What is a problem statement in UX?
A problem statement in UX is a short, clear description of the user problem a team wants to solve, who has it and why it matters, written before design.
also calleddesign problem statement · point-of-view statement · challenge statement
Teams rarely fail because they design badly. They fail because they design something good for a problem nobody had. A problem statement is the sentence or two that pins down what you are really trying to fix, so the rest of the project has something to aim at.
- A problem statement names who has the problem, what they need and what stands in the way.
- It describes the problem, not the solution.
- Base it on research evidence and revise it as you learn.
- Aim for a statement that is broad enough for options and narrow enough to act on.
What a good one contains
A useful statement answers three questions without drifting into solutions. Who is affected? What are they trying to do or need? What gets in their way, and why does it matter?
A common template reads: "[User] needs a way to [goal] because [insight about the obstacle]." It is a bit stiff, but it forces you to name a real person and a real reason. Many teams then reshape it into natural language once the thinking is done.
Problem versus solution
The sneakiest failure is a statement that smuggles in the answer. "Users need a chatbot to find help" is not a problem, it is a feature in disguise. The problem might be that people cannot find the return policy, which could be solved by a chatbot, a better menu or a clearer page.
To catch this, look for nouns that name a product or interface. If you see an app, button or dashboard, ask what human difficulty sits behind it, and write that instead.
How to write one in practice
Start from research, not from a hunch. Pull together interview notes, support tickets and observations. Then work through a few steps:
- Group findings into themes and pick the one that hurts most.
- Name the specific user group, not "everyone".
- Draft the statement in one or two sentences.
- Check it against the evidence: could a teammate point to real data behind each claim?
- Test its size: broad enough to allow several solutions, narrow enough to act on.
- Rewrite it with the team until everyone nods for the same reason.
Common mistakes
Too broad is one: "Improve the customer experience" gives no direction. Too narrow is the other: "The button should be blue" has already decided. Watch also for statements built on assumptions, like "Busy parents don't care about price", with no evidence.
Another subtle trap is writing it once and filing it away. As research teaches you more, a statement may need to change. That is a sign of learning, not of failure.
How it shapes what follows
A strong statement becomes a compass. It feeds brainstorming prompts like "How might we...", helps prioritize features and gives you a plain test for scope arguments: does this serve the problem or not?
It also helps with stakeholders. Showing them a crisp statement backed by evidence makes it much easier to agree on direction before pixels are pushed.
Problem statement: your questions, answered
What is a problem statement in UX design?
It is a concise description of a specific user problem the team intends to solve. It identifies the user, their need or goal and the obstacle, based on research, so that design work stays focused on a real issue instead of assumptions.
How do you write a good UX problem statement?
Start with research findings, pick the most important theme and describe the user, their goal and the obstacle in one or two sentences. Avoid naming a solution, check each claim against evidence and refine it with your team.
What is the difference between a problem statement and a hypothesis?
A problem statement describes what is wrong for users. A hypothesis is a testable guess about how a change will fix it, such as "If we add size guidance, returns will drop". The statement comes first and guides which hypotheses you form.
How long should a problem statement be?
Usually one to three sentences. If it needs a paragraph, the problem is probably too broad or mixed. A short statement is easier to remember, share and use as a test when decisions come up.
When in the design process do you write it?
After you have done enough research to understand the situation and before you start generating ideas. It sits between discovery and ideation, and you can revise it as new findings come in.
More quick answers
What is a point-of-view statement?
It is a design thinking version of a problem statement that frames a user, their need and an insight. It leads into brainstorming.
What is an example of a UX problem statement?
"New freelancers struggle to price their first project because they have no benchmark, so they undercharge and feel anxious." It names a user, a need and a cause.
What comes after a problem statement?
Usually ideation. Many teams turn the statement into "How might we" questions to open up possible solutions.
Who writes the problem statement?
It is often a team effort led by a designer or researcher, with input from product and stakeholders, so everyone shares the same view.
Is a problem statement the same as a project brief?
No. A brief covers goals, scope, timeline and constraints. The problem statement is one focused part that defines the user problem itself.
How Might We (HMW) in UX is a way of phrasing a problem as an open question, such as "How might we help new users get started?", to spark ideas.
Design thinking in UX is a problem-solving approach that starts with understanding people, then defines the problem, generates ideas, and tests prototypes.
Ideation in UX is the stage of the design process where a team generates and explores many possible solutions to a clearly defined user problem.
User research in UX is the practice of studying people who use or might use a product, to understand their needs and behavior so design rests on evidence.
Pain points in UX are the specific problems, frustrations or obstacles that users run into when trying to reach their goals with a product or service.
A persona in UX is a fictional but research-based profile of a typical user, describing their goals, habits and frustrations to keep design decisions grounded.
Found this useful? A GitHub star helps other designers find it.