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.

"Can You Say That in English? Explaining UX Research to Clients" in A List Apart Magazine

The new business meeting was going swimmingly—that is, until the client started asking questions about our design process. Then we unleashed our lexicon of specialized user experience (UX) research terminology.

Why should we do that thing you called...what was it, task analysis? We’d like some of those personas. They’re important, right? What the heck is contextual inquiry?!

As mental models flew about the room, I realized how hard it is for clients to understand the true value of UX research. As much as I’d like to tell my clients to go read The Elements of User Experience and call me back when they’re done, that won’t cut it in a professional services environment. The whole team needs a common language and a philosophy that’s easy to grok.

I created a cheat sheet to help you pitch UX research using plain, client-friendly language that focuses on the business value of each exercise. But, before we get to the cheat sheet, let’s talk about how we can communicate the value of UX research at a much higher level.

Continue reading at AListApart.com

Use Cases, Not Useless Cases

What's the use of use cases? Oh, I can think of a few.

Say that you're creating a website for a client that sells pony dolls made from corn plastic. On the site, there are games for kids to play, and if the kids log in, they'll be able to save their high scores, post messages regarding their favorite dolls, create a public user profile, and other features that have yet to be dreamed up by your team. You've been tasked with designing the screens required for registering users for accounts on the site.

Sounds pretty simple, right? This is where designers usually can't restrain themselves from diving right into sketching and ideation and Photoshop and luxurious comps. Next thing you know, the client approves the designs, the project moves into development—and lo and behold, there are a few corner cases you hadn't acknowledged. A few whiteboard sessions later, a long discussion or two with the client, and those corner cases are starting to loom large over the entire design that is now been un-approved and is in the midst of rapid redo.

Even worse, the client is on the hook for making some major changes to their company's business process because those details weren't thought through in the design phase and implemented in a usable fashion.

Oops. Looks like you should have run some use cases, and right from the start.

Critical information always lies buried within the details of use cases. If that information isn't triaged and surfaced properly to the client and your developer, you can totally bollix a big project.

Redesigning Wikipedia

This weekend, I found myself—through the execution of what seemed like an easy challenge for my book—thrust into redesigning a Wikipedia page. In the process, I was dumbfounded by how many usability and visual consistency issues there are in the Wikipedia interface.

We spend a ton of time querying the Internet for details about everything from where President Obama was born to who directed the third episode of the fourth season of Buffy the Vampire Slayer. And more often than not, we're interested in the facts we're uncovering, not how the facts are presented to us. This is a shame, because there are major improvements that can be made by designers to how we present factual content that's meant to be consumed through the Internet.

Other sites, such as Usability Post, have done a thorough job of documenting a number of the major issues with the old interface, so I spent an hour correcting some of them in a visually pleasing fashion to show how, with a minimum of effort, a coalition of designers could rethink some of the key interactions on Wikipedia.

Totally Loaded: How to Keep Your Users Waiting

Wait a minute. I mean, 20 seconds at least. Hold on... idea's almost here. Meanwhile, would you focus on the spinning circle I've included above and think happy thoughts?

OK, stop! Blog post loaded.

While we may think that the age of AJAX and the Flash/Silverlight preloader has ushered in a new era of more immersive and reactive user experiences, we still have light years to travel in how we manage expectations around wait times when content loads in a web browser.

And this post is a quick attempt to summarize some ways of thinking about wait times in the ideal user experience—and documenting those wait times in advance of development.

Every Word Counts

On the restaurant's Web site: penne pasta, seared oyster mushrooms, greens, basil, reggiano.

At the actual restaurant: penne pasta, winter greens, alfredo.

Not much difference, right?

Except that I was totally starving. I'd walked ten minutes out of my way in the bitter cold, just because this walk-up's food was totally killer. And they didn't say on their Web site the magic word: "alfredo."

I'm not a totally persnickety eater. I have no problem with a little cream on my noodles. They may have run out of ingredients and made a substitution in a pinch.

But what I thought I was eating for lunch wasn't exactly what I'd expected. I'd had in mind an olive oil-based sauce with shaved cheese on top... or maybe with a hint of tomato snuck into the pot while they were making a reduction.. and so on..

You've had this feeling too. This is exactly what happens when your copy on your Web site isn't precise.

Quick and Dirty Usability Testing

His eyes were dancing over the functional prototype on a 17" monitor. Tiny furrows were raising up on his brow. He was biting his lip so hard, he almost drew blood. Safely behind the glass, protected from the fury of his white-hot gaze, we could practically feel the heat emanating from his sandy brown hair.

Clearly, the interface wasn't faring so well.