Principles of Product Management: Prototyping (Paper, Low-fi, High-fi, Tools like Figma, Balsamiq)

Prototyping (Paper, Low?fi, High?fi, Tools like Figma, Balsamiq)

Prototyping: A Practical Study Guide for PMs

What This Is

Prototyping is the process of creating early, tangible representations of a product or feature to test assumptions, gather feedback, and iterate before investing in full development. It matters because it reduces risk, validates ideas cheaply, and aligns teams around a shared vision. Example: When Airbnb redesigned its booking flow, they used low-fidelity (low-fi) paper prototypes to test 10+ variations with hosts and guests in under a week, identifying a 30% drop in booking abandonment before writing a single line of code.

Key Terms & Frameworks

• Prototype Fidelity: The level of detail and realism in a prototype.
• Paper prototype: Hand-drawn sketches (0 fidelity).
• Low-fi: Digital wireframes (e.g., Balsamiq, Figma frames with placeholders).
• High-fi: Interactive, pixel-perfect mockups (e.g., Figma prototypes with animations).
• Prototype Purpose Spectrum (SVPG):
• Exploratory: Test broad concepts (e.g., "Should we add a chatbot?").
• Evolutionary: Refine a specific flow (e.g., "Does this checkout step reduce drop-off?").
• Explanatory: Sell a vision to stakeholders (e.g., "Here’s how our AI feature will work").
• Testable Hypothesis (Lean Startup): "We believe [user segment] will [achieve outcome] because [reason]. We’ll know we’re right if [quantitative/qualitative signal]."
• Example: "We believe new users will complete onboarding faster if we replace the 5-step form with a guided tour, because it reduces cognitive load. We’ll know we’re right if time-to-completion drops by 20%."
• Prototype Testing Methods:
• Usability Testing: Observe users interacting with the prototype (e.g., "Can they find the ‘Buy’ button?").
• A/B Testing: Compare two versions (e.g., "Does a red or green CTA button convert better?").
• Wizard of Oz: Fake functionality (e.g., a human manually processes orders behind a "AI-powered" UI).
• Prototype ROI Formula: ROI = (Value of Validated Learning – Cost of Prototype) / Cost of Prototype
• Value of Validated Learning: Estimated savings from avoiding a bad build (e.g., "$50K in dev costs saved by killing a feature early").
• Cost of Prototype: Time + tools (e.g., "2 days of PM/designer time + $50 for user incentives").
• Figma/Balsamiq Shortcuts for PMs:
• Figma: Shift + A (add auto-layout), Ctrl/Cmd + G (group), Prototype mode (link frames).
• Balsamiq: Ctrl/Cmd + D (duplicate), Ctrl/Cmd + Shift + F (search components).
• Prototype Feedback Loop (Reforge):
• Build: Create the prototype (1–2 days max).
• Test: Run 5–10 user sessions.
• Synthesize: Identify patterns (e.g., "80% of users ignored the tooltip").
• Decide: Kill, pivot, or iterate.
• Prototype vs. MVP vs. MMP:
• Prototype: Throwaway, tests assumptions (e.g., a Figma click-through).
• MVP: Minimal shippable product (e.g., a live feature with core functionality).
• MMP (Minimum Marketable Product): MVP + polish for public launch (e.g., MVP + analytics + support docs).
• Prototype Tools by Use Case:
• Quick exploration: Paper, Excalidraw, Whimsical.
• Low-fi wireframes: Balsamiq, Figma (wireframe kits).
• High-fi/interactive: Figma, Framer, ProtoPie.
• 3D/AR: Spline, Adobe Aero.

Step-by-Step Process Flow

1. Define the Goal
2. Action: Write a testable hypothesis (see above) and pick a fidelity level.
3. Example: "We believe first-time users will understand our ‘Smart Budget’ feature if we add a 15-second demo video. We’ll test this with a low-fi Figma prototype and measure if 70% of users can explain the feature after watching."

4. PM Task: Align with design/engineering on scope (e.g., "We’ll prototype the video + 2 screens, not the entire dashboard").

5. Build the Prototype

6. Action: Use the right tool for the job (see "Prototype Tools by Use Case").
7. PM Tips:
   • For exploratory prototypes, use paper or Excalidraw (1–2 hours max).
   • For evolutionary prototypes, use Figma/Balsamiq (1–2 days).
   • For explanatory prototypes, use high-fi Figma + animations (3–5 days).

8. Example: For a fintech app’s "Split Bill" feature, create a low-fi prototype with:

   • A screen showing a bill ($100).
   • A button labeled "Split with Friends."
   • A modal with 3 friend avatars + checkboxes.
   • A confirmation screen ("You owe $33.33").

9. Recruit Testers

10. Action: Target 5–10 users from your core segment (e.g., "frequent Venmo users aged 25–34").
11. PM Tips:
    • Use tools like UserTesting.com, UserInterviews.com, or your own network.
    • Offer incentives ($20–$50 gift cards) or leverage power users (e.g., "We’ll give you early access to the feature").

12. Example: For the "Split Bill" prototype, recruit 5 users who’ve split bills in the past month.

13. Run the Test

14. Action: Conduct usability tests (in-person or remote via Zoom + Figma’s "Share Prototype" link).
15. PM Script:
    • "Imagine you’re at dinner with friends and want to split a $100 bill. Show me how you’d use this app to do that."
    • Follow-up: "What was confusing? What would you change?"

16. Metrics to Track:

    • Quantitative: Task success rate (e.g., "80% completed the flow"), time on task.
    • Qualitative: User quotes (e.g., "I expected the ‘Split’ button to be at the top, not the bottom").

17. Synthesize & Decide

18. Action: Aggregate feedback into themes (e.g., "3/5 users struggled to find the ‘Split’ button").
19. PM Framework: Use the ICE Score (Impact × Confidence × Ease) to prioritize fixes.
    • Example: | Fix | Impact (1–10) | Confidence (1–10) | Ease (1–10) | ICE Score | |--------------------|---------------|-------------------|-------------|-----------| | Move "Split" button| 8 | 9 | 7 | 504 | | Add tooltip | 5 | 6 | 9 | 270 |

20. Decision: Kill, pivot, or iterate.

    • Kill: If <50% of users understand the core value (e.g., "Split Bill" is too confusing).
    • Pivot: If users suggest a better direction (e.g., "I’d rather split by item, not total").
    • Iterate: If most users succeed but with friction (e.g., "Move the button + add a tooltip").

21. Communicate Results

22. Action: Share a 1-pager with stakeholders (engineering, design, leadership).
23. Template:
    • Goal: [Hypothesis]
    • Prototype: [Link to Figma/Balsamiq]
    • Test Results: [Quantitative + qualitative findings]
    • Recommendation: [Kill/Pivot/Iterate + next steps]
24. Example: "We tested the ‘Split Bill’ prototype with 5 users. 80% completed the flow, but 3/5 struggled to find the ‘Split’ button. We recommend moving it to the top bar (ICE score: 504) and adding a tooltip (ICE score: 270). Next step: Build a high-fi prototype with these changes."

Common Mistakes

1. Mistake: Building high-fi prototypes too early.
2. Correction: Start with low-fi (paper/Figma wireframes) to test broad concepts. High-fi is expensive and locks you into details prematurely.

3. Why: Users give more honest feedback on rough prototypes ("This looks unfinished, so I’ll critique it") vs. polished ones ("This looks done, so I’ll assume it’s final").

4. Mistake: Testing with the wrong users.

5. Correction: Recruit users from your target segment (e.g., "frequent bill-splitters" for a fintech app). Avoid friends/family unless they match your persona.

6. Why: Feedback from non-users is noise (e.g., "I’d never use this" from someone who doesn’t split bills).

7. Mistake: Over-engineering the prototype.

8. Correction: Limit scope to one hypothesis per prototype (e.g., "Does the video demo improve understanding?" vs. "Does the video demo + new onboarding flow + tooltip improve understanding?").

9. Why: Too many variables = unclear results. Iterate in small batches.

10. Mistake: Ignoring "silent failures."

11. Correction: Watch for behavioral signals (e.g., users hesitating, clicking randomly) not just verbal feedback (e.g., "This looks good").

12. Why: Users often say one thing but do another (e.g., "I love this!" but abandon the flow).

13. Mistake: Not killing bad ideas.

14. Correction: Use a kill threshold (e.g., "If <50% of users understand the core value, we kill it"). Document the decision to avoid sunk-cost bias.
15. Why: It’s cheaper to fail in Figma than in production.

PM Interview / Practical Insights

1. Tricky Distinction: Prototype vs. MVP
2. Interviewer Trap: "How would you prototype a social network for pet owners?"
3. Answer: Clarify the goal:
   • Prototype: A low-fi Figma click-through to test if users understand the "Post a Pet Pic" flow.
   • MVP: A live web app with core features (upload, like, comment) but no polish (e.g., no profile customization).

4. Why: Interviewers want to see you understand scope and purpose.

5. Stakeholder Pushback: "Why not just build it?"

6. Common Objection: Engineers/leaders may resist prototyping ("It’s faster to code it").
7. Response: Use the Prototype ROI Formula:
   • "If we spend 2 days prototyping and kill a bad idea, we save 2 weeks of dev time. If we iterate, we’ll build the right thing faster. Here’s the math: [show ROI formula]."

8. Why: Stakeholders care about speed and cost.

9. Behavioral Question: "Tell me about a time you used a prototype to kill a feature."

10. Structure (STAR Method):
    • Situation: "We were building a ‘Group Goals’ feature for a fitness app."
    • Task: "We needed to validate if users would collaborate on goals (e.g., ‘Run 5K together’)."
    • Action: "I created a low-fi Figma prototype with 3 screens: goal creation, invite friends, progress tracking. We tested it with 8 users."
    • Result: "Only 2/8 users understood the value. We killed the feature and pivoted to solo challenges, which had 100% comprehension in follow-up tests."

11. Why: Interviewers want to see decisiveness and user-centricity.

12. Tool-Specific Question: "When would you use Balsamiq vs. Figma?"

13. Answer:
    • Balsamiq: For exploratory prototypes (e.g., "Should we add a chatbot?") or when speed matters (e.g., 1-hour brainstorming session).
    • Figma: For evolutionary or explanatory prototypes (e.g., "Does this checkout flow reduce drop-off?") or when you need interactivity (e.g., hover states, animations).
14. Why: Shows you understand trade-offs (speed vs. fidelity).

Quick Check Questions

1. Scenario: Your team wants to add a "Dark Mode" toggle to your app. The designer says, "Let’s build a high-fi prototype in Figma with animations." The engineer says, "We should just code it—it’s a simple toggle." How do you decide?
2. Answer: Start with a low-fi prototype (e.g., a static Figma frame with a toggle) to test discoverability (e.g., "Can users find the toggle?") and preference (e.g., "Do users actually want Dark Mode?"). Only invest in high-fi/code if the low-fi test validates demand.

3. Why: Dark Mode’s value isn’t obvious (e.g., some users hate it), and high-fi/code is overkill for a "nice-to-have" feature.

4. Scenario: You’re prototyping a new "Subscription Upsell" flow for a SaaS product. Users say, "This feels pushy," but your CEO insists, "We need to hit revenue targets." How do you proceed?

5. Answer: Run an A/B test with two prototypes:
   • Version A: Aggressive upsell (e.g., "Upgrade now or lose access!").
   • Version B: Value-focused upsell (e.g., "Unlock [feature] to save 10 hours/month").
   • Measure conversion rate and NPS. If Version B converts nearly as well with higher NPS, advocate for it.

6. Why: Data > opinions, and prototypes let you test emotional reactions (e.g., "pushy") quantitatively.

7. Scenario: Your prototype test shows 60% of users complete the flow, but 40% drop off at the "Payment" screen. The designer says, "Let’s add a progress bar." The engineer says, "Let’s remove the payment step entirely." How do you decide?

8. Answer: Dig into the qualitative feedback:
   • If users say, "I don’t trust this site with my card," add trust signals (e.g., "Secure checkout" badge, testimonials).
   • If users say, "I don’t want to pay yet," explore alternative monetization (e.g., freemium, trial).
   • Only add a progress bar if users say, "I don’t know how much longer this will take."
9. Why: The root cause of drop-off determines the fix.

Last-Minute Cram Sheet

1. Prototype fidelity ladder: Paper-Low-fi (wireframes)-High-fi (interactive mockups).
2. Prototype purpose: Exploratory (broad), Evolutionary (refine), Explanatory (sell).
3. Testable hypothesis formula: "We believe [X] will [Y] because [Z]. We’ll know we’re right if [signal]."
4. Prototype ROI: (Value of Learning – Cost) / Cost-Aim for >1.
5. Usability test script: "Imagine you’re [scenario]. Show me how you’d [task]."
6. Kill threshold: <50% task success = kill or pivot.
7. Figma shortcuts: Shift + A (auto-layout), Prototype mode (link frames).
8. Balsamiq use case: Fast, low-fi exploration (e.g., brainstorming sessions).
9. Prototype-MVP: Prototype = throwaway; MVP = shippable.
10. High-fi too early: Locks you into details before validating the concept.