Problem Statements

Author: Matt Carrano | Last edit: June 20, 2025

What is a problem statement?

A problem statement clearly defines the issue the design aims to address. It should:

• Be concise yet comprehensive.
• Be informed by data or explicitly state assumptions.
• Be actionable and measurable.
• Align with users needs and business goals.

Ideally, problem statements will always be supported by data about user needs coming from discovery research. Where that is not possible (i.e. data is not available) an assumptive  problem statement can be written. The assumptive problem statement is intended to make assumptions explicit so they may be challenged or tested later in the process.

Why are problem statements important?

It is important to have a defined problem statement prior to beginning design work. The problem statement should answer the question of why you are working on a particular design solution and provide criteria to evaluate the result. A problem statement should provide insight into expected user benefit and ensure that product features are aligned with strategic goals.

When should you create a problem statement?

Ideally, a problem statement should be defined before design work begins. Problem statements often are written in collaboration with product management (PM) and can help to make product requirements visible while serving as a written agreement between PM, design, and engineering about what the goals and requirements are for a new product feature before investing in developing solutions.

Best Practices for Creating Problem Statements

The following are some best practices to use to help you write good problem statements.

Keep in mind….

• Ensure problem statements are documented consistently across tools (Figma, Miro, Jira, Google Slides, etc). Focus specifically on the design assets you create and share out and note that Jira is a requirement.
• Collaborate with PMs and engineers to validate and align on problem statements.
• Share your problem statements early and often for feedback and validation.

Problem Statement Framework

A complete problem statement should be structured in a way that clearly explains the issue, why it matters, and how we know it’s a problem. Here is a framework to follow when writing problem statements:

1. Title or Problem Summary
   Keep it concise and descriptive of the issue. 
   • Example (Usability Issue - Existing Product):
     “Users struggle to find the search bar on the homepage.”
   • Example (New Capability - Feature Introduction):
     “Administrators want to easily give asset access only to the right people in their organization.”
     
     
      
2. Context/Background
   Briefly describe the situation, system, or environment where the problem occurs.
   • Example (Usability Issue - Existing Product):
     "Our homepage aims to encourage users to explore content quickly. However, user feedback and analytics reveal that the search functionality is often overlooked.”
   • Example (New Capability - Feature Introduction):
     “Administrators want to easily give asset access only to the right people in their organization.”
     
      
3. Problem Description
   Clearly articulate the problem. 
   • Example (Usability Issue - Existing Product):
     "Users have difficulty locating the search bar due to its placement and lack of visual prominence, leading to decreased usage of the search feature and user frustration.”
   • Example (New Capability - Feature Introduction):
     “Customers lack a way to allocate asset access at a granular level, leading to security concerns and inefficiencies in managing permissions.”
     
      
4. Impact
   Highlight the negative effects of the problem.
   • Example (Usability Issue - Existing Product):
     “This issue results in higher bounce rates, increased time-to-task, and reduced user satisfaction.”
   • Example (New Capability - Feature Introduction):
     “NPS is already decreasing for customers with large, committed spend deals facing complex reporting obligations. Customers experience delays in activation, security risks, and compliance issues due to inadequate access control.”
     
      
5. Evidence
   Provide supporting data, user feedback, or observations.
   • Example (Usability Issue - Existing Product):
     “Heatmaps show low interaction in the search bar area. Surveys indicate that 60% of users did not notice the search bar on their first visit.”
   • Example (New Capability - Feature Introduction):
     “Architects, product managers, and industry experts consider granular access control a standard feature in modern SaaS platforms. (We could link to a value proposition slide deck or industry research here.)”
     
      
6. Goal/Objective
   State what success looks like once the problem is resolved.
   • Example (Usability Issue - Existing Product):
     “Increase search bar visibility and usage by 30% within the next quarter.”
   • Example (New Capability - Feature Introduction):
     “Increase NPS by enabling administrators to allocate access only to intended users, monitor usage and costs, and ensure compliance with organizational policies.”

How much context should be provided?

When working on a story or feature use case, the amount of context depends on the audience:

• For stakeholders and leadership: Provide a high-level overview with business impact (metrics, revenue, compliance, security risks).
• For designers and engineers: Include user research, workflows, and constraints.
• For customers (documentation): Focus on how the feature benefits them and solves pain points.

By ensuring the right level of detail, we can align stakeholders and make problem statements actionable across teams.

Examples of Complete vs. Incomplete Problem Statements

Be clear and specific

State assumptions when data is unavailable

Connect problem statements to user research

Do’s and Don’ts Checklist

Templates for Problem Statements

Using a structured template ensures consistency and clarity in problem statements across the UX team. 

Data-Driven Problem Statement Template

Use this template when you have measurable data from sources such as analytics, usability tests, surveys, or customer support tickets. This template is ideal when there is clear evidence that supports the existence and impact of the problem.

 

Assumption-Based Problem Statement Template

Use this when data is limited or unavailable. This is useful in early-stage explorations, when making hypotheses that require validation, or when working with anecdotal feedback.

 

Problem Statements in Jira

A problem statement should be included in all Jira issues (stories and epics). For guidance on how to include a problem statement in Jira, see the Jira usage guidelines in this document. 

Adding problem statements to design deliverables

To make it easy for consumers of your design to understand the problem statement that you are working to solve, you should always restate the problem as part of your design document. 

Problem statements in Figma

The UXD Figma template includes standard cover slides that include a problem statement. 

Problem statements in Google Slides

Use the UXD Design Share starter template to create a Google Slides presentation for sharing your designs with stakeholders. This template utilizes unique slide layouts for presenting problem statements and annotated screen mockups.

Problem statements in Miro

You can add a problem statement to any Miro board by using the UXD Cover Page template. This template allows you to include a UXD branded cover page within your Miro board. There are two versions of the cover page, one with a data-driven problem statement and another with an assumptive statement. Simply delete the one that does not apply and fill in the information requested within the cover page frame.

Standard Practices for Using Problem Statement Templates

Using the right template helps ensure that problem statements are both appropriate for the stage of work and actionable for the team. Here are some guidelines to help you choose between the Data-Driven and Assumption-Based templates and apply them consistently.

When to Use a Data-Driven Problem Statement

Use this template when you have validated insights from any of the following sources:

• UX research (e.g., usability testing, surveys, interviews).
• Product analytics or telemetry.
• Customer feedback (e.g., support tickets, NPS responses).
• Engineering metrics or performance data.

Best practices:

• Clearly cite the data source in the problem statement.
• Include specific metrics or patterns that highlight the problem.
• Use this type of statement to inform work that is ready for refinement, implementation, or stakeholder alignment.
• Preferred for Epic-level work, feature design, and prioritization discussions.

When to Use an Assumption-Based Problem Statement

Use this template when data is limited, unavailable, or pending validation. These are especially useful in:

• Early exploration or discovery phases.
• Hypothesis-driven design or strategy work.
• New areas of the product where little research has been done.
• Fast-moving projects where a directional statement is needed to move forward.

Best practices:

• Be transparent about the assumption and what it’s based on (e.g., heuristic review, customer anecdote, team expertise).
• Include a plan or intention to validate the assumption with research.
• Clearly flag these for team awareness, especially when sharing with cross-functional stakeholders.

Collaborating with PM and Engineering on Problem Statements

Effective collaboration between UX Designers, PMs, Eng is crucial for aligning on problem statements and crafting solutions that truly address user needs. The list of practices below provides practical strategies for standardizing the collaboration process, helping teams work more efficiently and deliver better and more impactful solutions.

Goals of collaboration

1. Ensure shared understanding of the problem space
2. Align user needs, business objectives, and technical feasibility
3. Get agreed ownership for PM, Eng, and Design.

Standard practices 

1. Ensure you have PM buy-in and involve them early, even before conducting any research.
   
    
2. Come up with a list of questions to ask a PM to gather relevant data they may have about the feature they want us to deliver. This template will guide you in creating a set of standard questions. Click here to make a copy of the Problem Statement Questionnaire template. 
    
3. Review existing documentation, user feedback, and past research to identify key insights and gaps.
    
4. Collaborate with stakeholders, such as professional services, to gain diverse perspectives on the problem. 
    
5. Regularly share research findings and updates with the team through meetings or shared documentation to ensure everyone stays aligned and informed throughout the process.

Examples

The following are examples of well written problem statements.

Data-driven problem statements

Example #1: System Administrators and Platform Engineers struggle with understanding the value of image mode for RHEL. Data from the Image mode Cohort study shows that it took more than 3 hours of exposure to content and interactive labs before the value realization. This impacts Red Hat's goal of a successful RHEL 10 release.

Example #2: RHOAI Admins struggle with being able to manage all resources using distributed workloads. Data from customer conversations referenced in RHOAIRFE-410 shows customers struggle with inconsistencies in managing resources that aren't enabled inside Kueue. This impacts the ability for customers to use expensive GPU and CPU resources efficiently.

Why these work…

These statements identify who the target user is, the problem or situation that they face, and references specific data where that data came from. Finally, they include the expected impact if this problem is not addressed.

Assumptive problem statement

Example #1: Anisble users are likely to have a disjointed automation experience. This assumption is based on knowledge of the current workflow where users begin their automation workflow with Terraform to configure infrastructure and then use AAP to execute automation with that infrastructure. 

Why this works…

This statements identify who the target user is, and the problem or situation that they face. Unlike for the data-driven problem statement, it acknowledges that that this is based on an assumption rather than hard data, but does explicitly state what that assumption is.

Get in Touch!

Spotted a typo? Any feedback you want to share? Do you want to collaborate? Get in touch with the UXD Methods working group using one of the links below!

Drop us a message on the #uxd-hub Slack channel

Submit Feedback