Last week I was lucky enough to attend Device Design Day in San Francisco. This annual one-day conference is mostly for designers who create consumer devices and the software that runs on them, but many of the points the speakers made could be taken to heart by anyone who develops, well, pretty much any kind of hardware or software.
Here are a few key takeaways:
Know who you're designing for. A couple of speakers made seemingly contradictory statements, but their very different design goals underscored one important point: Knowing who you're designing for is crucial to the success of the product.
Robert Brunner, former industrial design director for Apple and founder of the Ammunition Group design consultancy, encouraged designers to be disruptive, noting such iconic products as the Sony Walkman, Tesla cars and Beats by Dr. Dre headphones. "'Risk' is not a four-letter word," he said. "Innovation equals risk."
But Brunner is focused on designing hip, stylish products for consumers. Cori Schauer, an ethnographer in the User Centered Technologies group at NASA Ames Research Center, said exactly the opposite. When NASA switched from analog to digital controls at its Mission Control Center (a.k.a. 'Houston') in the mid-'90s, Schauer revealed, the user interface remained nearly identical -- "a straight translation from the physical to the digital."
That's because a disruption to an interface that highly trained professionals have used for years could lead to unnecessary accidents and possibly cost astronauts their lives. In NASA's case, 'risk' is a four-letter word.
Research and design in context. Liz Bacon, who runs the Devise design consultancy (and who, by the way, showed extraordinary grace under pressure when an errant fire alarm interrupted her presentation), spoke about her experiences designing medical devices. As you can imagine, it makes a big difference whether a healthcare professional or a patient will be using a device, but equally important is what context it will be used in: at home, in a doctor's office, in a hospital ward, in an operating room, etc.
It's important to find out exactly where, when, by whom and in what circumstances a product will be used before you begin designing it, and to test it in the appropriate environment as you go along.
Karen Kaushansky, principal interaction designer at Jawbone, made the same point in her presentation about designing devices that talk to the user. When designing a talking device (or one that makes other noises), she advised, ask lots of usage questions: Does it have a screen in addition to the audio interface? Will the user's attention be elsewhere while using the device (such as when driving a car)? Is the intent to provide instructions (as with GPS directions), offer information (such as a low battery warning), give real-time feedback (e.g., a car's parking assistance beeps) or add magic (Furby or other talking toys)?
Most importantly, ask whether speech (or whatever form of user interaction you're considering) is the best means of communicating with the user. "Should all devices talk?" she asked. "No, that would clearly drive us all crazy."
Consider non-use cases. Kaushansky made another point that should be obvious but isn't: What happens when the user isn't actively using the device? She showed us a video of a moving walkway at Chicago's O'Hare airport that endlessly repeats, "Caution: The moving walkway is ending," whether anybody is on it or not. That's just bad design.
She also recounted how users of Jawbone's Jambox wireless speaker tended to leave it on even when they weren't actively listening to it, with the result that the audio low battery warning would inevitably go off in the middle of the night. The company has tweaked the product to avoid rude awakenings.
Consider user expectations. Leila Takayama is a research scientist at personal robot maker Willow Garage. Among the many lessons the company has learned in developing personal robotic devices is that what users believe before they go into a situation matters.
If you tell someone a robot's really smart and it's not, she said, they're disappointed. If you tell them it's not that smart and it does something really cool, they're blown away. The old business adage that it's better to under-promise and over-deliver definitely comes into play here.
Another angle to user expectation is that humans expect robots to send the same signals we do. For instance, Takayama recounted how an under-development robot was standing in front of a door at the Willow Garage office for hours on end, trying to solve the problem of how to open the door. "But it looks the same when it's thinking really hard as when it's turned off," she said, so she stepped in front of it, interrupting the robot and angering several engineers.
The solution? Have the robot use visual or audio cues to show forethought when it's trying to do something and to signify reactions to success or failure. It could scratch its head while solving a tough problem or give a sigh when it's failed in a particular task. To that end, Willow Garage offers non-copyrighted Robot Sound Libraries for anyone to use with their own robots.
Robots, high-end headphones and NASA's Mission Control may seem miles away from the hardware, sofware or Web interfaces you design, but you'll create a better product if you know who will use it and in what context, what happens when it's not in use, and what expectations the user brings to it.
More Device Design Day fun: Check out the Robot Petting Zoo.