AI builds the happy path. Usability is everything else.

We recently audited a large product for a client, a whole family of apps behind one login, built mostly in code by engineers working with AI. At first glance it looked finished, with tidy screens, consistent type and spacing that behaved itself. Then we tried to use it, making mistakes on purpose the way an audit should, and walked three of its core journeys against Jakob Nielsen's ten usability heuristics.

The heuristics are about as old-school as our field gets. Nielsen developed them with Rolf Molich in 1990 and settled on the ten we still use in 1994, and Nielsen Norman Group says they haven't needed changing since. They're rules of thumb rather than a specification, which is why they've lasted: they describe what people need from an interface, and people haven't had an update.

What surprised us was how neatly the problems lined up. Almost all of them sat on one side of a line: the product was good at the screen where everything goes right and thin everywhere else, from the waiting and the going back to the mistake and the hundredth use. Engineers call the route where nothing goes wrong the happy path, and that, it turns out, is what AI builds.

AI is good at the screen where everything goes right. Usability is what happens on all the others.

We're not alone in seeing it. A study at this year's CHI conference scored 138 AI-generated app screens against the same ten heuristics and found them dependable on the visual side and weakest on help, error recovery, efficiency and error prevention. The examples below are simplified composites rather than screenshots, partly to keep our client anonymous and partly because the same patterns turn up in almost every AI-built interface we review.

1. Visibility of system status

The rule. Always tell people what's going on, soon enough to be useful.

What we found. A multi-step set-up with no hint of how many steps were left, and a 'Processing...' screen with a spinner and nothing else - no time limit, no retry and no clue what it was waiting for. A prompt describes the result, so the model draws the result and leaves out the wait.

Fix the process. Brief time as well as screens. For every step that waits on something, add: 'Show what we're waiting for, how long it can take, and what the user can do if it never arrives.'

2. Match between the system and the real world

The rule. Speak your users' language and follow the conventions of their world rather than the system's.

What we found. A status that read PENDING_APPROVAL in capitals, straight from the database, and a follow-up prompt that said 'Remind him' about a contact the system knew only by a phone number. The model knew what a status label looks like but not what your users call things, so it used its own words and filled the gaps with guesses.

Fix the process. Give the model your users' words before it writes any. Attach a glossary and add: 'Use only the terms in the glossary. Never show internal names, codes or statuses, and never assume anything about a person that the data doesn't tell you.'

3. User control and freedom

The rule. People take wrong turns, so every journey needs a clearly marked way back and a way out.

What we found. A set-up flow where you couldn't go back and change an earlier answer, a lone back arrow that might have meant 'previous step' or 'leave altogether', and no word on whether leaving would keep your progress. Meanwhile a notification bell sat in the header of a five-step task, inviting people to wander off halfway through.

Fix the process. Exits don't show up in a screenshot, so they have to be written down before the screens exist. Add: 'Every step can be revisited and every flow can be left. Say what happens to the user's work when they leave, and remove anything that pulls them out of a task midway.'

4. Consistency and standards

The rule. Nobody should have to wonder whether two words, buttons or actions mean the same thing.

What we found. One action called Discard, Delete and Cancel on three consecutive screens, and the same field labelled three ways. Behind it sat a design system that was really a picture of one: colours and components laid out on a page with no tokens wired behind them, so nothing cascaded and every change meant checking every screen. A model with no system invents a slightly different one on every prompt, and a system that doesn't live inside the build never stays a system for long.

Fix the process. Make consistency a constraint rather than a request. Give the tools real tokens they can read and one written vocabulary for actions, and add: 'Use only the components, tokens and action names provided. If something new seems necessary, stop and ask.'

5. Error prevention

The rule. Better than a good error message is a design that stops the error happening.

What we found. A quantity field that happily accepted the letter B, a delete control that removed an item in one tap with no confirmation and no undo, and nothing to stop the same record being entered twice. Models reach for the most general control, which is a free-text box, because it always works in a demo.

Fix the process. Ask for the most constrained control that fits the data, and make destruction reversible: 'Prefer steppers, pickers and typed inputs to free text. Every destructive action is confirmed or can be undone, and duplicates are caught before they're saved.'

6. Recognition rather than recall

The rule. Show people what they need rather than making them remember it from one screen to the next.

What we found. Screens that were flat in the way prompted interfaces usually are - boxes inside boxes, everything the same weight, and text doing the job of an icon, a colour or a shape. Rows you could tap didn't look tappable and nothing showed what you'd already selected, which is hard work for anyone reading in a second language. Nielsen Norman Group found the same flatness in AI prototyping tools, for a simple reason: a model with no direction returns the average of everything it has seen.

Fix the process. Specify hierarchy, signifiers and states as deliberately as content: 'Tappable, selected and disabled states must look different from one another. Anything needed to make a decision is visible where the decision is made.'

7. Flexibility and efficiency of use

The rule. Serve the hundredth use as well as the first, with shortcuts that stay out of a newcomer's way.

What we found. Adding five items meant opening the same picker five times, and the same round numbers were typed out in full every time. After a failure, the biggest button offered a different route, while 'Try again' (what most people want first) was the small one. A prompt describes a task once, so the model designs for the first time it's done.

Fix the process. Tell the model how the task is really used - how often, by whom and under what pressure - and add: 'This is done many times a day, often with somebody waiting. Add bulk actions, sensible defaults and one-tap shortcuts, and make the likeliest next step the primary button.'

8. Aesthetic and minimalist design

The rule. Every extra piece of information competes with the pieces that matter, so this is about signal rather than looking clean.

What we found. Screens that looked clean and explained themselves constantly: 'We ask for your email so that we can send you a confirmation' under an email field, and a line asking you to check that something had saved, right beneath the message saying it had saved. It was the oddest pattern of the lot, and the easiest to explain: you give a model your reasoning while you brief it, and the model, being literal, prints it on the screen.

Fix the process. Say so in the brief: 'The reasons in this brief are for you, not for the user. No sentence may explain the interface.' Then treat every explanatory sentence that survives as a design problem to solve, not copy to polish.

Keep the why in the brief. Reasons are for the model, not for the user.

9. Help users recognise, diagnose and recover from errors

The rule. When something goes wrong, say so in plain words, explain the problem precisely and offer a way forward.

What we found. Mostly nothing, and that was the finding: the error and validation states hadn't been designed at all. The one we did find was a dead end, a greyed-out Continue button with no explanation of what would enable it and no other way forward. Three of us spent five minutes debating what it wanted, which is a usability test of sorts.

Fix the process. Nobody describes failure while they're describing a feature, so it never gets built unless somebody asks. Add: 'For every action that can fail, design the failure: what happened, in plain words, beside the thing it concerns, with the next step. No disabled button without a reason.'

10. Help and documentation

The rule. Ideally nothing needs explaining, and where something does, the help should be easy to find and about the task in hand.

What we found. The opposite distribution. The manual was written onto every screen (see rule eight), and there was nothing at the two or three moments where a newcomer would genuinely stop and wonder. The CHI study found help and documentation among the weakest heuristics for the AI tools it tested, too.

Fix the process. Ask the question the other way round: 'Find where a first-time user would hesitate, put the help there, in context, and nowhere else.'

Why you get the happy path

Put the ten side by side and the pattern is hard to miss. The heuristics these screens passed are the ones you can check in a screenshot. The ones they failed live where a screenshot can't reach: in time (the wait, the error, the retry), between screens (the same word for the same thing, a way back) or in the user's circumstances (the hurry, the second language, the hundredth use). A prompt describes one screen at one moment, so that's what comes back.

It isn't that the model doesn't know better. In one 2025 study, a model asked to run a heuristic evaluation found about three-quarters of the usability problems in two apps, more than the experienced evaluators it was compared with, although it struggled with problems that span several screens (which rather proves the point). The knowledge is there. It just isn't applied unless somebody asks, and asking has become a design skill.

Make asking part of the process

Three habits do most of the work. Put the context where the tools can read it: real tokens, plus a plain file of what no model can guess - who the users are, the conditions they work in and the words they use. Nielsen Norman Group calls this UX-context design, and it's the same move as keeping our engineering standards in a file the tooling reads first. Review journeys rather than screens, end to end, making mistakes on purpose. Then make the ten heuristics part of done: the model takes the first pass, a designer the second, and real users get the last word.

None of the ten is new, which is the encouraging part. The tools have made drawing screens nearly free, and that leaves more time for the things Nielsen wrote down in 1994: the wait, the wrong turn, the mistake and the way back. A model will happily build every one of them. It's just waiting to be asked.