User feedback and defining the product roadmap from customer support
Build what your users need, not what they want
We all know that a product is never done and never delivered. Milestones are being delivered but never products. Any designer or member of the product team, will tell you that: Products will never be complete. They are always evolving and milestones and product roadmaps are always shifting and morphing into some new feature everybody is awaiting for. The question here is: Do they actually need that long-awaited feature?
If you look around you will see a lot of designers asking for user feedback on what they want and how they want it. Feedback forms, website popups, surveys… The list is endless. Customer-centric has become the production process buzzword that’s here to stay. And once the customer has given their input, product teams start building a product from the wants and hows of the user feedback. The thing is though, asking questions is only helpful if they have a purpose. Designers should start asking more ‘why’ questions, at least 3 in a row to understand the underlying problem that the users actually have in the back of their minds and don’t realize.
Does it make sense to design something that your users want? No
Does it make sense to design something that your users need? Yes
The agile process of refining a design
Agile, agile and agile again. Another buzzword that has become a cornerstone of the product design space. One of the big benefits of being agile, and one of the reasons it has become a mainstay in product design, is always delivering small improvements and measure them when you launch them.
Gather feedback, measure and go back to the drawing board trying to improve the just-launched feature or MVP version of your product.
At this point, you’ve got to be tired of designers and product owners preaching agile methodology, but this isn’t a deep dive into that, don’t worry 🙂
However, we do need to discuss it. But it’ll be super short, promise!
Benefits of Agile:
– You can deliver faster small features
– You can make mistakes, learn from them and fix them in the next release
- No finite end, it’s hard for everyone in the team figure out where the product is going next
- It’s hard to measure a platform that is always changing
One of the most common misconceptions about Agile methodologies is:
“Don’t worry about requirements for designers, we are Agile, we can build this now without them”. Being Agile DOESN’T mean no requirements.
Listen to all ideas, not just from user feedback
One of the biggest mistakes that designers do is send people with potentially great ideas away because they are super busy trying to build reports and listen to actual users.
Everyone can have an idea, don’t send people away. Record that idea and make sure it’s being discussed and put in a UX Backlog. Gather data about it, do your customers encounter the same problem? Can some problems identified in you customer support tickets be solved with that idea?
Once you have some data about that idea go back and discuss it with the person that came up with that idea and the Product Manager to prioritize it and add it to the product roadmap.
For obvious reasons, the team here at Cx Moments are big fans of collecting data from customer support platforms. Our platform provides insights and reporting from customer support conversations. Why does this matter? Because customers are not always going to fill out product feedback surveys or make an effort to isolate where these features are causing friction.
What they do make an effort in is the conversations with customer support. Using artificial intelligence to analyse these tickets and categorise based on issues/ product feedback allows you to get not only a view of the volume of tickets with this issue but the very specific frictions it causes for customers. In fact, its a method we use in our own development process.
You can always go there to understand a problem and to build ideas backed by real use cases. That is a territory that often gets forgotten by designers. There you have tons of real conversations, real issues and real inputs from your users, it’s free and is accessible any time of the day.
The Met Office methodology for product feedback
Met Office UK is a great example of a great UX process. In spending some time talking to James Reader, who is a Lead UX designer from Met Office, a really clear and valuable picture has emerged in the way he is supporting his team to use data to gather and prioritize their user’s needs.
Met Office used this method of gathering and analysis customer feedback after launching a new service. The Met Office website has billions of yearly sessions and the feedback when they launched the product overhaul was impossible to analysis in any meaningful way without a tool like Cx Moments.
Their key goal in this analysis was prioritisation. The prioritisation was set out in a few ways, all of which Cx Moments is incredibly helpful with. Spotting trends, understanding what percentage of users had particular issues, building feedback themes (this was done by reading free-text feedback within topics and then abstracting what the user was saying he was having trouble with back to the problems they try to solve at a product level). This looks like this, User group A says wee hate the new scrolling on the site, What are user group A trying to do that the new scrolling causes problems for? that is the problem Met Office try and design for. As James is keen to point out “We do not just fix stuff that users ask for, we always try and understand what they need”.
James has provided us with some key points on how he collects and uses customer support feedback to augment the product roadmap and design process.
Leveraging user feedback is crucial
Customer feedback is important. Knowing how and why customers engage with a product as well as how they feel about it can help you drive important changes and give you a better sense of how the product should be moulded.
Sometimes quantity is more important
It goes against nearly every design ethos but when dealing with customer-centric design, you need to look at numbers. Building a product based on customer feedback means you need to take into account the number of people who either have an issue with, or don’t understand a feature or the product as a whole.
A few tips from met office on leveraging customer support data
- Start with the problems.
- Get organised. Sort bugs first to get them into backlog, find keywords and sort them by volume. It’s a good indicator something isn’t working for customers.
- Let customers say what they want, however, they want to say it. Letting customer enter free text means they are giving more authentic feedback in their own words than if they were restricted by a list of options.
- Unless you’re an Excel genius, invest in an AI/NLP solution. Feedback builds up quickly. Unless you want to be buried beneath spreadsheets, tabs and graphs you’re better of working smart and letting a machine do the heavy lifting when sorting the feedback.