UI/UX Design Basics for Marketers · Wireframes, UI patterns and prototypes · lesson 10 of 21 · 10 min

Prototyping and handoff

Testing before building

A prototype is an interactive simulation of an experience — clickable screens that let people try a flow before it's built. Prototypes are cheap to change; live websites and apps are not.

Prototype fidelity

| Type | Description | Use | |---|---|---| | Paper prototype | Sketches you "operate" by swapping papers | Very early concept tests | | Clickable wireframes | Low/mid-fi screens linked together | Test flows and structure | | High-fidelity prototype | Near-final visuals, interactions, transitions | Test details, get approval, guide developers | | Coded prototype / staging page | Real page not yet public | Test performance, real data |

Match fidelity to the question. "Can users find pricing?" needs clickable wireframes. "Does the new visual style feel premium?" needs high fidelity.

Building a clickable prototype (tool-neutral)

In Figma-style tools, prototypes are made by linking frames with interactions:

Create a frame per screen or state (landing page, form, error, confirmation).
Add hotspots/links: "On tap → navigate to Confirmation".
Add overlays for modals and menus.
Set the device frame (e.g. a common phone size) for mobile tests.
Define a starting point for each flow you'll test.
Share a link for testing and review.

Many landing-page builders and no-code tools let you build real pages quickly too — sometimes a live unpublished page is the fastest prototype.

What to prototype

Prototype the parts where uncertainty or risk is highest:

New flows (booking, checkout, onboarding).
Pages with high traffic or high spend.
Complex interactions (filters, calculators, pricing toggles).
Content order and messaging for key pages.

Design handoff to developers

Handoff is where good designs get lost. Reduce friction:

Handoff checklist
[ ] Final designs for mobile, tablet, desktop (or defined breakpoints)
[ ] All states: hover, focus, error, loading, empty, success
[ ] Spacing, typography and colors as tokens/styles
[ ] Components named consistently with the codebase (where it exists)
[ ] Assets exported (SVG icons, optimized images) with naming
[ ] Interaction notes: animations, sticky elements, modals, scroll behavior
[ ] Content: final copy, alt text, error messages, microcopy
[ ] Accessibility notes: heading levels, labels, focus order, contrast verified
[ ] Tracking plan: events to measure (e.g. CTA clicks, form submits)
[ ] Acceptance criteria: what "done" looks like

Design tools increasingly provide developer modes with measurements and code snippets, but conversations still matter. Walk developers through the flow and invite questions early.

Working with no-code builders

Marketers often build pages themselves in website or landing-page builders. The same discipline applies:

Build from approved sections/blocks.
Check every breakpoint — builders often produce odd mobile layouts unless adjusted.
Test forms end to end (does the submission arrive? is the confirmation right? does the CRM receive it?).
Check page speed and accessibility before launch.

Quality assurance before launch

Pre-launch QA
[ ] Works on at least one iOS and one Android phone, and major browsers
[ ] All links and buttons go to the right place
[ ] Forms submit, validate, confirm and store data correctly
[ ] Tracking events fire (and consent rules respected)
[ ] Page loads acceptably on mobile data
[ ] Keyboard navigation and focus visible
[ ] Spelling, prices, dates, legal text checked
[ ] Right-to-left layouts correct (if applicable)

Worked example: a new checkout step

A small online shop wants to add a "gift message" option.

Clickable prototype with two versions: checkbox that reveals a text field vs. a separate step.
Five quick tests: the checkbox version was faster and less confusing.
Handoff: states designed (empty, typing, character limit reached, error), copy for helper text, tracking event "gift_message_added".
QA: tested on two phones, confirmed the message appears on the packing slip.

Common mistakes

Skipping prototypes for high-risk flows.
Prototypes that only show the happy path.
Handing over designs without states, copy or accessibility notes.
Launching without end-to-end form and tracking tests.

Hands-on: build and share a clickable prototype in Figma

One frame per screen or state: Landing, Form, Form – error, Confirmation. Use the same phone preset for all.
Switch to the Prototype tab in the right sidebar. Select the CTA button, drag the blue connector to the Form frame, and set On tap → Navigate to with a Smart animate or Instant transition.
Add the error path: connect the submit button in Form to Form – error for one task version, and to Confirmation for another, or use a variable and conditional logic if you are comfortable with advanced prototyping.
Overlays for modals and menus: set the interaction to Open overlay, position it, and enable "Close when clicking outside".
Set a flow starting point on Landing and name the flow ("Register — mobile").
Present and share: click Present (the play icon), then Share prototype, and give testers view access. Check the device frame and scaling on your own phone first.

Handoff for the AI-assisted era

Design tools now offer Dev Mode views, annotations and "ready for dev" statuses, and AI coding assistants can read designs through Figma's MCP server. None of that replaces a clear handoff note. Add this to the top of every file you hand over:

## Handoff: Webinar registration — mobile v3
Status: Ready for dev (2026-09-18)   Owner: Sana (design)   Dev: Omar
Flows: Register (happy path), Email error, Already registered
Breakpoints: 360 / 768 / 1280
Components: Button, Input, Card from Brand Library v4 (Code Connect mapped)
States designed: default, focus, error, loading, success, empty
Copy: final (see "Copy" page); alt text in layer descriptions
Accessibility: headings H1>H2 order noted; labels visible; contrast checked; focus order numbered
Tracking: cta_click, form_start, generate_lead (consent-aware)
Acceptance: works at 320px, keyboard-only, in Instagram in-app browser; no layout shift on load
Open questions: calendar link behavior inside in-app browsers

How to measure success

Count issues found in prototype tests versus issues found after launch; a good prototyping habit shifts problems earlier, when they are cheap. For handoff, track the number of design-vs-build discrepancies found in QA and the time from "ready for dev" to launch.

Summary

Prototype at the fidelity your question needs, focus on high-risk parts, hand off with states, tokens, copy, accessibility and tracking notes, and QA end to end before launch.

Video lecture: Prototyping and handoff

Lecture coming soon · 12 chapters · about 8 minutes. Read the full transcript below.

Prototyping and handoff
What a prototype is
Match fidelity to the question
What to prototype
Worked example 1: gift message option
Worked example 2: onboarding (illustrative)
Watch me do it: clickable prototype
Complete handoff
No-code builders and pre-launch QA
Testing a prototype
Common mistakes and measures
Recap and try this now

Lecture transcript

Prototyping and handoff

Here's a painful story. A shop spends two weeks building a new checkout step. It launches on a Friday. By Monday, customer service is flooded with confused messages, and the team spends another two weeks fixing it. The frustrating part? Five people clicking through a prototype for twenty minutes each would have caught the problem before anyone wrote code. In this lecture, you'll learn what prototypes are and how to match fidelity to your question, what to prototype first, how to build a clickable prototype in Figma, how to hand off designs developers can build correctly, and how to QA before launch.

What a prototype is

A prototype is an interactive simulation of an experience. Clickable screens that let people try a flow before it's built. Why does it matter? Because prototypes are cheap to change, and live websites are not. Think of a dress rehearsal in theater. The actors walk through the whole show with props and costumes before opening night. Mistakes in rehearsal are funny. Mistakes on opening night are expensive. A prototype is your dress rehearsal. You find the confusing moments while fixing them still takes minutes, not sprints.

Match fidelity to the question

Match fidelity to your question. A paper prototype, sketches you operate by swapping sheets, is perfect for very early concept tests. Clickable wireframes, with low or mid-fidelity screens linked together, test flows and structure. A high-fidelity prototype with near-final visuals tests details, gets approval and guides developers. And a coded prototype or unpublished staging page tests performance and real data. So, can users find pricing? Clickable wireframes will do. Does the new visual style feel premium? You need high fidelity. Don't spend a week polishing visuals to answer a structural question.

What to prototype

What should you prototype? The parts where uncertainty or risk is highest. New flows, like booking, checkout or onboarding. Pages with high traffic or high ad spend, where a small problem costs a lot. Complex interactions, like filters, calculators or pricing toggles. And the content order and messaging on key pages. What don't you need to prototype? Small copy tweaks on low-traffic pages, or well-understood patterns you've tested before. Here's the key idea. Prototype in proportion to risk.

Worked example 1: gift message option

Worked example one, simple. A small online shop wants to add a gift message option at checkout. They build two clickable prototypes. Version A: a checkbox that reveals a text field. Version B: a separate gift step. Five customers try both over video calls. The checkbox version is faster and causes less confusion, because the separate step makes people think they're being upsold. In handoff, the designer includes every state: empty, typing, character limit reached, and error. Plus helper copy, and a tracking event called gift message added. QA confirms the message actually prints on the packing slip.

Worked example 2: onboarding (illustrative)

Worked example two, a business scenario with illustrative numbers. An education startup in Islamabad plans a new onboarding flow for parents, expected to take a developer three weeks. Instead, the designer builds a high-fidelity prototype in two days and tests it with six parents. Four of them stall on the same screen, which asks them to choose between two plan names that mean nothing to them. The fix, renaming the plans by outcome and adding a one-line comparison, takes an hour in the prototype. The developer builds the corrected version once. No launch-week firefighting.

Watch me do it: clickable prototype

Watch me do it in Figma. I create one frame for each screen or state: landing, form, form with error, and confirmation. I switch to the prototype tab. I select the call to action button, drag the blue connector to the form frame, and set on tap, navigate to. I connect the submit button to the confirmation frame. For the menu, I use open overlay and turn on close when clicking outside. I set a flow starting point on the landing frame and name the flow register, mobile. Then I press present, test it on my own phone, and share the prototype link with view access.

Complete handoff

Now handoff, which is where good designs often get lost. Developers need more than pretty screens. They need final designs for each breakpoint. Every state, including hover, focus, error, loading, empty and success. Spacing, type and colors as tokens or variables. Components named like the ones in the codebase. Exported assets. Interaction notes for animations, sticky elements and modals. Final copy, alt text and error messages. Accessibility notes on heading order, labels and focus order. A tracking plan. And acceptance criteria, meaning what done looks like. Dev Mode and the MCP server help, but a short handoff note at the top of the file still saves hours.

No-code builders and pre-launch QA

Many marketers build pages themselves in no-code builders. The same discipline applies. Build from approved sections. Check every breakpoint, because builders often produce odd mobile layouts unless you adjust them. And test the form end to end. Does the submission actually arrive? Is the confirmation right? Does your CRM receive the lead? Then run pre-launch QA. At least one iPhone and one Android phone. Every link and button. Forms submit, validate, confirm and store data. Tracking fires and respects consent. Acceptable load on mobile data. Keyboard navigation with visible focus. Prices, dates and legal text checked. Right to left layouts correct, if you have them.

Testing a prototype

How do you actually test a prototype? Keep it simple. Recruit three to five people who match your audience. Give each person a realistic scenario, like you want to join next week's webinar, see if you can sign up, rather than click the green button. Ask them to think aloud. Stay quiet, and don't rescue them when they get stuck, because that's exactly the moment you need to see. Note where they hesitate, what they expected to happen, and what they said. Prototypes do have limits. People know nothing is real, so they may skip reading or accept slow steps. Use prototypes for flow and comprehension, and confirm performance and real data on a staging page.

Common mistakes and measures

Common mistakes. Skipping prototypes for high-risk flows. Prototypes that only show the happy path, with no error or empty states. Handing over designs without states, copy or accessibility notes. Launching without testing forms and tracking end to end. And assuming that because a form says thanks, the lead reached the CRM. How do you measure success? Compare issues found in prototype tests with issues found after launch. A good prototyping habit shifts problems earlier, when they're cheap. For handoff, track design versus build mismatches found in QA, and the time from ready for dev to launch.

Recap and try this now

Let's recap. Prototype at the fidelity your question needs, and focus on the riskiest parts. Build clickable prototypes with one frame per screen and state, including errors. Hand off with states, tokens, copy, accessibility notes, tracking and acceptance criteria. And QA forms, tracking, devices and accessibility end to end before launch. Try this now. Build a clickable prototype of one flow, like sign-up to confirmation, including at least one error state. Test it with two or three people. Then write a handoff note for it using the template in the lesson.

Key takeaways

Prototypes let you test flows cheaply before building.
Match prototype fidelity to the question you're trying to answer.
Complete handoff includes states, tokens, copy, accessibility and tracking notes.
QA forms, tracking, devices and accessibility end to end before launch.

Try it

Build a clickable prototype of one flow (for example sign-up to confirmation) including one error state. Then write a handoff checklist for it using the template.