Monday, August 13, 2018

It is difficult to see the picture when you are inside the frame. (Wendell Castle)

It’s really hard to believe I’m fighting this battle again. 

One of the principles of Design Thinking, though, seems to involve designers testing their own stuff. They are encouraged to do this in full-on guerilla mode – grabbing people in coffee shops and thrusting screen shots in front of them.

Now, I will admit that their heart is at least in the right place. They are getting some feedback. It's also good for the designers to interact with their actual users. And, finally, I’m all for informal methods.

This is not, however, usability testing. First, testing cannot be done just by anyone. There are some real skills involved, skills that need to be seen, learned, practiced, and critiqued. It is very easy to bias your user, to ask the wrong questions, to intervene at the wrong point, to generally muck things up. Heck, I’ve seen my share of “professional” usability engineers who couldn’t get it right.

I’m also a firm believer that it takes a certain kind of personality as well. I’ve mentored a lot of folks over the years who have expressed an interest in becoming a usability engineer. Some people were total naturals. Others (often because they were too extroverted, or impatient, or unfocused) struggled and struggled.

Second, humans are simply not very good at objectivity. There are dozens of proven cognitive biases that show this – the IKEA effect, confirmation bias, the backfire effect, belief persistence, denial … And based on the resistance I sometimes get from mere observers, I can’t imagine that having those folks leading the tests instead of me could possibly do anything other than make things worse. 

One of the stories I like to tell in this regard involves a favorite designer of mine who was asked to play the “computer” (i.e., shuffle the papers) in a test of a paper prototype. His body language was comical. At one point, he actually spun around in his chair when the user, who had been struggling mightily with a task, finally got it right. A brilliant designer who has since gone on to a very successful career, I might add. I wouldn’t ask him to test his own stuff though. Heck, it would probably never occur to him to do so anyway. 

Tell you what … Give the usability engineers the tests and we’ll let you guys do some of the upfront research. It’s a lot harder to muck that up, plus it can really help you get to know and build empathy with your user. Just stay away from your designs though. And don’t be afraid to ask us for advice.


I have to give this guy credit, as Wendell Castle was actually a designer himself (and of art furniture, no less)

Tuesday, August 7, 2018

No one ever listened himself out of a job. (Calvin Coolidge)

Boy, people sure do love to talk. For a usability engineer, though, that’s a great thing. If they didn’t do that, the think-aloud method would have never seen the light of day, and I’d have probably had a career doing something else entirely.

I probably don’t need to tell you all that however. In the lab, listening is our main duty. Not only do we need to listen though. We also need to listen in the right way. 

You’ve probably heard of active listening before. It’s really just a set of behaviors we can use to make sure that listening isn’t just simply a matter of waiting for our turn to speak. It includes things like demonstrating attention, monitoring body language, paraphrasing, asking open-ended questions, probing, and watching for emotional impact. And that’s a great start. 

Some other things we can do include simply shutting up. (I’ve often said the best tests are the ones where I don’t say “boo.”) And when we do intervene, we need to be brief and completely unbiased. Our real job is simply to keep the user talking. Three particularly valuable tricks (which I learned from Judy Ramey, at the University of Washington) include:

  • Simple saying “uh-huh”
  • Echoing what the user just said (“You like that feature …”)
  • Repeating the user’s incomplete verbalization (“You think that …”

What usability engineers sometimes forget, unfortunately, is that they can apply those same skills outside the lab as well. And, when I say that, I’m not just referring to on-site testing or field studies either.

We can definitely use those same skills when we interact with the people we work for and with. An obvious spot to do so would be a stakeholder interview. It can also, though, come in handy in meetings, phone conversations, hallway drive-bys, and in pretty much any interaction we might have.

In fact, at this point in my career, I’ve become so good at it that I have colleagues jokingly accuse me of pulling “jedi mind tricks” on them. And, who knows? Maybe they’re right.




Our 30th president was after all
also known as “Silent Cal”

Tuesday, July 24, 2018

Creating a good UX is not a design problem, it’s a power struggle. (Alan Cooper)

I like to joke that I work in a sausage factory. Now, the various companies I’ve worked for over the years have produced some mighty tasty sausages. Our customers would be shocked, though, to know what actually goes on behind the scenes in the creation of their particularly delicious software, website, or app. 

It’s really not too surprising if you think about it though. First, there are usually way too many chefs in the kitchen – the client, upper management, the design team, IT, legal, usability … And everyone has their own opinion – if not axe to grind.

Further, there’s typically no set recipe. Oh sure, everyone tries to formalize the process somehow. But what all that usually devolves into at some point is a good, old-fashioned knockdown, drag-out fight. 

And I think that’s just human nature. We all pay lip service to collaboration, but there are always going to be dominant types who fight for their way as they climb up the corporate ladder. Ever been exposed to the DISC personality typology? It’s the only one I know that actually is quite honest about all this –  with D meaning dominant, S submissive, and C compliant (I is for influencers, by the way – sort of dominant types who are also pretty nice). Other folks may simply have fallen in love with their own design, want to get their own two cents in, have poor impulse control, or just possess an overly sized ego. 

I have noticed, though, that some companies are a little better at managing this than others. A lot of them, for example, have solved the problem by simply being very hierarchical. Of course, unless you’re the U.S. Army, this really isn’t the optimal solution. (To tell you the truth, though, I actually prefer this structure to the Darwinian free-for-all.) And I’ve also worked at some companies where people were actually pleasant to each other, weighed the evidence, and tried to make the right decision. Shocking, I know.

Well, one thing a usability engineer always has going for them is the evidence. I find that can have a lot of weight, even in the middle of those knockdown, drag-out fights. And as for those types who aren’t interested in evidence and live in a alternative fact-free universe? Well, those are fights I don’t care to even get involved in.



Though it’s definitely not just Microsoft
(Thanks to Manu Cornet for this)

Wednesday, May 30, 2018

It got so easy it got hard. (Gayle Wellborn)

Gayle Wellborn was simply a former exec I worked with at one time. Unlike a lot of execs, though, she seemed to really get usability. For some reason, it was just very easy for her to identify with the user. I’ve never met another exec – with their MBAs, or technical backgrounds, or bean counter creds – who was able to accomplish that so easily.

This particular comment came out at some review, and though we all kind of laughed at it at the time, I found that the more I thought of it, the more I became aware that she had really put her finger on a very important principle of design.

Now, most tech I deal with has just the opposite problem. It’s just too darn complicated. Sometimes, though, a design team has learned that lesson, and has gone just a little overboard in the opposite direction.

In particular, I find that this is an issue with graphic designers. Often, they want a nice, clean, aesthetically pleasing interface. And, sometimes, to get that, they might throw away some parts of the UI that were actually pretty central for the user to understand what exactly was going on. So, though the UI might look super simple on the surface, it actually makes the user’s job a little harder, forcing them to guess what some things might mean, or how to do something, or what to do next … when we could have made it so much more easy for them.

I see this a lot, in particular, with mobile. Now, I realize we’ve got a lot less real estate to work with, and the last thing we want to do is make it cluttered. But just thinking back to the struggles my users have with hamburger menus, or kebabs, or the tiny little dots that signal a carousel … 

And it’s not a matter so much of simply deleting affordances. There are also features that don’t appear until you mouse over them, using one feature to do multiple tasks, an over-reliance on icons (and a subsequent aversion to labels), gestures … 

But how can you tell when it’s so easy it’s hard? Well, one thing is to keep your target audience in mind (and realize, of course that they will be different from you). Personas are great for this. Second, test it out. See what’s hard, what’s missing, what needs a little boost – and then fix it. 



Tuesday, May 1, 2018

Under carefully controlled laboratory conditions, any lab subject will do exactly as they wish. (Caroline Jarrett)

And that’s why we love them. It’s what makes our job fun.

I’ve always said that the great part about usability is that we get to work with the two most complex things in the universe – humans and computers. There’s no telling what we’re going to get.

But we wouldn’t have it any other way, would we? Living, breathing human beings, with all their quirks and complications, make for very interesting work. 

In fact, I like to tell new usability engineers that out of every 10 users, they’re probably going to get at least 1character. But characters are fun, are not too hard to handle, and can help brighten up a long day.

Of course, I also point out that 1 in 100 is going to be a crazy. And that, for 1 in 1000, you’re going to need to call security. Both do make for engaging stories afterward though.

It’s also why I take a fairly relaxed approach in the lab. No lab coat for me. No voice-of-god mic. No clinical lab setting. I just like to sit with the user, engage with them to the degree they need it, prep them properly, then sit back and see what happens.

I know they’ll go off script sometimes. And, usually, I let them. I’ve gotten some good stuff over the years that way. That said, I have also developed a number of good tips and tricks to get them back on track without their ever knowing it.

Heck, after 3000 users, I kind of like it when I get a bit of challenge. Honestly, though, there’s probably nothing I haven’t already seen before.


Wednesday, April 18, 2018

Please forgive the long letter; I didn't have time to write a short one. (Blaise Pascal)

Huh! I always thought it was Voltaire.

Anyway, one thing I’ve noticed over the years that this is a very common problem with new usability engineers and user researchers. And what that means is both too many pages (in reports, of course – not letters) as well as too many words on that page.

Now, I do have a hunch of where this comes from. And that would basically be school. Think about it. Throughout everyone’s academic career, we are usually awarded for over-delivering. It’s basically the standard way to show how smart you are and how much work you’ve done. Hey, nobody’s awarded gold stars for 16-pt type, wide margins, and something slightly under the mandated page count, right?

I guess I’m kind of lucky in that I happened to round out my academic career with a graduate degree in tech writing. The difference between what I learned in that program and what I learned as an undergrad English major could not have been more stark. 

In fact, it was only as a grad student that I first learned the basics of the rhetorical situation – audience, purpose, and context. So, who is this for? What are you trying to accomplish with it? How is it being delivered? How will it be processed? How likely is it to be accepted?

In other words, in the real world, the point of writing is not to impress the teacher and get a good grade. It’s to get things done – to impart information, to offer suggestions, to come to an agreement …

And what’s an effective way to do that? How about a PPT where you can get through every slide in an hour? A presentation where the amount of information on each page is not a distraction to what you are saying? Something where an audience member might remember 3 main points 10 minutes after the presentation is over? 

To tell you the truth, this is advice that is not just for junior team members. I just sat through a presentation where a very seasoned team may have gotten through 10 slides of a 40-page presentation.  

And it’s definitely not easy either. It takes a brave (and experienced and humble) soul to take all of that great work they did and distill it down to something that their audience can actually relate to, process, and value. It’s truly something every UE and UX researcher needs to remember though – it’s not about you!


Yup, that's him alright!

Monday, April 2, 2018

It depends (every usability engineer ever)

I’ve often joked that I want this on my tombstone … Even though I feel a little conflicted by it.

On the one hand, I see my offering this statement as a good thing. It means people are coming to me with questions. So, basically, I’ve gained their trust. Yay!

On the other hand, though, there are some things that make me cringe a little when I have to say this. Probably the main thing is that my clients seem to be thinking in black and white terms. Alternatively, they may also simply be wanting a thumbs up / thumbs down from yours truly.

One of the things I feel like I am always trying to get across to my clients is that the world is a complex place, and a lot of it is very situational. In particular, I like to get across that usability issues are often contextual in nature.

For example, who is this system for? A technical audience? Well, they may be just fine with it. Your average Joe or Jane? No way in heck!

In addition … What is the user’s goal? How motivated are they? Where will they be doing this? Have they seen stuff like this before? 

What are your goals? Are those conflict in with the users’ in any way? How should we prioritize? Who is making the decisions?

How hard is it to the make that change? Do you have time to do that? Is it worth effort? What are the goals of your project?

Overall, how is this decision being applied? In just this particular situation? Across the board?

And on and on and on.

You know, maybe “it depends” is just a good way to begin the conversation. Maybe a better way to word that simply would be, “Tell me more.”


Ha ha!  Very clever, funny developer guys!