interaction design
Optimistic UI
What is optimistic UI, and what's the catch?
Optimistic UI updates the screen the instant you act - as if the action had already succeeded - and quietly confirms with the server in the background. It bets that the request will work (it nearly always does), so the interface feels immediate instead of making you watch a spinner wait on the network.
Also known as: optimistic ui, optimistic update, optimistic rendering
Prefer to watch?
Watch the recap 0:48
The demo
Tap to like. Try it optimistically - updating the instant you act - then pessimistically, waiting on the network. Then make the request fail, and see what optimism owes you when it's wrong.
What this demo shows (text version)
A "like" button with a count is shown two ways. Optimistically, clicking updates the heart and the count immediately, while a quiet "saving…" confirms with the (simulated) server in the background - so it feels instant. Pessimistically, the same click shows a spinner and only updates once the simulated network round-trip returns, so you wait to see the result.
A "make the next request fail" switch shows the part optimism can't skip: when the background save fails, the demo rolls the like back to its previous state and tells you it didn't save. That honest recovery is the price of optimistic UI - which is why it suits high-success, low-stakes, reversible actions, and why consequential actions should wait for real confirmation instead.
Optimistic UI shows the result immediately and reconciles with the server afterwards, so an action feels instant even over a slow network - because most requests do succeed. The catch is the rare failure: you must detect it, roll the change back clearly, and tell the user, or you've shown them a success that never happened. Use it for high-success, low-stakes, reversible actions; wait for confirmation on the rest.
Optimistically, the action felt done the instant you tapped - no spinner, no wait, because the screen didn't ask the network's permission first. Pessimistically, the same tap left you watching a loader while the request travelled and returned. Same outcome; one just stopped making you wait to see it.
It works because it removes the network from the user's perception of speed. Most requests succeed, so showing the result first and confirming after is honest the vast majority of the time - and it keeps the interface inside the Doherty-threshold window where it feels instant rather than laggy. Likes, toggles, adding to a list, sending a message: all classic fits.
The catch is the failure case, and it's non-negotiable. If the request does fail, you've already told the user it worked - so you must notice, undo the optimistic change, and say what happened, clearly. Skip that and optimistic UI becomes a lie: a like that didn't save, a message that never sent, with the user none the wiser.
So reserve it for actions that are high-success, low-stakes and reversible. For anything consequential or hard to undo - a payment, a permanent delete, a booking - be pessimistic and wait for real confirmation. Optimism is a speed trick for the safe, common path, not a way to paper over a risky one.