Prototyping & Interactive Design

Workflow

1. Choose the right fidelity for the questionEvery prototype costs time. Matching fidelity to the question (paper for structure, mid-fi for flow, hi-fi for visual) avoids wasting effort building details nobody needs to test.
2. Create Figma interactive prototypesFigma's prototype mode connects frames with interactions. Variables enable conditional logic - showing/hiding elements based on user actions - without code.
3. Run prototype usability testsThe goal of a prototype is to answer questions before building. Usability testing with 5 users finds 85% of usability issues at a fraction of the cost of fixing production bugs.
4. Document prototype decisionsPrototypes inform decisions. Without documenting why a design was chosen (not just what it is), the rationale is lost and teams revisit settled debates.
5. Know when to stop prototyping and shipPrototypes are a means to reduce risk - not a deliverable in themselves. Diminishing returns set in quickly; at some point, the prototype is more expensive than just building it.

Output Format

Prototyping: paper→wireframe→hi-fi fidelity ladder, Figma variables for conditional logic, 5-user usability test script with severity rating, decision log, and shipping checklist.

Paper: 30 min, layout questions
Wireframe: 4 hrs, flow questions (Figma, grayscale)
Hi-fi: 2 days, final polish + handoff
Test: scenario → observe (don't help) → debrief → severity tag
Stop when: flow tested + stakeholders aligned + engineering clear

Examples

Edge Cases & Gotchas

• Prototype scope creep - Teams keep adding screens to cover "every possible path" before testing. Scope the prototype to one task or flow per test session - testing partial flows is valid and much cheaper.
• Figma prototype performance - Complex Figma prototypes with many variables and interactive components lag on mobile. Simplify for mobile testing: remove animations, reduce variable complexity, use simpler state changes.
• Over-reliance on prototypes vs. A/B tests - Usability testing identifies confusion (qualitative); A/B tests measure behavior at scale (quantitative). For conversion-critical features, follow prototype usability tests with production A/B tests.
• Testing with your ideal user - Test with participants who match your target user - not colleagues or designers. Internal users have domain knowledge that masks real user confusion.

When to Break These Rules

• Build and test in production instead of prototyping when: the question is about backend performance, the change is trivially small (<2 hours to build), or when you have enough behavioral data from existing users.
• Skip hi-fi prototypes when the development team is co-located and can iterate in production rapidly (feature flag + small user group) faster than a prototype testing cycle.

Reference Files

• https://help.figma.com/hc/en-us/articles/360040314193-Guide-to-prototyping-in-Figma
• https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/