Money for usability 'repays bottom line'
Subscribe now for $100 (23 issues) and save more than 37% off the cover price!
Get the latest news from Computerworld delivered via email.
Sign up now
Improving the usability of an electronic device or software application could mean more to a business's profit or market share than recruiting an extra developer to get the innovation to market more quickly.
“Usability is often paid lip service, and sought as a rubber stamp,” says Suzanne Currie, usability consultant with Auckland location technology company Navman. “Adopting usability means reapportioning dollars in the engineering lifecycle. Most people in authority [over the development budget] believe that the value of another programmer is greater than the value of a usability engineer. That is the largest hurdle I face in working internally with companies.”
In a recent presentation to the Computer Society in Wellington Currie argued that today’s user is becoming more discriminating over usability. “Where a customer might once have said ‘I can’t get how to use this; I must be dumb’, I now hear them saying ‘I can’t use this; the product is stupid’.”
A dissatisfied user, even if given the product for use at work (for example, a travelling salesperson using one of Navman’s handheld route-planning devices) may purchase a less awkward product from a rival company, be "converted" to that maker long-term and directly hit the original supplier’s bottom line.
Usability design and evaluation can operate at various levels, from a general appreciation of the potential uses of the product to a detailed consideration of each physical or logical element, she says. It may be more appropriate to work in a “black-box” way, considering only inputs and outputs, so changes in the system’s inner workings won’t need usability re-evaluation. On the other hand, a “white-box” evaluation with knowledge of the internals may find a more efficient way of solving several problems at once by changing one or two elements.
Proponents of “use cases” — formal descriptions of the ways in which the product may be used — are often unclear about the level at which they are operating, Currie says, and such lack of clarity in usability-test planning will affect the ultimate utility of the product.
And use cases are not, by themselves an adequate test of usability, she says. There are well-tested general theories of the way people approach the use of a new object, and often there is no substitute for having a user operate a prototype and talk as they go about what they are doing and the problems they find.
It is sometimes useful to think of the device or application as another person with whom one is having a conversation, Currie suggests.This conversation may not be limited to two parties, but may involve multi-way interfaces between other people and objects. For example, in Navman's case a physical map, the car, road and other passengers.