What is the length of time the average user will wait at a wait indicator (i.e. a spinning circle, beach-ball-of-death, egg-timer) before they think something has gone wrong?

If anybody can point to any research to back up answers that would be a bonus.

I am mainly thinking in context of websites or within desktop applications rather than waiting for an action the user knows could take a long time i.e. waiting for a application to install or for Windows to boot to desktop.

That's really going to depend on the situation where they encounter the indicator. (i.e. if they're waiting for a complex PC game to load it's likely they'll be more patient than if they're trying to select a navigation link on a simple website). What situation do you have that made you ask this question?
–
JonW♦Feb 14 '13 at 9:43

7 Answers
7

If we ask UX-guru Jakob Nielsen it's 10 seconds. Longer waiting times could get the user to leave the program/page and do other stuff in the meantime. Supposing that something has gone wrong also depends on the users anticipation on how long a certain task could possibly take and the kind of task itself.

The 3 response-time limits are the same today as when I wrote about
them in 1993 (based on 40-year-old research by human factors
pioneers):

0.1 seconds gives the feeling of instantaneous response — that is, the outcome feels like it was caused by the user, not the
computer. This level of responsiveness is essential to support the
feeling of direct manipulation (direct manipulation is one of the
key GUI techniques to increase user engagement and control — for
more about it, see our Human Computer Interaction (HCI) for Real
World Problems seminar).

1 second keeps the user's flow of thought seamless . Users can sense a delay, and thus know the computer is generating the
outcome, but they still feel in control of the overall experience and
that they're moving freely rather than waiting on the computer. This
degree of responsiveness is needed for good navigation . 10 seconds
keeps the user's attention . From 1–10 seconds, users definitely feel
at the mercy of the computer and wish it was faster, but they can
handle it.

After 10 seconds, they start thinking about other things, making it harder to get their brains back on track once the computer
finally does respond.
A 10-second delay will often make users leave a site immediately. And even if they stay, it's harder for them to understand what's going on, making it less likely that they'll succeed in any difficult tasks.

Even a few seconds' delay is enough to create an unpleasant user experience. Users are no longer in control, and they're consciously annoyed by having to wait for the computer. Thus, with repeated short delays, users will give up unless they're extremely committed to completing the task.

Very good suggestion, but I would like to add that those limits were measured back in 1993, 20 years ago. I can imagine that user's patience has changed quite a bit in these fast-moving times.
–
Vincent van ScherpenseelFeb 14 '13 at 12:02

1

I would question the data behind Nielsen's results. That seems to be simply an observation of the order of magnitude rather than any hard data.
–
JohnGB♦Feb 14 '13 at 12:23

1

UX is all about observation. "Hard data" isn't that significant because auf the diversity of users and domains - that's why individual testing is so important.
–
J_rgenFeb 14 '13 at 13:28

The studies these limits are based on are in fact already 40 years old. However, Nielsen states that the values are still applicable to todays user needs. So we can assume we are dealing with very fundamental human behavior here. I edited the answer and included a revised version of Nielsen's article.
–
J_rgenFeb 21 '13 at 13:25

These studies by Nielsen seem to have addressed only the speed at which a site is rendered the speed or at which the site appears to respond to user input. It does not seem to include an evaluation of sites with an explicit wait dialog. As such, although Nielsen's cited findings are informative, I don't think they are directly applicable to this question.
–
Mike RiceFeb 25 '13 at 18:43

If you expect it to take a lot of time, instead of just a spinning circle you could add progress indicator. Progress indicators are almost perfect from the users perspective, they have just one weak side - they should reflect the TIME spent on waiting, and not DATA PROCESSED, but from programming point of view there are too many dependencies to say that a process will take, say, 10 seconds in general. As an effect, user can either see progress going from 0 to 40% in the first 3 seconds, and from 40 to 70% takes 30 seconds. Or even worse: user is presented a progress indicator going from 0 to 100% and then he can still see a spinning circle for god only knows how long. At 100% he or she will really feel something is wrong.

A good progress indicator, methinks, in situations where you cannot tell how long (measured in time) the process wil take, should be switched from 0-100% to some relative data. Just to inform user that something works in the background (just in this case). User will not know how much more time it will take, but at least he or she will know that the background process works.

So, there are two things you should do: a good wait indicator + a good progress indicator.

I can't recall where I read it, but for airline flight bookings it was found that a short wait had a worse response than a longer one. If it were longer (and showed some fake activity), the customers had a better confidence in the algorithm and results. The same applies for insurance quotes and similar actions that have a perception of being more complex.

The overall rule is to make customer facing actions as fast as possible. If it has to be slower, you should show some progress bar (with tricks to make is seem faster) or information (even if it's dummy info) to communicate that something important is happening.

This question has some info on this, such as how the Coinstar machines added an intentional delay into their operation to give customers a better expereince of the machine: ux.stackexchange.com/questions/29285/…
–
JonW♦Feb 14 '13 at 12:38

Very interesting,so if people are waiting for cheaper results or money saving results they are willing to wait?
–
Mervin JohnsinghFeb 14 '13 at 16:04

@Mervin Not necessarily. If people are waiting for a result that the perceive to be complexed to obtain, and they want a better result, they are willing to wait. In fact, they expect to wait.
–
JohnGB♦Feb 14 '13 at 16:17

makes sense :) but my comment was also tongue in cheek since if the system responded quickly with flight fares, you would wonder if it really did search across all flights and if there was a cheaper flight available
–
Mervin JohnsinghFeb 14 '13 at 16:19

How long they're willing to wait depends on several factors, including what they think is the complexity of the task. There's a relationship between how complex users perceive the task is and how long they will wait for it before getting concerned that something has gone wrong.

One of the best methods to address a user's concern over the time it takes to complete a task is to use determinate progress indicators whenever possible. That way, users have an indication of how much has been done and how much is remaining. Being able to see that there is progress being made, instead of just an indeterminate progress indicator (which, as I'm sure we've all experienced, can just indicate that the task will never complete), gives the user much more confidence in the system and helps build trust.

A user willing to get something from a web site will allot the site a number of patience units, a quota.
The number of units depends on the site's expected outcome, or the interest of the user in that outcome.
In some cases the quota might be infinite, like for example when the user is doing taxes through a web interface, by force.
As the site provides value, the user might allot more units. On the other hand, if the site lags behind the user's expectations then it (the site) starts consuming patience units.
When the remaining number of units reaches zero the user leaves.

All the progress indicators and hypnotic revolving animations are attempts to make the user refrain from withdrawing patience units from the current session.

So, there is not a fixed time after which the user will leave.
To make your users stay offer them great value. Or faster response times.

There is another facet, like building confidence through honesty. @Dominik's visualization is a good example, in that it sincerely communicates the user for how long will he have to wait, as opposed to the phony stay in line messages from some call centers.

If the users know the value of what they are waiting for, and more or less how long the wait will take, then they can make an informed decision no matter what Nielsen sais.
Web sites should not attempt to influence them; maybe begging would be right: please don't go!.

I once waited over 24 hours for a Java applet to load. After the first few seconds, I started multitasking. After about 10 seconds, I reloaded the page. 10 seconds later, I threw the browser to a distant desktop and carried on with my day, feeling quite disappointed with the Java applets in general. But maybe the applet or it's server was doing a lot of work, I thought; it was supposed to visualize a lot of data. The next day, I was cleaning up a bunch of windows that I had scattered across six desktops, and I noticed that the Java logo was still spinning!

My point is that you should put an upper limit on how long you will ask a user to wait without meaningful feedback, because some of them will wait long enough to get a very bad impression. I don't even bother installing Java in the browser any more.

It's not so much about expected wait times but, more about setting reasonable expectations and always meeting or exceeding them. It's quite a challenge to first of all set correct targets and then ALWAYS deliver on time or gracefully back out when operations don't go as planned. Users are as patient as you want them to be, within reasonable limits. Three minutes for a typical browser blocking wait to fail retrieving data is not a good user experience and they'll close the window before then. Start with non-blocking ajax to retrieve resources or commit data, use good logic in SQL etc to do things efficiently and most importantly lots of defensive programming. Most half-baked kocky programmers are over-confident in their code, assuming it's so good that it hardly needs much error handling. Make sure you don't unknowingly lose your users before you even start setting time/performance expectations.