UX mistakes AI tools make in every app
AI builders reliably get the happy path right and miss everything around it: what matters most on a screen, what happens when data is empty, slow or wrong, what an error actually says, and how the app behaves on a phone or with a keyboard. Check those areas before real users arrive.
On this page
Why it matters
AI app builders are very good at the screen you asked for. Describe a project tracker and you get a project tracker, with a sidebar, a list and a form, usually in minutes. What you rarely get is the thinking around the screen: what the user needs first, what happens when something goes wrong, and how the screen behaves outside the demo.
That is not a criticism of the tools. A prompt describes the happy path with sample data, so the output is the happy path with sample data. The problems show up when a real person signs up with an empty account, a slow connection and a phone.
Jakob Nielsen's 10 usability heuristics, developed with Rolf Molich in 1990, refined in 1994 and still maintained by Nielsen Norman Group, are a useful lens here. The first one, visibility of system status, and the ninth, helping users recognise, diagnose and recover from errors, cover most of what AI-built apps miss. The rest of this list is those two ideas made specific.
Work through each group on your own app. Anything you cannot tick is worth fixing before launch.
The checklist
Hierarchy and layout
Every screen has a clear first thing
- Each screen has one primary action, and it is visually the strongest element. Not three buttons of equal weight.
- The most important number or item is bigger, higher or bolder than the rest. Four identical stat cards fail this.
- Headings describe the content below them in plain words, not decorative labels or emoji.
- App screens are left-aligned for scanning. Centred text is kept for short, standalone moments like empty states.
- Related things are grouped by spacing, and unrelated things are visibly separated. Equal gaps everywhere fail this.
- Decoration that carries no meaning (gradients, glows, icons in tinted circles) has been removed or justified.
States and feedback
The app always says what it is doing
- Every list, table and chart has a designed empty state that explains what will appear and how to add the first item.
- Anything that takes longer than about a second shows that it is working. Full-page loads use a skeleton; single panels can use a spinner.
- Buttons show a pending state while a request runs, and cannot be double-submitted.
- Successful actions are confirmed where the user is looking, not only in a toast in the far corner.
- Failed requests show a message and a way to retry, not a blank panel or an endless spinner.
- A crash shows a designed error screen with a way back, not a white page.
Forms and errors
Errors help people recover
- Every input has a visible label. Placeholder text is not used as the only label.
- Error messages appear next to the field they refer to, say what went wrong in plain words and say how to fix it.
- Errors are shown with text and an icon or border, not by turning something red alone.
- Validation waits until the user has finished a field, rather than shouting while they type.
- A failed submit keeps everything the user typed.
- Destructive actions ask for confirmation or can be undone.
Navigation and flow
People can find their way and get back
- The current page is marked in the navigation.
- Every screen has a way back that does not rely on the browser button alone.
- Sign-up asks only for what is needed to start. Profile details can wait.
- A new user lands somewhere useful after sign-up, not on an empty dashboard with no next step.
- Links and buttons say where they go or what they do. No row of identical Learn more links.
- Settings, billing and sign-out are where people expect them: usually under the account menu.
Content and copy
The words are real
- No placeholder copy is left anywhere: no Lorem ipsum, no Transaction 1, no John Doe.
- Dates, money and numbers are formatted for your users' locale. A UK product shows pounds and day-month dates.
- Labels use the words your users use, not internal or database names.
- The product's main promise is stated in one plain sentence somewhere a new user will read it.
- Buttons start with a verb that says what will happen: Save changes, Send invoice, Delete project.
Mobile, touch and keyboard
It works off the happy path
- Every screen has been checked at 320px wide without sideways scrolling.
- Tap targets are at least 24 by 24 CSS pixels, or spaced so they do not overlap. Larger is better for primary actions.
- Tables either reflow into cards on mobile or scroll horizontally inside their own container.
- Every action can be reached and triggered with a keyboard, and the focus outline is visible.
- Modals and drawers can be closed with Escape and return focus to where the user was.
- Text and essential controls keep enough contrast to read outdoors on a phone.
Common misses
These are the items most likely to slip through, and why.
Empty states. The AI builds the screen with sample data, so the empty version is never seen until a real user signs up. Nielsen Norman Group's guidance on empty states is simple: say what is happening, teach what the area is for, and give a direct path to the first action. A blank white panel does none of those. Empty states, errors and loading states AI forgets has the code for all three.
Slow states. Development machines are fast and test data is small. On a real connection the same screen takes two seconds, and without a loading state it looks broken. Nielsen's response time limits still hold: about 0.1 second feels instant, about 1 second keeps the user's flow, and past 10 seconds you lose their attention. Anything over a second needs a visible sign that work is happening.
Error wording. Generated error handling tends to show one of two things: nothing, or the raw message from the server. NN/g's error message guidelines ask for messages near the problem, in plain language, with a way to fix it, and they warn against using colour or animation as the only signal. "Something went wrong" passes none of that.
Tap target size. Icon-only buttons in generated tables and toolbars are often sized to the icon, which leaves a very small target. WCAG 2.2 added success criterion 2.5.8, Target Size (Minimum), at level AA: pointer targets should be at least 24 by 24 CSS pixels, with exceptions for spacing and inline links. It is an easy fix and an easy miss.
Focus outlines. Some generated styles remove the outline on buttons and links to look cleaner. WCAG 2.2 success criterion 2.4.7, Focus Visible, at level AA, requires a visible keyboard focus indicator. The shadcn/ui components include focus rings by default; the problem is usually custom elements built around them. Making an AI-built app accessible goes through the rest.
Equal weight everywhere. A dashboard with four identical cards, a form with three identical buttons, a landing page with six identical feature tiles. Equal weight tells the user nothing is more important than anything else. Nobody prompts for it; it is a default layout, and it is a big part of why every AI-built app looks the same.
Fixing them with the tool that made them
You do not have to leave the AI builder to fix most of this list. The trick is to ask for one specific change at a time, with the detail the original prompt left out. A request to "improve the UX" tends to come back with more gradients and more icons, because that is what the model associates with improvement.
Compare these two prompts for the same problem:
- Vague: "Make the projects page better when there's no data."
- Specific: "When the projects list has no items, replace the table with an empty state: a one-line heading saying there are no projects yet, one sentence explaining that projects hold invoices and files, and a primary button that opens the New project dialog. Keep the page header and filters visible."
The second one names the condition, the content, the action and what must not change. It also gives the model a reason for the screen to exist, which steers the copy away from filler.
A few more habits that help:
- Test with an empty account first. Sign up as a new user before you test anything else. Most of the states and flow problems on this list show up in the first five minutes.
- Throttle the network. Browser developer tools can simulate a slow connection. Load every main screen on it and note where nothing tells you it is working.
- Use the keyboard only for one full task. Sign in, create something, edit it, delete it. Note every point where focus disappears or an action cannot be reached.
- Read every label out loud. If a label would not make sense to a new user over the phone, rewrite it.
- Fix one thing per prompt and check it. Batched changes are harder to review, and generated fixes sometimes undo earlier ones.
None of this needs a designer. It does need someone to decide what each screen is for, which is the part the tool cannot guess.
Next step
Pick the three screens your users touch most, usually sign-up, the main dashboard and the main create flow, and run this checklist against each one. Fix the states first, because they are where users decide whether the app works. Then fix hierarchy, because that is where they decide whether it is for them.
If the list comes back long, or you are not sure which problems matter most for your product, that is a design question as much as a build one. I am a product designer who also writes the code, so I can make the call and make the change in the same codebase. The design guide for AI-built apps covers the whole topic, FindPopups shows how I approach a real product, and the free vibe code health check covers the technical side if you want both looked at.
- Nielsen Norman Group: 10 Usability Heuristics for User Interface Design, checked 10 November 2026
- Nielsen Norman Group: Designing Empty States in Complex Applications, checked 10 November 2026
- Nielsen Norman Group: Response Times, the 3 Important Limits, checked 10 November 2026
- Nielsen Norman Group: Skeleton Screens 101, checked 10 November 2026
- Nielsen Norman Group: Error-Message Guidelines, checked 10 November 2026
- W3C: WCAG 2.2, 2.5.8 Target Size (Minimum) and 2.4.7 Focus Visible, checked 10 November 2026
- shadcn/ui docs: Button, checked 10 November 2026
Questions founders ask
Why do AI tools make the same UX mistakes?
They build what the prompt describes, which is usually the happy path with sample data. States, edge cases and priorities are rarely in the prompt, so they are rarely in the output.
Can I ask the AI tool to fix these itself?
Often, yes, if you name the problem precisely. Prompt for one fix at a time, such as an empty state for the projects list, and check the result. A vague request to improve the UX tends to add decoration rather than fix flow.
How long does a UX pass on an AI-built app take?
Going through this checklist on a small app takes an afternoon. Fixing what it finds depends on how many screens and flows the app has.
Ant
Product designer who builds MVPs, based in Nottingham. 10+ years designing digital products, and the only person at BlackFig. More about me