It's really hard to design products by focus groups. A lot of times, people don't know what they want until you show it to them. (Steve Jobs)

Great point about the focus groups, Steve.  I was wondering, though, how you were able to uncover exactly what people wanted.

Focus groups, used properly, are actually one way to do that.  You might, for example, get people to talk about their experience with some task.  That’ll get at the existing systems, whether they’re working or not.  But it’ll also likely get at things that are outside the current systems.  And addressing all that can help you come up with some really innovative ideas.  In other words, ask them what their problems are (whether that’s with the systems they use currently or has absolutely nothing to do with those).  Don’t ask them for solutions.  Coming up with those is your job.

Just to make this a little concrete, I worked on a project once where my team was tasked with completely redesigning the mortgage application process.  As part of that effort, we put together some focus groups with people who had just been through that process – good, bad, indifferent, with our company, with other companies, mostly online, mostly offline …  The pain points came up quickly, easily, and in great volume.  Further, many of these were not being addressed by anyone else out there.  They typically had to do with things like communications, and paperwork, and motivation – and not necessarily with the systems these people worked with.  The solutions we came up with were rather proprietary, so I really shouldn’t share them here.  Suffice it to say, though, they were pretty darn good.  And I’m not sure we would ever have come up with them on our own.

Now, an even better way to generate ideas is through ethnography.  That’s just a fancy way to say “field study,” and all that involves is watching people complete their own tasks in their own environment.  In the session itself, you should concentrate on observing, simply capturing all the reality that happens right in front of your eyes (there’ll be plenty).  Later, you can analyze all that data ‘til the cows come home.  Once again, though, what you’ll be looking for primarily are the pain points, the gaps – along with creative ways to address them.

Does Apple do something like that?  I do know that they love their genius designer paradigm.  So, maybe they have some genius way to get at those user pain points as well.  I also know that they like to design for themselves.  And seeing that iPhones and iPads and so on are meant for pretty much everyone, they can probably get away with that.  You and I though – with our specialized audiences who we may or may not have anything in common with – may not be so lucky.  Finally, I do know that Apple is extremely secretive – heck, even paranoid.  So, we may never actually know.  Anyway, unless you’re one of those Apple geniuses yourself, I would definitely recommend some of that upfront research – whether a focus group, field study, or what have you.

A successful test is a test that uncovers many problems. (Rolf Molich)

I often get asked in the elevator or the break room or the wash room how “that test is going.” Even after all the years, I’m afraid I have to admit that I never know quite what to say.

If it’s someone on the project team, they basically want to know that everything’s hunky-dory and that I have essentially uncovered no problems [yeah, right]. If it’s another usability engineer, I might delightedly share that the system’s a piece of crap, or that my 1:00 appeared to have had a few drinks with lunch, or that that method they suggested is working well. If it’s a developer, they may simply want to know that the prototype worked.

For me, though, what I’m really looking for is consistency. What I really like is when the first three or four or five users all have trouble with widget X, or label Y, or screen Z. Even though we are dealing with pretty small numbers, that consistency makes me feel much more confident.

(Now, there are never any shortage of problems that only one or two users might uncover. What I do in that situation is take a closer look at these issues and see if the user has uncovered something valuable or if they are simply an outlier. That’s always a judgment call, though, unfortunately.)

My ability to tie a problem quickly, directly, and clearly to a specific field or interaction or missing piece of information also makes me feel good inside. Some of the hardest reports to write are those where there was obviously an issue, but what it was and what was causing it weren’t so clear. Of course, it’s always a great feeling when I’ve solved these knotty problems, but there can definitely be a fair amount of anxiety leading up to that moment.

One final thing … Yes, most of my tests do find plenty of problems.  Plenty, though, also uncover many things that work. And some even uncover plenty of good things and very few problems. And I’ve always believed that’s just as important to present as when there’s nothing but issues.

Unlike a lot of usability engineers, I do like to emphasize the positive. I just find my report recipients are a lot more open to what I have to say if it’s not all negative. So, maybe Rolf’s quote should read, “A successful test is a test that uncovers many things,” or “A successful test is a test that uncovers a lot of stuff,” or … Ah, forget it, it’s still a pretty darn good quote just as is.

 Also from Rolf:

• "God is on our side, but we can help him."
• "Help doesn't."
• "Even developers have feelings."

Perfection is achieved, not when there is nothing left to add, but when there is nothing left to take away. (Antoine de Saint-Exupery)

Have you ever heard of “additive design”? Please don’t Google it. You’ll only get 7,000 results, and probably won’t find a serviceable definition anyway. In fact, I think I might have made it up.  ;^)

Anyway, it’s a pretty simple idea – and it also appears to be the way most websites and software are developed. First, you start with something nice and clean and simple. Then, when some important business partner wants their piece of real estate, or some high-profile client complains about some piddly little thing missing, or some marketing exec wants to add their special little widget … well, you add them. You repeat this process month after month, quarter after quarter, and year after year until the page or site or whatever basically sinks under its own weight.

Then, if you’re smart, you blow it up and start all over from scratch. (If you’re not so smart, you just keep adding, and adding, and adding.) It’s the difference between Google and Yahoo. Between an iPhone and Microsoft Office.  Between Swedish Modern and High Victorian. Between Mies van der Rohe and the Winchester House. Between Hemingway and the federal tax code. Additive design can also happen on that first iteration of your system too. Are you designing by committee? How many people are on that committee? Is anyone thinking of the user's holistic experience, or are they thinking of their own little fiefdoms and pet projects?

And, if they are thinking of the user, how are they doing that exactly? Are they doing that in the abstract only? Are they using themselves as stand-ins? Are they trying to be all things to all people? One thing I can definitely tell you for sure is that no user wants complexity. One thing I’ve noticed over the years is that managing the impulse against additive design is easier for some members of the project team than for others. Graphic designers consider it a no-brainer. Content folks can often be talked into it (though I swear some of them are paid by the word). Techies and business/marketing types, however, sometimes seem not to get it at all.

Now, there are several things you can do to avoid an additive style. One is to try to get the whole team to buy into the overall, integrated, holistic user experience – instead of their own little silos. Strong direction from the top down can help a lot here. Personally, I’ve had a lot of luck with personas, the old 90/10 rule, and progressive disclosure. Ultimately, though, the most effective strategy may simply to be aware of the phenomenon of additive design itself – how nefarious it can be and how many problems it can cause.

M. de Saint-Exupery, an extremely unflattering photo. 

Yes, he’s the one who wrote The Little Prince. 

Et, oui, c’est un chapeau d’aviateurs. Il etait un
(un avaiteur, pas un chapeau).

When fixing problems, always do the least you can do. (Steve Krug)

Geez, Steve.  Is this a call for me to surf the Internet instead of analyze those tapes?  Get a bagel instead of add up all my numbers?  Go home early even though I have a report-out first thing tomorrow?

Actually, I think Steve might really be onto something here.  If you’re like most usability engineers, you probably want to change the world.  Further, you’re more than likely to find every result from your test to be absolutely fascinating.  Finally, you’re also typically very good at seeing the big picture – at not just settling for the easy fix but trying to solve the underlining problem. 

Now, all that’s a good recipe for your basic usability engineer.  It might, however, also be a good recipe for creating an ineffective report – a report that includes way too much and tries too hard to fix way too many things. 

Here’s the thing …  It’s not just enough to run a test and write a report.  Our jobs really aren’t done until the problems that our tests uncover and our reports communicate are fixed.  But doing that is not something we can do on our own.  It’s usually somebody else who is doing that fixing. 

And those somebodies are human beings just like we are.  They may have other things they’d prefer to do, they may not totally agree with our suggestions, they may be super busy, they may not have the passion we have, they may be feeling a little lazy that day.  So, if we want to actually have our suggestion acted upon, why not make it a little easier for the person who is actually making the fix?  Yes, it would be nice to cure cancer and bring about world peace by totally redesigning the website from scratch, but if simply adding an FAQ to a page that’s six levels deep actually solves the problem we’ve uncovered, well, go for it! 

And that’s not even broaching the topic of how many new usability issues you may have introduced in your new, revolutionary, broad-ranging solution.  But that’s a topic for another post …

Steve “Don’t Make Me Think” Krug

Steve also said:

• "Instructions must die."
• "People often test to decide which color drapes are best, only to learn that they forgot to put windows in the room."
• "Happy talk must die."
• "The point of testing is not to prove or disprove something. It’s to inform your judgement."
• "It doesn’t matter how many times I have to click, as long as each click is a mindless, unambiguous choice."

The only secure password is the one you can’t remember. (Troy Hunt)

I have long had an intense love/hate relationship with security folks.  Originally, they were the trolls who somehow or other got in the way on every log in or sign up sequence I ever worked on.  Kind of like Dilbert’s famous Mordac character:

(The “squeal like a pig” quote here is what really makes this one.)

A few years ago, I ended up seated next to my company’s security group.  Turns out that they were regular people after all, and we ended up having a great relationship.  I walked away with a lot of knowledge about and an appreciation for security issues, and they learned a thing or two about usability.

One of the first reports I did for them included the following graph, pretty much as a joke:

Get it?  As security goes up, usability goes down.  As well as all the other corollaries this graph implies.

As it turned out, this graph turned out to be a pretty effective way to think about each new wrinkle the security folks wanted to introduce.  What we were trying to hit was that point where the two lines intersect – the happy medium between security and usability.  We actually started to think of it more like this:

What we tried to do here was come up with something that got us in that top right box.  And if we didn’t, we had to think hard about what was preventing us from getting there, how to get there, and whether that particular solution would ever get us there or should simply be scrapped.  We also had to assiduously avoid the lower left hand box and, if we ended up in the other two boxes, think long and hard about whether we were really comfortable there.

It also got us both thinking outside of our own little boxes.  Personally, I now look forward to security work.  Instead of making me simply throw up my hands and run away, security just seems to add a little extra challenge that can be a lot of fun.

Nothing I say this day will teach me anything. So if I’m going to learn, I must do it by listening. (Larry King)

Having worked on staff (at very large corporations) for most of my career, I have had to complete my fair share of performance appraisals.  One of the things you typically get measured on is communications skills.  And a big part of that is simply the ability to listen.  As a usability engineer, I’ve never had any hesitation in giving myself a 5 out of 5.  In fact, if you’re a usability engineer and you can’t do the same, you really might want to dust off the old resume and start thinking about a different career.

So, what makes somebody a good listener?  I actually think a lot of it is innate.  If you just naturally have empathy for your fellow human being, you’re half the way there.  

At the same time, though, it is possible to be too empathetic.  When a user struggles, if your first reaction is to jump in and fix their problem, you may be helping them, but you often do so at the expense of other users.  The way I look at it is, I can fix this person’s problem, but by so doing I may not get the data I need.  And it’s that data, in turn, that will help me fix the problem for this person and for a whole lot of other people.

It ain’t easy, though – let me tell ya.  It just goes against the grain of the average empathetic person.  And that’s why I recommend a lot of practice.  In fact, if you’re a new usability engineer, there’s no substitute for having someone more experienced watch and critique you.  It doesn’t happen a lot and it’s not an easy thing to do, but it can be very valuable.

Another thing that can help in this situation is innate also, and that’s simply being an introvert.  For the average person, it’s not easy sitting behind somebody, taking notes, and saying nothing more than, “What are you thinking?”  We mousy people have a much easier time doing that.

All in all, it’s a very odd combination of empathy and distance.  But it is something that good therapists, talk show hosts, and usability engineers do as second nature.  And when it comes down to it, it’s really just sitting back and letting the other person do the talking for a change.

Larry King, ancient talk show host, serial husband, and great listener

(Yes, that is his wife.  No, I’m not kidding.  Yes, it’s his seventh.  Yup, she is 33 younger than him.  And, yes, she is a Mormon.)

The only truly intuitive interface is the nipple. (Jay Vollmer)

You know, I think he’s right. What other device could you put in front of a day-old infant and have a 100% task completion rate? An iPhone? I don’t think so.  

Heck, we were born that way, weren’t we? If you think about it, pretty much everything else has to be learned. And I’m not talking about iPads and Photoshop here. What I’m talking about are spoons, and crayons, and stairs, and shoe laces.

One thing that can help learning is simplicity. One of my favorite slides in any presentation I do on usability basics is a comparison of the Google homepage with the train wreck that the Yahoo homepage eventually became. Searching the Web should not be rocket science.  Rocket science should be rocket science. Everything else needs to be a heck of a lot simpler.

Another crucial factor is consistency. Know why? Inconsistency basically just makes things more complex. Say you’re designing an ecommerce checkout process. Why would you change where the next button appears from one page to another? Why would you say “next” on one page and “continue” on another? All of these things make users stop and think about what’s different, why it’s different, and why exactly you’re making them waste time figuring those things out.

A final thing to consider is modeling your new interface or interaction on something the user already knows and is familiar with. In the early days, this meant using something from the real, physical world. Designing an email system? Just use the fields from a typical, real-world memo – from, to, subject, cc. (Anyone know what “cc” stands for?  Answer below.) Heck, just looking at the tool bar on the software I’m using to write this, I find folders, floppy disks, a paintbrush, and scissors (for cut and paste). These kinds of models were a big part of Don Norman’s early and ground-breaking book The Psychology of Everyday Things.  

These days though, with more people familiar with the virtual world than the real one, modeling your system on such quaint things as desks, offices, book stores, and newspaper classifieds might not always work.  And that’s where standards come in.  

In the early days of the Web, there actually weren’t a lot of standards. Now, however, you break standards at your own risk. The user has already learned how to do certain basic things on plenty of other sites. Doing things differently on your site simply makes your UI inconsistent, which makes it more complex, which makes it less usable. (Yes, that does make you stand out, Mr. Art Director … but not really in a good way.) And, yes, the same thing is taking place for mobile as well.

No, none of us are designing the next nipple (though I have to admit, Google has come close). But there are some things we can do to make our systems and websites approach that simple ideal.

Don Norman (you weren’t expecting a nipple, were you?)

“cc” stands for “carbon copy.”  Before photocopy machines, people made multiple copies of documents by using “carbon paper.”  According to Wikipedia:

“A sheet of carbon paper is placed between two sheets of paper and the pressure applied by the writing implement (pen, pencil, typewriter or impact printer) to the top sheet causes pigment from the carbon paper to make a similar mark on the copy. More than one copy can be made by stacking several sheets with carbon paper between each pair. Four or five copies is a practical limit. The top sheet is the original and each of the additional sheets is called a carbon copy, from the use of the carbon paper.”

Scary stuff, huh?