AI: Explaining Latency Preserves Trust

In AI interfaces, it is not slowness that costs the most, but misunderstood waiting. Practitioners like Bilal Skiani and foundational work in ergonomics converge: a product should describe what it does rather than promise a timeframe it cannot control. Otherwise, trust erodes quietly and then breaks.

Teams Notice the Loss of Trust Too Late

Latency can be monitored and accuracy calibrated, but the degradation of trust lacks both a dashboard and a reference point. Teams discover it too late. Bilal Skiani summarizes: “Latency degrades noisily. Trust degrades silently, then suddenly.” Most software failures evolve with load or input quality; trust, however, does not follow this proportionality. It erodes with unexplained wait after unexplained wait, then collapses around an unrelated trigger.

Inaccurate Progress Messages Worsen the Problem

A progress message that describes the wrong operation is more damaging than a missed time estimate, as it installs a false model in the user's mind. Displaying “Analyzing your document” while the system is waiting for a slow network call is pure fiction. Bilal Skiani encountered this case: in an earlier version, his messages ran on a timer, regardless of the actual state. While the demonstrations seemed clean, in production the model could finish in about 400 milliseconds while the interface continued to announce ongoing processing, as the animation relied on time rather than state. The user was then left waiting for nothing.

The Anchor of the Fastest Turns Expectations into Suspicions of Failure

Users evaluate an AI product by the fastest response they have observed, not by an average. Tversky and Kahneman described anchoring: an initial value serves as a reference point, and subsequent adjustments are insufficient. In interfaces, the first quick result sets the anchor. In practice, search or export operations on a small history finish almost instantly; on a large history, they take longer, and support messages shift from “how to use” to “is it broken?” The code and architecture remain the same; only the input size varies. Without anchor resetting by the interface, “it’s generally fast” does not help: the goodwill generated by the quick case is spent by the slow case. The example reported by Bilal Skiani with his transcription tool illustrates this: a two-second return set an implicit promise; a week later, six seconds—though proportional to the length of the passage—were perceived as a failure, even though nothing had changed on the system side. “The unexplained variance,” he says, is what destroys trust.

Exposing Variance or Smoothing It: Two Misguided Ideas

Two responses dominate in the face of high variability in AI response times: exposing it raw via a uniform indicator or smoothing it with a minimum delay. The first, with a simple “thinking” that is the same for one second as it is for forty, prevents distinguishing a long calculation from a blockage. The second avoids a lightning-fast return setting an unrealistic anchor but deliberately degrades every quick response, removing a potential benefit to prevent a risk that the interface could explain. In both cases, variance is treated as the problem. However, as David Maister formulated, explained or known expectations seem shorter than uncertain ones; an acceptable variable wait becomes penalizing when it remains unexplained. This issue is central in AI products, where the same prompt can take anywhere from one to forty seconds depending on load, depth of reasoning, tool calls, and input length.

Saying What Is Happening Rather Than Promising a Delay

The challenge is no longer to display a progress indicator but to choose its content. Older studies remain relevant: a strong preference for percentages (Brad Myers), the need for continuous information (Jakob Nielsen), principles of latency and anticipation (Bruce Tognazzini), and the influence of the progress bar's behavior on perception (Chris Harrison and colleagues). When the duration is unknown, Nielsen recommends listing the processed units—such as the databases being scanned—rather than resorting to a simple indicator, deemed a “last resort” because it does not convey what is being done. Pipelines log each step and have the data to display them; the decision to show them to the waiting person is often absent. An operational approach is to name the work, not the clock: temporal anticipation (“about 10 seconds”) engages a fragile promise, while process anticipation (“scanning conversation history”) places the anchor on the activity. A missed estimate is perceived as a delay; a named process is not late since no time has been promised.