Design QA for AI-built apps: 12 things AI gets wrong
AI is good at the first ninety percent of a screen. The last ten percent is where a product starts to feel cheap or cared for.
Design · Oct 7, 2026 · 6 min read
Open any app built by an AI tool and it looks fine at a glance. Look for thirty seconds longer and small things start to show. None of them is a disaster. Together they are the difference between “a demo” and “a product”.
We review a lot of AI-built screens. These are the twelve problems we see again and again, in rough order of how often they turn up.
Type and words
- Heading sizes that don't match. The same level of heading is 28px on one page and 32px on the next.
- Too many font weights. Four weights on one screen makes nothing stand out.
- Typos in buttons and headings. Body text is usually clean. Short labels are where mistakes hide.
- Filler copy. Lines that sound good and say nothing, or placeholder text that was never replaced.
Spacing and layout
- Uneven gaps between sections. One section has 64px above it and the next has 24px.
- Cards that don't line up. One card in a row sits a few pixels lower than the others.
- Content that touches the edge on mobile. Text with no side padding at phone width.
- Columns that overlap on small screens instead of stacking.
Colour and states
- Low contrast. Pale text on a coloured button, or grey text on a grey card.
- More than one “primary” colour. A blue button here, a purple one there, both meant to be the main action.
- Missing states. Nothing changes when you hover, focus or press, so the page feels dead.
- Empty and error states that were never designed. A blank area where the first-time message should be.
How to spot them quickly
Don't trust your eye alone. Check the numbers. If two headings look different, click each and compare the font size. If a gap looks tight, measure it against the one next to it.
Vizhound's inspect and spacing tools do this on the live page. Click any element to see its font size, weight, colour, padding and margin, without opening browser dev tools. When you leave a note, those facts go with it.
How to ask for the fix
Design notes work best when they point at a rule, not just one instance. Compare:
| Fixes one place | Fixes the pattern |
|---|---|
| “Make this heading 32px” | “Section headings should all be 32px. This one is 28px.” |
| “Add space above this” | “Use the same 64px gap above every section. This one has 24px.” |
| “Make this button blue” | “Primary buttons should all use the brand blue. This one is purple.” |
The second column teaches the AI the rule, so it is less likely to break it again on the next screen.
When to do design QA
Do a quick pass before anyone outside the team sees the prototype, and a proper pass before launch. It takes ten to fifteen minutes per screen the first time and much less after that, because fixed patterns tend to stay fixed.
