8.9 Directing AI to build good frontends

Everything in this module was setup for this chapter. The vocabulary, the principles, the states, the patterns — they all become leverage the moment you turn them into a brief the AI can’t misread and a review that catches what it gets wrong. This is the loop that separates “I generated a UI” from “I shipped a good one”: brief precisely, review against a checklist, give feedback in design language, iterate.

Key vocabulary

Design brief: A precise build request that names the component, its props (inputs), its states (incl. loading/empty/error/success), its variants, the layout, and a visual reference. It removes the AI's room to guess.
Named-element spec: Describing a screen as a list of the named elements from 8.2 (“a navbar, a card grid, a primary button, an empty state”) so the AI builds the right parts instead of inventing a layout.
Review checklist: The fixed set of checks you run over any AI-built UI before accepting it — states, spacing/tokens, semantic HTML, contrast, one primary action, responsiveness.
Design-language feedback: Iteration phrased in the terms from this module (“raise the heading weight”, “use a drawer”, “tighten spacing to the grid”) instead of vague aesthetics (“make it pop”).

Write a brief the AI can’t misread

A weak prompt (“build a settings page”) forces the AI to guess, and it guesses generic. A strong brief names six things — the component, its props, its states, its variants, the layout, and a visual reference — leaving no room to drift. Every piece you learned in this module shows up here: the four states from 8.5, the named elements from 8.2, the tokens from 8.7, the layout archetype from 8.4.

Weak prompt → a brief built from this module

WEAK:  "Build a settings page that looks good."

STRONG: "Build a <BillingSettings> page.
 Layout: master–detail — a left nav (Plan, Payment, Invoices) + a content pane;
         stacks to a single list on mobile.
 Plan section: a Card showing current plan; one PRIMARY 'Upgrade' button + a ghost
         'Cancel plan' (destructive, confirm in a modal).
 States: loading = skeleton card; error = 'Couldn't load billing' + Retry;
         empty invoices = 'No invoices yet'.
 Use our tokens.css (spacing on the 8-pt grid, one accent) and the existing <Card>/<Button>.
 Labels on every field; AA contrast; keyboard-reachable. Match the dark style in src/components/."

That brief names the layout archetype, the elements, the variants, every state, the design system, and the accessibility floor. The AI now builds your page, not a generic one.

Review what it built — every time

AI output looks finished long before it is finished. Run the same checklist over every screen it hands back; each failure maps to a one-line instruction you already know how to phrase.

AI mistake	How you catch it	What you ask for
Success-only screen	ask “what does this show while loading / on error / when empty?”	“build all four states (8.5)”
Lorem / fake data shipped	scan for placeholder text left in	“wire to real data; remove placeholders”
Inconsistent spacing/radii	eyeball gaps and corners	“snap spacing to the 8-pt grid; one radius”
Div-soup / no labels	Tab through it; check the markup	“semantic HTML, real labels, visible focus”
Low-contrast “subtle” text	check it against AA	“raise contrast to WCAG AA”
Modal for a complex flow	is it multi-step or deep-linkable?	“make this a page, not a modal (8.6)”

This is the pre-ship review. Run it before you accept any AI-built UI.

FIG 1 · the loop Brief → AI builds → review against the checklist → targeted feedback → iterate. The review step is the one beginners skip.

Give feedback in design language

The reason iteration stalls is vague feedback. “Make it nicer” gives the AI nothing; the vocabulary from this module gives it everything. “Tighten the spacing to the 8-pt grid,” “raise the heading weight for hierarchy,” “this should be a drawer, not a modal,” “add the empty state,” “the subtle text fails AA — darken it.” Each is specific, actionable, and traceable to a principle. And when you can, point rather than describe: hand the AI an existing component, a screenshot, or your token file as the reference.

01 Learning objectives

0 / 6 done

02 Curated reading

NN/g — 10 Usability Heuristics for UI Design
essential 15m — A timeless checklist to review any UI against.
Anthropic — Prompt engineering overview
optional 15m — How to phrase a precise build request.
Refactoring UI — 7 Practical Tips for Cheating at Design
optional 15m — The vocabulary to give targeted design feedback.

03 Knowledge check

knowledge check3 questions · pass ≥ 70%

01easy
You should run a fixed review checklist (states, spacing, semantic HTML, contrast…) over AI-built UI before accepting it.
02medium
A strong frontend brief to an AI names… (select all)
03medium
Which is the most useful iteration feedback to an AI?

04 Interview questions

browse all ↗

What gets asked on this topic — tap a card for how to approach it, the follow-ups, and the trap. Company tags are best-effort & sourced.

Commonly asked mid concept occasional How do you review an AI-generated UI before shipping it?
Run a fixed checklist, because AI output looks finished long before it is. Ask: does it handle all four states (loading/empty/error/success), or just success? Is spacing consistent (on a grid) and does it use the design tokens? Is the markup semantic and keyboard-reachable? Does text meet WCAG AA? Is there exactly one primary action? Is it responsive? Then scan for the classic tells — leftover lorem/placeholder data, div-soup, and a modal where a page belonged. Each failure maps to a one-line instruction.
What a strong answer covers
- Four states present, not just the happy path.
- Consistent spacing + tokens; semantic, keyboard-reachable markup.
- AA contrast; one primary action; responsive.
- Scan for lorem data, div-soup, and modal-for-everything.
Follow-ups they push on
- Which of these does AI most often get wrong?
- Why give feedback in design language instead of 'make it nicer'?
Red flag Accepting the first draft because it looks done — the review checklist is exactly what separates 'looks finished' from 'is finished'.
source: NN/g — 10 Usability Heuristics for User Interface Design ↗