diff --git a/src/assets/optimistic_actions_thumbnail.svg b/src/assets/optimistic_actions_thumbnail.svg new file mode 100644 index 0000000..af1635b --- /dev/null +++ b/src/assets/optimistic_actions_thumbnail.svg @@ -0,0 +1,87 @@ + + + Optimistic Actions + Two coupon lists side by side. The left list, labeled "without optimism", shows three coupons each in a "Clipping…" pending state with spinners. The right list, labeled "with optimism", shows the same three coupons each immediately marked "Clipped ✓". + + + + Repetitive actions feel slow when each one waits + + + + + without optimism + + + + + 10% off — pasta + expires soon + + + + + + … + + + + $2 off — bread + members only + + + + + + … + + + + 15% off — produce + ends Friday + + + + + + … + + + each click waits for the server + cumulative delay across many clicks + + + + + + with optimism + + + + 10% off — pasta + expires soon + + Clipped ✓ + + + + $2 off — bread + members only + + Clipped ✓ + + + + 15% off — produce + ends Friday + + Clipped ✓ + + + success state lands instantly + requests reconcile in the background + + + + SPEEDPATTERNS.COM + diff --git a/src/patterns/optimistic_actions.md b/src/patterns/optimistic_actions.md new file mode 100644 index 0000000..5bc72a0 --- /dev/null +++ b/src/patterns/optimistic_actions.md @@ -0,0 +1,75 @@ +--- +layout: article.njk +title: Optimistic Actions +tags: pattern +thumbnail: /assets/optimistic_actions_thumbnail.svg +og_image: /assets/speed_patterns_og_image.jpg +order: 14 +ai_assisted: true +date: 2020-01-06 +authors: + - name: Joseph Gannon + url: https://www.linkedin.com/in/environmentalux/ + - name: Sergey Chernyshev + url: https://www.sergeychernyshev.com/ +--- + +Some user actions don't need to wait for the server to feel complete. Clipping a coupon, marking a task done, voting on a poll, adding to a wishlist — for actions like these, the user has formed an intent and moved on before the request even leaves the device. Designing the action flow around that fact is what turns a usable feature into one that feels instantaneous. + + + +## The Problem + +Even fast servers add latency that the user can feel. A 200ms round-trip is invisible on a benchmark and very visible on a coupon-clipping list, where the user is trying to clip ten coupons in five seconds. Each pause between "click" and "clipped" stacks up: + +- The user clicks ten coupon buttons +- Each one disables, shows a small spinner, then ticks to "clipped" +- The total task takes the user three or four seconds longer than it had to +- Worse, the cumulative friction makes the whole feature feel slow even if any single action is acceptable + +The same shape repeats across every product: bulk-archive in an email client, add-to-cart on a shop, like-button mash on a social feed. The cost isn't a single slow action — it's the accumulated waiting across many fast ones. + +## Solution + +Decide, at design time, that certain user actions should appear to complete instantaneously regardless of the underlying network. The action's _visible_ outcome lands on the next paint after the user's input. The actual work — the request, the response, the persistence — happens behind that outcome, not in front of it. + +This is the umbrella pattern; the specific rendering technique that delivers it is [Optimistic Rendering](/patterns/optimistic_rendering/). + +### Which actions are candidates? + +An action is a good candidate for this treatment when **all** of the following are true: + +- **High success rate.** The action almost always succeeds. If failure is common, optimism trains the user to distrust the UI +- **Local, well-defined outcome.** The new state can be expressed entirely in the client without waiting for server-assigned data +- **Doesn't gate the next step.** The user shouldn't depend on the result to make their next decision (payments and account creation are obvious counter-examples) +- **Reversible.** If the optimistic outcome turns out to be wrong, rolling back is straightforward and won't have already cascaded into other UI +- **Repetitive or fast-paced.** The benefit grows with how often the user performs the action — clipping coupons, swiping cards, reordering a list + +A coupon-clip ticks every box. A "complete checkout" button ticks none of them. + +## Why This Matters + +Google's [RAIL model](https://web.dev/articles/rail) calls out the **100ms** mark as the threshold below which an action feels instantaneous. The full **0–1s** window is workable with acknowledgment, and beyond that the user disengages. Optimistic actions move the experience squarely under 100ms — not by making the network faster, but by removing the network from the user's experience of the action. + +For repetitive workflows, this isn't just a perceived-performance win — it's a throughput win. Users complete the task faster, accumulate less waiting time, and leave the feature with the impression that it works. + +## Guidelines + +- **Choose deliberately.** Don't make every action optimistic by reflex. The decision should follow from the product/design conversation, not from a framework default +- **Plan the failure path.** Define exactly what happens when an optimistic action fails — rollback, error message, opportunity to retry. Make it specific to the action; a generic toast isn't enough for actions that matter +- **Don't be optimistic about money or identity.** Anything financial, security-critical, or legally consequential should be visibly pessimistic — the user expects, and is reassured by, an explicit confirmation +- **Combine with [Acknowledge Actions](/patterns/acknowledge_actions/) when appropriate.** Even an optimistic action can include a tiny inline confirmation ("saved", a quick check icon) that gives the user a hook to notice if anything went wrong +- **Validate the assumption with users.** "Probability of success is high" is an empirical claim, not an aesthetic one. Watch real-user metrics for the action's failure rate. If it climbs, the pattern stops paying off +- **Be honest about what's still happening.** Some users — or some operations — benefit from the small delay of an explicit confirmation. User research on the specific action will tell you whether speed or certainty is more valuable + +## Related Patterns + +- [Optimistic Rendering](/patterns/optimistic_rendering/) — the UI technique used to deliver optimistic actions; covers state management, reconciliation, and rollback +- [Acknowledge Actions](/patterns/acknowledge_actions/) — for actions that can't be optimistic but still need to feel responsive +- [Don't Use Spinners](/patterns/dont_use_spinners/) — optimism is one of the strongest tools for avoiding spinners on user actions + +## Resources + +- [Measure Performance with the RAIL Model](https://web.dev/articles/rail) on web.dev +- [Being Optimistic in UI](https://dev.to/tiagodcosta/being-optimistic-in-ui-511k) by Tiago da Costa +- [Response Times: The 3 Important Limits](https://www.nngroup.com/articles/response-times-3-important-limits/) by Jakob Nielsen