Standard Operational Procedure: Feedback Validation Cycles
Note: This is one of my work as Product Designer at Sehati TeleCTG. Some informations are changed to keep the confidentiality of the company’s valuable data.
Problem
In some product environment, it is hard to decide which complaints should we listen to and which issue should we improve. At the early level of product release, where the adopters are one of the most valuable resource, especially for insights and improvement purposes, most common action a product designer do is: listen to every complaints, fix them all. The question is, is it equally important to change the loading animation compared with the data visualisation? How do we keep the development roadmap on track? Or which issue is more important than the other?
Solution
In my team, we decided to create a regular activity to validate the feedbacks, called Feedback Validation Cycle (FB Cycle n). What is FB Cycle? Simply, a 3 phase activity where a team formed from different departments are deployed to validate feedbacks we’ve collected regularly.
The 3 phases are: Collection Phase, Validation Phase and finally Handover Phase. Each phases are involving multiple departments to spread the knowledge of issues and progress.
Collection Phase
At the Collection Phase. Which held for maximum 2 months, we opened our “dropbox” sheet contain the detail of issue or feedbacks coming from any employee among the company. The dropbox contain: Issue date, name, details, source, area where the issue coming from (from province to city), platform and employee who discovered the issue.
At the end of the Collection Phase, the Feedback Validation Team starting to sort the issue based on the relation of the issue or the number of the most mentioned platform. For example: We compiled the issue and finds out that there are 3 issue coming from our mobile apps and 4 from our web-app. After the compiling process, we discovered that 2 out of 3 issue from mobile apps are related to 3 or our web-app issue. In this case, we decided to execute those 5 issues for this cycle, leaving the rest waiting for the next cycle.
Validation Phase
The Validation Phase are divided into 2 parts:
a. Pre-validation: The FBC Team are formed by various team member, including people from Product Department, the UXR Team. In this phase, UXR team create an online questionnaire. The questions are based on the Opportunity Scoring Framework.
b. Validation: At the validation phase, we compiled the questionnaire results. Typically, the result are:
Sometimes, the result didn’t run well. It leaves biases, or the questions are misinterpreted by the respondents. If the problem occurred, FBC team sorted the result and distribute the failed task to UXR team for further research and leave the rest to the Handover Phase.
Result
After implemented this method for 2 cycles, we’ve discovered the fittest mechanism at the third cycle. At the first cycle, we experienced the Feedback Validation Cycle impact. Team are no longer debating which issue to solve, whose voice are most valuable, and else.
