One of the newest members of the extended Cooper family has his own unique approach for consuming media.

• Susan held open office hours on how to conduct user feedback sessions with the team at Rock Health.
• Renna makes her way to the Mayo Clinic's Transform '11 to share progress on the Center for Disease Control's Healthy Aging 5over50 initiative.
• The counter-point of where good user experience ideas come from is quite compellling as we continue to consider the implications of the end of client services.
• The obsession for animated gifs shared by a small but growing number of Cooperistas continues: via Stefan, we have this week’s choice link of living, breathing cinematographs.

We celebrate the launch of Platfora, the first company to harness the power of Hadoop. Cooper is partnering with Platfora and we helped them launch a new website in just a few weeks. Congratulations to the Platfora team!

That hot post on the Fast Company Design blog, User-Led Innovation Can't Create Breakthroughs; Just Ask Apple and Ikea, is both wonderfully true and dangerously wrong. I want to both make it required reading for all my clients, and also bury it underground where it will never again see the light of day.

It is deeply and importantly true that you should not build what your users ask for (or put another way, you should not ask your users what to build). At Cooper we call that “automating the misery.” One commenter on the original post reminds us of the Henry Ford quote:

“If I'd asked customers what they wanted, they would have said 'a faster horse.'“

If Ford had listened to his users, he would have bred faster horses and made better saddles, and he wouldn’t have put out a game-changing product. Many of our clients come to us with a history of producing bad user interfaces, and they can’t understand why when they have included every popular feature request from their users.

The reason for this is very simple: users are not designers or visionaries. We should no sooner ask them to design a product than we would ask them to write the code.

Where this article gets it very, very wrong is in the implication that being user-centered, talking to users, or understanding them at a deep level is not important or even antithetical to creating a game-changing product. Apple and Ikea are held up as the prime example of this. But both of these companies make products for consumers. Their target market is not too dissimilar from the designers themselves. They can get away with not talking to users because they already understand them at a deep level.

But what if you’re designing a product for a user very different from yourself? What if your user is a heart surgeon? An architect? An investment banker? In these situations designers can’t draw on their own personal experience for inspiration, and shouldn’t. (Though honestly it might be funny to see Apple’s take on a heart surgery interface.) As I talked about in my blog post on expertise, you can’t use your brain to design for a very different brain.

Users can only tell you what they think they want to achieve their goals. It’s our job to listen to what they say, detangle it, and design something that they love. To be in a position to do what you do well—design visionary products—for someone not like yourself, you have to understand your users. Once you truly understand your users’ goals, only then can you create game-changing products to help them achieve those goals.

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.

No one can argue that social media hasn't had a significant impact on modern life. My current favorite example is the Zooniverse series of “citizen science projects” that bring people together to apply human brains to tasks in science that computers aren’t very good at yet, like identifying types of galaxies in Hubble images or craters on the moon. Supported and produced by the Citizen Science Alliance, this is social media at its very finest: Bringing communities of people together for the common good of humanity. The whole thing, I gotta say, leaves me a little verklempt.

On the other end of the ultility spectrum we have Cookie Bonus Solitaire, a little nothing of an iPhone solitaire game that cleverly bakes in cheating. It also incorporates robust social features like profiles and chat, achievements and leader boards, the whole shebang. I used to play Cookie Bonus Solitaire daily on my commute, but got irritated when there were constant updates to the social features of the program. Hello? Solitaire is not a social game, that’s why they call it “solitaire.” I finally deleted the game in disgust when it got to be too much, chalking it up to me just being some old fuddy-duddy who just doesn’t get it.

But, this is where I draw the line.

This is only acceptable in a home-care situation where people can keep track of the health and well-being of infirm individuals. Beyond that? No. Just no. Sleeping is not a social activity, and I say that as a married woman who sleeps alone only on business trips. What’s next? Social colonoscopy?

How did this happen? I can see it now: a conference room at SDI Technologies, a red faced manager pounding the table and demanding innovation. “How can we make this alarm clock more hip? What is it that all the kids are into these days? Social networking, right? How can we incorporate that?”

This, my friend, is where a brave soul should have spoken up. Not everything is social.

Understanding how the brain works is important in interaction design not only to be able to craft experiences that support the way people think, but also to avoid common biases in our own brains as we make design decisions. One bias that sneaks into design problems all the time is called the “availability heuristic”, or the tendency to judge how important or common something is based on how easy it is for us to think of an example. For example, if you were to ask me how the baby boomers react to technology, the first example that jumps to my mind is my mother who happens to be a complete technophile and Apple fangrrl. Because of the ease with which that example comes to mind, I am at risk of grossly overestimating technical interest and ability amongst the baby boomer population.

If you’re involved in the design of products, you run into this problem all the time. Stakeholders use their own most easily-retrieved examples to compare against, whether it’s the CEO who is influenced by the pundit he read that morning, or the product manager who knows that one guy who is just like your target market, or the designer who is really designing for himself -- the self being the extreme “available example.”

Availability biases leads to poor design decisions because they are based on single, potentially skewed, examples; they also result in thrash because each individual involved in the design has his or her own reference example, making consensus difficult.

Effective research is only the first step toward avoiding this problem. Properly conducted ethnographic research will provide an understanding of the needs, goals, and behaviors of your target market, but it won’t solve the problem of availability bias on its own. It is too easy for designers and stakeholders to be influenced by, say, the most recent interview conducted, or the most memorable one.

Fortunately, we have a well-honed tool to elegantly overcome this problem: the persona. A well-crafted, research-based persona is an archetype that smooths out the idiosyncrasies of real individual people while retaining the patterns of needs and behaviors in the target market. At the same time, a persona retains enough human detail to feel like a real person. With practice and dedication, the persona becomes the first example that comes to mind. You still suffer from availability bias, but the bias is in favor of reality.

Incidentally, I got to thinking about the availability bias when Chris Noessel pointed me to this video on YouTube. Be forewarned: the tune is catchy and likely to cause a nasty case of earworm . Bradley Wray, FTW.

What tools do you use to overcome cognitive biases in your work?

There comes a time in any parent’s life when she has the face the inevitable: Her child’s first cell phone. That time has come at last for me, and I confess I have been dreading it. What if she buys 50 ring tones? What if she calls China? What if she sends a prank photo to a friend and ends up going to jail and having to register as a sex offender for life? (That’s right, I’m a parent: I can go from “my kid might overspend my money” to “my kid might go to jail” in ten seconds flat.)

It was with utter delight, therefore, that I stumbled across kajeet, a cell phone service for ‘tweens and their parents. What sets kajeet apart is not their phones (they don’t make any), or their network (they’re essentially a Sprint reseller), but the service. With kajeet, parents can fine-tune what their kids can and can’t do, and who pays for what. You can set up separate wallets for the parents and the kid, such that the parents can pay for phone calls to Mom and Dad, but the kid has to pay for calls to friends or goodies like ringtones and wallpaper. You can set up times of day for certain activities, like only emergency phone calls during school hours. You can even track the location of your kid’s phone using its built-in GPS and online tracking tools.

When I discovered kajeet, I was in parental heaven. The service was so exquisitely tuned to my needs that I started to get professionally curious. What was the process that had led to this product?

The kajeet origin story goes something like this: Three dads saw a need, and created a company. Now, that’s a great start, but there had to be more to that story. They must have done their homework. So to learn more I spoke with kajeet’s SVP of Corporate and Business Development, Carol Politi.

Figuring out the right way to capture information during user and stakeholder interviews can be tricky. I like to capture as much information as possible because I’m never sure what will turn out to be important later on. Audio or video might seem to be ideal; however, recording makes subjects nervous, lessening the value of the interview. Besides, going back through the audio or video is extremely time consuming and therefore usually cost-prohibitive.

I touch-type very well, and so I have the uncanny ability to type an almost verbatim transcript of an interview while simultaneously keeping eye contact and participating in the conversation. This can come in handy during some kinds of meetings, such as internal meetings or during a kickoff with a client, when everyone involved understands and is invested in the process and I, as the naïve consultant, can be forgiven for wanting to capture every word.

This approach is much less successful in the context of a user interview, however. Not only is it kind of creepy, but the presence of a computer acts as a barrier to communication. It’s noisy, and the screen acts as an actual physical barrier between interviewer and interview subject. Furthermore, a computer is a complex, interactive device, so looking at the screen can be distracting for both interviewer and interviewee. Since we like to err on the side of a quality interview over perfect documentation, for a long time this has meant using a paper notebook for user interviews.

Enter the tablet PC.

Wanna Bet is a new show on ABC wherein celebrities bet on whether “ordinary” people can accomplish extraordinary things. Whichever celebrity has the most money at the end of the program gets to donate it to the charity of his or her choice. The way it works is that the show introduces the ordinary person, describes the (usually very odd) action this person is going to attempt, and the celebrities write down their prediction and bet amount. The attempt is made, the person succeeds or fails, and then the celebrities reveal their bets to much fanfare.

So far so good, right? The trouble is that there is some kind of disconnect in the betting process. On the first episode George Takei (better known as Sulu from Star Trek) excitedly revealed that he had guessed correctly and had bet $20,000. The show’s hosts, however, informed him he had only bet $2,000. For anyone not employed as a designer of interactive systems, it looked like George Takei was having a senior moment. It was embarrassing. The other celebrities on the show spent the rest of the episode pretending to have flubbed their bets to make up for it.

So where’s the failure here? George Takei is getting on in years; maybe he’s just not very comfortable with technology. Leaving off a zero is an easy mistake, right? Maybe, except that in the very next episode of the show, the same thing happened to comedian Melissa Peterman who thought she bet $5,000 but “really” bet $6,000. She’s only 37 and sharp as a whip. The show is now two for two, and I would argue there is a failure in the system.