Tuesday, December 9, 2014

Criticism is a form of optimism. Only silence is pessimistic. (Carlos Fuentes)

I once heard one of my colleagues describe herself as a “professional scab-picker.” And that, sometimes, is a pretty apt description of what we do. Or at least a good representation of how some people view us, if nothing else.

Now, I like to think that that last group probably just didn’t work with a more seasoned usability engineer. Let me tell you, letting someone know their baby is ugly takes some real skills. Not only do you have to report some positive results as well, you have to be convincing with your arguments, offer some possible solutions, have enough emotional intelligence to know how your report will be received, and just let some things slide.

Actually, sometimes this has more to do with the team receiving the criticism than the one giving it. In particular, I’ve noticed that it’s the more seasoned, experienced teams who can’t wait to get something into the lab, come what may. It’s the ones newer to usability that might have a tougher time – whose skin is a little thinner, who tend to be a little more defensive. Ironically, it’s also typically the less experienced team that has more to fix, and the more experienced one much less. Ah well.

Now, I have been in some situations where I have, effectively, been “silent.” These typically arise when there is such a mismatch between a team’s capabilities and any form of usability that it simply just isn’t worth it. Are you surprised that there are actually places in this day and age where this might happen?

Well, it’s true. I just so happened to work on one just a little while ago. It was basically an internal team, developing an internal tool, for an internal client. Everyone was very heavy IT, and the atmosphere actually gave me a very heady feel of the 1990s. They had heard of me somehow or other, and I made some pretty basic suggestions as delicately as I could over the phone on our first contact, explaining everything in detail as I went. I repeated that approach again in another phone call, then a conference call, and then another …

At that time, it became pretty obvious that no one was going to actually act on any of those suggestions, so I eventually retired from the field. No reason dying on my sword for this one.


Carlos Fuentes, Mexican novelist. I’m pretty sure he never uttered the word “usability” in his life, but any author who says the first thing he thinks about when he begins is a book is “Who am I writing for?” might actually not have a hard time understanding user-centered design.

Wednesday, November 12, 2014

It is easy to prove something is not usable with small sample sizes. It is hard to show that something is usable with small sample sizes. (Jim Lewis)

Boy, do I get this one a lot these days. Interestingly, though, I never got it at the beginning of my career, when I worked mostly with techies. Nowadays, though, the web seems to have been pretty much taken over by marketeers – and, boy, does this resonate with them.

And that’s because the typical marketeer is very data-driven. Web analytics, VOC (voice of the customer), CSAT (customer satisfaction surveys), NPS (net promoter score), KPIs (key performance indicators) … Throw about a dozen brightly-colored graphs and charts on a screen and lots and lots of numbers, then call it a “dashboard,” and these people are in heaven.

Now, a usability report does not look a lot like a dashboard. So, there’s typically a couple of points I like to make with this group.

First, this is qualitative research. They’re usually familiar with focus groups, so if you can make this connection, you’re already halfway there.

Second, like all good qualitative research, usability testing gets at the “why” of the issue. Yes, it’s nice to know that A/B testing showed a definite preference for B, but wouldn’t it be nice to know why that is? Maybe we can use a similar strategy for our next design. Could work.

Third, this kind of research is not about preferences. What it is is about bugs. Now, these are not the broken links, infinite loops, etc. marketeers may associate with QA. To the user, though, they might as well be. These are the obvious things – the mislabeled buttons, the hidden links, the missing help – that trip lots of people up. In fact, at this point, I usually bring up the old story of the bunched-up carpet in the hallway, and ask the marketeers how many people they would need to see trip over it before they would fix it.

Finally, this kind of research goes before launch. Marketeers really can’t say that about their nice, shiny statistics. In fact, once you start counting, whatever it is you want to count will be out there for all the world to see. Wouldn’t it be nice to get a little feedback on what you might expect before everyone else sees it?


Jim Lewis has been doing great work at IBM since 1981! He has a PhD and is the author of Quantifying the User Experience: Practical Statistics for User Research, with Jeff Sauro.

Friday, October 24, 2014

Never take a fence down until you know why it was put up. (Robert Frost)

I’m a strong believer in the law of unintended consequences. I think it fits my basically pessimistic nature. 

So, while the marketeers and execs and genius designers are all ready to – oh, I don’t know – turn every word into an icon or have all navigation be done by gestures, I’m usually the one who has to rein things in. Honestly, sometimes I feel like the ballast that keeps the balloon from wandering off into the troposphere. Unfortunately, all of that gives me a reputation for being rather conservative, which I do not relish. 

Now, this is not just a matter of my saying “no” to everything. What I like to do, instead, is ask these questions:
  1. Do we know already if it’s working or not working, or are we merely guessing?
  2. Do we know if the new idea will work as well? What would we be basing that on?
  3. Would you like me to help you answer that second question?

It’s that third question where I really like to position myself. Basically, I’m not shooting down their idea so much as simply getting them some feedback on it. Yes, I do have my opinions on the topic. And, yes, those opinions are typically based on spending a lot of time with real users … and seeing things work … or not work. But wouldn’t it be great if we could get this out of the realm of total conjecture and seat-of-the-pants intuition and see whether something will actually fly or not? 

My Dad, the electrical engineer, took one of Frost’s poetry classes 
while at Dartmouth (the buildings in the background). 
It was his favorite class.

Tuesday, September 23, 2014

If you can’t explain it simply, you don’t understand it well enough. (Albert Einstein)

I got my start as a tech writer. One thing I began to notice very early on – and be rather concerned about – was when I had to writes pages and pages explaining a particular feature. Was all this verbiage really necessary? Could the way that feature operates be made a little simpler?

At some point, I started going back to my developers and asking them about it. Sometimes, they ignored me. Sometimes, they took me seriously. And, sometimes, they actually tried to come up with something simpler and more elegant.

I then made the rather monumental decision of coming up with some ideas on my own and presenting them. These led to some pretty good discussions – and with some of my ideas actually getting implemented. Hmm, I said to myself, this is pretty cool!

In fact, a number of the developers I worked with started to expect something from me in the way of a solution. I guess it was just easier than coming up with something on their own. And that’s how I got started in this business.

So, I don’t know if I’m in total agreement with Einstein here. Yes, I do get his point. Sometimes, though, complex things need complex explanations. The question we have to ask ourselves, as UX professionals, is whether that complex thing needs to be quite as complex as it is. If we can make it simpler, not only will it be simpler to explain, but it will be easier for the user to understand and use. And isn’t that the real goal here?


Tuesday, September 2, 2014

The most savage controversies are about those issues for which there is no clear evidence either way. (Bertrand Russell)

Some days, it seems these are the only issues I deal with.  :^(  What’s interesting, though, is that I never seem to come up with these on my own.  

I’m pretty evidence-based. I think it’s rather hard to be a usability engineer for 25 years and not be. More than that, though, it’s just the way I operate. I like nothing more than having my biases disconfirmed. That means I actually learned something that day.

As for the people I work with? Maybe not so much. The execs, the marketeers, and even the interaction designers and information architects on my team don’t always necessarily seem to do things that same way.  

How do they work instead? I think some of them might call themselves “passionate.” Now, that’s all well and good. Sometimes, though, that “passion” can strike others as simply “loudest voice wins.”

Now, I do have to say, that these people genuinely are passionate. They’re also typically pretty darn smart, and know their stuff as well. Finally, they do respect actual evidence. They may just not have any at hand – not that that’ll stop them though.  ;^)

Now, I’m passionate, and smart, and know my stuff too. The role I typically carve out for myself, though, is all that stuff, but subbing out the “passion” and throwing “evidence” in there instead (okay, I tend to be passionate about my evidence). And it’s really amazing how well that works, how that can stop all the conjecture and debate and “savagery” in its tracks.

So, here’s how I typically do that:
  1. Interrupt with some real data that is directly applicable
  2. Interrupt with some real data that is applicable but maybe a little less directly
  3. Start counting on the team to ask me if there’s any data
  4. Have no fear of saying, “I don’t know”
  5. Offer, though, to find out for them

Bertrand Arthur William Russell, 3rd Earl Russell, OM, FRS

Monday, August 25, 2014

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.


Friday, August 8, 2014

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:

Thursday, July 24, 2014

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).

Monday, July 7, 2014

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 …


Thursday, June 26, 2014

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.

Wednesday, June 4, 2014

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.)

Wednesday, May 28, 2014

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?

Monday, May 5, 2014

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:


Friday, April 25, 2014

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.

Thursday, April 3, 2014

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

Tuesday, March 11, 2014

Even developers have feelings. (Rolf Molich)

I’ve always found it ironic that usability engineers, who are so centered on “the user,” often neglect to keep their own users in mind.  I’m not talking about the end users of some system or website, but the usability engineer’s own clients, the people who receive the reports and pay the bills.

This problem seems to be most evident in usability reports.   I’ve seen a number over the years that just aren’t very friendly.  And so has Rolf.  In fact, one of his main interests is helping usability engineers create better, more usable reports.  

So, what are Rolf and I griping about?  Now, this is by no means something that is the problem that it was years ago, and probably only applies to a small minority of usability engineers these days.  I guess I put it all down to two things…

One is that we are engineers, right?  So, it’s an engineering report then, correct?  And we all know that engineering reports are long, and boring, and have plenty of data and tables and appendices.

The second is probably simply a hangover from academia.  God knows there are an awful lot of PhDs in this field.  And we all know what journal articles are like, right (and how long, boring, and full of data and tables and appendices they are)?  

Well, as it turns out, our actual audiences cannot typically get as jazzed up about the traditional usability report as we can.  Our audiences are usually not other usability engineers or editors of academic journals.  Our audiences are typically information architects, and interaction designers, and marketers, and execs, and graphic designers, and content specialists, and – can you imagine – even developers!  

There are plenty of things we can do to make our reports more usable for our actual readers, but one thing we can do to help developers (and any person, really, who had input into the look and feel of what we are testing) is simply to be nice. Now, there are several ways to do that.  

One that I have fallen in love with over the years is to simply include some positive findings in my report.  I have heard other usability engineers balk at that, saying that we’re all adults here, that we’re not getting paid to stroke egos, etc., etc.  I find, though, that responding well to positive reinforcement is simply the way that most humans work – and that includes developers as well.

Monday, March 3, 2014

Personas are the bright lights under which designers do surgery. (Kim Goodwin)

There are three ways to design a website or piece of software.  One, you can just code it up and throw it out there.  Or, before you throw it out there, you can run it past some real users.  Or, if you really want to do this user-centered design thing, you can do some user research upfront.

That last piece, in my mind, is what really separates the men from the boys (the women from the girls, the adults from the children – you know what I mean).  It allows you to bake in usability from the very beginning.  That said, I’m often surprised at how little it’s done.

So, what does that actually involve?  It might be as simple as interviews, or as complex as a field or diary study, or something in between, like a focus group.  It’s what you do with that data, though, that’s really crucial.

And that’s where personas come in.  Upfront research can generate a ton of information.  What the researcher’s real task becomes is how to take that fire hose of data and turn it into a nice, quick, refreshing drink.  And, for that, personas really can’t be beat.

I think we all know what personas are by now.  You take all that information you uncovered, then distill it into several user types.  What really makes the persona, though, is how we can turn each one into a real person – with a name, a picture, a place where they live, a job they go to, a family …  

Humans are social animals.  They also love a good story.  What personas do is take those two very important human characteristics and turn them to your advantage.  Instead of designing for a complete abstraction (or, worse, with no one or yourself in mind), how much easier it can be to keep the user in mind by thinking of Phyllis with her fear of technology, or Bill with his impatience, or Julie who is trying to juggle family and job and caring for her elderly parents.

Over the years, I have gotten some resistance to using personas.  It’s often a little too touchy-feely for computer science or MBA types.  What’s gratifying to see, though, is how readily personas are adapted, when given just half a chance.  It’s so nice when developers start talking about Ben or Carol or Leah.  To me, though, that’s just human nature.


Kim Goodwin has a pretty good background in personas, having worked for Alan Cooper, the creator of personas, for 12 years.  She’s also the author of Designing for the Digital Age.

Tuesday, February 4, 2014

If you don’t have the right users, you don’t have the right data. (Dana Chisnell)

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

One of the most fundamental rules of user experience on the web is that developers are rarely qualified to evaluate it. (Luke Wroblewski)

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

Thursday, January 30, 2014

Design is not about democracy; design is about quality. (Hartmut Esslinger)

Hartmut Esslinger is a German/American industrial designer who did some important work for Apple back in the ‘80s, including designing the Apple IIc.

I was hoping this quote of his was about the design-by-committee approach.  Instead, it’s really more about the “genius  designer.”  This is a design style that was made famous at Apple, by people like Hartmut, Jonathan Ive, and Jerry Manock.  It basically posits that really brilliant designers design really brilliant products.  What some people take away from this – unfortunately – is that all the user-centered design stuff is not always absolutely necessary, and might be more for the hoi polloi.

Now, I have no beef with the concept as is.  Apple has some incredible designers and has designed some incredible stuff.

Here’s what I worry about though …  What about the rest of us?  I’m afraid I haven’t worked with a lot of Hartmuts in my career.  Now, I have worked with a ton of really excellent designers.  But none of them ever seemed to want to work “without a net” in this way.  In fact, it always struck me that the better they were, the more interested they were in getting feedback, at getting their stuff into the lab.

It was the other ones that I always worried about.  They always seemed to shy away from having real users do real tasks using their designs.  Now, here’s the great irony …  Some of these guys believed quite strongly in the genius designer theory.   Go figure. 

So, if you’re in the same league as Hartmut and Jonathan and the rest of the übermenschen, go for it!  If not, though, run your stuff by some users, okay?

Oh, designing by committee?  I see it all the time.  It’s a really bad idea.

Herr Hartmut himself