Defining problems in the Design Thinking process

Carla

Published in

Bootcamp

8 min readJun 12, 2022

Notes on the second stage of Design Thinking — Define.

What Is Design Thinking?

Before discussing about defining problems and identifying solutions, let’s start with the beginning. What is Design Thinking? Design thinking is a non-linear, iterative process that we use to define problems, identify solutions, prototype and test them. The process involves five stages — Empathize, Define, Ideate, Prototype, Test.

The steps of the Design Thinking process

The Define Phase

The purpose in the Define phase of Design Thinking is to define an actionable problem statement that you can work towards solving. Having gathered as much information as you could about your users, this is when you make sense of it, in order to understand which design problem to address.

Analyzing vs Synthesizing

After going through the process of gathering user data and uncovering several concepts and problems, we must break them down into smaller pieces in order to identify the areas that need to be addressed. This analysis can be done during the Define phase, but also as you collect the data, as you may need additional data, or to interpret the data you already collected.

When we talk about synthesizing data, we refer to the processes that follows analysis, which is combining the points of data into whole ideas, problem statements and solutions. This can be done in the Define phase, the Ideation phase, and even in the Prototype phase.

Analysis and synthesis often happen consecutively throughout all stages of the design thinking process, and produce valuable insights.

Methods of Defining the Problem

The most common methods used when defining problems are personas, affinity diagrams, and empathy maps. Additionally, some other methods worth exploring are:

Storyboarding
Story Madlibs
User Stories
Reframing
2x2 Diagrams
Customer Journey Maps
Card Sorting
Value Proposition Canvas

So let’s discuss some of these methods in more detail.

👉 Affinity Diagrams

To begin with the definition, an affinity diagram is a collection of large amounts of data, organised in groups or themes based on their relationship. Here is an example.

Afinity diagram example from Miro — Source

There are several steps to be followed when creating an affinity diagram:

We start by grouping similar pieces of data

You can use post-it notes for this (Miro is a nice alternative for remote teamwork) → Write a piece of information on each post-it note. These can be quotes, facts, ideas, observations, any sort of information that will help your design process.
Place these on a wall or whiteboard if you’re working in person, or in Miro or any app of your choice.
Choose one of these post-it notes randomly — this will be your first post-it or your first group.
Next, take each post-it separately and add it either to the already created group, or create a new group as needed, if it doesn’t fit there.
Continue doing this, post-it by post-it, until you’re left with clearly defined groups of data. If there are any post-it notes that don’t fit in any group, that’s fine at this stage. Leave them on the board, they can sit on their own for now.

2. After grouping the data, we discuss on each post-it note, to clarify the clusters. Here are a few notes on this:

Discuss with your colleagues all the pieces of data on the post-it notes, and reorganise them as needed.
When you are all satisfied with the groups created, name them accordingly, to best represent the information in each.

So we’ve created our affinity diagram, but how does it actually help us in our design process? Well to begin with, it stands as the basis for empathy maps and user personas. By having a clear view of our target audience in clusters of data, we ensure we create accurate personas that best represent the potential users of our product. Furthermore, affinity diagrams help us synthesize insights and create problem statements that guide or design thinking process.

👉 Personas

Speaking of personas, these are fictional characters that we as designers use to represent the target audience of our product. This is how we ensure we design for the users, and not for ourselves. While these are fictional, they are based on real data gathered through research, and not on fictional data. Because personas use individual names, rather than collective ones, we can focus on individuals rather than groups, which allows for more targeted design.

Personas can be categorised on four aspects:

Goal-directed personas → Based upon Alan Cooper’s perspectives, the purpose of such a persona is to observe the process a user follows when wishing to achieve a goal using your product. This is the type of persona that aims to define the user’s needs and wants.
Role-based personas → While also goal-oriented, a role-based persona focuses on behaviour and is built on both qualitative and quantitative data.
Engaging personas → These types of personas tap into the emotions of the user, their psychology and background, and can encompass both goal-oriented and role-based personas, as well as the traditional personas.
Proto personas → Built based on assumptions, these personas can be deeply flawed, as they require the team to assume things based on interactions with users and products.

We can define 10 steps when creating engaging personas:

Collect data
Form a hypothesis
Ensure everyone accepts the hypothesis
Establish a number of personas
Construct and describe your personas
Prepare situations for your personas
Get acceptance from your organisation
Disseminate knowledge
Create scenarios for the personas
Make ongoing adjustments

I discussed more about the anatomy of a user persona in this article 👉 https://medium.com/@ux-notes/the-anatomy-of-a-user-persona-419b25c2e629

👉 Empathy Maps

In definition, an empathy map helps you visualize data which you summed up and learned from design research. Being done in the Define phase, it helps define user’s needs and develop an actionable problem statement.

Empathy map example from Miro — Miro template — Empathy Map

There are several ways in which empathy maps help us in our design thinking process:

Firstly, it removes bias from your research and helps uncover the user’s real wants and needs.
It helps uncover certain gaps that you might have in your research, and ways in which you could address those gaps through new research.
Empathy maps also assist in categorising knowledge in order to make sense of it about a particular user persona or segment of users.
It adds more depth to personas.
When we create empathy maps, we can clearly map out ideas and involve more colleagues and stakeholders into our design thinking process, by presenting clear information that helps develop the product.
Empathy maps also serve in decision making, as they organise data effectively.

As a structure, empathy maps consist of four quadrants:

Says → Contains direct quotes from user research.
Does → Contains the actions that users took and what processed they followed.
Thinks → Contains information about what users think, which we gather by actually asking what they though during the research, in order not to assume anything.
Feels → Contains information about the users’ emotional state.
Extra sections → At the bottom of the empathy map, we can add two additional sections for Pains and Gains. The Pains section refer to the pain points each user experiences, and the Gains section refers to the user’s ultimate goals and what they want to achieve.

When creating empathy maps, we can follow several steps to ensure they are built correctly and reflect all the needed information:

Define the scope and purpose — after defining these, we also want to make sure everyone in the team is on board.
Conduct relevant research—user interviews, user observations, and other forms of research will be conducted in this stage.
Fill out the empathy map—you can use pen&paper for this, sticky notes. I personally use Miro for this, and they also provide templates to make things easier.
Analyse each quadrant data — in this stage you can cluster similar pieces of information together, and discuss each cluster with your team.
Identify your users’ needs — some things to look for in the data: verbs (activities and desires), the user traits you noted, contradictions and inconsistencies. You can also use Maslow’s Hierarchy of Needs for this stage.

Creating Your Point of View (POV) Problem Statement

Having gone through some of the methods we use most often to define our user’s needs, wants and pain points, we can now discuss about contouring our POV problem statement.

A POV is what will guide the team throughout the rest of the design process.

So what are the traits of a good POV problem statement?

It should first of all be centered around your users. We want to always keep in mind our target audience’s needs, wants and behaviours, in order to ensure we build a product that truly addresses these needs.
A POV problem statement should be broad enough for creative freedom. This means that we should always allow creative flexibility to team members, in order to uncover new ideas and opportunities.
We should start with a verb, as to make the POV actionable (e.g. “create”, “define”, “adapt”).
Ensure the POV you define is narrow enough to make it manageable for the team to handle, but not vague that’s impossible for the team to solve.
The POV must be built as a source of inspiration. A good POV has the potential to create a sense of optimism within the team, which is much needed.

There are several steps that we can follow when developing a POV:

Define the user — this is the step where we define which type of person we wish to design for.
Express your definitions — we put the definitions of user, needs and insights on paper (or an app such as Miro).
Articulate the POV—we can use the following sentence and fill it in with our information:

[User . . . (description)] needs [Need . . . (verb)] because [Insight . . . (compelling statement)]

4. Make sure the POV is on point—the last step is to ensure that the POV is narrow enough to focus on something specific, while also valid, insightful, and actionable.

Conclusions

The define stage focuses on organising all the information gathered in the Empathize stage, by observing and defining the problems identified up until this point. As the entire Design Thinking process, the Defining phase is human-centered, and helps define the user personas and user journeys, as well as the POV problem statement which acts as the basis of the design that the team will work on.