Users forgive a slow answer. What breaks trust is an AI product that is fast one day, slow the next, and never says why.
Quick note: I wrote this article from firsthand experience as a founder and engineer. I co-build browser tools that run on top of several of the AI chat products mentioned here. I have no relationship with the companies that make them.
A transcription product ships. On a short clip, the result comes back in two seconds. A week later, the same user records a longer passage and waits six seconds, which is exactly how long a passage that size takes. They assume it is broken.
That story is not mine. It came from Bilal Skiani, who builds a transcription product called Genie 007 and shared it in the comments of an earlier piece of mine on waiting in AI interfaces. Nothing about the system changed between the two runs. What changed was the user’s reference point. The two-second run set the promise, and the six-second run broke it. As Bilal put it in that thread: “Variance isn’t the trust killer, unexplained variance is.”
AI products produce more of this than any software category before them. The same prompt can take one second or forty, depending on model load, reasoning depth, tool calls and input length. Most products respond to that variance in one of two ways, and both are wrong.
The fastest answer becomes the promise
Users do not judge an AI product by its average response time. They judge it against the fastest response they have personally seen. Tversky and Kahneman described the mechanism in 1974: people estimate by starting from an initial value and adjusting, and the adjustment is usually too small (Judgment under Uncertainty: Heuristics and Biases). In an interface, the first fast result is that initial value.
I see the same pattern in the tools I work on. Search and export on a small history finish almost instantly. When the same operation runs on a large history and takes longer, the support messages change character. They stop asking “how do I use this” and start asking “is this broken”. Same code, same architecture, different input size.
This is why “it’s usually fast” is not a defence. The snappy case earns goodwill that the slow case then spends, and the product never gets to choose which case the user remembers.
Two common answers, and why both fail
AI products currently handle variance by either exposing it raw or flattening it with an artificial floor, and each trades one failure for another. Raw variance means a spinner and a word like “Thinking” that looks identical at one second and at forty. The user has no way to tell a long job from a stuck one.
The floor is subtler. Some teams add a minimum delay so fast responses never set an unrealistic anchor. It works, in the narrow sense that slow runs stop feeling broken. But it erases the upside to prevent one kind of downside. Every fast answer the system could have given is now deliberately slowed, forever, to protect the user from a comparison the interface could have explained instead.
Both approaches treat variance as the problem. It is not. David Maister named the actual problem in 1985, writing about queues rather than software: “Unexplained Waits Are Longer than Explained Waits”, and “Uncertain Waits Are Longer than Known, Finite Waits” (The Psychology of Waiting Lines). A variable wait is fine. An unexplained variable wait is the one that feels broken.
The question has moved from whether to show progress to what it should say
Progress indicators are at the point error messages reached decades ago: nobody argues about whether to show one anymore, and the open question is what it should tell the user. The research to answer it has existed for a long time.
Brad Myers found in 1985 that users strongly prefer interfaces with percent-done progress indicators (The importance of percent-done progress indicators). Jakob Nielsen’s first usability heuristic asks that the design “always keep users informed about what is going on” (10 Usability Heuristics). Bruce Tognazzini lists “Keep users informed when they face delay” among his principles of latency reduction, alongside a separate principle of anticipation (First Principles of Interaction Design). Chris Harrison and colleagues later found that the behaviour of a progress bar changes how long the same wait feels (Rethinking the progress bar).
The most useful line for AI teams, though, is from Nielsen’s essay on response times, and it covers exactly the case where a system cannot know how long it will take: “a system searching an unknown number of remote databases could print the name of each database as it is processed.” A spinner, he adds, is “a last resort”, because it “does not indicate what it is doing” (Response Times: The 3 Important Limits).
Build pipelines are the cleanest non-AI example of this gap. Every command, exit code and timestamp is recorded. The status the person actually looks at is a spinner and the word “Running”. The technical problem is solved. The editorial one is not, and it is the same gap AI products have.
Name the work, not the clock
When an AI product cannot bound how long something will take, it should say what it is doing rather than how long it will take. There are two kinds of anticipation, and Bilal’s distinction between them is sharper than anything I had written before.
Time anticipation, “this takes about 10 seconds”, makes a promise about duration, so it breaks the moment reality overshoots. Process anticipation, “scanning your conversation history”, names the work. The user’s anchor sits on the work instead of the clock, so a longer run does not break a contract, because no contract about time was offered.
There is an honesty argument underneath the usability one. A time estimate is a best guess dressed as a promise. A process description is a true statement about what is happening right now. Users sense the difference over repeated use, even when they cannot name it. As Bilal put it: “One estimate being off reads as noise. A pattern reads as a character flaw.”
Some shipped AI products already do this in small ways. Anthropic’s help centre, describing how Claude handles long conversations, says: “You may occasionally see that Claude is ‘organizing its thoughts’ during long conversations”, and explains that the message means automatic context management is working (Anthropic Help Center). It names a process and promises no duration. The wording is anthropomorphic rather than literal, which is a separate debate, but the structure is the right one.
My working heuristic for when a time estimate is still acceptable, offered as a practitioner’s read rather than a study: if the worst case stays under roughly twice the estimate, “about 10 seconds” survives a 15 or 18 second run. Past about 20 it starts to bite, and past 25 it becomes a liability. If you cannot bound the worst case, do not say a number. Name the work.
A description that lies is worse than a spinner
A progress message that describes the wrong thing does more damage than a missed time estimate, because it gives the user a false model of the system that they carry into every later interaction. “Analyzing your document”, shown while the system is actually waiting on a slow network call, is not imprecise. It is fiction.
Bilal described exactly this in an earlier version of his own product. Its progress messages rotated on a timer, regardless of what the system was doing. It looked clean in demos. In production there were cases where the model finished in about 400 milliseconds while the interface was still cycling through “processing your request”, because the rotation was bound to time, not to state. The user waited for nothing.
The discipline test is simple: does the visible description change when the underlying operation changes? If it does not survive a real change of state without lying, it is narrative cover, not reporting. There is a cheap way to pass the test, tagging each major operation with its own description and switching the visible one as the system moves, and an expensive way, deriving the description from live telemetry. The trap is the third option most teams ship: descriptions written once and deployed, which look like reporting and are not.
This is also an organisational problem, not only a design one. Descriptions written once usually come from someone who is not building the state machine. The fix requires the person writing the words to know what the system actually does, which in practice means the writer and the builder sit together, or are the same person.
Trust degrades quietly, then suddenly
Latency has a dashboard and accuracy has a benchmark, but trust degradation has neither, which is why teams find out about it late. Bilal’s line for this is the one I have repeated most since: “Latency degrades loudly. Trust degrades quietly, then suddenly.”
Most failure modes in software are roughly proportional. Latency rises with load. Errors rise with bad inputs. Trust does not behave that way. It erodes one unexplained wait at a time, and then collapses around some unrelated trigger. By the time retention or ratings move, the decision to leave was made weeks earlier.
That puts process honesty in the same category as accessibility and security. All three have to be designed in rather than added on, all three are usually retrofitted by people who did not make the original decisions, and all three stay invisible until something breaks. For trust, the thing that breaks is usually a support thread or a slow drift in a retention curve.
The practical response is to own at least one leading indicator for trust rather than waiting for lagging ones. Watch session recordings for users opening a second tab to check whether something is still working. Track the kind of support question people ask, not only the number. Those shifts show up months before churn does.
Where to start
If a team can ship only one thing, it should ship anticipation before real-time feedback. A single sentence that sets the anchor before the wait, naming the work rather than the time, can be owned end to end by one person, and it sets the reference point before the user forms their own. Real-time feedback has to fight an anchor that already exists.
The second step is coupling: bind each description to the state it describes, so the words change when the work changes. The third is measurement: decide how you will notice trust eroding before a retention chart tells you.
None of this requires removing variance. AI systems will keep being fast sometimes and slow other times. What users need is a product that tells them which one is happening, in words that stay true while it happens. Or, as Bilal said when we discussed how much of this a small team can realistically build: “A shipped sentence beats a coordinated system that never ships.”
Thanks to Bilal Skiani, whose comments on my earlier piece about waiting in AI products shaped most of this one, and who shared the production cases from Genie 007 quoted above.
Follow me on Medium for more essays on AI UX and the design reality of building for global audiences.
About the author: Adi Leviim is a full-stack engineer and product builder with 7+ years of experience shipping commercial software to global audiences. He writes about AI UX, the design reality of building for millions of users, and the gap between AI demos and production AI. Follow him on Medium for essays at the intersection of engineering and design.
The variance problem in AI products was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.
