scott@maya.com | MAYA Design
usability more difficult, if not irrelevant in the new paradigm.
[1] Whitaker, B. “Technologies Untanglers: They really make it work.” The New York Times, 8 July 2007.
May + June 2009
Usability and HCD grew to prominence with the expansion of the Web: We’ve written the standards, developed the testing protocols, and had a hand in designing the leading systems. While the roots of the field are much older, growth has been significant in the past 15 years. We’ve gone from invisible wonks to key “technology untanglers” [1].
Unfortunately, our field has barely evolved in that time frame. While the computing universe has shifted dramatically, we’ve clung to the same methods, advice, and processes. Without significant changes, the growth and influence of our field is unlikely to continue. Although the New York Times named usability a hot “emerging career field” in 2007, in many ways the height of usability has already passed us. Current usability work is a relic of the 1990s, an artifact of an earlier computer ecosystem, out of step with contemporary computing realities.
Usability can no longer keep up with computing: The products are too complex, too pervasive, and too easy to build. And in our absence, users and engineers are beginning to take over the design process. Five trends demonstrate the growing gap between usability theory and commercial practice—the “new realities” of computing haven’t been truly embraced by the usability community. The trends are, at a minimum, making traditional
First, the idea of a “computer system” has obviously changed significantly. Initially, usability and HCI research methods were developed to tackle stand-alone systems or individual devices or programs. As computers evolved, we tweaked our techniques to work with networked applications, linking a single provider to a group of consumers. Computing has continued to evolve, with users now interacting with a vast network of hosts, services, applications, and platforms. Most first-world inhabitants use this intercon-nected infrastructure on a daily basis, often without noticing the underlying infrastructure until the system breaks down.
Take the example of a location-based service, like the “Urban Spoon” application for the iPhone. The application provides real-time restaurant recommendations based on their proximity to your current location. The user launches the application on the handset, which identifies your location via GPS. The system returns potential restaurant ideas based on location and ratings in their database (i.e., highly rated restaurants are shown more often). With a shake of the phone, recommendations appear, cleverly, like reels in a
slot machine. The Urban Spoon collects ratings and reviews from users, as well as aggregated information from other sites like CitySearch and Yelp.
There are at least six pieces to the “enterprise” of Urban Spoon. First, there are three traditional interface components: the “store” interface for purchasing and downloading the application (managed by Apple), the slot-machine interface for requesting and reviewing restaurants (part of the iPhone application, from Urban Spoon), and the rating interface (part of the Urban Spoon website). But there are also three unseen infrastructure components that affect the application’s usability: the quality of the restaurant data (e.g., how many restaurants are available in any given area), the resolution of the GPS satellites (e.g., does it know I’m in Boston, or does it realize I’m in Somerville near Davis Square?), and the responsiveness of the system (e.g., do new restaurants appear in a timely fashion?).
Even if the system was perfect in every other way, a major breakdown in any of these six components would cripple the rest of the system in the eyes of users. Imagine a recommendation system with perfect GPS but with a very limited restaurant database; similarly, imagine if the system couldn’t resolve your location in less than a mile, making the quality of the actual restau-
References:
Archives