Feedback or didn’t happen: How we use VoC solutions?
It’s just like drinking-2-litres-of-water-per-day case all over again. Everyone seems to agree about it, but the majority does not care much to follow it in their daily life. Similarly, if you are a product person, you’ll be harshly lashed out if you say anything against collecting feedback from end-users, even though you have no interest in giving your users a voice.
Let’s stop here for a moment and take a look at the logic behind it. Why is it so critical to gather user opinion?
Despite the numerous benefits of having daily harvested feedback from your users, feedback collection comes into the picture with two essential questions:
- How to collect feedback?
- How to use feedback?
First one is relatively easy to answer. You either create a team & department with a growth mindset or consult someone to learn the intricacies of collecting opinions. In our case, we’re the ones who can teach you the intricacies.
It’s quite rare to come across a project owner who needs help with implementing VoC tools or analyzing the collated data. It’s more like there is a project to be completed and we are the crusaders to bring the idea of gathering user feedback to the table.
There is a stark difference between those who understand the importance of what users think and those who try to trim any UX research resources assigned to a specific project. To be honest, it’s utterly unspeakable to bring forward such an idea, cutting of UX research from a project plan, which could be also framed as I-do-not-care-what-my-users-think-or-feel. But, we see it and we circumvent it at any cost.
You still may ask how to collect it. Let us explain: It’s easy.
We use well-known tools like Hotjar or Usabilla to seamlessly integrate the UX research phase of our design methodology into projects. We configure polls, surveys and keep the pulse of user behaviour directly and consistently to develop stories, features and eventually products built upon user needs. Regardless of the context, the steps are as follows:
- Find a problem or question to investigate
- Determine who is your audience
- Employ the right tool & logic
- Build a feedback loop
- Decipher the results
- Turn them into actionable backlog items
If it is all done, then we can move onto the second question. How to use feedback?
Even though it’s an undeniable fact that you need feedback in each and every step of your product lifecycle, using feedback in a meaningful way requires planning and structure. You first need to frame your effort with a purpose: Why do you need feedback?
→ Feedback for product development
Great, then you need to specifically target pre-defined segments or cohorts and a set of features to choose your collection method. You should be methodical about sifting through collected answers with a prioritization framework. And, you need to configure a way to knit your ideas and user requests together to build a product that creates value while helping you reach your business goals.
→ Feedback for anomaly detection
Understandable. It’s never easy to concurrently design a product and launch something bug freely. Plus, the more the merrier in Quality Assurrance, right. Then, roll your sleeves up and help your users understand that their contribution is highly valued and making their product bulletproof. You may think of a way to reward them too. Just remember that your developers have also life and the collected feedback does not necessarily mean anything. Therefore, craft a way to pop your questions at the right time with the right tool. If you need help to kickstart, do not hesitate to get in touch with experts.
→ Feedback for customer relations
How can you separate B2C products from B2B products? Simple, take a look at the average support time spent on a user account.
If you’re operating a B2B product, you must definitely give your users an open channel, because their loss would shake things up depending on their share in your financial charts. You need to value them by simply asking for their opinions and feelings regularly, also you probably should create customized solutions based on their ideas. In the meantime, the crucial thing for you is not to be entangled with the size of the feedback you collect and to stay on track when it comes following your roadmap. While keeping your users happy by giving ear to their opinions, you must act to ward off any gibberish that reaches to you. That means you need an intricate, more complex feedback mechanism that might have logical jumps and in-depth functionality to automatically assess the quality of given feedback. To create such a practice, you need someone who knows your product top to bottom and the questions that have been asked frequently.
As for the conclusion, one thing became very clear: You need feedback to outcompete the competition. I reckon there are many more noble purposes to collect feedback, but this is what we do fairly regularly to help our project owners with giving their users a voice.
If you think it would help you listen to your users, for any reason at all, then let’s have a talk about how you can do it.