Progress Bars vs. Spinners: When to Use Which

by on 11/15/16 at 8:13 pm

How would you feel if you asked someone at the store where an item was and they just stood there? You would probably get frustrated and move on. Users find themselves in this situation when same they see a spinner on their screen for a long time.

Spinners Are Not For Long Processes

Spinners don’t tell users how long the process will take to load. If you use it for long processes, they’ll end up wondering if something went wrong with the app. The lack of feedback creates uncertainty which makes users assume the worst.

They’ll assume that it’ll take a long time to load which discourages them from waiting. Impatience will set in and they may hit the back button or exit out of the app.


4-Second Rule

If you want users to stay on your app, don’t use spinners for processes that take longer than 4 seconds to load. A research study has found that most users’ tolerable wait time is 4 seconds. This means that their behavioral intentions begin to change after 4 seconds.

When to Display a Spinner

Users expect an app’s response time to be immediate. An immediate response time is less than 1 second. If they don’t get any visual feedback after a second, they start to worry.

If you have a process that takes longer than a second, you should display a spinner. This lets users know that the app is loading which will ease their worries.


Progress Bars Make Long Processes Tolerable

If a process takes longer than 4 seconds to load, you should use a progress bar. Users are more willing to tolerate a long wait time if they see a progress bar.


This is because it sets a clear expectation of the load time. The linear bar allows them to see that progress is being made which encourages them to wait. If they see a spinner, they can’t see any progress and don’t know if their action even processed. This gives them no incentive to wait.

How to Display a Progress Bar

A progress bar needs to show users how much progress is being made. Your bar should animate from left to right at a gradual and consistent pace. If the animation pauses for too long, users will think it’s stuck and won’t want to wait.


You should also add a numeric estimation to your progress bar. If the process is under a minute, display the percent done or number of items loaded. Inform them what activity the app is doing as it loads.

If it’s over a minute, you should give them an estimated time remaining. This lets them know that they can expect a longer than usual wait time. Displaying the number of minutes allows them to leave and come back to their screen.

Don’t Go Spinner Crazy

Many designers have a habit of using spinners for all their processes. But when you use spinners for long processes, you create user frustration. Avoid this by using progress bars when needed.

Progress bars make longer processes tolerable. Users don’t mind waiting if they know the app is doing work for them. But if it’s taking longer than expected, they need visual feedback. Not knowing what they’re waiting for makes them impatient and leave.


Light Resume Light Freelancer Wireframe Sheets Wireframe Patterns Flow Patterns


Elegant Themes UX T-Shirts

Author and founder of UX Movement. Founded this site to help you learn user experience design for a more user-friendly world.

6 Responses to “Progress Bars vs. Spinners: When to Use Which”

  1. Kyriakos

    Nov 16th, 2016

    Although I complete agree with the idea I think spinners also serve another purpose. In many occasions the task completion progress is not known or very hard to know (e.g. a slow query is running in the database) in which case there’s no data to feed the progress bar. That’s why a lot of developers resort to the quick and dirty spinner instead of showing real progress.

  2. Adrian

    Nov 17th, 2016

    In this case is an indeterminate progress bar style any better?

    It probably makes me thing it’s a longer progress than a normal spinner, just because it’s closer visually, and isn’t quite as anxiety inducing.

    Another thing I’ve seen Google do in particular is flash up a notification when things are taking longer than normal with some help text on how to resolve the situation or ask the user to try again later, perhaps saving any state if possible.

  3. Daniel

    Nov 17th, 2016

    Hey Anthony, I see your point, but since both spinner and progress bar usually appear when something is loading, we have to consider the speed of the data connection as well. It is pretty much impossible to predict how long a certain action will take for individual users because, what takes only a second on a super-fast cable connection might take way longer on a crappy mobile connection.

    • Rajnish

      Mar 23rd, 2017

      I am agree with Daniel. In most of the cases its depend on the speed of data connection. I would recommend if you want to use the spinner then use the percentage along with it. that will help user to understand better that how much time it is going to take.

  4. Paul Marshall

    Nov 18th, 2016

    Great post, I think I agree with Kyriakos that the likelihood of you being able to calculate the progress is often remote.

    I’ll definitely keep a note of the timings though, very useful.

  5. Eneroth3

    Jun 6th, 2017

    Regarding how to display the progress bar I’d like to add that it depends on how accurately the time can be estimated. A progress bar that jumps back and forth between 4 hours and 32 minutes simply because the speed of the connection varies is less helpful than one that says 43%, even if it takes an hour in total. Unless the estimated time is accurate within a +-50% tolerance or so I’d say showing the percentage is better.

Leave a Comment