Every AI demo shows you the answer. The model reads the question, pauses for a beat, and produces something that looks clever. What the demo never shows is the beat itself, or the moment when the model has nothing useful to say. Those are the parts your customers actually live in, and they are usually the parts nobody designed.
An AI feature is not the answer it gives. It is the whole experience around the answer: the wait before it arrives, the half-formed version on the way, the blank screen the first time someone opens it, and the failure when the question is one it cannot handle. Get those right and a slightly imperfect feature feels trustworthy. Get them wrong and a brilliant one feels broken.
Waiting starts before the first answer
Press the button, and there is a gap before anything appears. It might be two hundred milliseconds. It might be five seconds. If nothing visible happens in that gap, people do not assume the model is thinking. They assume the button did not work, and they press it again.
There is an old piece of interface research that has not aged. People feel a response under a tenth of a second as instant. They stay in flow up to about a second, even though they notice the wait. Past ten seconds they start losing attention, and anything that slow needs both a sign that something is happening and a way to stop it. Almost every AI feature lives past one second, and plenty live past ten. So you are never in the comfortable zone where doing nothing is acceptable. The moment the request leaves, the screen has to acknowledge it.
Streaming creates new waiting states
For a long time the answer was a spinner. Now most people have watched an AI tool type an answer out word by word, and a feature that waits in silence and then drops a finished block of text feels worse than one that starts talking immediately, even when the silent one actually finishes sooner. What people judge is how long until something appears, not how long the whole answer takes.
Streaming the answer out as it forms is close to the default expectation now, but it brings its own problems that a tidy mockup skips. As the text grows, it pushes everything below it down the page, so the line someone is reading keeps moving under them. A half-finished bit of formatting, an open bold tag or a code block with no closing line, can break the layout for a second before it settles. The fixes are unglamorous: reserve the space before the text arrives so the page does not jump, and hold formatting back until it is complete rather than rendering it mid-word.
Describe real progress without inventing it
A blank spinner says "wait". "Reading your catalogue" says "wait, and here is why". People forgive a slower feature when they can see what it is busy with, which is why naming the stage, looking something up, drafting a reply, checking stock, beats an anonymous wheel turning.
The caveat matters as much as the rule. Do not narrate work the feature is not doing. A progress label that says "Analysing" while the code runs a three-second timer is just for show, and people catch on to a fake faster than they forgive a genuine wait. Show the real stages, or show a plain, calm wait. Inventing a thoughtful pause to make a feature feel cleverer than it is will quietly cost you the trust you were trying to build.
Design for empty and failed states
Two moments get skipped in almost every AI feature built from a generated mockup, because the mockup only ever renders the happy path.
The first is the empty state: the very first time someone opens the feature, before they have typed anything. A blank box with a blinking cursor tells a new user nothing about what the thing can do. One good example prompt, or a single line describing what it actually helps with, turns a dead end into a starting point.
The second is the broken state, and AI features break in more ways than ordinary ones do. The request times out. The model refuses. It returns half an answer and stops. Worst of all, it returns a confident answer that is simply wrong. A feature that handles this well does three things: it keeps whatever the person typed so they are not made to start again, it says plainly what happened in words a customer understands, and it offers a real next step, retry, rephrase, or reach a person. A feature that handles it badly clears the box, shows a red message about a "request error", and leaves the customer stranded with nobody to ask.
There is an accessibility layer under all of this that is easy to miss. The pulsing dots and the typing animation need a calm fallback for people who turn motion off in their settings, or the reassuring "thinking" state becomes a headache instead. Updates that appear while the model works should be announced to a screen reader, but not so often that they talk over themselves. We have written before about the checks that generated sites quietly fail, and the in-between states of an AI feature are exactly where those failures hide, because nobody thinks to screenshot them.
Our own products show why waiting states matter
In our own art shop, Modern Printworks, the on-site assistant answers from the real product catalogue and helps a shopper towards a basket with the right size and materials. The clever part, reading the catalogue and forming a useful reply, was never the part that took the most care. The care went into the second and a half before the reply, and into what happens when the catalogue genuinely cannot answer, so the customer is handed a useful next move rather than a shrug.
Our own Enneagram Helper product writes a personalised report for each person from their scored profile, and that writing takes real, visible time. The wait had to feel like something considered was being composed for you, not like the page had frozen. In both cases the in-between states were the design work, not an afterthought.
We build these features inside the same applications we host and maintain, which means we are the ones who get the support email when the "thinking" spinner spins forever. That is a strong incentive to design the waiting and the failing before the clever bit.
Test the waiting state before development
Here is a test worth running before any AI feature gets built. Write down four states, one sentence each: what it shows while it is working, what it shows when the answer is partway there, what it shows the first time with nothing entered, and what it shows when it fails. If you can describe all four, the feature is designed. If you can only describe the answer, you have a demo, and the gap between a demo and a feature is exactly those four sentences.
AI features rarely lose people on the answer. They lose them in the pause that felt like a crash, the blank box that gave no hint, and the failure that wiped their work and blamed them for it. Those moments are not edge cases. They are most of the experience, and they are where trust is won or lost. If you are about to add an AI feature to your site or your product and you want a second pair of eyes on how it behaves when it is thinking, partial, empty, or broken, that is the sort of thing we are happy to look at on a short call.
