August 17, 2005

"Make it faster...less clicks"

Usability engineers should be familiar with this request from clients. When gathering requirements and goals for an application / website redesign it is not too unusual for clients to come up with a request similar to the one stated in the headline. If the client is aware of the significance of such a request in the "big scheme" of things then there is nothing to say against it. If the client, however, thinks that "faster / less clicks" is the ultimate goal for a redesign, then the usability engineer should invest some time in educating the client if he does not want to get into trouble in later phases of the usability engineering project.

Where does this kind of request come from? There are at least two reasons that "inspire" people to ask for their systems being faster and operated with a minimized number of clicks.
  • People come across usability guidelines like the "Three-Click Rule", stating that each piece of information on a site should not be more than three clicks away. The idea behind this rule is a sensible one: minimizing the effort it takes users to find information. The trouble begins when people take this guideline (and others) as a law of nature. There may be very strong reasons for structuring a site in a certain way, even if not each and every piece of information can be reached by clicking three times (and saying "there's no place like home"...) An inappropriately used Three-Click Rule can lead to sites with incredibly wide but shallow hierarchies. Some remarks on the Three-Click Rule and its implications can be found in this article on, which also contains a link to a report about testing the Three-Click rule. So in case the usability engineer suspects some misconceptions of that kind with a client, the time to educate them that usability engineering is more than "Three-Click Rule followed: good site / Three-Click Rule broken: bad site" is well invested.
  • The second factor that contributes to laws...err...guidelines of that kind appearing in usability engineering projects is a more profound one: people are interested in measuring usability. This applies to usability engineers and clients alike. Clients are interested in knowing exactly how much better their system is after a redesign and usability engineers would like to tell them to prove that they delivered good work. From that point of view, measures like clicks, time to complete a task or number of errors are very attractive, because they enable the usability engineer to come up with hard numbers to describe the "usability" of a system and they enable the customer to quantify requirements ("Make it 20% less clicks"). Now, there is nothing wrong with including quantitative measures in a usability engineering project. But quantitative measures don't necessarily tell the whole story. Just think of the whole Emotional Design issue. It is not so easy to come up with a single number to describe how pleasant an interface is (to use / to the eye), but that does not render the hedonistic aspect of an interface any less important. So the importance of quantitative measures for a project depends heavily on the interface under investigation and the purpose it is supposed to fulfil. When designing an interface for a nuclear power plant, time to complete a task (let's take "shutdown" as an example) is obviously quite important whereas for a game interface, the interaction may not necessarily be optimized for fast task completion but for making the way to task completion as pleasant as possible. (You wouldn't expect to finish an adventure game in three clicks, would you?)
To sum things up: quantitative measures are not all bad, but one should be aware of the fact, that they are only part of the overall usability of an interface. Numbers - as attractive as they may be as requirements or benchmarks - will not give you the whole picture. (No, not even 42.) If the usability engineer is aware of this fact he can tailor his approach to the concrete system under investigation. If the client is aware of this fact, that's good, if not, the client should be educated by the usability engineer to set the right expectations and to understand that usability is more than calculating numbers.

No comments :