Why Is It Hard To Make Things Easy? (part two)
Yesterday I argued that one of the difficulties in designing for usability is fundamental tension in the design process, for example as a simple interface requires complex implementation, or that different people react differently to the same interface. Today I would like to explore the problem of usability from a business perspective.
Once again, I think we need to begin by examining the subjective nature of usability. From a business perspective, the problem with subjectivity is that it is hard to measure. In other words, it is hard to know when we have a sufficiently good interface, or to compare two different approaches. Yes, there are means to make these judgments, but they are expensive and time consuming.
The real issue with subjectivity is that, while usability is subjective, many other aspects of design are not. For example, it is easy to quantify the stability of a program: we can track the number and recurring frequency of bugs, for example. We can quantify the number of features in a given design and justify a particular feature or feature set by describing a target market and the cost of implementation. We can measure application performance in terms of execution time, memory usage, and storage footprint. All of these things are relatively easy to do, and each provides useful input into business decisions.
In fact, the problem may be that all this other information crowds usability out of the design equation. For example, it is much easier to quantify a trade-off between extra features and application execution speed than it is to quantify the trade-off between extra features and usability — largely because it is hard to quantify usability. As a result, we push usability aside – or at least we are tempted to say that it is “good enough.”
Unfortunately, the result is that we tend to overlook the importance of usability. Usable design benefits not only those that have difficulty learning a new technology, it also benefits people who can make do with that technology but perhaps could be more efficient in their actions.
In fact, the existence of consumers with differing skill levels has led some to say that usable design should consider two different extremes: how to make an application accessible to novices, and how to enable shortcuts for “power users.” The classic example here is a menu bar. Individual menu items lay out the possible functions for the novice user to browse, while keyboard shortcuts allow the power user to continue typing without having to move one hand over to the mouse or trackpad, navigate to the menu and select the desired command.
While I understand the logic, I think that this rationalization is a bit of a compromise. To me, the most usable designs will help the novice and the power user simultaneously, rather than offering different systems for them. Instead of keyboard shortcuts and menus, what if the application suggested appropriate actions based on context? Then the power user could focus on the task at hand rather than remembering keyboard shortcuts, and the novice would have immediate access to relevant functionality without having to sift through an array of menu choices.
The traditional approach to usability is to layer it on as an afterthought. First, start with the functionality that we need to bring in as many customers as possible, and then we will get creative and figure out how to present all those functions in as logical a way as possible. But if usability really matters, why don’t we trim back the functionality to its core and then figure out the best way to implement and to present that functionality so that consumers reap the greatest benefit?
It may sound as if I am arguing that function follows form, but I am not. Instead, my question is whether the proliferation of functionality (with the noble business goal of elbowing out competitive products and addressing ever-larger markets) should be prioritized over making the basic purpose of the application or device as accessible as possible. Then, once we have a foundation that is usable, it should be easier to maintain usability as we layer on more functionality.
I believe this is the approach Apple has taken with the iPod, and the reason it is so successful. They started with something simple and basic – a music player. No color screen, no fancy animations, no video. Just a relatively large amount of storage, decent sound quality, a conveniently sized package, and easy synchronizing with a computer. Later came the other improvements. Now the iPod line includes many of the other bells and whistles – color screens, fancy animations, video playback, even (if we include the iPhone in the mix) phone calls, web browsing, email, etc. But the device continues to be easy to use because the foundation was usability. There is a lesson here, but I wonder if we are ready to accept it.
