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.
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.
Original (1993): http://www.nngroup.com/articles/response-times-3-important-limits/
Revised Version (2010), taken from http://www.nngroup.com/articles/website-response-times/
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.
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.
Here is a simple visualization:
I lot depends on what the person is waiting for.
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.
Wait time is closely related to perceived performance. Steve Seow has an excellent book titled Designing and Engineering Time: The Psychology of Time Perception in Software.
One of its major results is how we perceive response time:
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.
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.
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!.
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.
