When a system is fast, the user trusts it. When it is slow, they do not, even when the slowness is justified. This is not a rational response. It is a near-universal one. Speed is not a performance metric. It is a trust metric, and I design for it accordingly.
The interesting subtlety is that perceived speed and actual speed are not the same thing. A system can be fast and feel slow if it does not communicate what it is doing. A system can be slower than its peers and still feel fast if it manages perception well.
The hundred-millisecond rule
There is a well-established threshold in interface design at around one hundred milliseconds. Below that, the user perceives a response as instantaneous. Above it, they perceive a delay. The exact number varies, but the principle holds across decades of research.
For most user-initiated actions in this product, I work hard to be under the hundred-millisecond threshold for the first visible feedback. Not the completed action. The first visible acknowledgement. A button-state change. A spinner. A row that begins to leave the list. The user clicks, and within a hundred milliseconds, something has visibly happened.
This does not mean the action itself is complete in a hundred milliseconds. It often is not. AI generations can take seconds. Email sends can take minutes. Image renderings can take longer still. But the first visible acknowledgement of the click happens fast, because that is the part the user is measuring.
The streaming dividend
For long operations, the right strategy is not to wait until completion before showing anything. It is to stream. Whatever output the operation is producing, show it as it is produced. The user reads as the system writes. The clock continues to run, but the user is no longer waiting in silence. They are reading.
This is most visible in the chat experience. The AI's response begins streaming as soon as the first token is generated. The user is engaged with the response within a second of sending the message, even when the full response takes ten or twenty seconds. The total elapsed time is the same. The perceived experience is fundamentally different.
The same principle applies to many non-AI operations. A search that returns a thousand results should show the first ten while the rest load. An import that processes a thousand contacts should show progress as each batch completes. A long page that loads many sections should render the sections as they become available, not block on the slowest one.
The cost of pretending to be fast
There is a temptation to fake speed. Show a fake spinner that completes when the action does. Show a progress bar that is not actually tied to progress. Animate something to fill the wait.
I try not to do this. The cost of being caught is high. Once a user notices that a progress bar is theatre, every progress bar in the product becomes suspect. The trust dividend that real speed provides is destroyed by fake speed.
If I cannot stream, and I cannot complete in under a second, the message says what is happening. "Generating, this can take up to a minute." "Sending, you can navigate away." "Importing, you will be notified when done." The user trades certainty about completion for honesty about duration, and that trade is almost always worth it.
What speed unlocks
A product that feels fast is a product the user uses more often. They check it more frequently. They try more things. They are more willing to undo and redo, because each step is cheap. The compounding effect of small speed advantages is enormous.
I invest in speed not because users tell me they want it. They almost never do. I invest in speed because the products that feel fast win in the long run, and I want to win in the long run.
Latency is a tax on trust. Trust is the currency the product runs on. The arithmetic is straightforward.