Fatskills
Practice. Master. Repeat.
Study Guide: Principles of Product Management: UX Design Process (Research → Ideate → Prototype → Test → Implement)
Source: https://www.fatskills.com/ccent/chapter/product-management-ux-design-process-research-ideate-prototype-test-implement

Principles of Product Management: UX Design Process (Research → Ideate → Prototype → Test → Implement)

By Fatskills Exam Guides Team — the exam nerds behind 28,500+ quizzes and 2.1M practice questions across 500+ global exams.

⏱️ ~9 min read

UX Design Process (Research → Ideate → Prototype → Test → Implement)



UX Design Process (Research → Ideate → Prototype → Test → Implement)


What This Is

The UX design process is a user-centered, iterative loop that turns vague problems into validated, scalable solutions. It’s not just for designers—PMs own the problem space, define success metrics, and ensure the team builds the right thing (not just the thing right). Why it matters: Skipping steps (e.g., prototyping before research) leads to wasted effort, low adoption, or churn.
Example: When Monzo redesigned its app’s savings pots feature, they started with user research (discovering users struggled to track goals), ideated 10+ concepts, prototype-tested 3 with 50 users, and implemented the winner—resulting in a 22% increase in savings deposits within 3 months.


Key Terms & Frameworks

  • Double Diamond (Design Council):
    Discover (research) → Define (problem) → Develop (ideate) → Deliver (prototype/test). A visual model for divergent (exploring) and convergent (narrowing) thinking.
  • Jobs to Be Done (JTBD):
    “When [situation], I want to [motivation] so I can [outcome].” Example: “When I’m at the grocery store, I want to quickly check my budget so I can avoid overspending.”
  • ICE Score (Sean Ellis):
    Impact × Confidence × Ease (1–10 scale). Prioritizes ideas quickly (e.g., a feature with ICE 8/10/7 = 56).
  • Usability Testing (Nielsen’s 5 Users Rule):
    Testing with 5 users uncovers 85% of usability issues (diminishing returns after 5).
  • Cognitive Walkthrough:
    A heuristic evaluation where PMs/designers simulate a user’s first-time experience to spot friction (e.g., “Can a new user complete the onboarding flow without help?”).
  • A/B Test Power Calculation:
    Sample Size = (Z² × p × (1-p)) / E²
  • Z = confidence level (1.96 for 95%),
  • p = baseline conversion rate,
  • E = minimum detectable effect.
    Example: For a 5% baseline conversion, you need ~3,000 users per variant to detect a 1% lift.
  • Fidelity Spectrum (Prototypes):
    Low-fidelity (paper sketches, wireframes) → Mid-fidelity (clickable Figma mocks) → High-fidelity (pixel-perfect, coded prototypes).
  • HEART Framework (Google):
    Metrics for user experience: Happiness (NPS), Engagement (sessions/week), Adoption (new users), Retention (DAU/MAU), Task Success (completion rate).
  • Kano Model:
    Classifies features by user satisfaction:
  • Basic (must-haves, e.g., login),
  • Performance (more = better, e.g., faster load times),
  • Delighters (unexpected, e.g., Spotify’s “Discover Weekly”).
  • Opportunity Solution Tree (Teresa Torres):
    Visualizes how outcomes (e.g., “increase retention”) map to opportunities (e.g., “users forget to return”) and solutions (e.g., “push notifications”).
  • Design Sprint (Google Ventures):
    5-day process: Map (problem) → Sketch (solutions) → Decide (best idea) → PrototypeTest (with 5 users).
  • System Usability Scale (SUS):
    10-question survey (e.g., “I found the system unnecessarily complex”) scored 0–100. >68 = above average, <50 = failing.


Step-by-Step / Process Flow


1. Research: Understand the Problem

Actions:
- Define the goal: “Reduce checkout abandonment by 15%” (not “redesign checkout”).
- Identify users: Segment by behavior (e.g., “first-time buyers vs. repeat customers”).
- Choose methods:
- Qualitative: 5–10 user interviews, diary studies (e.g., “Show me how you shop online”).
- Quantitative: Analyze funnel drop-off (e.g., 60% abandon at shipping step), heatmaps (Hotjar), or surveys (Typeform).
- Synthesize findings: Use affinity mapping (group sticky notes by theme) to spot patterns (e.g., “Users distrust shipping cost transparency”).

Output: Problem statement (e.g., “Users abandon checkout because they’re surprised by shipping costs at the last step”).


2. Ideate: Generate Solutions

Actions:
- Brainstorm: Run a divergent session (e.g., “How might we make shipping costs transparent earlier?”). Use crazy 8s (8 ideas in 8 minutes) or SCAMPER (Substitute, Combine, Adapt, Modify, Put to another use, Eliminate, Reverse).
- Prioritize: Score ideas with ICE or RICE. Example: - Idea A: “Show shipping cost on product page” (ICE: 9/8/7 = 56).
- Idea B: “Free shipping threshold” (ICE: 7/6/5 = 35).
- Map to outcomes: Use an Opportunity Solution Tree to link ideas to metrics (e.g., “Idea A → Reduce surprise → Lower abandonment”).

Output: Top 2–3 solutions with hypotheses (e.g., “Showing shipping costs on the product page will reduce abandonment by 10%”).


3. Prototype: Build to Learn

Actions:
- Choose fidelity: Start low-fi (e.g., paper sketches for a mobile app) to test concepts cheaply. Move to mid-fi (Figma) for usability testing.
- Define scope: Focus on 1–2 key flows (e.g., “Can users find the shipping cost before checkout?”). Use user stories (e.g., “As a shopper, I want to see shipping costs upfront so I can decide if I’ll proceed”).
- Build fast: Use tools like Figma (design), Framer (interactive), or Webflow (coded prototypes). For physical products, use 3D prints or cardboard mockups.

Output: Testable prototype (e.g., a clickable Figma link with 3 screens: product page → cart → checkout).


4. Test: Validate with Users

Actions:
- Recruit users: Use UserTesting.com, usertesting.io, or your own network. Aim for 5–10 users (Nielsen’s rule).
- Run tests:
- Usability test: Give a task (e.g., “Buy this item”) and observe where they struggle.
- A/B test: Compare prototypes (e.g., “Variant A: Shipping cost on product page vs. Variant B: Free shipping threshold”).
- Measure success: Track HEART metrics (e.g., Task Success = % who complete checkout) and qualitative feedback (e.g., “I love seeing the cost upfront!”).
- Iterate: Fix critical issues (e.g., “Users didn’t notice the shipping cost label”) and retest.

Output: Validated solution (e.g., “Variant A reduced abandonment by 12% in testing”).


5. Implement: Ship & Monitor

Actions:
- Work with engineers: Break the solution into epics/stories (e.g., “Add shipping cost API call to product page”). Use story mapping to visualize the flow.
- Launch in phases:
- Internal dogfooding: Test with employees.
- Beta test: Release to 5% of users (e.g., “New checkout for iOS users in the UK”).
- Full rollout: Monitor leading indicators (e.g., add-to-cart rate) and lagging indicators (e.g., revenue).
- Monitor & iterate: Set up dashboards (Mixpanel, Amplitude) to track HEART metrics. Example: - Happiness: NPS survey post-purchase.
- Engagement: Sessions per user.
- Adoption: % of users who see the new shipping cost.

Output: Shipped feature with success metrics (e.g., “Checkout abandonment dropped 14% in 30 days”).


Common Mistakes

Mistake Correction Why
Skipping research and jumping to solutions. Always start with problem validation (e.g., interviews, data). Assumptions lead to building the wrong thing (e.g., “We thought users wanted dark mode, but they actually wanted faster load times”).
Testing with too few users (e.g., 1–2). Test with 5+ users (Nielsen’s rule). Small samples miss critical issues (e.g., 1 user might not notice a bug that 3 others do).
Prototyping at high fidelity too early. Start with low-fi (paper, wireframes) to test concepts cheaply. High-fi prototypes take time; low-fi lets you iterate faster (e.g., “We wasted 2 weeks designing a pixel-perfect prototype that users hated”).
Ignoring edge cases in testing. Test with diverse users (e.g., new vs. power users, mobile vs. desktop). Edge cases reveal hidden friction (e.g., “Users with slow internet couldn’t load the shipping cost API”).
Measuring success with vanity metrics. Tie metrics to business outcomes (e.g., “Increase revenue”) not outputs (e.g., “Number of features shipped”). Vanity metrics don’t prove impact (e.g., “We launched 10 features but retention didn’t change”).


PM Interview / Practical Insights


1. “How would you decide between two design solutions?”

What they’re testing: Can you balance user needs, business goals, and feasibility? Answer:
- Quantitative: Run an A/B test (e.g., compare conversion rates).
- Qualitative: Conduct usability tests (e.g., “Which design do users find more intuitive?”).
- Business impact: Use RICE to score solutions (e.g., “Solution A has higher impact but takes 3 months to build”).
- Stakeholder alignment: Present trade-offs (e.g., “Solution B is faster to build but may hurt long-term retention”).

Trap: Don’t default to “Let’s A/B test” without considering why you’re testing (e.g., “Is this a high-stakes decision? Do we have enough traffic?”).


2. “How do you handle a designer who wants to build a ‘perfect’ prototype before testing?”

What they’re testing: Can you advocate for speed and learning over perfection? Answer:
- Push for low-fi: “Let’s test a paper prototype first—if users hate the concept, we’ll save 2 weeks of design time.” - Set constraints: “We’ll spend 1 day on this prototype, then test with 5 users.” - Frame as a hypothesis: “We’re not building the final product—we’re testing if this idea solves the problem.” - Use data: Show examples of high-fi prototypes that failed (e.g., “Google Wave was beautiful but no one used it”).

Trap: Don’t dismiss design quality—balance speed with enough fidelity to get valid feedback.


3. “How do you measure the success of a UX change?”

What they’re testing: Do you know leading vs. lagging metrics and proxy metrics? Answer:
- Leading indicators: Task success rate, time on task, click-through rate (predict future behavior).
- Lagging indicators: Retention, revenue, NPS (measure long-term impact).
- Proxy metrics: If you can’t measure the outcome directly, use a proxy (e.g., “If we improve onboarding, we’ll see higher Day 7 retention”).
- HEART framework: Pick 1–2 metrics per category (e.g., Happiness = NPS, Engagement = sessions/week).

Trap: Avoid “We’ll know it’s working when users like it”—always tie to quantifiable outcomes.


Quick Check Questions


1. Your team wants to add a chatbot to reduce customer support tickets, but early tests show users prefer talking to humans. How do you decide?

Answer: Run a controlled experiment (A/B test) to measure the chatbot’s impact on support tickets vs. user satisfaction (NPS). If tickets drop but NPS plummets, it’s not worth the trade-off. Why: You can’t assume automation is always better—validate with data.

2. A designer proposes a “delighter” feature (Kano Model) that’s expensive to build. How do you prioritize it?

Answer: Score it with RICE: If the feature has low reach/impact but high effort, deprioritize it. Instead, focus on “performance” features (e.g., faster load times) that drive more value. Why: Delighters are nice-to-haves; prioritize must-haves and performance features first.

3. Your CEO wants to skip prototyping and launch a feature directly. How do you respond?

Answer: “Prototyping reduces risk—let’s test with 5 users for 1 day. If it fails, we’ll save 2 months of engineering time. If it succeeds, we’ll have confidence to scale.” Why: Prototyping is cheap insurance against costly mistakes.


Last-Minute Cram Sheet

  1. Double Diamond: Discover → Define → Develop → Deliver.
  2. JTBD: “When [situation], I want to [motivation] so I can [outcome].”
  3. ICE Score: Impact × Confidence × Ease (1–10 scale).
  4. Nielsen’s Rule: 5 users find 85% of usability issues. ⚠️ More users = diminishing returns.
  5. HEART Metrics: Happiness (NPS), Engagement (sessions), Adoption (new users), Retention (DAU/MAU), Task Success (completion rate).
  6. Kano Model: Basic (must-haves), Performance (more = better), Delighters (unexpected).
  7. A/B Test Power: Need ~3,000 users per variant to detect a 1% lift (for 5% baseline).
  8. Prototype Fidelity: Low-fi (paper) → Mid-fi (Figma) → High-fi (coded).
  9. Opportunity Solution Tree: Outcome → Opportunities → Solutions.
  10. ⚠️ Trap: “Confidence” in RICE is your confidence in the data, not stakeholders’ confidence in the idea.


ADVERTISEMENT