Principles of UX / UI (Product Design): Design Thinking (Empathize, Define, Ideate, Prototype, Test)

Design Thinking (Empathize, Define, Ideate, Prototype, Test)

Design Thinking: A Portfolio-Ready Study Guide

(Empathize, Define, Ideate, Prototype, Test)

What This Is

Design Thinking is a human-centered, iterative process for solving complex problems in a way that’s both usable and delightful. It’s not just for designers—it’s a framework used by product teams, engineers, and business leaders to build products that people actually want to use.

Concrete example: Imagine a hospital’s patient portal where users struggle to book appointments. Instead of jumping straight to a redesign, you’d: 1. Empathize (interview patients to understand frustrations, like confusing medical jargon or hidden "Book Now" buttons).
2. Define (pinpoint the core problem: "Patients can’t find appointment slots quickly because the UI prioritizes admin needs over user goals.").
3. Ideate (sketch 3 solutions: a calendar view, a chatbot assistant, or a "Quick Book" button on the homepage).
4. Prototype (build a low-fidelity Figma mockup of the calendar view).
5. Test (watch 5 users try to book an appointment; iterate based on where they get stuck).

This process reduces guesswork and ensures your design solves real problems—not just what stakeholders think users need.

Key Terms & Principles

• Empathy Map
  Definition: A visual tool to synthesize user research into 4 quadrants: Says, Thinks, Does, Feels. Helps teams align on user needs.
  Example: For a fitness app, an empathy map might reveal users feel "overwhelmed by too many workout options" but say "I want more variety." The gap? They need curated plans, not infinite choices.

• Problem Statement (Point of View - POV)
  Definition: A concise, actionable definition of the user’s core need, structured as: [User] needs a way to [need] because [insight]. Example: "Busy parents need a way to order groceries in under 2 minutes because they’re juggling childcare and don’t have time to browse."

• How Might We (HMW) Questions
  Definition: Open-ended questions that reframe problems as opportunities for ideation. Start with "How might we…?" Example: "How might we reduce checkout abandonment for first-time users?" (Leads to ideas like guest checkout, progress indicators, or saved carts.)

• Divergent vs. Convergent Thinking
  Definition: Divergent = generating many ideas (e.g., brainstorming 50 solutions). Convergent = narrowing down to the best one (e.g., voting on the top 3).
  Example: In Figma, use a sticky-note storm (divergent) to list all possible features for a meditation app, then dot-vote (convergent) to prioritize the top 3.

• Affinity Diagramming
  Definition: Grouping related ideas/themes from research to spot patterns. Often done with sticky notes or Figma’s auto-layout.
  Example: After interviewing 10 users about a banking app, you group feedback into themes: "Login frustrations," "Confusing fees," "Need for budgeting tools."

• Crazy 8s
  Definition: A rapid ideation exercise where you sketch 8 variations of a solution in 8 minutes (1 minute per sketch). Forces creativity and avoids overthinking.
  Example: Redesigning a food delivery app’s "Reorder" button—sketch 8 placements (floating, in the menu, on the receipt, etc.).

• Low-Fidelity (Lo-Fi) vs. High-Fidelity (Hi-Fi) Prototypes
  Definition:

• Lo-Fi: Quick, rough sketches (e.g., paper wireframes, Figma frames with placeholder text). Used for early testing.

• Hi-Fi: Polished, interactive mockups (e.g., Figma prototypes with real copy, colors, and micro-interactions). Used for stakeholder buy-in or late-stage testing.
  Example: Test a lo-fi paper prototype of a checkout flow with 5 users, then build a hi-fi Figma prototype with animations for a client presentation.

• Usability Testing vs. User Interviews
  Definition:

• Usability Test: Observing users completing tasks (e.g., "Book a doctor’s appointment") to identify friction points.

• User Interview: Asking open-ended questions (e.g., "Walk me through the last time you booked an appointment") to uncover why problems exist.
  Example: A usability test might reveal users can’t find the "Book" button, while an interview might uncover they expect it to be in the top-right (not buried in a menu).

• Heuristic Evaluation
  Definition: Auditing a design against Nielsen’s 10 Usability Heuristics (e.g., "Does the system match real-world language?"). Often done by UX experts before user testing.
  Example: Evaluating a travel app’s booking flow: "Does the ‘Confirm’ button use clear, actionable language, or is it vague like ‘Submit’?"

• Cognitive Load
  Definition: The mental effort required to use a product. High cognitive load = frustration. Reduce it by simplifying choices, using familiar patterns, and chunking information.
  Example: A dashboard with 20 metrics overwhelms users. Instead, group data into 3 key cards (e.g., "Revenue," "User Growth," "Support Tickets") with expandable details.

• Progressive Disclosure
  Definition: Showing only the most important information upfront, revealing details as needed. Reduces cognitive load.
  Example: A flight booking site shows departure/arrival times first, then expands to show baggage fees and seat selection only after the user selects a flight.

• Hick’s Law
  Definition: The time it takes to make a decision increases with the number of choices. Simplify options to speed up decisions.
  Example: A restaurant app’s "Order" screen has 3 buttons: "Delivery," "Pickup," "Dine-In" (not 10+ options like "Curbside," "Drive-Thru," etc.).

• Jakob’s Law
  Definition: Users expect your product to work like others they’ve used. Follow familiar patterns to reduce learning curves.
  Example: Place the shopping cart icon in the top-right (like Amazon) instead of inventing a new location.

Step-by-Step / Process Flow

1. Empathize: Understand the User

Actions:
- Conduct user interviews (5–7 users) or contextual inquiries (observe users in their natural environment).
- Figma tip: Use the FigJam whiteboard to map out interview questions (e.g., "What’s the hardest part about [task]?").
- Create an empathy map in Figma or Miro. Example: [User: College Student] Says: "I need to study but get distracted." Thinks: "I’m failing because I can’t focus." Does: Opens 10 tabs, checks phone every 5 mins.
Feels: Stressed, guilty. - Synthesize findings into key insights (e.g., "Users abandon study apps because they feel judged by progress trackers.").

Output: A research report (1–2 slides in Figma) with quotes, pain points, and a summary of user needs.

2. Define: Frame the Problem

Actions:
- Write a problem statement (POV) based on research. Example: "Busy professionals need a way to track their water intake in under 10 seconds because they forget to hydrate while working." - Use HMW questions to reframe the problem as opportunities. Example: - "How might we make hydration tracking effortless?" - "How might we gamify water intake without adding guilt?" - Prioritize problems using a 2x2 matrix (Impact vs. Feasibility) in Figma. Example: High Impact / High Feasibility: "Add a one-tap ‘Log Water’ button." Low Impact / Low Feasibility: "Integrate with smart water bottles."

Output: A problem statement slide + HMW questions in your Figma file.

3. Ideate: Generate Solutions

Actions:
- Run a Crazy 8s session (sketch 8 ideas in 8 minutes). Example ideas for a hydration app: 1. Floating "Log Water" button.
2. Voice command ("Hey Hydrate, log 1 cup").
3. Auto-tracking via phone sensors.
4. Streak counter (e.g., "3-day streak!").
- Use dot voting (team members vote on top ideas) or impact/effort matrix to narrow down.
- Sketch 3–5 wireframe variations in Figma (use auto-layout for consistency). Example: - Variation 1: Bottom navigation with a "Log" tab.
- Variation 2: Persistent "Log Water" button in the corner.
- Variation 3: Home screen with a progress bar.

Output: Lo-fi wireframes (Figma frames with placeholders) + voting results.

4. Prototype: Build a Testable Model

Actions:
- Create a clickable prototype in Figma (use prototyping mode to link frames). Example: - Flow: Home screen → Tap "Log Water" → Confirmation animation → Updated progress bar.
- For lo-fi tests, use paper prototypes or Figma’s "Present" mode with basic interactions.
- For hi-fi tests, add micro-interactions (e.g., a "splash" animation when logging water) and real copy.

Output: A Figma prototype link (shareable with users/stakeholders).

5. Test: Validate with Users

Actions:
- Recruit 5 users (use guerilla testing in cafes or UserTesting.com for remote tests).
- Assign tasks (e.g., "Log 1 cup of water") and observe where they struggle.
- Take notes in FigJam or a spreadsheet. Example: User 1: Tapped "Log" button → Confused by "ml vs. oz" → Abandoned.
User 2: Expected "Log" to be in the top-right (Jakob’s Law). - Iterate based on findings (e.g., simplify units, move the button).

Output: A usability test report (1 slide in Figma) with key findings and recommended changes.

Common Mistakes

Design Interview / Portfolio Tips

What Interviewers Look For

1. Storytelling with the Double Diamond
2. Structure your case study like this:
   Problem → Research (Empathize/Define) → Ideas (Ideate) → Solution (Prototype/Test) → Impact.

3. Example: For a checkout flow redesign, show:

   
   
   • Problem: "30% drop-off at payment step."
   • Research: "User interviews revealed confusion over shipping costs."
   • Ideas: "Brainstormed 3 solutions: progress bar, guest checkout, cost calculator."
   • Solution: "Prototyped a progress bar with shipping costs upfront."
   • Impact: "Reduced drop-off by 15%."

4. Distinguishing Key Terms

5. Wireframe vs. Prototype:
   • Wireframe: Static, low-detail layout (e.g., gray boxes for buttons).
   • Prototype: Interactive, clickable model (e.g., Figma prototype with hotspots).
6. Usability Test vs. User Interview:
   • Usability Test: "Can users complete Task X?" (e.g., "Book a flight").
   • User Interview: "What do users think about the booking process?"

7. Design System vs. Style Guide:

   
   
   • Style Guide: Colors, typography, logos (static).
   • Design System: Components, interactions, voice/tone, and how to use them (e.g., "When to use a primary vs. secondary button").

8. Showing Iteration

9. Include before/after screens and explain why you changed things. Example:

   
   
   • Before: "Checkout button was small and gray (low contrast)."
   • After: "Made it large, green, and sticky (Fitts’s Law + contrast)."
   • Result: "Clicks increased by 22%."

10. Quantifying Impact

11. Use metrics to prove your work mattered. Example:
    • "Reduced form fields from 12 to 5, increasing completion by 35%."
    • "Added a progress indicator, decreasing drop-off by 18%."

Quick Check Questions

1. Scenario: A stakeholder insists on adding a "Live Chat" feature to your app’s homepage. How do you use design thinking to evaluate this request?

2. Answer: Start with empathy (interview users: "Have you ever used live chat? When?"). If research shows users prefer self-service, define the problem (e.g., "Users struggle to find FAQs") and ideate alternatives (e.g., a searchable help center). Use Hick’s Law to argue that adding another feature increases cognitive load. Prototype and test both options to compare engagement.

3. Scenario: Your team is stuck in a debate about whether to use a bottom navigation bar or a hamburger menu for a mobile app. How do you decide?

4. Answer: Test both prototypes with users (usability test). Use Jakob’s Law—if most apps in your industry use bottom nav (e.g., social media apps), users will expect it. Also consider Fitts’s Law: bottom nav is easier to reach with one hand. If data is inconclusive, default to the most familiar pattern (Jakob’s Law).

5. Scenario: A user test reveals that participants can’t find the "Settings" button in your app. What’s your next step?

6. Answer: Define the problem: "Users expect ‘Settings’ to be in the top-right (Jakob’s Law) but it’s hidden in a dropdown." Ideate solutions (e.g., move it to the top-right, add an icon, or use a persistent tab bar). Prototype the change and test again with 3–5 users to confirm the fix.

Last-Minute Cram Sheet

1. Design Thinking Phases: Empathize → Define → Ideate → Prototype → Test. ⚠️ Don’t skip empathy!
2. Nielsen’s 10 Heuristics: Match real-world language, consistency, error prevention, etc. ⚠️ Memorize at least 5 for interviews.
3. Fitts’s Law: Big, close targets = faster clicks. Example: Mobile "Buy" button at thumb zone.
4. Hick’s Law: More choices = slower decisions. Example: Limit filters to 3–5 options.
5. Jakob’s Law: Users expect your product to work like others. Example: Shopping cart in top-right.
6. WCAG Contrast Ratio: 4.5:1 for normal text, 3:1 for large text. Use Figma’s contrast checker.
7. Lo-Fi vs. Hi-Fi: Lo-fi = speed/ideas; hi-fi = polish/buy-in. ⚠️ Don’t jump to hi-fi too soon!
8. Usability Test vs. User Interview: Test = tasks; interview = opinions. ⚠️ They answer different questions.
9. Crazy 8s: 8 sketches in 8 minutes. Forces creativity, not perfection.
10. Problem Statement Template: "[User] needs a way to [need] because [insight]." ⚠️ Avoid vague problems like "The app is confusing."