There’s a reason why the usability engineer is asking you to review that incredibly long screener. It’s to make sure you get the right person in that chair in the lab at 9:00 next Tuesday.
Have you ever seen what happens when that doesn’t take place? Believe me, it isn’t pretty. A test of a CD (certificate of deposit) product on someone who thinks you’re talking about music? Maybe not such a good idea. A test of a mobile app with someone who just bought an iPhone, but hasn’t really used it yet? You might want to think about that one. A standard, think-aloud test with a participant who just isn’t comfortable thinking out loud? Perhaps we ought to reconsider.
Of course, the problems don’t have to be so blatant, and can be a lot more subtle – and can still cause lots of issues. Designing a mobile app for people in their 40s and 50s, but your participants skew more toward the 20s and 30s? Well, don’t be surprised if that tiny little button that your participants had no trouble tapping will cause some issues down the road. Or if actual customers never use that particular gesture that your test participants (and your 20-something designers) just loved. Or if the real users can’t read that link because the text is too small.
(That said, I sometimes have just the opposite experience, usually when I work with marketing. I find they’re used to demographics. So, in addition to the traditional mix of genders, ages, and so on, they typically also want to make sure we get some Midwesterners and some African-Americans females and some stay-at-home Moms in their mid-30s in a certain set of ZIP codes. The typical joke I make here is about left-handed, green-eyed, Presbyterian Capricorns. Sometimes they even laugh at it.)
Actually, I’d have to up Dana one and say that if you don’t have the right users, or the right tasks, or the right system, you won’t have the right data either. A usability test is lot like a soufflé recipe. You miss one of the ingredients, and the thing’s going to fall flat.
Dana
I’ve been doing this usability stuff for a shockingly long time. In the beginning, we had only one enemy to blame for everything – the techy. It’s who Alan Cooper was talking about when he titled his 1999 book The Inmates are Running the Asylum.
Back then, this approach made a ton of sense. Computers had originally been developed by techies for techies. I’m talking card readers, green screens, punch cards, and command-line interfaces (all of which yours truly actually has experience with – something I like to scare my younger colleagues with when we all go out to lunch).
Then along came this thing called a “PC.” All of a sudden, techies weren’t designing for techies anymore, but for secretaries and insurance salesmen and high school teachers. And these people really didn’t want to learn COBOL or Fortran to print their label or fill out their expense report or enter their class grades.
And this is where I stepped in. Well, actually, I just happened to complete graduate school at this time. But there sure were plenty of opportunities out there for people like me to help make the world a better place (with a special emphasis on the human-computer interface, of course).
Nowadays, the blame can be spread around a little. In addition to techies, we’ve also got marketeers, bean counters, art directors, senior execs, and all sorts of sundry corporate types getting between the users and what they want to do.
At the same time, though, I have to admit that there is a lot less blame to go around. Everybody, it seems, appears to get usability and user experience in a way that no one did twenty-five years ago. Even the poor developer.
With all that said, I still think The Inmates are Running the Asylum is one of the best UX books ever written. It introduced concepts like not designing for the edge case, modeling human-computer interaction on human-human interaction (what Cooper calls politeness), and using personas and scenarios. Except maybe for its tone toward developers, I’m not sure that book will ever be out of date.
Alan, not Luke
