Faster Progress Bars: Manipulating Perceived Duration [pdf]

Link to the article so you can actually see test variables: http://www.chrisharrison.net/index.php/Research/ProgressBars...

Hey all, author of Designing and Engineering Time here. I am now a startup evangelist with Microsoft, but very happy to revisit this timeless (no pun intended) topic.

Remember that there is not only just actual duration vs perceived duration, but also how much users are willing to tolerate a delay, and whenever I get a question on how much people are willing to tolerate, I always ask if the users know/appreciate the value/return of what they are waiting for.

The delta between what was perceived and what they expect or are willing to tolerate, I submit, regulates user satisfaction. Some techniques manipulate perception, others manipulate tolerance (or expectations) - both are as effectively as actual code refactoring - but sure as hell cheaper.

Happy to share PDFs of the book and chat more. Ping me @steveseow

Don't have a link, but I recall research showing greater user satisfaction if you bias the progress bar to start artificially slow so that it can always be slightly accelerating. The acceleration of the bar helps to cancel the acceleration of the user's impatience.

If you find this article interesting, you should check out the book 'designing and engineering time'. Aside from having a great title it is filled with interesting tips regarding perception and user interface design.

Additionally, a progress bar which initially advances quickly but advances slowly at the end is perceived to be slower than a progress bar that is purely linear with respect to time. And a progress bar that starts slow then finishes quickly at the end gives the perception that the task took less time than it actually did.

I'm working on a side project (kind of on the backburner) JS library to drive progress bars based on perceptual tricks like these, and using estimates instead of actual progress monitoring (linear regression will be used to adjust the estimates over time), and this is certainly good data to have for that.

Any studies that contrast progress bars with telling the user what % is complete or how much time is remaining?

I wonder how long until people get used to artificially-accelerated progress bars, and we need to exponentially accelerated them to make people thing things are going smoothly...