This is an article by Jenea Hayes on Cooper that I really appreciated and wanted to share with non-English speakers. Thanks Thomas for putting me on the trail of this article.
Jenea wrote:
Considerations on expertise
You are not an expert
Do you remember the first time you tried to drive a car? It’s an exhilarating and terrifying experience to attempt to coordinate several parts of your body! And while our attention is focused on this coordination effort, it’s hard not to crash into something and keep control of the vehicle!
After several hours of practice, however, driving is no longer torture. Experienced drivers can easily steer their cars while doing other activities: having a conversation, adjusting the radio, eating a sandwich, etc. Indeed, many of us have driven long distances without remembering the details of the day, driving unconsciously.
This is the experience of expertise, that is, the implementation of a large dose of experience in a specific domain. What our driving example illustrates is that -in their domains- experts manage information differently from novices. Researchers in cognitive sciences study “experts” in the hope of discovering what the brain implements when there is expertise, with the objective of capturing the very essence of expertise in order to build “expert” systems. In a famous study, grand chess masters and novices were confronted with a test: they were quickly shown a chessboard with certain pieces on it. Then, they were asked to recreate it by positioning the pieces as they had seen them. The grand masters were significantly better than the novices at this game. Unlike novices, the experts were capable of identifying many patterns in the organization of the pieces and using this information to remember their locations.
Careful, this is only true if the arrangement of the pieces corresponds to something plausible (in a chess game). If they were presented with a certain number of pieces scattered on the board randomly, the grand masters were no better than the novices.
The key factor here is the expert’s ability to group elements into blocks of complementary information. Most people are capable of apprehending 7 pieces of information in their “immediate” memory (this principle is known as “Miller’s magical 7”). This is true for experts as well as novices. The essential difference between experts and novices is therefore what constitutes information for them. Experts are capable of aggregating several elements into a single piece of information. Thus, for an expert, 7 elements in their domain of expertise aggregate into a single piece of information. And so 7 pieces of information in their domain of expertise represents far more elements than the novice’s 7 pieces of information. In the previous chess example, the grand masters are capable of aggregating several pieces into a single piece of information.
This aggregation of information occurs naturally, without conscious effort on the part of the expert. Because the greatest part of the magic of expertise resides outside of consciousness. It’s like driving, if you remember the example above. The pilot performs the same actions as the beginning driver, but does them without even thinking about it. Brain studies concerning expertise have noted this fact. It seems that people don’t use the same parts of their brains depending on whether they perceive information from one of their domains of expertise or not.
I stress this point because it’s fundamental: it seems that people don’t use the same parts of their brains depending on whether they perceive information from one of their domains of expertise or not.
And so, what does this have to do with our work? We work with experts constantly, those who are involved in making a product, those who are the targets of that product. Understanding expertise well will help us better design the products we create.
The first expert you encounter is yourself. Except in exceptional cases, you are not exactly like the target of your product, your project. Either you’re a product manager, or a designer, an art director, a developer, etc. your brain, your thinking has evolved enormously over time. Your perception is different from that of the target of your product, your project. Beware of the danger of imagining yourself representative of your product’s expectations. You are not designing a product for yourself, but for another.
This suddenly struck me on a project recently. The project included a website and the target of the product seemed to be myself, to a tee! at least on paper. Same economic and social profile, spending as much time as I do online, on the internet, (which is no small thing), etc. I thought that for once I could use myself as a reference to develop ideas, because I was exactly like the product’s target. OK?
Wrong. Our research revealed how different I was! Over time, the behaviors we observed (in the target) were very different from mine. Normal people who haven’t spent years studying computer science, playing with computers, manipulating software, designing software necessarily and simply have a different approach from mine. My perception has been forever altered by my own experience, and designing a product based on this modified perception is a serious mistake.
This is why we need to use tools like personas and scenarios (translator’s note: “personas” are imaginary characters who represent the people who will actually use the product. We often invent a life for them, qualities and flaws, a photo, etc.). These practices allow you to design products made for people different from you.
You learn from experts
In the case of a complex product, either you will have to work with experts to make it, or you will have to design this product for experts, or both. In any case you will have to talk with experts and design this product from the information you gather. The problem is that if you are a novice in the domain, talking to these experts is like talking with someone who speaks a different and unknown language.
Remember that experts are not conscious of their expertise (at least of how they use it), and often are not capable of clearly formulating what mechanisms they implement in their perception. This won’t stop them from trying, naturally, or even thinking that what they express is precise and simple. The fact is well established that we -humans- often try to rationalize and understand unconscious phenomena of thought. In an analysis of the literature on expertise, Dreyfus & Dreyfus (2005) thus write:
“If you ask an expert how they proceed, it will push them, effectively, to put themselves back at the novice level and explain the rules they learned in school. And so, instead of stating rules they don’t remember, as one might imagine, the expert is forced to remember rules they no longer use. In fact, it is impossible to quantify an expert’s experience, the sum of knowledge built on an incalculable number of different situations.”
This is why asking an expert to describe how they interact with their domain of expertise rarely gives good results. At Cooper, we try to avoid producing what the user says they want, so as not to “automatically impoverish” the need. Understanding expertise provides a good reason for this: expert users are rarely aware of what they really need.
This is why observation is a key factor in research. A user’s ways of doing things is a better indicator of their real objectives than the need they will express rationally.
Designing for experts
Perhaps you are designing products for experts in a particular domain. An identical problem, and perhaps even more interesting, is designing for expert users, or those who will become so, on your product. So how do you design for experts?
First, let’s take a look at the classic stages of learning as heuristic experts do. Let’s observe people from the novice stage to that of expert. This might give us the keys to developing expertise. Be open to what you observe. A pattern could emerge from what doesn’t yet make sense to you, but that’s not surprising: you are the novice.
If we’re designing a product with which your users will be experts, keep in mind the path that leads the novice to expertise. Thinking of your product as a language is useful (a language is a special case, but it works quite well as an analogy for expertise in general). Does your product communicate in a simple and effective way to the novice? Or does your product seem to speak different languages at the same time? With use, does the user improve, mature, gather simple concepts into meaningful sets? This is when the interactions (translator’s note: with the product) become crucial. If the interactions with the product are not quality, it will be much longer to develop this expertise. This is why products created by aggregating the work of several people are so difficult to learn, it’s like reading a book written in several languages.
Designing for novices
Perhaps you are designing products whose use would be occasional, by novice users. However, everyone is an expert in their domain. Might there be opportunities to use this expertise despite everything? Perhaps your product can rely on methods or ways of interacting with which the user is already familiar (“speaking the same language” as other products). Or perhaps you can rely on a more fundamental, more common, more basic expertise. One of the reasons for the success of touchscreens like the iPhone’s is that it is based on our expertise in the rules of elementary physics. I was able to teach an 18-month-old baby to use a photo application on my iPhone because they already knew they could slide things on a surface. They didn’t have to learn anything new, no “options list”, “file”, or “next” button for the application to work.
Let’s summarize all this
If you should retain only one thing from this text, it’s this: the perception of experts is different from that of novices. Consider all the experts with whom you will work during the product design: business managers, functional managers, management, technical managers, users, etc. They are all experts in their domain, and novices elsewhere. They have all transformed their brains for their needs. If you take the time to think about this, your products will be better for experts, as well as for novices.
Dreyfus H. & Dreyfus S. (2005) “Expertise in real world contexts”. Organization studies 26(5):779-792
My translation is far from perfect, don’t hesitate to give me feedback for correction.