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


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



Early and often

Listen to Chapter

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

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, “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.

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.

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.

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

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

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

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.


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

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