Time is a very fluid thing. Ten minutes can feel like an eternity for a user in a hurry, or mere seconds when the user is engrossed. Steven C. Seow addresses these issues of time perception by pointing out some good ideas to try and some bad practices to avoid.

From the author of

Every interaction in your solution (software applications, internal company
tools, instruments, websites, and so on) requires end users to expend time. How
it’s designed—internally in the data access layer, the business
logic layer, etc., or externally in the presentation layer—can make or
break the user experience. My book
Designing and Engineering Time: The Psychology of Time Perception in Software
presents various techniques that you can apply to the design of your solution
(particularly at the user interface level) and violations that you should avoid.
This article summarizes some of those key techniques and violations, listing the
do’s and don’ts for five application features that are notorious for
wasting not only users’ time but also their tolerance.

Downloading and Uploading Files

Downloading and uploading are common processes for many kinds of applications
and websites. Users are accustomed to seeing file transfers in progress, but
most of the time they just want to know how much longer it’s going to
take, not how long it has taken so far. (No point in frustrating the user by
emphasizing that he’s been waiting quite a while for your app to finish
up—unless you want your support staff to get nasty email
messages.)

Don’t report elapsed time.

Do give "good faith" time estimates.

Don’t Report Elapsed Time

Never report elapsed time in your user interface (UI) unless it’s
absolutely necessary to do so. Knowing elapsed time is useful only in limited
situations, such as for diagnostics and testing. Mainstream users typically
don’t benefit from knowing how long a download has taken so far, or how
long it took to complete (see Figure 1).

NOTE

Obviously, you may need to track elapsed time in algorithms behind the
scenes—to determine when some process should time out, for instance. But
telling users how much of their time you have used offers limited
advantages.

Figure 1 Unless
there’s a strong reason to display elapsed time, don’t show it in
your user interface.

Do Give "Good Faith" Time Estimates

Uncertainty is one of the biggest culprits in causing users frustration. Not
knowing how long something will take is infuriating in any situation—not
just when interacting with a software application or a website. To plan their
priorities and organize their tasks, users rely on the estimates provided by the
UI. If the wait is going to be long, for example, the user may want to step out
of the office or make an important phone call. Whenever possible, give users a
good estimate before the process starts, indicating how long the
process might take.