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. It 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.

"Design thinking is a human-centered approach to innovation that draws from the designer’s toolkit to integrate the needs of people, the possibilities of technology, and the requirements for business success."

Tim Brown — IDEO

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.

“Design thinking is making organizations think about how to move faster…with iterative speed.”

John Maeda — Automattic

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:

Stanford d.school’s design thinking framework.

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.

DESIGN SYSTEMS HANDBOOK

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.

"Empathy is at the heart of design. Without the understanding of what others see, feel, and experience, design is a pointless task."

Tim Brown — IDEO

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.

Figure 1: The Embrace infant warmer.

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.)

Design the ideal wallet — VIEW EXERCISE

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

"Ultimately, people want to feel that they are in control … managing money is not generally something people like to deal with … [this project] was about helping people build better habits, but also relate to their money in more positive ways."

Christian Marc Schmidt — INTERACTION AT IDEO DURING THE KEEP THE CHANGE PROJECT

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.

"There was an almost unexpected and very emotional effect from this new service … people who previously never had savings suddenly did … and it wasn’t the amount that mattered; even a small amount of money in their savings account gave them a sense of power and control over their finances."

Faith Tucker — SENIOR VICE PRESIDENT & PRODUCT DEVELOPER AT BANK OF AMERICA DURING THE KEEP THE CHANGE PROJECT

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.

Erika Hall, Mule Design

Listen Online: Defining ethnography

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.

“It’s painful, and it helps us understand where the shortcomings in our product are…”

Julie Zhou — FACEBOOK, FEATURED IN THE DOCUMENTARY DESIGN DISTRUPTORS

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.

Erika Hall, Mule Design

Listen Online: Minimum viable ethnography

A camera study can be a great substitute for rapid empathy work, but getting buy-in from the participants is an essential, and not always easy piece.

Bobby Hughes — AARDVARK DESIGN LABS

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:

Camera studies & user permissions — VIEW EXERCISE

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.

“I’m trying to solve a problem I see in every industry, where the person in the room who talks about the customer wins.”

John Maeda — AUTOMATTIC

Further reading

Interviews aren’t the only way to gain empathy

D.school Wallet Project

Just Enough Research

Creative Confidence

Wired to Care

DESIGN SYSTEMS HANDBOOK

In 1968, when Apollo 8 became the first spacecraft to circumnavigate the moon, the crew had one photographic mission: to capture detailed images of the moon’s surface. As the astronauts rounded the dark side, Earth became visible—a brilliant blue and white marble. Earth was remarkable not only for its serene beauty from this perspective but also for its apparent fragility. The only life-sustaining planet in our solar system is dwarfed by the vast emptiness of space.

With the photograph from this event, which became known as “Earthrise,” the Apollo 8 astronauts inadvertently sparked a spontaneous reframing of the environmental problems threatening our planet. No longer were we on a vast planet with seemingly endless resources, but rather a small, very finite lifeboat in an infinite universe. This change in perspective helped charge the modern environmental movement, inspiring the creation of Earth Day in 1970.

Figure 1: Earthrise: image of Earth from NASA’s Apollo 8 mission.

Reframing the way that a problem is viewed can inspire a movement, as it did in this case. It can also be a powerful way to create innovative design solutions to challenging problems and even create new and disruptive business models. During the Empathize phase of the Design Thinking process, you collected stories and insights from your users. This Define phase will give you an opportunity to synthesize these findings and come up with a problem statement, called a point of view (POV), that can help you reframe the problem and open new and innovative solution spaces.

Developing a point of view (POV)

A POV is composed of 3 elements:

• Who is your user? (Note as many specific details as possible.)
• What is their deep, unmet need?
• Why is this insightful? (List the insights you gleaned from your empathetic needfinding process.)

As an example, below is a POV from the founders of AwesomeBox, a gift-giving platform, used in the early days of developing their product. They were trying to design for people who have a hard time giving thoughtful gifts. They interviewed and observed hundreds of potential customers, from which they created POVs like the following.

Figure 2: An early POV from the founders of the gift-giving platform AwesomeBox.

Let’s create some hypothetical POVs using Netflix, as they’re a good example of a company that disrupted an existing business model by reframing the problem for users.

In the early days, Netflix might have framed their POV like this:

“Caroline is a 26-year-old single mom who loves sci-fi movies. She needs a way to rent DVDs that doesn’t clutter her already-busy schedule, while making her feel relaxed after a long day of work and taking care of her daughter.”

Using this point of view, Netflix certainly could have come up with a solution that only delivers DVDs by mail—but the solution space would have been constrained and they might’ve missed a larger opportunity.

Now consider how Netflix could have reframed the problem with a different POV.

Caroline is a 26-year-old single mom who loves sci-fi movies. She needs a way to access new and entertaining content in a way that allows her to consume it at her own pace, while making her feel excited about discovering new shows to share with her friends.

With the problem statement rewritten, Netflix opened up all kinds of opportunities for innovation. Let’s unpack them.

“She needs a way to access new and entertaining content … ”

This doesn’t even mention DVDs! In the early days, a mail delivery solution may have worked, but over time Netflix developed the streaming services that helped make them so popular. Also, “new and entertaining” doesn’t necessarily limit them to licensing content. Netflix could also develop and distribute their own shows.

“ … in a way that allows her to consume it at her own pace … ”

Again, mail delivery of DVDs would be a partial solution to this constraint, but with streaming as an option, there’s an even bigger opportunity. Add in original content, and now Caroline can binge-watch House of Cards while her daughter sleeps. (We never said that innovative solutions always have a positive social impact.)

“ … while making her feel excited about discovering new shows … ”

Netflix famously developed a “recommendation algorithm” that helps viewers discover new content based on the shows they already watch—and the ratings they give to each. This feature wouldn’t have necessarily stemmed from the previous POV.

“ … which she can share with her friends.”

This last insight, while minor on its surface, is a huge reason for the viral growth of Netflix—especially after the company began developing original content. Once rave reviews about shows began to surface—with the only way to access them being Netflix—the continued growth was almost assured.

Andy Law, Netflix

Listen Online: Reframing to scale

Clearly, there would have been a lot of value left on the table had Netflix used the first POV to guide their designs. In addition to helping you reframe a problem, a good POV can align your team, provide a way to compare competing ideas, and help fuel brainstorms. In fact, the d.school at Stanford came up with a great checklist of all the things that a good POV should help you accomplish:

Point of view (POV) checklist

Your POV should:

• Provide focus and frame the problem
• Inspire your team
• Provide a reference for evaluating competing ideas
• Empower team members to make decisions in response to the high level goals of the team
• Fuel brainstorms by suggesting “how might we” statements
• Capture the hearts and minds of people you meet
• Save you from the impossible task of developing solution concepts that are all things to all people
• Allow you to revisit and reformulate the POV as you learn by doing
• Guide your innovation efforts

In the remaining sections of this chapter, we will dive into a case study where developing a POV provided inspiration for a healthcare project with a lot of impact. Then, we’ll share an exercise to help you quickly generate POVs of your own.

Leah Buley, author of The User Experience Team of One

Listen Online: Synthesizing Research

Case study: GE Healthcare MRI redesign

We first met Doug Dietz when doing the research for this chapter. Over the phone, Doug is a kind, affable midwesterner—the sort of guy you imagine it would be fun to go to a Milwaukee Brewers game with. But beneath his unassuming presence is a formidable design mind with over 25 years of experience at GE Healthcare. First as a principal designer and now Innovation Architect, Doug has helped develop medical equipment such as MRI and CT scanners for one of the world’s largest corporations.

In 2008, Doug ran into a problem. He was at a hospital where one of his new MRI machines had recently been installed. The machine had won a prestigious industrial design award and Doug was eager to see the machine in situ.

Before he had much of a chance to ask the technician about the machine, he was asked to step outside of the room, as a patient was scheduled to come in for an appointment. What he witnessed in the hallway changed the course of his career and helped him reframe the MRI user experience.

A young family walked in, their 7-year-old daughter obviously distressed. As the family got closer, Doug could see that she was weeping. The father leaned over and said, “Remember, we talked about this, you can be brave.”

Doug peered into the room where the young girl was about to enter the scanner. Crouching down, he had a new perspective on the room—and on the machine that he had so proudly designed. He could immediately understand why the girl was terrified: warning stickers plastered the machine and yellow and black tape marked the floor like a crash-test scene. The machine itself looked like a beige “brick with a hole in it.”

Given this new perspective, it’s no mystery why many children have to be sedated to get MRI or CT scans. Everything about the experience can be frightening, from the room and the machine to the claustrophobia and loud noises. Doug came away with a new mission: to understand how GE might redesign this experience for children so that it’s a positive experience and not something to be dreaded.

Doug’s boss recommended he attend an executive education workshop at the d.school at Stanford to get the Design Thinking toolkit and help him solve this big, emotionally-charged problem. The workshop helped him frame the problem as a POV, in the form of a Madlib which was structured in the following way:

“We met … ”

“We were amazed to realize that … ”

“It would change the world if … ”

Using this framework, Doug and his team were able to iterate on their POV until they came up with a statement more aligned with the goal.

“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 children between 3 and 8 years old, in order to have them 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.”

By reframing the problem using this POV, Doug and his team realized that the beginning of the user experience started at home, when the parents were trying to figure out what the procedure was like and how to explain it to their children. They were able to outline the whole user journey for the family and determine the different touchpoints that they could influence or redesign.

Doug Dietz, GE Healthcare

Listen Online: The experience is the product

The team didn’t have the budget to do a full redesign of the machines, so once they had identified a few promising opportunities, they decided to implement a low-fidelity prototype. By applying decals to the exterior of the machine and the walls of the scanning room, they were able to transform the dull, monotone experience into a colorful pirate adventure, where the captain’s helm led to the inside of the “ship” (this feature had the added benefit of making the opening seem much larger and less claustrophobic). They created a script for the operator, who led the children through the pirate adventure.

Figure 3: By reframing the problem, Doug Dietz created a positive experience for children facing stressful MRI and CAT scans. Photo courtesy Children’s Hospital of Pittsburgh.

The results from this redesign and from others like it were no less than amazing. Sedation rates dropped from 80% to fractions of one percent. But to Doug, the human stories behind the numbers are just as important.

While visiting the pirate-themed scanner, Doug talked to the parents of a little girl about the room’s piña colada scented aroma, something they were getting a kick out of. The little girl came up to the mom and tugged at her shirt. “Can we come back tomorrow?” she asked.

For at least one family, Doug and his team had transformed the experience from something terrifying to something to look forward to. By using their POV as a way to reframe the problem, his team was able to change the world.

Using Madlibs to generate POVs — VIEW EXERCISE

The exponential power of reframing

In their wonderful 1977 film for IBM, designers Charles and Ray Eames explored how perspectives change by looking at the relative scale of objects. For example, the film zooms out from a man and woman on a picnic blanket to the grass surrounding them.

The short film Powers of Ten by designers Charles and Ray Eames

A film dealing with the relative size of things in the universe and the effect of adding another zero.

The film quickly progresses through Earth to the edge of the universe, then zooms back into the nucleus of a carbon atom. In the process, viewers get a wonderful understanding of extremes at both ends of the scale, but also of how reframing your viewpoint can create a new perspective on something familiar and ordinary.

As designers, we can leverage the power of reframing to help us innovate and solve wicked problems. We can create POVs to help guide our product design process and connect us to our users. And if we’re lucky, we might just see the world in a new light along the way.

Further reading

How Reframing A Problem Unlocks Innovation

Three Ways to Reframe a Problem to Find an Innovative Solution

Reframe: Shift the Way You Work, Innovate, and Think

Designing features using Job Stories

Don’t Make a Journey Map: 9 archetypes

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.

Figure 1: The NASA Houston mission control team discusses the emergency filter prototype ‘mailbox.’

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.”

Figure 2: The ‘mailbox’ filter as created by the astronauts on board the Apollo 13 mission.

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

I don’t believe the value of brainstorming is the ideas generated; I believe it is the shared value/evaluation context created. The experience of brainstorming creates a group of people with a shared perspective, and an understanding of each other’s communication styles, who are then capable of providing a useful and powerful critique of future work on the topic.

Tim Sheiner — SALESFORCE

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.

"[Brainstorms are] excellent at helping clients buy into the creative process…they get to join in on the brainstorms, they see lots of ideas, they get to vote for their favorites and a dialogue happens during the voting process that is crucial. Some kind of sorting always follows a brainstorm, and it’s during this process that one can learn from the client. What have they already done or are currently doing? What can’t they do? Won’t they do? And most importantly, what are they excited about?"

Yona Belfort — VITAL INNOVATION

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.

[The] goal is to give you a mass quantity of ideas quickly … not solutions, but the seeds to possible solutions. Solutions take real hard work. Brainstorming gets you the lay of the land quickly for possible solution areas to investigate. But good solutions are like body building, there’s no way to cheat the hours of the gym you got to put in.

Art Sandoval — LUNAR DESIGN

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.

Irene Au, KHOSLA VENTURES

Listen Online: Design sprints and brainstorming

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.

Figure 3: An illustration of the design thinking process, showing flaring and focusing phases, from the Stanford d.school’s visual resource guide.

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.

PRO TIP — Brainstorming at IDEO

Peter Macdonald has run countless brainstorms during his 23-year tenure at IDEO as a design lead. Peter says: “You can’t have a good brainstorm without setting it up right—having everyone feeling safe and heard. A key element is trust, consistent with IDEO’s culture of trust. Bullies and blowhards are not tolerated.”

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.”

Brainstorm warm-up: 30 circles — VIEW EXERCISE

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.

Daniel Burka, Google Ventures

Listen Online: Flipping soft vs. hard skills ketching in design sprints

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.

Figure 4: Mindmapping a birthday party for a 1 year old.

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.”

Figure 5: Mendeleev’s 1869 handwritten sketch of the periodic table.

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.

Further reading

When brainstorming fails, throw an imaginary cat

Graphic Design Thinking: Beyond Brainstorming

How IBM brings forward ideas from its teams

How to Fly a Horse

Quiet: The Power of Introverts in a World That Can't Stop Talking

"You must not fool yourself, and you are the easiest person to fool."

Richard Feynman

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.

Figure 1: A production version of the CM-1 Connection Machine.

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

"The reason that these prototypes are really useful is that when we don’t have a live product built, but we need to get feedback, we can send them to researchers on the ground … it allows us to get feedback not just from drivers in San Francisco, but from all around the world."

Molly Nix — UBER

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.

"A good prototype is a prototype that facilitates answering the questions you have."

Molly Nix — UBER

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.

Figure 2: The original Earnings icon for the Uber driver app was confusing for drivers in India. Via Molly Nix on Medium.

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.

Figure 3: An animated transition helped Uber drivers understand the app wasn’t frozen when going online. Via Molly Nix on Medium.

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.

"Timeboxing [a prototype] forces you to focus on the right things."

Daniel Burka — GOOGLE VENTURES

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.

“Typically we will go to a higher fidelity, earlier on in the process…”

Andy Law — NETFLIX

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.

Figure 4: Complex charts, filled with ‘chartjunk,’ proved to be more confusing than enlightening to those investigating the Challenger disaster.

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.

Further reading

Prototyping Lessons from a BMX backflip

The Lean Product Playbook

The Skeptic’s Guide To Low-Fidelity Prototyping

10 Tips on Prototyping UIs with Sketch

How I Built This (NPR): Instagram

A Guide to Prototype Fidelity

If you’ve ever been to a spin class, you may think there isn’t much variability in the experience: a dark room, music with a beat, an instructor yelling to change the level to 8 and keep pushing. SoulCycle offers something different.

From the minute you walk in the door, SoulCycle fosters a sense of community. Heading into class, you pass by the lockers where the previous class is exiting—giving a chance for serendipitous encounters. The instructors shout inspirational quotes as you pump up a hill and hover above your saddle.

With this emphasis on the whole user experience, it’s no wonder that SoulCycle has garnered something of a cult following, even at 34 bucks a class—which sell out quickly.

“On Mondays at noon—when the upcoming week’s schedule for SoulCycle is released—if you’re not on the computer hitting the keys right then like an eBay addict on the hunt for porcelain figurines, you’re often out of luck.”

–From a Vanity Fair article on SoulCycle

Obviously, this part of the experience doesn’t seem to be in line with the brand. SoulCycle decided to create a mobile app so riders wouldn’t have to be glued to their desktops in anticipation of booking a class.

Prolific Interactive, the agency that SoulCycle hired to create the app, went through the entire design thinking process, from empathy-based user research to testing—using InVision along the way for testing prototypes and getting feedback from stakeholders.

The Prolific team worked out at SoulCycle twice a week, manned the front desk at the studio, and “interviewed the founders, staff, and frequent riders to understand the inner workings of the company.” Getting insights from these observations and interviews guided them as they began working on early solutions.

Beginner’s mind

Figure 1: Zen Mind, Beginner’s Mind by Shunryu Suzuki (image via Meditation Los Angeles).

Adopting a beginner’s mind is valuable at every step of the design process. To test early solutions and not be blinded by assumptions, the Prolific team needed to tackle their challenge with fresh eyes. The Zen teacher Shunryu Suzuki writes that, “In the beginner’s mind there are many possibilities, in the expert’s mind there are few.”

As you Empathize, it allows you to be open to the experiences of people from different backgrounds and see things from their perspectives. When you Define, it helps you reframe your point of view to see a problem from a different angle. As you Ideate, a beginner’s mind prevents you from being judgmental about ideas that seem trivial or silly, but which may spur new approaches to a problem.

Building your Prototype, a beginner’s mindset helps remind you that the purpose of a prototype is to answer critical questions quickly—not to highlight your mastery as a designer.

And when you test your prototype, a beginner’s mindset opens you to both the many possible directions of your design and to the ways it might address real human needs. Each step along the way affords an opportunity to rethink, relearn, and reboot as needed. The design process is rarely linear.

Test early, test often

If prototyping is where the fun begins for many designers, testing is where it can get a little scary. Getting your product ideas in front of real users for feedback can be daunting. But the whole basis for prototyping early and often is intended to keep us from forming attachments to ideas that may or may not be worthwhile.

By testing our prototypes with real users in context, observing their reactions, 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.”

It’s important to test prototypes early in the design process so you can quickly correct course if your product hypotheses are incorrect. As we discussed in Fast feedback, testing these assumptions early will help you build better products faster.

"While testing the app prototype, we ultimately realized that speed was critical; some of the bikes get booked in 30 seconds, so designing the flow in such a way that people wouldn’t get caught up at any step was really important."

Christine Lee — PROLIFIC INTERACTIVE

Once the Prolific team started building prototypes, they tested them on site. The great thing about this situation was they didn’t have to do any user recruiting. SoulCycle welcomed the team to run prototypes by their riders as often as they liked (while being respectful of their time, of course). This also had the benefit of mirroring the context where users were booking a class.

Figure 2: Early wireframes of the SoulCycle app.

There was already some anxiety about getting into class on time, so users were forced to go through the app test in a hurry, which quickly revealed speed bumps in the flow. The team eventually moved on to more formal user testing sessions, observing users in a conference room as they went through a few scenarios while thinking aloud.

"We started out by testing our prototypes in SoulCycle studios with riders. That gave us a sense of the real constraints: distractions, unstable internet connections, and time crunches. User testing challenged our assumptions and we got to get out of our own design-focused heads to see how our designs fared in the real world."

Christine Lee — PROLIFIC INTERACTIVE

Throughout the process, the Prolific team relied on a rapid prototyping and testing cycle and kept the SoulCycle stakeholders updated with new insights and observations, rather than “keeping the research and design process hidden behind a curtain for weeks before revealing it in a comprehensive research report that no one would end up reading.”

The app is a huge hit with riders, and it’s largely thanks to the collaborative effort between Prolific, SoulCycle, and users who helped test the prototypes.

Keeping a beginner’s mindset

The older you get as a designer, the more you realize that you just don’t know anything … if you can embrace that you don’t know, but you know how to go find out, that makes you very effective.

Daniel Burka — GOOGLE VENTURES

The Tega is a cuddly, expressive robot that MIT researchers developed as a personalized educational assistant for young children. Designed to act as a peer in digital learning environments, Tega’s facial expression recognition allows it to mimic a child’s demeanor, which the MIT team hoped would help the robot and child bond during learning sessions.

They could have tried to test this hypothesis in the lab, but they would have had no clue whether young kids would actually find the robot charming, scary, or boring. So they brought a Tega prototype to a classroom to test in context with preschoolers.

The results were fantastic. Team member Goren Gordon said, “After a while the students started hugging it, touching it, making the expression it was making and playing independently with almost no intervention or encouragement.” And even more crucially, Tega was able to increase the children’s positive feelings toward it with its physical behaviors—leaning over like it was interested or making happy noises.

Erika Hall, Mule Design

Listen Online: Focus Groups

These parameters are critical. They were testing the prototype in context (at a preschool, with kids in the target demographic), and were able to observe the reactions of the users in real-time. They didn’t rely on a survey or focus group about the experience (which with children at this age wouldn’t have worked anyway). Observing these gut reactions is what makes testing with a prototype so powerful; it’s hard for people to fake enthusiasm or hide frustrations when interacting with a product, and so the signal is clear.

With these tests, the MIT team was able to determine that Tega was a promising platform for other educational contexts, such as helping students with learning disabilities. And they never would have discovered this if they hadn’t brought the prototype out into the real world, embracing the fact that they didn’t know what the results would be.

Having a beginner’s mindset and testing assumptions early in the design process will help you design better products faster. It can be just as important to carry this mindset to later tests, when a product is more developed, to answer questions about critical scenarios. This is exactly what the Google Ventures team did to help robotics company Savioke (see the interview with Daniel Burka below).

Daniel Burka, Google Ventures

Listen Online: Testing Savioke's Relay robot

It takes a lot of effort to round up participants for in-person, one-on-one tests, but the results are compelling. Below we outline some testing techniques and suggestions for a variety of timeline and budgetary considerations.

Setting up your test

Set objectives

What specifically are you testing, and what do you want to know? This drives everything that comes next: the questions you ask, the people you recruit, and how you determine success.

Recruiting users

As we’ve seen in the examples above, running user tests in person is the ideal situation, but recruiting users to come to your office (or better yet, to visit in-situ where they will be using the product) isn’t always feasible. In the Fast feedback section of Principles of Product Design, we run through some ideas for recruiting both in-person and remote users.

Erika Hall’s Just Enough Research also has some fantastic tips for recruiting users. She highlights the importance of setting the parameters for a good research participant (e.g., “shares the concerns and goals of your target users” and “can articulate their thoughts clearly”). She also outlines how to create a screener, so you can “weed out the ax murderers and the fatally inarticulate.” And she gives some great tips on places to post a link to the screener—friends and family can be a great resource for sharing (assuming they are likely to reach your target demographic), and Craigslist (along with social media) is your friend.

If you’re constrained to remote testing, services like ethn.io and UserTesting can provide you with users in fairly targeted demographics.

Testing the prototype

Once you’ve recruited your users, create an experience for them that puts the prototype into a context as close to real life use as possible, whether it’s before a workout like SoulCycle or testing in a hotel like Savioke. You want your users to react to the experience, not to an explanation of the prototype. The more real-life it feels, the more natural these reactions will be.

It’s also important to show, not tell. Once your user is set up with the experience, prototype in hand, don’t explain everything right away. Give them a chance to figure things out, and observe how they use the product. Is it intuitive, or are your users confused or frustrated? What kind of questions do they have? Look for smiles or frowns as they work with the prototype.

Finally, remember in the Ideate phase where you came up with several ideas to test? It can be helpful to bring multiple prototypes to a testing session. This will give users more fodder to react to and compare against (e.g. “the version of the SoulCycle app that introduced the trainer with a video was great, but I really just need to book my session as quickly as possible, so I’m more inclined to use the version without it because it’s faster.”)

Capturing video and audio of your users in action with the prototype will be helpful in the next step. You don’t need anything fancy—just use the equipment you have at hand (smartphones and screen recording software will work just fine). Michael Margolis at Google Ventures outlines a slightly more elaborate setup, which can be handy if you’re testing mobile prototypes.

Reviewing and synthesizing observations

After you’re done with testing sessions, it’s important to take the time to review and synthesize your findings. Again, Just Enough Research is a great resource for this. In her section on analyzing the data from user research, Erika Hall outlines how to structure the session (summarize goals, pull quotes and observations), the space and supplies you’ll need (sticky notes and sharpies!), and the types of data to look for (user goals and priorities).

Another great resource for debriefing and synthesizing is from Brendan Mulligan at Cluster. Mulligan outlines some great tips and techniques for holding a viewing party and capturing insights from your team, and identifying and bucketing patterns as a group.

Once you’ve had a chance to synthesize the data and group patterns, take a look at how they support or contradict your original POVs. This is an iterative process. Testing your prototypes should give you a chance to refine your original hypotheses and make the product that much better in the next round.

Empathy and compassion

The beginner’s mind is the mind of compassion. When our mind is compassionate, it is boundless.

Shunryu Suzuki — ZEN MIND, BEGINNER’S MIND

Empathy is the heart of design, as it allows us to experience the situations our users find themselves in. Empathy lets us discover opportunities to make those experiences less frightening—like Doug Dietz did for children needing MRIs—or more delightful, like the Savioke team did with Relay.

Compassion in tandem with a beginner’s mind helps us translate empathy into action. If we instill a sense of duty toward users in our designs, we can align our products with the humans who use them—and perhaps improve their lives along the way. We can remain open to the possibility that our first ideas weren’t our best ideas, and that by taking an iterative approach and gaining insights from our users as we test prototypes, we can make better products.

As designers, we have a real impact on how our products take shape, how users experience them, and the consequences of their use. We hope that you have a chance to use these opportunities with empathy and compassion, and design products that you’re proud to bring into the world.

Further reading

Just Enough Research

How to run live user testing Part 3: the debrief

The GV Research Sprint: Interview participants and summarize findings

Remote User Testing at Vox