Friday, May 12, 2017

A foolish consistency is the hobgoblin of little minds. (Ralph Waldo Emerson)

Now, this one is another maxim for more advanced clients (as is this one). The challenge for less experienced clients is to recognize that consistency is actually quite a good thing. They’re the ones more likely to have a blue button on one page and an orange one on another, to have title case for one field and sentence case on the next, to have the call to action at the bottom left on one screen and the bottom right on the following one …

Unfortunately, once they really learn the value of consistency, these folks now have to start dealing with exceptions to the rule. Note, though, that this is a good problem for you to have. A rigidly consistent, even overly consistent, system is a ton better than a system that is just total chaos.

As an example of the former, I just had to deal with a consistency problem involving menus. My company offers multiple products – bank accounts, mortgages, car loans, etc. Our menus for each of these is typically a list of the actual products, but also some subsidiary and educational material as well, with these three areas marked out as sub-menus.

We are currently getting into an additional product area, and came up with a menu that includes 1 actual product, 1 bit of subsidiary material, and 1 tutorial. Needless to say, this is quite different from our other product areas, which typically include multiple examples of each type. Even so, some of the team wanted to still use the same organizing scheme – which basically amounted to three one-item lists.

Another common problem is parallel lists – i.e., lists whose items are all similar. I’m a huge fan of these, but sometimes it just doesn’t work. For example, you might have a menu with a bunch of tasks. It makes a ton of sense, then, to make these all start with action verbs – “edit,” “delete,” “create,” etc. Sometimes, though, these menus will also include some support material. But changing that from, say, “help” to something like “Getting Help” or “Understanding how to use …” is just wordy, unnecessary, and possibly confusing.

So, here are some things you can ask the overly consistent to get them to focus on, not just following the rules, but knowing when to break them as well:

  • Are these things truly the same? 
  • Is there a good reason to make this one stick out a little more? 
  • How will the user perceive them?
  • What do we accomplish by making these consistent?
  • What confusion, awkwardness, or other unintended consequences might we cause as well?

By the way, though, do not use this quote! I have a funny feeling that might not go over that well.

I’m thinking this one might have been Photoshopped

Thursday, May 11, 2017

Biased questions lead to biased answers. (Anonymous)

To be honest, I think – at least when it comes to usability testing – all questions lead to biased answers. 

As I was just telling one of our new usability engineers the other day, a usability test is not an interview. They’re supposed to be task-based. And what that means is that, other than prepping the user for think-aloud and giving them a scenario, you need never say another word. It’s all about the user completing the task and vocalizing what they are doing and thinking. The perfect test is one where you just sit there and take notes. 

Now, though I do get these every once in awhile, imperfect tests are much more common. Users only rarely will make it that easy for me. Most of the time, I have to work a little bit harder to earn my pay.

Indeed, there are no shortage of times when you have to say something. Most often, the user may simply fail to do the think-aloud. I think all usability engineers are familiar with the classic “What are you thinking?” just for those situations. Variations on this include, “What just happened?” “What’s going on?” “Is that what you expected?” and so on. And, once users do start talking, a simple “un-huh” is usually enough to keep them going.

Even if users are doing the think-aloud, though, sometimes that’s not enough. Frequently, they may leave thoughts hanging. They might say, “That’s a nice …” or “I don’t know if …” or “How did that …?”  Because we humans hate to leave anything incomplete, simply repeating what they just said will usually prompt them to complete the thought.

You can use a similar trick to get users to elaborate on vague comments like, “That’s not good,” or “I don’t like that.” Simply repeating their phrase will get them to almost magically add the “why” (and in a way that sounds a lot less accusatory than simply asking them why).

All in all, the less questions the better. And, if you do have to throw in a few, make it so they don't even sound like questions.

A lot of this advice came from an excellent talk Judy Ramey (at the University of Washington) gave at a UXPA conference many years ago

Wednesday, May 3, 2017

It’s not your job to guarantee a happy ending. (Philip Hodgson)

I like being a critic. It’s kind of fun pointing out everyone else’s foibles. And let me tell you, being a usability engineer is a great way to do that. Other people’s errors are on parade before you in test after test after test. Great fun!

Seriously, though, I’m actually not really a sadist. In fact, I’m known in particular for making a special effort to be positive when reporting results. I figure I’m just accounting for basic human nature here – nobody wants to hear their baby is ugly. And if you do need to broach the subject of some possible unsightliness, well, it’s generally a good idea to have some sugar to go along with that medicine. In general, I’d much rather be, not the scold who everyone hates and ignores, but the nice guy who actually has some valuable advice that might be worth listening to every once in awhile.

Now, it is pretty rare that I get ugly babies with absolutely no redeeming qualities. Almost everything has something good to be said for it. So, that part of it isn't really that hard.

That said, there are times when you do have communicate that, yes, we do indeed have a problem here, Houston. But even in those situations, there are still some things you can do to soften the blow.

One of these is to make sure that your client is aware that there might be a problem as testing progresses. In other words, don’t wait until the report out to bring attention to serious issues. No one likes surprises like that.

So, one thing you’ll want to do is make sure you debrief after every test. You can also send out topline reports – not full reports, but quick summaries – at the end of each day. Finally, you can also get your team to see if they come up with a solution to any serious issues, say, midway through the test. (In fact, overcoming a problem can feel like an even more positive experience than simply having no issues pop up.)

Another thing I’ve found helpful is to allow the client to vent a little. I just try to put myself in their shoes (I know I’m a venter myself), and try not to take it too personally. Easy to say, but it really does take a little practice to get comfortable with.

Along similar lines, you’re going to have to also make sure that your data is pretty well buttoned-up. They say the best defense is a good offense, and I’ve seen plenty of clients who really go on the offensive when they hear something they don’t want to. In those situations, once again, I counsel remaining cool and calm as you fend off attacks on your methodology, users, prototype, personal integrity, whatever.

A final thing you can do is to do a good job of picking your battles. It’s pretty rare for me to fall on my sword for an issue. And that probably is something that just comes with experience. After doing this for 30 years, I know that it’s rare for something to be a real show-stopper. But there definitely have been some cases, over the years, where data from tests I ran caused products to be pulled, releases to be moved out, or projects to be shut down. 

Just be a little mindful about how to communicate results like those.

Philip is the owner of Blueprint Usability