Start from the flow, not the screen 8 min live
Ask a generator for "the summary screen" and you get a summary screen. It will be plausible, centred, and it will quietly assume a flow you never described - usually one where the user reads and agrees. The expensive failure is not an ugly screen, it is a beautiful screen for a step that should not exist. Four moves, in this order: name the decision the user is making, write the flow in plain sentences, mark the one screen that carries the decision, then draft. Three of those four happen in a text file.
Cadence's shared summary, written as sentences: the meeting ends, so a summary is generated, then the user reviews and corrects it, then the user chooses what to share and with whom, and finally the recipients see it - often outside your product, in a channel you do not control. Read that back and the decision is obvious: everything hinges on step four, and step four is only trustworthy because step three exists. That is the screen that earns the design time.
LiveWriting the flow so a tool cannot wander4 min▶
A flow written as sentences is a constraint the same way a type scale is a constraint - it can be checked. Three rules make it hold:
- One sentence per step, in the user's voice. "I check the summary got the decision right before anyone else sees it." Not "review state". The voice keeps you honest about whether the step is real.
- Mark exactly one screen as decision-carrying. If two screens claim it, you have two features. Split them or pick one - and the one you pick gets the design time, the states, and the review.
- Say what happens outside your product. Cadence's summary is read in chat and email by people who never open Cadence. That constraint changes the design of step 4 more than any style choice will.
Paste the flow above the drafting prompt every time. The draft will still drift, but you will be able to see the drift instead of adopting it.
Self-studyThe invented-screen smell test3 min read▶
Generated drafts are generous. They add the screens that exist in most apps, because most apps are the training distribution: a dashboard, a settings page, an empty onboarding carousel. Two questions kill an invented screen in seconds:
- What decision does the user make here? If the answer is "they look at it", it is a report, not a screen, and it can usually be a section of something else.
- What breaks if I delete it? If nothing does, delete it. You just recovered a week of state design, copy, and review.
The same two questions work on screens humans invented in a workshop, which is the more common source of them.
What each drafting tool actually gives you 9 min live
These tools are not competing on quality of output any more; they are competing on where the artifact lands. A prototype that has to become production code and a prototype that has to become Figma layers are two different jobs, and choosing wrong costs you a rebuild. So pick the tool by destination first, then accept its handoff cost with your eyes open. Every fact in this table is from the vendors' own documentation, checked in August 2026 - and this is exactly the kind of table that goes stale, so re-check before you quote a limit to a client.
| Tool | Real artifact | Where it lands | The gate you will hit |
|---|---|---|---|
| v0 (Vercel) | Production Next.js / React / TypeScript / Tailwind / shadcn code | Dev handoff and production. Once GitHub is connected, GitHub becomes the source of truth | Free tier is 7 messages a day; Figma import needs a paid plan |
| Lovable | Full-stack app with a hosted URL, exportable as a zip or via Git sync | Production for small or internal apps - genuinely exportable | Priced by credits, with unlimited workspace members |
| Framer AI | Editable native Framer pages and components, and a published Framer site | Marketing and CMS sites. A destination, not a handoff | No documented code export - plan to stay, or plan to rebuild |
| Claude Artifacts | A single self-contained page | Concept prototype, interactive spec, stakeholder demo | No backend; outside data only through MCP connectors |
| Figma Make | Working prototype plus a downloadable code zip; paste-back into Design as layers | In-Figma prototyping. Both bridges out of it are lossy | Full seat on a paid plan to edit code; one-way GitHub push; pasted layers are "not automatically tied to your design system" |
| Figma First Draft + agent beta | Native Figma layers from a prompt; the agent (beta from May 2026) is becoming the entry point for First Draft | Inside Figma, where the rest of your design work already lives | AI features generally need a Full seat on a paid plan; Starter plans do not include Figma AI |
LiveThe Figma Make trap, spelled out4 min▶
Figma Make is the most likely tool in this list to burn a designer, precisely because it looks like the safe in-house option. Two documented behaviours to internalise:
- The GitHub push is one-way. Figma's own documentation is blunt: if you edit your code in GitHub, those changes will not appear in Figma Make and will be overwritten the next time you push. So Make is the source of truth or GitHub is - never both, and never "we will sync it later".
- Paste-back is untethered. Pasting Make output into a Design file produces layers that are "not automatically tied to your design system". They look right and they are strangers: not your components, not your variables, not maintained by anything. That is fine for a conversation and quietly poisonous in a library.
Neither is a bug. They are the handoff cost, and you can pay it deliberately - as long as you decide which direction is authoritative before anyone gets attached to the artifact.
The states generated work forgets 7 min live
A generated draft renders the happy path, because the happy path is the likely path. Real products are mostly not that. Ask for states explicitly, by name, or you will design them under deadline pressure in the last week of the project - which is where bad copy and inconsistent components come from.
LiveThe four clusters, and what to ask for5 min▶
- System states - empty, loading, partial, error, offline, no permission. Ask for: what the user sees and what they can do next in each. An empty state with no action is a dead end; an error with no retry is a support ticket.
- Content extremes - one item, five hundred items, a three-word note, a three-thousand-word note, and every string in your longest supported language. Ask for: the layout at both ends, not the comfortable middle.
- AI-specific states - low-confidence transcript, wrong speaker attribution, a summary the user has corrected. Ask for: how confidence is shown without theatre, how a correction is labelled without shaming the user, and what the recipient sees when a summary was edited.
- Permission and audience states - shared, revoked, expired, viewed by someone outside the company. Ask for: whether the person looking at this can tell who else can see it. For Cadence that is the whole feature.
The AI cluster is the one no generic template will give you, and it is where the trust in an AI product is actually built or lost.
"Design the summary screen for our AI meeting-notes app. Clean and modern."
"Cadence shared-summary screen. Flow: meeting ends → summary generated → user reviews and corrects → user chooses what to share → recipients read it outside Cadence. This screen carries the review-and-correct decision.
Required system states: empty (no summary yet), loading, partial (transcript still processing), error with retry, offline, no permission to view.
Required AI states: low-confidence passage, wrong speaker attribution, and 'edited by the organiser' shown to recipients.
Content extremes: one decision item; five hundred items; a 3,000-word note; a two-word note.
Constraints: one primary action (Share summary), everything else secondary; type on one 1.25 ratio from 16px; spacing in multiples of 8; one accent hue plus neutrals; all text meets WCAG AA against its background.
Deliver every state, not just the ideal one. Where a state is impossible, say so instead of inventing content."
Draft the screen, then climb from hierarchy ★ 14 min · everyone runs it
Draft Cadence's shared-summary screen in whichever tool your destination demands, then bring it back into the lab discipline. The lab below starts with hierarchy already on - rung one, 32 - because b1's habit is now assumed. Your job tonight is the two structure levers a drafting session controls: type scale takes you to 46, and spacing takes you to 66. Watch those two rows specifically; everything else stays where it is.
Paste your flow sentences above the prompt, then the state list, then the constraints. Ask for the review-and-correct screen only - not a suite.
Read what came back against the flow. Delete any screen you did not ask for, and note which states it silently skipped. That note is homework item two.
In the lab, add Type scale. The screen's sizes collapse onto one 1.25 ratio and the score moves to 46. Watch the type-scale row, not the picture.
Add Spacing. Every gap lands on the 8px rhythm and you are at 66. Two arithmetic changes, no taste argument, two thirds of the way up.
Stop at 66 on purpose. Contrast and one accent are b5 and b6 - and 66 is a fair honest score for a good draft that has not been systemised yet.
The states list is the cheapest credibility you will ever buy with an engineering team. Turning up to a handoff with eight states drafted, instead of one screen and a promise, changes who is trusted to make decisions on the feature. It is also the fastest way to find out that a state is impossible in the data model - which is much better news in week one than in week nine.
Try it yourself - this week ◐ 35-45 min total
- Draft the flow before the screen. Write your current feature as one sentence per step in the user's voice, and mark exactly one screen as decision-carrying.
- List every state for one real screen - system, content extremes, AI-specific, permission - then count how many of them your last generated draft actually contained. Write the number down.
- Run the same brief through two different tools from the table and compare where the artifact lands: what you can export, what you would have to rebuild, and which gate you hit first.
- Take one generated screen to 66 in the lab using only structure levers - hierarchy, type scale, spacing. No colour changes. Notice how far arithmetic alone gets you.
Official sources covered
Every tool behaviour on this page comes from the vendor's own documentation, checked in August 2026. Credit systems, seat gates and beta status in this category change monthly, so treat the table as a shape to re-verify rather than a fact to memorise. Where documentation is silent - as with Framer code export - the page says silent rather than guessing.
Three questions before you go 🎯 ◐ 90 seconds
1 · You built a screen in Figma Make, pushed it to GitHub, then an engineer edited the code there. What does Figma document will happen?
The push is one-way. Figma's documentation says edits made in GitHub will not appear in Figma Make and will be overwritten next time you push, so exactly one side has to be the source of truth. The related trap: pasting Make output back into Design produces layers that are "not automatically tied to your design system".
2 · Why write the flow before asking for the screen?
The generator will fill the gap with the likeliest flow, usually one where the user simply reads and agrees. Naming the decision, writing the steps in sentences, and marking the one decision-carrying screen keeps the draft answerable to something. A screen that carries no decision can usually be deleted.
3 · Which of these is a state a generated draft is least likely to give you unasked?
Drafts render the happy path because it is the likeliest path. The AI-specific states - low confidence, wrong speaker attribution, "edited by the organiser" - are where trust in an AI product is won or lost, and no generic template contains them. Enumerate them in the brief or design them under deadline pressure later.