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?

Not everything that counts can be counted, and not everything that can be counted counts. (Albert Einstein)

I once put this quote on a report I put together for a client who was really into counting.  It may not have been the best idea, but it did get their attention.  And several years later, it looks like they may actually have found a place at their table for qualitative research.

I use a couple of arguments when I have to stand up for the legitimacy of qualitative research with more numeric types (those who are really into surveys or analytics, for example). First, I simply point out that we’re both simply creating some sort of feedback loop. The one real advantage of usability testing is that we can get that feedback before something launches.

At this point, I often have to make a distinction between usability testing and QA. What I typically stress here is that usability testing can happen at any point in the cycle (from pieces of paper to production systems) and that it has a much broader focus (not just, “is it broken?”).

Next, I usually point to qualitative work that they may be familiar with. If they’re marketing types, that usually means focus groups. (Though usability engineers may have trouble with these, marketeers typically do appreciate this method.)

I then make the point that there is often a real trade-off between numbers and richness of data. Methods that emphasize the former (web analytics, say) tend to give you a real good feel for what’s happening, but often don’t tell you why it’s happening.

Finally, I like to point to the famous graph that Jakob Nielsen (with help from Bob Virzi) came up with:

I also typically mention – in an offhand way – that this is a perfect example of an asymptotic curve (and ask them where they think the asymptote would be). It’s usually at this point, when they’re so bowled over with my brilliance, that I can get them to agree to anything. (That’s a joke, by the way.)


Einstein also said:

• "Make everything as simple as possible, but not simpler."
• "If you can’t explain it simply, you don’t understand it well enough."
• "If I had one hour to solve a problem, I’d spend 55 minutes thinking about the problem and five minutes thinking about the solution."

The measure of success is not whether you have a tough problem to deal with, but whether it is the same problem as last year. (John Foster Dulles)

Steve Krug and Caroline Jarrett put on an excellent session at UPA 2012 called “’...but the light bulb has to want to change’: Why do the most serious usability problems we uncover often go unfixed?”  

To me, this has always been the proverbial elephant in the room.  Everyone knows usability engineers do great work.  How often, though, is their work actually acted upon?  How often do things fall through the cracks?  How often do project teams pay only lip service to usability?

In a previous life, I once had a little time on my hands … and decided to find out.  I went through a year’s worth of usability reports, then tallied up what percentage of issues our different clients actually fixed.  As it turns out, the client that we seemed to be on the best standing with (they wanted our services constantly, observed sessions religiously, and seemed to “get” usability) fixed the fewest issues.  And a client who we had wrestled with on what seemed like everything actually fixed the most!  I’m really not sure what was behind all this, but it certainly was an eye-opener.

Steve and Caroline (in a survey that they ran on over a hundred usability engineers) found that the major culprits were capacity and politics.  Other issues included changes to business processes, technology, holding the fix for a future redesign, and legal.  Some ideas for mitigating these issues include:

• Prioritizing (for example, putting easy fixes that have major impacts at the top of the list)
• Making testing more collaborative (getting team members to observe, debriefing with the team, etc.)
• Speaking the language of business and focusing on their priorities
• Focusing on the big problems (i.e., avoiding the temptation to list anything and everything in your  report)
• Doing the least you can to fix the problem (e.g., not redoing the whole system when adding a help link will suffice)
• Equating usability bugs with any other kind of bug
• Putting fixing usability bugs in the schedule
• Celebrating fixes

I like these ideas.  Heck, anything that would get around reporting the same issue over and over again would be a winner with me.

John Foster Dulles was not a usability engineer, but was Secretary of State during the Eisenhower administration.  Dulles Airport, in DC, is named after him.  As afar as I know, there are no airports named after famous usability engineers.

Usability is about making technology work for you, instead of you having to work to use the technology. (Laura Downey)

There’s a certain kind of person who loves a challenge. That beautiful kitchen island with the marble countertop? They built that. That underground sprinkler system? They put that in. That home network? They set that up.

Then there’s the rest of us. We just want the stinking printer to work … so we can get our report … and go home.

Now, here’s the rub … As usability engineers, we tend to work with the first type of person. But we usually advocate for the second. When we’re in the lab, we work with the latter, but then typically have to explain what happened to the former.

It can be quite a challenge operating as translator. Luckily, most of us are used to drawing on both sides of our brain. In fact, that’s why a lot of usability engineers come from fields like technical writing or instructional design, in my opinion.   

At the same time, though, we are engineers. And there are some of us who take that part of the title very seriously. They might be stat heads who are interested in ANOVAs, Bayesian inference, and stochastic processes. Or they might just be closet developers.  

The latter are the ones I worry about. For those folks, understanding and working with users can sometimes seem to take a backseat to making the eye tracker run or tweaking the prototype or coming up with some homegrown tool for this or that. I know there are true Renaissance people out there (and I know I ain’t one of them), but I sometimes wonder if usability engineers like this haven’t gone over to the other side.

Mary Beth Rettger, Directory of Usability at The Mathworks and former UPA president, has called herself a “luddite.” I don’t know if I want to go that far. I do, however, like to keep myself somewhat “pure.”  

The only time I’m around non-techies these days seems to be when I’m in the lab with my users. Being able to channel them outside the lab is a lot easier if I feel I genuinely have something in common with them. So, I guess that’s why I’ll always be more on the “usability” – and less on the “engineer” – side of “usability engineer.”

Not Mary Beth Rettger