Eric Karjaluoto

Ignore (Some) User Feedback

If you do services-based design work, certain devices are useful. Research, scenarios, user interviews, and other mechanisms can help you make sense of user behavior. These can also be useful for product-based design, but they’re not quite as necessary. This is because you can see for yourself what users do—and they’ll tell you.

User feedback is useful in aggregate. When 10 (or 100) people tell you your onboarding process is confusing, you have work to do. That said, all opinions are not equal, and you need to factor this into your decision making.

Truth is that one-off opinions are rarely ever that important. In fact, they can be outright misleading. Follow every bit of advice from individual users, and you’ll make changes that prove detrimental to your product.

I run into this from time-to-time, while working on Officehours. A user reaches out, furious about some approach we’ve taken, or a feature we haven’t included. Sometimes this is well-intentioned feedback. At others, it’s less productive. In either circumstance, his/her feedback is hardly ever critical.

Users often confuse their needs with common requirements. In my experience, this bias is not restricted to any one type of user. Novice and expert users alike convince themselves that their needs are universal. Some will even claim you’re clueless for making something they’re slightly inconvenienced by. (E.g., Familiarizing themselves with the news feed, each time Facebook redesigns it.)

This problem occurs when a user confuses him/herself as the user. Again, this isn’t uncommon. We’re all narcissistic, and believe the world should work around our needs—and not the other way around. (This is worse as a result of the “cult of the user” time we live in, in which every user seems to believe that his/her UX opinion is the only relevant one.)

I don’t mean to imply that you should ignore your users. That said, I suspect there’s little worry of you actually doing so. Most startup folks are so fearful of losing users, they’re unlikely to dismiss any feedback. This concern can lead them to respond hastily to ideas/criticisms from individual users.

The downside with making changes around individual requests, is two-fold. The first problem is that individual changes are often reactive and don’t fit into a bigger plan. Additionally, what one user likes in a user interface will disappoint another. If you’re looking to please every user, you’ll find yourself bouncing from one bit of rash feedback to the next.

There’s a reason why Apple products are great. Their designers care so much about users that they’re willing to ignore some feedback. Remember all those folks who insisted on a physical keyboard on their mobile phones? Tell me: who was right on this matter?

Should you listen to your users? Yes—absolutely! Should you react every time a user asks you to make a change? Heck, no! You direct the product, and you maintain the long-term vision. Few others understand your product as comprehensively. So, ask users questions, and consider their responses. At the same time, try to remember that there’s just as much bad feedback out there, as there is good.

On an unrelated note, I’m working on a new podcast called The Kerfuffle. I hope you can find some time to give it a listen.

Sign up to receive new articles by email: