The AI-Built App Design Checklist: Six Passes That Catch It All

An AI-built app needs a design checklist for one structural reason: the builder made hundreds of visual decisions you never saw, and some of them are wrong in ways that compound. A human designer makes mistakes too, but makes them consciously; a model makes them statistically, scattering near-misses, a 15-pixel gap in an 8-point world, a fourth text size, a button color at 3.2:1 contrast, across every screen with perfect confidence. The checklist below is the audit that catches them, ordered so each pass makes the next one faster, and it assumes the single best pre-check already happened: the app was generated against a specific visual reference, a free VP0 design being the zero-cost version, because auditing output aimed at a real system is proofreading, while auditing output aimed at nothing is rewriting.

Before the checklist: confirm there is a system to check against

A checklist needs a spec, and generic AI output has none: its implicit spec is “the average of everything,” which nothing can be audited against. So the first item is meta. Write down, or pull from your VP0 reference, the five system values every later check compares to: the type scale (which sizes exist, and for what roles), the exact palette (hex values for background, text, accent, semantic colors), the spacing unit (almost always 8 points), the corner radius family, and the icon set. Ten minutes, one note file, and every ambiguous judgment call below becomes a lookup. If you cannot produce this note, stop and fix the professional-look foundations first, because a checklist applied to systemless output only documents the chaos.

The typography pass

Work screenshot by screenshot, and count before you judge. Every distinct text style on each screen: more than five is a red flag, and any style appearing exactly once anywhere in the app is almost certainly a generation accident to merge into a neighbor. Then the checks in order: one typeface family everywhere, with any second family able to justify its existence out loud; sizes drawn only from the scale in your note, no orphan 15s and 17s between deliberate 14s and 16s; weights carrying hierarchy so size does not have to do all the work; line height at 1.4 to 1.5 for body text, because generated output trends cramped; and truncation behavior verified with real long content, names that overflow, prices with many digits, German words, since models test with short placeholder strings and layouts lie until stressed.

The typography pass goes first because it is the fastest to run and the loudest to users: type hierarchy is most of what people read as “designed”, and a clean pass here upgrades every remaining screenshot before you audit anything else.

The color and contrast pass

Two questions per screen: is every color from the note’s palette, and does every text-background pair pass contrast? The first catches the model’s love of decorative drift, tinted grays, surprise gradients, a second blue that arrived with a copied component. Consolidate ruthlessly: one accent doing one job, neutrals for everything structural, semantic colors reserved for meaning. The second question is mechanical: body text at 4.5:1 minimum, large text at 3:1, checked with any contrast tool, and generated palettes fail this constantly in the same two places, light-gray metadata on white and white labels on pastel accent buttons. Fix by adjusting lightness, not hue, and re-check dark mode separately, because models frequently generate it by inversion and inverted contrast failures hide until a user hits them at night.

The spacing and layout pass

Spacing is where statistical generation shows most nakedly, because near-misses are invisible one at a time and deafening in aggregate. The check is a measurement, not an opinion: sample gaps and paddings across screens and confirm every value is a multiple of the note’s unit, with 4 permitted for fine adjustment. Then the structural sub-checks: equal-role elements share equal spacing (cards in a list, icons in a bar); related content sits closer than unrelated content, so grouping reads without borders; screen edges get consistent margins, and the safe areas, notch, home indicator, keyboard, are respected on a real device rather than a simulator screenshot. Finally, hunt the filled-every-pixel screens: generated layouts abhor emptiness, and giving a crowded screen one deliberate breath of white space is routinely the single largest perceived-quality jump in the whole audit.

The platform-behavior pass

This pass is about whether the app feels native or web-in-a-costume, and the Human Interface Guidelines are the answer key. Navigation: tab bars and back behavior where iOS thumbs expect them, no hamburger menus cosplaying as mobile design. Gestures: swipe-back works everywhere, pull-to-refresh where lists update, nothing hijacking system gestures. Controls: system-sized tap targets of at least 44 points, keyboards that match input types, pickers and sheets that are the platform’s own rather than reinvented. And the modern table stakes: Dynamic Type respected so user font-size settings do not shatter layouts, dark mode designed rather than inverted, and VoiceOver labels present on interactive elements, which generated code omits by default and which one pass through the accessibility inspector surfaces immediately.

The content and edge-state pass

The last pass swaps the demo lens for the day-one-user lens. Content first: no lorem ipsum, no “John Doe,” no $99.99 placeholders anywhere, and copy written like the product’s voice rather than a template’s, since placeholder residue is among the most common tells of an unreviewed AI build. Then the three states nobody prompts for, checked per screen: empty (what does day one look like, and does it point to one clear action), loading (skeletons where content has shape, not spinners everywhere), and error (a human sentence and a retry, not a raw exception string). Close with two full journeys on a physical phone, a brand-new user and a returning user, because flows that pass screen-by-screen still snag between screens, and the seams are where generated apps come apart: the transition that flashes white in dark mode, the keyboard that covers the field it belongs to, the back gesture that loses form state. Seams never show in screenshots, which is exactly why this pass happens on a device in your hand.

The full checklist, one screen at a time

Pass	The check	The usual finding
System note	Five values written: type scale, palette, spacing unit, radius, icons	There was no system to audit against
Typography	1 family, scale-only sizes, ≤5 styles per screen, 1.4-1.5 line height	Orphan sizes, cramped body text
Color	Palette-only colors, 4.5:1 body contrast, dark mode re-checked	Gray-on-white metadata failing WCAG
Spacing	Every gap a multiple of the unit, grouping by proximity, safe areas	15px accidents, filled-every-pixel screens
Platform	HIG navigation, 44pt targets, gestures, Dynamic Type, VoiceOver	Web idioms, missing accessibility labels
Content + edges	Real copy, empty/loading/error designed, 2 journeys on-device	Placeholder residue, raw error strings

Run it as written the first time, roughly two focused hours for a typical app, then keep it alive as a per-feature ritual: every new AI-generated screen gets the same six passes in miniature, five minutes instead of two hours, because the checklist’s real product is the habit. Builders drift; audited builders drift within the system.

What the checklist deliberately leaves out

A checklist earns trust by what it refuses to cover, and three exclusions here are deliberate. Taste calls, whether the accent should be amber or teal, whether the cards want more radius, are system-note decisions made once, not audit items relitigated per screen; the checklist enforces consistency with the decision, not the decision itself, and that separation is what keeps a two-hour audit from becoming a two-week redesign. Performance and code quality are real but belong to a different review with different tools; conflating them with the design pass is how both get skimmed. And branding beyond the system, logo, tone of voice, marketing surfaces, sits upstream: an audit can make an app coherent, but only a direction can make it distinctive, which is why the inspiration-to-system pipeline runs before generation and this checklist runs after.

The exclusions also explain when to bring in a human designer: not to run these passes, which are arithmetic, but for the two things arithmetic cannot produce, a distinctive direction worth systematizing, and novel interaction patterns no reference library covers. For everything else, the checklist plus a committed evening workflow covers the ground a first design hire used to.

Key takeaways: the AI-built app design checklist

Audit against a system, not taste: write the five system values down first, from your own decisions or a free VP0 design, because every check below becomes a lookup instead of a debate. Then six passes in order: typography (one family, scale-only sizes), color (palette-only, WCAG contrast, dark mode separately), spacing (every gap on the unit, breathing room restored), platform behavior (HIG navigation, 44pt targets, Dynamic Type, VoiceOver), and content with edge states (real copy, designed empty/loading/error, two on-device journeys). Two hours the first time, five minutes per feature after, and the compounding near-misses that make apps feel generated get caught while they are still cheap.

Frequently asked questions

What should a design checklist for an AI-built app include? Six passes, run against a written system: a system note capturing type scale, exact palette, spacing unit, radius, and icon set; a typography pass (one family, scale-only sizes, five or fewer styles per screen); a color pass (palette-only colors, WCAG contrast, dark mode checked separately); a spacing pass (every gap a multiple of the unit, safe areas respected); a platform pass (HIG navigation, 44-point targets, Dynamic Type, VoiceOver labels); and a content pass (no placeholders, designed empty, loading, and error states, two full journeys on a real device).

Why do AI-built apps need a different checklist than human-designed ones? Because the error distribution is different: humans make fewer, bigger, conscious mistakes, while models scatter confident near-misses, off-grid spacing, orphan text sizes, 3.2:1 contrast, across every screen, and each one is invisible alone but compounding in aggregate. The audit therefore leans on measurement over judgment: count text styles, check gap multiples, run the contrast numbers. A model’s mistakes are statistical, so the checklist that catches them is arithmetic.

How long does auditing an AI-generated app’s design take? Roughly two focused hours for a typical small app the first time: ten minutes writing the system note, then the six passes screen by screen, with typography and spacing consuming most of it. After the first full run it becomes a five-minute ritual per new feature, and that per-feature habit is the real payoff, since it catches drift while a fix is one prompt instead of a redesign. Auditing without a system note takes far longer and settles less, which is why the note comes first.

Can I just prompt the AI to fix its own design mistakes? Partially: models apply stated, specific constraints well, “normalize all spacing to an 8-point grid,” “merge these text styles,” and prompting the fix from your checklist findings is exactly the right workflow. What they cannot do is find the mistakes reliably or hold the system across regenerations without being retold, so the division of labor is stable: the checklist finds, with your eyes and a contrast tool, and the model fixes, with constraints quoted from your system note. Keeping the note in every prompt is what makes the fixes stick.

Does starting from a VP0 design remove the need for this checklist? It shrinks it from rewriting to proofreading, which is the honest win: generation aimed at a real system produces far fewer accidents, and the audit mostly confirms rather than repairs. You still run the passes, because builders drift between generations and the platform and edge-state checks cover behavior no visual reference can enforce. The combination is the workflow that holds up: a specific free reference in front of the builder, and this checklist behind it.