Heating Water: UX principles from your microwave
When I was at WebMD back in the late '90's, I often worked on pieces of the site that were designed by Tog. (If you haven't heard of him, check out his Wikipedia page). I developed a sincere respect for UX engineering because of him.
Today, I was looking for a decent set of UX guidelines to give to people who were struggling to understand why it is important. I found Tog's, and this particular portion of the article really struck me. <!--break-->
- Look at the user's productivity, not the computer's.
-
People cost a lot more money than machines, and while it might appear that increasing machine productivity must result in increasing human productivity, the opposite is often true. In judging the efficiency of a system, look beyond just the efficiency of the machine.
For example, which of the following takes less time? Heating water in a microwave for one minute and ten seconds or heating it for one minute and eleven seconds?
From the standpoint of the microwave, one minute and ten seconds is the obviously correct answer. From the standpoint of the user of the microwave, one minute and eleven seconds is faster. Why? Because in the first case, the user must press the one key twice, then visually locate the zero key, move the finger into place over it, and press it once. In the second case, the user just presses the same key–the one key–three times. It typically takes more than one second to acquire the zero key. Hence, the water is heated faster when it is "cooked" longer.
Other factors beyond speed make the 111 solution more efficient. Seeking out a different key not only takes time, it requires a fairly high level of cognitive processing. While the processing is underway, the main task the user was involved with–cooking their meal–must be set aside. The longer it is set aside, the longer it will take to reacquire it.
Additionally, the user who adopts the expedient of using repeating digits for microwave cooking faces fewer decisions. They soon abandon figuring out, for example, whether bacon should be cooked for two minutes and ten seconds or two minutes and twenty-three seconds. They do a fast estimate and, given the variability of water content and bacon thickness, end up with as likely a successful result with a lot less dickering up front, again increasing human efficiency.
This mode of thinking is, I suggest, profoundly difficult for software developers. Just as the above requires a cognitive shift (some might call it a Gestalt shift) in the way we have to think about the problem, software developers are often guilty of failing to shift from "programming mode" back to "what it looks like for an average user." Some of us get obsessive over details that might gain milliseconds of machine time, but add another button click, page load, or worse to each user's task.
Read the rest of Tog's list, too. It's totally worth it.
