Blog

Users Are Not Always Right

A while back (on another UX blog), I posted about how it’s not always good to listen to your web users. I just wanted to reiterate that concept here, since lately we, at Methink, have been getting projects where we need to actually ignore what users would traditionally want. Sometimes, when you’re developing web products or systems that redefine what users are customarily used to, user’s just do not have the capability or insight to provide developers with quality feedback to help build a better product.

For example, in the video below, Paul Buchheit (creator of Gmail and founder of FriendFeed), talks about the importance of listening to users, but ignoring them on certain occasions. He quotes Henry Ford, who once said “If I had asked people what they wanted, they would have said faster horses.” Obviously, before the invention of cars, people would not have been equipped to give proper feedback on how to make cars better. Anyways, great video by Paul on how to listen to users.

  • I agree. It's definitely up to us designers and developers to always learn how to communicate better. As Paul says throughout the presentation, the key concept is to learn "how" to listen to users...not to listen to them at all cost. Most developers are aware that "always" listening to users can often lead to bad development practices. I think that ability to understand and read between the lines of "what" they are saying is the art of client/user communication.
  • ColoradoMatt
    "...user’s just do not have the capability or insight to provide developers with quality feedback to help build a better product."

    To me this smacks of a bit of hubris. Communication has two sides so I don't think it's fair to say that users don't have the ability to communicate. Perhaps it is we (the designers and developers) that need to work on our communication abilities with regard to understanding the signal.

    I think Paul makes this point well with his radio signal metaphor... it's our dial that needs adjustment, not the signal itself.
blog comments powered by Disqus