When is it appropriate to intentionally delay an application's actions?

Question

I was in a discussion in another forum where I disagreed with the purpose of intentionally delaying an application's actions, and I'm hoping someone can clarify where doing would be considered acceptable design.

The scenario presented by the developer was that in their application, they add a delay of "a second or so" when updating a record—simple items like a phone number, address, and the like—saying that "Humans are usually happy to wait for a couple of seconds and are more disturbed when something happens instantly" and actually going so far as to show a progress bar for even the simplest actions.

My point was that intentionally delaying actions is typically a sign of poor design decisions, and that the progress bar should only appear when an action is going to take an extended period of time; if a transaction takes only a second that there are other ways to let the user know the state has changed. It may only be a second here and there but that time does add up and to delay things unnecessarily is just wasting the user's time, and only because one may think the user would be concerned if there were no feedback of some kind.

I want to ask the community what they think would be an appropriate use of this technique. I'm not looking for materials that would specifically disprove either position. But I did want to get a better understanding of why one would want to do something like this because. Frankly, I'm not buying his argument, but I also don't mind being proven wrong as long if I learn something from this.

I've tagged this question community wiki because I've looked for questions related to this, but they all deal with how to actually perform a delay as opposed to the context in which a delay is done.

Answer 1

Actually, this came up at my job recently. We were writing an application that integrated with a 3rd party application's database and had to write a record to a table. The full details of the application are unknown to me (I was just fixing a bug, not writing the whole application), but a bug surfaced whereby records were being duplicated in a table.

The table is just a log of something that happens. Event details and a time stamp, nothing terribly complicated. But the time stamp, as it turns out, is accurate only to the second. So what was happening was that, in our application, in rare instances someone would be able to write the "same" record twice by being able make an edit and save it in less than a second.

It had to line up perfectly, they had to load it just as the second was starting and save it before the second finished, but in a quick data entry form sort of way it was physically possible.

This confused the 3rd party application's internal logic and it complained about the duplicate records. We couldn't change that application, we couldn't change the database schema in any way, we could only change our application. It was a bit critical that "something be done" quickly, so all we did was add a 1 second delay in our application to the save function. The users claim they don't see a difference and the system doesn't complain about duplicate records anymore.

I wouldn't exactly present this as an example of when one should use a delay, since I'm much more a fan of designing better software and insisting that others (vendors) do the same. But in this particular situation it was the only viable solution.

Answer 2

Adding a delay is just silly in my opinion. Adding an animation or some indication that an action has occurred may well be appropriate though but that's not quite the same thing

Answer 3

The goal of an application is to serve the needs of the user. Intentionally making a program slower doesn't properly serve the needs of the user. Applications can be thought of as hurdles the user must overcome to accomplish their real task, and making the application slower is akin to making the hurdle taller.

If you're concerned that the user will think "that was too fast, it must not have worked" then you need to rethink the strategy. And by that I mean, don't slow it down but rather think of how you can provide other feedback that the action completed successfully. For example, do what google does and display how long the action took. This solves two problems: it lets the user know the action finished, and gives them additional feedback that the system doesn't just seem fast but is measurably fast which will raise their confidence level.