While reading Paco Underhill’s Why We Buy, I was struck by his discovery of the 90 second rule:
We’ve interviewed lots of shoppers on the subject and have found this interesting result: When people wait up to about a minute and a half, their sense of how much time has elapsed is fairly accurate. Anything over ninety or so seconds, however, and their sense of time distorts—if you ask how long they’ve been waiting, their honest answer can often be a very exaggerated one. If they’ve waited two minutes, they’ll say it’s been three or four. In the shopper’s mind, the waiting period goes from being a transitional phase in a larger enterprise (purchasing goods) to being a full-fledged activity of its own. That’s when time becomes very bad. Taking care of a customer in two minutes is a success; doing it in three minutes is a failure.
I suspect the rule applies to a lot more than merely shopping. For example, outside my apartment on Eastern Parkway there is a stop light. Like many stop lights in New York City, there are buttons you can press to request a walk sign. Unlike many of the stoplights in NYC, these buttons actually work. That is, after pressing the button, the light changes; and if nobody presses the button, the light will never change. I’ve timed this light repeatedly with my wristwatch, and it takes just barely under two minutes to change. That measurement is repeatable. Assuming nobody else has recently pressed the button, the elapsed time between pressing the button and getting a walk signal is always between one minute, 50 seconds, and one minute, 59 seconds. I suspect the signal is actually set to change after two minutes, and there’s a systematic error that makes me undercount it a little.
However if you ask locals how long the light takes, the estimates invariably run high. The lowest I’ve ever heard anyone claim is three minutes. The highest is around six minutes. The average estimate for the light is probably about four minutes. No one ever guesses that it takes two minutes to change (even though it does) and most people swear up and down that it takes longer than that, and will not believe it’s on a two minute timer unless you pull out a watch and time it with them.
In this case, I suspect the violation of the ninety second rule is actively dangerous since it encourages people to cross against heavy traffic rather than waiting for the light. Reducing the wait time to 90 seconds might make the intersection safer for pedestrians, who’d be much more likely to wait for the light before crossing.
I suspect the ninety second rule has been undernoticed and undervalued in the world of computer human interfaces because we mostly focus on the half-second rule instead. That is, anything that takes less than half a second is seen as instantaneous, and anything that takes more is not.
Recently there’s been some discussion of the four second rule; i.e. the amount of time that user will wait for a page to load before leaving and going to another site. I think that’s probably a debased form of the half-second rule. That is, it’s half a second the user doesn’t notice plus 3.5 seconds of time they do notice before they take action. However, I suspect there are cases where the user expects to wait and therefore doesn’t mind waiting, and it’s in these cases where the ninety second rule applies instead.
For example, when doing test driven development, you want to be able to run all the tests after every change. This requires them to be reasonably fast, but how fast? 5 seconds is clearly fast enough. 30 minutes is way too long. Where’s the happy medium? I hypothesize that it’s right around 90 seconds. Anything less than that is fine. Anything more than that, and you should start looking at optimizing your tests, or subsetting the test suite so you run only the fastest and most critical tests. (Other tests can be migrated into the functional test suite. They’re still run, just not as often.)
Here’s another example, in the World of Warcraft, monsters respawn a certain amount of time after they’ve been killed. If you arrive at a site just after another party has killed the monster, your quest requires you have to wait for it to respawn. Probably 90 seconds is the maximum amount of time you want to make someone wait here. Beyond that, you risk the player losing interest and quitting. (Non-quest related monsters don’t need to respawn so quickly.)
Generally speaking, you can get away with modal operations for 90 seconds or less, as long as you provide some feedback so the program doesn’t look like it’s hung. For example, if you’re transferring files over the network, a progress bar is enough feedback if the files finish in under ninety seconds. However, if the transfer is going to take more than 90 seconds, start considering parallelizing the operation so the user can work with some of the files before the last one has finished transferring. If you’re transferring a single large file like a movie, then consider playing it in streaming mode rather than downloading and then starting the movie. Furthermore, don’t pre-buffer for more than 90 seconds.
Where else might the ninety second rule apply?
If you need an outside eye to measure how much your product is making users wait, and how it might be improved. I’m available for consulting and expert design reviews. I specialize in end-user facing software and programmer-facing APIs, but I’ve been known to help out with devices like cameras, refrigerators, microwaves, and watches from time to time too.