Design, Disruption, and Drunk Usability Testing

I held the drunk man's hand like a dance partner at a debutante ball, sashaying our way towards the front door of the Collins Pub.

We had both been at the Seattle Matsuri, a two-hour "all you can taste" exhibition of sakes that would be hitting the American market soon. At the event, most of us directed the delicious sakes from each brewer's bottle from our mouths into the handily-provided metal spittoons, thereby avoiding imbibing dozens of ounces of these potent wines and the fallout possible therein.

Then there were fellows like this man—whom we shall call Jeff, to protect his identity—who chose to swallow from each glass a bit too liberally. Upon running into him on the street after the event, he seemed quite lucid. But as our party sat down at the pub, desperate for a late dinner of burgers, fish, and chips to counter the onslaught of wine, you could see the power light draining right out of his eyes, his speech slurring from complete sentences to fragments. When he announced that he needed to get outside to wake up a bit, his attempt to stand up caused him to flip another table and fall to the ground in a mixture of both bewilderment and humiliation.

Sitting outside with Jeff for a little fresh air, we chatted haltingly about where he lived and what he did for a living, all the while demurring the advances of the usual Pioneer Square drug dealers offering cut-rate deals on stimulants and muscle relaxants. (Seriously, does this guy look like he needs a muscle relaxant?) But our real adventure began when he said the following: "Let's call my wife. She can pick me up."

First, we had to find the phone.

He told me to look in his leather jacket, which was located on his chair back in the pub. Riffling through the pockets, I found a wallet, business cards, tiny carabiner, a set of house keys attached to a bottle opener, a pen, and a few used tissues, but a phone was not to be found. He then patted his own pants realizing that the phone had been in his right front pocket all along.

The phone was an old school flip phone with a directional pad, probably about four years old. He opened the phone, held it up so the line of sight was even with his face, and began to click through a field of nine icons with the directional pad. I felt like I was observing a usability test. We're not testing you. We're testing the interface. Start the stopwatch, so we can gauge the time on task.

Well, the clock was ticking, and after a good minute of clicking on the D-pad, continuously moving through the various icons, Jeff had yet to locate the address book. With a shrug, he handed the phone to me and asked for me to try and find the phone number.

Within a few seconds, I had identified the proper icon—whose descriptor was completely divorced from the icon at the top of the screen—and pressed the center button on the pad to bring up the list of phone numbers. Thankfully, he had placed the letters "aa" before his wife's name and their home, forcing them to the top of the list. Clicking on the number with the D-pad brought up edit options for the listing, and hitting back went back to the list. At that moment, task failed by usability professional was running through my mind. Oh wait, I had one of these eons ago... perhaps I should hit the green button lacking a phone icon on the keypad, and that will engage a call...

Success! Wife is now driving down from Edmonds, and Jeff can now sit at the table with the rest of us and begin to sober up.

*

Since that night, I've been thinking about our sundry responsibilities as designers in the face of disruption, and I can summarize it thusly over the next few hundred words or so:

We make too many assumptions about the optimum state of use for the products we design, and by extension the critical content that they provide to us. We should catalogue these assumptions, and be aware of how they influence the end product we deliver to our clients. These clients may not be aware of the effect our products have on their customers until they have been proven out in a wide range of deathly and often surreal use cases—uses that were never intended by anyone involved in the product's design. This is disruption on the part of the user's faculties, and falls into the domain of accessibility.

The story that I shared earlier had an obvious moral: Interfaces intended to be used in emergencies—i.e. anything you design that you can actually say, "Okay, no one's going to die because of what I just created"—should be usable for those whose cognition is impaired. Those kinds of scenarios include use of a product after an accident, while injured, while driving (which in many place is quite illegal!), by one with a range of critical disabilities, by a visually impaired person, by a colorblind person—the list could go on forever, right down to a common impairment scenario my co-worker Matt C. suggested, which was trying to call someone while carrying a few bags of groceries upon leaving the Trader Joe's. We're always juggling the phone, the car keys, the coffee, the overloaded bags, and perhaps two kids in tow that are both screaming for mac and cheese for dinner. Designing for accessibility, in this regard, is a topic that many others have written about quite cogently, so I won't try to cram their learnings in here. Google can help you with that.

In these situations, the user often thinks they're the ones who have failed in being able to "figure out" the interface. In a few cases, they're right—but more often than not, we're at fault. Though the recent, somewhat amusing confusion between ReadWriteWeb and Facebook from typing into their search engine a common search query further dashed our assumptions that people, when they want to visit websites, type in URLs or click on saved bookmarks to reach sites they visit on a daily, nay hourly basis. Never assume that there is one "right way" to use any tool provided to a human. I'm sure there's someone out there who has tried to eat a can opener.

Then, there's the disruption we're always thinking about as designers: what happens when the system that we've been asked to design has a failure independent of the user's faculties. It's not just what's part of the UI/UX that is hard to scan or control with reduced cognitive function. It's also content that can't be accessed from remote servers quickly enough to stop new problems from occurring.

While walking through downtown Savannah a few weeks ago, I saw the servers at the Old Pink House bar gathered around the HDTV with bated breath, watching a racecar gracefully pin a turn during the final laps of a NASCAR race. The picture flashed to black, replaced by text something like the following: "Satellite signal disrupted. Please stand by." I think I could see a little tarnish on the logo of the service provider glimmering in the corner, as the servers swore and shook their fists at the screen.

Many of the products we're being asked to design—products intended to consume and render data from the cloud or an existing service provider—can't assure 100% uptime. This adds a further layer of complexity to furnishing stable, accessible web services and user interfaces. We're constantly struggling to find places the user can wait for further action, or flip to a redundant channel to consume and provide content.

This isn't good UX, depending on the service we're continually calling from, and isn't sustainable either. (First few years of Twitter, anyone?) We're creating an increasing number of failure points that we can't accommodate thoughtfully throughout the design process. The level of uptime required, especially when delivered through everyday utilities with inconsistent infrastructure, cannot be guaranteed without doubling or tripling the amount of signal we need to push out. Besides, even backup plans fail. (That's why there are two people with their two sets of keys in nuclear missile launch points, right? Wasn't there an episode of Quantum Leap about this?)

Imagine the same scenario that happened to Jeff this past week, only that he would need to access critical information from a web service. Would he have to furnish another password to gain access to data he needed right away? Then, compound that by fluctuating quality of service from his wireless provider. Can we ever assume that signal is ubiquitous? Will there ever be a day that we aren't seeking the right street-corner to get that faster Internet signal? (Yes: When we are powering our devices with our own electricity, and receiving signals through our own bodies via signals that are extant in every crevice of the Earth. Eeek.)

*

There's a resilience to organic systems that haven't been mimicked well by computer systems, yet, which I'm sure we'll eclipse in the next decade or two. We forgive disruption between people more than we do between ourselves and our supposedly subservient machines.

Jeff's wife showed up to take her drunk spouse home—looking a bit bemused, but not overly pissed. He had at least one redundant system in place, besides calling a taxi or trying to survive a 45-minute bus ride without inconveniencing everyone around him. (His dog, tail thumping in the back seat, happily greeted him as well.)

These human networks serve as our strongest support, and their services cannot be easily bought and sold. Other than talking about preloaders and architecting redundant systems, I wonder if we should be questioning each feature that we add to a website or a product, and confirming their utility compared to real live people. I was thrilled to see that Google had recently purchased Aardvark, a human-powered search engine—precisely because the amount of information in our heads, while dwarfed by the petabytes of information buried in millions of servers across the globes, is provided more intelligently (and with a dash more character) than what can be designed by any one person with Adobe CS4.

And for the immediate future, I'm more than comfortable with that.

Comments

[Julia r]

You may be interested in Three Sheets Market Research, a company that provides user experience research services focused on drunk subjects.
http://threesheetsresearch.com