A pitch prototype wins when it answers one buying question fast: does this direction feel right? Production wins when that same artifact carries tokens, motion specs, known risks, and a QA plan into engineering. Teams lose when prototypes simulate feasibility they do not have—or when handoff drops everything except screens. This playbook covers when to prototype at each fidelity, which illusions kill projects, what must ship in the handoff, and how to keep prototype work from becoming throwaway code. Treat the prototype as evidence in a decision chain, not as a gift that ends the conversation.
When does a pitch prototype beat straight build documentation?
Clients approve what they can experience. An annotated wireframe deck explains structure; a clickable flow with real copy and motion intent shows behavior. Use a prototype when stakeholders disagree on direction, when scroll or transition quality is the product differentiator, or when budget conversations need a concrete object to react to. Use documentation-only paths when requirements are stable, the design system is already trusted, and no one is debating feel—then speed matters more than persuasion. A prototype is a decision tool: if the next meeting still needs debate, build the artifact that ends the debate.
Fidelity should track the decision you need, not the time you have. Early: explore structure and priority. Mid: validate flows, content density, and interaction logic. High: prove motion timing, reduced-motion behavior, and edge states before engineering commits. The mistake is jumping to polish that hides open questions. For the strategic trade-off, see prototype-first vs build-first. If the pitch already won, continue with the full pitch-to-production playbook and the guides hub. When the build starts, the same fidelity logic reappears as sprint planning: highest-risk questions first, cosmetic certainty last.
What fidelity levels should a pitch use?
Match fidelity to the decision. Each level below has a job, a cost, and a failure mode when misused. Move up a level only when the previous level’s question is answered and recorded—otherwise teams re-litigate settled structure while polishing screens.
| Level | What it proves | Best moment | Failure mode |
|---|---|---|---|
| Sketch / lo-fi flow | Information order, task paths, scope boundaries | Kickoff and scope negotiation | Styling debates too early; false confidence on content length |
| Wireframe prototype | Navigation, hierarchy, component inventory | Aligning stakeholders on structure | Looks “done enough”; motion and states ignored |
| Visual mid-fi | Brand fit, content density, responsive intent | Direction selection between two routes | Pixel polish without interaction logic |
| High-fi clickable | End-to-end flow, copy, empty/error states | Client approval before engineering kickoff | Simulation of APIs and data that do not exist yet |
| Motion / tech spike | Timing, easing, page transitions, performance headroom | Before promising signature interaction in the build | Hero animation that breaks under real content or input delay |
Each step upward should retire a specific risk. If it does not retire risk, it is decoration. Motion spikes must be tested against real input and rendering constraints—see page transitions and INP in Core Web Vitals and GSAP vs CSS. When a level closes no risk, stop climbing—extra fidelity then is taste, not evidence.
Which prototype illusions kill production projects?
The dangerous prototype is not the ugly one—it is the beautiful one that lies. Infinite-scroll mocks with perfectly spaced fake data collapse against real CMS variability. Instant filter transitions collapse when the query is slow. Motion that assumes every device runs cool breaks on mid-range hardware or when the main thread is busy. Hover-only navigation fails touch users. Prototypes that never show loading, empty, or error states train clients to expect perfection the first build cannot deliver. The cure: label fake data, demo the slow path once, and show an empty state before anyone asks.
Another trap: treating the prototype file as the specification when it is not. If easing curves, durations, breakpoints, and reduced-motion fallbacks live only in the designer’s head, engineering will approximate—and approximations drift. Stakeholders also fall in love with placeholder behavior—mock integrations, perfect data, impossible timing—and negotiate the real build against a fiction you created. Name the cheats out loud: “this data is sample,” “this transition is aspirational until the spike.” Early honesty is cheaper than a change order later.
Align early on what must be accessible: respect user motion preferences as defined by prefers-reduced-motion, and keep keyboard and focus paths intact from the first clickable build. If the pitch flow cannot be operated with a keyboard, stakeholders will approve a product half of users cannot drive. See the figma handoff checklist for developers.
What belongs in the handoff package?
Handoff is a contract, not a file drop. Ship five things every time. First, design tokens and naming: colors, type scale, spacing, radii, z-index rules—referenced from the source of truth, not re-typed into a spreadsheet that immediately forks. Second, motion specs: trigger, duration, easing, interruption behavior, and reduced-motion alternative for every animated element that survived approval. Third, a risk register: known fragile flows, unvalidated data assumptions, third-party embeds, and the places where the prototype cheated. Fourth, a QA plan: browsers, devices, breakpoints, performance budgets, and who signs off before client review. Fifth, content and state coverage: empty, loading, error, long-string, and edge-content examples drawn from real or realistic copy. If any of the five is missing, say so explicitly—silent gaps become week-three arguments.
Attach the prototype link beside the tokens—not instead of them. The prototype shows intent; the package makes intent executable. One named designer answers component questions for the first sprint, one engineer confirms receipt and flags gaps before coding starts, and unresolved risks stay visible until someone closes them. A handoff meeting without a written package produces nods; a package without a walkthrough produces misreads. Do both, then freeze a version tag.
When the handoff targets WordPress, pair this with the white-label Figma-to-WordPress process so component mapping, editor experience, and review gates are defined before the first commit. For QA depth, use cross-browser QA process for WordPress.
How do you keep the prototype from becoming disposable code?
Throwaway code becomes permanent the moment it works well enough to ship. Prevent that with boundaries. Decide in writing whether the prototype is a throw spike, a UI shell to keep, or production seed. Throw spikes live on a branch that never merges; UI shells must adopt the real token system before feature work continues; production seed code must pass the same review bar as any other commit. Agree on this classification before anyone opens a pull request—after a demo goes well, nobody wants to delete working code.
Map prototype components to the real component library on day one of engineering. If the prototype invented a one-off button, decide immediately whether it becomes a library variant or collapses into an existing pattern—drift starts with “temporary” exceptions. Replace hard-coded arrays with CMS-backed queries early, before screens multiply. Extract animation code into named modules with documented props so page transitions and micro-interactions can be reused. Keep the prototype in sync once: either freeze it as an approval artifact with a version tag, or maintain it as a living preview. Two sources of truth will diverge; choose one owner per artifact. See also headless WordPress vs classic for agencies and figma-to-wordpress timeline and cost.
How does the prototype feed a Motion Sprint?
A Motion Sprint converts approved interaction intent into a production motion system: inventory of animated elements, timing and easing tokens, scroll and transition patterns, reduced-motion branches, and performance checks under real content. The prototype supplies candidates; the sprint filters them. Effects that only work with empty layouts get cut. Effects that ignore user motion preferences get a fallback or get cut. Effects that survive become documented specs—in the same package engineering already uses. Keep the inventory visible so future templates inherit cuts as well as keeps.
Sequence it: hand off static structure first, then run the sprint on top of stable layout so motion work does not chase shifting boxes. Output feeds QA: every motion spec gets a manual test and a reduced-motion pass. When the system is in place, new templates inherit motion rules. See GSAP motion systems in production and motion sprint explained. Client-visible proof sits in shipped work—Mukani, Switch Sound & Music, Mujer Raíz, Leadly—while motion implementation is scoped under motion web development.
Key takeaways
- Prototype fidelity should retire a specific decision: structure, flow, brand fit, then motion—polish that hides open questions costs more later.
- Kill viability illusions early: fake data density, skipped loading/error states, hover-only paths, and motion that ignores input latency—label every cheat before approval.
- Handoff ships tokens, motion specs, a risk register, a QA plan, and edge-content states—not just a prototype link; declare prototype fate in writing.
- Freeze a version tag on approval so later scope arguments have a reference, and carry open risks into the register—not into a hopeful launch.
- Run a Motion Sprint after layout is stable so approved interaction becomes a tokenized, testable system with reduced-motion branches QA can verify.
Frequently asked questions
Should every pitch include a coded prototype?
No. Code when you must prove motion quality, performance headroom, or a risky integration. When stakeholders only need direction and flow clarity, a high-fidelity clickable prototype is faster to iterate and cheaper to discard. Match the artifact to the decision—and if the coded path is chosen, classify it as spike, shell, or seed before the first commit. Ask one question before writing a line: what decision changes if this code exists?
What is the most common handoff failure?
Motion and states living only in the prototype. Durations, easing, interruptions, reduced-motion behavior, and loading/empty/error screens never become specs, so engineering improvises and clients notice the gap between demo and launch. Put every animated element and every state into the written package before kickoff, then verify them in QA the same way you verify layout.
How do we prevent prototype code from shipping accidentally?
Name the branch policy and merge rules before coding starts. Throw spikes never merge. Shells must adopt real tokens first. Anything reaching production passes normal review—no prototype exemption. Put the policy in the repo README or the PR template so it does not live only in someone’s head.
When should a Motion Sprint start?
After static layout is stable and before template sprawl. Running motion on a moving foundation causes rework; running it too late means transitions get hard-coded per page instead of extracted into a reusable system. Freeze structural review, hand off tokens and specs, then start the sprint with the QA plan already attached.
Do we need separate QA for animation?
Yes. Animation needs checks for interruption, reduced-motion alternatives, keyboard focus visibility, and behavior under load—especially page transitions tied to input responsiveness. Fold those cases into the QA plan that ships with handoff. If the plan only lists browsers and breakpoints, add a short motion checklist before the first client review.
What if the client changes direction after high-fidelity approval?
Treat it as a scope event. Re-open the fidelity level where the decision actually changed—flow, visual, or motion—update tokens and specs, and re-tag the prototype version. Unversioned “final” files are how approval records turn into arguments. If the change touches motion, re-run the relevant spike before promising a new date.