Inherent to the design process, â€œthe user” is regarded as the prime source of necessary, valuable, actionable information for making sensible design decisions, captured in a variety of forms, from A/B tests to in-context interviews. However, we should be careful in assuming that users have all the answers or, to put it bluntly, know whatâ€™s best. Before we appoint “the user” to the holy pedestal of infallibility, itâ€™s worth remembering the following:
* Users (i.e., humans ;-) are contradictory, messy, emotional beings with hidden motives and desires, and often have difficulty articulating them accurately. They may have an instinctive sense for something being “not quite right” or “just spot on”, but often have a very hard time expressing it in a way that product decision-makers can act on it effectively. This includes theÂ lack of proper language to convey it well (â€œMake the button red and flashing” is usually code for â€œthis button is very importantâ€, not actually put burning flames on it.)
* Users usually only know their current situationâ€”thus, can helpfully itemize all the perceived problems from their POV. However, they may not have a sense for how to improve things in a significantly useful or novel way. that â€œconnects the dotsâ€. Â This requires stepping outside of themselves to spot opportunities they might be blind to.
* Users are quite good at local tweaking, optimization of their specific tasks against known or perceived problems, of some tangible factor. But not necessarily global, architectural, flow-level issues of coherence, integration, aggregation, of the entire ecosystem, since many rarely experience or see the total system.Â
* Users aren’t empowered to make tradeoffs and compromises impacting the final product or service deliveryâ€”which might effect other users beyond themselves! The product team has that responsibility. Users don’t need to know all the inside baseball that goes on, of course, but designers do and that necessarily impacts what’s possible, viable, feasible just as much as what the user needs.
Ultimately, users are not designers. I know itâ€™s obvious, but itâ€™s true and often has to be stated. Thatâ€™s why well-trained and educated designers are hired, for their ability to interpret and transfer user-oriented findings into strategic and tactical, well-considered, decisions around affordances, semantics, task flow, visual style, and functional value. Users are essential to that process but not sole bearer of all the answers, for a good reason!