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
03

Define

Reframe the problem

Listen to Chapter

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.

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.

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.

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.

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.

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.

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.

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

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.

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