Principles of UX / UI (Product Design): Low‑Fidelity Prototypes (Paper, Wireframes)

Low‑Fidelity Prototypes (Paper, Wireframes)

Low-Fidelity Prototypes (Paper, Wireframes) – Portfolio-Ready Study Guide

What This Is

Low-fidelity (lo-fi) prototypes are quick, rough representations of a product’s structure and flow—think sketches, paper cutouts, or basic digital wireframes. They help designers test ideas early, gather feedback, and iterate before investing time in high-fidelity designs. For example, a hospital patient portal might use lo-fi wireframes to simplify appointment booking, reducing frustration by testing navigation before adding colors or branding. Similarly, an e-commerce checkout flow can be sketched to identify drop-off points before coding.

Key Terms & Principles

• Wireframe: A bare-bones, grayscale layout showing content hierarchy, navigation, and functionality (e.g., a mobile app screen with placeholder boxes for images and buttons).
• Paper Prototype: A hand-drawn or printed version of a UI, often used for rapid testing (e.g., sticky notes representing screens in a user flow).
• Design Thinking (Empathize → Define → Ideate → Prototype → Test): A problem-solving framework where lo-fi prototypes live in the "Prototype" phase.
• Jakob’s Law: Users expect interfaces to work like ones they already know (e.g., a "hamburger menu" in the top-left corner of a mobile app).
• Hick’s Law: The more choices a user has, the longer it takes to decide (e.g., limiting a mobile menu to 5 items instead of 10).
• Fitts’s Law: Larger, closer targets are easier to click (e.g., a "Submit" button that spans the full width of a mobile form).
• Guerrilla Testing: Quick, informal usability tests with random users (e.g., asking a café patron to try your paper prototype).
• Affordance: A design element that suggests its function (e.g., a 3D button that looks clickable vs. a flat, ambiguous shape).
• Heuristic Evaluation: A usability inspection using principles like Nielsen’s 10 Heuristics (e.g., checking if error messages are clear in a wireframe).
• Information Architecture (IA): The structure of content (e.g., organizing a dashboard’s navigation based on user tasks).
• User Flow: The path a user takes to complete a task (e.g., "Sign Up → Verify Email → Onboarding").
• White Space: Empty space that improves readability (e.g., leaving room between form fields to reduce cognitive load).

Step-by-Step / Process Flow

1. Define the Problem & User Flow
2. Write down the goal (e.g., "Reduce checkout abandonment by 20%").

3. Sketch a user flow (e.g., "Cart → Shipping → Payment → Confirmation") on paper or in Figma using simple boxes and arrows.

4. Sketch 3–5 Variations

5. Use pen and paper or Figma’s "Wireframe" kit to draw rough layouts.
6. Example: Test a single-page checkout vs. a multi-step wizard.

7. Apply Hick’s Law by limiting options (e.g., only 3 payment methods).

8. Create a Paper Prototype (Optional but Powerful)

9. Print or cut out screens, then simulate interactions (e.g., "If the user taps ‘Back,’ show the previous screen").

10. Use sticky notes for dynamic elements (e.g., error messages).

11. Conduct Guerrilla Testing

12. Grab 5 users (friends, coworkers, or café patrons).
13. Ask them to complete a task (e.g., "Book an appointment") while you observe.

14. Note where they hesitate or fail (e.g., "Users missed the ‘Continue’ button").

15. Iterate Based on Feedback

16. Update your wireframes in Figma (e.g., move the "Continue" button to the thumb zone).

17. Test again if needed.

18. Share with Stakeholders

19. Export Figma wireframes as a PDF or present paper prototypes in a meeting.
20. Focus on user problems, not aesthetics (e.g., "Users struggled with the date picker, so we simplified it").

Common Mistakes

• Mistake: Skipping user flows and jumping straight to screens.
  Correction: Always map the user’s journey first (e.g., "What happens after they tap ‘Sign Up’?").

• Mistake: Making wireframes too detailed (e.g., adding colors, logos, or real content).
  Correction: Keep it grayscale and low-detail to avoid distracting feedback on visuals.

• Mistake: Testing with only 1–2 users.
  Correction: Aim for 5 users to uncover ~85% of usability issues (Nielsen’s rule).

• Mistake: Ignoring accessibility in wireframes (e.g., tiny touch targets).
  Correction: Follow WCAG (e.g., buttons should be at least 48x48px).

• Mistake: Treating wireframes as "final designs." Correction: Label them as "Draft" or "Work in Progress" to set expectations.

Design Interview / Portfolio Tips

• Show Your Process: Interviewers want to see how you think. Include:
• Photos of paper prototypes.
• Figma screenshots with annotations (e.g., "Users struggled here, so we moved the button").

• A short video of a guerrilla test (even a phone recording).

• Explain Trade-offs: Be ready to discuss why you chose one wireframe over another (e.g., "We prioritized speed over flexibility because users were dropping off").

• Clarify Terminology:

• Wireframe vs. Prototype: Wireframes = static layouts; prototypes = interactive (even if lo-fi).
• Usability Test vs. User Interview: Usability tests observe tasks; interviews ask open-ended questions.

• Design System vs. Style Guide: A design system includes components, patterns, and rules; a style guide is just colors, fonts, and logos.

• Portfolio Storytelling: Frame your case study as a problem → solution → impact (e.g., "We reduced checkout steps from 5 to 3, increasing conversions by 15%").

Quick Check Questions

1. Scenario: A stakeholder wants to add a "Live Chat" button to every screen of a mobile app. How do you use design principles to advise against clutter?
   Answer: Apply Hick’s Law (more choices = slower decisions) and Jakob’s Law (users expect familiar patterns). Suggest testing the chat button in only 2–3 key screens (e.g., checkout, support) to avoid overwhelming users.

2. Scenario: During a paper prototype test, users keep tapping a non-interactive image, expecting it to do something. What’s the issue, and how do you fix it?
   Answer: The image lacks affordance (it doesn’t look clickable). Fix it by adding a border, shadow, or label (e.g., "Tap to enlarge").

3. Scenario: Your team argues that wireframes are a waste of time because "users can’t give feedback on something so ugly." How do you respond?
   Answer: Explain that lo-fi prototypes focus on functionality and flow, not aesthetics. Users give better feedback when they’re not distracted by colors or branding (cite Nielsen’s "Discount Usability" principle).

Last-Minute Cram Sheet

1. Lo-fi = speed over polish (test early, fail fast).
2. Jakob’s Law: Users expect familiar patterns (e.g., logo in top-left).
3. Hick’s Law: More choices = slower decisions (limit options).
4. Fitts’s Law: Bigger/closer targets = easier to click (e.g., mobile thumb zone).
5. Guerrilla testing: 5 users find ~85% of issues.
6. WCAG touch target: 48x48px minimum.
7. Paper prototypes > digital for early testing (cheaper, faster).
8. ⚠️ Wireframes ≠ prototypes (prototypes are interactive).
9. ⚠️ User interviews ≠ usability tests (interviews ask; tests observe).
10. Always annotate wireframes (explain functionality, not just layout).