InVision presents

Design Thinking Handbook


by Eli Woolery

What is design thinking? More than a methodology or framework, design thinking combines the problem-solving roots of design with deep empathy for the user. The design thinking-based framework popularized by the Stanford d.school can help your team take on the thorniest challenges with insightful solutions.

In this guide, you’ll learn how to put design thinking into practice in your organization.


Go to Chapter
Why we need design thinking
Tackle complex challenges

What is design thinking? More than a methodology or framework, design thinking combines the problem-solving roots of design with deep empathy for the user. The design thinking-based framework popularized by the Stanford d.school can help your team take on the thorniest challenges with insightful solutions.

In this guide, you’ll learn how to put design thinking into practice in your organization.

Go to Chapter
Go to Chapter
Empathize
The heart of design

Designers work to solve others’ problems but the most insightful and innovative design work begins with empathy. Slip on your users’ shoes and seek to gain understanding with an open mind. You’ll be surprised what deep needs and insights you can uncover.

Go to Chapter
Go to Chapter
Define
Reframe the problem

A single image of the earth from the moon shifted the course of environmental history. A new point of view on a design problem can shift your perspective just as much. Learning to reframe your point of view based on insights from your users can be a powerful design tool.

Go to Chapter
Go to Chapter
Ideate
Beyond basic brainstorms

Ideation early in the design process helps teams get aligned and find potential solutions to investigate. While most teams use some form of ideation, design thinking can lend new structure and spark the brainstorming process.

Go to Chapter
Go to Chapter
Prototype
Get smarter, faster

The smartest design teams build prototypes throughout the design process. Rather than discover issues after the expense and time spent on building a complete product, challenge assumptions and solve disagreements through iterative prototyping.

Go to Chapter
Go to Chapter
Test
Early and often

Prototyping forms a key step in solid product design, but the best design teams go a step further and test their products with real users. Observing how your end user approaches your product gives you the most important feedback of all.

Go to Chapter
01

Why we need design thinking

Tackle complex challenges

In 1958, 4 months after Sputnik launched and President Eisenhower created NASA, a Stanford engineering professor named John Arnold proposed that design engineering should be human-centered.

This was a strange thing for Arnold to introduce. This was an era in which engineers were largely focused on twin Cold War driven goals: the space race and the optimization of the hydrogen bomb.

Inspired by Arnold’s work, engineering professor Bob McKim, with the help of art professor Matt Kahn, created an engineering program called Product Design. Within this program, McKim and others helped create a design thinking process that became the foundation for Stanford’s d.school, as well as the guiding framework for design-driven companies like IDEO.

Just as the space race resulted in the invention of Velcro and satellite communications, design thinking plays a large role in how we interact with computers (the mouse and notebook), how we deliver our healthcare, and how we do our banking now and in the future.

Why has design thinking been embraced not only by forward-thinking innovators like IDEO but large enterprises like IBM? For one, it brings everyone into the process, not just designers; using the design process helps companies solve wicked problems with clear eyes.

Design thinking also helps scale the design process through large organizations.  Business leaders who use the shared vocabulary and toolset of design thinking can confidently create better, human-centered user experiences and disruptive products.

Finally, design thinking helps to instill a bias towards action, balanced with a user-centered perspective that guides the team towards the right outcome.

The design thinking process is not necessarily linear, nor is there one canonical way to approach it; it is an iterative system with many variations. However, Stanford’s d.school teaches a framework that can help jump-start the process for almost any problem:

We’ll walk you through the 5 steps of this design thinking framework, which will provide a toolkit for design challenges large and small in your organization.

The core of the design thinking approach is a focus on empathy, or using a beginner’s mindset and immersing yourself in the user’s experience to uncover deep needs and insights.

Defining the problem with a point of view (POV) is a key part of the process: who is your user (with as many specific details as possible); what is their deep, unmet need; why is this insightful (what insights did you glean from your empathetic needfinding process?). Often, reframing the problem using a unique POV will lead to more innovative solution spaces.

The design thinking process goes through a cycle of generative flaring and selective focusing. In the definition phase, we narrowed down to a specific Point of View; now, in the ideation phase, we flare out and generate as many ideas as possible.

For many designers, prototyping is where the fun begins. Sometimes the key to good empathy is sharing or co-creating a prototype with your users and getting feedback. Prototyping helps us learn, solve disagreements, and test hypotheses quickly and with minimal repercussions.

By testing our prototypes with real users and getting feedback, we can refine our POV, learn more about our users, and make the next iteration of the product that much better. As they say at Stanford’s d.school: “Prototype as if you know you’re right, but test as if you know you’re wrong.”

These steps should be considered a way to get started with design thinking. Over time, you will adapt them to your working style and make them your own. With this flexible toolkit, you’ll be prepared to tackle any project, from a new app to—perhaps—new NASA moonshots.

With thanks to Bill Burnett, executive director of the Design Program at Stanford, for giving the lecture that inspired this introduction.

02

Empathize

The heart of design

Listen to Chapter

Imagine that you live in a remote village in Nepal. It’s winter and freezing sleet pounds the nearby roads, making them nearly impassable. You’ve just had your first baby, a little girl, and she’s premature and severely underweight. The room that you’re in, while warm to you, feels like an ice-bath to the baby. Without help soon, she will almost certainly die from hypothermia. What do you do?

Worldwide, about 15 million premature babies are born every year and the most common preventable cause of infant mortality is hypothermia. As designers, we solve the problems of others, and solving the problem of infant mortality due to hypothermia seems like an extremely worthy design challenge. This is exactly what a team from Stanford’s d.school set out to accomplish as a project for the class Design for Extreme Affordability (often known just as “Extreme”).

The team ended up with a novel, innovative solution—but they never would’ve arrived there if they remained within the bubble of Stanford’s campus. They needed empathy to see the problem clearly from the perspective of hospital staff, doctors, and most importantly, parents of the child in danger.

Initially, the design team thought redesigning existing hospital incubators to be simpler and more cost effective would be the easiest solution. But when team member Linus Liang toured a hospital in Nepal, he noticed something strange—the incubators were sitting empty. After interviewing a doctor about this, he learned that many homes where these babies were born were 30 or more miles away on rough rural roads, and that the parents faced the fight for their babies’ lives at home, without much hope of making it to a hospital.

The Extreme team used this insight to inform their decisions about the product’s direction. Instead of a cheaper incubator (the initial concept, but likely ineffective given the evidence) they decided to design something to help babies at home: a portable incubator, much like a tiny, heated sleeping bag, which they named Embrace.

While prototyping the Embrace, the team interviewed many moms, healthcare workers, and shopkeepers who helped them iterate on solutions. By showing prototypes, they learned about critical barriers to adoption:

  • In a village in India, a mother explained they believe Western medicines are very powerful, so villagers often halve doses. The warmer on the Embrace had a temperature indicator, and this mother indicated that other mothers would only heat it halfway to the ideal temperature. This information led the team to iterate on the design, removing the temperature strip and changing the design to showcase an “OK” indicator.
  • The team also learned that in many communities, electricity is unavailable or unreliable. So they designed a version of the warmer that could be heated using hot water.

With these insights, the team was able to create a product that was easy to use correctly in the locations it was designed for. They formed a company based on this product, grew it to 90 people, and have helped over 3,000 babies.

By using empathy and focusing on the people who would use the product—in this team’s case, a literal journey that exposed them to the feelings and challenges of their users—the Embrace team came up with a product that saves lives.

Practicing empathy

Empathy is the foundation of the whole design thinking process. Using a beginner’s mindset and immersing yourself in the user’s experience is a great way to uncover deep needs and insights. It also ties directly to the Guess less principle of product design. In this Empathize section of our course, we’ll dive into a case study where empathy helped create an innovative product for Bank of America. We’ll then walk through some exercises you can employ to gain more empathy for, and insights from, your own users.

How can empathy help us design better products? To find out, try this exercise, adapted from the Wallet Project exercise taught at Stanford’s d.school. It should only take about 15 minutes. (Go ahead, we’ll wait for you.)

Case study: IDEO and Bank of America’s Keep the Change program

Let’s try a thought experiment. Put yourself in the state of mind of someone living paycheck to paycheck. For some of us who as designers spent time freelancing and waiting … and waiting … to get paid by clients, this might not be a hard thing to imagine.

What are some of your biggest fears? Getting your water or heat shut off because you can’t pay bills on time? Maybe things are bad enough that you worry you won’t make rent and could get evicted.

You probably don’t have time (or the means) to worry about setting up a savings plan. A 2013 study at Princeton showed that being in this state of mind actually impairs the brainpower needed to navigate other areas of life.

So how do you go about designing a banking product for someone stuck in this vicious cycle? In 2004, the design firm IDEO tackled exactly this challenge for Bank of America. Their target users were not restricted to people in this demographic, but the insights that lead to Bank of America’s innovative “Keep the Change” program came in part from extreme users.

Such users had unconventional ways of solving banking problems, which gave the IDEO team ideas for a banking service that would help address the needs of people having a difficult time achieving a sense of control over their finances.

IDEO was given the challenge by Bank of America to find novel ways to entice people to open accounts. The bank was hoping that IDEO’s human-centered, ethnographic-based approach to design would bring innovation to an industry that’s typically very conservative and reluctant to change.

To accomplish this, IDEO embedded themselves into the Bank of America team and conducted observations in several cities across America. They spoke to families and individuals, learning about spending and banking habits. As IDEO synthesized their observations, they began to notice some interesting patterns.

Often, mothers were in charge of the finances. This was during the early 2000s, before online banking and mobile devices had more or less replaced the idea of a balanced checkbook. Some moms had a practice of rounding up the number in their checkbooks; this made addition easier, but it also gave a small buffer in spending.

Armed with this insight and the knowledge that many of these families had difficulty saving what money they had, IDEO came up with a service idea. People could enroll in a savings account that would round up purchases made with debit cards. Then, the overage would be transferred to a savings account automatically. In addition, the bank would match the money transferred to savings to a certain dollar amount.

As you might imagine, this program became very popular—and not only with people who had trouble saving money. Ever since the program launched in September of 2005, more than 12.3 million customers have enrolled, saving a total of more than 2 billion dollars. Of all new customers, 60% enroll in the program.

When we interviewed Faith Tucker, the former Senior Vice President & Product Developer at Bank of America, she was clearly proud of the emotional impact this service had on people who found saving money difficult. The amount was largely inconsequential—it was more about the change in mental state and feeling of empowerment that these customers gained.

To a certain degree, it removed the feeling of shame that came along with being unable to save money, which was replaced with pride at taking more control over finances.

In the film DESIGN DISRUPTORS, Julia Zhou (VP Product Design, Facebook) and Mia Blume (Product Design Manager, Pinterest), talk about the importance of having empathy for your user.

Establishing empathy remotely: the camera study

Product teams need to move fast, and they’re often working on a strict timeline. It can be hard to convince stakeholders that user research—in the form of an ethnography—can be completed quickly and still have an impact.

However, there are some great techniques available to do exactly that. If you’re highly constrained on time and budget, try a Minimum Viable Ethnography, pioneered by user research expert Erika Hall of Mule Design.

If you have a little more time, try a user camera study. The advantage of this approach is that you get a semi-unfiltered view into the day-to-day environment of your users and you gain insights that may not be available via a phone or video interview.

Here’s a step-by-step guide for the study:

Empathy as the heart of design

Empathy is a journey into the feelings of others. Sometimes it’s a physical journey, like the one the Embrace team took to Nepal. Other times, it’s a virtual journey, where users share their screens with you or collect pictures of their environment in a camera study. Whatever your methods include, a good empathy study will give you new perspectives on the lives of your users—including the challenges they face, the things that keep them up at night, and the moments that delight them. Having this empathy can give you the insights you need to solve hard, worthwhile problems.

Without empathy, IDEO would not have been able to help Bank of America create a product that helped their financially strained customers feel empowered about saving money. Embrace wouldn’t have been able to create a product that’s saved the lives of thousands of premature babies. Empathy connects designers to the people who will use our products, empowering us to create products that ultimately meet real human needs.

As humans, we evolved to have a powerful sense of empathy. The primatologist Frans de Waal writes that the power of empathy to help people collaborate is one of the reasons we became so successful as a species. Wield this power as a designer and you’ll have the foundation, and the heart, to create great products for humans everywhere.

04

Ideate

Beyond basic brainstorms

Listen to Chapter

The Apollo 13 Mission Control team faced a huge number of seemingly insurmountable obstacles after an oxygen tank exploded on board the 1970 mission to the moon. They needed to find a new route that would get the astronauts back to Earth quickly with a limited supply of life-supporting fuel and power.

The most pressing problem was a buildup of carbon dioxide in the ship. Without a replacement scrubber, stored out of reach in a different module in the craft, the crew would soon asphyxiate from their own exhalations.

In the 1995 movie version of this dramatic event, Apollo 13, Flight Director Gene Kranz (played by Ed Harris) assembles the top engineers and scientists in a room for a brainstorming session. He tells the group to forget the flight plan, and that they would be “improvising a new mission.” Standing in front of a chalkboard, he quickly sketches the original route of the ship. Then, when one of the engineers suggests a new route, Kranz alters the original route to show a slingshot approach that would use the moon’s gravity to whip the astronauts back toward Earth.

In a later scene, a group of engineers tasked with devising a new filtration system dumps the same items aboard Apollo 13 onto a table. They proceed to prototype a fix that the crew can build from the objects at hand, ending up with a literal “duct-tape solution.”

In each case, the route to resolving the problems seemed relatively straightforward, if fraught with urgency: get a bunch of smart people in a room, and have them collectively come up with ideas until the best solution was found. We can assume that the film was faithful to what happened in the real life control room in Houston, but what conditions created such a successful environment for brainstorming?

The term “brainstorm” was popularized by the ad agency executive Alex Osborn in his 1953 book Applied Imagination (though he had outlined his method in a 1948 book, Your Creative Power). Osborn claimed that by organizing a group to attack a creative problem “commando fashion, with each stormer attacking the same objective,” creative output could be doubled.

Osborn created 2 main rules for a successful brainstorm:

  1. Defer judgement
  2. Reach for quantity

Deferring judgement reduced social inhibitions in the group—no one would be stigmatized for shouting out a crazy idea. By reaching for quantity, participants would boost their overall creative output and increase the likelihood of coming up with innovative solutions.

As we discussed in Pencils before pixels, brainstorming in a group might not work as well for original ideas, as compared to individuals working independently.  However, brainstorming adds value to the creative process in ways that don’t just involve coming up with ideas.

Brainstorming isn’t about new ideas, really

It turns out that the power of brainstorming doesn’t really come from spontaneously generating new ideas. Rather, the real strength in brainstorming stems from the process’s ability to:

  • Quickly generate lots of ideas, to help get an overview of the conceptual landscape. These are not necessarily new ideas (or good ideas). They may have been brewing for a while as individuals considered the problem beforehand. These ideas can become the seeds for solutions, to be investigated with prototypes.
  • Gather a team into a physical space where everyone can share perspectives on the problem and become aware of the potential solution spaces as they are surfaced. Done well, it can energize a team (and done poorly, it can deflate one).
  • Get clients or stakeholders to buy into the design process, and also learn what is important to these decision makers.

Generating ideas, sharing perspectives, and gaining stakeholder buy-in are lofty goals. To achieve them via brainstorming requires careful planning. In the next few sections, we’ll cover how to properly set the stage for success.

Prepare for brainstorming success

Before we dive into suggestions for making your brainstorms more successful, a caveat—just like any other creative tool, there are a lot of ways to run a brainstorm, some of which might work better for certain types of problems. The only way you’ll learn which technique works best for you is to experiment with a few.

You’ll remember from our introduction that Alex Osborn sets 2 guidelines for a successful brainstorm:

  1. Defer judgement
  2. Reach for quantity

While these are fundamentally important, there are a few additional guidelines that will make your brainstorm more successful.

Before the brainstorm

A key part of the brainstorming process is the facilitator—someone who will lead the session, keep track of time, and set up the space for the group. This facilitator can also make sure that the group comes prepared with a mission framed by problem statements.

Set a mission

Your brainstorming session should have a clear goal. What problem(s) are you surfacing ideas for? What is the best method for coming up with this goal?

Recall that Stanford’s d.school design thinking framework (below) alternates between generative (flaring) and selective (focusing) phases. As you Empathize, you gather data and stories from your users, generating insights and flaring out.

As you begin to synthesize that information and come closer to Defining your point of view (POV), you become selective about the solution space you will pursue, and you focus.

In the current Ideate phase, you flare out again as you generate a multitude of ideas and select promising solutions for Prototyping. Doing this helps your team step beyond obvious solutions, harness the collective creativity of the team, and discover new and unexpected areas to explore.

How do you go about generating those ideas? The POV that you generated in the Define phase is a great platform to help start the process. Using your POV problem statement, come up with “How might we … ?” topics that are subsets of the entire problem. If your POV is well constructed, these topics should fall naturally out of it.

For example, let’s go back to Doug Dietz’s POV.

“We met scared families trying not to fall apart during the hospital visit. We were amazed to realize that they have to sedate 80% of the children between 3 and 8 years old, in order to have them be scanned. It would change the world if we could capitalize on the child’s amazing imagination to transform the radiology experience into a positive, memorable adventure.”

With that POV, you can pretty easily come up with problem statements like “How might we make the MRI scanner a more imaginative space?” or “How can we reduce anxiety before appointments by sparking children’s imaginations?” With these topics, you can then set up brainstorming sessions to surface a lot of ideas.

Set up the space

For a good brainstorm to happen, the energy in the room needs to be right. First, pick a space that has large whiteboards or room on a wall to set up poster-sized Easel Pads. The room should also be somewhat enclosed if there is a worry about bothering other teams (brainstorming can get boisterous)—but there are alternate techniques for a quiet brainstorm, which we’ll get to a little later.

Get into the right headspace

If you’re coming into a brainstorming session from individual work, it can be a little jarring to adopt a collaborative mindset—and hard to ramp up your energy level accordingly. The facilitator should spend a few minutes getting everyone acclimated. There are quick, improv-based techniques for this, like Sound Ball or Knife, Baby, and Angry Cat. You can also use the 30 Circles Exercise that we outline later in this article.

Limit the time

A brainstorm can quickly run out of steam if the facilitator doesn’t establish time limits and keep the conversation moving. Setting a time limit for each topic is a good idea (15–20 minutes works well, depending on how many topics you need to cover). You can also set a goal for the number of ideas per topic (e.g., 100 ideas in 20 minutes). Use a Time Timer so everyone has a visual indicator and benefits from adrenaline-powered sprints as the time begins to run short.

During the brainstorm

When the brainstorm kicks off, the moderator’s job is to keep the momentum going, stay on topic, and make sure all ideas are captured.

Always say yes

To keep the energy high and the ideas flowing, a good brainstorm shares a lot in common with the improv technique of “Yes, and … ” When an idea is put forth, participants should be encouraged to build on it, putting a positive spin on the contribution. Critical energy can be diverted into productive ideation in this way. For example, “Yes, I like that idea, and we could go even further by … ”

Stay on topic

In the heated environment of a brainstorm, it’s easy to get sidetracked and start diving down rabbit holes that have no relation to the problem statement at hand. It’s important for the facilitator to gently guide participants back to the current topic. Sometimes this is best done by noting adjacent topics and mentioning that the group can come back to it later or during a future session.

Be visual and headline

One way to run a brainstorm is to have the facilitator serve as scribe, logging all the ideas as they come. Another is to arm the group with sticky notes and sharpies, so that they can walk up to the board, verbally share an idea, and put a summary of the idea on the board.

Either way, it’s important to be visual. Encourage quick sketches— these will help to clarify and group ideas.

Also, ideas should be headlined as they are produced. A participant can say, “We could create a way for the user to leave feedback for us directly via a comment form,” which someone would then summarize as “Feedback comment form.”

Whatever method you choose, ideas should be shared one at a time. This allows the scribe to write them, or the participant to be heard as they post their idea to the board.

After the brainstorm

When the brainstorm is finished and there are a hundred ideas on the board, it’s easy enough to give high fives all around and walk away without really having accomplished much. Leave a little time after the brainstorm to review and capture the ideas that were shared.

Narrow down, but not too fast

If you’ve run a productive brainstorm, you’ll likely have a lot of different ideas on the board—some funny, some weird, perhaps some verging on insane. It can be tempting to cut any idea that isn’t feasible, but by doing so you may be tripping up the ideation process. Sometimes good ideas can come from a place that initially seemed silly.

Instead, give the participants a way to select ideas across multiple criteria. One way to do this is to use color-coded sticky dots or pieces of colored Post-its. Each color can signify a person’s top choices in each category, such as the lowest hanging fruit, most delightful, or the long shot.

Capture and move to prototyping

Once you’ve selected ideas in each category, carry them into prototyping, ensuring that you don’t walk away from the session with just the safest choice. Use a phone to photograph the whole board, and then extract the top ideas in a document which can be used to kick off the prototyping process (Google Docs is great for this).

Prototyping is a flaring part of the design thinking process. Even if a selected idea is so crazy it doesn’t seem worthy of a test, figure out what’s attractive in that solution, and use that to inspire a prototype. The goal is to come into the Prototype phase with multiple solutions to build and then test.

Remember that brainstorming is just 1 step in the process of coming up with a solution. In all likelihood, you won’t come out of a brainstorming session armed with the exact idea that you’ll bring to your users. But you will hopefully compile an overview of the conceptual landscape, gain a shared perspective on the problem with your team, or get key stakeholders to buy into the design process. All of these things will help seed the minds of your team.

Here are some more insights from Peter Macdonald on how brainstorming at IDEO has evolved over the years:

“Our favored approach today is to start with everyone working heads-down for 5 minutes to begin brainstorming around each key question. Then we have people share those ideas with the group and continue with a classic brainstorm process.

“It ensures a diversity of ideas and prevents the first ideas from setting the direction of the entire brainstorm—it also helps the group build strong momentum.

“At IDEO we aren’t dogmatic about creative techniques. You should use whatever process or format works for you. Sometimes different approaches work better for different problems.

“Our industrial designers often hold “design-storms” where everyone is sketching form or design ideas at the same time and sharing back as they finish each sketch. Instead of Post-its, they use 8.5” x 11” sheets or half sheets (8.5″ x 5.5″) and a variety of pens, pencils, and markers so they can add more details.

“Our toy invention group does “tinker-time” where they build in 3D together. Every team is encouraged to experiment and create and evolve new techniques.”

Alternatives to brainstorming

You may have noticed that the “classic” brainstorming method we described requires a fair amount of coordination, and ultimately practice, to run well. It also relies, as Peter Macdonald from IDEO notes, on a “culture of trust.”

But what if you don’t have the resources to pull this off, or are working with a new team or client and don’t have the time to build this culture from repeated brainstorming sessions? There are ways to get around this.

Sketching

In Sprint, Jake Knapp outlines a method for sketching and discussing ideas in a group (listen to Daniel Burka talk about this technique in the clip below). The GV team explicitly does not call this brainstorming (which they have some strong opinions about)—but the point is to find a process that functions within your workflow and organization.

Performing ideation with individual sketches—which are reviewed by the group silently, voted on, and not discussed until the end of the session—is a way to address situations where a strong collaborative culture may not yet be established.

Mindmapping

What if you’re on your own, with no one to run a brainstorming session with? In that case, mindmaps are your friend! The concept is simple, but mindmaps can be a powerful way to move from conventional ideas to unpredictable, innovative ones. The following version of this technique is adapted from David and Tom Kelley’s Creative Confidence. You can start with a problem statement like, “A better birthday party for a 1-year-old.”

Write your topic or problem statement in the middle of a piece of paper, and circle it. Make connections to that central node, and write them down. In this example, you might write down “cupcakes to devour” and “make it for the adults” as 2 directions to investigate.

Each connection should spur new ideas (“make it for the adults” could inspire “baby birthday adult beverages,” for example). If an idea becomes a new cluster, circle it to indicate that it is a new node in the map. Be visual where possible; simple sketches can inspire new directions. You’re done when the page is full, but you can always continue the mindmap by reframing the topic and starting a new map.

Mindmapping will help you get the early, obvious ideas out of your head. It can help you look for patterns, reveal the structure of a subject, and—once you have an opportunity to move beyond a solo mission—communicate the ideas and process to others.

Related: Ideate with Craft Freehand

Sowing the seeds of innovation

In 1869, the Russian chemist Dmitry Mendeleev fell asleep at his desk. He was in the midst of a 3-day working sprint, during which he was trying to arrange the elements in a logical manner. He was stuck.

Asleep, Mendeleev dreamt of a solution. “I saw … a table where all the elements fell into place as required. Awakening, I immediately wrote it down on a piece of paper.”

Dreaming helps our brains organize and consolidate the information that we are exposed to throughout our working day. Much like taking a shower or a long walk, it’s a time during which solutions to the problem at hand come to mind.

But these solutions only appear after the hard work of exposing your mind to a lot of diverse ideas. Ideating, whether through brainstorming, sketching, or mind mapping, can help you and your team seed this field of ideas—which you can carry into the prototyping process.

05

Prototype

Get smarter, faster

Listen to Chapter

One day in the early 1980s, the computer scientist Danny Hillis was having lunch with the Nobel-prize winning physicist Richard Feynman. Hillis mentioned that he was going to create a startup, with the goal of building a parallel computer that had a million processors. In typical Feynman fashion, the physicist responded that it was “positively the dopiest idea I ever heard.” But he was intrigued, and by the end of lunch had agreed to spend the summer working at the company.

During the first few months on the job, Feynman worked on the router circuits. These would allow the processors to communicate and were far more complex than the processors themselves. The routers—tasked with ferrying information from point to point—had to find a free path through a 20-dimensional traffic jam between the processors, or hold the message in a buffer until the path was clear. A critical question was whether the design had allowed for enough buffering to operate efficiently.

Feynman began studying the circuit diagrams and was willing to listen to explanations of why things worked. But he far preferred to use pencil and paper to simulate the action of each circuit and figure out things for himself.

Feynman’s work on the routers helped the team discover the potential of the computer—which they had dubbed the Connection Machine—for complex numerical computing and physical simulation. This was useful for modeling things like the behavior of fluids and the simulation of artificial life, programs which other computers of that era were not designed to perform efficiently.

The team had initially assumed that their machine would not be capable of these types of number-crunching calculations, but Feynman argued that the assumption was worth challenging.

To settle the argument and find out how well these computations would work in practice, Feynman had to create a prototype program to run. He was only really familiar with the programming language Basic, so he made up his own version of Basic that would run on the parallel processors. He would write the program, and then simulate it by hand to estimate how fast the Connection Machine could run it.

Feynman treated these challenges like a game, starting with very basic questions like, “What is the simplest example?” He would then continue to ask questions until he had boiled the problem down to something he thought he could solve—which he would attack with pencil on paper.

Feynman’s contributions eventually helped the company become a leader in parallel computing, generating tens of millions of dollars in revenue.

When Hillis reminisced about his work with Feynman, he realized that in almost everything they collaborated on, they were amateurs. From neural networks to parallel computing, they didn’t know what they were doing—but these things were so new that no one else did either.

By distilling complex problems down into simple ones and using prototypes to answer critical questions, they were able to drive innovation that even they themselves didn’t know was possible.

Prototype like a physicist

Although Richard Feynman was a physicist and not a product designer, he intuitively understood the power of prototyping. Prototyping helps us learn, solve disagreements, and test ideas quickly and cheaply. Feynman began the design process with sketches, which helped him understand the problem and identify critical questions that the prototype needed to answer.

Building a prototype gave Feynman a chance to settle the argument he made for the capability of the Connection Machine to solve complex calculations. Without it, he and his colleagues might have sat in front of a chalkboard, endlessly throwing equations at each other and citing research papers.

Finally, instead of taking the time to teach himself a more complex language, he used familiar tools to quickly build a program which simulated the efficiency of the machine. If he had failed at this point, it only would have cost days or weeks instead of months.

Framed in this way, it’s clear why design-driven companies prototype early and often, throughout the design process, to create better products. In the remainder of this article, we’ll look at a case study where Uber prototyped to help them build better products for multilingual use, and we’ll run through some techniques that can help you and your team instill a bias towards prototyping from the beginning of the product design process.

Case study: Uber goes international

 

Uber, the increasingly ubiquitous ride-sharing service, boasts some impressive statistics. As of the writing of this article, 1+ million Uber drivers—or “driver partners,” as Uber prefers to call them—had given more than 2 billion rides to more than 8 million users. No matter what destination you travel to, you’re likely to find an Uber driver—they’re present in more than 400 cities in 70 countries.

Designing Uber’s app to work seamlessly for the drivers and riders in this multitude of countries offered a unique set of challenges. There are differences in language, of course, as well as with symbology and wireless access speeds. All of these variables had to be taken into account as Uber worked on a ground-up redesign of its driver app in 2015.

The team began with lightweight prototypes of the app in English, using Sketch and InVision. As they worked through these flows, the team had to also take into account their global audience, so they would go back into the Sketch files and update the languages to reflect Hindi or Chinese versions of the InVision prototypes.

With prototypes in hand, the team could test with users in each country and begin to answer critical questions about where the app might be confusing or fall short of an excellent user experience for the drivers. They began with the navigational structure. What were the important functions to drivers, and how should they organize the content of the app? In the evaluation phase, they asked whether terms like “earnings” and “ratings” would translate appropriately into the other languages.

 

Along the way, they made some interesting discoveries. For example, one of the icons for Earnings was a bar chart, which represented what the Earnings screen looked like when you tapped into it.

However, when they tested the prototype in India, drivers there thought the icon would take them to network settings. High latency and slow speeds kept the network at top-of-mind for Indian drivers—and the Earnings icon closely resembled common signal-strength icons you might see in the status bar of a smartphone.

This discovery allowed Uber designers to alter course and create an icon more representative of cash, which solved the problem before it had a chance to crop up in a live product.

Another discovery, also related to the low speed networks, was the scenario in which a driver was starting their shift and going online to begin accepting trips. At this point, the team had moved from low-fidelity prototypes, through higher-fidelity interactive and animated prototypes, to early functional builds.

In these initial builds, there was no feedback to the driver after tapping the button to go online—just a delay while the app called to the server to verify that the driver could accept trips in their current area.  To the driver, the app appeared frozen.

In this case, adding an animated transition, which normally might be considered non-critical “polish” of the app, was critical to its function. The animation resolved this problem and improved the user experience for drivers.

One important thing the Uber team did throughout the design process was match the fidelity of their prototypes to the questions that they had to answer. Early in the process, low-fidelity prototypes were used to get a better handle on how the product translated into other languages. As the product direction solidified, higher-resolution, functional prototypes ironed out some of the potential user experience roadblocks.

Prototyping earlier

As a designer, you’ve almost certainly built prototypes of a product before releasing it, but you may be looking for ways to insert prototyping earlier in your process. When considering the fidelity of a prototype, it’s always important to consider the kinds of questions that you’re trying to answer and to be cautious about interpreting the results of testing very low-fidelity prototypes with users (see Daniel Burka’s sidebar about prototype fidelity).

That said, if you are working out the flow of a new feature or trying to communicate ideas to team members, sketches and paper prototypes are completely valid ways of moving forward. Here, we’ll outline a number of techniques and ideas for moving prototypes to the beginning of your design process. Some can also be found in the Stanford d.school Bootcamp Bootleg.

The timeboxed prototype

Create a low resolution prototype of a feature that you’d like to test with your team, before investing the time to build a higher-fidelity version to test with users.

Challenge yourself to work quickly. Set aside an hour and create 2–3 variations of the prototype. Screens can be sketched by hand, captured on a smartphone, and brought into InVision to be made interactive. Alternately, you can use the Prototype on Paper (POP) app.

Prototype to decide

Settle an argument amongst your team about what direction to take a product or feature.

Just like Richard Feynman and Danny Hillis, your team might have differing points of view around the direction a product may take. To make a decision, build prototypes of the competing solutions.

If your users are going to judge, try to get to a level of fidelity that will elicit a genuine observable reaction from them—but don’t spend any more time than necessary. Distill the problem down as much as possible and isolate the variable you’re testing.

Wizard of Oz prototyping

Build a prototype faster by using humans on the back-end to save time and resources.

The music-streaming service Pandora has an almost magical ability to create playlists of the songs you like, just by rating a track or two with a thumbs up or down. The company likes to give credit to its Music Genome Project, which attempts to categorize all music by attributes (tempo, vocals, etc.) and then sort them using a complex algorithm.

Early on, however, the company realized it needed a human touch to make the playlists resonate with human ears. Much like the Wizard of Oz, there’s a human behind the curtain, categorizing and describing each song as part of the “algorithm.”

You can take advantage of this technique, too. If you’re building a chat-bot, for example, have a human on the other end supplying the replies until you better understand the needs of the user. Or if you’re trying to build an on-demand service (let’s say Uber for dog walkers), you and your team walk the dogs yourselves before you build out the infrastructure to summon actual dog walkers on demand. Tools like IFTTT and Zapier can connect the services needed to build prototypes like this—pushing a button can simply send a text right to your product team.

Wizard of Oz prototyping allows you to learn a lot about how your users communicate before the commitment of writing any back-end code.

Related: Prototyping in Sketch with Craft Prototype

Prototype to teach

In 1986, 7 astronauts lost their lives when the space shuttle Challenger broke apart 73 seconds into its flight. In the aftermath of this tragedy, Richard Feynman participated in a Congressional hearing investigating the cause of the disaster.

In what has become a famous anecdote, he sat in front of the congressional panel and demonstrated what happened to the shuttle’s O-rings in the colder-than-normal launch day temperature. Using a glass of water and dropping a clamped O-ring into the glass, he showed how O-rings become brittle and inflexible when exposed to the cold.

Contrast this simple demonstration with the complex charts produced by engineers in an attempt to warn about the dangers of O-ring exposure to cold temperatures.

Once again, Feynman’s ability to distill a problem down to its essence, and to create a prototype which tested his hypothesis, was critical to his ability to share this experiment. We prototype to learn—but we can also prototype to teach.

Challenge yourself to find new ways to insert prototyping into your design process—it might teach your team a fresh approach to a challenging idea. Sometimes the act of building is the best way to raise energy and surmount a problem. Just be clear about the questions you’re trying to answer and the level of fidelity you need to do so.

For many hands-on designers, prototyping is where the fun begins. And even though it’s the 4th phase of this Design Thinking framework, it can just as easily be a starting point (remember, the process is not always linear). Sometimes the key to good Empathy is sharing or co-creating a prototype with your users and getting feedback.

In the next chapter, we’ll talk about how to use these prototypes to test your hypotheses so you can channel your inner Feynman to overcome the problem at hand.

About the Authors

Aarron Walter
VP of Design Education

As the VP of Design Education at InVision, Aarron Walter draws upon 15 years of experience running product teams and teaching design to help companies enact design best practices. Aarron founded the UX practice at MailChimp and helped grow the product from a few thousand users to more than 10 million.

He is the author of the best selling book Designing for Emotion from A Book Apart. You’ll find Aarron on Twitter and Medium sharing thoughts on design. Learn more at http://aarronwalter.com.

Eli Woolery
Director of Design Education

Eli is the Director of Design Education at InVision. His design career spans both physical and digital products, and he has worked with companies ranging from startups (his own and others) to Fortune 500 companies.

In addition to his background in product and industrial design, he has been a professional photographer and filmmaker. He teaches the senior capstone class Implementation to undergraduate Product Designers at Stanford University. You can find Eli on Twitter and Medium.

Design Thinking Handbook
Design Thinking Handbook

Design better. Faster. Together.

Transform your products with the world's leading digital product design platform

GET STARTED NOW