The Define stage is where you take everything you learned during empathy research and distill it into a clear, actionable problem statement. It is the hinge of the entire design thinking process. Get it right and ideation flows naturally. Get it wrong and you will spend weeks building solutions to the wrong problem.

The Define stage narrows broad observations into focused, actionable problem statements

Why Defining the Problem Is the Hardest Part

Albert Einstein is often quoted as saying, "If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and five minutes thinking about solutions." Whether or not he actually said it, the principle is sound.

Most teams skip this stage or rush through it because it feels unproductive. You are not building anything. You are not generating ideas. You are just... thinking. But this thinking is what separates useful innovation from expensive guesswork.

After the Empathize stage, you should have empathy maps, affinity clusters, and possibly journey maps. The Define stage takes that raw material and shapes it into something you can act on.

The Point of View (POV) Statement

The POV statement is the primary output of the Define stage. It follows a simple structure:

[User] needs [need] because [insight].

Each component does specific work:

User: A specific person or archetype, not a generic label. "A working parent with two school-age children" is specific. "Our users" is not.
Need: What they need to accomplish or overcome. Frame it as a verb, not a feature. "Needs to coordinate family schedules across multiple activities" not "needs a scheduling app."
Insight: The surprising thing you learned from research that makes this need non-obvious. This is the part that most teams get wrong. If your insight is something everyone already knew, your POV is too shallow.

Example: From Research to POV

Suppose your empathy research for a healthcare project revealed these findings:

Patients with chronic conditions typically manage 3 to 7 medications
Most patients understand the importance of taking medications correctly
Missed doses usually happen not because patients forget but because their daily routine gets disrupted (travel, guests, unusual schedules)
Existing reminder apps treat medication as a standalone task rather than part of a daily rhythm

A weak POV: "Patients need a better way to remember their medications because they forget."

A strong POV: "Patients managing multiple chronic conditions need their medication routine to adapt to disruptions in their daily schedule because missed doses cluster around non-routine days, not forgetfulness."

See the difference? The strong POV contains a genuine insight from research: the problem is routine disruption, not memory. That insight completely changes the direction of ideation.

How Might We (HMW) Questions

Once you have a solid POV, convert it into "How Might We" questions. HMW questions reframe the problem as an opportunity, opening up space for creative solutions.

From the medication POV above, you might generate:

"How might we help patients maintain their medication routine when their daily schedule changes?"
"How might we make medication routines flexible enough to survive disruptions without requiring conscious effort?"
"How might we help patients anticipate schedule changes and pre-adjust their medication timing?"

Notice how each question is at a different scope. The first is broad. The second focuses on the "effortless" angle. The third focuses on anticipation. Generate 3 to 5 HMW questions at different scopes and then choose the one that best balances ambition with feasibility.

For more worked examples across healthcare, education, fintech, and sustainability, see our Problem Statement Examples guide.

Techniques for Finding the Insight

The insight is the hardest part of the POV to write well. Here are three techniques that help:

1. Look for Contradictions

Review your empathy maps and look for gaps between what people say and what they do. "I always eat healthy" said by someone whose observation notes show three fast-food wrappers in their car is a contradiction. Contradictions point to real, unmet needs that people have not consciously acknowledged.

2. Ask "Why" Five Times

Take a surface-level observation and ask why repeatedly until you reach a root cause.

"Users abandon the checkout flow." Why? "Because the shipping options are confusing." Why? "Because there are six options with similar names." Why? "Because the logistics team added options for internal tracking purposes." Why? "Because the CRM requires specific shipping codes." Why? "Because nobody updated the CRM categories when the company switched carriers three years ago."

The root cause (an outdated CRM configuration) is very different from the surface symptom (confusing checkout). If you define the problem at the surface level, you will redesign the checkout page. If you define it at the root, you will fix the underlying data structure and the checkout problem solves itself.

3. Cluster and Name

Group your research findings into themes and give each theme a name that captures the underlying pattern, not just the topic. "Payment issues" is a topic label. "Users equate payment complexity with untrustworthiness" is an insight label. The naming process itself forces you to articulate what you actually learned.

Common Traps

Defining a solution disguised as a problem. "Users need a mobile app for X" is not a problem statement. It is a solution statement with the word "need" in front of it. A genuine problem statement describes the gap between what exists and what should exist without prescribing how to close it.

Too broad to act on. "People need better access to healthcare" is true but useless for ideation. Narrow it. Which people? Which aspect of access? What specific barrier did your research reveal?

Too narrow to ideate on. "Users need the submit button to be green instead of blue" is specific but has only one possible solution. A good problem statement should open up at least 5 to 10 different solution directions.

Missing the insight. If you can delete the "because" clause and the statement still makes perfect sense, your insight is not doing any work. The insight should change how you think about the problem.

What Comes Next

With your POV statement and HMW questions finalized, you are ready for the Ideate stage. The quality of your problem definition directly determines the quality of the ideas you generate. A sharp HMW question produces sharp ideas. A vague one produces a brainstorming session full of generic suggestions.