Understanding the Messy “Define” Stage

In our previous articles, we’ve discussed the basics of design thinking and immersive empathy. In this post, we’ll dive a little deeper into what we refer to as the “define” stage in that process. Warning: it’s messy! So let’s first remind ourselves where it sits in the Hasso-Plattner Institute of Design’s proposal:

Image source Interaction Design Foundation Website Interaction-designorg
Image source: Interaction Design Foundation

Defining “Define”

The main concern in the “define” stage of Design Thinking is around clearly articulating the problem you are trying to solve. Without clearly defining the problem, you will stumble in the dark and come up with solutions that don’t work. Our goal should be to frame the problem correctly. By doing so, we generate a variety of questions, which in turn give us different options and ways of thinking about the problem. As a result, more solutions will open up. 

The fundamental questions at this stage are:

  • What is the actual problem we are trying to solve?
  • Who is really affected by it?
  • What are the different ways of solving the problem?

In order to answer these questions, we use the data collected by members of the team through engagement with users during the “empathize” stage. This data is interpreted and assigned meaning by all members of the cross-functional team.

Interpreting and assigning meaning is concerned with knowing:

  1. Who the users are.
  2. Their motivations.
  3. Their context.
  4. Their needs relating to the particular problem you are trying to solve.

The Define Stage in Practice

Begin by making the data you’ve collected more visual in order to identify patterns and themes.

Unpack user stories in order to allow the cross-functional team to dissect the stories and organize them into four categories. The four categories in which the user data is organized are:

  1. Quotes and defining words.
  2. Thoughts and beliefs.
  3. Actions and behaviors: think body language vs. what the user is saying.
  4. Feelings and emotions: emotional responses may be positive, neutral, or negative.

Unpacking is: 

  1. Sharing what you found with fellow designers.
  2. Capturing the important parts in a visual form.
  3. Getting all the information out of your head and onto a wall.
  4. Making connections, patterns, themes.
design thinking
Source: Joey Aquino

Unpack Your Findings Through Story Mapping

How exactly does one unpack findings? Do so by creating empathy maps of user experiences.

Begin by reproducing the diagram above on a tall vertical space like a wall, whiteboard, etc. Write names of the interviewees/users on the board—you can post pictures of your users under their names, with pictures of their environment if you have them.

Under each name, put up post-its that tell the stories that you gathered during empathy interviews: what they said, how they responded, how they reacted, and their emotional responses (What did you hear? What did you feel? What did you see?).

List their emotional responses: positive, neutral, or negative.

Then their actions: body language offers a more reliable way of reading than the words one is saying. Body language may reveal hesitation, doubt, resistance and other behaviors that become a basis for deeper understanding of the problem. Make note of what stood out: contrasts, contradictions, tensions. What patterns emerge? What connections emerge? What themes emerge? What are the key takeaways from each interview? 

How do you start making connections between all the possibilities raised during the unpacking phase?

What questions are sparked, and how do they spark possible solutions? Through discussion, reflection and synthesis, we start forming “how might we?” questions. These are meant to spark ideas in a radical new direction.

What needs do you see? 

What is the real problem? 

Always Remember: The Process Is Not Linear

At this stage, you will find yourself going out to gather more data from new and familiar users. You will bring more interview data, unpack it, and synthesize it.

You will keep coming up with more insights, and you’ll keep discovering different needs. However, you still won’t know what the real problem is. So embrace ambiguity and uncertainty.

Allow for the problem to germinate. It’s an organic process. You will eventually arrive at what the real problem is. Do not impose your own shortcut answer.

Methods Used in This Process: #1 Analysis and Synthesis

Analysis is about breaking down complex concepts and problems into smaller, easier-to-understand constituents. 

Synthesis, on the other hand, involves creatively piecing the puzzle together to form whole ideas.

Here are three ways of carrying out analysis and synthesis:

  • Information clustering to reveal patterns in the data.
  • Analysis of metaphors used by the users.
  • Exploring contexts: social, cultural, psychological, functional, etc.

Methods Used in This Process: #2 Five Whys

5 Whys is an iterative interrogative technique used to explore the cause-and-effect relationships of a particular problem. The primary goal is to get to the bottom of a problem by repeating the question “Why?” where each answer leads to the next question. Typically, five cycles are enough to achieve the goal here.

Not all problems have a single root cause. If one wishes to uncover multiple root causes, the method must be repeated, asking a different sequence of questions each time.

Here’s an example Toyota offers of a potential 5 Whys that might be used at one of their plants.

The Main Goal

The main goal of the define stage is to club all the answers together and convert them into a coherent single statement.

In other words: a meaningful and actionable problem statement or point of view. This focuses on the insights and needs of a particular user or composite character.

The POV statement is created by making sense of who the users are, what their needs are, and the insights that come from the observations
made. 

This is laid out in this easy formula from IDEO’s Design School:

IDEO
Source

And here’s a similar take on a point of view:

POV
Source

What Makes a Good Problem Statement?

A problem statement is a roadmap that guides your team and focuses on the specific needs that you have
uncovered. It creates a sense of possibility and optimism that
allows team members to spark off ideas in the Ideation stage. 

A good
problem statement should thus have the following traits:

  • Human-centred. The problem
    statement should be about the people the team is trying to help, rather
    than focusing on technology, monetary returns, or product
    specifications.
  • Broad enough for creative freedom. The problem statement should not focus too narrowly on a specific
    method regarding the implementation of the solution.
  • Narrow enough to make it manageable. A problem statement such as “Improve the human condition” is
    too broad. Problem statements should have sufficient constraints to make the
    project manageable.
  • Forward looking: A good problem statement is always forward looking. It contains within it seeds for possibilities. 
  • Verb driven, action oriented: begin the problem statement with a verb, such as “Create”, “Define”, or “Adapt”, to make the problem become more action-oriented (source).

“How Might We”: From Define to Ideate 

Now that you have your problem statement, it is time to reframe the problem/challenge using a “how might we” statement.

“Every problem is an opportunity for design. By framing your challenge as a How Might We question, you’ll set yourself up for an innovative solution.” — Designkit.org

Detailed Steps

  1. Start by looking at the insight/problem statements that you’ve created. 
  2. What further insights/topics arise from the problem statement? These topics are subsets of the entire problem. They focus on different aspects of the challenge. 
  3. Try rephrasing/reframing them as questions by adding “How might we” at the beginning. It is a good idea to spend plenty of time getting the right HMWs first, before you start generating ideas.
  4. The goal is to find opportunities for design, so if your insights suggest several How Might We questions, that’s great.
  5. Now take a look at your How Might We question and ask yourself if it allows for a variety of solutions. If it doesn’t, broaden it. Your How Might We should generate a number of possible answers and will become a launchpad for your brainstorms.
  6. Finally, make sure that your ‘How Might We’s aren’t too broad. It’s a tricky process but a good How Might We should give you a narrow enough frame to let you know where to start your brainstorm, but also enough breadth to give you room to explore wild ideas.
  7. Use brainstorming techniques to come up with as many solutions that you and your team can imagine to How Might We? questions. 
  8. Finally, prioritise the best ideas with the team, build on them, and work them into next steps. At the ideation stage, you can select different topics and try out a few to find the sweet spot of where the group can really churn out a large quantity of compelling ideas.

Conclusion

As you’ll have gathered, the define stage is messy. It’s where we spend a lot of time understanding what the real problem is and what its root causes are. Without getting to the root of the problem, we will not be able to clearly define it, and any solution we come up with will fail.

In the define stage, every possible iteration of the problem and its potential solution are explored. We gain a sharper focus by continuous exploration of all the variabilities that occur during this stage. This enables us to know what the real problem is and what the best solution is. 

The end goal of this stage is to come up with a clearly defined and actionable problem statement that shows the team what the real problem is and who the users are. This lays the ground for coming up with ideas that suggest potential solutions to the problem. 

Sources