How long should the user wait before providing reassurance?

Question

I have an application with user login. When a user logs in for the first time, I show them a screen similar to this while the login process completes:

The user's access must be validated before they can access any part of the app so it makes sense to block their access while we wait.

The problem is that, due to reasons out of my control, authentication can take anywhere between 3 seconds and 1 minute, because of the backend identity provider. So this icon is on the screen for a long time.

During testing, I've noticed that users start to feel like something is broken and want to reload/leave the page after a bit of waiting when authentication is slow.

I want to supplement the "Logging you in..." text after the user has been waiting for a while by adding in "...this can take a while. Please do not navigate away or reload the page."

How long should I wait to present this additional "reassurance" to the user? Also, is there a better way to comfort the user that everything is working, just taking a while?

Note: I did see this question, which answers a related question of "how long should I wait to show the initial loading indicator to a user?" - not "how long should I wait to supplement the initial loading indicator?" - Loading time and page loader display (when to show)

Answer 1

...authentication can take anywhere between 3 seconds and 1 minute...

I'd recommend starting with your basic animation, then add additional feedback as time elapses.

An example

A video game I play often, Rocket League, does this when you begin to search for an online match. It begins with the simple message (the first in the list below) then adds additional messages if it starts taking a while.

"Searching for [game mode] in [region]..."
"Searching for players near your skill..."
"Now searching in more regions..."
"Tip: you can search for more game modes to find a match quicker."

It never seems like these messages are indicative of actual changes on the search parameters (I still almost always get matched in the same region, against a similar skill level), but it does effectively ease my mind that the system is still working on my request—it never appears idle or frozen.

---

Suggestion

In your case, I'd recommend you begin with your basic animation there. After a few seconds (5 or so), you can add a message that explains a bit more, then perhaps a timer showing how long the request has taken so the user can see where they are in the typical <= 1 minute load time.

^{download bmml source – Wireframes created with Balsamiq Mockups}

For what it's worth, there's an interesting study on this by NNGroup who do a great amount of user research for its own sake. They determined there are three main thresholds for wait times in an application:

• 0.1 seconds gives the feeling of instantaneous response
• 1 second keeps the user's flow of thought seamless
• 10 seconds keeps the user's attention ... 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

Answer 2

As maxathousand suggest, you can improve the wait spinner by providing a progress message (or even a fake progress bar). My only addition to that suggestion is to use "Less than 1 minute" instead of "up to a minute." This suggestion comes from the book Designing and Engineering Time: The Psychology of Time Perception in Software, and you can find some tips here: http://www.stevenseow.com/papers/UI%20Timing%20Cheatsheet.pdf

But, the main problem that you need to solve is why the authentication can take 1 minute! For example a user/password mistake could take you more than 2-minutes.

I understand that is beyond your control but sometimes is better to pick the fight and escalate it to engineering than trying to solve it with UI tricks. A few arguments that can help you in that discussion:

• Even for federated authentication, 1 minute is a considerable wait time. For such a long wait time, the bottleneck is usually in the network (any I/O is orders of magnitude higher than CPU, and wait times of network I/O is more elevated than disk I/O). So there is an obvious issue with the communication path between your system and the auth system. If the network is not the problem, then the auth process is idle doing something else (e.g., waiting on a lock to be free). That problem needs to be addressed beyond the login UI, because is going to bite your team in other areas.

• No matter what kind of progress status you show; the perception of time is relative to the task that you perform. For example, 1-minute wait for file download could be expected, but for login is not. So users will be frustrated, and that frustration will impact negatively to the whole system.

You also mention that this might happen the first time. Does a first-time setup cause the wait time? If that is the case, then you can show something like "Setting up your account."

Answer 3

My answer is a bit simpler than the others.

I think your answer is in the tests you made already.

Ask this question:

What was the average time after people showed signs of hesitation when waiting to login?

Once you have this measurement then you know that you should give "reassurance" some seconds before this. Or even some seconds before the earliest sign of hesitation out of any of the participants.

Edit: As a counter argument to having a loading indicator i'd like to share this brief point by Luke W on the subject of loading screens.

Basically, we told people we're slow because we told people we were slow... It's the classic watched pot never boils.

Answer 4

I think you should show the full message, including the "Please do not navigate away or reload the page." The connection/authentication speed is hard to accurately detect and I recommend showing the repercussions of try to reload the page. The progressive reassurance messages are fine (shows the user that the system is still working etc) but I suggest keeping "Please do not reload the page" message on display at all times.

Or you could use a progress bar instead of a spinner as the bar can show much longer they have to wait.