0.1s to 1s is about the limit to keep it snappy.

0.1 second is the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.

For example, this is the limit from the time the user selects a row in a table until that row should highlight or otherwise give feedback that it’s selected.

1.0 second is about the limit for the user’s flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.

For example, if sorting a table according to the selected column can’t be done in 0.1 seconds, it certainly has to be done in 1 second, or users will feel that the UI is sluggish and will lose the sense of “flow” in performing their task. For delays of more than 1 second, indicate to the user that the computer is working on the problem, for example by changing the shape of the cursor.

10 seconds is the limit for keeping the user’s attention focused on the dialogue. Anything slower than 10 seconds needs a percent-done indicator as well as a clearly signposted way for the user to interrupt the operation. Assume that users will need to reorient themselves when they return to the UI after a delay of more than 10 seconds.

For example, exporting a report as PDF should happen under 10 seconds. A percent-done indicator should preferably be shown while the export is being created.

For longer delays, users should be able to perform other tasks while waiting for the process to finish, so they should be given feedback indicating when it’s expected to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect.

Delays longer than 10 seconds are only acceptable during natural breaks in the user’s work, for example when switching tasks.