Problem statements
A problem statement is a concise, user-centred description of what needs to be solved — before any solution is chosen. It aligns the team on scope, communicates why the work matters, and keeps ideation focused on user needs rather than premature features.
Why it matters
NN/g describes problem statements as a scoping device: they make clear what discovery will explore and what is out of scope. Well-written statements help stakeholders agree on why a problem deserves investment and provide a basis for measuring success later.
Key ideas
- Solution-free. Describe the problem, not a feature. Users need verbs (goals and end states), not nouns (dropdowns, dashboards).
- Name who is affected. Call out the user group and how the problem impacts them.
- Explain why it matters. Connect the problem to user value and, where relevant, organisational impact.
- Keep it brief. A few clear sentences beat a long narrative that obscures the focus.
- Trace to evidence. Each statement should link back to a research insight, not invent a problem the data does not support.
A useful point-of-view form: "[User] needs [need] because [insight/evidence]."
How it fits the pipeline
Problem statements follow research synthesis and clarify what must be solved before ideation begins.
Common mistakes
- Smuggling solutions into the problem ("users need a mobile app")
- Writing problems too broad to guide design ("improve the experience")
- Skipping the people affected and why the problem matters
- Creating problems unsupported by upstream research
Further reading (NN/g)
- — scoping discovery and communicating focus
- — defining needs before generating solutions
- — grounding UX in real user needs
Educational summaries informed by research published by Nielsen Norman Group.
