Principles of UX / UI (Product Design): User‑Centered Design (UCD) Principles

User‑Centered Design (UCD) Principles

User-Centered Design (UCD) Principles: Portfolio-Ready Study Guide

What This Is

User-Centered Design (UCD) is a design philosophy that prioritizes the needs, behaviors, and pain points of real users at every stage of the product development process. Instead of designing based on assumptions or stakeholder preferences, UCD ensures that solutions are usable, accessible, and delightful by involving users early and often.

Example: A hospital’s patient portal might have a confusing appointment-booking flow, leading to high drop-off rates. A UCD approach would involve: - Research: Interviewing patients to uncover frustrations (e.g., too many steps, unclear time slots).
- Prototyping: Testing a simplified, mobile-friendly flow with real users.
- Iteration: Refining based on feedback (e.g., adding a progress indicator, reducing form fields).

Key Terms & Principles

• Design Thinking: A problem-solving framework with 5 phases—Empathize, Define, Ideate, Prototype, Test—used to create human-centered solutions.
  Example: Airbnb used design thinking to redesign their booking flow after realizing users struggled with unclear pricing.

• Heuristic Evaluation: A usability inspection method where experts review a product against Nielsen’s 10 Usability Heuristics (e.g., "Match between system and real world").
  Example: A banking app might violate the "Recognition over recall" heuristic if it forces users to remember account numbers instead of displaying them.

• Fitts’s Law: The time to acquire a target (e.g., a button) is a function of its size and distance from the user’s pointer.
  Example: On mobile, the "Add to Cart" button should be large and placed in the thumb zone (bottom-right for right-handed users).

• Hick’s Law: The more choices a user has, the longer it takes to make a decision.
  Example: A restaurant menu with 50 items overwhelms users—grouping dishes into categories (e.g., "Vegetarian," "Seafood") speeds up decision-making.

• Jakob’s Law: Users expect your product to work like others they’ve used.
  Example: A new e-commerce site should place the shopping cart icon in the top-right (like Amazon) to avoid confusion.

• Affordance: A design element’s perceived function (e.g., a button looks clickable, a slider looks draggable).
  Example: A 3D button with a shadow affords clicking, while a flat, underlined text link might be missed.

• Cognitive Load: The mental effort required to use a product. High cognitive load = frustration.
  Example: A dashboard with too many charts and numbers increases cognitive load—simplify by showing only key metrics.

• Accessibility (WCAG): Web Content Accessibility Guidelines ensure designs work for people with disabilities (e.g., 4.5:1 contrast ratio for text, keyboard navigation).
  Example: A gray (#777) button on a white background fails WCAG—use #0056b3 (blue) on white for sufficient contrast.

• User Flow: A visual representation of the steps a user takes to complete a task (e.g., signing up, checking out).
  Example: A user flow for a food delivery app might include: Homepage → Search → Menu → Cart → Checkout → Confirmation.

• Micro-interactions: Small, functional animations that provide feedback (e.g., a "like" button that fills with color when tapped).
  Example: Slack’s "typing indicator" (three dots) reassures users that a message is being composed.

• Progressive Disclosure: Showing only essential information upfront and revealing details as needed.
  Example: A flight booking site hides advanced filters (e.g., "Layover duration") under a "More options" dropdown.

• Guerrilla Testing: Quick, informal usability tests with 3–5 users (e.g., asking strangers in a café to try your prototype).
  Example: Testing a Figma prototype of a new onboarding flow by asking coworkers to complete a task while you observe.

Step-by-Step / Process Flow

Here’s how to apply UCD principles in a real project (e.g., redesigning a fitness app’s workout tracker):

1. Research (Empathize)
2. Action: Conduct user interviews (5–7 users) to uncover pain points. Ask:
   • "Walk me through the last time you tracked a workout. What was frustrating?"
   • "What features do you wish existed?"
3. Tool: Use Miro or Google Forms to organize insights.

4. Output: A problem statement (e.g., "Users struggle to log workouts quickly because the current flow has too many steps.").

5. Define the Problem

6. Action: Create a user persona (e.g., "Busy professional, 30s, wants quick logging") and a journey map highlighting pain points.
7. Tool: Figma (for journey maps) or Whimsical (for flowcharts).

8. Output: A How Might We (HMW) question (e.g., "HMW reduce workout logging time from 3 steps to 1?").

9. Ideate (Brainstorm Solutions)

10. Action: Sketch 3–5 wireframe variations (e.g., voice logging, one-tap buttons, swipe gestures).
11. Tool: Figma (low-fidelity frames) or pen and paper.

12. Output: A prioritization matrix (e.g., "Quick wins" vs. "Long-term ideas").

13. Prototype

14. Action: Build a clickable prototype in Figma (focus on the happy path—the most common user flow).
15. Tip: Use auto-animate for micro-interactions (e.g., a checkmark appearing after logging a workout).

16. Output: A Figma prototype with 1–2 key flows (e.g., "Log a workout" and "View progress").

17. Test (Usability Testing)

18. Action: Conduct guerrilla testing with 5 users. Give them a task (e.g., "Log a 30-minute run") and observe:
    • Where do they hesitate?
    • Do they understand the icons?
19. Tool: Lookback or Zoom (for remote testing).

20. Output: A list of usability issues (e.g., "Users didn’t notice the ‘Save’ button because it blended into the background").

21. Iterate & Refine

22. Action: Fix critical issues (e.g., increase button contrast, simplify the flow) and test again.
23. Tool: Figma (update the prototype) + Notion (track feedback).
24. Output: A final prototype ready for development handoff.

Common Mistakes

Design Interview / Portfolio Tips

What Interviewers Look For

1. Evidence of User Research
2. Show: Screenshots of user interview notes, affinity diagrams, or survey results in your portfolio.

3. Say: "I conducted 5 user interviews and discovered that 80% of users struggled with X, so I redesigned Y."

4. Clear Problem-Solution Narrative

5. Structure your case study like this:

   
   
   • Problem: "Users couldn’t find the checkout button."
   • Research: "I ran a heuristic evaluation and found it violated Fitts’s Law."
   • Solution: "I moved the button to the thumb zone and increased its size."
   • Impact: "Drop-off rates decreased by 30%."

6. Distinguishing Key Terms

7. Wireframe vs. Prototype:
   • Wireframe: Low-fidelity (grayscale, no interactivity).
   • Prototype: Clickable, high-fidelity (used for testing).
8. Usability Test vs. User Interview:
   • Usability Test: Observing users complete tasks (e.g., "Book a flight").
   • User Interview: Asking open-ended questions (e.g., "What frustrates you about booking flights?").

9. Design System vs. Style Guide:

   
   
   • Style Guide: Colors, typography, logos (static).
   • Design System: Components, interactions, code snippets (dynamic).

10. Handling Stakeholder Pushback

11. Scenario: A PM wants to add 3 new features to the homepage.
12. Response: "I’d use Hick’s Law to explain that more choices increase cognitive load. Instead, we could prioritize the top 2 features and test their impact on engagement."

Quick Check Questions

1. Scenario: A stakeholder insists on adding a "Refer a Friend" pop-up to the checkout flow. How do you use UCD principles to evaluate this?

2. Answer: "I’d apply Jakob’s Law—users expect a smooth checkout, not interruptions. I’d test the pop-up’s impact on conversion (e.g., A/B test) and suggest progressive disclosure (e.g., show the referral option post-purchase)."

3. Scenario: Users are abandoning a form halfway through. What UCD methods would you use to diagnose the issue?

4. Answer: "I’d run a usability test to observe where users drop off. If it’s unclear, I’d check for heuristic violations (e.g., no progress indicator, too many required fields). I’d also interview users to uncover frustrations (e.g., ‘I didn’t understand this question’)."

5. Scenario: A designer argues that a button should be red because "it’s the brand color." How do you respond?

6. Answer: "I’d reference affordance and accessibility—red might signal ‘error’ or fail WCAG contrast. I’d test button colors (e.g., A/B test red vs. blue) and ensure it meets 4.5:1 contrast for readability."

Last-Minute Cram Sheet

1. Nielsen’s 10 Usability Heuristics – Memorize at least 3 (e.g., "Match system & real world," "Consistency & standards," "Error prevention").
2. Fitts’s Law – Big, close targets = faster clicks.
3. Hick’s Law – More choices = slower decisions.
4. Jakob’s Law – Design like familiar products.
5. WCAG Contrast Ratio – 4.5:1 for normal text, 3:1 for large text.
6. Cognitive Load – Simplify = less frustration.
7. Progressive Disclosure – Hide complexity until needed.
8. Guerrilla Testing – Test with 5 users, not 50.
9. ⚠️ User Interviews ≠ Usability Tests – Interviews uncover problems; tests observe task completion.
10. ⚠️ Design Systems ≠ Style Guides – Systems include components + code; guides are static.