Understanding User Problems

The foundation of great product design isn't beautiful interfaces or clever interactions—it's a deep understanding of user problems. This chapter explores how to move beyond what users say they want to uncover what they actually need.

The Problem with Problems

Most teams think they understand user problems, but they're often solving the wrong things. Common mistakes include:

• Taking requests literally - Users say "I need a faster horse" when they mean "I need better transportation"
• Focusing on features - "We need a calendar integration" instead of "We need better time management"
• Assuming uniformity - Believing all users have the same problems
• Stopping at symptoms - Addressing surface issues without finding root causes

The Five Levels of User Problems

User problems exist at different levels of depth. Great designers learn to dig through all five:

Level 1: Stated Problems

What users explicitly tell you they need. "I need a way to organize my files better."

Level 2: Expressed Problems

What you observe users struggling with. They spend 10 minutes looking for a document they know exists.

Level 3: Real Problems

The underlying challenge causing the expressed problem. Their current organization system doesn't match their mental model.

Level 4: Unconscious Problems

Issues users don't realize they have. They've developed workarounds that waste time but seem normal.

Level 5: Secret Problems

Problems users know about but won't admit. They feel stupid when they can't find things, affecting their confidence.

Techniques for Problem Discovery

1. The Five Whys Technique

Start with a stated problem and ask "why" five times:

User says: "I want better notifications"

• Why? "I miss important messages"
• Why? "I get too many notifications to pay attention"
• Why? "The system treats all notifications equally"
• Why? "There's no way to prioritize what matters to me"
• Why? "The app doesn't understand my context and relationships"

Real problem: Need for contextual, intelligent notification prioritization.

2. Job-to-be-Done Framework

People "hire" products to do specific jobs. Ask:

• What job is the user trying to accomplish?
• What's their desired outcome?
• What obstacles prevent success?
• What would success look like?

3. Problem Journey Mapping

Map out the user's problem experience:

Research Methods for Problem Understanding

Qualitative Methods

User Interviews

• Focus on stories, not opinions
• Ask about specific recent experiences
• Probe emotional responses
• Observe what they don't say

Contextual Inquiry

• Watch users in their natural environment
• See the full context of their work
• Notice workarounds and adaptations
• Understand interruptions and constraints

Diary Studies

• Capture problems as they happen
• Understand patterns over time
• Get unfiltered reactions
• See emotional fluctuations

Quantitative Methods

Analytics Deep Dives

• Where do users struggle or drop off?
• What paths do they take?
• How much time do they spend?
• What errors occur most frequently?

Surveys

• Quantify problem frequency
• Understand problem priority
• Segment users by problem type
• Track problem evolution over time

The Problem Statement Framework

A good problem statement includes:

WHO: Which users are affected? WHAT: What specific challenge do they face?
WHERE: In what context does this occur? WHEN: At what point in their journey? WHY: What's the underlying cause? IMPACT: What happens if this isn't solved?

Example Problem Statement

WHO: New project managers at growing startups WHAT: Struggle to maintain visibility into team progress WHERE: During weekly planning and daily check-ins WHEN: After teams grow beyond 5 people WHY: Informal communication methods don't scale IMPACT: Projects slip, team members feel disconnected, managers feel out of control

Common Problem Discovery Pitfalls

1. Solution Bias

Going into research with a solution in mind and looking for problems that fit.

Fix: Start with open-ended exploration. Let problems emerge naturally.

2. Leading Questions

Asking questions that guide users toward specific answers.

Bad: "How frustrating is it when the app is slow?" Good: "Tell me about a recent time you used the app."

3. Expert Blindness

Assuming your deep product knowledge matches user mental models.

Fix: Regularly interact with new or casual users.

4. Sample Bias

Only talking to power users or vocal customers.

Fix: Intentionally seek out quiet, struggling, or lost users.

Practical Exercise: Problem Archaeology

Choose a feature in a product you use regularly that frustrates you.

Write a problem statement using the framework above.

Validating Problem Understanding

Before moving to solutions:

• Check with multiple users: Does this resonate broadly?
• Quantify the impact: How many people does this affect?
• Understand priority: How important is solving this?
• Test your assumptions: What might you be wrong about?

Moving from Problems to Opportunities

Great problem understanding reveals opportunities:

• Underserved user segments: Who's being ignored?
• Workflow improvements: Where can you remove friction?
• Emotional needs: How can you make users feel better?
• Competitive advantages: What problems do competitors miss?

Understanding user problems deeply is the foundation of all great product design. It's the difference between building features and solving real human needs.

---

Next week: Research and Discovery Methods - Tools and techniques for uncovering user insights