The 90 Second Rule
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.
December 1st, 2006 at 6:59 pm
Great post, Elliotte. I’ve not been reading the junit list for a while, but I think there have been plenty of active discussions about exactly the sweet spot for time taken to run tests, with good contributions from Cédric and JB.
As an aside, what time of year was that photo taken? The light / sky looks fantastic.
December 6th, 2006 at 4:32 am
Looks like a fine article, but I didn’t finish it, I stopped after 90 seconds or so 🙂
December 12th, 2006 at 11:15 pm
[…] Start your timer. Elliotte Rusty Harold about the 90 second rule: “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.” […]
December 24th, 2006 at 10:22 am
[…] Elliotte Rusty Harold muses whether the 90 second rule applies to cases beyond shopping. Taking care of a customer in two minutes is a success; doing it in three minutes is a failure. […]
December 29th, 2006 at 8:27 am
Note that in Ireland and Britain, pedestrian crossings at junctions also “really work”, but in a way that sometimes confuses tourists: The lights have a preset cycle, but skip the break for pedestrian crossing if the button is not active. The occurence of the pedestrian crossing break deactivates the button after one run. Thus, if you don’t press the button and it isn’t lit up (active already), the break doesn’t happen, and the lights just cycle through traffic control again. But if you do press the button, the break always occurs at the same point in the traffic light cycle, and thus takes a variable time to happen from button press time. I’ve lost count of the times I’ve seen american tourists waiting aimlessly at traffic lights, not realising they have to press the button, because the first few crossings, some local has pressed it and the americans have noticed the sequence seems to be preset like the “fake” buttons in the USA…
December 17th, 2007 at 5:29 pm
I think there’s also a 20-minute rule for something like this… I’d like to make one up. For example, it states that any big event that lasts longer than 20 minutes will seem shorter than it actually is if you participate in it, and much longer if you’re waiting for them.
I’m thinking of the possibilities for these rules; for example, a 2-hour rule for movies; if a movie lasts for less than 2 hours, then it will seem to last only 30 minutes.
December 29th, 2007 at 10:59 am
Another example is with $$$. I’ve had many an argument with coworkers about the taxes we pay when we work overtime. Many, if not the the majority, of my coworkers believe that if we earn more than one day of overtime pay in a given week, the pay bumps us into the next tax bracket and thus, the government takes a higher percentage out of that particular paycheck. It’s complete fiction; I’ve done the math. I can pull out a calculator and show them and they refuse to believe me. I’ve said to one coworker, “I’ve done the math, the numbers don’t lie.” And his response was, no joke, “But I’ve been doing this for 20 years!”
If they take $250 out of $850, which is roughly 30%, the paycheck ends up $600. Without a calculator or a decent sense of proportion, when they take 30% out of 2000, and the paycheck ends up $1400, they might think, “I got raped; they took out almost half!”
I think this boils down not merely to people being unable to gauge time or percentages, but being conditioned to look for things to complain about.
I used to work in a restaurant and if a table had to wait 15 minutes, they would complain that they were waiting over 30.
January 1st, 2008 at 5:01 am
I’m not sure you’re correct about WoW. As I understand it, the dungeons are stateful – that is, each separate party that enters a dungeon explores their own instance of the entire dungeon, including monsters. After all, there are 40 million players and nowhere near 40 million different dungeons – you’d have dozens of hundreds of parties all trying to cram in to kill one single quest-related monster.
January 2nd, 2008 at 5:15 pm
Providing feedback about the wait time helps. I hypothesise that predicting the wait duration isn’t always helpful, though, because — based on my anecdotal evidence — it’s annoying because it’s often wrong.
A few decades ago, when phoning directory assistance, the phone company in Holland used a recording to announce the number of people in the queue. “There are 12 people waiting ahead of you.” [“Er zijn nog 12 wachtenden voor U.”] And it would count down: 11, 8, 2, 2 (again), my turn!
In my experience, this was better than trying to predict the time to completion. We all know from experience that “serving people” in a queue takes a variable and unpredictable amount of time, whereas “about 2 minutes” is a much more specific commitment.
[On a different note: does it bug you, in the movies, that during the last 30 seconds before a time bomb blows up, the timer practically stops dead when the camera looks away at the sweaty face of the hero trying to cut the blue NO THE RED wire? Every ten seconds of action fits in a mere 3 seconds on the bomb’s timer.]
January 2nd, 2008 at 6:48 pm
If you are sitting in traffic at a red light, after a period of time you’ll notice the drivers around you start to edge forward, anticipating the green light – i’ve never timed it, I will next time, but I suspect it’s around 90 seconds
January 6th, 2008 at 8:19 pm
@Dan: Not all quest mobs in WoW are in instanced dungeons. It’s those that aren’t that you have to wait for if someone else kills it. You don’t have to worry about all 40 million people cramming into the same space because there are multiple servers and each server has plenty of space for people to adventure in. I have a tool that periodically performs a census of everyone logged onto the server and have never seen much more than 1500 players on at the same time.
March 9th, 2010 at 1:31 pm
[…] The Cafes » The 90 Second Rule Hace muchísimo que leí este artículo, y estaba intentando encontrarlo de nuevo para justificar por qué un tiempo de espera en una operación larga aún puede ser considerado satisfactorio por debajo de 90 segundos. Lo cual me ha llevado al libro de Paco Underhill… (tags: blog psychology webdesign usability time perception) […]