figma-prototype-plan

Figma Prototype Plan Skill

Plans what to prototype in Figma and how — scoping to what the user test needs, defining every interaction, and setting up the test scenarios. Prevents over-building and ensures the prototype answers the research question.

Required Inputs

• Research question (what are you trying to learn?)
• Feature or flow being prototyped
• Prototype fidelity (low wireframe / mid functional / high pixel-perfect)
• Testing method (moderated in-person / moderated remote / unmoderated)
• Number of test tasks

Output Structure

1. Prototype Scope

In scope: [Flows with real interactions — specific screens listed] Out of scope: [Screens to show as static — not worth building as interactive] Rationale: Prototypes should be the minimum needed to test the hypothesis.

2. Interaction Specification

Interaction N: [Description]

• Trigger: Tap/Swipe/Hover/Form submit
• Element: [Figma layer name]
• Destination: [Figma frame name]
• Animation: Instant/Dissolve/Push left/Push right/Slide up
• Timing: [ms]
• Reset after: Yes/No

3. Prototype Flow Diagram

[Start frame]
  -> Tap "Action"
[Next frame]
  -> Tap "Complete" -> [Success frame]
  -> Tap "Cancel"   -> [Back to start]

4. Test Task Scripts

Task N: [Title]

Scenario (read to participant): "[Realistic scenario giving context without directing the click path]"

Observing:

• [What to watch for]

Success when: [Specific trigger]

5. Figma Setup Guide

• Starting frame: [Name]
• Device preview: [Device]
• Prototype settings: background colour, show device, type
• Sharing: Can view link, reset process between participants

6. Build vs Fake Table

Element	Build	Fake	Notes
Primary CTA flow	Yes		Core to research
Secondary nav		Yes	Not being tested
Error state	Yes		Testing recovery

Quality Checks

• Scope limited to what the research question requires
• Every interaction has a named destination frame
• Task scripts are scenario-based (not "click on X")
• Success criteria defined for each task
• Reset process defined for between participants

Anti-Patterns

• Do not prototype everything — scope must be limited to the interactions that answer the specific research questions
• Do not design prototype flows without also writing the test task scripts — the two must align exactly
• Do not skip the reset process between participants — unsettled prototype state contaminates results
• Do not plan a prototype without specifying which interactions are clickable vs static — ambiguity causes scope creep
• Do not scope a prototype without first defining the research questions it needs to answer

Example Trigger Phrases

• "Plan the Figma prototype for our user test on [feature]"
• "What interactions do I need to build for this prototype?"
• "Help me set up a Figma prototype for [research question]"
• "Write the test task scripts for our [feature] prototype"
• "What should I prototype vs leave as static screens?"