The Five Stages of Design Thinking
Design Thinking is a five-stage model proposed by the Hasso-Plattner Institute of Design at Stanford (d.school). The five stages are: Empathize, Define (the problem), Ideate, Prototype, and Test.
1. Empathize
Empathy is defined as “understand and share the feelings of another”. The first step of Design Thinking is to gain that understanding and shared feeling of the personas and problem for which you are solving. This requires both defining all of your assumptions and then acknowledging that they are only assumptions, to seek beyond them to actual data gained through direct contact with the affected personas.
Empathy for your users is developed through research. Whether it is collecting your group’s assumptions, interviewing users, or analyzing historical data, you are researching the problem at hand and the landscape of issues surrounding it, and then synthesizing and internalizing your discoveries. This makes sense, of course. If someone comes to you with a problem, you want to know as much as possible about that problem, it’s potential causes, affected personas, and solutions that have been considered. You want to feel it from the perspective of the affected users. Otherwise, how can you solve it?
The problem with research, in many organizations, is that “research” is actually done by the client or internal customer, informed by their experience living the problem (or hearing from others who are affected) on a daily basis. They “know” everything about the problem, the root causes, and even how to fix it. You end up receiving, not a description of a problem, but a prescription for exactly what to build or create to solve the problem. Unfortunately, what stands for “research” in this case ends up being the perspective of a limited number of people, and rarely are those people the ones directly affected. So the message gets watered down, and even worse gets translated into technical marching orders by non-technical customers. And most importantly, the solution is based on assumptions and anecdotal evidence. We all know how this often turns out for the worst.
Research is an essential step in any significant effort and should be undertaken by the team doing the work, with direct access to the users who are affected by the problem and therefore the solution. Anything short of that is a game of “telephone” based on assumptions. Research needs the rigor of UX practitioners to guide and facilitate the research efforts, and the neutrality of researchers who are outside the company or division of the research subjects.
This is not to say that the clients and internal customers who bring their problems to us should not be heard. To the contrary, they have an important role in level setting the efforts at the beginning of Design Thinking and at regular points during the project. Most importantly, they are often aware of business constraints that need to be factored into the solution, regardless of what the user data reveals. What they should not be encouraged to do is dictate the solution. This is our responsibility as creative professionals. Research will actually tell us more about the problem than they know, often more than anyone knows. It’s up to them to provide us with direction toward the problem and the affected personas, and we take it from there.
Research can be a time-consuming activity. Interviewing can be derailed by difficult interviewee schedules or other time constraints. It may take time to accumulate enough data for analysis. People may put off taking your survey until the deadline. The goal and challenge are to make research as lightweight as possible. It’s often said that 5 interviews will tell you 80% of what you want to know. There are a number of lightweight research techniques to minimize the overhead and time commitments of research because every day a team is researching is a day they are not coding. However, research is an essential function, and skipping it to get farther ahead on development isn’t going to save time if you have to later throw all that code away.
2. Define the Problem
Research is only one half of what is often called “discovery”; the other half is making sense of the data collected in the Empathize phase and narrow it down to a small number of Problem Statements. A problem statement is the culmination of your research and problem definition efforts. It defines, in user-centric terms, the problem, the persona affected, the action that causes the problem, and the underlying cause of the problem.
Problem Statements are of critical importance to the rest of your design efforts, because they state the problem in user-centric terms, and are based on your research efforts. Problem Statements are not hearsay, or what your customer believes to be true. They may not all be true, but Design Thinking is a scientific method for generating hypotheses to test assumptions with real users, and by following the process we validate our hypotheses. And by basing our problem statements on educated hypotheses, rather than the word of stakeholders who may not have the most direct line to the information necessary to solve the problem, we start much closer to 100% to begin with.
How do you get from research to a problem statement? By analysis and synthesis of your research data. UX techniques like user story mapping and affinity mapping help to boil down your results into themes and categories, pain points and data points. Prioritization techniques can help you to identify the pain points that are the most painful and most frequent, which are often the best place to start when looking at possible MVP solutions. In general, you should try to solve the biggest pain for the most people first, in the spirit of getting the most value to the user as quickly as possible. When we get to identifying possible solutions for our top pain points, we will prioritize those as well based on speed to market and perceived user value.
3. Ideate
Up to this point in our discussion, Design Thinking has been about research and analysis, leading up to the problem statement. Depending on the team members involved in this process, they may be getting antsy to get started with the design (and/or the technical solution). Now, with a problem statement in hand, the team is at last free to pair their creativity and expertise with their newfound knowledge of the problem to conceptualize innovative solutions. The ideation phase is all about innovating, but at the user level in terms of the user experience, answering the question “what user experience can we provide (screens, messages, emails, etc) that will solve the problem statement or allow users to solve it themselves?”
I want to be very clear that Ideation is not about technical solutioning. There is a fundamental difference between designing for the user and solving a technical solution. Trying to do them simultaneously is only a distraction to the first task at hand, to explore how to solve the problem for the user. Think about the essential steps in the process you are implementing or enhancing, and then ideate on as many ideas as possible for how to allow the user to accomplish those same steps.
Let’s use the example of a hammer. The hammer is a solution for driving a nail into a piece of wood. Our problem statement could say:
As a… carpenter
When I… try to drive nails into hard to reach spots
I have the problem… being unable to drive in the nails
Because… there is no room to swing the hammer
How might we… make it possible to drive nails into hard to reach spots
So if we were going to try to ideate on this problem, but also at the same time we have decided that we want to keep the technical solution a hammer, but come up with a hammer that solves the problem. So, we start experimenting with hammers. We make very small hammers that can fit into tight spaces that can be swung in a few inches, but these can only drive very small nails. We try normal hammers with very long heads on them so you swing them from far away, but it’s very hard to drive in a nail from far away. After a while, we run out of ideas for how we can modify the hammer to do the job.
We took a problem “getting a nail into hard to reach spots” and turned it into the problem “how to use a hammer to get a nail into hard to reach spots”. Defining the technical solution before the user experience is designed is like trying to invent a better hammer when there are more elegant options. Once we reconsider the problem in a more abstract way “nail in hard to reach spots”, and abstract away any expectations about what the technical solution should or shouldn’t be, it eliminates that as a distraction to “out of the box thinking” that departs completely from the established precedent. Then you look at this “nail” problem and realize a “gun” with a thin nozzle could use compressed air to force a nail into wood, eliminating the need for “swinging room”, side-stepping the hammer altogether to discover the nail gun.
4. Prototype
Empathizing, Defining the Problem, and Ideating have mostly worked in the realm of words and some simple sketches, and that is fine for those steps. You are trying to get your arms around the problem and go wide on possible solutions, so anything but words and sketches, up until now, would only be heavy and premature.
At the end of Ideation, you should have completed numerous user interface design sketches created by the entire team with ideas for possible solutions. It is now up to the team to identify one or more solutions (or combinations of solutions) that contain their strongest ideas, and then create prototypes of these designs to present to users. Next, we need to get user feedback to validate if the conceptual solutions will really serve the user. This is the complement to the research you did in the Empathize step; before you were asking them for feedback on their experience of the problem, now you need to get feedback on their experience with your proposed solutions for that problem. Anything you can tangibly create to get this feedback is known as a Prototype.
Prototypes support the Design Thinking bias towards action “making over talking/thinking”; get something out into the world that will help you find gaps in the solution and feed new ideas as you create it, and garner more relevant feedback from users than if you were simply describing it to them.
I defined Prototypes as anything you can “tangibly create” to get feedback. This can mean clickable, high-fidelity mockups, but a prototype can also be anything that sufficiently conveys the idea to your user including paper sketches, storyboards, and even experiences like role-playing. Whatever the method, your prototype should make the user experience tangible for the user so they are not trying to translate a description of the experience but are able to experience it directly.
Prototypes are an excellent technique that can be used throughout the Design Thinking process. Design Thinking is non-linear and iterative, and prototyping can help you think through problems and communicate with users at every step of the process.
Prototypes are important because your research is not going to tell you everything you need to know to solve the problem. Research may lead you in one direction, but as soon as you show users your proposed screens they may realize there is a fundamental flaw in their assumptions (which they will usually externalize as a problem with your design). There is really no other way to get at that information than taking the user through a simulation of the intended experience and allow them to feel it rather than think about it. They are fundamentally different ways of experiencing the solution.
Prototypes are meant to be fast and easy. Prototypes can rarely take the place of a fully functional “live” solution, but they can often be close enough to elicit valuable feedback. People can fill in the blanks in your prototype if you give them the right amount of information, which allows the prototypes to be more lightweight and faster to get into users hands so you can start collecting the feedback sooner. The longer you wait to validate your concepts with users, the more time and effort you will waste if you later find out you are on the wrong track. Prototypes allow you to get feedback quickly, within a single sprint, so the team can know which way to move forward with their solution.
5. Test
Testing prototypes with users is a kind of user research called Usability Testing. Usability testing is about understanding the “usefulness” of the solution which includes both usability and utility: is it intuitive and easy to use, and does it solve the problem? A prototype simulates the flow of a solution for the user, allowing them to experience it almost as they would if it were coded for real. Your role as a facilitator of the usability test is to have the user to explain to you what they are seeing and what they think they can do with the solution, an indicator of usability, and if using it will solve the problem, which speaks to the utility.
You would be surprised the low fidelity users are willing to accept in a prototype if they are able to click around and get a sense for it as a real application. Users will often be more accepting of very low fidelity prototypes than more high fidelity where they can get distracted by irrelevant issues like body copy or colors.
It is often helpful to test more than one solution design in the same session, in effect an A/B test of your solutions. This can be a little tricky because the experience of the first design will inevitably flavor the user’s experience of the second one, but you could have a separate activity in between to sort of “cleanse the palette”. When done right it can be very effective to have the feedback on multiple designs from the same person in the same session.
Testing is often the final step in the Design Thinking process before the team starts building out a solution. One or more solutions are validated as potentially valuable by users, they are planned and put in the backlog. Many times, however, you will get to the end of a round of testing and have no validated solutions, or only part of the solution is validated, preventing you from moving forward until the rest of the solution has been designed and validated.
At this point in Design Thinking, you would retrace your steps and do new work to get to a validated solution. Testing may have uncovered new information that was missed in the original user research, which could potentially send you back to the ‘Define the Problem’ step to reevaluate your problem statement. Testing may have validated the problem statement but invalidated all the proposed solutions, so you would go back to the ‘Ideation’ step to consider new solution possibilities for the original problem statement, avoiding concepts that were invalidated by users.
Summary
Design Thinking is a five stage, user-centric model for discovering, designing and validating software. Beginning with Empathy, we conduct research to understand the problem from our users’ perspective. Next we Define the Problem to clarify what we are actually trying to solve. Ideation is where we imagine possible solutions from the user’s perspective. In Prototyping we “tangibly create” a simulation of our solution to gather user feedback. Lastly we Test our prototype and gather the learnings. These stages can be followed sequentially but are often repeated in smaller loops (Ideate through Testing for example) depending on the outcome of research and testing.
