Define the prototype job
1- Write the exact decision the prototype must answer before opening Figma.
- Name the target user, device, entry point, and success signal.
- Cut any screen that does not reduce product, sales, or usability risk.
Template for Figma prototypes
Rapid prototypes should answer decisions, not decorate uncertainty.
Use this checklist before you build a Figma, Framer, or Webflow prototype. It keeps the work focused on the user path, the business decision, and the handoff quality a small team can actually ship.
6 phasesFrom product question to handoff decision.
18 checksConcrete items for UX, copy, states, and prototype links.
15 minutesA lean review loop before visual polish begins.
Checklist
Use one pass for each prototype revision
The goal is not to make the prototype bigger. The goal is to make the next product decision obvious enough that you can ship, test, or discard it.
Map the critical path
2- Limit the first version to one happy path and one failure path.
- Mark the moments where users must understand price, value, or next action.
- Keep reusable states for empty, loading, error, and success screens.
Build the interaction spine
3- Connect frames with realistic navigation, not static screen dumps.
- Use real labels, realistic data, and production-like button states.
- Check that every CTA has a destination and every back action works.
Run a five-minute review
4- Ask a reviewer to complete one task without verbal guidance.
- Record where they hesitate, reread, or click the wrong object.
- Fix comprehension issues before visual polish or motion details.
Score the handoff
5- Confirm developers can identify components, variants, and breakpoints.
- Add notes only where behavior is not obvious from the prototype.
- Remove decorative frames that will not be shipped or tested.
Decide ship, test, or discard
6- Ship when the prototype answers the original decision clearly.
- Run another test only when there is one unresolved behavior question.
- Discard the prototype when it became a presentation instead of a decision tool.
Copy into your project
Three prototype boards that stay useful
Create these boards in Figma before you add extra screens. They keep feedback specific and stop prototype reviews from turning into opinion rounds.
Decision board
Problem, hypothesis, target user, success metric, and the one question this prototype must answer.
Flow board
Entry point, happy path, failure path, empty state, and final conversion or learning moment.
Handoff board
Components, responsive rules, behavior notes, open risks, and the decision to ship, test, or discard.
FAQ
Prototype questions small teams ask first
Is this checklist only for Figma?
No. The workflow works for Figma, Framer, Webflow, Penpot, and clickable prototypes in product decks. Figma is the main search use case because most teams use it for UI prototyping.
How detailed should a rapid prototype be?
Detailed enough to answer one product decision. If the prototype needs onboarding text to be understood, it is probably missing a state, path, or realistic copy.
When should a solo creator stop prototyping?
Stop when the prototype has answered the purchase, signup, or usability question. More polish after that usually delays shipping without reducing risk.