Should progress bars accurately reflect how close the operation is to completion during long operations?

Question

I'm creating a simple application. There's a certain operation that will take a long time to complete (~15 minutes), and I'm hoping to make a progress bar showing how close the operation is to completion.

I've notices that progress bars on some applications load slightly quicker at the start than at the end. It might just be because of the operation being performed, but it also seems like a good strategy for keeping the end user less frustrated because it'll appear to be loading fast, but doesn't go quite as fast at the end.

Is this a good strategy for keeping users happier during long operations? What are the pros and cons?

Answer 1

Depends on the context, but I would go a step further to say a 15 minute operation should run asynchronously (disappear into the background and let you get on with something else). Then you only need to give progress if the user actively wants to find out how soon it is to being done, and you can send notifications. You can see many examples of this pattern, including apps downloading on iphone, games on the ps4 etc.

There is a nice article on the Nielson Norman Group website regarding usability of progress bars: Progress Indicators Make a Slow System Less Insufferable.

To directly answer your question: If you need a progress bar and you can accurately determine the time, I can't see any advantage in trying to manipulate the end user into thinking it is coming quicker than it really is, even if this could be achieved by speeding up at the start.

As a deliberate strategy, it feels a bit too manipulative and is more likely to annoy than trick. If anything I'd want it to speed up at the end so I feel I've got some free time back!

It is unlikely that any of the progress bars you have witnessed are deliberately sped up at the beginning (although I can't second guess all developers intentions). I can't find any evidence of any of the big companies deliberately giving that as a design principle.

It is much more likely that it is either a bit of sloppy coding or an operation the developer has to guess progress for until enough data has been collected to show a sensible estimate. I don't know whether Microsoft are being self referential in their advice these days, but they clearly advise a realistic progress and avoiding the famous sitting at 100% for an additional unspecified amount of time.

Image courtesy of xkcd.

Answer 2

I've notices that progress bars on some applications load slightly quicker at the start than at the end.

Progress bars may appear to move more quickly at the beginning because a move from 1% to 2% represents double the amount of work completed, whereas, a move from 70% to 71% only represents a 1.4% change in the amount of work completed.

There may also be issues with granularity. For instance, if the progress bar is updated on a per-file basis and small files are moved early, the progress bar will be updated more frequently toward the beginning.

... it also seems like a good strategy for keeping the end user less frustrated because it'll appear to be loading fast, but doesn't go quite as fast at the end.

Bad idea. You're proposing to make the progress bars in your application intentionally lie. As soon as users realize this is what you've done, you'll have lost credibility.

Is this a good strategy for keeping users happier during long operations?

No. If users time the beginning of the operation, say the first 10%, and estimate total task completion time to be 10 min, but your application ends up taking 15 min, why would you expect them to be happier?

If you're going to misrepresent data to the user, you should do like Scotty on Star Trek. Show slow progress at the beginning, and gradually speed up toward the end. That way, if they calculate task completion as 20 min, but it only takes 15 min, they'll feel like your app saved them 5 min.

Answer 3

According to Progress Indicators Make a Slow System Less Insufferable by Nielson Norman Group:

One issue for designers and developers using percent-done animation is the difficulty in calculating how long the process is going to take. Here are a few ways to handle this:

• Start the progressive animation slower and allow it to move faster as it approaches the end. This way you don’t risk establishing a faster expectation than the system can maintain. Exceeding customer expectations always creates more satisfaction than disappointing customers by delivering less than promised. (Note that this slow-fast recommendation only applies to wait-animations; research has shown that for surveys, progress indicators that start fast and end slow reduce drop-off rates.)
• Provide a general time estimate. (Don’t try to be exact, as it will inevitably be inaccurate at some point and the site’s credibility will suffer.) A simple, “This might take at least a minute” or “About 3 minutes remaining” can be enough to inform the user and encourage them to wait it out. Always allow for extra time, just in case. If the action goes faster towards the end, then it’s a pleasant surprise. We’ve never heard a user complain, “Hey! I wasn’t ready for it to be done yet!”.
• Instead of showing a percentage number, consider showing the number of steps. Users might not know how long each step lasts, but knowing the number of steps at least helps them form an estimate.