What is the best way to estimate remaining time for a progress bar?

In my case, it's a computing time, but I suppose this is a general issue of estimating the remaining time of a task in a user-friendly fashion.

Currently I'm using an estimated time based on percentage accomplished and using it to linearly estimate the time that remains. However estimation or load variation change will result in the time not decreasing anymore, or worse, going up rather than down.

I've been experimenting with "cheats" based on over-estimating the time initially, so the time tends to trend down in a more "friendly" way, under the assumption that people are happy if it ends earlier than planned, and unhappy if it ends later than planned.

Are there studies/experiments on the "good" ways to tackle that issue?


2 Answers 2


Maybe this paper, would be helpful: http://www.chrisharrison.net/projects/progressbars2/ProgressBarsHarrison.pdf

(...) backwards-moving behaviors were significantly preferred over both still and forward ones (p<0.001 for both). When grouped by change in velocity, accelerating behaviors (both forward and backwards) were significantly preferred over still ribbing (i.e., no velocity, p<0.05), while decelerating behaviors are significantly preferred over both still and constant velocity ribbing (...)

  • Links can rot. Care to summarize the article here in SE? Mar 31, 2014 at 23:09
  • 1
    Interesting article. @Jon: the idea is that a pulsating or animated progress bar can affect perception of time taken by about 10% vs a static progress bar. Apr 1, 2014 at 6:50

There are 2 nice studies on this, as referenced in this article.

For progress bars that display % actual progress:

  • Use backward moving ribbings.
  • Make sure that you downplay progress at the start and make it appear to accelerate it at the end.
  • Avoid pauses at the end.

For indeterminate activity indicators:

  • Faster pulsing or rotation generates the illusion of faster progress.

I generally prefer to keep progress bars as indeterminite activity indicators for simplicity, unless there is a specific use case where the user must be aware of the specific progress.

  • 2
    As a dev, I prefer indeterminate activity, but as a user, I'm really annoyed by indeterminate activity for anything lasting more than handful of seconds. Apr 1, 2014 at 15:31
  • @EricGrange Yes, but I guess that for activity where the user has to wait longer than that would fall into the ux-feedback category (Interfaces should provide feedback about their current status. Users should never wonder what state the system is in. [Source: Nielsen])
    – Franchesca
    Apr 2, 2014 at 9:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.