Dumbing Down da Doherty Threshold 💫

Design Crazy: S1 E1: The Crazy Design Blog by the humans @ Devfasttt!

·

2 min read

Ok, if you're here, welcome humans to a mind-numbing explanation of the Doherty Threshold 💫🤩

A little backstory everybody: In 1982, Walter J. Doherty and Ahrvind J. Thadani presented a research report in the IBM Systems Journal which transformed the previous norm for computer response timing from 2,000 milliseconds (2 seconds) to 400 milliseconds. This program was considered to be "addictive" to users when a human instruction was executed and answered in less than 400 milliseconds, which was considered to transcend the Doherty threshold.

So coming back to our original question: What the hell is the Doherty Threshold?
According to Doherty's Threshold, when the system feedback time falls below 400ms, a user experience changes from being agonizing to being addictive.

\ Doherty had a notion that this might be taking place as a user was cognitively storing the sequence of events he planned to execute. His train of thought was disrupted by the device's slow reaction times, which ultimately reduced his productivity.*

So the Key takeaways for you:

💫 Even when a procedure actually takes considerably less time, imposing a delay on purpose can boost faith in it and raise the perceived value of the process.

🤩 Enhance response times and lessen the sense of waiting by using perceived performance.

🧋 One method of keeping visitors' attention while loading or processing is taking place in the background is animation.

🎭 Irrespective of their accuracy, progress bars aid in rendering wait durations bearable.

🧩 Productivity goes up in much more than direct proportion to the response time reduction.

🔭 To hold the users' attention and boost productivity, give system feedback within 400 milliseconds.

Did we miss out something? Share your 💭💭 in the comments 🤩 below! 👇👇 We'll be waiting for your thoughts!