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?

I have to admit that I’ve been steering clear of talking about “design thinking” for a while now. A couple years back, when I first heard about what sounded like an exciting new angle on design strategy, I eagerly scoured the web to figure out what it was all about. At Cooper, we’ve always concerned ourselves with challenges beyond skin-deep ornamentation, and we particularly relish working for clients who value the insights that we can bring to their strategic business decisions. I’m interested in anything that gives us leverage to help businesses get beyond the assumptions that stand in the way of truly serving human needs.

So when I set off to learn more, I was a bit disappointed to discover that all the information I could find about “design thinking” appeared to prominently feature the Keeley triangle, some business success stories and not a lot more. (For those that aren’t familiar, Larry Keeley, an OG innovation strategist, devised the triangle as a way of expressing how successful businesses are balanced in the concerns about the desirability, technical feasibility and financial viability of their products.)

The Keeley Triangle. The d-school site appears to have been refreshed in the interim, but if I remember correctly, at one point, the home page featured a marker sketch of this diagram with the words “this is design thinking.”

To be clear, I have no argument with the Keeley triangle. It was part of the foundation of Alan’s arguments in The Inmates are Running the Asylum (Alan Cooper’s 1999 book about the challenges of creating great digital products), and throughout the years I’ve found it to be an incredibly useful device in explaining how design fits with business and technology concerns.

But I guess I feel like defining design thinking by the Keeley triangle alone is like explaining how to fly by stating the laws of physics. In a 1998 HBR article, one of the first articulations of design thinking, Tim Brown defined design thinking as “a discipline that uses the designer’s sensibility and methods to match people’s needs with what is technologically feasible and what a viable business strategy can convert into customer value and market opportunity.” I have very little to disagree with in this, yet I don’t find it particularly useful or interesting. And it really begs at least one big question—what part of “the designer’s sensibility”? The obsession over details? The ability to create incredibly disorganized Photoshop (or Fireworks) files? The propensity to wear black?

All this said, I certainly see promise in the vision and enormously appreciate the work that Brown and IDEO have done to popularize the idea that human-centered design methods are fantastic tools for improving all kinds of things—not just product skins and interfaces, and that businesses can get vastly more value when they ask designers to participate in the product (or service) conception process, rather than to just pretty-up an already-formed idea. So I was really excited when I finally got around to reading Roger Martin’s The Design of Business and discovered a conceptual model that has really helped me understand what part of the designer’s skillset is really useful for this big picture thinking.

Martin refers to this conceptual model as “the knowledge funnel.” The funnel starts with a mystery—for example, how to feed the newly emergent car-centric middle class of 1950s Southern California. Businesses then can create value by moving along the tunnel first to a heuristic, or simple idea about how to solve the mystery—a quick service hamburger stand; then to an algorithm, or the specific operational rules about how to achieve the heuristic—where the hamburger stands should be located, how they should be designed, what the menu should be, how to prepare every item on the menu, and how customers should be served.

Among other things, what emerges in Martin’s model of design thinking is that this “designer’s sensibility” that Brown speaks of is the ability to use an understanding of customers’ needs (as well as technology and business factors) to move inwards and outwards in this funnel by iterating through many different heuristics and algorithms to ultimately imagine and then validate a way of solving this mystery. Intrinsic to this ability is abductive reasoning— making logical leaps to imagine what might be true in the future.

These ideas really resonate with me, but I struggle with the notion that abductive reasoning abilities are unique to designers. Martin is dean at the Rotman School of Management at the University of Toronto, and his audience is largely business people. I understand why he wants to differentiate these sensibilities from the largely analytical skills that dominate modern business education. But when I first read and thought about the idea that abductive reasoning is “design thinking”, I had two reactions: first, this is what I’d thought business people were supposed to be doing all along; and second, I know plenty of designers who aren’t at all interested in or good at abductive reasoning beyond their medium of, for example, interaction design, visual interface design or industrial design.

Ultimately, I have grave concerns if imagining a better future becomes solely the province of designers or design thinkers, a world of business and political leaders will be absolved of their core responsibility—making things better. (Not that I’m suggesting either Brown or Martin propose this; in fact, they both very focused on how non-designers can learn to think like designers.) I also worry that the term “design” will lose relevance for all the other meanings we rely upon it to convey. As Michael Beirut recently put it, “Don't say design, say innovation, and when innovation doesn't work, make sure you saved some of that design stuff, because you're going to need it.”

Given the big challenges we face in terms of the economy, environment and society, I think it’s a great idea that everyone learns more about creatively engaging with mysteries through abductive reasoning. Still,there must be a better term than “design thinking” to describe it. Any ideas?

Here’s a quick tip for you as you conduct your goal-directed interviews with users and potential users: Leave a four-second pause after your interviewee pauses their response, allowing them to add more information or additional detail.

This is hard to do. In ordinary conversation, people will often step in and fill these silences. Especially with a stranger, we don’t want to leave the conversation “hanging,” preferring instead to offer up some response or reflection on what the other has said.

But an interview is not a cocktail conversation. The interviewer is trying to get as complete a picture as he or she can of the user’s thoughts. To help do this, we want to give them that room to think about what they’ve just said and append as necessary.

Last week some designers from Google came to our studio for a discussion about the  practice of interaction design. We each shared a bit about our team structures and processes, and talked about some of the unique challenges that we face as a consultancy vs an in-house design team. But some of the most interesting discussions emerged when we focused on the areas of overlap - the basic bread and butter of interaction design. One of the most provocative questions posed by the Googlers was simply: “Where do ideas come from?”

We spend a lot of time thinking and talking about how we do things around here, but if we’re honest, this is the “then a miracle occurs” step in our design process.

This is where the rubber meets the road for every designer: you’ve done your research, synthesis, and analysis to clearly articulate the problem you’re trying to solve, and now it’s time to produce that winning design solution. You get up, grab a marker, and hope inspiration strikes somewhere along those five small steps to the whiteboard. As seasoned designers, it’s not something we think much about anymore - it just happens (unless it doesn’t). But as mentors, it’s important not to yada yada yada the best part (though we DID mention the lobster bisque).

So this week, we’ve spent a little time looking inward to try to develop a deeper understanding of where design ideas come from. Here’s what we found:

Research matters

Cooper designers conduct our own user research, and many feel that this provides indispensible fuel for design ideas. Experiencing real people in their actual environments fuels our senses of empathy and intuition that helps to guide us towards the ideas that make people happy, successful (and even better looking). Plus, the research phase affords us the opportunity to be fully immersed in the users and the domain for a few weeks at the start of the project, which in addition to providing rich data and empathy, also gives our brains boot-up time to start noodling on the problem and explore possible solutions in the background. Many of our designers confessed that they often doodle during interviews, sketching design ideas when inspiration strikes without the pressure of being expected to produce a solution. At the end of the research and analysis phase when patterns, goals, and requirements have been formally defined, designers can flip back through these quick sketches and easily pick out the good ideas from the bad and begin to improve upon them based on their deeper understanding of the users and the problems that must be solved.

Sometimes, words are worth 1,000 pictures

The first step in our design ideation process comes before any “official” sketching is done: we describe the users’ ideal experience in words. The scenarios we develop at this stage are forward-looking and technology-agnostic, focusing on the personas and how they think, feel and behave rather than on specific interface elements or technical implementations. We also identify experience keywords that describe the emotional response that users should have to the product. Not having to answer the “how” frees us up to think big, imagining the best-case scenario for how the product supports each persona in achieving his or her goals. Then, when it comes time to actually start sketching and exploring interaction, form and visual languages, we’re already united around a clear vision for the kind of experience that would truly delight our users, helping us to focus on design solutions and visual styles that most fully embody that vision.

Just do it

Fear of the blank page can be daunting for all of us. Sometimes, just pushing past that fear and starting to sketch can get the juices flowing. Our designers make sure to have a tablet, sketchpad, or whiteboard easily accessible at all times, and we don’t wait until we have a fully formed thought or idea to use them. We may look like we have a brilliant idea in our heads as we approach the whiteboard, but often those few short steps aren’t where the thinking actually happens - the ideas start to come only after we draw the first few rectangles. There’s something special about the process of sketching - even jotting down some really bad ideas helps us learn about the tensions on the problem and gets us closer to a workable solution. (See Bill Buxton's Sketching User Experiences for a fantastic exploration of the idea that the act of sketching is integral to ideation and design problem solving.)

A few months ago, Luke Hohmann visited Cooper to teach a special session of his Innovation Games class. Alan Cooper, Steve Calde, Tim McCoy, Jeff Patton and I and spent two days with Luke learning about the games and practicing how to apply them in different situations. Since the class, I’ve often found myself reflecting on what I learned. I’d like to share with you how I’ve adapted some of the techniques in my User Experience consulting practice:

• I look for opportunities to make all my meetings more engaging and participatory. A collaborative process generates a different kind of results than a meeting run by a single facilitator. When people work together to create an artifact (as you do in “Spider Web,” “Start Your Day”, and several other games) they are more engaged in the conversation and it’s easier to get participation from the entire group. You also have a useful record of what you talked about for future reference. My meeting room “kit” now contains large newsprint pads, sticky notes and thick black markers so we can jump into an Innovation Game at any time it becomes relevant.
• At our ChiFoo workshop, Jeff Patton and I used a variation of “Speedboat” to guide a group discussion about blending Agile and User Experience (UX) techniques. We asked people to tell us what “anchors drag them down” and what “winds support them.” You can see a picture of the results on flickr. We budgeted about 45 minutes for the exercise, and people wanted to keep going well into lunch. The process of sharing our thoughts visually and verbally created a sense of community and shared direction in the room that surprised and pleased me.
  
• I found the Innovation Game role of “observer” and the process of recording one observation per index card useful in another context. While teaching interviewing skills at Atomic Object. We grouped the interviewers in pairs (main interviewer, backup interviewer) and had the rest of the people sit behind the interview subject and act as observers, taking notes on index cards, one observation per card. After the interview, we did a group debrief of the observations and found that we had excellent coverage of what we’d learned. Even though none of the student interviewers caught all the details, as a group they covered everything. Another benefit; we quickly reached a shared understanding of the key insights from the interviews. I can imagine this would be equally as useful during usability testing, either behind glass or with silent observers.
• And, for my personal and professional planning, I’ve found “Remember the Future” valuable to help me clearly articulate my long term objectives, and the specific measurable steps I need to follow to accomplish them.

Thanks again, Luke, for a memorable class, and some useful additions to my UX toolkit! For more information about the Innovation Games event, please see the Cooper Journal post about the event, and the full set of photos on flickr.

At Cooper, we spend a considerable amount of time understanding the experience requirements of the products that we're designing. Our client stakeholders often request a design that our users will react to as feeling simple, intuitive, innovative, and so on. In many cases the products we're asked to design must display a sense of trust.

Why is trust good?

Trust can play an important role in the successful adoption of a product. For example, in data backup and management, if the software does not give a user, such as a backup administrator, the confidence that his data is safe and securely managed then he's unlikely to want to use, or switch to, this software. Especially, when considering that his job is on the line in cases where servers go down and critical data could be lost. Likewise, for online banking websites, customers want to know that their personal information is securely housed and not at risk of being stolen.

How do we make software that appears trustworthy?

All aspects of design and technology contribute to improving a product's trustworthiness whether it be through the visual presentation, the tone of content, the accurate and clear communication of data, or the brand awareness of a company or product. Ultimately, when considering visual design it's our task to create a visual language that appears professional, high in quality, and appropriate to the user's expectations. For content and data, it should be clear, concise, error-free and accurate. Finally, repeated interactions with brands can build trust over time if consistent, dependable, and memorable.

When trust can be bad

Right now you might be wondering, "Trust can be bad?" You've got a point. No client has ever asked me to design a software application, website, or device that's intended to be untrustworthy. But, our continuing reliance on complex information systems could lead us down the path of blindly relying on data, even when we don't fully understand that data. Trust must always be cultivated in users, but too much trust, like too much of anything, can be a bad thing.

Consider the financial meltdown. I don't pretend to fully understand what has happened, who's to blame, and how it could have been prevented. What seems clear is that many of those responsible were only looking out for themselves. Michael Lewis, author of Liar's Poker, discusses this issue that began decades ago in "The End of Wall Street's Boom,"

The shareholders who financed the risks had no real understanding of what the risk takers were doing, and as the risk-taking grew ever more complex, their understanding diminished. The moment Salomon Brothers demonstrated the potential gains to be had by the investment bank as public corporation, the psychological foundations of Wall Street shifted from trust to blind faith.

In assuming that a system is correct, users assume that what they are doing is correct, ethical and in the best interests of everyone. In doing so, they (perhaps unconsciously) absolve themselves of accountability. It is incumbent on the system to ensure that users are fully aware of their accountability, so the system must leave no doubt about that fact.

In Jerome Groopman's How Doctors Think, he discusses a surgical protocol for cardiac tamponade, a condition in which "fluid has accumulated around the heart and was compressing it." In the story, Dr. James Lock retells of how a standard procedure, where a needle is used to remove the fluid, had been nearly fatal for a young patient,

"Why do you stick the needle under the xiphoid?" Lock asked. I paused. "Because that was how my teachers taught me in my training."

"And why do you think your teachers taught you the way they did?" Lock asked.

"Because that's how they were taught."

By not fully understanding the procedure or its history, the medical staff ceased to improve the procedure and more critically put the patient at great risk.

When viewing complex systems, users should not only understand data but, when necessary, ascertain its origin. Consider the frequency with which patients receive the wrong medication in healthcare environments. Relying too much on a system could give a nurse the false sense that she has administered the correct medication when in actual fact, a pharmacist prescribed the wrong dosage in her computer.

So what's the solution?

The solution is to dive deep into the research problem and fully understand the trust need from your stakeholders and users. Regarding the stated examples, users should be made to feel like the software they're using is reliable and dependable. But most of all, users should understand the system, be accountable for managing it, and be empowered to change it.

At Cooper, we’ve historically advocated a clear and explicit separation of interaction design and software development efforts. Underlying this position is the assertion that the job of interaction designers is to serve as user advocates. We approach the design problem not by asking “What can we deliver?” but “What do people desire?”

We’re guarding against the urge to focus on the development and delivery of software, hardware, and services before we understand its value to the humans using the system. By no means does that suggest our designs should ignore business and technological factors, only that our designs should be influenced primarily by our the motivations of the users represented by our personas.

The design must meet the needs of its users, and it follows that the product’s creators (designers, business folks, developers, etc.) deliver a product that meets the expectations of the design.

But how to design so that those expectations can be met? It’s a delicate balance. Ideally, there is a healthy interplay of possibilities and limits between the business factors, technology issues, and design motivations. Each group shares the goal of delivering the best product possible with the time, budget, and expertise available.

Here are some ways to keep a user-centered focus without losing sight of the factors that influence development:

Understand the business situation

Get a clear sense of the breadth of the design mandate: Is management pulling out all the stops to create a category-killer, or have they set a firm cap on the time and resources available to the project?

Know your medium (but not too well)

Understand enough about the technologies underlying the product so you can leverage things it does well without falling into the trap of designing to technical capabilities rather than user needs.

Listen to developers’ concerns and ideas

Recognize that every one of your design decisions impacts the work developers will need to do to implement and support them. Solicit their input on the design’s feasibility and seek their advice on ways to make the design more achievable. Your concern should not be that you’re signing developers up for hard work (after all, solving hard problems is what being a developer is all about)—it’s signing them up for unnecessary hard work.

Don’t concede your personas’ needs to business or technological limitations

If you’ve done your homework, you know what the product needs to do (and not do) to satisfy its users. If technical or business issues are in conflict with a persona’s needs, speak up. Demonstrate the value of your design to business and technology stakeholders to help them see the merits of accommodating the design intention.

Pick your battles

Be comfortable with letting some technology and business considerations trump design ideals. There are situations where a less-perfect standard implementation of one feature means more time to develop a custom feature that truly delights your users. Too many of these is death by a thousand cuts, but everything doesn’t have to be ideal for the things that really matter to be fantastic. The reconciliation of technology, business, and user-centered design is ultimately a business decision. The most fabulous design will never see the light of day if it doesn’t meet business objectives or isn’t technically feasible. By understanding the business and technical landscape, working across disciplines, advocating for your users’ needs, and knowing when to compromise, you can produce successful designs—successful because they meet the needs of users and the needs of developers and business stakeholders.

Here at Cooper, we’re pretty well known for our holistic and methodical approach to design, but don’t let that fool you - when the situation calls for it, we’re more than happy to get all “mavericky” with our clients and provide some good old fashioned ad-hoc consulting.

For example, I was recently asked to provide management support to a client who is in the midst of implementing a Cooper re-design of their robust web application. As I immersed myself in the project, I was quickly reminded of my previous life as a project manager and business analyst at a large software company, and how easy it is to fall into the many efficiency traps that often permeate large-scale development projects.

Over the course of my recent engagement, I identified several critical success factors for effective project teams, and some specific things that both project managers and team members can do to ensure project success.

A good persona (or user archetype) is based on research and is specific, memorable and includes actionable information. Often, I’ve seen people give them descriptive names that leverage often-heard phrases, like “Nora the newbie” or “Joe Helpdesk.”

The term “Joe Six Pack” has frequently been used in the 2008 presidential campaign. This is a good example of how using “soundbite” names for your persona work against your need for a specific design target that keeps everyone on the team focused on the same idea.

In NPR’s Morning Edition program “York Voters Untangle Rhetoric On Race” Renee Montagne, Steve Inskeep, Michele Norris asked 15 voters from York Pennsylvania what they thought of when they heard the term “Joe Six Pack.” The got a variety of responses: