Latency changes behavior. A button that returns in 200 milliseconds invites exploration. The same button at eight seconds becomes a commitment. Users click less, batch more, and stop trusting the screen.
That is a product decision whether anyone names it or not.
The mistake is treating latency as a backend concern until it becomes a complaint. By then users have already built habits around the delay. They open another tab. They refresh. They ask support whether the action worked. The product now has a performance problem and a trust problem.
Choose the promise
Not every action has to be instant. Some work is slow. The product still owes a promise:
- Instant: the result appears now.
- Queued: the work is accepted and tracked.
- Async: the user can leave and get a receipt later.
What fails is pretending slow work is instant. A spinner with no state is not honesty. It is avoidance.
Latency belongs in product specs. It defines the shape of the workflow as much as permissions or pricing. If the user has to wait, design the waiting.