Guidelines for Time Indication and Progress Bars in User Interaction Design
This is the 4th part in a series of articles on time perception in human-computer interaction. This series’ intent is to explore the perception of time in software and physical environments as well as persuasive psychologies.
My first article on this topic discussed the difference between occupied time and time spent waiting. The second article explored 7 Rules to Manage User Wait Times. The third article explored “flow” and how it relates to user tolerance when waiting or delayed — specifically in regards to interfaces and service design. This article will discuss how we indicate the progression of time in interfaces and guidelines for the use of time indicators.
These articles directly support a topic I am speaking on this year at the IA Summit 2018. The presentation is titled: Don’t Make Me Wait! User Perception of Time & Software Speed.
This series of articles has, thus far, been an exploration of the user’s perception of time where I have written about waiting versus occupied time and the psychology behind waiting. The gist of these articles has been to convey how retail and other industries manage customer wait times or convert those wait times into occupied time. We are now moving into practical examples of how we can apply these principles to computer, web and application interfaces. In this article, I do just that, taking you through the first part of a series in which we’ll delve deeper and deeper into how we can design interfaces that are perceived as being faster or leverage user tolerance for delays. This particular piece focuses on the representation of time in systems and software.
It is inevitable the user will have to wait at some point in time for a process to complete or a page to load. Perhaps in the future we’ll have instantaneous response in systems. But as of the writing of this article, load times, data retrieval, installations and downloads all take between a few and hundreds of seconds. So how and when should this be represented so the user knows the system is working and not frozen? The answer to this will depend on how long our user will wait and what our ultimate goal is.
Let’s consider our end-user for a moment and what they might need to know. Generally, there are three questions your user may wish to answer:
- How much time will this take? — this is useful if the user needs to calculate whether they can afford to start the process or not.
- How much longer will this take? — this is the most common question the user will want answered because they are in a waiting state at that point.
- How much time did this take? — this is mostly useful for benchmarking, testing or some similar situation where the user (or the software development team) must know how long a particular process actually took.
We are generally not concerned with the third question. The first question, however, addresses the estimated length of a process so the user can figure out whether it is something they can start and come back to later or if perhaps they must wait until after their next meeting, for example, to start the process. In some situations, the user can hit the button, walk off to the office cooler and kill some time while a scan or installation completes. Other processes may need “shepherding” as they progress. For example, installation processes often have a number of steps in which the user must make selections and click controls to progress. All of these scenarios are cases where knowing the prospective reporting of time can be useful.
The second question comprises the majority of time reporting in systems and software. This is the time where our user is actually waiting. And as I have written before, waits can be excruciating for the end-user — especially when they don’t know how long they will be waiting.
There are generally two ways to report the amount of time remaining or estimated for a process — visually or textually (or both).
Visual indicators usually take the form of:
- Busy animations such as spinners or the spinning hourglass Microsoft used to use
- Progress bars in various forms / formats
Textual representation can take the form of:
- Elapsed time or how much time has passed
- Time remaining until task completion
- Work units remaining such as “1017 of 3043 files scanned”
Often, interface designers and developers will include both textual and visual indicators such as a progress bar with textual indication of time remaining. But when should you use a busy animation versus a progress bar or textual indication? As a general rule of thumb, the following guidelines are best practice.
0–2 Seconds = No Indication Needed (generally instantaneous to the user)
2–5 Seconds = Busy Animation, Spinner or Spinning Animation
5-X Seconds = Progress Indication Needed, Progress Bar or Visual Indication of Start & Finish (Note: A textual indication of the time remaining is generally recommended in these scenarios.)
10+ Seconds = Progress Indication & Cancel Button, User Should Have Ability to Cancel the Process (Note: A textual indication of the time remaining is strongly recommended in these scenarios.)
To expound on this: Human factors research has consistently documented our attention span as humans (specifically in airline industry research). We know humans generally have about an 8–10 second attention span. Any delay approaching that time span should be represented with some sort of progress indication and should also allow the user to cancel out of the process. At the other end of the spectrum: If the delay is 0–2 seconds, this is usually instantaneous to the user and needs no indication. There are instances when the busy animation is perfectly appropriate (2–5 seconds or just long enough for the user to pause and wonder if the software has crashed). But as users, we tend to become impatient or suspect system hangup if those animations appear on screen for more than about 5 seconds. The progress indicator with a textual estimate of time remaining is most appropriate in situations where the wait will last longer than 5 seconds. But how do we estimate the time?
Time Units vs. Work Units — time units are great when you have a rough idea of how long a process will take. They are less ideal when the process length is not well defined or the estimate can change during the process. In such instances, you will most likely want to use work units as noted above where the number of files transferred is given or the number of files scanned is reported.
Time units do not have to be exact. In fact, you really don’t want to report there are “12 minutes 32 seconds remaining” in a process. Reporting right down to the second can be torturous. Steven Seow discussed this in his book and uses human reporting of time as an analogy. When you are asked how long you were at lunch today, you don’t reply with an exact number such as “43 minutes,” but rather “about an hour.” Seow suggests the use of time anchors — round numbers we often use to estimate time — and provides a matrix to use as a guide.
The time anchor matrix should be read from left to right starting at the top left number and working your way down line by line. Seow also provides some guidelines on using time anchors:
- Time Anchors are time estimates under an hour (1, 2, 3, 5, 10, 15, 20, and 30 seconds or minutes)
- Use the Time Anchor Matrix to express ranges
- Never skip over a number when representing ranges (examples: “Installation will take 2 to 3 minutes” “The download will take about 20-30 seconds”)
- Ranges prevent users from holding us to exact numbers (or at least they are less likely to do this when given a range)
- Use anchors for countdown units in timers and progress bars
Putting all of this together is pretty simple. If the process will take less than 5 seconds, you can just use a spinning beach ball, spinning circle or some other busy animation. If the process lasts longer than 5 seconds, you will generally want to use a progress indicator (such as a progress bar) and time anchors to give the user a rough estimate of how long the process will be. There may still be a wait, but the user will not have their attention called to an exact number or hold the system accountable for that exact number.
In the end, this is truly about smoothing out the waiting process for the user. Using these techniques will not magically turn your users into Zen Monks with infinite patience. But these changes (along with other changes I write of in this series) begin to give you a synergistic effect where the sum of the small changes equals far more than the sum of their individual parts. It’s the small changes that matter to users in many instances. This has recently been written of in Dan Saffer’s book, Microinteractions. I recommend checking out his work if you are skeptical of the small changes herein making a differences.
The next article in this series will focus on time units and 5 rules you should never violate when expressing time units.
