Usability Week 2004, Day 3

More of same. More graphs. More statistics. More information of no value in my day-to-day work. And more doodles.

Day Three, actual doodle

Actually, I did glean a bit of actual interesting information today, but it was barely mentioned in passing so I pretty much latched onto it by accident. Somewhere in the middle of the presentation on usability field studies, there was a brief discussion of the book The Inmates are Running the Asylum by Alan Cooper. The book is about some of the deeply embedded usability issues that continue to make high-tech devices non-user-friendly, or even user-hostile. I haven’t read the book, but I may just have to pick it up. There was mention in the presentation that Cooper pioneered the notion of “user personas,” a fictional user with a set of common traits.

The idea is that designers and developers can bear these made up personas in mind during the design process to help them gear their products toward the way real people will use them. Making up a fictional character something I had ever really thought of, but it seems like an excellent mental exercise to keep developers focused on the end user.


So let’s make up an archetypical user. We’ll name her Lucy. Lucy is in her mid-40s, college educated, and fairly web-savvy since she’s been using the Internet on a daily basis for several years. She knows how to get around a website, knows how to send and receive email, and has seen enough websites to understand the common devices like shopping carts and contact forms. But she’s not a programmer and doesn’t know how sites work on the back end. She doesn’t know anything about how the data is stored or transmitted, or how the site is actually built. She’s heard terms like “HTML” and “JavaScript” and “JPEG” but doesn’t really know what they mean. And last but not least, Lucy is smack dab in the middle of our target market.

So let’s say we’re building a basic order page, and for security and privacy reasons we require our customers to create a user account before they can proceed with their purchase, complete with a unique username and password. If they enter a username which is already in use on another account, we need to display an error message explaining the situation and asking the user to select a different username. Now a really techie programmer type person who knows all the ins and outs of complex data systems, and who is more concerned with getting the site functional than he is with making it usable, might write a cryptic error message like this:

Error: Username exists in database

How do you think Lucy would react to this message? She’d probably be stumped. What database? If the username exists, does that mean she successfully created an account? If so, why does it say “Error” and why can’t she just keep going with her purchase? She knows what a username is because she has them on a dozen other sites, so what’s the deal? Lucy, as smart as she is, probably would not know what to do next. And since Lucy is smart, she doesn’t like being made to feel dumb and will quickly lose patience and leave the site, never to return. Poof, we just lost a customer.

So let’s teach our brilliant programmer guy all about this charming and intelligent lady named Lucy. Let him get to know her as a typical user of the system he is building. At every step, he should pause and think “How would Lucy handle this?” With that consideration in mind, he’d probably write a much clearer and more helpful error message like:

The username you entered is already in use by someone else on this site. Please choose a different one.

Now that is an error message Lucy can work with. Plain English, complete sentences, no techspeak, and clear instructions for what to do next to recover from the error. The typical person with a fair amount of online experience would understand exactly what’s happening, and would know just what to do to proceed.

But maybe we’re also targeting novice users who are just getting online for the very first time, so even that simple error message may be too confusing. We need another archetypical user persona (we’ll call him Mel) who has no idea what a “username” is. He might need even more help, preferably in the form of clear instructions before he enters his desired username, rather than the site sending him in blind and waiting for him to make a mistake. If we’re targeting Mel, we should probably add a supporting note near the username field saying something like:

Your username is what you will use to identify yourself when you use this website. Your username should be unique, and must be at least 8 letters long with no spaces or punctuation.

That gives Mel a good head start, and he’ll be less likely to get annoyed and frustrated when he tries a non-unique username and encounters our polite error message.

In the earliest stages of any web project, you should have spent some time deciding who your target audience is going to be. Based on what you know of your audience, their experience level, their traits, and their expectations (and based on behaviors you may have observed in usability studies), you can cobble together a few archetypical user personas, and then keep those imaginary friends close at heart while you’re building the site.

So lookie there, I learned something from this seminar after all. The first three days were the “Uasability in Practice” series, which is a complete misnomer since it wasn’t really about usability in practice, but was really all about how one should go about conducting usability testing. Tomorrow is Web Usability 2004, which will hopefully present a lot more practical knowledge.