Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

True Lies Of Optimistic User Interfaces

Three user interfaces (UIs) go to a pub. The first one orders a drink, then several more. A couple of hours later, it asks for the bill and leaves the pub drunk. The second UI orders a drink, pays for it up front, orders another drink, pays for it and so on, and in a couple of hours leaves the pub drunk. The third UI exits the pub already drunk immediately after going in — it knows how the pubs work and is efficient enough not to lose time. Have you heard of this third one? It is called an “optimistic UI.”

optimistic ui1
Optimistic UI design is not about looking at the web through rose-colored glasses — at least not only about it. (View large version2)

Recently, having discussed psychological performance optimization3 at a number of conferences dedicated to both front-end development and UX, I was surprised to see how little the topic of optimistic UI design is addressed in the community. Frankly, the term itself is not even well defined. In this article, we will find out what concepts it is based on, and we will look at some examples as well as review its psychological background. After that, we will review the concerns and main points regarding how to maintain control over this UX technique.

Further Reading on SmashingMag: Link

But before we begin, truth be told, no single thing could be called an “optimistic UI.” Rather, it is the mental model behind the implementation of an interface. Optimistic UI design has its own history and rationale.

Once Upon A Time Link

A long while ago — when the word “tweet” applied mostly to birds, Apple was on the verge of bankruptcy and people still put fax numbers on their business cards — web interfaces were quite ascetic. And the vast majority of them had not even a hint of optimism. An interaction with a button, for example, could follow a scenario similar to the following:

  1. The user clicks a button.
  2. The button is triggered into a disabled state.
  3. A call is sent to a server.
  4. A response from the server is sent back to the page.
  5. The page is reloaded to reflect the status of the response.

In the old days, interfaces were nowhere nearly as optimistic. (View large version8)

This might look quite inefficient in 2016; however, surprisingly enough, the same scenario is still used in a lot of web pages and applications and is still a part of the interaction process for many products. The reason is that it is predictable and more or less error-proof: The user knows that the action has been requested from the server (the disabled state of the button hints at this), and once the server responds, the updated page clearly indicates the end of this client-server-client interaction. The problems with this kind of interaction are quite obvious:

  • The user has to wait. By now, we know that even the shortest delay in the server’s response time has a negative effect on the user’s perception9 of the entire brand, not only on this particular page.
  • Every time the user gets a response to their action, it is presented in quite a destructive way (a new page loads, instead of the existing one being updated), which breaks the context of the user’s task and might affect their train of thought4010. Even though we are not necessarily talking about multitasking11 in this case, any switch of mental context is unpleasant. So, if an action is not inherently meant to switch contexts (online payment is a good example of when a switch is natural), switching would set up an unfriendly tone of dialogue between user and system.

Good Not-So-Old Days Link

Then, the so-called Web 2.0 arrived and provided new modes of interaction with web pages. The core of these were XMLHttpRequest and AJAX. These new modes of interaction were complemented by “spinners”: the simplest form of progress indicator, the sole purpose of which was to communicate to the user that the system is busy performing some operation. Now, we did not need to reload the page after getting a response from the server; we could just update a part of the already-rendered page instead. This made the web much more dynamic, while allowing for smoother and more engaging experiences for users. The typical interaction with a button could now look like this:

  1. The user clicks a button.
  2. The button is triggered into a disabled state, and a spinner of some kind is shown on the button to indicate the system is working.
  3. A call is sent to the server.
  4. A response from the server is sent back to the page.
  5. The visual state of the button and the page are updated according to the response status.

This new interaction model addressed one of the aforementioned problems of the old method of interaction: The update of the page happens without a destructive action, keeping the context for the user and engaging them in the interaction much better than before.


XMLHttpRequest and spinners solved one of the issues of the old methods of interaction: a destructive switch of context after the server’s response. (View large version13)

This kind of interaction pattern has been widely used everywhere in digital media. But one issue remains: Users still have to wait for a response from the server. Yes, we can make our servers respond faster, but no matter how hard we try to speed up the infrastructure, users still have to wait. Again, users do not like to wait, to put it mildly. For example, research shows14 that 78% of consumers feel negative emotions as a result of slow or unreliable websites. Moreover, according to a survey15 conducted by Harris Interactive for Tealeaf, 23% of users confess to cursing at their phones, 11% have screamed at them, and a whole 4% have actually thrown their phone when experiencing a problem with an online transaction. Delays are among those problems.


About 78% of consumers feel negative emotions as a result of slow or unreliable websites. (View large version17)

Even if you show some kind of progress indicator while the user waits, unless you are very creative with the indicator18, nowadays that is simply not enough. For the most part, people have gotten accustomed to spinners indicating a system’s slowness. Spinners are now more associated with purely passive waiting19, when the user has no option other than either to wait for the server’s response or to close the tab or application altogether. So, let’s come up with a step to improve this kind of interaction; let’s look at this concept of an optimistic UI.

Optimistic UI Link

As mentioned, an optimistic UI is nothing more than a way of handling human-computer interaction. To understand the main ideas behind it, we will stick with our “user clicks a button” scenario. But the principle will be the same for pretty much any kind of interaction that you might want to make optimistic. According to the Oxford English Dictionary20:

op-ti-mis-tic, adj. hopeful and confident about the future.

Let’s begin with the “confident about the future” part.

What do you think: How often does your server return an error on some user action? For example, does your API fail often when users click a button? Or maybe it fails a lot when users click a link? Frankly, I don’t think so. Of course, this might vary based on the API, server load, level of error-handling and other factors that you, as the front-end developer or UX specialist, might not be willing to get involved in. But as long as the API is stable and predictable and the front end properly communicates legitimate actions in the UI, then the number of errors in response to actions initiated by the user will be quite low. I would go so far as to state that they should never go above 1 to 3%. This means that in 97 to 99% of cases when the user clicks a button on a website, the server’s response should be success, with no error. This deserves to be put in a better perspective:

Optimistic UIs are based on the assumption that when the user clicks a button, the server should return a success response in 97 to 99% of cases. (View large version22)

Think about it for a moment: If we were 97 to 99% certain about a success response, we could be confident about the future of those responses — well, at least much more confident about the future than Schrödinger’s cat was. We could write a whole new story about button interaction:

  1. The user clicks a button.
  2. The visual state of the button is triggered into success mode instantly.

That’s it! At least from the user’s point of view, there is nothing more to it — no waiting, no staring at a disabled button, and not yet another annoying spinner. The interaction is seamless, without the system crudely stepping in to remind the user about itself.

An optimistic UI interaction has no place for either a disabled button or a spinner. (View large version24)

From the developer’s point of view, the complete cycle looks like this:

  1. The user clicks a button.
  2. The visual state of the button is triggered into success mode instantly.
  3. The call is sent to the server.
  4. The response from the server is sent back to the page.
  5. In 97 to 99% of cases, we know that the response will be success, and so we don’t need to bother the user.
  6. Only in the case of a failed request will the system speak up. Don’t worry about this for now — we will get to this point later in the article.

Let’s look at some examples of optimistic interactions. You are probably familiar with “like” buttons, as found on Facebook and Twitter. Let’s take a look at the latter.

It starts, obviously enough, with the click of the button. But note the visual state of the button when the user is no longer pressing or hovering over the button. It switches to the success state instantly!


After the like button is clicked, Twitter instantly updates it to the success state visually.

Let’s see what’s happening in the “Network” tab of our browser’s developer tools at this very moment.


The visual state of the button is updated independent of the server request, which is still in progress. (View large version27)

The “Network” tab shows that the server request has been sent but is still in progress. The “likes” counter number has not been incremented yet, but with the change in color, the interface is clearly communicating success to the user, even before having gotten a response from the server.

After a successful response is received from the server, the counter is updated, but the transition is much subtler than the instant color change. This provides the user with a smooth, uninterrupted experience, without any perceived waiting.

While the like button is visually in success mode, the counter is updated only after the server response confirms success. (View large version29)

Another example of optimistic interaction is seen on Facebook, with its own like button. The scenario is quite similar, except that Facebook updates the counter instantly, together with success color of the button, without waiting for the server’s response.

Facebook employs the same optimistic interaction as Twitter, except that it updates the counter instantly along with the button’s visual state.

One thing to note here, though. If we look at the server’s response time, we’ll see that it is a little over 1 second. Considering that the RAIL model recommends31 100 milliseconds as the optimal response time for a simple interaction, this would normally be way too long. However, the user does not perceive any wait time in this case because of the optimistic nature of this interaction. Nice! This is another instance of psychological performance optimization32.

But let’s face it: There is still that 1 to 3% chance that the server will return an error. Or perhaps the user is simply offline. Or, more likely, perhaps the server returns what is technically a success response but the response contains information that has to be further processed by the client. As a result, the user will not get a failure indicator, but we cannot consider the response a success either. To understand how to deal with such cases, we should understand why and how optimistic UIs work psychologically in the first place.

The Psychology Behind Optimistic UIs Link

So far, I have not heard anyone complain about the aforementioned optimistic interactions on the major social networks. So, let’s say that these examples have convinced us that optimistic UIs work. But why do they work for users? They work simply because people hate waiting. That’s it, folks! You can skip to the next part of the article.

But if you’re still reading, then you are probably interested in knowing why it is so. So, let’s dig a bit deeper into the psychological ground of this approach.


Brain studies help us to understand the psychology behind why optimistic UIs work. (View large version34)

An optimistic UI has two basic ingredients that are worth psychological analysis:

  • the fast response to the user’s action;
  • the handling of potential failures on the server, on the network and elsewhere.

Fast Response to User Action Link

When we talk about optimistic UI design, we’re talking about an optimal response time in human-computer interaction. And recommendations for this type of communication have been around since as far back as 1968. Back then, Robert B. Miller published his seminal piece “Response Time in Man-Computer Conversational Transactions35” (PDF), in which he defines as many as 17 different types of responses a user can get from a computer. One of those types Miller calls a “response to control activation” — the delay between the depressing of a key and the visual feedback. Even back in 1968, it should have not exceeded 0.1 to 0.2 seconds. Yes, the RAIL model36 is not the first to recommend this — the advice has been around for about 50 years. Miller notes, though, that even this short delay in feedback might be far too slow for skilled users. This means that, ideally, the user should get acknowledgement of their action within 100 milliseconds. This is getting into the range of one of the fastest unconscious actions the human body can perform — an eye blink. For this reason, the 100-millisecond interval is usually perceived to be instant. “Most people blink around 15 times a minute and a blink lasts on average 100 to 150 milliseconds,” says Davina Bristow37, of University College London’s Institute of Neurology, adding that this “means that overall we spend at least 9 days per year blinking.”

Because of its instant visual response (even before the actual request has finished), an optimistic UI is one of the examples of the early-completion38 techniques used in psychological performance optimization. But the fact that people like interfaces that respond in the blink of an eye should not come as a surprise to most of us, really. And it’s not hard to achieve either. Even in the old days, we disabled buttons instantly after they were clicked, and this was usually enough to acknowledge the user’s input. But a disabled state in an interface element means passive waiting39: The user cannot do anything about it and has no control over the process. And this is very frustrating for the user. That’s why we skip the disabled state altogether in an optimistic UI — we communicate a positive outcome instead of making the user wait.

Handling Potential Failure Link

Let’s get to the second interesting psychological aspect of optimistic UI design — the handling of potential failure. In general, plenty of information and articles are available on how to handle UI errors in the best possible way. However, while we will see how to handle failure later in this article, what matters most in an optimistic UI is not how we handle errors, but when we do it.

Humans naturally organize their activity into clumps, terminated by the completion of a subjectively defined purpose or sub-purpose. Sometimes we refer to these clumps as a “train of thought4010,” a “flow of thought41” (PDF) or simply a “flow42.” The flow state is characterized by peak enjoyment, energetic focus and creative concentration. During a flow, the user is completely absorbed in the activity. A tweet by Tammy Everts43 nicely illustrates this:

Sometimes, spotting a person in a flow state is pretty easy. (View large version45)

On the web, the durations of such clumps of activity are much shorter. Let’s revisit Robert B. Miller’s work for a moment. The response types he cites include:

  • a response to a simple inquiry of listed information;
  • a response to a complex inquiry in graphic form;
  • a response to “System, do you understand me?”

He ties all of these to the same 2-second interval within which the user should get the relevant type of response. Without digging deeper, we should note that this interval also depends on a person’s working memory46 (referring to the span of time within which a person can keep a certain amount of information in their head and, more importantly, be able to manipulate it). To us, as developers and UX specialists, this means that within 2 seconds of interacting with an element, the user will be in a flow and focused on the response they are expecting. If the server returns an error during this interval, the user will still be in “dialogue” with the interface, so to speak. It’s similar to a dialogue between two people, where you say something and the other person mildly disagrees with you. Imagine if the other person spent a long time nodding in agreement (the equivalent of our indication of a success state in the UI) but then finally said “no” to you. Awkward, isn’t it? So, an optimistic UI must communicate failure to the user within the 2 seconds of the flow.

An optimistic UI must clearly yet carefully communicate failure to the user. Most importantly, it should happen within the 2 seconds of the user’s flow. (View large version48)

Armed with the psychology of how to handle failure in an optimistic UI, let’s finally get to those 1 to 3% of failed requests.

The Pessimistic Side Of Optimistic UI Design Link

By far, the most common remark I hear is that optimistic UI design is a kind of black pattern — cheating, if you will. That is, by employing it, we are lying to our users about the result of their interaction. Legally, any court would probably support this point. Still, I consider the technique a prediction or hope. (Remember the definition of “optimistic”? Here is where we allow some room for the “hopeful” part of it.) The difference between “lying” and “predicting” is in how you treat those 1 to 3% of failed requests. Let’s look at how Twitter’s optimistic “like” button behaves offline.

First, in line with the optimistic UI pattern, the button switches to the success state right after being clicked — again, without the user pressing or hovering over the button any longer, exactly as the button behaves when the user is online.


When offline, Twitter’s like button is still visually updated after being clicked. (View large version50)

But because the user is offline, the request fails.


(View large version52)

So, as soon as possible within the user’s flow, the failure should be communicated. Again, 2 seconds is usually the duration of such a flow. Twitter communicates this in the subtlest way possible, simply by reverting the button’s state.


After the failed request, Twitter subtly reverts the visual state of the like button, without any visual fuss. (View large version54)

The conscientious reader here might say that this failure-handling could be taken one step further, by actually notifying the user that the request could not be sent or that an error has occurred. This would make the system as transparent as possible. But there is a catch — or, rather, a series of issues:

  • Any sort of notification that appears suddenly on screen would switch the user’s context, prompting them to analyze the reason behind the failure, a reason that would probably be presented in the error message.
  • As with any error message or notification, this one should guide the user in this new context by providing actionable information.
  • That actionable information would set yet another context.

OK, by now we can all agree that this is getting a bit complicated. While this error-handling would be reasonable for, say, a large form on a website, for an action as simple as clicking a like button, it’s overkill — both in terms of the technical development required and the working memory of users.

So, yes, we should be open about failure in an optimistic UI, and we should communicate it as soon as possible so that our optimism does not become a lie. But it should be proportional to the context. For a failed like, subtly reverting the button to its original state should be enough — that is, unless the user is liking their significant other’s status, in which case the thing better work all the time.

Extreme Pessimism Link

One other question might arise: What happens if the user closes the browser tab right after getting a success indicator but before the response is returned from the server? The most unpleasant case would be if the user closes the tab before a request has even been sent to the server. But unless the user is extremely nimble or has the ability to slow down time, this is hardly possible.

If an optimistic UI is implemented properly, and interactions are applied only to those elements that never wait longer than 2 seconds for a server response, then the user would have to close the browser tab within that 2-second window. That’s not particularly difficult with a keystroke; however, as we’ve seen, in 97 to 99% of cases, the request will be successful, whether the tab is active or not (it’s just that a response won’t be returned to the client).

So, this problem might arise only for those 1 to 3% who get a server error. Then again, how many of those rush to close the tab within 2 seconds? Unless they’re in a tab-closing speed competition, I don’t think the number will be significant. But if you feel this is relevant to your particular project and might have negative consequences, then employ some tools to analyze user behavior; if the probability of such a scenario is high enough, then limit optimistic interaction to non-critical elements.

I intentionally haven’t mentioned cases in which a request is artificially delayed; these do not generally fall under the umbrella of optimistic UI design. Moreover, we have spent more than enough time on the pessimistic side of things, so let’s summarize some main points about implementing a good optimistic UI.

Rules Of Thumb Link

I sincerely hope this article has helped you to understand some of the main concepts behind optimistic UI design. Perhaps you’re interesting in trying out this approach in your next project. If so, here are some things to keep in mind before you begin:

  • A prerequisite to everything we’ve talked about so far: Make sure the API you’re relying on is stable and returns predictable results. Enough said.
  • The interface should catch potential errors and problems before a request is sent to the server. Better yet, totally eliminate anything that could result in an error from the API. The simpler a UI element is, the simpler it will be to make it optimistic.
  • Apply optimistic patterns to simple binary-like elements for which nothing more than a success or failure response is expected. For example, if a button click assumes a server response such as “yes,” “no” or “maybe” (all of which might represent success to varying degrees), such a button would be better off without an optimistic pattern.
  • Know your API’s response times. This is crucial. If you know that the response time for a particular request never goes below 2 seconds, then sprinkling some optimism over your API first is probably best. As mentioned, an optimistic UI works best for server response times of less than 2 seconds. Going beyond that could lead to unexpected results and a lot of frustrated users. Consider yourself warned.
  • An optimistic UI is not just about button clicks. The approach could be applied to different interactions and events during a page’s lifecycle, including the loading of the page. For example, skeleton screens55 follow the same idea: You predict that the server will respond with success in order to fill out placeholders to show to the user as soon as possible.

(View large version57)

Optimistic UI design is not really a novelty on the web, nor is it a particularly advanced technique, as we have seen. It is just another approach, another mental model, to help you manage the perceived performance58 of your product. Being grounded in the psychological aspects of human-computer interaction, optimistic UI design, when used intelligently, can help you to build better, more seamless experiences on the web, while requiring very little to implement. But, in order to make the pattern truly effective and to keep our products from lying to users, we must understand the mechanics of optimistic UI design.

Resources Link

(rb, al, il)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40
  41. 41
  42. 42
  43. 43
  44. 44
  45. 45
  46. 46
  47. 47
  48. 48
  49. 49
  50. 50
  51. 51
  52. 52
  53. 53
  54. 54
  55. 55
  56. 56
  57. 57
  58. 58
  59. 59
  60. 60
  61. 61
  62. 62
  63. 63
  64. 64

↑ Back to top Tweet itShare on Facebook

Denys is a frontend developer living and working in Norway while advocating psychological optimizations around the world. Since the beginning of 00's he has gained experience with a wide range of frontend tasks. Being originally on "CSS side" of development, for the last years Denys has been building javascript applications, continuing breaking CSS, abusing HTML and working with optimization of pretty much all aspects of the frontend at Digital Garden AS ( and Passionate about science, history, psychology, in his day-to-day job Denys enjoys getting to the heart of the matter of things and processes. Cycling, photography, impressionist paintings and many more can trigger his attention.

  1. 1

    Really interesting approach! Thanks!

  2. 3

    What are your thoughts on google’s optimistic actions such as deleting an email without requesting confirmation? (but giving you an undo for a few seconds after). Does it fit into this model?

    • 4

      Denys Mishunov

      November 15, 2016 2:19 pm

      Thank you for the question, Zoobster. I have to be very honest here: I have not experienced the scenario you are mentioning. Is it when you try to remove an email in the web interface of Gmail?

      In any case, this scenario you are talking about does not sound as an “optimistic” approach. We are talking about UI as being “optimistic” when an interface element is talking to the server but doesn’t wait for server’s response on the *simple* elements.

      Even if we don’t mention quite destructive nature of the action in your example, it’s a bit different from optimistic UI. Here, the interface performs cancellable action without waiting for the *user’s* response. You see, we are somehow missing the core of the optimistic UI – communication with the server.

      Performing a destructive action when user does not expect it is a totally different story of psychology.

      • 5

        I believe he is talking about Google’s Inbox web app (an alternate interface to Gmail). When you mark an email as “done” (the same as archiving) it removes the email from your inbox without waiting for a reply from the server. You can test is is the optimistic approach by trying to close the tab and it will say something like “Some changes have not been made, are you sure you want to exit?”

        The undo function is just an extra feature to avoid confirmation dialogs without the risk of accidental actions. It’s not really related to the optimistic concept you talked about but I guess it is optimistic in the way that it assumes if a user clicks on something it wasn’t accidental.

        • 6

          Denys Mishunov

          November 15, 2016 8:56 pm

          Ah! Thank you for the clarification, Josh. Will try it. But yes, I think you have the point – it sounds like not directly related to the article’s subject behaviour. But still similar mindset has place in that interaction.

  3. 7

    Great stuff Denys!
    I really like your posts on SM

  4. 9

    Interesting idea, although I’d challenge the idea that users want to see things happen immediately: I for one am suspicious when something reacts too fast… although that maybe just a hangover of my years in the wild West of the web.

    • 10

      Denys Mishunov

      November 15, 2016 3:50 pm

      This is a very good point, Stuart. And you are absolutely right, not always users want to get an immediate feedback from a service. I have wrote a bit more about this in another article ;)

      Also at the conferences I advocate for carefully considering whether speed is really what your users need before diving into the optimisations. Though, for the cases when you know that this is what the users expect, you have now one more technique to choose from :)

  5. 11

    It seems to me that the unspoken key to these optimistic UIs is that they are low-stakes actions. I have experienced my FB like not going through. It makes me scratch my head a bit and just hit the button again or refresh my screen. It’s not a big enough deal for me to complain about it.

    If I were trying to purchase a gift online, though, and an “optimistic UI” assured me my purchase had gone through, I’d be very upset to find myself in the 1-3% failure group. I think I’d make the low-stakes aspect of this more explicit.

    • 12

      Denys Mishunov

      November 15, 2016 8:28 pm

      Dear Nate, you are absolutely right that such optimistic approach on an online gift purchase form could lead to a lot of frustration. But let’s sort out this example a bit if you don’t mind.

      First of all, as it is stated in the article: “The interface should catch potential errors and problems before a request is sent to the server.” And this statement is especially true for a complex element such as a form on a site – inline validation of the input, patterns on the fields and so on should all catch potential errors before the user clicks “submit” button.

      Second, “an optimistic UI works best for server response times of less than 2 seconds. Going beyond that could lead to unexpected results and a lot of frustrated users. Consider yourself warned.” This is a serious warning and is crucial for successful implementation of the “optimistic” interactions. Hence even if you are trying to buy a gift online, as long as the interface communicates a failure within 2 seconds you will still be in the flow of this task and will tolerate the failure. But in this case, subtle revert of the visual state of course is not enough – probably the interface should give user some more information about the failure and some actions to correct and send the re-send the request.

      But again, when it comes to online purchases, it involves some processing on the server side to have a distinct “true” or “false” and usually, the whole round-trip takes longer than 2 seconds. Hence, this leads us to a simple conclusion – optimistic UI should, probably, not be implemented for an online form in the first place if developer pays attention to the warnings in the article.

      So, I would not be worried a lot about hitting an “optimistic” online purchase form as long as it is not a one-click-buy, but this is completely different story ;)

  6. 13

    Nice Article Denys.

    I have experienced such things before. But today after reading your points, I got the catch.


    • 14

      Denys Mishunov

      November 15, 2016 8:29 pm

      Thank you, Vishal. Hope the things are more clear about this kind of interactions now :)

  7. 15

    I think there is a downside to the way Twitter handles a failed like (reverting the button’s state):

    Say that I’ve logged into Twitter on a friend’s computer and I’m scrolling through a bunch of tweets and one of them has a link to a useful article. I don’t want to read the article right now, so I like the tweet and keep scrolling down. Because I’ve scrolled down, I don’t notice that the button’s state got reverted. Later on, I’m back at home and I want to go read that article. I look at my liked tweets, but it’s not there anymore and I can’t remember who tweeted it.

    Sure, this isn’t a super realistic example, but it could happen. I would rather be alerted of the failure and have to snap out of my current context than to lose whatever it is I was trying to do (liking a tweet, in this case). Especially since failure is unlikely anyway (1 to 3%). I don’t think website owners can always judge how important a user’s actions are to them. If the user performed an action, they did it for a reason. So if the server fails to record that action, they should be informed.

    • 16

      This is exactly what I was thinking. I’m not sure about most users but to me that 1 unnoticed failure is going to be far more annoying and memorable than the occasional error message. If I perform an action and the feedback says the action was completed then I expect it to be completed.

      Of course most people might be different, this is just how I would I react to the situation. I wonder if any studies have been done on this?

      • 17

        I think that’s not a fair expectation to have of a distributed system- digital or otherwise. It’s always the case that while you may get an initial confirmation (acknowledgment), there are monkeys in the back rooms to process stuff, and sometimes one of them eats the Xmas card you’d sent to Grandma.
        At best you’d get a weekly email of failures, but in general those situations where you thought you Liked, then don’t see the like, are inevitable when information transfer is that much slower than a users’ attention span.

    • 18

      Denys Mishunov

      November 15, 2016 9:17 pm

      Valid comment, Adam!
      I do agree that it might be *too* subtle for some the way Twitter handles the failed request. But the case you are mentioning is a special one of those 1-3% of the failed requests. Should Twitter have made failed-request notification more intrusive, it should have also provided some actionable context to the user (otherwise what’s the point for a system to step in at all?).

      Now how would it look like in this case? Probably something like “Click ‘like’ again” or “Want to try liking again?” :) Yes, I am exceptionally creative with the copy here, but I think you get the point – the actionable context would be quite confusing and, probably, would build frustration for *all* of 1-3% users getting the error.

      I totally understand what you mean but I am still not convinced that Twitter (and it’s only about Twitter we are talking here) should make the failed-request notification any more obvious.

      • 19

        From the point of view of the user, the app/website only works most of the time, but not always, for unknown reasons and fails silently. I think people having the perception that the app is to some extent unreliable is a fairly high price to pay.

        • 20

          While very eloquent in their complaints, the users that are offended by such techniques may be outnumbered by those for whom the immediate benefits build trust and confidence. YMMV

      • 21

        I think Twitter should display the error message or not, depending on the reason. If it’s an 1-3% error from the request, it’s probably ok not to display any error. But as you say in your post, the like will fail as long as you’re not logged in anymore, so every tweet I’ll like will fail. In this case, I think they should display an error message on the top and ask you to log in to like the post. In the present, I could just like dozen of tweets without noticing that I’m not logged in and everything failed.

        • 22

          Denys Mishunov

          November 17, 2016 5:39 pm

          Just curious, am I missing something here? :) When I am not logged in, I get notification about *not being logged in* immediately after I click “Like”. Zetura, could you please sharing your scenario where you can ‘like dozen of tweets’ without noticing that you’re not logged in? If this happens to you, then there has to be a bug that would be nice to report to Twitter, I suppose.

  8. 23

    awesome article!!! The concepts are masterfully concatenated. Thank you!

  9. 25

    Great lecture! It’s like the first long article i read from this page (i’m new btw) and i found it very interesting!

    Didn’t know about the subject, thanks a lot!

    • 26

      Denys Mishunov

      November 15, 2016 9:20 pm

      Yes, Gino, the article ended up a bit longer than expected but I hope it is worth it – it’s always better to have more information to make a conscious choice when you have to rather than guess.

      Thank you for the comment and I am glad you found it interesting! :)

  10. 27

    It’s funny that I read this just as I am fixing an interface issue wherein I am incorporating the disabling of a submit button. The problem which we have run into that you may not have experienced is that older, typically baby-boomer users have a tendency to double-click buttons and links on the web. They have carried over that behavior from using non-web software and I have witnessed it both in family members and in doing user testing.

    In the application I am currently working, we noticed we were receiving duplicate messages in our customer contact forms. At first it was listed as a bug thought to be caused by system latency and the lack of a spinner indicating to users that the form submit was in process. Having experienced this double-clicking behavior in the past, I deduced that was the problem and am now implementing the disabled buttons state while validation is taking place to prevent it.

    I’m sure this is just one of many seemingly bizarre user behaviors that may cause problems with the optimistic approach.

    • 28

      Denys Mishunov

      November 16, 2016 8:41 am

      Thank you for the comment, Dave.
      Double-clicking a button is a good point! But does 100% of your audience doing this? If not then instead of a disabled state, maybe you simply need to implement a debouncer or do not accept clicks on already-successful button to avoid the described scenario? Just another perspective on this problem ;)

      Just to make it clear – Optimistic UI does not handle technical issues or flaws in the UI (means if your users double-click they will double-click no matter the technique) for that matter and tackles only one particular thing – psychological performance optimisation. It’s just yet another tool. And as with *any tool* one might misuse it, but it doesn’t mean the tool doesn’t work ;)

    • 29

      The problem of duplicate form submissions is a well-known problem. The solution is not disabling the submit button, but including a server-generated unique ID in the form and submitting that back to the server together with the form content. This way you can prevent duplicate submissions, and have a little DOS-protection at the same time.

      • 30

        Denys Mishunov

        November 16, 2016 9:29 am

        Good point, Peter. Thank you. So this gives even more options to tackle Dave’s problem.

        But the message is quite clear – making people wait instead of fixing things properly is not a solution most of the times.

  11. 31

    Francesco Bertelli

    November 16, 2016 7:07 am

    interesting but for no i prefer to be cautious and try to get 100% of my user completing the action.

    I prefer a different approach which I would call semi-optimistic or “traffic-light”

    What I prefer doing is:

    – user clicks a button say “Publish Article”
    – the spinner spins for a T time I established before or less (basically i set a timeout)
    – after the T or less time, I display the success state

    with my approach i believe i can get those extra seconds for the server to respond, and by providing a spinner i communicate the user something is happening and I’m moving to a new state.

    Traffic lights don’t go from red to green directly, they need the orange to communicate that something is going to happen…

    • 32

      Denys Mishunov

      November 16, 2016 8:56 am

      Thank you for the comment, Francesco.

      What you’re describing doesn’t differ from “not-so-old-days” approach. You still show the spinner, users still wait for the server to respond. I just don’t understand the point of the timer since you’re:
      a) either getting the response within this time frame anyway or
      b) the server didn’t respond and in this case, I suppose something went wrong on the server.

      And in this second scenario showing a success when you have quite a bold hint of something going wrong is not good. Furthermore, you’re writing about “extra seconds for the server to respond”. Here, I should once again, point to “an optimistic UI works best for server response times of less than 2 seconds. Going beyond that could lead to unexpected results and a lot of frustrated users. Consider yourself warned.” If you are not sure your server responds within 2 seconds, optimistic approach is not for this particular interaction.

      But in general there is absolutely *nothing wrong* with not-so-old-days approach as long as your users are fine with waiting. In your particular case, I suppose they are since publishing an article is one of those processes where users usually don’t expect things happen immediately (Blogger had a similar issue long time ago). But it happens because of another psychological aspects: user’s expectations and the feeling of fairness play the main role now. People spend time filling out the text for the article, filling out metadata and so on. They spend time and this not-so-fast process requires adequate response from the system, acknowledging the user’s effort. Doing things instantly *in this particular case* simple communicates that all the time user spent is worth nothing (or rather a fraction of a second). And this is much worse than letting user wait a bit.

      I am talking a lot about cases like yours at my workshops but is is very far from the topic of this article ;)

  12. 33

    Firstly, I feel a 2 second time frame for changing success feedback into failure is a huge amount of time. This is not at all about users in a hurry to close their browser tab within 2 seconds, this is about users receiving a feedback of success, and after that their attention goes on to other things. Many Twitter users will have scrolled way beyond the liked post within those 2 seconds. But the problem is not so much in the length of time, but in the positive feedback. Users expect a positive feedback, but check the feedback because they are used to their own imperfection (accidental double-clicking, clicking outside the active area, performing a minimal drag instead of a click, etc). As soon as they see a positive feedback, within microseconds their attention moves on to other things, and they will not notice the reverted feedback.

    An error rate of 1-3% also seems very high to me, if I don’t get proper feedback. What if 1 in 30 of my Tweets is never published? What if 1 in 100 of my favorited pages is never added to my favorites? I might not think much of it the first few times, but for every failure I discover, my trust plummets further.

    Disabling form submit buttons is a weak, bad practice. It was not common on the “old web” as is suggested here. Duplicate submissions are easy to catch by including a unique ID. At least on the old web we had a uniform, centralized progress indicator provided by the browser. Granted, it was outside the focus field, but at least it was in a predictable format and location. In the current web we have to watch out for any number of different forms of feedback. And with an optimistic UI, we can’t even really trust the immediate feedback.

    • 34

      Denys Mishunov

      November 16, 2016 9:59 am

      What you’re writing, Peter, is absolutely valid concern. I agree. And yes, optimistic UI can help or it can make things really bad. As any other technique out there. This is why I do not advocate for using it all over. I don’t say that one should implement it on all the forms, buttons, links, who knows what else. What I am doing with this article is provide another tool to be added into the developers’ toolbox.

      When you get a tool like hammer, for example, you don’t go out and try to fix your broken vase with it. You need another tool like glue. We do know that. But in order to know what tool should be used and when, you have to understand what it does and how to apply it properly. Optimistic UI is a tool. And with this article I provide the mechanics of how it works.

      But it is up to *you*, knowing all the tools available at your disposal, being aware of how they work and should be used, make a conscious choice of whether the tool suits your needs nor not. “What if 1 in 30 of my Tweets is never published? What if 1 in 100 of my favorited pages is never added to my favorites?” are the valid questions that you should ask yourself, as a developer, before making a decision about which tool to use. And if you are not satisfied with the answer, you should consider another tool.

      Any tool is capable of making thing better or worse. Every tool has quite obvious limitations and consequences of it’s usage. But knowing those helps making the right decision about whether to use this tool or maybe look at another one.

  13. 35

    I don’t totally agree. In my experience, one of the surest ways to create an uncomfortable user experience it to violate the UI contract. That is, to misinform the user about the real state of the application or to otherwise break with what the user expects will happen given an interaction. Going back to the Facebook example, there have been a couple of times when I’ve clicked “like” on a post on the mobile app, then scrolled through my newsfeed a few hours later and found that it hadn’t gone through. This immediately called into question all interactions I’d had on the app before that and all the ones I’d have in the future, and has caused me to sometimes refresh over and over to make sure a like or comment was successful. Even though failures only happen in the minority of cases, a user’s trust is delicate. Computers (and for those of us who work in the field, software we didn’t personally write) are such mysterious black boxes to their users, that any inkling that we can’t rely on an interface causes instant anxiety. We rely on user interfaces to guide us through interacting with something we can’t interact with directly, and when they fail us we have nowhere else to turn.

    • 36

      Denys Mishunov

      November 17, 2016 9:00 am

      Yes, Brandon. You are raising the issue that has been mentioned a couple of times in the comments already. I do agree with you about violation of the UI contract. And moreover, about “a user’s trust is delicate”. Support both with both hands.

      The problem of any community, is the lack of open-mindedness, seeking for opportunities, hunger for invention. Instead, we are constantly trying to find limitations, side-effects and negative in anything we are told. I deliberately use “we”: I am guilty as charge. BUT. If we would all see only limitations instead of opportunities, negative instead of positive, complexities instead of possibilities we would still live in the web of ’90s. Oh no! The WEB would not exist in the first place!

      When it comes to Facebook in particular, if not their use of optimistic mindset with skeleton screens on load, optimistic interactions and others, then exactly the same people complaining about optimistic UI, would complain about Facebook being slow and unreliable. That’s life.

      Getting back to optimistic UI :)
      So truth be told: This technique is, probably, only for adventurous and brave among us. Those who sees opportunities. Because it requires some thinking and considerations to not turn it into “lie” as it is stated in the article.
      You should feel comfortable with the tools you use and so if you don’t see how to use optimistic UI (that is nothing more than a tool that you are free to use or not to use) as an opportunity and build improved UX on top of it, if you don’t feel like it gives you a required level of comfort, then optimistic UI is simply the wrong tool! As easy as that! :)

  14. 37

    Gaspar Mostafa

    November 17, 2016 8:52 am

    Great article, Denys. Thanks for taking the time to reply to other user’s comments; it clarified some of the questions I had while reading it.

    • 38

      Denys Mishunov

      November 17, 2016 9:05 am

      Thank you very much for your words, Gaspar! It simply feels fair to answer the comments as clear as possible: people spent time writing those as well. Moreover it generates really interesting discussions and might point to the issues I did not consider myself before; at the same time explaining the topic a bit better, as you point out.

      Thank you for your support :)

      • 39

        Damn. You really have the urgent requirement to comment literally everything, I sense. Though your feedback obviously takes a little more than 2 seconds. It would make your article more believable and worthwile for me if you could let flow things “in an optimistic way”, and not to just try to show that the comment count is way up high once more and once more again just to say, um, what again? Thank you? Thank you! Thank you.

  15. 40

    Interesting article. I’m sure the answer to my question would be: “Use common sense,” but here goes: A like button is rather trivial. Adding a product to your basket is less trivial. If you optimistically add it to your basket and maybe store it successfully in your localStorage, it might not be stored on the server.

    Do you then quietly remove the item from the user’s basket?
    Do you attempt to re-try sending it to the server?
    Do you show an error icon (with tooltip) in your basket?

    Right now my “add to basket” button shows the success icon, but at 0.8 opacity. It turns fully visible when it’s successful.

    Honestly, that’s the fairest feedback I feel I can give. I’m never lying to the user by at least communicating the transient state ever so briefly. And it’s still optimistic in the sense that I’m showing the success icon by default. Showing “done!” and maybe coming back on that later feels like I’d betray the trust of the user.

    The side effect I’ve seen in comments in this post, but also experienced myself, is that you simply don’t trust the app anymore. If it shows a successful state but you know it might still fail, that makes me mistrust your product.

    I, personally, have resorted to hard-reloading the page to verify my action was stored successfully. And even then I’ve ran into an issue once where the problem persisted: the state was stored in localStorage, but never made it to the server.

    Lying to the user isn’t good. Even if that’s only in 1% to 3% of all cases. And that’s an interesting figure as well: you can only measure the failures that can be measured. Connections with a lot of packet losses aren’t going to send the request; hence you can’t measure the failure.

    In the mobile world with 3G and 4G and people going underground and switching cell towers several times a day I guarantee you this figure is much higher.

    TL;DR: I’m opting for an in-between solution, but I strongly recommend never lying to your users. Even if the connection is slow, at least make sure your product is trustworthy.

    • 41

      Thank you for your question, Marcel. But I think you misunderstood the concept a bit.

      You write: “I, personally, have resorted to hard-reloading the page to verify my action was stored successfully. And even then I’ve ran into an issue once where the problem persisted: the state was stored in localStorage, but never made it to the server.”

      Two alarming points here:

      * First of all, re-loading the page switches all possible mental contexts for the user and you never get smooth UX, Even though you do tell the truth, of course, people most probably will switch to your competitor (if there is any) where they get better experience. This is my personal opinion based on long study of perception and performance. Moreover it’s confusing to read this in the same post where you write about mobile users ;)

      * Secondly, once you set ‘localStorage’ and ‘optimistic UI’ in the same logical chain I suspect you’re doing it wrong. Optimistic UI is exactly about that – UI. You update the UI element *visually*, but you don’t do real action on the client before getting the definite answer from the server. Exactly as Twitter does by not incrementing the number of likes before getting the server response (I agree with this model more than with the one at Facebook).

      As a final note to not dive deep into yet another discussion of the same things. It is not the task of optimistic UI to make your product trustworthy. It is how *you* manage your project that makes it trustworthy. If you put data in localStorage before getting a response, probably, you’re doing it wrong: too soon. If you can not send data from localStorage to your server, optimisticUI on it’s own has nothing to do with it. If the connection is down or bad, optimistic UI on it’s own has nothing to do with it. Possibly, you could employ some tools for monitoring the network’s availability to send what you have in your localStorage, but *any* UI HAS NOTHING TO DO with it on it’s own.

  16. 42

    This is interesting.

    However I think this can only be applied to minor or simple interactions where a failure “dosen’t really matter” to the user. For example, if I like a post and something goes wrong I’m not really bothered.

    For more complex actions, like “Save my work” for an online tool, I think it’s comforting for users to see the “not-so-old” processing spinner graphic and then “Work Saved” type button.

    Regarding the pessimistic side, if the user is offline, the webpage can easily detect this on page load and show a global error message for all buttons pressed. Also if the user is on page and drops connection at some point, then using this method or the not-so-old method will alsways result in some client-side / server side confussion and therefore effects both.

  17. 43

    Thanks for the insights Denys, really interesting article.

    As with everything, I think it’s worth mentioning that there are cases where you do want to slow down the experience. If anyone’s curious, I’d recommend to read:

    I am also maintaining a list of great resources about perceived speed here:

    I’ll add this article to the list, of course :)

  18. 44

    Denys, I really loved reading this article.
    I think all the potential errors can be captured on the client side and the other errors can be stored on local storage and retired/fixed.

  19. 45

    I think it’s too optimistic for the most of cases. Imagine you post a comment or submit your order in online store, I can imagine your feelings when after seeing your comment published or payment processed the state of your application changes and your action reverts.

    Also I believe this behavior in general is against web nature. We can be optimistic by saying that all our users have stable internet connection, never use mobile network or public wifi, but this is (in 97-99% cases) far away from reality.

    So I can clearly see benefits of using this technique when it comes to “likes” (well, I don’t think you’ll miss reverted “likes” that much), but this shouldn’t be applied to submitting massive/sensitive data. Thus I’d limit usage of optimistic UI by 1-3%: chance of pessimistic scenario when we can risk loosing user’s data.

    • 46

      Denys Mishunov

      November 21, 2016 7:08 pm

      Thank you for your comment, Alex.

      You are right, optimistic UI is definitely not a “silver bullet”. As no other technique is. But one thing I should make clear I think, so that those reading the comments later would not need to look for this answer in all the previous comments:

      *Optimistic UI for an ONLINE FORM.*
      Yes, in most of the cases optimistic ui might not be suitable for “online purchase forms”. This is too critical element. Though, if you:

      – validate date before sending the final request (it can be pure client-side validation or ajax-based validation of the particular fields);
      – make sure your server-side implementation of the order form is stable and returns either true or false;
      – here is the important part – communicate the error in the much more detailed way than it is done on Twitter with proper error message, actionable context and so on…

      Then optimistic UI might work even for the order forms. I don’t see how this is different from employing spinner or anything else except the experience for 97-99% of your users will be instant. Also, this technique is totally appropriate tool for 1-click buy buttons on your site, as long as you follow all the instructions listed in the article.

      * One note. In case of optimistic UI for an order form, you might face another psychological problem – usually online forms are slow as hell and hence optimistic approach on them might simply look suspicious. People might not believe that the order was really successful because of this. Furthermore, the time they “invest” in making the order will not be justified by optimistic approach in their perception. And with this we have already drifted far enough from the topic of the article :)

  20. 47

    Interesting article, BUT:
    1) Why are text or image links not opening in new tab? Could’ve saved me a lot of unneeded clicks
    2) I feel the article can be 50% shorter. There’re many repetitions or just extra words that don’t add anything to the reading experience. It feels like an academic article, but why??

    • 48

      Denys Mishunov

      November 23, 2016 9:33 pm

      Oh! This is a very pleasant comment. Thank you, Yaya. Reading that my work “feels like an academic article” makes me happy :) And I am very glad that you find the article interesting.

      BUT (see what I am doing here? ;)):

      1) you can write your comments about opening the external links in a separate tab to Smashing Magazine stuff instead of a comment to an article. I am sure you could find a link for that within the same timeframe you have used to write the comment here ;) But don’t you worry, I have you covered with this – Contact form. In order to open this link in a new tab, use Cmd + CLICK (on MacOS) or Ctrl + CLICK (if you’re on Windows).

      2) the article could be even 90% shorter. But it’s not :) It’s as long as I supposed it to be in order to explain the aspects I wanted to be explained. But I will consider reviewing possible shortenings of my future articles for them to be easier to consume.

      Thank you for your opinion, and I hope this comment was not tooooo long ;)

      • 49

        Oh yeah I suppose I should’ve figured the issue comes from the hosting site, I just got the link as a share from someone so didn’t bother to think where I’m at. Still.. As a writer I advise you to contact them as well – after all it’s your loss if I leave the site and don’t come back or what not..

        My issue with it being an article is that your audience and your subject do not fit to this kind of writing, I mean, UI-text-wise, not so optimistic :P
        I don’t mean it should be 1 paragraph either, but 40-50% less text would be more fun and easy to read, at least for me. Dunno about the rest. Don’t forget, there are nowadays gazillion UI/UX/Design related websites like this one, with bazillion writers and articles like yours – and as a reader, I want to read many, but not get tired or overwhelmed by them!

        Anyway I’m pleased that you were at least happy with my comment, my intension of course wasn’t a negative one.

  21. 50

    Well presented article, although as you suggest, this only applies to low value activities. The problem I’d have is those are precisely the UI actions I simply don’t bother doing… I only want the effort of interacting if it isn’t low value.
    If you wanted to see optimism done badly, the way Google Newsstand handled content update was it: they used to show a spinner to indicate an update, yet that was being shown “optimistically”, such as times when you knew before the system that it had no internet! As others have said, this kind of failure scores double (or worse) as it totally erodes trust

  22. 51

    Nice article, glad you’re pushing this forward. I gave a talk at velocity 2010 where I mentioned that users don’t care if you’re really fast, they just care that you appear fast, so it’s okay to fake it. It got a few laughs and tweets, but nothing more. I hope that we can move forward to a point of creating an Optimistic UI pattern library that devs & designers can adopt.

  23. 52

    Thanks so much for the article, I didn’t even know about this optimistic UI. Was super interesting to read.

    Spasibo ogromnoye, krutaya stat’ya :)


↑ Back to top