This 70s UX gem still applies today

Laggy websites suck. The amount of suckiness started to really be quantified in the late 70s. At the time, the thinking was that it was OK for a computer to take 2 seconds to spit out a response because they thought it took people around 2 seconds to plan out their next task.

But by 1979, computer performance improved and response times started to fall under 2 seconds. At IBM, Walter Doherty noticed a beautiful consequence from the improve performance — a massive increase in productivity. He then ran a series of studies to measure the impact.

It turns out that the time the computer took to process a request was highly correlated with the user response time (the time it took the user to type in the next command). In other words, the longer the computer took to respond, the longer the user took to think of what he wanted to do next! Even a few hundred milliseconds in system response time made a huge difference.

Image for post
Image for post
At a 3 second system response time, it took the user 17 seconds to enter the next command. At a 0.3 second response time, it only took the user 9.4 seconds to enter the next command.

Doherty suspected that was happening because a user was storing the series of steps he wanted to take in his working memory. The long system response times were an interruption that made him lose his train of thought and ultimately caused lower productivity.

The conclusion here is that computer response times make a disproportionate impact on productivity. Your goal should be to get response times under 400ms. Does your app do that?

P.S. If you use Google Analytics, you can find the answer here.

Jim Elliott’s Blog
Computer World Magazine, June 1984

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store