Why Users Don’t Make Good Designers

Some approaches to product development advocate engaging users directly in the design process, as co-designers. Along this line, a new client recently suggested that we organize several joint design sessions with their clinical advisory panel, and bring along a developer to the meetings who could incorporate the panel’s design ideas into a software prototype, “on-the-fly.” We (gently) moved our client away from this approach, by convincing them that in general, users don’t make good designers.

On the surface, inviting users to actively participate in design sounds like a good idea. After all, users have two qualifications that would seem to make them well suited as designers:

  1. They use the product. Who better to know what’s good and bad about it, and how best to improve it?
  2. They’re clinical domain experts. Who is better qualified to define what a product should do and how it should work?

But both arguments are suspect. Here are six reasons why users do not make good designers:

  1. Users are too firmly rooted in their own perspective. All of us, as regular users of products, can be so entrenched in our way of doing things, that we can’t appreciate the merits of other approaches. A key challenge of design is creating a solution that will meet the common needs of a large enough group of users for the product to be commercially viable. Professional designers utilize a range of techniques to help define this broader perspective, including contextual inquiry, user profiling, and persona development.
  2. Users of a product often fail to see its design limitations. If we can’t recall the name of our patient even though it was presented on the previous screen, we’re more inclined to chastise our failing memories than the designer of the device for not displaying the information where we need it. We simply accommodate poor design by inventing workarounds. After a while these work arounds feel like the normal way to do things.
  3. The “users are clinical experts” argument confuses domain knowledge with design knowledge. Just as clinicians are highly skilled in their specialty, designers are highly skilled in theirs. Professional designers receive several years of formal training, and seasoned designers have practiced this skill across numerous design projects. Just as living in a house doesn’t qualify you to be an architect, using a product doesn’t qualify you to redesign it.
  4. A user’s own account of what, how and why she does things may not be accurate. Psychologists have shown repeatedly, that despite our strongly held beliefs to the contrary, we often do not know how or why we do what we do. If, for example, you asked a physician how she arrived at a diagnosis, she may well describe an analytical process of weighing presenting symptoms and ruling out competing hypotheses. But research has shown that clinical expertise (as with expertise across many domains) is largely a matter of pattern matching. This pattern of symptoms looks like those of a prior patient. Our clinician isn’t being dishonest when she describes a different process. Rather, she is describing how she was taught. Her problem is that much of the mental work that supports her ability to diagnose problems based on a complex pattern of symptoms goes on below the level of her conscious awareness. Our conscious mind simply isn’t privy to what goes on beneath it. Our thoughts would be over-whelmed (not to mention exceedingly slow) if it was.
  5. On a related note, just because someone can perform a complex skill or activity, doesn’t mean they are good at describing how to do it. Cognitive psychologists characterize this difference as a procedural-declarative gap. Procedural knowledge enables us to perform complex skills and activities; declarative knowledge enables us to understand and describe them. They are two different knowledge systems. In the same way that an artist may produce a remarkably creative painting but be able to say little about her own creative process, a lab tech may be quite skilled at differentiating analytes under a microscope but unable to articulate how she does it. Designers need to understand the how and why. Being a user doesn’t guarantee that you know this.
  6. Like the proverbial kid at the candy shop, users sometimes ask for more data and features than they end up using. What can seem like a good idea (“show me everything”) may not work well in practice. Predicting how we will make use of something is inherently difficult. Design professionals use techniques like scenario-based testing to engage users in trying to simulate actual use in an effort to overcome the limits of prediction.

Conclusion

While the design professionals at Human Factors MD are strong proponents of involving users in the product development process, we don’t encourage active participation of users in design. User involvement is critical for understanding and refining requirements, as well as evaluating and providing feedback on designs as they evolve. But by-and-large, users do not make good designers.