Progress Bar

What is a progress bar?

Also known as a loading bar, a progress bar is an icon used in design to visualize processes happening behind the scenes that are invisible to users. Common examples are when loading an app, or when downloading or transferring files.

Progress bars are designed around a part-to-whole relationship, with the whole being the total size of the task, and the part being the portion of the task completed so far. Typically they take the form of an animation, with a line or bar graphically representing the full length of the task to be completed, and an ever growing portion of that line changing to a different color as the task progresses.

In reality, though, most progress bars are fake. Or at least not truly representative of the progress taking place behind the scenes. Indeed, the information displayed on a progress bar is rarely connected to the task it purportedly displays information about in any meaningful way at all.

Rather, the true purpose of a loading bar is simply to show that something is happening; thus reassuring the user that progress is indeed being made. But the actual degree of progress is less important than knowing that the device is still functioning and that any delay is therefore not the result of a technical issue.

In any case, the actual progress of a task is often impossible to know. When performing a network request or other asynchronous action online, an app has no way of knowing how far along the remote process has progressed. It only knows the beginning and end; when the request begins and then when it succeeds or fails.

For this reason, on most apps featuring progress bars - such as Apple’s Safari browser for example - the progress bar will initially advance a certain amount, then slow to a crawl, before finally rushing to complete.

Why fake it?

A good UI provides feedback to its users. Feedback is especially important when user action prompts a delayed or asynchronous effect, such as downloading a file, initiating a process, or submitting a request that must be validated by a server.

Whenever an app asks a user to wait, it’s important that the user be informed that they’re waiting, and why. Otherwise the user is likely to believe that their action hasn’t been received, or that they’ve frozen, broken, or otherwise killed the app.

No one likes to wait, and yet sometimes waiting can add value to what follows. Comparison apps, especially in the security and travel industries, often introduce artificial waiting in order to make their results feel more valuable; as if they were the outcome of heavy bespoke calculations. It works!

When waiting is just waiting, be sure to choose your progress bar carefully. In one famous example, Facebook found that by replacing their branded loading indicator with a stock device spinner, users were more likely to put blame for the delay on their device than on Facebook.

In any case, though, no matter how well you design your progress bar, your user shouldn’t be given too much time to admire it!

Progress bar design: best practices

A progress bar has three states: idle, loading, and complete. (In practice, it would also have a fourth state: error). In addition to designing each state and working out the transitions between those states, be sure to also protect against certain events in certain states. For example, whatever event brought the user from idle to loading should no longer work once they’ve reached that loading state. Finally, if you’re expecting a long load, offer an option to cancel the process.

Want to experiment with Apple’s misleading-but-effective progress bar animations? Try animating with Keyframes feature from Framer Motion!