How to Write a Design Thinking Problem Statement

Turn empathy research into a point-of-view statement naming a specific user, a real need, and an insight that reframes the challenge.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

A design thinking problem statement, usually called a point of view or POV, is the sentence your team will ideate against. In Stanford d.school's framing, this work translates empathy findings into user needs and insights and then scopes a meaningful challenge. It belongs to the Define mode, one of the five modes the d.school identifies alongside Empathize, Ideate, Prototype and Test. For the method's history, definition and the full picture of how the modes relate, see the Design Thinking method page. This page is only about doing the framing well.

The statement matters because it decides which ideas count as on-topic. IxDF's ideation guidance lists a problem statement or point of view as a starting input for ideation and advises staying focused on the topic. A frame that is too broad produces a brainstorm that scatters in every direction. A frame that is too narrow, or that quietly names a solution, produces a brainstorm that only rearranges one idea. Either way, the team spends its ideation energy on the wrong question.

The primary input is the understanding of users and their environments that the team gathered through empathy work, as the d.school bootleg deck describes. In practice that means interview notes, observations, quotes, photos and whatever patterns the team has already pulled out. If the raw material has not been sorted yet, do that first using Synthesizing User Insights, because a POV built directly on unsorted notes tends to repeat the loudest anecdote.

The output is small and specific: one or a few POV statements, each with four parts. There is a user described precisely enough to picture, a need phrased as what that user is trying to accomplish, an insight that changes how the team sees the situation, and a line stating what would be game-changing if the insight is correct. Each statement should be ready to be broken into prompts for Generating Divergent Ideas.

You can tell framing went wrong in a few ways. The team reads the statement and everyone proposes the same fix. The user could be swapped for any customer segment without changing a word. The insight is something the team already believed before the research. Or the need is a feature request in disguise, such as needing a dashboard. Each of these signals that the frame is describing the team's assumptions rather than the user's situation.

How It Works

A point of view has four working parts, and each one does a different job. The d.school guidance gives the core moves: describe the user in vivid language with pertinent details, choose an insight that represents a powerful shift in perspective, and state what would be game-changing for the user if that insight is correct. The need sits between the user and the insight and ties them together.

User. The user description sets the boundaries of empathy for everyone who reads the statement. It should identify a relevant person or group, not a generic customer or audience, which is why the d.school asks for pertinent details rather than demographics for their own sake. A good test is whether a teammate could picture a specific moment in that person's day.

Need. The need says what the user is trying to accomplish. Phrasing it as an activity or outcome, for example "needs to hand off a patient without losing context," keeps it open to many solutions. Phrasing it as a thing, such as "needs an app," closes the solution space before ideation starts.

Insight. The insight explains why the need is hard or unmet, and it is the part that makes a POV worth ideating against. Pick the one that most changed the team's thinking. An insight everyone already agreed with adds no direction; one that surprised the room usually opens new territory.

Game-changer. This line describes what would be different for the user if the insight holds. It gives ideation a target without naming a product.

The table below contrasts weak and strong versions of each part. Illustrative scenario: a team studying clinical handovers on a hospital ward.

Scoping the challenge. Once the parts are drafted, scope is the final judgment. The d.school treats framing as ending in a scoped, meaningful challenge, and IxDF notes that ideation should start from the problem statement or point of view and stay focused on it. A practical check is a quick smoke test: ask the group for a handful of ideas against the statement in a couple of minutes, for example five ideas in two minutes. If every idea is the same, the frame is too narrow or contains a solution. If the ideas have nothing in common, the frame is too broad. Adjust the user, need or insight, not just the wording, until the ideas are varied but clearly about the same person and problem.

Step-by-Step Guide

Step 1: Reassemble the empathy material

Gather everything from the research in one place: interview notes, observation logs, quotes, photos and any patterns already identified. The d.school names an understanding of users and their environments from empathy work as the input to framing, so the POV can only be as good as this material. Bring in at least one person who did the fieldwork so context is not lost. If there are several distinct user groups, decide now whether you are writing one POV or several.

Pro tip: Read two or three raw quotes aloud before drafting anything. It anchors the room in the user's words instead of the team's summary.

Step 2: Pull needs and insights from observations

Translate observations into needs and insights rather than carrying raw notes straight into ideation, which is the first move in the d.school's description of framing. For each meaningful observation, ask what the person was trying to do and why it was difficult for them. Write needs as activities or outcomes, and write insights as explanations of the difficulty. Keep a list of candidates rather than settling on one yet.

Pro tip: If a candidate need contains a noun like app, portal or dashboard, rewrite it as the action the user wants that thing for.

Step 3: Describe the specific user

Write a short description of the user in vivid language with pertinent details, as the d.school bootleg deck recommends. Choose details that bear on the problem, such as when, where and under what pressure they act, and drop details that do not. The description should identify a relevant person or group, not a generic customer. Check that someone who missed the research could picture this person in a concrete moment.

Step 4: Choose the perspective-shifting insight

From your candidate insights, select the one that represents a powerful shift in the team's perspective, which is the d.school's criterion for a strong POV. Ask which insight surprised people or overturned an assumption held before the research. Confirm that it rests on something users actually said or did, not on a teammate's hunch. If two insights compete, draft a POV for each and compare them in the scoping step.

Pro tip: Ask the room: what did we believe before the research that this insight contradicts? If nobody can answer, the insight is probably not shifting anything.

Step 5: State the game-changing outcome

Write one line on what would be game-changing for the user if the insight is correct, following the d.school's guidance. Describe a changed situation for the user, not a product or feature the team will build. This line gives ideation a destination while leaving the route open. Then combine user, need, insight and game-changer into a single readable statement.

Pro tip: A useful template is: user needs a way to do something because of an insight, and it would be game-changing if a changed situation were true.

Step 6: Scope and pressure-test the challenge

Check whether the statement is scoped for ideation. IxDF advises that ideation start from a problem statement or point of view and stay focused on it, so the frame must be tight enough to focus a session and open enough to allow varied answers. Run a quick smoke test by asking for several ideas against it and looking at their spread. Too similar means narrow or solution-laden; too unrelated means broad.

Revise the underlying component rather than the wording, then hand the statement to the ideation facilitator.

Pro tip: Keep rejected drafts. When test results later challenge the frame, an earlier variant is often the right starting point for the rewrite.

Best Practices

• Write the POV with people who did the research in the room. They carry context that notes lose, and they can tell quickly when a statement no longer matches what users said.
• Phrase needs as activities or outcomes, never as features. A need framed as a thing presupposes the answer and shrinks ideation to variations on it.
• Choose the insight that surprised the team, not the one everyone agreed with. The d.school asks for an insight representing a powerful shift in perspective, because an unsurprising insight gives ideation no new direction.
• Trace every part of the statement to evidence. If you cannot point to an observation or quote behind the user detail, need or insight, treat that part as an assumption to verify.
• Write separate POVs for genuinely different users. Blending two groups into one statement produces a description that fits neither, and ideas that serve neither well.
• Treat the POV as the anchor for ideation. IxDF recommends that brainstorming stay focused on the problem statement or point of view, so keep it visible throughout the session and use it to redirect drift.

Common Mistakes

• Describing the user as a generic segment such as small businesses or our customers.: Describe a specific person or group with pertinent details, as the d.school recommends. If the user could be swapped for any other segment without changing the statement, it is too generic.
• Embedding a solution in the need, for example needs a mobile app for tracking.: Rewrite the need as what the user is trying to accomplish. Solutions belong in ideation, and naming one in the frame means the team only iterates on it.
• Carrying raw observations straight into ideation without interpreting them.: Translate observations into needs and insights first, which the d.school treats as the core of framing. Raw observations describe what happened; the POV has to explain why it matters.
• Picking an insight the team already believed before the research.: Choose the insight that changed minds. If the POV could have been written without doing the research, it adds nothing to what the team knew.
• Scoping the challenge so broadly that any idea qualifies.: Run a quick smoke test and look at the spread of ideas. If they share no common thread, narrow the user or the need until ideas stay on topic but still vary.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Design Thinking

Related Skills

• Generating Divergent Ideas
• Building Rapid Prototypes
• Balancing Desirability, Feasibility, and Viability
• Iterating from Evidence
• Synthesizing User Insights

Sources

• Design Thinking Bootleg | Stanford d.school
• dschool.sfo3.digitaloceanspaces.com
• Stage 3 in the Design Thinking Process: Ideate | IxDF

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.