Writing Problem Statements Ux

The Foundation of User-Centered Design

Every successful digital product begins with a clear understanding of the problem it solves. Problem statements are the cornerstone of user-centered design, providing a focused description of the user challenge that design teams need to address. Unlike solutions-focused documentation, problem statements remain anchored in user needs, context, and impact--serving as a north star throughout the design process.

A well-crafted problem statement accomplishes several critical objectives. It crystallizes research findings into a concise articulation of user needs, aligns cross-functional teams around a shared understanding of what success looks like, and provides a decision-making framework for evaluating potential solutions. When teams have clarity on the problem they're solving, they generate more focused, innovative solutions that directly address user needs.

The problem statement represents the transition from research (Empathize stage) to solution development (Ideate stage) within the Design Thinking framework. This positioning makes it one of the most consequential artifacts in the UX design process--a poorly defined problem leads to misaligned solutions, while a precisely articulated problem sets the entire team up for success.

Beyond aligning teams internally, problem statements serve as powerful communication tools with stakeholders and investors. When you can clearly articulate the problem your product solves, why it matters to users, and what success looks like, you build confidence in your product strategy and secure the resources needed for development. This external communication function makes problem statements valuable beyond the immediate design team, influencing product roadmaps and organizational priorities.

Why Problem Statements Matter

Products created for a specific purpose are more likely to appeal to target audiences than those developed without clear direction. A strong problem statement ensures every design decision connects back to genuine user needs rather than assumptions or organizational preferences. This alignment between user needs and product development creates products that resonate with their intended audience and achieve business objectives simultaneously. When your team understands the user needs you're addressing, every subsequent decision becomes more focused and effective.

The Anatomy of an Effective Problem Statement

Core Framework and Structure

A problem statement follows a fundamental framework that captures the essential elements of a user challenge: who is affected, what the problem is, where or when it occurs, and why it matters. The classic template reads:

[User A] experiences [this problem] when they [try to complete this action] in [context]. This is a problem because [impact on user and business].

This structure ensures that every problem statement includes four critical components. First, it identifies the specific user segment experiencing the challenge--not generic "users" but a defined group with particular characteristics and contexts. Second, it articulates the precise problem in concrete terms, avoiding vague descriptions that could apply to multiple situations. Third, it establishes the context or scenario where the problem manifests, which helps teams design contextually appropriate solutions. Fourth, it explains the impact--why solving this problem matters to users and, by extension, to the business.

Practical Example

Consider this example: "Busy professionals experience difficulty tracking their daily nutrition intake when using mobile apps during their commute because current solutions require too much manual input and time commitment. This leads to abandoned tracking and missed health goals."

Notice how this statement identifies a specific user segment (busy professionals), describes a concrete problem (difficulty tracking during commute), establishes context (mobile app use during commute), and explains impact (abandonment and missed goals)--all within a few sentences.

What Problem Statements Are Not

Understanding what problem statements should not contain is equally important as knowing what they should include. A problem statement does not suggest solutions--that work belongs to later stages of the design process. Premature solution thinking narrows creative exploration and may lead teams to build features that don't address the root problem.

Problem statements also avoid organizational preferences, technical constraints, and business assumptions unless those directly relate to user impact. The focus remains firmly on user needs and challenges, not on what the company wants to build or how it wants to build it. This discipline ensures your problem statement remains a pure definition of the challenge, leaving solution space open for creative exploration during ideation phases.

When to Create Problem Statements

Timing Within the Design Thinking Process

Problem statements are created during the Define stage of Design Thinking, which follows the Empathize stage where research occurs. This sequence matters because problem statements should synthesize research findings, not guess at user needs. Teams first observe and engage with users to understand their experiences, then articulate the core challenges those users face.

Creating problem statements too early--before adequate research--leads to assumptions dressed up as facts. Creating them too late--after ideation has already begun--means solutions may not address the actual problem. The Define stage serves as a critical checkpoint: have we understood the problem correctly before we start generating solutions?

The Research Foundation

Before writing a problem statement, teams should have completed substantial user research including interviews, observations, and data analysis. This research provides the evidence base that validates each component of the problem statement. Without this foundation, problem statements become hypotheses rather than insights, and solutions based on them address guessed-at problems rather than real ones.

The research should reveal patterns across multiple users--isolated incidents rarely justify a product investment. Problem statements should articulate challenges that a meaningful user segment faces repeatedly, not one-time frustrations that users have already found workarounds for. This requirement for pattern identification is why A/B testing and research validation play crucial roles in confirming problem statements before solution development begins.

Methods for Writing Problem Statements

Method 1: The Five Ws Technique

The Five Ws technique provides a systematic approach to gathering the information needed for a comprehensive problem statement. This method asks five questions about the problem:

Who does the problem affect? This identifies the target user segment with sufficient specificity that design decisions can be tailored to their characteristics, context, and capabilities.

What is the specific problem your target audience is experiencing? This requires precision--moving from "users have trouble" to "users cannot complete X task within Y time frame."

Where does your target audience typically experience this problem and where will they primarily use your solution? Context shapes solutions; a problem experienced during mobile commutes requires different solutions than one experienced at a desk.

Why is finding a solution to this particular problem important to your target audience? Understanding the stakes helps prioritize problems and communicate value to stakeholders.

When does the problem occur? Temporal context--including triggers and frequency--provides important design inputs.

Answering these questions with research-backed evidence creates a comprehensive foundation for writing the problem statement itself.

Method 2: The Five Whys Technique

The Five Whys technique digs deeper than surface-level problem descriptions to uncover root causes. This method works by asking "why" repeatedly, with each answer becoming the basis for the next question.

For example, if the initial problem is "users abandon their shopping carts," the first "why" might reveal "checkout takes too long." The second "why" might show "users must create accounts before purchasing." The third "why" might indicate "the company prioritizes email marketing over conversion." The fourth "why" might expose "there is no alternative login method." The fifth "why" might uncover "the original team didn't consider guest checkout important."

This progressive questioning reveals that the real problem isn't checkout speed--it's a policy decision that creates unnecessary friction. Solutions based on the surface problem (faster checkout) miss the mark compared to solutions addressing the root cause (eliminating mandatory account creation).

Method 3: Fill-in-the-Blank Template

For teams seeking simplicity or working under time constraints, the fill-in-the-blank method provides a quick path to a functional problem statement. This approach identifies three specific pieces of information and inserts them into a sentence template:

[A user] needs [need] in order to accomplish [goal].

For instance: "A fitness enthusiast needs quick and easy food logging because they want to maintain their nutrition tracking habit during busy workdays without disrupting their workflow."

This method typically produces a more basic problem statement than the Five Ws or Five Whys techniques, making it ideal for early-stage exploration or when problem scope is intentionally broad. However, it provides a helpful starting point that teams can refine using the other methods as needed.

Best Practices for Problem Statements

Frame as Questions

Problem statements that begin with "How might we..." or similar question structures encourage creative solution generation. Questions signal opportunity rather than constraint, inviting teams to explore multiple approaches rather than converging prematurely on a single solution.

Compare these two approaches: "The problem is that users can't find products" versus "How might we help users find products more easily?" The question format is open-ended and generative; the statement format is closed and limiting. Throughout ideation, the question format keeps options on the table while the statement format implicitly asks "have we solved it yet?"

Be Specific (Counterintuitively)

Highly specific problem statements generate more solutions, not fewer. Vague problems like "improve the checkout experience" leave teams unsure where to focus. Specific problems like "reduce time-to-purchase for returning customers who know exactly what they want" provide clear boundaries that channel creative energy productively.

Specificity also makes success measurable. "Make checkout faster" leaves success undefined. "Reduce checkout completion time from 4 minutes to under 2 minutes for returning customers" establishes a clear target that teams can work toward and evaluate against.

Use Strong, Actionable Language

Problem statements benefit from active verbs that convey intent and direction. "How might we help users..." or "How might we enable users..." or "How might we provide users..." all communicate purposeful action. Weak language like "How might we consider helping users..." signals uncertainty and dilutes focus.

Strong verbs also prevent scope creep. When problem statements use precise action words, they define boundaries that help teams resist the temptation to add features that don't directly address the core problem.

Keep It Visible

Write problem statements on large sheets of paper and display them prominently in workspaces. This constant visibility keeps teams aligned as projects progress and decisions become more complex. When new feature requests emerge or scope discussions arise, teams can reference the problem statement to evaluate whether proposed changes maintain focus on user needs.

Problem statements should be living documents--not carved in stone. As research deepens and understanding evolves, problem statements may be refined. But significant changes should prompt reconsideration: have you learned something new that fundamentally changes the problem we're solving?

Collaborate Across Disciplines

Problem definition benefits from diverse perspectives. Engineers bring technical constraints to light, designers contribute interaction expertise, product managers add business context, and researchers contribute user insights. A problem statement developed collaboratively reflects multiple valid viewpoints rather than a single perspective.

Collaborative problem definition also builds shared ownership of solutions. When team members participate in articulating the problem, they feel invested in solving it well. This ownership translates to better solutions and smoother execution throughout the product development lifecycle.

Common Mistakes to Avoid

Solving the Wrong Problem

The most dangerous problem statement error is defining the wrong problem. Teams may invest significant resources solving surface problems while root causes remain unaddressed. The Five Whys technique specifically guards against this mistake by forcing teams to dig deeper than initial observations.

Including Solutions Prematurely

Problem statements that hint at preferred solutions constrain ideation before it begins. If a problem statement reads "users need a better search feature," teams are directed toward search improvements even when the real problem might be better solved through navigation redesign or content organization.

Overly Narrow Scope

While specificity is valuable, overly narrow problem statements limit exploration unnecessarily. Problems should be specific enough to guide focused ideation but broad enough to allow creative freedom. Finding this balance comes with practice and feedback.

Ignoring Business Context

Problem statements focused solely on user needs without considering business viability create tension between design goals and organizational objectives. The best problem statements acknowledge both user impact and business implications, creating alignment across stakeholders. This balanced approach ensures that solutions emerging from ideation address genuine user needs while remaining feasible for the organization to implement.

Practical Examples

Example 1: E-Commerce Application

Problem Statement: "First-time online shoppers experience uncertainty about product quality when browsing because they cannot see physical products before purchase. This leads to high cart abandonment and returns for items that don't meet expectations."

This statement identifies a specific user segment (first-time shoppers), articulates the core challenge (uncertainty about quality without physical inspection), establishes context (browsing behavior), and explains impact (abandonment and returns). The solution space remains open--teams might address this through better imagery, reviews integration, sizing tools, or flexible return policies.

Example 2: Healthcare Portal

Problem Statement: "Elderly patients managing multiple chronic conditions struggle to understand their medication schedules when using patient portals because information is scattered across multiple screens and uses technical terminology. This results in missed doses and poorer health outcomes."

This statement demonstrates specificity about user characteristics (elderly, managing multiple conditions), the precise problem (scattered information, technical language), and measurable impact (missed doses, health outcomes). The context (patient portal use) shapes potential solutions toward interface improvements and plain language communication.

Example 3: Productivity Application

Problem Statement: "Knowledge workers experience difficulty capturing ideas during meetings because existing note-taking tools require too much context-switching between conversation and documentation. This results in incomplete notes and missed action items."

The specificity here--knowledge workers, meeting context, context-switching friction--provides clear direction for solution exploration. Solutions might include voice recording integration, AI-powered summarization, or meeting-specific capture interfaces. The problem statement rules out solutions unrelated to meeting capture efficiency.

From Problem Statement to Solution

Transitioning to Ideation

Once a problem statement is established and validated, teams move into the Ideation stage where solution generation begins. The problem statement serves as criteria for evaluating ideas: does this solution address the identified problem for the identified users in the identified context?

"How might we" phrasing makes this transition natural. Each solution concept can be tested against the question: "Does this help [user] achieve [goal] by addressing [problem]?" Solutions that don't connect clearly to the problem statement should be reconsidered or set aside.

Maintaining Focus Throughout Development

As projects progress from concept through design to implementation, problem statements help maintain focus. When feature requests emerge, stakeholder preferences shift, or technical challenges arise, teams can reference the problem statement to evaluate whether proposed changes maintain alignment with user needs.

The problem statement also guides trade-off decisions. When optimization in one area might compromise another, the problem statement provides a lens for evaluating which path better serves users. This consistency throughout development creates products that remain true to their original purpose and deliver meaningful value to the users they were designed to serve.

Sources

• UX Design Institute: Problem Statement in UX - Definition and Examples
• Future Processing: How to Create and Effectively Use UX Problem Statement
• thoughtbot: Writing Effective Problem Statements
• Dovetail: Problem Statements in UX - How to Create One