g.grow.

Design & UX Lesson 1 of 5

Uncovering Real User Problems & Framing Needs

14:20 Designing Your First Digital Product

Great products do not start with features; they start with acute user frustration. Learn how to identify core user friction and frame problem statements.

Lesson notes

Before opening any design software, world-class product designers spend the majority of their energy understanding the problem space. When you jump straight into visual styling or feature lists, you risk building a polished solution to a problem nobody actually has.

What you'll learn

  • Differentiate between user symptoms and root causes
  • Formulate 'How Might We' (HMW) opportunity statements
  • Conduct 15-minute exploratory interviews without leading the user

1. The 5 Whys Technique

When users complain about a problem, they often describe superficial symptoms. By repeatedly asking 'Why does that happen?', you peel away successive layers of symptoms to arrive at the underlying root cause. For example: 'I missed the meeting' -> 'Why?' -> 'The reminder arrived too late' -> 'Why?' -> 'Notifications are bundled into email digests' -> 'Why?' -> 'Users feel overwhelmed by push alerts.' Now you know the real problem is notification fatigue, not calendar scheduling.

2. Constructing 'How Might We' Statements

Transform your problem statements into open-ended creative prompts. The structure is simple: 'How might we [action] for [target user] so that [desired outcome]?'

  • Too narrow: 'How might we add a red banner button?' (presumes the UI solution)
  • Too broad: 'How might we reinvent communication?' (unfocused and impractical)
  • Just right: 'How might we help remote teams share asynchronous progress updates in under two minutes?'

3. Identifying Emotional vs Functional Jobs

Users hire products to accomplish both functional tasks (e.g. format a spreadsheet) and emotional desires (e.g. feel organized and respected by their manager). Documenting both guarantees your product design speaks directly to human motivation.

markdown
# User Problem Statement Template

**User Persona:** Freelance Web Developer (Solo)
**Context / Trigger:** When sending project invoices at month-end
**Pain Point / Obstacle:** Manually calculating tracked hours from 3 different tools
**Root Impact:** Loses 4 hours of billable work and worries about billing discrepancies

**HMW Question:** 
How might we automate timesheet consolidation so freelancers can invoice accurately in under 30 seconds?

Use this structured template to document problem statements before initiating design sprints.

Practice exercise

Practice: Write 3 HMW Statements

Think of an app you use daily that frustrates you. Identify the core user friction, find the root cause, and write three distinct 'How Might We' statements exploring different solution angles.

Hint: Focus on the user outcome rather than specific UI controls like dropdowns or sliders.

Quick check

What is the primary danger of jumping straight into Figma without user problem validation?

  1. A.Figma licenses expire quickly
  2. B.You risk building a beautifully polished solution to a problem that nobody has
  3. C.You cannot export vector assets properly
  4. D.It violates WCAG accessibility compliance

Great design starts with deep problem validation. Without validating user demand and root causes, engineering and design effort is wasted on unused features.