uiuxdn.in

Product Thinking

How to Frame a UX Problem Before Designing

By Dnyaneshwar N • 6 min read • Published 14 Sep 2026 · Dnyaneshwar N

Learn how to frame a UX problem before opening Figma. A practical process for understanding users, identifying friction, questioning assumptions, and defining the right design problem.

Core Principle

A practical process for understanding users, identifying friction, questioning assumptions, and defining the right design problem.

What Is UX Problem Framing?

UX problem framing is the process of turning a broad symptom, request, or observation into a clearly defined user problem.

> Shift from “What should we design?” toward: “What is preventing the user from accomplishing their goal?”

That distinction matters. If the problem is framed too quickly around a proposed solution, the design process can become focused on improving that solution rather than determining whether it is the right solution in the first place.

For me, good problem framing creates enough clarity to begin exploring possible directions without pretending that every question has already been answered.

Start With the User's Goal

The first question I ask is: What is the user actually trying to accomplish? Not: “What screen are they trying to reach?” Not: “What button should they press?” But: What outcome are they trying to achieve?

For example, imagine a user is struggling with an appointment-booking interface. The product-level description might be: “The user needs to select a time slot.” But their actual goal might be: “I need to confidently find a suitable appointment without disrupting the rest of my day.”

Those statements lead to very different design conversations. The first focuses on the interface. The second introduces availability, confidence, comparison, scheduling context, flexibility, and decision-making. Understanding the goal helps us design around the user's task rather than around the existing interface.

Separate the Symptom From the Problem

One habit I find useful is separating what we can observe from why we think it is happening. Imagine we observe: “Many users leave during a multi-step form.” That is a symptom.

Possible explanations might include:

• The form is too long. • Users do not understand why certain information is required. • They do not have the required information available. • The perceived effort is greater than the expected value. • The sequence of questions feels inappropriate. • Trust drops when sensitive information is requested. • There is a technical problem. • The user realizes the product is not suitable for them.

Those are very different problems. If I immediately redesign the form to look cleaner, I may improve the interface without addressing the reason people leave. This is why the distinction between observation and interpretation is important.

Identify What You Know and What You Are Assuming

UX work contains assumptions. The problem is not that assumptions exist. The problem begins when assumptions quietly turn into facts. I like to separate information into three simple categories:

What we know: Information supported by evidence (research, analytics, usability observations, support conversations, or existing product data).

What we think: A possible explanation based on the information available (for example: “Users may be leaving because they do not understand why this information is required”).

What we need to learn: Questions that need further investigation (for example: At what point does uncertainty increase? What information do users expect before proceeding?).

This separation makes the design process more honest. It also tells us where research or testing can create the most value. For a complete deep-dive into prioritizing beliefs, explore How to Identify and Test Assumptions in UX Design.

Understand the Context Around the Problem

Users do not experience interfaces in isolation. Their environment, knowledge, expectations, previous experiences, device, urgency, and emotional state can all influence the experience.

So I try to ask: • When does this problem happen? • What happened immediately before it? • What does the user already know? • What information are they missing? • What decision are they trying to make? • What happens if they make the wrong decision? • What happens after they complete the task?

Sometimes the most important part of a screen is determined by something that happens two steps earlier or two steps later. Looking at the surrounding journey prevents the design from becoming too locally optimized.

Understand the Constraints

Good UX does not happen without constraints. Real products have business requirements, technical limitations, existing systems, policies, operational processes, accessibility requirements, timelines, data dependencies, and security considerations.

The goal is not to ignore these constraints in the name of an ideal user experience. It is to understand them early enough that they become part of the design problem.

> Which constraints are fixed, and which ones are simply assumptions about what cannot change?

That distinction can open up better solutions.

Ask Whether It Is Actually a UI Problem

Before changing an interface, I try to understand which layer contains the friction. Is this primarily a problem with:

• Information: Users do not have what they need. • Architecture: Information exists but is difficult to find or understand. • Flow: The sequence of steps creates unnecessary friction. • Interaction: Users understand the goal but struggle to operate the interface. • Visual hierarchy: The correct action exists but is difficult to recognize. • Content: The wording creates uncertainty. • Product logic: The underlying rules make the experience difficult. • Trust: Users understand what to do but do not feel confident doing it.

The answer may involve several layers. The point is to diagnose before redesigning. For an in-depth diagnostic guide, read How to Tell If a Problem Is UI or UX.

Turn the Problem Into a Clear Statement

Once I understand the user, goal, barrier, evidence, and context, I try to express the problem simply using a proven structure:

> [User] needs to [goal], but [barrier] makes it difficult because [reason/context].

For example: “First-time users need to understand which plan fits their needs, but comparing the available options is difficult because important differences are distributed across multiple sections.”

This is much more useful than: “The pricing page needs a redesign.” The first statement creates room for multiple solutions; the second already assumes what needs to happen.

Move From Problem to Opportunity

Once the problem is reasonably clear, we can begin asking: “How might we reduce this friction?”

Depending on the problem, the next step might be mapping the journey, exploring alternative flows, reorganizing information, sketching concepts, creating low-fidelity wireframes, testing terminology, prototyping one difficult interaction, or conducting additional research.

The fidelity of the solution should match the certainty we have about the problem. When uncertainty is high, I prefer inexpensive ways of learning.

See how empirical problem framing was applied to boost learner retention in the Learniac Microlearning Case Study.

Problem Framing in the Age of Generative AI

With tools like ChatGPT and Claude capable of generating dozens of interface ideas in seconds, designers face a new temptation: treating AI-assisted ideation as an answer rather than a sounding board.

Generative AI can propose feature sets, generate interview scripts, and write initial microcopy. What it cannot do is validate whether an observed symptom represents a genuine human friction point or an artifact of broken organizational process.

Prompt engineering cannot replace problem discovery. When you prompt an AI with a flawed problem statement like "Design a rewards dashboard to increase retention," the model produces solutions for the wrong goal.

Use AI to identify blind spots in your research synthesis, but retain human ownership over the root cause definition. If the underlying premise is mistaken, AI simply helps you produce the wrong solution faster.

My Simple Problem-Framing Checklist

Before moving deeply into design, I verify these 10 diagnostic questions:

1. Who is experiencing the problem?
2. What are they trying to accomplish?
3. What friction can we actually observe?
4. What do we know with empirical certainty?
5. What are we assuming?
6. What information are we missing?
7. Where in the journey does the problem begin?
8. What business and technical constraints influence the experience?
9. Is this primarily a UI, flow, information, content, trust, or product problem?
10. What would concrete success look like?

Frequently Asked Questions

Key insights into problem framing in day-to-day product teams:

What is problem framing in UX design? Problem framing is the process of clearly defining the user problem before generating solutions. It helps designers understand the user, goal, context, evidence, barriers, assumptions, and constraints surrounding the problem.
Why should UX designers frame the problem before designing? Problem framing reduces the risk of creating a polished solution for the wrong problem. It helps designers explore solutions based on user needs instead of beginning with a predetermined interface.
What makes a good UX problem statement? A useful UX problem statement identifies the user, their goal, the barrier preventing that goal, and relevant context without prescribing a specific solution.
Should designers avoid Figma during problem framing? Not necessarily. Figma, FigJam, sketches, and other tools can support thinking. The important point is not to let polished interface design replace understanding of the underlying problem.

When to Apply

Framing user problems and isolating symptoms from systemic root causes
Validating user assumptions before initiating development cycles
Standardizing UX decision criteria across multi-disciplinary product teams

Recommended Practices

Focus on task outcomes and mental models rather than surface UI cosmetics.
Prioritize assumptions with high uncertainty and high architectural impact.
Test error states and edge cases before declaring an experience ready.

Practices to Avoid

Do not jump into high-fidelity Figma mockups before defining the core problem statement.
Do not confuse visual polish with usable interaction architecture.
Do not rely on subjective opinions when empirical user behaviour is measurable.

Diagnostic Checklist

Is the primary user goal clearly defined?
Have observations been separated from interpretations?
Has the riskiest UX decision been tested?