{"site":{"name":"Koji","description":"AI-native customer research platform that helps teams conduct, analyze, and synthesize customer interviews at scale.","url":"https://www.koji.so","contentTypes":["blog","documentation"],"lastUpdated":"2026-04-25T23:56:52.780Z"},"content":[{"type":"documentation","id":"253d19e8-2c71-4955-a703-87543e5e0fe3","slug":"problem-statement-ux-research","title":"How to Write a UX Problem Statement: Templates, Examples, and Best Practices","url":"https://www.koji.so/docs/problem-statement-ux-research","summary":"A UX problem statement is a concise, user-centered description of the challenge a design team is solving — written without prescribing solutions. The standard format is \"[User] needs [need] in order to [goal].\" Strong problem statements are grounded in user research, specific, and solution-free. Fixing a product post-launch costs 100x more than defining the right problem upfront.","content":"\n## The Quick Answer\n\nA UX problem statement is a concise, user-centered description of the challenge your team is trying to solve — written in a way that guides design decisions without prescribing solutions. The standard format is: **\"[User] needs [need] in order to accomplish [goal].\"** Problem statements must be grounded in user research, specific enough to guide ideation, and free of assumed solutions. The cost of skipping good problem definition is steep: fixing a product after launch costs **100x more** than getting the definition right upfront — and research consistently shows that building the wrong thing is the primary driver of product failure.\n\n## What Is a UX Problem Statement?\n\nA UX problem statement defines the user need your team is addressing, the context in which that need arises, and the impact of not addressing it. It is the bridge between user research findings and design decisions.\n\nMore importantly, a good problem statement defines what you are *not* solving. Every time a team works from a vague or solution-biased brief, they build something that addresses a symptom or a hypothesis rather than a real user need. Don Norman — one of the most influential voices in UX and co-founder of the Nielsen Norman Group — put it directly: *\"A brilliant solution to the wrong problem can be worse than no solution at all: solve the correct problem.\"*\n\nProblem statements are not just useful for UX designers. Product managers use them to align roadmaps. Engineering teams use them to understand scope. Stakeholders use them to evaluate whether proposed solutions actually address what users need. A well-written problem statement is often the most-shared document a product team produces — and the one most often written carelessly.\n\n## Why Problem Statements Matter: The Cost of Getting It Wrong\n\nProduct teams make an assumption that feels reasonable: we are close enough to our users that we know what problems to solve. The data says otherwise.\n\nResearch consistently shows that a primary cause of product failure is launching products that solve the wrong problem — products that do not fulfill real user needs or address genuine pain points. Customer validation often happens at the end of the design-development cycle, after significant investment. By then, discovering a fundamental mismatch between the assumed problem and the real one is catastrophic.\n\nDon Norman described the right approach: *\"Good designers never start by trying to solve the problem given to them: they start by trying to understand what the real issues are. As a result, rather than converge upon a solution, they diverge, studying people and what they are trying to accomplish, generating idea after idea.\"*\n\nThe economics of early problem definition are stark. Fixing a product after launch costs **100x more** than addressing the problem during discovery. That asymmetry makes problem statement quality one of the highest-leverage investments a team can make.\n\n## The Three Standard Formats\n\n### 1. The POV Statement (Point of View)\n\nThe POV statement, developed as part of the Stanford d.school design thinking methodology, combines three essential elements into a user-centric problem definition:\n\n- **User:** The specific person or persona experiencing the problem\n- **Need:** What they require or want to accomplish\n- **Insight:** Why they have this need — the deeper understanding drawn from research\n\n**Template:** *\"[User] needs [need] in order to [goal/insight].\"*\n\n**Example:** \"A first-time parent expecting their second child needs to set up a college savings account because they want to plan for their children's future education but are overwhelmed by the number of options and do not know where to start.\"\n\nNotice what this statement does: it names a specific user, a specific need, and a specific context derived from research. That context — the overwhelm and uncertainty — is what transforms a generic problem into a specific design brief.\n\n### 2. The How Might We (HMW) Question\n\nHMW questions — popularized by IDEO and described authoritatively by Nielsen Norman Group — transform problem statements into design opportunities by posing them as open questions.\n\n**Template:** *\"How might we [intended experience] for [user] so that [desired outcome]?\"*\n\n**Example (from the POV above):** \"How might we make it effortless for new parents to set up a college savings plan so they feel confident they have done the right thing for their children?\"\n\nHMW questions are divergent by nature — they invite multiple solutions rather than prescribing one. The best HMW questions are specific enough to be actionable and open enough to allow creative exploration. A useful test: if the HMW question has only one obvious answer, it is too narrow.\n\n### 3. The Job Story Format (Jobs to Be Done)\n\nJob Stories — used in the Jobs to Be Done framework — frame the problem from the user's perspective as a job they are trying to accomplish:\n\n**Template:** *\"When [situation], I want to [motivation], so I can [expected outcome].\"*\n\n**Example:** \"When I am planning my budget for the next school year, I want to quickly see how much I have saved and how it compares to my target, so I can decide whether to increase my monthly contribution.\"\n\nJob Stories are particularly useful for B2B product teams and for capturing functional motivations. They make the user's goal explicit in a way that directly informs feature decisions.\n\n## How to Write a Problem Statement: Step by Step\n\n### Step 1: Conduct Research First\n\nThis is non-negotiable. A problem statement written without research is a hypothesis dressed up as insight. Pre-definition research includes:\n\n- User interviews — discovery-stage conversations about how users currently handle the problem space\n- Observational research — watching users in context to capture actual behavior, not self-report\n- Quantitative data — what is happening in your product (though not why)\n- Secondary research — what is already known about this domain and adjacent problems\n\nDo not write the problem statement until you have spoken with at least 5–8 people who experience the problem. Don Norman advocated for using \"the Five Whys approach to get at root causes\" — asking why repeatedly until you reach the fundamental issue rather than surface symptoms.\n\n### Step 2: Extract Findings\n\nSynthesize your research into discrete findings — specific observations from specific participants. Keep findings at the level of what you heard and saw, not what you concluded.\n\n*Finding:* \"Three of seven participants could not locate the settings menu during their first session.\"\n\n*Not a finding (this is already an insight):* \"The navigation architecture does not match users' mental models.\"\n\n### Step 3: Generate Insights\n\nInsights move from *what* to *why*. They explain the cause behind a pattern of findings.\n\n*Insight:* \"Users expect settings to be accessible from the main navigation, not buried in their profile — because they associate settings with product features, not personal preferences.\"\n\nGood insights are surprising (they contradict an assumption) or clarifying (they explain something previously mysterious). Nielsen Norman Group describes insights as \"the why behind a finding.\"\n\n### Step 4: Write the Problem Statement\n\nUse your insights to write the problem statement. Apply the POV template:\n\n*\"[User] needs [need] in order to [insight/goal].\"*\n\nWrite 3–5 draft versions and test each against these criteria:\n\n- **User-centered:** Does it describe the problem from the user's perspective, not the business's?\n- **Solution-free:** Does it avoid specifying what the solution should be?\n- **Research-backed:** Is it derived from what you learned, not assumed beforehand?\n- **Specific:** Is it narrow enough to guide design decisions?\n- **Actionable:** Could a designer use this to generate diverse solution ideas?\n\n### Step 5: Generate HMW Questions\n\nOnce you have a problem statement you are confident in, convert it into 3–5 HMW questions to open ideation. HMW questions should all flow from the same underlying problem statement but approach it from different angles:\n\n- \"How might we make the settings location discoverable in under 10 seconds?\"\n- \"How might we design navigation that matches how users think about their account versus the product?\"\n- \"How might we reduce cognitive load when users need to move between personal preferences and product features?\"\n\n### Step 6: Validate the Problem Statement\n\nBefore investing in solution development, validate the problem statement with stakeholders (\"does this feel like the right problem to solve?\") and with users who participated in your research (\"if we fixed this, would it make a meaningful difference for you?\"). A problem statement that passes both checks is ready to drive ideation.\n\n## Good vs. Bad Problem Statements\n\n### Examples of Strong Problem Statements\n\n**Strong:** \"Young professionals using our budgeting app struggle to track daily expenses because of a cluttered interface, leading to frustration and a 30% drop in engagement within a week.\"\n- Specific user ✓ | Specific problem ✓ | Quantified impact ✓ | No solution implied ✓\n\n**Strong:** \"Online shoppers struggle to compare products efficiently when browsing on mobile, which leads to frustration and cart abandonment.\"\n- Clear context ✓ | Observable behavior ✓ | Business-relevant outcome ✓\n\n**Strong:** \"Busy professionals find it difficult to reorder their previous meals quickly, causing delays and reducing repeat purchases.\"\n- Persona clear ✓ | Problem observable ✓ | Impact measurable ✓\n\n### Examples of Weak Problem Statements\n\n**Weak:** \"We need to add a comparison feature.\"\n- This is a solution, not a problem. There is no user perspective and no context for why this is needed. ❌\n\n**Weak:** \"Users do not like the app.\"\n- Too vague to be actionable. No specific problem identified. ❌\n\n**Weak:** \"Sales are low.\"\n- A business metric, not a user problem. Does not identify what users are actually experiencing. ❌\n\n**Weak:** \"We need a better mobile experience.\"\n- No specific user, no specific problem, no actionable direction. ❌\n\n## Common Mistakes and How to Avoid Them\n\n### Writing Solution Statements Disguised as Problem Statements\n\n\"Users need a faster checkout\" sounds like a problem statement but is actually a solution. The real problem might be: \"Users abandon checkout when they have to re-enter payment details that were saved previously.\" Faster checkout is one potential solution; seamless data recall is another. A good problem statement should make multiple solutions visible, not prescribe one.\n\n**Fix:** Ask \"what makes that needed?\" until you cannot answer with another \"because.\" That is your problem statement.\n\n### Being Too Broad\n\n\"Users struggle to manage their work\" is true of everyone, everywhere, always. It is not actionable for any specific design decision.\n\n**Fix:** Add specificity: which users, in which context, doing which tasks, experiencing which failures.\n\n### Being Too Narrow\n\n\"Users aged 35–45 in the Pacific Northwest who use our iOS app cannot find the settings gear icon when using dark mode at night\" is a bug report, not a problem statement. It implies a fix (change the icon) and describes a symptom, not a user need.\n\n**Fix:** Ask \"what need is failing to be met?\" and write to that level of abstraction.\n\n### Confusing Findings with Problem Statements\n\nA finding is what you observed: \"Six participants tried clicking on the product image before the Add to Cart button.\" A problem statement is what that finding reveals: \"Users expect the product image to be the primary purchase trigger, but our call-to-action hierarchy does not match that mental model.\"\n\n### Writing Problem Statements from Stakeholder Assumptions\n\nThe most common source of bad problem statements is senior stakeholders who \"already know\" what the problem is. Problem statements written without research often turn out to be perfectly worded descriptions of internal assumptions — not user realities.\n\n**Fix:** Make the research source explicit. \"Based on 12 user interviews conducted in March 2026\" signals that the statement is grounded, not assumed. Stakeholders who see the evidence are more willing to update their assumptions.\n\n## How Koji Accelerates Problem Definition\n\nThe research step is the bottleneck in good problem statement writing. Without enough research, you are guessing. Without enough time, you are skipping.\n\nKoji dramatically shortens the time between \"we need to understand this problem\" and \"we have the research to write a solid problem statement.\"\n\nSet up a discovery study in Koji, write your open-ended research questions, and distribute the link to your users. Koji's AI interviewer conducts the conversations — probing follow-up questions automatically, capturing voice or text responses, and synthesizing findings into themes in the resulting report.\n\nKoji's [6 structured question types](/docs/structured-questions-guide) let you mix formats in a single session: a yes/no question to segment participants, a scale question to calibrate severity, an open-ended probe to capture context and motivation, a single_choice question to understand which dimensions of the problem are most painful. The resulting report surfaces quotes, themes, and patterns — the raw material you need to move from data to insight to problem statement.\n\nWhat used to take two weeks of scheduling, conducting, transcribing, and analyzing can happen in two days. That changes how early you can write a good problem statement — and how confident you can be when you do. While traditional tools like SurveyMonkey or Qualtrics give you data about what users think, Koji's AI-moderated interviews give you the qualitative depth to understand *why* — the essential foundation for any meaningful problem statement.\n\n## Writing Problem Statements for Different Research Methodologies\n\n**Mom Test research:** Frame around past behavior, not future hypotheses. \"Users who handle [specific task] currently spend [time/effort] on [workaround], indicating that [unmet need].\"\n\n**Jobs to Be Done:** \"When [users experience situation X], they need to [accomplish job Y] because current alternatives require [painful workaround] and fail when [specific condition].\"\n\n**Customer discovery:** \"Early adopters in [market segment] need a way to [solve problem X] because existing solutions require [painful workaround] and fail when [specific condition].\"\n\n**Ongoing product research:** \"Users who have been with us for [timeframe] struggle to [accomplish workflow Y] because the product assumes [assumption that no longer holds].\"\n\n## Summary: The Foundation Every Design Decision Builds On\n\nA UX problem statement is not a deliverable. It is a foundation — the thing every design decision, feature prioritization call, and roadmap item builds on. Write it poorly, and everything downstream is misaligned. Write it well, grounded in real research with real users, and you have a north star clear enough to navigate even the most complex product decisions.\n\nDon Norman's warning bears repeating: *\"Solve the correct problem.\"* Every tool, framework, and methodology in UX research exists ultimately to help teams do exactly that. A well-researched, clearly written problem statement is the most direct path there.\n\n---\n\n## Related Resources\n\n- [Structured Questions in AI Interviews](/docs/structured-questions-guide)\n- [Customer Discovery Interviews: The Complete Guide](/docs/customer-discovery-interviews)\n- [Research Brief Template: How to Define Your Research Before You Start](/docs/research-brief-template)\n- [How to Write Research Insight Statements That Drive Action](/docs/writing-insight-statements)\n- [Assumption Testing: How to Validate Product Assumptions Before You Build](/docs/assumption-testing-guide)\n- [Double Diamond Design Process: The Research-Driven Framework](/docs/double-diamond-design-process)\n","category":"Research Methods","lastModified":"2026-04-25T19:14:08.521275+00:00","metaTitle":"How to Write a UX Problem Statement: Templates, Examples, Best Practices | Koji","metaDescription":"Learn how to write UX problem statements that guide great design decisions. Includes POV, HMW, and Job Story formats, step-by-step process, good vs. bad examples, and how Koji accelerates the research behind every problem statement.","keywords":["ux problem statement","how to write a problem statement","problem statement ux","ux problem statement examples","how might we questions","point of view statement ux","design problem statement"],"aiSummary":"A UX problem statement is a concise, user-centered description of the challenge a design team is solving — written without prescribing solutions. The standard format is \"[User] needs [need] in order to [goal].\" Strong problem statements are grounded in user research, specific, and solution-free. Fixing a product post-launch costs 100x more than defining the right problem upfront.","aiPrerequisites":["Basic familiarity with user research methods","Understanding of user interviews or qualitative research"],"aiLearningOutcomes":["Write UX problem statements using the POV, HMW, and Job Story formats","Move from research findings to insights to problem statements","Identify and avoid common mistakes like solution-biased statements","Use research to validate problem statements before investing in solutions"],"aiDifficulty":"beginner","aiEstimatedTime":"13 minutes"}],"pagination":{"total":1,"returned":1,"offset":0}}