Menu Search
Jump to the content X X
Smashing Conf New York

We use ad-blockers as well, you know. 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. upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Why Performance Matters, Part 3: Tolerance Management

When technical performance optimizations reach certain limits, psychology and perception management might help us to push the limits further. Waiting can consist of active and passive phases; for the user to perceive a wait as a shorter one, we increase the active phase and reduce the passive phase of the wait. But what do we do when the event is a purely passive wait, with no active phase at all? Can we push the limits even further?

Further reading on Smashing: Link

What can we do when there is no active wait at all? (View large version9)

Waits without an active phase happen quite often in the offline world: waiting in a checkout line to the till, waiting for a bus, queuing in an amusement park, and so on. It is widely accepted that the longer the user has to wait, the more negative the reaction10 to the wait. User reaction to a wait online is no different from that in the offline world. Studies based on the analysis of more than a thousand cases identify 14 distinct types of waiting situations on the web11. Being dependent on our users’ loyalty, we cannot leave them facing a passive wait.

This three-part series explores the perception of time that has also an effect on observed performance. The first part12 explored objective time and some techniques for managing it. We reviewed the ideas behind several widely adopted industry standards, such as page-loading time and system response time. Part 213 reviewed the preemptive start2814 and early completion5315 techniques which, by dealing with active and passive wait, allow us to manage a user’s perception of time.

This part finally discusses pure passive waiting on the web, how we can deal with it and what can be done to keep user satisfaction high even when the service cannot be delivered fast enough. In addition to the studies on waiting online, our analysis will employ the psychology of waiting lines, customer satisfaction and other tools applicable to offline waiting.

The psychology of waiting lines and other studies applicable in the offline world will help us better understand online waiting. (View large version17)

Psychological Time: Tolerance Management

In the first half of the 20th century, building managers received complaints about long waiting times for elevators. The managers were perplexed because there was no easy technical solution. To solve the issue, some expensive and time-consuming engineering had to be considered. From this point the stories vary18, but someone (designers say a designer, engineers argue that it was an engineer) came up with the idea of tackling the problem from a different, non-technical point of view.

The solution, much simpler and less expensive was found: install mirrors in the elevators and floor-to-ceiling mirrors in the lobby. After installing the mirrors, the number of complaints dropped to nearly zero without any change in the objective time. Why?

“White Rabbit: Oh! Won’t she be savage if I’ve kept her waiting!”

— Lewis Carroll, Alice’s Adventures in Wonderland

I’m sure most of you can guess the answer. Simply put, the solution replaced the pure passive wait that people experienced while waiting for an elevator with an active one by engaging people with looking at themselves (and in surreptitiously looking at others). It didn’t try to convince people that the wait was shorter, didn’t do anything to the objective time or event markers. Instead, people were shifted into the active phase right from the beginning of the wait to its end. In so doing, people were much more tolerant of the wait.

Who came up with the idea of installing mirrors in elevators? (View large version20)

Now it’s time to get all the way down the rabbit hole of the waiting problem. Let’s face it, it’s not always easy to convince a user that a wait is shorter than it really is. Nevertheless, waiting need not have a negative effect on consumers’ evaluations21 of websites if the waiting time is well managed. So why are people so intolerant of waiting?

In 1985, David Maister conceptualized eight “propositions”22 (that have been confirmed in experiments by P. Johns and E. Peppiatt23, P. Jones and M. Dent24, and others) concerning the psychology of waiting. Although Davis and Heineke25 and E. Peppiatt supplemented the list with two more propositions later, for simplicity’s sake we will call all of the propositions Maister’s list. You will find the list along with the possible recommendations on how we can deal with corresponding propositions in the table below.

Eight propositions from D. Maister concerning the psychology of waiting, with two additional propositions from M. Davis, J. Heineke and E. Peppiatt.
Proposition Recommendation/comment
P1 Occupied time feels shorter than unoccupied time. Balance between active and passive phases discussed in part 25426. This is also how the elevator problem was solved.
P2 People want to get started (pre-process waits feel longer than in-process waits). Early completion7627 and preemptive start2814 techniques from part 2.
P3 Anxiety makes waits seem longer. Very subjective and hard to manage in the online world where there is no real contact with the user.
P4 Uncertain waits are longer than known, finite waits.
P5 Unexplained waits are longer than explained waits.
P6 Unfair waits are longer than equitable waits. Meet users’ expectations: match your waiting times to those of competitors or at least neutralize the waiting time of your services29 if you cannot reduce the wait otherwise.
P7 The more valuable the service, the longer the customer will wait. Increasing the value of your services is beyond the scope of this article.
P8 Solo waits feel longer than group waits. We can assume that most of the users are ‘queuing’ alone in front of their computers, hence we have no management control over this proposition.
P9 Uncomfortable waits feel longer than comfortable waits. Definition of “comfortable” is very broad and prone to subjective evaluations.
P10 New or infrequent users feel they wait longer than frequent users. As in P6, here we should meet users’ expectations considering a hypothetical user who comes to the site for the first time.

P3, P8, P9 and P10 are either subjects for a much broader application than front-end development is capable of, or are altogether out of reach for management of a website. Hence, P4 and P5 are the only propositions that miss the management tools in this psychology of waiting puzzle. These two tell us that one of the main reasons people feel unhappy about waiting is uncertainty of different nature: how long will the wait take? What is going on now? Is the result worth the wait? To answer these questions, tolerance management steps in.


Users feel agitated and frustrated about uncertain waits. (View large version31)

Show Me Your Progress

“I wonder how many miles I’ve fallen by this time?” she said aloud. “I must be getting somewhere near the centre of the earth.”

— Lewis Carroll, Alice’s Adventures in Wonderland

To partially resolve the uncertainty and provide information about the waiting time and current state of a process, good ol’ progress indicators are at our disposal. User researcher Steven C. Seow32 suggests dividing progress indicators into two main groups: dynamic (those updating information with time); and static (unchanging over time). Each of these can be split into two subgroups: determinate (projects completion by work units, time or some other measure); and indeterminate (does not project completion).

Different types of progress indicators. Mind the classes. (View large version34)

Now the question becomes when to use these. Obviously, if we show a class A indicator for every action the user performs, it will get very annoying very fast. So, we need some guidelines. When we talked about performance budgets35 in part 1 we defined some static time intervals. Let me remind you of those while mapping them to appropriate indicators.

  • Instantaneous (0.1–0.2s)36
    Obviously, we do not need to show an indicator for something that is perceived to be instantaneous.
  • Immediate (0.5–1s)37
    One second is the maximum time of a user’s uninterrupted flow of thought. Showing any complex indicator within this interval would introduce an interruption of this flow. But usually it does no harm to display a simple indicator without textual information. Indicators of class D, like spinners or very basic progress bard (simplified class A), are natural enough to avoid breaking a user’s flow of thought, while subtly indicating that the system is responding.
  • Optimal experience38
    Within this interval, we must give users an indication of input or a request being processed and that the system is responding. Again, the optimal indicator would be a class D or a simplified class A indicator – there is no need to draw a user’s attention to additional information.

    Some, like GitHub39 (left) and Flickr40, incorporate logos into the spinners or loaders shown during the optimal experience or even shorter intervals.
  • Attention span (5–10s)
    This is the frontier of the user’s tolerance threshold and requires a more complete solution. For events within this interval or longer, we have to show more information than just a general ‘working on it’ indicator: users need to know how much longer they have to wait. Therefore, we should show a dynamic indicator of class A or B where the advance of the process is clear.

    A progress indicator for durations longer than five seconds can be a simple progress bar with a percentage or more advanced information providing current status while mid-process.

To summarize these recommendations we could formulate our guidelines as simply as follows:

Guidelines for progress indicators on the web. (View large version42)
  • For events lasting 0.5–1s, showing an indicator of class D (spinner) or simplified class A (progress bar) is advised on a case-by-case basis.
  • For events lasting for 1–5s, a class D (spinner) or simplified class A indicator (progress bar) is required.
  • For events longer than 5s, a dynamic indicator of class A or B is recommended

It is common for progress indicators to combine different classes or combinations targeted at different propositions in Maister’s list.


momondo.com43 combines indicators of class D (spinner) and class B (updating current status without projecting completion).

Slack app44 has two levels of progress indicators. The second one adds emotional component to the process by offering users a positive message.

Some, like Outlook-powered webmail at the University of Oslo, combine a spinner with information about what is going on at a particular moment. Even though in most cases this information is artificial and does not reflect real actions (the text is being updated based purely on the elapsed waiting time), it is not necessarily a bad thing if it helps users tolerate the wait. (View large version46)

Little Big Room8948 is a lovely site that sets the mood, reduces anxiety (P3 in the Maister’s list) and sets up a comfortable feeling (P9) for further waits on the site with its page loading indicator. (View large version49)

Note that in cases when you use other distracting tools (like animation) during the whole wait, there might be no need for an additional progress indicator: users’ are already busy processing the animation, thereby tolerating the wait more easily by default.

Progress indicators are capable of providing enough information to neutralize uncertainty in accordance with P4 and P5. But can we do better than just indicating loading? Can we address multiple propositions simultaneously? We certainly can.

Tolerance Beyond Progress Indicators

Alice said nothing: she had never been so much contradicted in her life before, and she felt that she was losing her temper.
— Lewis Carroll, Alice’s Adventures in Wonderland

Let’s get to a quite interesting service: tripmydream.com50. Users can find flights and hotel packages all over the world for a predefined budget. After the basic operations like choosing the theme of your trip and desired dates, the user sets the budget for the trip and gets to the search page.


The search page at employs quite a few techniques for tolerance management. (View large version52)

From a performance point of view, searching for a flight and hotel combination all over the world to match a predefined budget is not a lightweight task at all. According to the DevTools, the results for my particular search kept coming in for as long as two minutes. Let’s examine what is done for tolerance management in this case.

First of all, the early completion5315 technique mentioned in part 25426: the first results are rendered as soon as there are any that match the search criteria. But early completion alone is not enough: the first possible result was rendered after almost ten seconds of waiting.


The early completion technique alone does not save the first search results are rendered only after about ten seconds. (View large version56)

Earlier, we reasoned that a dynamic progress indicator should be shown for such long-lasting processes. For, this is the complex indicator of class B consisting of the orange progress bar and the “Analyzing” block right below the bar.


The progress bar and “Analyzing” block together comprise a complex progress indicator of class B. (View large version57)

Finally, let’s address the illustrated character at the bottom. The character is aimed at coping with P9 (uncomfortable waits feel longer than comfortable waits): usually, smiling cartoonish characters evoke emotions related to light-hearted childhood memories, setting up more comfortable feelings while dealing with the wait. The character might even partially solve P8 (solo waits feel longer than group waits) for those of us who spend more time with virtual friends in front of the computer than with real people. Keep in mind, though, that the use of a cartoon character should not contradict users’ expectations of the service: such a character on a banking website, for example, would be inappropriate.

tmd cartoon58

Cartoon characters can help make a wait more tolerable. (View large version59)

Overall, early completion helps manage a user’s acceptance of waiting time in accordance with P1 and P2; the complex progress indicator deals with P4 and P5; and the cartoon character at the bottom attempts to deal with P9 and P8. Quite a handful of harmful propositions are under control here!

But not everything is smooth with the cartoon character on this page: it not only soothes, but also communicates, providing the user with additional textual information. And here we have a problem. Because the character and the corresponding text in this element are changed to another character every six seconds or so, most of the time users have no time to read the full text.160


If you place text next to a drawing, make sure you provide enough time for users to read it. Removing text while users are reading builds up frustration rather than managing tolerance. (View large version62)

There are many good and bad examples of tolerance management on the web. But we will take a look at two which try to achieve the same result with a different approach.

SlideShare63 and Speaker Deck64 are arguably the two most popular services for uploading presentation slides online. Services like these are very useful for speakers to share their slides after an event with a wider audience. Both of these services have their own supporters based on aesthetics or for historical reasons, but for a user, the services are quite similar in functionality. What interests us in particular is the process of uploading presentation files to these services.

From a technical point of view, the process is the same in both cases: a user chooses a file, uploads it, writes the title and other meta information, then clicks a button to publish the presentation. From a psychological point of view, the process is also the same: uploading a file is a pure passive wait because the user has no control over the uploading process. Neither has the user options other than cancelling the upload altogether. But the interfaces for this process differ between SlideShare and Speaker Deck.

SlideShare vs. Speaker Deck65

SlideShare (top) and Speaker Deck have rather different interfaces for the same operation of uploading slides. (View large version66)

The good part first. Looking at these screenshots we can see how the services employ tolerance management for the process of uploading a file: the form suggests filling out the meta information not after, but while the file is being uploaded, thereby catering for P1 (occupied time feels shorter than unoccupied time) and P2 (people want to get started) propositions in Maister’s list. Instead of keeping the user passively waiting, the user’s brain is instantly triggered into the active phase by the suggestion of filling out this form.

But can you spot the difference between the two? I am sure you can: the two different progress indicators on Speaker Deck. And this is where things get out of control. The second progress indicator not only adds some confusion to the interface, it also significantly slows down the process as perceived by the user. With SlideShare, my presentation file had been uploaded the moment I finished filling out the form, hence I didn’t feel any delay or passive wait. But with Speaker Deck, even though my file had been uploaded comparably fast (the first progress indicator), I still had to wait for the second process to finish before my slides could be visible. And even if I could click the Save the Details button, it does exactly that – only saves the details while my presentation is still being processed. The situation gets worse because nothing in the interface tells the user what to expect after the “processing” is finished: will a user get any benefit that is worth the wait?

Speaker Deck processing a file67

Speaker Deck keeps processing the slides for much longer than it takes a user to fill out the form with presentation details, eliminating any positive effects of the tolerance management. (View large version68)

In this comparison, SlideShare shows impressive use of the tolerance management technique: users barely notice the passive wait while uploading files to the service. On the other hand, the same functionality at Speaker Deck, while employing the same technique at first, eliminates its success further in the process.

With tolerance management at hand, we could extend the performance optimization strategy69, provided in part 2, to get the full picture of basic techniques for managing objective time, perception and tolerance in our projects.


Part I: Objective time management71

Part II: Perception management74

  • Preemptive start75: keep the user in the active phase for as long as possible before switching to the passive wait.
  • Early completion7627: give the user something to work with by switching from a passive to active wait as soon as possible.

Part III: Tolerance management77

Anything that helps your users stay away from the harmful influence of the uncertain wait. Consider progress indicators78, switching fully to an active wait, or combining multiple techniques at once79.

But, be it objectively or psychologically, should we make everything as fast as possible? As you can guess, this is not yet the end.

Easy, Tiger!

“Are there moments when intentionally adding a few extra seconds—however artificial—creates a better experience?” asks Stephen P. Anderson in his article “Wait for It …80”. Let’s figure this out.

Last year, discussion about a placebo progress bar81 on the website of South Africa’s First National Bank82 made respected minds claim it to be some sort of nonsense83. But let’s not rush to judgement.


A placebo progress bar on the website of First National Bank raised a lot of controversy. (View large version85)

First of all, as William J. McEwen writes86, “Faster can be better – but only when speed is exactly what the customer wants. Not all customers want to complete every contact with a company at lightning speed.” Do you like it when a bank website hurries you? The website provides an online interface to the offline interactions that a user can relate to in real life. Users have expectations about these operations and usually these interactions with banks do not happen at the speed of light.


Not everything should be as fast as possible. (View large version88)

Second, by adding this progress indicator, the bank tries to cultivate a particular emotional design quality: the idea of a complex product with many benefits. “A lot of things that are really valuable take time,” says Darrell Worthy, an assistant professor of psychology at Texas A&M University. This echoes Maister’s P7: the more valuable the service, the longer the customer will wait. The bank is not serving fast food; it is not expected to deliver results instantly. Simply by delaying its response to an average user (that is, without developer tools and a hunger for sensation), the bank tries to manage users’ expectations, building the perceived value of the service. By the way, progress indicators on Little Big Room8948 mentioned above, similar to the progress indicator at First National Bank, are not connected to any real process as well: they manage expectation and have a function different from simple progress indication.

This brings us to the following point – as long as you don’t introduce a genuinely new way of interaction or operation, your users already have certain expectations of it. Sometimes, speeding up a process confounds those expectations and puts the user out of countenance, significantly reducing the perceived value of your service. In the long run, this might be more destructive than a slower process.


In some cases speeding up a process significantly reduces the perceived value of your service. (View large version91)

“Everything’s got a moral, if only you can find it,” said the Duchess in Alice’s Adventures in Wonderland. And this article humbly tries to communicate its own lesson. The performance and speed of our projects are very important, without a doubt. But they have to meet users’ expectations and needs before we slake our thirst for speed. A good developer knows how to make a website faster; an excellent developer knows when and why to do so. Know your users, know your tools and deliver your best.


Everything comes to an end. And here’s the end event marker of this article.


1 According to a number of studies like the ones by M. Masson et al93 and K. Rayner94, the reading speed for an average reader (native English speaker reading in English) is around 250 words per minute, or about 4 words per second. The graphical elements shown randomly at contain 16–24 words; this means that to read and, most importantly, understand the textual information, an average user would need 4–6 seconds. And indeed, the pictures change every 6 seconds on average.

But these studies review reading speed for texts isolated from other distracting elements. Owing to saccadic suppression95 (the fact that we do not perceive information during an eye movement), the more elements on the page, the more time users need to process and understand the information.

Moreover, P. Carroll et al96 found that when presented with a captioned drawing, users tend to focus more on the drawing than on the caption, hence it requires more time to process textual information provided together with a drawing. This means that: a) being a supportive element, the illustrated character unnecessarily drags the user’s attention away from other more important elements, diluting their effect; and b) to read and understand the textual information coming with the drawings, users need more than six seconds. There is a risk in changing the picture during the reading process; instead of managing tolerance, this builds up frustration.

(ml, al, vf)

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 #endnote1
  61. 61
  62. 62
  63. 63
  64. 64
  65. 65
  66. 66
  67. 67
  68. 68
  69. 69
  70. 70
  71. 71
  72. 72
  73. 73
  74. 74
  75. 75
  76. 76
  77. 77 #tolerance-management
  78. 78 #progress-indicators
  79. 79 #beyond-indicators
  80. 80
  81. 81
  82. 82
  83. 83
  84. 84
  85. 85
  86. 86
  87. 87
  88. 88
  89. 89
  90. 90
  91. 91
  92. 92
  93. 93
  94. 94
  95. 95
  96. 96
SmashingConf New York

Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.

↑ Back to top Tweet itShare on Facebook

Denys is a frontend developer living and working in Norway. He has more than 12 years of 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

    Great article. Love the breakdown and nitpicking of something that many designers take for granted. Definitely something that I can apply in projects right away.

    • 2

      Denys Mishunov

      December 10, 2015 9:43 am

      Glad to know you find it useful and practically applicable, Ulrik. Thank you for your feedback.

  2. 3

    If you’ve been following along boys and girls you would have seen this erupt in one of the last Smashing Magazine posts where actual users of the web application/web site that was built for an airline was perturbing people to the extreme that they spewed out their frustrations over this blog.

    • 4

      Yes, David, sometimes companies do not manage users’ tolerance well. And then they should be ready to accept complaints in any form that suits their users more. And it’s not always pleasurable form I must admit. So, the better we manage users’ perception and tolerance the more forgiving and thankful clients we will have.

  3. 5

    wow Nice post !! and i will apply in my project.

    Thank you

  4. 7

    Awesome article. What a nice read :) Hope more people out there will follow your thoughts so modern apps will feel any faster.

    • 8

      Denys Mishunov

      December 15, 2015 4:52 pm

      Hey! Thanks for the kind words Chris. I would definitely like to see more sites/applications/products that use psychology as the tool for delivering smooth and natural experiences instead of pure technology. Technology has its limits and… oh well, already wrote this in part 2 ;)

  5. 9

    Great article, some great thoughts to mull over.

    I love the “Little Big Room” loader, the illustration was beautiful, however i have one issue with it, and it’s not an issue that every one will have, but it was a big one for me.

    If the loader/progress bar continues at a nice linear pace, it’s a very relaxing, anxiety reducing experience, however, for me on ‘slownet’, the loader was somewhat jumpy, it’d get to a certain % and the car would just bounce around, at which point it’d lose all the comfort factor that made it so good in the first place.
    My personal thought in this is that by attaching the idea of ‘loading progress’ to a car, when it did falter, it hit on that deep urge that all humans have that is if you’re in a car, you want to be moving and not stuck. So when it got to 78% and froze for 5 seconds (for me) it basically created a virtual ‘traffic jam’. No one likes being stuck in a car, so maybe a car wasn’t quite the perfect setting?

    • 10

      That’s a valid point about the progress indicator at LBR , Mike. When one is using a progress indicator it is quite important to make it as smooth as possible, otherwise the trust in accuracy of such indicator vanishes of course. So, you are right, even though it is a good example of a creative progress indicator, there is still room for its functional and associative improvements.


↑ Back to top