Reckoning with expertise

Do you remember the first time you tried to drive a car? It’s an exhilarating and terrifying experience, as you attempt to coordinate the efforts of multiple body parts, your attention continually being pulled this way and that as you try not to crash into anything and maintain control of the vehicle.

Many hours of experience later, driving is no longer the attention hog it was in the beginning. Most experienced drivers can successfully manipulate a vehicle while simultaneously performing other activities: participating in conversation, adjusting the radio, eating a snack, etc. Indeed most of us have had the experience of driving a long distance while retaining no conscious memory of the journey at all.

This common experience is an example of expertise, i.e. the application of a great deal of experience in a specific domain. As our driving example illustrates, experts process information in their domain of expertise differently than novices. Cognitive scientists study experts in the hope of understanding the brain processes that underlie expertise, with a further goal of capturing the essence of expertise in computerized expert systems. In one famous study, chess experts and novices were briefly shown a chess board with a number of chess pieces on it. Later, they were asked to recreate the chess board. Chess experts were significantly better than novices at this task. Unlike the novices, experts were able to identify meaningful patterns in the arrangement of the pieces and use this information to remember them.

Importantly, this finding only holds true if the layout of chess pieces come from actual chess games. When presented with an equal number of chess pieces arranged truly randomly, the chess experts were no better than novices at this task.

The key ingredient here is expert’s ability to chunk meaningful information. Most people are able to hold about seven “pieces” of information in their short-term memory (known as “Miller’s magical seven, plus or minus two”. This is true for experts and novices alike. The key distinction between experts and novices in this regard is what constitutes a “piece of information.” Experts are able to pull related bits of information together into a single chunk. For an expert, then, seven chunks of information in their domain of expertise represent a significantly larger amount of information than the novice’s seven chunks. In the chess example, experts are able to see groupings of pieces as units of information.

This chunking of information happens naturally with no conscious effort on the part of the expert. Indeed, most of the magic of expertise happens outside of conscious awareness. It is like the driving example from above. The expert driver is performing all of the same actions as the novice driver, but is doing so without even thinking about it. Brain studies of developing expertise back up this observation. As it turns out, novices and experts use different parts of their brains when processing information related to their area of expertise.

That bears repeating because it’s staggering: Experts are using a different part of their brain when processing information related to their area of expertise.

So what does this have to do with design? We deal with experts all the time, from the experts involved in the product design, to experts who are the intended targets of the product. Understanding expertise will improve the design process and the products that result from them.

You are an expert

The first expert to consider in the design process is you. Except in the rarest of cases, you are not like your target market. Whether you are a product manager, an interaction designer, a visual designer, or an engineer, your brain has undergone dramatic changes over time. Your brain is not like the brains of your target market. We caution against the dangers of self-referential design all the time, and this is just another example of why this is so important. You are not designing for your brain; you are designing for a different brain.

This was brought home to me vividly in a recent project I worked on. The product included a web browser, and the target market for the product included people who are remarkably like me—at least on paper. They had a similar economic and educational background as me, and they spent about as much time online as me (which is saying something). I thought I would finally be justified in doing a little self-referential design in this case, because after all I am in the sweet spot of the intended market. Right?

Wrong. Our research revealed to me how much of an alien I really am. As it turned out, the patterns of behavior we observed were nothing like my own. Regular humans who haven’t spent years studying software, playing with software, and designing software as I have simply approach computers and software differently than I do. My brain has been forever altered based on my experience, and to design a product for regular humans based on the impressions of my modified brain is a grave error.

This is where quality research followed up with design tools like personas and scenarios come in to play. These tools allow you to design for a brain quite different from your own.

You learn from experts

If you are designing a complex product, you are going to deal with experts such as subject matter experts who help you understand the domain, or you may be designing a product for experts. Either way, you are going to have to talk to experts and fold what you learn from them into your design. The problem is, if you are a novice in the domain in question talking to experts is like trying to learn from someone who speaks a different language.

Remember that the expert has no conscious awareness of his expertise, and therefore usually cannot provide an accurate verbal description of how he is processing information. This will not stop him from trying, of course, or even from believing that what he says is accurate. It is a well-established phenomenon that humans will attempt to create conscious rationalizations for any number of unconscious processes in the brain. In an analysis of the literature on expertise, Dreyfus & Dreyfus (2005) make this very point:

“If one asks an expert for the rules he or she is using, one will, in effect, force the expert to regress to the level of a beginner and state the rules learned in school. Thus, instead of using rules they no longer remember, as knowledge engineers suppose, the expert is forced to remember rules they no longer use. … No amount of rules and facts can capture the knowledge an expert has when he or she has stored experience of the actual outcomes of tens of thousands of situations.”

This is why asking an expert to describe how he is interacting with his domain of expertise is unlikely to provide good results. At Cooper, we always try to avoid building what users say they want and thereby “automating the misery.” Understanding how expertise works reveals one reason why this is a bad idea: Expert users don’t always have conscious access to what they really need.

This is why observation is such an important component of research. A user’s behavior is usually a better indicator of his true goals and needs than are his conscious rationalizations.

Designing for experts

You may be designing a product intended for experts in a particular domain. A related and perhaps even more interesting problem is designing for users who are already or who will become experts at your product. So how best to design for experts?

First, look for the natural steps along the learning curve for clues to the heuristics experts ultimately develop. Try to observe people all along the spectrum from novice to expert. This can provide you with clues to the development of the expertise. Be open-minded about the patterns that you observe. A pattern may emerge that makes no sense to you, but that’s to be expected: you’re the novice.

If you are designing a product that your users will become experts at, be aware of the journey from novice to expert. Thinking of your product as a language is helpful here (language is something of a special case, but it stands in as a very useful analogy for expertise generally). Does your product use simple, direct language to the novice user? Or does it feel like it is speaking several different languages? Over repeated use, does it feel like it grows in maturity and depth, abstracting some of the simpler concepts into meaningful chunks? This is where consistent interaction patterns come in very handy. If interactions are inconsistent, it takes many more instances to develop expertise. This is why products created by glomming together acquired properties are so difficult to learn; it’s like trying to read a book written in multiple languages.

Designing for novices

You may be designing a product that is used infrequently for users who are not experts in the domain. However, everyone is an expert at something. Are there opportunities to piggy-back on your users’ existing expertise? Perhaps your product can rely on existing interaction paradigms that your users are familiar with (or “speak the same language” as existing products). Or perhaps you can take advantage of more fundamental expertise. One of the reasons touch-screen applications like the iPhone are so successful and feel so intuitive is that they take advantage of our existing expertise in the physics of the real world. I was able to teach an 18-month-old child to use the Photos application on the iPhone because he already knows about sliding things around on a surface. He didn’t need to learn anything at all about lists or files or “next” arrows to be able to use the application.

Wrapping it all up

If you only take one thing away from this discussion, let it be this: an expert’s brain is different from a novice’s brain. Consider that when you work with all the experts you will come into contact with during the course of creating your product: stakeholders, subject matter experts, designers, users, and so on. They are all experts at some things, and novices at others. They have all rewired their own brains to their own purposes. If you take the time to consider the implications of this, your products will better serve experts and novices alike.

Dreyfus, H.; Dreyfus, S. (2005). “Expertise in real world contexts”. Organization Studies 26 (5): 779-792.

6 Comments

stefan klocek
Perhaps this is why experts can also be the most resistant to changing how they do things? I was surprised at the push-back from doctors in switching from paper to computer based medical records. Their brains had made the shift into experts and note writing had become an almost subconscious activity. Switching back into beginner brain with electronic medical records represented a significant hit their current efficiencies and learned expertise, even though objectively the switch would deliver significant advantages.
Pablo
Hi Jenea. I like a lot your post...so I translate it to french ... http://www.areyouagile.com/2011/01/considerations-sur-lexpertise/ Bye
Jenea
@Pablo: Wow, that's cool! Thanks! @Stefan: It's certainly somewhat painful and cumbersome to have to go back to a novice space where learning something new takes conscious effort, especially if you already have a system that works for you that is largely automatic (outside of consciousness). Besides, a computer-based system requires doctors to master several skills at once (at least for those who are not already technically proficient).
Jasmin
Thanks Jenea, you've articulated this really well, and brought the journey from novice to expert back to the top of my mind. You've also explained why sometimes I get so frustrated with experts dismissing the needs of novices! Forgetting the start is no excuse for ignoring the start :-) My mantra for today ...
Bryan Yurasits
This also applies to training and presentations. I recently ran into this problem when cross-training to work on another team's website. My team was getting deep details of the code without being given a tour of the website's features or structure. The presentations were geared towards expert developers of the site instead of novice developers of the site. Even with both teams being experts in the same web technologies it felt like they were speaking to us in a different language.
Vukašin
Epic post, thanks.

Post a comment

We’re trying to advance the conversation, and we trust that you will, too. We’d rather not moderate, but we will remove any comments that are blatantly inflammatory or inappropriate. Let it fly, but keep it clean. Thanks.

Post this comment