Making Sense of Uncertainty with Design Thinking

by | Design

Kayla MacNeil and Trevor Newberry discuss Design Thinking

Design thinking is a problem-solving methodology that is non-linear and iterative. The process contains a number of steps–which means that, while the methodology has well-defined phases, they don’t always happen linearly and often any given problem will go through several iterations of design thinking before an acceptable solution has been discovered and validated.

Practically speaking, design thinking helps us address poorly defined or even completely unknown problems. In new venture creation and new software development in particular, we’re frequently dealing with user desires and pain that are novel and which even the users themselves may struggle to define clearly.

For that reason, we turn to design thinking as a process for understanding, defining, ideating, and testing solutions. It’s a comprehensive approach that, when implemented correctly, helps give structure and definition to unstructured problems.

In this article, we’ll cover the five phases of design thinking, some common techniques for practicing design thinking, and where you can start with design thinking in your organization or startup.

The Five Steps of Design Thinking

Design thinking consists of five distinct steps which, as we’ve already covered, are not required to be engaged in step-by-step and should be iterated on over time to arrive at better and better solution ideas.

Step 1: Empathize

Developing empathy for your user is the first step to understanding the problems they’re facing and coming up with effective solution ideas. Empathy comes from regular communication, observation, and feedback.

Practically, we build empathy with our users along the entire process of design thinking from user interviews to validating solutions with prototype demonstrations.

Step 2: Define

Once you have developed a good understanding of your user, the next step is to define the problem more clearly. Defining the problem is more than just summarizing what has been encountered, but also begins to shape the question of how it can be solved.

When we define the problem we’re trying to solve, we typically want to use the voice of our users. A very common format is the User Story typically used to communicate desired outcomes to developers.

Step 3: Ideate

In the Ideate phase of design thinking, potential solutions are generated. There are many techniques for generating new ideas that range from brainstorming to multi-day design sprints. We’ll cover a few of our favorites in the next session.

Step 4: Prototype

Once potential solutions have been ideated and refined, it’s time to build prototypes. Prototypes are fake versions of your solution idea that are intended to be interactive and communicate the key value of the solution to users.

Prototypes can take many forms and exist at a wide range of fidelity. From simple drawings on paper to functional software prototypes, there is a wide range of options to choose from that should be achievable by anyone regardless of technical abilities.

Step 5: Test + Iterate

Testing is when we test put our solution prototypes in front of real users, gather feedback, and make changes based on that feedback. This is the last step in the design thinking process. It is very common for testing to require several iterations before a team is satisfied that the solution is both highly usable and that it delivers value effectively to the end user.

Getting Started with Design Thinking

Now that you have a basic understanding of what design thinking is, what it helps us accomplish, and the steps in the design thinking process, we wanted to talk through a few techniques that we’ve found particularly helpful when developing problems into new product ideas.


Our primary tool for developing empathy with users is the Discovery Interview. These 20-30 minute interviews are carefully designed to help us understand the behaviors and motivations of users.

We accomplish this by developing story-based questions instead of direct questions. For example, instead of asking “How do you [insert activity]?” we will instead ask our interview participants to describe the last time they actually engaged in that activity.

From that point, we will drill down into specifics asking questions to understand the who, what, when, where, and why of the activity. This helps us add context and understand the motivational drivers for the activity much better.

The outcome of a Discovery Interview is captured in the form of Opportunities. We use the phrase opportunity to describe not only problems but also the desires and unmet needs expressed by users. These opportunities and any helpful insights are collected and shared via several assets and documents we create internally and that helps the team stay aligned.

Another great tool for developing empathy is market research. While this is a degree or more removed from the user themselves, we can often correlate the behavioral and motivational data from interviews with trends and data from market research.

We also spend time analyzing user sentiment about competitor products to paint an even more detailed picture of the opportunities that exist for these users. To accomplish this, we review and document the negative and positive attributes expressed by users in reviews and social media interactions of our competitor’s products.


If we’ve done our jobs well developing empathy with our users and documenting and sharing our findings, then defining the problem is usually pretty straightforward. However, one thing we always try to remember is that defining problems should be a combination of the problem itself along with the desired outcome expressed from the perspective of the user.

A common format for this kind of problem definition is the user story. User stories are typically structured like this:

“As a [user], I want to [perform an action], so that [desired outcome].”

For example, a user story for Uber might sound like this:

“As a commuter, I want to request a ride from my phone whenever I need it so that I can get to and from my commitments easier.”

Another common format is the “How might we…?” statement. In this format, we structure the problem as a question of solving the problem. Using the Uber example above, we might say:

“How might we help commuters request rides when they need it more easily so that they can get to and from their commitments easier?”

“How might we…?” statements still need to contain the elements of User, Action, Outcome but are helpful in that they are structured as a prompt for teams to ideate around.

One of the challenges with defining problems is balancing specificity with the freedom to ideate and test solutions. This can take some practice, but, as a general rule, if the team feels like the problem statement boxes them into one or two solution ideas, then the statement is too narrow.

However, if the team feels like beginning ideation is difficult or even impossible based on the problem statement, you’ve likely structured the problem definition too broadly.

Structuring your problem definition this way allows the entire team to understand the problem, desire, or need as well as the outcome a user hopes to solve this problem will help them achieve.


We could write entire volumes about ideation. Instead, we’ll make a few suggestions here and provide links to helpful articles that will allow you to facilitate ideation with your team.

There are several key things to consider and accomplish for effective ideation:

  1. A properly defined problem statement (see the previous section)
  2. Starting by ideating alone, then refining as a group
  3. An ideation format or structure that is easy to follow and understand

Since we already have a properly defined problem statement, we’ll focus our energies on the other two elements.

Ideating as a group carries with it a whole host of cognitive bias pitfalls you should work actively to avoid. Instead of listing each one and ways to avoid them, we can instead give you one simple rule that will accomplish the same thing:

Begin your ideation sessions by working individually, then return to the group for sharing, refinement, and voting.

Thanks to numerous studies, we now know that we are most creative when we begin our ideation alone and that editing and refining ideas is best reserved for group participation.

Bearing this in mind, there are two key methods we use to ideate solutions:

  1. Crazy 8s
  2. Brainwriting

Crazy 8s is a simple exercise that asks participants to come up with eight unique solution ideas in eight minutes. Participants are encouraged to illustrate, however crudely, their ideas as illustrating engages a different, more creative part of our brains.

Brainwriting is a group exercise that consists of rounds of ideation and evolving ideas each round. Participants begin with a sheet of paper and are asked to ideate and write down three ideas in five minutes. After this five-minute round, the sheets are passed to the next person and another round begins. At this stage, each person can generate three completely new ideas or evolve the ideas from previous steps, a process known as “hitchhiking”

Regardless of the method you choose to ideate with your group, the following steps are almost always the same:

  1. Identify and merge or remove duplicate ideas
  2. Discuss or debate the remaining ideas
  3. Decide by either voting or decider or a combination of the two


Once we’ve ideated and decided on a solution for our target problem, we need to create a fake or incomplete version of the solution idea that we can use to test with users and iterate based on their feedback.

At HVL, we create high-fidelity prototypes using a tool called Figma and occasionally create functional prototypes with actual code. However, you don’t need to be technical or a trained designer to create a prototype.

Instead, you can create working prototypes using several low-fi techniques:

Flipbook prototyping

Simply draw each screen of your solution idea in a notebook. Draw each screen on successive pages and ask your users to navigate the prototype by “clicking” on buttons or parts of the screen using their fingers to point.

You can turn the pages of your flipbook prototype to simulate navigating to a new screen or part of the application.


These days most slide builders like Powerpoint and Google Slides allow users to interact with the slides through mouse clicks. This is handy for prototyping as you can simulate the experience of using an application and take advantage of the clickable navigation to simulate navigating the application.

Low-Fidelity Prototyping Software

Finally, there are tools designed to help you create quick and easy prototypes regardless of your technical skill.

One of the most popular is Balsamiq. Other tools like Miro, Whimsical, or even Apple’s new app Freeform can allow you to create simulative experiences of your solution idea to test with users.

Regardless of the tool you choose, the goal of creating a prototype remains the same. Your goal is to simulate the delivery of the key value of your solution idea for users and to gather their feedback to help iterate new versions of your solution.

For this reason, it isn’t necessary to create a prototype that contains things like sign-up/sign-in flows, settings, etc. You simply need to demonstrate the key parts of your solution idea that communicate value delivery.

In the next section, we’ll talk about testing and iterating your prototype.

Test + Iterate

Now that you have a defined problem, an idea for a solution, and a prototype to test your solution, you’ll need to start…testing it!

Prototype testing is an incredibly useful exercise that allows you to gather important insights and use them to evolve or iterate your solution idea to accomplish two key tasks:

  1. Be extremely usable by users
  2. Deliver value quickly and effectively to users

To conduct these tests, you will want to engage in Prototype Demos with users. Demos can be led by you and your team or, even better, they can be led by the user with your guidance. 

Prototype demos are relatively simple to conduct, but there are a few rules you’ll want to follow to collect user feedback and avoid biases. 

  1. Have a script ready
    1. Introduce yourself
    2. Explain the process
      1. There are no wrong answers
      2. We want you to think aloud as you’re engaging with the prototype
      3. If you’re stuck, we’ll try to let you figure it out before we jump in to help
  2. Start the demo
    1. Be ready with specific prompts that are outcome-based to guide the demo
      1. For example, “Please navigate to the next page” is preferable to “Click this button to navigate to the next page.” 
      2. You want to be specific about the outcome you’re asking the participant to achieve, but not the action they take to get to the outcome. 
    2. If they get stuck, take a deep breath and see if they can figure out how to get unstuck on their own
      1. This can be very uncomfortable for some people, but trust us when we say it passes quickly and the insights you gain from watching users navigate sticky parts of your prototype are invaluable
  3. Take good notes!
    1. Have a partner to help take notes for you
    2. If possible, record the demo for future reference and to cross-check notes
  4. Share insights from your demo with your product team and use them to iterate the prototype to deliver more value

After three-to-five of these demos, you should start to see patterns in feedback regarding how you can improve the prototype. Take a break, iterate your prototype based on the feedback, and start again with another three-to-five participants. 

At a certain point, you’ll notice that these demos become less and less productive and that you’re hearing a lot of the same things over and over again. That’s a great sign that it’s time to take the prototype, convert it into tasks for engineering, and build the product or features you’ve been testing. 

Design thinking is a fantastic framework for systematically taking unknowns and uncertainties and converting them into knowledge that your team can use to build amazing products that deliver value for your customers. 

One last thing to remember is that there is a meta benefit to practicing design thinking: improving how you learn and perform as a team

Over time and after completing these steps together repeatedly, you should start to notice that your individual and collective “sense” of what makes products great and valuable begins to crystalize and help shorten the feedback loop between the idea and the finished product. Be sure to pay attention to this effect and take advantage of it to ship more value to your customers faster. 

In the world of startups, speed wins and design thinking is an excellent ways to both deliver value reliably and increase your team’s speed to delivering that value.