How to synthesize empathy research into clear problem statements using POV and How Might We frameworks. Practical examples and common traps to avoid.
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.
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 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:
Suppose your empathy research for a healthcare project revealed these findings:
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.
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:
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.
The insight is the hardest part of the POV to write well. Here are three techniques that help:
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.
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.
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.
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.
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.
Related guides: ideate stage · prototype stage · test stage
Design Thinker Labs Home · All Guides · How It Works · Pricing