Table of Contents
The 5 W's in UX design - Who, What, When, Where, and Why - are a simple but powerful framework that forces you to slow down and understand the problem before you try to solve it.
This isn't a theory. It's the difference between designing something people actually use and designing something that looks great in Figma but fails in the real world.
What Are the 5 W's in UX Design?
The 5 W's in UX design are five core questions - Who, What, When, Where, and Why - used during the discovery and research phase to define the user, the problem, the context, and the motivation before any design work begins.
Borrowed from journalism and research methodology, the framework gives UX designers a structured way to gather context. Each question targets a different layer of the user experience. Together, they build a complete picture of who you're designing for and what they actually need.
Think of it as your design brief - but built from evidence instead of assumptions.
What Are the 5 W's in UX Design?
The 5 W's in UX design are five core questions - Who, What, When, Where, and Why - used during the discovery and research phase to define the user, the problem, the context, and the motivation before any design work begins.
Borrowed from journalism and research methodology, the framework gives UX designers a structured way to gather context. Each question targets a different layer of the user experience. Together, they build a complete picture of who you're designing for and what they actually need.
Think of it as your design brief - but built from evidence instead of assumptions.
Who - Are You Designing For?
A product team defines their target user like this: “25–40 years old, uses a smartphone.”
On paper, that sounds reasonable. In reality, it tells you almost nothing about how that person thinks, decides, or struggles.
The “who” isn’t about demographics. It’s about behavior, context, and intent.
If you don’t understand those, you’re not designing for a user you’re guessing.
The Who question is about understanding real people: their goals, frustrations, mental models, and behaviors. It’s the foundation of any meaningful user research.
What to find out:
- What is the user's primary goal in this context?
- What technical skill level do they have?
- What emotional state are they likely in when using this product?
- Do they have accessibility needs (visual, motor, cognitive)?
What - Problem Are You Actually Solving?
A user reports that “checkout is too slow.” The team interprets this as a need for a faster checkout and proceeds to redesign the entire flow. However, the real issue isn’t the flow itself. It’s a delay after tapping “Pay” — just long enough to make users think nothing happened.
This is how designers end up solving the wrong problem. They react to symptoms instead of identifying what’s actually breaking in the experience.
Example (bad): “Users need a faster checkout.”
Example (good): “Users with saved payment details abandon checkout on mobile because the confirmation screen loads slowly on 4G, making them unsure whether the transaction went through.”
The difference here is clarity. The second version identifies a specific moment, a real constraint, and a clear failure point. The first is vague, which often leads to unnecessary redesign work without addressing the root issue.
Once you understand this distinction, the structure of a strong problem statement becomes clear. It should always answer the following:
• What is the user trying to accomplish right now?
• What is getting in their way?
• What does success look like from their perspective?
When - Do Users Interact With Your Product?
A laundry delivery app, SwiftWash, discovered that 73% of bookings happened between 9 - 11 PM - right before users went to bed.
At that time, people weren’t comparing options or exploring features. They were tired, distracted, and focused on finishing a task with as little effort as possible.
That insight led to a simpler experience. Optional steps were removed, the interface was reduced, and the primary booking action was made immediately visible. The goal shifted from offering flexibility to minimizing friction in a low-energy moment.
This is why timing matters. The same product can require very different design decisions depending on when and in what state it’s used.
Someone opening your product during a rushed commute behaves very differently from someone using it at a desk with time to think.
If you ignore that context, you end up designing for the wrong situation.
To understand that context clearly, focus on a few key questions:
• What time of day or week does the user typically engage?
• Is this a frequent habit or an occasional, high-stakes task?
• Is the user in a rush, or do they have time to think?
• Are there specific situations or triggers that influence behavior
Where - Does the Experience Happen?
UX design that ignores physical context is incomplete design. The Where is not just about device type it's about the full environment around the user.
A food delivery app (Gourmeat, for example) might look flawless on a clean desktop mockup. But if the majority of users are ordering from a kitchen while cooking, holding their phone one-handed, with greasy fingers that context changes everything about interaction design.
Environmental factors to map:
- Device type and screen size
- Network reliability (strong WiFi vs. spotty 4G)
- Lighting conditions (outdoor glare vs. dim bedroom)
- Physical posture (seated, standing, moving)
- Surrounding distractions (noise, other tasks)
Why - Does the User Need This?
A meditation app might assume the reason is simple: users want to meditate. But research often reveals something deeper.
Many users feel overwhelmed, mentally drained, and out of control during the workday. What they actually want is a quick way to reset something that fits into a few minutes and helps them regain focus.
That shift changes everything. The goal is no longer “help users meditate.” It becomes “help users feel calmer and more in control in under 10 minutes.” As a result, onboarding, session length, and even the language used in the product need to support that outcome.
This is what the “why” uncovers. It moves you from surface-level actions to the real motivation behind them.
People don’t use a product just to complete a task. They use it to achieve a result or change how they feel.
For example: “I want to track my spending” is often driven by something deeper like anxiety about running out of money before the end of the month.
If you design only for the task, the experience stays functional. If you design for motivation, it becomes meaningful.
To uncover that motivation, you need to answer a few key questions:
• What outcome is the user ultimately trying to achieve?
• What emotional state are they trying to move toward - or away from?
• What would make them feel that the product actually worked?
The 6th W: How - Why 5W1H in UX Design Is More Complete
The classic five questions cover context beautifully. But there's one dimension they miss: the execution layer.
5W1H in UX design adds 'How' to the framework and it's where research transitions into design decisions.
The How also connects your UX research directly to your design system. If users are consistently doing something the 'wrong' way, that's not user error that's a design opportunity.
Practical note: In Figma, the How question often informs your component variants and auto layout decisions. If research shows users frequently switch between two modes of a feature, build that toggle into the component don't hide it in a menu.
How answers questions like:
- How does the user currently solve this problem (workarounds, tools, habits)?
- How technically confident are they?
- How many steps are acceptable before they abandon the flow?
- How will this design be built and does that affect the experience?
Where the 5 W's Fit Inside Design Thinking
The 5 W's aren't a replacement for design thinking they're a tool that sharpens the Empathize and Define phases.
In the double diamond model, the 5 W's belong in the first diamond: the divergent research phase where you're expanding understanding before narrowing to a solution.
Teams that skip the 5 W's phase typically run into a specific problem: their prototype testing fails not because the design is wrong, but because they defined the problem wrong. It's expensive feedback to receive at prototype stage.
If you're using HMW (How Might We) questions in your ideation, you should be able to trace each HMW directly back to an answer from your 5 W's research. If you can't the research wasn't deep enough.
Mapping 5 W's to design thinking phases:
- Empathize - Who and Why (understanding people and motivations)
- Define - What (crafting the problem statement)
- Ideate - Where and When inform constraints for solutions
- Prototype & Test - How validates your design decisions
Using the 5 W's in an Agile Sprint
One objection always comes up: 'We don't have time for discovery in a two-week sprint.' It's a fair concern. But the 5 W's don't require a three-month research project.
A lean version of the framework takes 2–3 hours and can be done as a UX workshop with your product team using FigJam.
During backlog refinement, the 5 W's check is a fast way to validate that each user story has enough context to actually design from. If a ticket can't answer all five questions, it's not ready to enter the sprint.
Sprint-ready 5 W's workshop format:
- 30 min: Frame the user story - map Who and Why to the acceptance criteria
- 20 min: Define the problem - convert the user story into a What problem statement
- 20 min: Map context - document When and Where assumptions from existing data
- 30 min: Add How - identify constraints and current user workarounds
- 20 min: Review and prioritize - convert findings into design requirements
How to Apply the 5 W's in Figma
The 5 W's framework works best when it's embedded into your design workflow - not treated as a separate research document that never gets opened again.
For mobile app UX research, label each screen variant by the When/Where context it serves. A screen optimized for 'commute mode' (one-handed, short attention span) should look different from 'home mode' (seated, two-handed, longer task completion acceptable).
In FigJam (Research Phase):
- Create a 5 W's discovery board with one frame per question
- Paste research notes, quotes, and observations directly under each W
- Link each W section to the corresponding design component it informs
In Figma Design (Design Phase):
- Add a 5 W's annotation layer to your design file
- Use component descriptions to document which W a component was designed around
- Create design tokens that reflect context (e.g., low-light mode for nighttime use cases)
Free resource: A Figma Community template built around the 5 W's discovery framework gives you a ready-made research-to-design handoff structure. Search 'UX discovery framework template' in Figma Community.
5 W's vs. Design Thinking: What's the Difference?
They're not competing frameworks. But understanding where they overlap and where they don't matters.
Common Mistakes UX Designers Make With the 5 W's
The framework is simple. The execution, less so. Here's what goes wrong most often — and how to avoid it.
1. Answering the questions with assumptions
The biggest failure mode: filling in the 5 W's from a product roadmap or a stakeholder's gut feeling. If the answers aren't coming from actual users — they're guesses dressed up as research.
2. Treating it as a one-time exercise
Context changes. Users evolve. A 5 W's document from 18 months ago is likely outdated. Run a quick re-validation every major product cycle, especially before a significant feature launch.
3. Skipping the 'Why' because it feels soft
Teams that skip the motivation layer end up building efficient solutions to problems users don't actually care about. The Why is what connects your design to real human behavior.
4. Ignoring WCAG and accessibility in the 'Who'
The Who question must include users with accessibility needs — not as an edge case, but as a core design consideration. WCAG 2.2 AA compliance starts in research, not in dev handoff. Screen reader behavior, color contrast ratios, and ARIA label decisions all trace back to who you're actually designing for.
5. Keeping it in a document no one reads
Embed the 5 W's directly into Figma. Annotation layers, component notes, and FigJam boards that live alongside the design file get used. PDFs that live in a shared drive folder do not.
Get the Free 5 W's UX Discovery Template
The 5 W's framework is most useful when it's built into your workflow not referenced from memory mid-sprint.
A well-structured UX design checklist based on the 5 W's framework gives you:
- A pre-built FigJam discovery board with prompts for each W
- A sprint-ready user story validation template
- An example filled with a real-world case study (mobile app context)
- A research-to-design handoff structure
Search 'UX Discovery Framework Template' in Figma Community or use the link in the resource section below to access the free template directly.
Final Thoughts
The 5 W's in UX design are not a checklist you rush through at the start of a project. They're a discipline a commitment to understanding the problem before you start solving it.
Most design teams know they should do more research. The 5 W's give them a specific, structured way to actually do it without adding weeks to their process.
Start with one question. Ask Who about your last shipped feature. If you can't answer it with research-backed specifics, you've found your gap. Fill it then bring that habit to every project that follows.
Frequently Asked Questions
What are the 5 W's in UX design?
The 5 W's in UX design are five discovery questions - Who (the user), What (the problem), When (timing of use), Where (context of use), and Why (user motivation) used during research to build a complete understanding of the user experience before design begins.
What is 5W1H in UX design?
5W1H in UX design extends the classic 5 W's framework by adding 'How' — covering how users currently solve the problem, how technically confident they are, and how the design will be implemented. It bridges research insights and design decisions more completely than the 5 W's alone.
How do I apply the 5 W's in Figma?
Create a FigJam discovery board with one frame per question (Who, What, When, Where, Why). Populate each frame with research quotes, observations, and insights from user interviews. Link findings directly to design components to keep research connected to your design decisions throughout the project.
What is the difference between the 5 W's and design thinking?
The 5 W's framework is a research and discovery tool used primarily in the Empathize and Define phases of design thinking. Design thinking is a broader end-to-end process covering research through prototype testing. The 5 W's sharpens the front end of that process defining the right problem to solve.
Can I use the 5 W's framework in an agile sprint?
Yes. A lean version of the 5 W's workshop takes 2–3 hours and can run within a sprint cycle. Use it during backlog refinement to validate that each user story has enough context to design from. Add a 5 W's row to your sprint planning template to check each ticket before it enters the sprint.
What is a 5 W's UX design template?
A 5 W's UX design template is a structured discovery document typically in FigJam or Notion with guided prompts for each of the five questions. It helps teams systematically gather user context before design begins and serves as a handoff artifact between UX research and design.
What is the difference between the 5 W's and design thinking?
Design thinking is a broader methodology with five phases: empathize, define, ideate, prototype, and test. The 5 W's are a focused questioning tool that fits within the empathize and define phases. They complement design thinking by providing specific questions to answer during early research and problem framing.
