Skip to content
UX Atlas
Plate PAT·013 · PatternGrid E1 · Rev. 2026-09-14

Optimistic UI

Apply the change immediately and reconcile with the server afterwards, so the interface never waits on the network.

PatternCraft conventionAdvanced

Definition

Optimistic UI updates local state as soon as the user acts, assuming success, then reconciles when the server responds. If the operation fails, the change is reverted visibly and the reason explained.

Craft convention. True because the industry converged on it. Breaking it costs familiarity, not correctness.

On this plate
  1. 1Definition
  2. 2When it is appropriate
  3. 3Being optimistic honestly
  4. 4Operation by operation
  5. 5Designing the failure path first
  6. 6The branch that decides whether to be optimistic
  7. 7In practice
  8. 8Local chart
  9. 9Continue from here

Reach for this when

  • Frequent low-risk operations.
  • Direct manipulation interactions.
  • Products that must work on unreliable connections.
  • A frequent, low-risk action would otherwise wait on a network round trip.

Common mistakes

  • Optimism applied to operations that genuinely fail often.
  • Silent reverts.
  • No retry path.

When it is appropriate

  • The operation almost always succeeds.
  • Failure is recoverable and the revert is easy to understand.
  • The user can tolerate a brief inconsistency.
  • Good candidates: likes, toggles, reordering, adding a tag, marking as read.
  • Bad candidates: payments, irreversible deletions, anything where the user will act on the assumed result before it is confirmed.

Being optimistic honestly

Do

  • Apply it where failure is rare and the correction is cheap.
  • Keep the correction visible: say what failed, and restore the previous state clearly.
  • Preserve the reader's input so a retry costs nothing.
  • Keep an eye on how often the optimism is wrong, which is a reliability signal.

Do not

  • Use it for payments, or anything else that must be true before it is shown.
  • Revert silently, which leaves the reader believing something happened.
  • Queue dozens of optimistic changes with no way to see which have landed.
  • Show success styling for a state that has not been confirmed.

Operation by operation

OperationShow it immediately?Because
Like, star, follow, mark as readYesFailure is rare, the revert is one element, and nobody acts on the result.
Reordering a list, moving a cardYesThe reader is mid-gesture and any latency reads as the interface not responding.
Sending a messageYes, marked as pendingThe message appears, with a state that changes to sent or failed. Never a silent disappearance.
Uploading a filePartlyShow the row and its progress, but not a completed state until the server has it.
Deleting somethingOnly with real undo behind itAn optimistic delete that fails has to put the item back exactly where it was, in view.
Payments, bookings, anything scarceNoThe reader will act on a success that has not happened, and the correction arrives too late to help.

Designing the failure path first

Optimistic UI is entirely a question of what happens on the rare occasion you were wrong.

  1. 1

    Keep the previous state

    You cannot restore what you did not retain. Hold it until the server confirms.

  2. 2

    Mark the change as pending

    Subtly, but visibly, so a reader watching closely can tell confirmed from assumed.

  3. 3

    Restore in place on failure

    Put the item back where it was, in view, rather than on a screen the reader has since left.

  4. 4

    Say what happened and offer retry

    A persistent message naming the action that failed, with the reader's input preserved so retrying costs nothing.

  5. 5

    Measure how often you are wrong

    A rising rollback rate is a reliability signal, and the point at which optimism stops being honest.

The branch that decides whether to be optimistic

the reader actsApplied nowmarked pendingServer confirmspending mark removedServer refusesthe case that decides thisprevious state backmessage, and retryinput preservedReverting without saying so leaves the reader believing something happened.
The top path is why teams reach for this. The bottom path is the whole design problem, and it is usually built last or not at all.

In practice

  1. i.

    Optimistic reordering

    Task tools

    Drag-and-drop reordering that waits for a server round trip feels broken. Applying the move immediately and reconciling in the background is the only acceptable behaviour for direct manipulation.

  2. ii.

    The like that came back

    Silent revert

    A like applied instantly, failed on the server and quietly reverted. The reader saw it work, and later saw it undone with no explanation, which reads as the product losing their action.

Local chart

PAT·013 · Region III · Grid E1

This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.

Help Users Recognise, Diagnose and Recover From ErrorsHEUR·009 · PRINCIPLES BEHIND THISVisibility of System StatusHEUR·001 · PRINCIPLES BEHIND THISDoherty ThresholdLAW·006 · PRINCIPLES BEHIND THISFeedbackPRIN·004 · PRINCIPLES BEHIND THISForgivenessPRIN·006 · PRINCIPLES BEHIND THISFlowPSY·005 · PRINCIPLES BEHIND THISPerformance as User ExperienceFND·054 · PRINCIPLES BEHIND THISToggle SwitchCMP·007 · OFTEN USED WITHLoading StatesPAT·011 · ALTERNATIVE APPROACHDesigning an AI Suggestion Feature People Would UseCASE·010 · PRACTICAL EXAMPLEGraceful DegradationTERM·121 · SHORT DEFINITIONInteraction DesignTERM·034 · SHORT DEFINITION

Continue from here

Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.

Applies when you are designing

A Mobile AppAn AI Product

Principles behind this

The reasoning this solution is an application of.

Often used with

These usually appear in the same screen or the same decision.

Alternative approach

A different answer to the same problem, with a different cost.

  • Loading StatesPAT·011 · Pattern

    Optimistic UI removes the wait instead of decorating it, and pays for it in rollback complexity.

Practical example

A worked decision where this was the deciding factor.

Short definition

The one-paragraph version, for when that is all you need.