What Are the 5 W’s in UX Design? A Practical Guide

The 5 W's in UX design are Who, What, When, Where, and Why. They form a questioning framework that forces designers to clarify the user, the problem, the context, the environment, and the rationale before making a single design decision.

Skipping these questions is the fastest way to build something nobody needs. Teams that anchor their Figma workflow in the 5 W's produce mobile apps that are focused, usable, and aligned with real user behavior.

This guide breaks down each W with practical applications for mobile app design, shows you how to integrate the framework into Figma, and highlights the mistakes that happen when you skip it.

What Are the 5 W's in UX Design?

The 5 W's in UX design are a structured questioning framework borrowed from journalism and investigative research. They stand for Who, What, When, Where, and Why. Each question targets a different dimension of the user experience, and together they create a complete picture of the design problem before any pixels get pushed.

In UX, the framework works like this:

• Who identifies the target user.
• What defines the problem or task.
• When establishes the timing and context of use.
• Where determines the platform, device, and physical environment.
• Why uncovers the motivation behind both the user's behavior and the design decision.

Some practitioners add a sixth element, How, which addresses the execution method. But the core five questions are the foundation. They apply whether you are designing a fintech onboarding flow, a health tracking dashboard, or a social media feed.

The Origin of the 5 W's Framework

The 5 W's did not originate in design. They come from classical rhetoric and journalism, where reporters use Who, What, When, Where, and Why to ensure complete coverage of a story. The framework dates back to Hermagoras of Temnos in the first century BCE and was later codified in journalism education as the standard for factual reporting.

UX design adopted the framework because it solves the same problem: incomplete understanding. Just as a news story fails without answering all five questions, a product design fails when the team cannot articulate who they are building for, what problem they are solving, or why a specific interaction pattern exists. The 5 W's became a staple in design thinking workshops, user research planning, and product discovery sessions.

Why the 5 W's Matter for Mobile App Design

Mobile app design operates under tighter constraints than web or desktop design. Screen real estate is limited. Attention spans are shorter. Users interact in unpredictable environments, from crowded trains to dimly lit rooms. Every design decision carries more weight.

The 5 W's matter here because they prevent assumption-driven design. When a product team skips the "When" question, they might design a checkout flow that works perfectly at a desk but fails when a user is walking and tapping with one thumb. When they skip the "Who" question, they build features for an imagined user that does not match the actual audience.

For teams working in Figma, the 5 W's provide a pre-design checklist. Before creating components, building design systems, or prototyping interactions, answering these five questions ensures that every frame in your Figma file has a reason to exist.

Who Are You Designing For?

The first W is the most consequential. "Who" defines your target user, and every other design decision flows from that answer. Get the user wrong, and the entire product misses.

This is not about demographics alone. Knowing that your user is "25-34, urban, tech-savvy" tells you almost nothing about how they will interact with your app. The "Who" question in UX design digs into behavior, goals, frustrations, technical literacy, accessibility needs, and the mental models users carry from other products.

Defining User Personas in Figma

User personas translate research into a reference artifact your team can use throughout the design process. In Figma, you can build persona templates as reusable components within your design system.

A strong persona for mobile app design includes:

• Name and photo (to humanize the reference)
• Primary goal (what they are trying to accomplish)
• Key frustration (what blocks them today)
• Device and platform (iOS, Android, screen size preferences)
• Usage context (where and when they typically use similar apps)
• Technical comfort level (beginner, intermediate, power user)
• Accessibility considerations (vision, motor, cognitive needs)

Place persona frames on a dedicated Figma page at the start of your project file. This keeps the "Who" visible to every designer and developer who opens the file. When a design review question comes up, the team can point back to the persona and ask: "Does this serve Maria's primary goal, or are we designing for ourselves?"

Mapping Stakeholders and Their Goals

The "Who" question extends beyond end users. Stakeholders shape product decisions, and their goals often conflict with user needs. A founder might prioritize monetization. A marketing lead might push for more sign-up friction to capture emails. An engineering lead might resist animation because of performance costs.

Mapping stakeholders early prevents design rework. Create a simple stakeholder map in Figma or FigJam that lists each stakeholder, their primary objective, and where their goals align or conflict with user needs. This does not mean stakeholder goals override user needs. It means you design with full awareness of the forces acting on your product.

How User Research Shapes Every Design Decision

Answering "Who" without research is guessing. User interviews, surveys, analytics data, and usability tests are the tools that turn the "Who" question into actionable insight.

For mobile app projects, even lightweight research makes a difference. Five user interviews can reveal patterns that reshape your entire navigation structure. Analytics from a beta release can show which features users actually touch versus which ones the team assumed would be popular.

In Figma, research findings should feed directly into your design process. Annotate frames with research insights. Link to interview recordings in Figma comments. Use observation notes to justify component choices. The goal is to make the "Who" answer traceable from research data to final UI.

What Problem Are You Solving?

The second W forces clarity on the problem space. "What" asks: What task is the user trying to complete? What pain point are you addressing? What outcome does the user expect?

Many mobile apps fail not because of bad UI, but because they solve the wrong problem. A beautifully designed feature that nobody needs is still a failure. The "What" question prevents this by anchoring design work in a defined problem statement.

Identifying Core User Needs

Core user needs are not feature requests. They are the underlying goals that drive behavior. A user who says "I want a calendar view" might actually need "I want to see my upcoming tasks without opening three different screens."

To identify core needs, use techniques like:

• Jobs to Be Done (JTBD): Frame needs as jobs the user hires your product to do.
• User story mapping: Organize needs into a narrative flow of tasks.
• Pain point audits: Review support tickets, app store reviews, and interview transcripts for recurring frustrations.

In Figma, document core user needs on a dedicated project page. Reference them in frame annotations so that every screen in your prototype ties back to a specific need.

Translating Business Goals into Design Requirements

The "What" question also bridges business objectives and user needs. A startup founder might define the problem as "We need users to subscribe." But the design problem is different: "Users need to understand the product's value before they commit."

Translating business goals into design requirements means reframing commercial objectives as user experience challenges. Subscription conversion becomes an onboarding clarity problem. Retention becomes a value delivery problem. Revenue per user becomes a feature discovery problem.

This reframing keeps the design user-centered while still serving business outcomes. In your Figma file, maintain a requirements matrix that maps each business goal to a corresponding user need and the design solution that addresses both.

Prioritizing Features with the What Question

Not every user need deserves a feature in your MVP. The "What" question helps prioritize by forcing the team to rank problems by severity, frequency, and alignment with the product's core value proposition.

Use a prioritization framework like MoSCoW (Must have, Should have, Could have, Won't have) or a simple impact-effort matrix. In Figma, you can build these as interactive components in FigJam and link them to your design file so that prioritization decisions stay connected to the screens they affect.

The discipline here is saying no. If a feature does not answer a clearly defined "What" problem, it does not belong in the current design scope.

When Will Users Interact with Your Product?

The third W addresses timing and context. "When" asks: At what moment in the user's day, workflow, or journey will they open your app? What state of mind are they in? How much time do they have?

Timing shapes everything from information density to interaction patterns. A user checking a fitness app at 6 AM before a run needs a different experience than someone reviewing their weekly stats on a Sunday evening.

Understanding Context of Use

Context of use is a UX research concept that describes the conditions under which a product is used. For mobile apps, context includes:

• Time of day (morning commute, lunch break, late night)
• Duration of session (quick glance vs. extended use)
• Attention level (focused vs. distracted)
• Emotional state (stressed, relaxed, urgent)
• Concurrent activities (walking, cooking, waiting in line)

Understanding context prevents designing for ideal conditions that rarely exist. If your analytics show that most sessions last under 90 seconds, your app needs to deliver value in that window. Long onboarding tutorials and multi-step flows will not survive real-world usage patterns.

Designing for Different User Moments

Mobile app interactions fall into distinct moment types:

• Micro-moments: Quick, intent-driven actions (checking a notification, scanning a balance, confirming a booking).
• Immersive sessions: Longer, focused interactions (browsing a catalog, completing a form, reading content).
• Background interactions: Passive engagement (receiving alerts, tracking location, syncing data).

Each moment type demands different UI patterns. Micro-moments need large tap targets, minimal navigation, and instant feedback. Immersive sessions can support richer layouts, progressive disclosure, and deeper content hierarchies. Background interactions require clear notification design and respectful interruption patterns.

In Figma, prototype each moment type separately. Create distinct user flows for quick-action scenarios and extended-use scenarios. This ensures your design system accommodates the full range of "When" contexts.

Timing in Prototyping and Usability Testing

The "When" question also applies to your design process. When you prototype and test matters as much as how you do it.

Prototype early and test often. In Figma, use simple clickable prototypes to validate navigation flows before investing in high-fidelity screens. Test with users in conditions that match real usage contexts. If your app is designed for on-the-go use, do not test it only on desktop monitors in a quiet conference room.

Timing also affects iteration cycles. Test after each major design decision, not just at the end of a sprint. The earlier you catch a usability issue, the cheaper it is to fix.

Where Does the Experience Take Place?

The fourth W defines the environment. "Where" asks: On what device, platform, and physical setting will users experience your product?

For mobile app design, "Where" is not just "on a phone." It includes the operating system, screen size, network conditions, and the physical environment where the interaction happens.

Platform and Device Considerations

Designing for mobile means designing for fragmentation. iOS and Android have different design languages, interaction patterns, and user expectations. Apple's Human Interface Guidelines and Google's Material Design provide platform-specific standards that users have internalized.

In Figma, maintain separate component variants for iOS and Android when platform conventions differ significantly. Navigation patterns (tab bars vs. bottom navigation), typography scales, and gesture behaviors all vary between platforms. Ignoring these differences creates friction for users who expect platform-native behavior.

Screen size also matters. Design for the most common device sizes in your target market, and use Figma's auto layout and constraints to ensure your designs adapt gracefully across screen dimensions.

Designing for Mobile-First Environments

Mobile-first design is not about shrinking a desktop layout. It is about starting with the most constrained environment and building up. This forces prioritization. When you have 375 pixels of width, every element must earn its place.

Mobile-first principles include:

• Touch-first interactions: Minimum 44x44pt tap targets, thumb-friendly placement of primary actions.
• Content prioritization: Show the most important information first, use progressive disclosure for secondary content.
• Performance awareness: Optimize for slower networks and lower-powered devices.
• Vertical scrolling preference: Users expect to scroll vertically on mobile. Horizontal scrolling should be intentional and clearly signaled.

In Figma, start your design process with mobile frames. Build your component library at mobile scale first, then create responsive variants for larger screens if needed.

Environmental Factors That Affect Usability

design systems

The physical environment where users interact with your app affects usability in ways that are easy to overlook.

• Lighting: Bright sunlight washes out low-contrast interfaces. Ensure sufficient contrast ratios (WCAG AA minimum of 4.5:1 for body text).
• Noise: Loud environments make audio feedback useless. Rely on visual and haptic feedback for confirmations.
• Motion: Users on buses, trains, or walking have reduced precision. Larger touch targets and forgiving gesture recognition help.
• One-handed use: Many mobile interactions happen with one hand. Place critical actions within the thumb's natural reach zone.

These environmental factors should inform your Figma design decisions. Test your color contrast with accessibility plugins. Position primary actions in the bottom third of the screen for thumb reachability. Design error states that do not rely solely on color to communicate.

Why Does This Design Decision Exist?

The fifth W is the most overlooked and the most powerful. "Why" asks: Why does this screen exist? Why is this button here? Why did we choose this interaction pattern over another?

Every design decision should have a traceable rationale. When a team cannot explain why a specific UI element exists, that element is a candidate for removal or redesign.

Justifying Design Choices with Data

Data-informed design is not about A/B testing every pixel. It is about using available evidence to support decisions and reduce guesswork.

Sources of design justification include:

• User research findings: Interview quotes, survey results, behavioral observations.
• Analytics data: Heatmaps, funnel drop-off rates, session recordings.
• Usability test results: Task completion rates, error rates, time-on-task metrics.
• Industry benchmarks: Established patterns from Nielsen Norman Group research and platform guidelines.
• Accessibility standards: WCAG compliance requirements that are non-negotiable.

In Figma, annotate design decisions with their rationale. Use comments or a dedicated annotation layer to explain why a specific layout, color, or interaction was chosen. This practice saves time during design reviews and developer handoff because it preempts "why did you do it this way?" questions.

Connecting UX Rationale to Business Outcomes

The "Why" question connects design work to measurable business results. When a designer can articulate that a simplified checkout flow reduces cart abandonment, the design decision gains organizational support.

Frame your design rationale in terms stakeholders understand:

• "We reduced form fields from 8 to 4 because user testing showed a 40% drop-off at field 5."
• "We moved the CTA above the fold because heatmap data showed only 30% of users scrolled past the hero section."
• "We added onboarding tooltips because new user retention was 15% lower than the industry benchmark."

This approach transforms design from a subjective craft into a strategic function. It also makes it easier to defend design decisions when stakeholders push for changes that conflict with user needs.

Building a Design Decision Log

A design decision log is a living document that records what was decided, why, and what evidence supported the decision. It prevents teams from revisiting settled questions and provides context for new team members.

In Figma, you can maintain a decision log as a dedicated page in your project file. Structure each entry with:

• Decision: What was decided (e.g., "Use bottom sheet navigation instead of hamburger menu").
• Rationale: Why (e.g., "User testing showed 60% of participants did not discover the hamburger menu").
• Evidence: Link to research data, test results, or analytics.
• Date: When the decision was made.
• Owner: Who made the call.

This log becomes invaluable during design-to-development handoff. Developers understand not just what to build, but why it was designed that way, which reduces implementation errors and unnecessary back-and-forth.

How to Apply the 5 W's in Your Figma Workflow

Knowing the 5 W's is one thing. Integrating them into your daily design workflow is where the framework delivers real value. Here is a practical, step-by-step process for applying the 5 W's in Figma-based mobile app projects.

1. Frame the 5 W's Before You Open Figma

Before creating a single frame, answer all five questions in writing. Use a shared document, a FigJam board, or a dedicated Figma page.

Create a 5 W's brief that includes:

• Who: Primary persona, secondary personas, stakeholder map.
• What: Problem statement, core user needs, prioritized feature list.
• When: Usage contexts, session types, timing constraints.
• Where: Target platforms, device specifications, environmental considerations.
• Why: Business objectives, success metrics, design principles.

This brief becomes the foundation for every design decision that follows. Pin it to the top of your Figma project so it is always accessible.

2. Build User Flows Around Your Answers

With the 5 W's answered, map user flows that reflect real usage scenarios. Each flow should trace a path from a specific "When" trigger through a "What" task to a "Why" outcome.

In Figma, use FigJam or a dedicated flow page to diagram:

• Entry points: How does the user arrive at this screen? (Push notification, app icon, deep link)
• Decision points: Where does the user make a choice?
• Success states: What does task completion look like?
• Error states: What happens when something goes wrong?
• Exit points: Where does the user leave the flow?

Label each flow with the persona it serves and the context it assumes. A flow designed for a first-time user on a slow network looks different from one designed for a power user on Wi-Fi.

3. Validate with Prototyping and Testing

Figma's prototyping features let you test your 5 W's assumptions before writing a single line of code.

Build interactive prototypes that simulate real usage scenarios:

• Task-based prototypes: Give testers a specific task ("Book a table for two tonight") and observe how they navigate.
• Context-specific prototypes: Test on actual mobile devices, not just desktop previews. Figma's mobile preview app lets testers interact with your prototype on their own phone.
• Scenario prototypes: Set the scene. Tell testers "You are on a bus, you have 30 seconds, and you need to check your account balance." This tests your "When" and "Where" assumptions.

After each test, revisit your 5 W's answers. Did the "Who" persona match the actual tester's behavior? Did the "When" context hold up? Update your brief based on findings.

4. Document for Design-to-Development Handoff

The 5 W's framework does not stop at design. It carries through to development handoff.

In Figma, prepare handoff documentation that includes:

• Design specs: Auto layout properties, spacing tokens, color variables, typography scales.
• Interaction specs: Transition types, animation timing, gesture behaviors.
• Context notes: Why specific decisions were made (pulled from your decision log).
• Platform notes: iOS vs. Android differences and how to handle them.
• Accessibility notes: Contrast ratios, screen reader labels, focus order.

Use Figma's Dev Mode to streamline this process. Tag components with implementation notes. Link to your 5 W's brief so developers understand the design intent, not just the visual output.

Common Mistakes When Ignoring the 5 W's

Teams that skip the 5 W's framework tend to make the same mistakes repeatedly. Recognizing these patterns helps you avoid them.

Designing Without a Clear User Definition

The most common mistake is designing for "everyone." When the "Who" is undefined, the product tries to serve all users and satisfies none. Features bloat. Navigation becomes confusing. The interface tries to accommodate conflicting use cases on the same screen.

The fix is simple but requires discipline: define your primary persona before you design. If you cannot describe your target user in two sentences, you are not ready to open Figma.

Skipping the Why Behind UI Patterns

Another frequent mistake is copying UI patterns from popular apps without understanding why those patterns work in their original context. A swipe-to-delete gesture makes sense in a messaging app where users manage high volumes of items. It makes less sense in a banking app where accidental deletion has serious consequences.

Every pattern you use should pass the "Why" test. Why this pattern? Why here? Why now? If the answer is "because Spotify does it," that is not a sufficient rationale.

Overlooking Context and Timing

Designing for ideal conditions is a trap. Teams build flows that work perfectly in a Figma prototype viewed on a 27-inch monitor but fall apart on a 5.4-inch screen in direct sunlight.

The "When" and "Where" questions exist to prevent this. If you have not considered the physical and temporal context of use, your design is incomplete. Test in realistic conditions. Design for the worst-case scenario, not the best.

Conclusion

The 5 W's in UX design give your team a repeatable framework for making intentional, user-centered decisions. Who, What, When, Where, and Why are not abstract concepts. They are practical checkpoints that prevent wasted effort and misaligned products.

Applying this framework in Figma transforms your workflow from reactive to strategic. Every component, flow, and interaction ties back to a clear rationale rooted in user needs and business goals.

At Orbix Studio, we build the 5 W's into every mobile app project from discovery to handoff. Reach out to our team to design a product that is grounded in strategy, built for real users, and ready to scale.

Frequently Asked Questions

What are the 5 W's in UX design?

The 5 W's in UX design are Who, What, When, Where, and Why. They form a questioning framework that helps designers define the user, the problem, the context, the environment, and the rationale behind every design decision before building interfaces.

How do the 5 W's improve mobile app design?

They force teams to clarify assumptions before designing. By answering each question, you avoid building features nobody needs, designing for wrong contexts, or copying UI patterns without understanding why they work. The result is a more focused, usable mobile app.

Can I use the 5 W's framework in Figma?

Yes. Create a dedicated 5 W's brief page in your Figma project file. Use FigJam for collaborative workshops. Annotate frames with rationale from your answers. Link persona components and decision logs directly within your design file to keep the framework visible throughout the project.

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.

When should I apply the 5 W's in a project?

Apply them at the start of every project, before opening your design tool. Revisit them after user testing, when pivoting features, or when onboarding new team members. The 5 W's are not a one-time exercise. They should be referenced throughout the design lifecycle.

Do the 5 W's replace user research?

No. The 5 W's provide the questions. User research provides the answers. Without research, your 5 W's responses are assumptions. Interviews, surveys, analytics, and usability tests supply the evidence needed to answer each W accurately and confidently.

How do the 5 W's help with design-to-development handoff?

They provide developers with context, not just specs. When handoff documentation includes why a design decision was made, what user need it serves, and what context it was designed for, developers can make better implementation choices and flag conflicts early instead of building blindly from visual mockups.