Optimistic UI is an anti-pattern

Optimistic UI is often held up as a paragon of optimal interface design. Should it be?

What is Optimistic UI?

To understand what an "Optimistic" user interface is, it’s helpful to take a step back in history. Let’s hop in my time machine and head way, way, WAY back to 1986. There you will find many wonderful things that no longer exist: The A-team. Max Headroom. And the Typewriter.

If you were to take that typewriter and press one of those wonderfully clicky buttons, say... the "M" button, what would happen? A little arm would swing up and slap the paper with a tiny, inked-up letter M. Letter printed. There is an instant, physical connection between the action and the result.

Now, let’s say that right next to that typewriter was a brand-new IBM PC. Looks a bit different from the computer you'd use today, but has the same basic parts. Including a good keyboard.

So you’ve got the PC booted up. You’re staring at the DOS prompt. When you press the "M" button on the keyboard, an "M" appears on the screen a split second later.

Seems a lot like the typewriter, yeah? Well, no. It’s not.

In that split second, a whole bunch of things had to happen before that little "M" appeared on the screen (

). Sometimes, one or more of those things are delayed. Even with a short delay, the disconnect in time between pressing the keyboard button and displaying the character on the screen has awful effects on user experience. It destroys the illusion that your interaction is in real-time, like a typewriter.

Now, imagine the delay if you sent that keyboard signal out across the internet to a distant computer and waited for the response before displaying the character. Well, that is essentially what happens with web-based interfaces that rely on server state directly – what you might call, "Pessimistic UI".

Optimistic UI is a philosophy aiming to fix that problem. Let’s look at a description of an Optimistic User Interface:

In a web-based app, the server is the canonical source of truth. Your client-side state is just a cached copy. It’s not available to others – or, by default, to you after a refresh.

In order to make that local state into canon, you have to ship it off to the server. That means delays. And, as mentioned earlier, users hate those delays. Optimistic UI solves that problem by... well, by being optimistic.

Assume the operation will succeed! The vast majority of the time, you’ll be correct. Instead of waiting for several network and server processes, the user can see the result of their action immediately. Snappier user interfaces mean happier users, so this is a great thing. In theory.

As with many good things, the danger is in the edge cases. For example, what happens when the operation fails when executed after you tell the user everything went well? You need to display an error state and hope that the user notices it. But you’ve already told them everything went fine!

For illustrative purposes, an example: On my last day at a previous job, I shared my contact information via my team’s Slack channel. Some folks already had my info, but I wanted to make sure it was available to everyone. So I wrote a little "So long!" note, attached my personal contact info, sent it, and signed off.

I only found out later that message didn't actually send! Even though the UI showed me that the message posted to the channel. Because of the optimistic UI approach, I ended up feeling awful — as if I had left without saying goodbye. A helpful tip for anyone building a service: never leave your users feeling awful.

So now you understand some potential dangers of Optimistic UI design. But what are the alternatives?

Pessimistic UI

As described previously, most digital interfaces before the optimistic UI philosophy used a pessimistic approach. When a user initiates an operation, the client sends the update to the server and doesn't show the result until it gets confirmation from the server that everything worked successfully. This approach gives us confidence that we're never showing the user incorrect state.

Unfortunately, it also means a lot of waiting for the user, which sucks. Slow interfaces feel broken. Can you imagine turning a screwdriver and then waiting 3 seconds for the screw to turn? Every screw on earth would be stripped.

So, what's the solution? How do we balance the confidence of Pessimistic UI with the speed of Optimistic UI?

Let's talk about Realistic UI.

Realistic UI

Between the slow-but-reliable approach of Pessimistic UIs and the fast-but-awkward approach of Optimistic UIs is a hybrid approach: Realistic UI.

The core principle of Realistic UI is being honest with the user while also prioritizing instantaneous feedback. Typically, this involves showing the successful state as the optimistic approach does, but — here’s the difference — adding an obvious indicator that the operation is not yet finalized.

Imagine a switch that toggles when clicked but shows a spinner icon while the client waits for confirmation from the server. It’s only a small addition in work compared to the optimistic approach, but avoids the pitfalls of misleading the user into thinking the operation is completed when it's not.

Some advantages of Realistic UI:

• Instant feedback to the user that their action is being processed
• Straightforward, honest presentation of the state of the source of truth
• Reduced chance of causing the user to hate you later

Is it all upside? No, there is a bit of extra work involved with this approach. There is the possibility of adding too much visual noise. For some interface elements, it’s not the right fit.

But as a rule, trying to be honest with your user about the state of the system is a good thing. An interface that reacts quickly is a good thing. So Realistic UI is a good thing.

P.S.

You probably didn't read this whole post just so I could give a wishy-washy suggestion, so here goes: Realistic UI should be the default choice for interface design.

Tell me why I’m wrong! 👇