Engineering metrics pass. Why do users still call it slow?
Same 5-second request races blank freeze, spinner, streaming, and visible steps side by side—feel how identical wall-clock time can differ 3× in feel; then meet three timing quirks of the user's stopwatch
THE QUESTION THIS PAGE ANSWERS
ANSWER FIRSTEngineering metrics pass. Why do users still call it slow?
Same 5-second request races blank freeze, spinner, streaming, and visible steps side by side—feel how identical wall-clock time can differ 3× in feel; then meet three timing quirks of the user's stopwatch
Turn taste into a behavior the product can repeat. The useful outcome is not a nice opinion. It is a visible rule, a small example, and a way to tell when the experience falls below the bar.
Capture one before-and-after example that shows the quality bar without extra explanation.
Polish that improves the surface while leaving the user's uncertainty untouched.
The four panels below share one request: same question, same 5 seconds to a full answer. The only difference: what you show the user during those 5 seconds. Hit the button to start all four at once, and notice how each feels.
Option A · Blank freeze
Give nothingOption B · Spinner wait
Shows it's aliveOption C · Streaming
Give part firstOption D · Visible steps
Show what it's doingMost people found the blank panel worst. Blank isn't just unpleasant—it has a hidden cost: it inflates your estimate of how long you waited. Perceived-time research calls timing while you attend to time itself prospective timing: the more attention you park on time, the more subjective duration balloons, and anxiety stretches it further. Zakay and Block's attentional-gate model is the most-cited account. Here's the conclusion up front—measuring it yourself is more convincing.
After you tap Start, the left panel enters a wait with no progress, no spinner, no copy. Stop when it feels like 8 seconds. Try not to count beats in your head—that's cheating.
That's the bill blank freeze runs that never shows in the backend: the server logs 5 seconds, the user logs six and a half. Overestimation on no-feedback waits—20–30% is common in experiments. Your product's “felt latency” is worse than the P99 on the monitoring panel, and the gap is decided by the UI.
If the stopwatch runs in the user's head, spend the engineering budget on the interval they time. Below, this chatbot's total duration is locked at 5 seconds; you move one knob only: TTFT—time to first token (from send to seeing the first character). Drag the slider, hit Replay; the right side replays the typing stream at that TTFT, and the feel score moves with it.
Package the feel above into three reusable rules. Each tier has a mini demo—switch through all three.
The user's clock starts on Send and stops at the first character. After that, attention goes to reading—tokens arriving while they read barely enter the waiting ledger. Engineering watches total-duration P99; users only remember first token. When the two watches disagree, bad reviews slip through the crack. How long the TTFT lever is in Experiment 3 comes from this quirk.
Same wait: answer lands at 5 seconds. Flip the two endings and watch remembered duration change.
Physically it's the same 5 seconds. Retrospective time is rebuilt after the fact—the worse the mood, the longer the reconstructed wait. So latency and hallucination often share one bad-review sentence: slow and dumb. Answer quality gets blamed onto speed; conversely, a good answer can cover for some of the slowness. Lesson 4 on the peak-end rule puts this into ending design.
AI products have three native flaws: slow (inference takes time), wrong (hallucination never fully dies), opaque (users can't see what it's doing). Engineering can only ease these in the short run, but ratings come from perception—and perception can be designed. Streaming, model routing, semantic cache, Agent progress reports from earlier chapters each also have a psychology-switch identity. This chapter teaches when to flip them for psychological effect.
Slow, wrong, opaque—each flaw has lessons behind it; later come relationships and money. Tap a card to flip and see which user complaint each lesson targets.
Turn the feeling in “Experiment 1 · Same 5 seconds, four ways to live” into a judgment
“The four panels below share one request : same question, same 5 seconds to a full answer.” points out that AI has lowered the bar for making something usable. The skill readers need is noticing what is wrong and turning that feeling into an actionable requirement.
Watch the user's next action, not just the surface
Turn “Most people found the blank panel worst.” into observable questions: does the user know what happened, what to do next, and how to recover from an empty or failed state? Does the hierarchy make the important information visible first?
- Watch both stopwatches : the server times wall-clock duration; the user times from send to first token—give TTFT its own line in the scorecard
- Don't leave the UI blank : no-feedback waits inflate 20–30%; past 1 second give feedback, past 3 seconds give progress
- Budget first-token first : streaming, outline-first, chunked returns all schedule ahead of bigger machines
Pretty is not the same as usable
Apply “Slow, wrong, opaque—each flaw has lessons behind it;” to a second screen or flow. Record one moment of hesitation and the user action after the change; observable behavior is stronger evidence than polish alone.
From “Experiment 1 · Same 5 seconds, four ways to live” to “Experiment 2 · Calibrate your body stopwatch”
“Experiment 1 · Same 5 seconds, four ways to live” grounds the problem in “The four panels below share one request : same question, same 5 seconds to a full answer. The only difference: what you show the user during those 5 seconds. Hit the button to start all four at once, and notice…”. “Experiment 2 · Calibrate your body stopwatch” then moves it toward “Most people found the blank panel worst. Blank isn't just unpleasant—it has a hidden cost: it inflates your estimate of how long you waited . Perceived-time research calls timing while you attend to time itself…”. Together, they show that the lesson is not just a conclusion to remember, but a claim with conditions.
Carry the judgment into the next situation
For experience work, turn abstract impressions into user actions: did the person understand the state, find the next step, recover from an error, and want to continue?
- “Experiment 1 · Same 5 seconds, four ways to live”: The four panels below share one request : same question, same 5 seconds to a full answer. The only difference: what you show the user during those 5 seconds. Hit the button to start all four at once, and notice…
- “Experiment 2 · Calibrate your body stopwatch”: Most people found the blank panel worst. Blank isn't just unpleasant—it has a hidden cost: it inflates your estimate of how long you waited . Perceived-time research calls timing while you attend to time itself…
- “The closing point”: Catch errors in the moment : time memory follows mood—missing the point writes “slow” into the bad review too
The final “The closing point” brings the discussion to “Catch errors in the moment : time memory follows mood—missing the point writes “slow” into the bad review too”. The useful thing to carry forward is knowing which judgments must be revisited when input, scale, or risk changes.
✅ What this lesson wants to share
- Watch both stopwatches: the server times wall-clock duration; the user times from send to first token—give TTFT its own line in the scorecard
- Don't leave the UI blank: no-feedback waits inflate 20–30%; past 1 second give feedback, past 3 seconds give progress
- Budget first-token first: streaming, outline-first, chunked returns all schedule ahead of bigger machines
- Catch errors in the moment: time memory follows mood—missing the point writes “slow” into the bad review too
I turned one judgment from this article into a small experiment I could run today. Knowing what to observe next is more useful than simply remembering the conclusion.
After reading this, I first looked for the conditions behind the idea instead of copying the method into a project. That order made the later trade-offs much clearer.
When this judgment reaches real work, which constraint should be added first? I am curious which step matters most between reading and the first practical attempt.
No discussion on this article yet.