User feedback is one of the bloodlines for creating user-centric designs and the reason for this is simple. Feedback helps you see beyond your biases and assumptions, thereby helping you make experience design decisions that are factual. Ensuring that your product is solving the problem in a way that meets and perhaps surpasses user expectations.Before I started my first job at Dillali, I didn’t understand the extent to which user feedback could help improve products. I would always wonder how people who didn’t know anything about design could help make my designs better (that’s pretty smug, I know) but I was new to design and didn’t know any better.

I remember my first user sprint. It came with lots of aha! moments, arising from insights and the stints of errors I had missed, despite having looked over the designs and experience a thousand times. To say it’s the most transformatory moment yet in my career is an understatement.By the end of that sprint, I had a lot of work to do, which honestly didn’t feel good. But it was great to have a better direction towards creating a great user experience. Asides that, it saved the entire team from a number of design debts, especially from edge cases that would have arisen had the feature been shipped without proper testing. Ultimately, we had the pre-emptive advantage of solving problems before they even materialized. There are, however, instances when you can and should say “no” to feedback (not to the user’s face, obviously). From experience, here are a few instances when, and reasons why saying no to user feedback can work out well.

The product’s milestone

As much as you want to create the best experience for the users of your product, you need to consider the product’s milestones and roadmaps before implementing feedback you receive from your users.

This is very important to keep you on track with your company’s visions and goals.

Let’s say you’re working on a redesign of your product and decide to see how your users will receive this new look and feel. Amongst the sea of feedback you get, some people ask for a new feature. Valid, right? But you really should not stall the release of your redesign by adding these new features to your product, because your main goal is a redesign and not a feature release.

I’m not alluding that you should throw the feature request out the window, however your current goal takes precedence over it. You can make the decision to save those insights for use in future updates. Sort of an incremental release pattern.

Timing

We all agree that time is of the essence in product development and in startups, delay can be lethal. So time is a very important factor to consider. Oftentimes, implementing some feedback would mean taking a lot of time to redesign and more time to develop, and this is not feasible, especially if it’s not an immediate need or something that could invariably alter user satisfaction.

For one, it would likely disrupt your roadmap, invariably affecting the launch date. Similarly, the team runs the risk of falling into analysis paralysis — a scenario you should avoid at all costs.

Come to think of it, there will always be feedback, and if you try to act on everything before shipping, you’ll be stuck in a loop. Focus rather on making the product as usable as is possible at the time, and launch. Any useful feedback can be released as updates, to improve on what already exists.

The user’s persona

Your users, despite having commonalities, are still a diverse bunch. And this diversity, however minute, can drastically affect how they receive and interact with your product.

I have encountered a user who was accustomed to using complex systems. Due to her background, her feedback was mostly complex. Although we got a lot of insights from it, we sadly couldn’t act on any because that would have made the feature too advanced for users who do not have her level of expertise.

There are also users who would give only commendations, despite having some difficulty navigating your product. Instead of dwelling on the mostly positive feedback, you should observe the edge cases related to the flow and resolve them.

In my opinion, the best way to treat user feedback is to take insights. Be more interested in the significance of what your users are saying or doing rather than the what. During testing sprints, be open minded and attentive to your users. Document all feedback; deliberate on them carefully with key team members; ask as many relevant questions as possible before choosing what to ignore, even if for a while.