text of use varies significantly from user to user, or day to day, the homogeneity of usability testing becomes a poor proxy for real use. And, again, perhaps the richest data comes from niche contexts within the long tail (e.g., ice rinks, car repair shops, hospital waiting rooms). We need methods that can anticipate and account for unexpected and continuously changing contexts of use. And we need to see the richness and variability as an opportunity for universal design.
May + June 2009
As computing devices get smaller and more pervasive, they are used in a broadening array of contexts. For example, company email accounts were once reserved for in-office communication during the workday. Then, in the 1990s, employees were supplied with laptops to work anytime, anywhere, introducing the world to the concept of telecommuting. Now, with email-enabled phones, employees can read and respond to work email at any hour of the day or night, from truly anywhere.
Beyond mobile phones, there are thousands of other mobile computing devices. There are satellite radios and Internet radios that can be used in the car, on a boat, out camping, or within the home. There are fitness systems like the Garmin Forerunner or the BodyMedia Go WearFit that sense and track physical char-
acteristics like heart rate or skin temperature to calculate fitness metrics. The sensors can be used during athletic or day-to-day activities, or can be repurposed as health-reporting tools. There are complex chips and sensors in late-model cars that can track our driving behavior, monitor our safety, and improve our driving skills.
The point here is not that computing has moved into the domain of automobiles, fitness, or music. It’s that these computing applications themselves are pervasive: They live in a variety of different environments, scenarios, and contexts of the users’ choosing. While context of use has always been a part of usability, the variability is making our job much more difficult. In the past, we could study and then simulate the anticipated context of use: an office, a vehicle, a kitchen, or a school. Even if the context were outside the norm (e.g., an operating room rather than an office), we could reasonably estimate the context as a category. In general, the per-device variability was much lower.
Most contexts of use today, however, live in the “long tail.” The increasing mobility and ubiquity of devices makes predicting the context of use, and thus its usability, more difficult. Sure, we can test the interface in an operating room, or in a yoga studio, or in the airportpark-ing lot. Besides the obvious cost of repeating our tests, how can we even be sure we’ve chosen the right contexts as our benchmark? These three examples represent a raw sampling of the 1,529 potential contexts of use for the product. And as the con-
Introducing a product or service used to involve an inevitable production lag. With traditional hardware products, there were upfront design and development costs, plus the huge production costs. The factory must be built or reconfigured, new machinery or dies developed, and workers hired or trained. The initial delays are considerable, and they are repeated each time a change is made.
As we all know, cycle time has been shortened dramatically for software-based products and services. While the early design and development phase still exists, the deployment phase is essentially zero. Design and development can now be intensely iterative, with little additional cost. Downloaded applications are upgraded with weekly service patches; new features appear, often without notice, within Web applications; Web services are refined almost hourly as errors are fixed. In the growing open source community especially, the “invisible hand” of shared revision and correction has dramatically accelerated the pace of development. A study
References:
Archives