We’ve all got our own personal benchmarks for what makes a good user experience. My personal list includes a few: Does it delight me? Will I recommend it to my friends and colleagues? Would I have used the same approach if I had designed the product? I’ve found among some product executives one particular pattern for this subjective evaluation criteria that is both humorous and troublesome: “Would my mother/grandmother/Luddite Uncle Bill be able to use this product on the first try?”
While there is a sort of noble aspirational quality to this kind of thinking—let’s make everything so dead simple that any person can use every product—it also sets the bar for the experience rather low. I imagine a sea of step-by-step wizard dialogs that target the lowest common denominator and force everyone else to step through the same predefined (and very explicit) experience. If I’m designing a product for people who have specialized knowledge, I want to leverage that knowledge in the product. Why force people to walk when they can run? I’ll want to provide these people with clear, appropriate pathways through the product, but I also want these specialized users to be able to forge a variety of their own pathways through the interface, dependent on the specifics of their situation or how they want to do things.
I once worked with a client to design an intravenous medication delivery device called an infusion pump. This is a machine that nurses in hospitals use to administer drugs to patients by attaching a bag of medication to the device and specifying delivery parameters such as how long and how fast to dispense the medicine. This is critical stuff; the consequences of a mistake could be catastrophic. Based on our field research, we learned that the nurses who use these devices are required to attend an in-service training session to learn how to use new clinical equipment such as this infusion pump. We also discovered that even when using a new device after training, nurses prefer to watch others who were more experienced use the device until they felt comfortable with it themselves. Under no circumstances, ever, would a nurse even consider walking up to an IV device that she had never seen before and attempt to program an infusion. It just wouldn’t happen.
When our client wanted to usability test some design concepts with nurses, we helped them create testing scenarios and identified what we hoped to learn from the test. We also told our client how important it was to make the testing environment mimic the real world environment as much as possible. While we couldn’t do a full in-service session on how to use the new device design, we did specify that the test should start with a brief overview of the new product and how it worked.
Our client, however, was very interested to see just how intuitive the new design was. If it was a good design, they argued, wouldn’t it be self evident to any nurse who sat down and looked at it? Well, maybe but the product wasn’t designed to target first-time, uninitiated nurses who were given no instructions about how it worked. What would we learn from a test that evaluated a situation that would never actually happen?
So it was no surprise, really, when the nurses didn’t know exactly what to do. Was this bad design? Should we have included a help screen that pops up whenever a user initiates an infusion program? Maybe a talking stethoscope that taps on the glass and offers advice?
After a two-minute overview from the test facilitator that explained the basic principle behind the infusion visualization, the nurses said, “Oh, I get it” and were able to proceed with the test. But it failed that uninitiated first-time user scenario, and the client team lost some confidence in the design because of it.
I also remember a project I worked on for IT storage administrators. We learned that for their current product, the installation process the storage admins had to go through was laborious and a source of many complaints and technical support calls (and costs). When talking about usability and how he measured a good user experience, the company’s CTO told us a story about how his mother, a relative computer novice, often asked him to help her with her PC software. “Our product’s installation program should be easy enough for my mother to sit down in front of a computer and complete the installation.” I wanted to ask him what company’s storage network his mother managed, but decided to keep that to myself.
Remember: a person is a first-time user exactly once (and in the case of the infusion pump, because of training and observation, nurses were actually never really first-time users), and in many cases a beginner for only a very short while. The first-time user scenario is always important to get right (as is that highly emotional first impression); for some products such as an airport check-in kiosk or a public emergency defibrillator, for example, it’s the most critical one and deserves the most elegant solution. But for countless other products that target people who will use the product to accomplish complex workflows over long periods of time, the first-time use case is likely only one of many secondary scenarios that deserve attention.