Ehab Fayez Webflow Premium Partner
Book a Call
Back to Learning Path
UX Phase 1 — Discovery & Understanding

Problem Solving in UX

March 2, 2026 · 13 min read

If you ask any successful UX designer "what do you do?", the answer will not be "I design beautiful screens." The answer will be: "I solve problems."

Design at its core is problem solving. Every screen you design, every button you place, every flow you build — that is a solution to some problem the user has. But the real challenge is: how do you identify the right problem?

Albert Einstein famously said:

"If I had an hour to solve a problem, I would spend 55 minutes thinking about the problem and 5 minutes thinking about the solution."

In this article, we will learn the most important frameworks and methodologies that help you identify the problem correctly and arrive at effective solutions.

Why Is Defining the Problem More Important Than the Solution?

The most common mistake in design is jumping to the solution immediately:

  • Client: "I want a Chatbot button on the website"
  • Junior designer: starts designing the Chatbot
  • Senior designer: asks "Why? What problem are you solving?"

They might discover that the real problem is that the FAQ page is not organized and nobody can find anything in it. The solution is not a Chatbot — the solution is reorganizing the content.

The rule: if you solve the wrong problem correctly, you still wasted your time. But if you define the right problem, even a modest solution will be better.

The Jobs to be Done (JTBD) Framework

The Idea

Instead of asking "who is the user?", ask: "What is the Job the user is trying to accomplish?"

Clayton Christensen — a professor at Harvard — developed this framework. His famous example about the milkshake:

A fast food chain wanted to sell more milkshakes. They did traditional market research: "Want it thicker? Sweeter? Cheaper?" They changed the recipe several times and sales did not increase.

Then researchers came and asked a different question: "What is the Job the milkshake does in the customer's life?"

They discovered something surprising: most sales were in the morning. People were buying milkshakes on their way to work. The Job is not "I want something sweet" — the Job is "I want something to keep me occupied during the long commute, fill my stomach, and one hand is enough."

The real competitor to the milkshake was not ice cream or juice — it was bananas, bagels, and boredom.

How to Use It in UX

The Job Statement formula:

When [situation], I want [motivation] so that [desired outcome]

Example: "When I am on public transit and bored, I want to read something useful so that I feel I made good use of my time."

Steps:

  1. Observe users in their natural context
  2. Ask: "What were you trying to do?" (not "what do you think of the product?")
  3. Identify the core Job and the social and emotional functions associated with it
  4. Design a solution that accomplishes the Job better than current alternatives

The 5 Whys Technique

The Idea

A very simple and very powerful technique: ask "why" 5 times to reach the root cause of the problem. Developed by Sakichi Toyoda, founder of Toyota.

Practical Example

The apparent problem: users are not completing the purchase process.

  1. Why are they not completing it? → Because they abandon the payment page
  2. Why do they abandon the payment page? → Because they are surprised by shipping costs
  3. Why are they surprised? → Because shipping costs only appear in the last step
  4. Why do they not appear earlier? → Because the team felt showing them earlier would scare customers
  5. Why would that scare them? → Because shipping costs are high compared to competitors

The root cause is not in the design — it is in shipping pricing. The design solution (showing costs earlier) is important, but the real solution is reviewing the shipping policy.

Tips for Use

  • Does not have to be exactly 5 — sometimes 3 is enough and sometimes you need 7
  • Can branch: each "why" can have more than one answer
  • Get the whole team involved: each person might see the cause from a different angle
  • Focus on processes, not people: "why does the process allow this" is better than "who is at fault"

The How Might We (HMW) Framework

The Idea

After you have identified the problem, "How Might We" turns it into an open creative question. The formula:

"How might we... [action]... so that [goal]?"

Why This Formula Is Powerful

  • "How": assumes there is a solution — opens the door to creativity
  • "Might": not a must — encourages exploration without pressure
  • "We": not just me — this is a team effort

Examples

  • Problem: users cannot find the content they are looking for

  • HMW: "How might we help users find the right content for them with the least effort?"

  • Problem: users feel bored while waiting

  • HMW: "How might we make waiting time an enjoyable experience instead of boring?"

Tips

  • Do not make it too broad: "How might we improve the app?" — that is not useful
  • Do not make it too narrow: "How might we add a blue search button?" — that is a solution not a question
  • The ideal middle ground: broad enough to generate diverse ideas, and narrow enough to stay focused

Problem Statement

The Idea

A problem statement is a clear and specific sentence describing the problem you are solving. It becomes your reference throughout the project.

The Formula

[User] needs a way to [need] because [reason/insight]

Or a more detailed version:

[User] struggles with [problem] when trying to [task], which leads to [negative outcome]

Example

"Working mothers in Cairo struggle to track their daily expenses when trying to manage the family budget, which leads to consistently exceeding the monthly budget and feeling a loss of control."

Tips for a Good Problem Statement

  • Based on real research, not assumptions
  • Specific enough that you can work on it
  • Contains no solution — describes the problem only
  • Defines the impact — why this problem matters
  • Measurable — you can tell whether you solved it or not

The Double Diamond Framework

The Idea

A framework developed by the British Design Council that became one of the most famous problem-solving frameworks in design. It is called the "Double Diamond" because it consists of two phases, each with an expansion and a contraction:

The First Diamond: The Right Problem

  1. Discover: expand your understanding — do research, meet users, observe behaviors. Do not judge anything — the goal is to gather information
  2. Define: narrow the focus — from everything you discovered, what is the real problem you need to solve? Here you come out with a clear Problem Statement

The Second Diamond: The Right Solution

  1. Develop: expand solution options — Brainstorm, Ideate, generate as many ideas as possible. There are no wrong ideas in this stage
  2. Deliver: narrow and refine — choose the best solution, make a Prototype, test it, and develop it

The important idea: many teams jump straight to the second diamond (start solving) without investing time in the first diamond (understanding the problem). This is the main reason many products fail.

Affinity Mapping Technique

The Idea

When you have a large amount of data (from interviews, observations, feedback), Affinity Mapping helps you organize it and extract patterns.

How to Do It

  1. Write each observation on a separate Post-it (physical or digital in Miro)
  2. Start grouping similar ones together — without defining categories in advance
  3. Name each group after it takes shape
  4. Arrange the groups by importance or frequency
  5. Extract Insights — what patterns emerged?

Practical Example

After 10 interviews with users of a banking app, I collected 80 observations. After Affinity Mapping, 5 groups emerged:

  • Security: people are afraid of fraud (18 observations)
  • Simplicity: want to make transfers quickly (15 observations)
  • Transparency: want to understand fees and commissions (14 observations)
  • Control: want to control notifications and limits (12 observations)
  • Support: cannot find help when they need it (11 observations)

Now you know that security and simplicity are the top priorities.

Crazy 8s Technique

The Idea

A fast technique for generating ideas: sketch 8 different solutions in 8 minutes. One minute for each idea.

Why It Works

  • Speed prevents perfectionism: no time to overthink — just sketch and go
  • Quantity generates quality: the first 2-3 ideas will be ordinary, but ideas 5-8 will be more creative because you have exhausted the obvious ideas
  • Gets everyone out of their comfort zone: no time for hesitation or fear

How to Do It

  1. Fold an A4 sheet to get 8 squares
  2. Set a timer for 8 minutes
  3. Sketch a different idea in each square — one square per minute
  4. After finishing: share with the team and choose the best

The RICE Framework for Prioritization

After generating many ideas, you need to prioritize. RICE helps you:

  • Reach: how many users will be affected?
  • Impact: how big will the impact be? (1-3)
  • Confidence: how confident are you in these estimates? (%)
  • Effort: how much time/resources do you need?

Score = (Reach x Impact x Confidence) / Effort

Ideas with a higher score get implemented first.

General Tips for Problem Solving in UX

1. Resist "First Solution Bias"

The first solution that comes to mind is rarely the best. Take your time and explore different options.

2. Frame and Reframe

Try to rephrase the problem in more than one way. "Users are not registering" can be rephrased as "users do not see enough value in registering" or "the registration process is too long."

Each framing opens the door to different solutions.

3. Think of Constraints as Opportunities

Constraints (limited time, small budget, limited technical capabilities) are not obstacles — they direct creativity. Sometimes the best solutions come from the tightest constraints.

4. Test Assumptions

Every solution is built on assumptions. Identify them explicitly and test them:

  • "Users will understand this icon" ← test it
  • "People will pay for this feature" ← test it
  • "The core problem is speed" ← test it

5. Learn from Failure

Not every solution will succeed. What matters is that you learn from every experience:

  • What worked and why?
  • What failed and why?
  • What will we do differently next time?

Tools and Resources

  • Books: "Competing Against Luck" by Clayton Christensen (about JTBD), and "Sprint" by Jake Knapp (about solving problems in a week)
  • Tools: Miro for Affinity Mapping, FigJam for collaboration, Notion for documentation
  • Courses: IDEO U: From Ideas to Action on creative problem solving
  • Podcast: The Design Better Podcast talks a lot about problem solving in design

Summary

Problem solving in UX is not a talent — it is a skill you learn and practice. The frameworks we discussed — Jobs to be Done, 5 Whys, How Might We, Double Diamond — are tools in your toolbox. You do not have to use all of them in every project, but you need to know them so you can choose the right one.

The most important thing to remember: spend more time understanding the problem. If you understand the problem correctly, the solution is usually clear. If you jump to the solution immediately, you will find yourself solving the wrong problem.

In your next project, before opening Figma, write one clear Problem Statement. If you cannot write it in two sentences, you still do not understand the problem well enough.

اختبر فهمك

السؤال ١ من

سجّل عشان تبدأ الاختبار

اكتب اسمك وإيميلك وهتقدر تحل الاختبار فوراً. وكمان هنبعتلك نصايح تصميم ومصادر حصرية مرة في الأسبوع.

بياناتك آمنة تقدر تلغي الاشتراك في أي وقت

Share Article