Before you build a better mouse trap, it helps to know if there are any mice out there. (Yogi Berra)

Man, the guy’s a genius. What better way to sum up the argument against feature-first design?

And what’s feature-first design? It’s really pretty simple …

Say you’re a designer who’s run across some cool feature on another website. Wouldn’t it be great if you could use something like that too?  Now, where we can we do that?  How about the current project you’re working on?

Now, there may not be any need for that feature on that project. Or, if there is, there may be no need to do that particular way. What’s already there may work just fine. Or the newfangled way might not be a good fit.

But is that going to get in your way?  Of course not!  

I guess a lot depends on where you’re going to get your from feedback from.  If it’s from other designers (say, in a crit), their inherent neophilia will probably get them to go along with you.  And management, of course, always likes bright, shiny, new objects.

I would, though, suggest getting that feature in front of some users.  If it truly is a game changer, they may very well like it.  Otherwise, you may find that it’s simply hard to use.

Over the years, I’ve tested some “cool” new features that fit both categories. As for the first, I remember testing long, scrollable pages back in the day, back when not a lot of sites were using them (if you can imagine that!). Boy, did they test well.  Slam dunk.

As for the second, I remember testing the hamburger menu back when it was brand new as well.  Man, did that bomb.  Users tended to have no idea what it was for, and subsequently never clicked on it.

Now, of course, it’s everywhere.  Back then, though, not so much.  I guess you could say we were ahead of our time.  From the user’s standpoint, though, it’s important to realize that may not necessarily be a good thing.  Can you imagine that?

I tell ya, the man was just a usability quote machine

Never ascribe to malice that which is adequately explained by incompetence. (Robert J Hanlon)

Boy, do I see a lot of the latter. And that is indeed a good first assumption that that’s probably what you’re dealing with in any particular situation.

I do also see some of the former. It’s pretty rare though, and typically from some marketeer. It’s where the idea of “dark patterns” comes from.

What I actually see, though, is a lot of laziness. In fact, I see that more and more. I guess speed to market is the culprit here. I’ve also seen a fair amount of throwing issues that do come up into the backlog, where they can conveniently be ignored. It’s typically not incompetence per se, but just other things taking priority.

So, what’s a simple user researcher to do in this situation? I guess my main advice is to not be afraid to call it out. 

God knows, there are always people on the team who will speak up for the business or the schedule or the technical side of things. Just make sure someone’s drawing the team’s attention to the user as well.

By the way, this quote is sometimes called Hanlon’s Razor. I’m guessing that’s a nod to Occam’s Razor, where the simplest explanation of something is usually the best. For example, I love a good JFK conspiracy theory. But when it comes down to it, it was probably just Oswald. 

Apart from his submitting his saying to Arthur Bloch's Murphy's Law Book Two (and being from Scranton, PA), no one knows for sure exactly who Hanlon is

Show, don't tell (Percy Lubbock)

I’m intimately familiar with this one primarily because my wife is a novelist. It’s one of the most basic ideas in fiction. A good example might be revealing a character’s true nature by an act or a quote of theirs. Which certainly beats simply saying the character is mean, or brave, or witty, or whatever.

Now, how could that possibly apply to user research? Isn’t a good usability report all about "just the facts"? And though I do work a lot with personas, aren’t they something very different from characters in novels?

Maybe a better way to say this might be, “Do the math.” It’s usually not enough to simply say that screen X didn’t work or task A failed. If you do nothing else, you have to at least offer some detail. There’s a reason something failed or didn’t work, right? Now, what was that exactly?

If your client can get their head around those reasons, that might be all that’s required. So, that button was hidden, that path was pretty convoluted, that copy was really hard to read. I get it.

It helps too, though, if you have some evidence. First, you can just throw some numbers in there. Even though you’re probably talking about the small numbers that come with qualitative studies, it is helpful to know that everybody had that problem, or most did, or over half …

It’s even better, though, when you can share quotes and clips. Those can really bring home the idea that these are real users having real problems. It’s not just my take on it. I’m not just editorializing here. Quotes and clips really do speak for themselves.

So, you’re probably now asking yourself who the heck was Percy Lubbock. Well, the interwebs are telling me that he was, in fact, a British literary critic (and a CBE to boot!). His The Craft of Fiction popularized this adage way back in the 1920’s.

It’s an idea, though, that’s been expressed by a number of different writers:

• Mark Swan (American playwright and scriptwriter): "Show–not tell”
• Anton Chekhov: “Don't tell me the moon is shining; show me the glint of light on broken glass.”
• Ernest Hemingway:  “Show the readers everything, tell them nothing.”

My favorite writer after Shakespeare 
(and my wife, of course)

If you want information, feign ignorance. (unknown)

Ever researched something that you don’t yourself understand? No matter how hard you try?

Though most of my work has been with straight-up, average consumers, I do get the occasional something way out there. I also know that there are researchers who deal with this every day (poor things). 

Since researchers tend to come from all over the place, this could mean dealing with medical devices if your degree is in psychology, accounting if your background is comp sci, nuclear engineering if you have a BA in English …

For me, ex tech writer that I am, it’s been a challenge on almost everything outside of that nice, cozy (mostly financial) consumer space. Personally, I’ve worked on stuff that might normally require an MBA, or 5 years in the insurance business, or a degree in statistics …

How to deal with it? I think the first thing is to admit to yourself that you won’t understand it all. I know that can be tempting, but I think it’s better to concentrate instead on your knowledge of research. Let that be your SME superpower. 

Second, don’t try to cover up your ignorance. That can backfire, resulting in misunderstandings, embarrassment, and bad research results. 

Ironically, it actually takes a fair amount of self-confidence to admit you don’t know anything. (In general, humility is another wonderful superpower to have.)

Finally, don’t beat around the bush. Just come right out and fess up. It’s really no biggie. In fact, it really helps in making it clear where everyone stands, getting you the info you ultimately need, and making the SME feel like a big-shot. 

But, if you’re still worried about how you’ll come across, here’s another anonymous quote I found on the Interwebs: “Ignorance is lack of knowledge, not intelligence.” Indeed, you have to be pretty darn smart to be able to talk with the experts effectively. Just make sure you’re taking the right tack right from the get-go.

Where that last metaphor comes from (and, no, I don’t understand it at all)

Method shouldn’t dictate results. (me)

I looked all around for a better quote than this, perhaps from someone a little higher up in the UX firmament than yours truly. Unfortunately, though, you’re stuck with me.

It is one of my all-time favorite topics however. I find it applies to a lot of newer researchers especially, but to more seasoned ones as well, especially if they are short on time or just forget.

What I am talking about here? Well, I guess it’s just a plea for a little more high-level thinking. Let me give you an example…

Say you’re writing up a usability test you just ran. Now, a traditional approach would be just to report things task by task. You know, task 1 had an 87% completion rate, as well as these particular issues. Same deal with task 2, task 3 & all on down the line.

But what about those issues that came up on all – or at least on multiple – tasks? Just mentioning them for each task doesn’t really give the reader an idea of how pervasive – and important – they might be.

Another approach – especially if you have, say, a single task with multiple steps or pages – is to go screen by screen. Screen x had these issues, screen y these, screen z none, yada yada yada. Unfortunately, you’re going to have the same problems with that approach as well. What issues spanned multiple screens? What are some of the larger problems here? 

I guess a lot depends on how you think about your research. If it’s just like a punch list for a new house, say, go for that bottom-up approach. If, however, you’d like to engage with your audience at a higher level – maybe even learn ‘em a few things – you might want to sum things up a little more.

If, for example, terminology is an issue across tasks or screens, simply put in a slide solely on that topic. Yes, you can mention where that appears, but I think it’s better that the team knows this is a larger issue. Heck, they might even want to do a review of all the screens or functions to make sure it’s taken care of everywhere. After that, they may even go so far as to apply that learning to their next project, and the one after that, and the one after that…

I do find that there are topics that seem to go across multiple projects & multiple teams – nav, graphics, accessibility, mental models, TMI, affordances … In fact, you can even start to track some of these and even address them upfront, separate from any particular project. In other words, help your team address root causes, not every little nit.

Same thing applies to surveys, focus groups, and other research methods as well. As an example, I just read a report that separated out quantitative survey results into each individual question, then tackled verbatims separately. How nice it would have been if the researcher had combined those two, identifying some larger themes along the way. That seems to be something that most researchers do naturally on interviews and ethnographies. I’m not sure why that wouldn’t apply all around.

So, in sum, don’t leave your results half-baked. Go that extra step and give them something that’s easy and pleasant to digest. And, whatever you do, don’t just give ‘em a recipe! Go ahead and plop that amazing dish right on their plates in front of them.

Tell me, why does it seem that all my favorite metaphors involve food?

Just do it. I don’t want an experience. (user)

I just had a user offer up this quote on a DMV website. She had just run across a message saying, “Just a moment while your experience is loading.” She was trying to pay a bill, and the site was being a little slow, hence the interesting variation on the standard “loading” message.

The same user was also on Vanguard, trying to make sense of some message that asked her to “migrate off the legacy platform.” “What’re they talking about?” she asked me. “How are you understanding it?” would be my typical response in a situation like this.

Jargon used to be the sole province of techies or industry insiders. You know, the error message that sounded like a leftover from the space program – “Invalid response: abort or retry?” Or perhaps the casual use of terms like “widget,” “RSS,” “cache,” “patch,” “API,” “firewall” or “SSL.” I think we’re all familiar with this sort of thing sneaking into the UI.

Now, ever heard of the terms “deposit account,” “external transfer” “HELOC” or “ACH”? Those are all nuggets I’ve run across in my career in banking. I’m sure each industry has a list of something similar.

Well, UX must be mature, because I’m starting to see jargon from there now as well. “Experience,” “interaction,” “journey,” “hamburger menu,” “onboarding,” “breadcrumbs,” “responsive” … 

Yup, not only do users have to contend with the techies and the industry insiders. They now have to contend with us. The irony is palpable.

Now, you might be wondering what I’m doing testing DMV and Vanguard. Actually, I’m not.

That particular user? To paraphrase an old vaudeville joke, that was no user – that was my wife. Sounds like I’ve got her trained pretty well now to recognize poor design.

And here I always thought that quote came from Groucho

It’s kind of a pain in the button. (anonymous user)

Actually, the user didn’t really say that. What they really said was that something was a “pain in the butt.”

My transcription software, though, rendered it as “pain in the button.” Which, in its own way, is absolutely perfect.

To be honest, I don’t think I could live without transcription. Sure, I could simply watch the tapes. That, though is an extremely linear experience.

Honestly, there’s going to be so much filler – my prep, polite chitchat, reading scenarios, the user’s making their way through the easy part of the task, irrelevant diversions …

But with a transcript, if I’ve got a note about something interesting the user said about a certain topic, I can just search on that topic and go right there. Alternatively, if I’ve captured part of a quote, I can just search on any distinguishing word in that quote.

Now, if the test was unmoderated, I can also scroll through the transcript faster than I can go through tape. And that’s even if I play the tape at 2X (which, honestly, can be a little hard to interpret). Once again, I can just ignore all the filler, and go straight to where there’s something with a little more meat on it.

Now, no transcription software is perfect. So, I do get my fair share of stuff like this, usually with non-native English speakers (poor things):

• “I'm a little bit confusing.”
• “Sorry, I have a little bit, uh, destruction.”
• “So I'm confident that I have the DF finger, right?”
• “So again, uh, notifications for competent for Diva.”
• “APIs are, are variable submitted to change and accurate as okay as female reduced enemy, okay? A bonus plus a great threat.”

That said, I do love my transcripts. 

Oh, and by the way … Transcript or not, I’ve had users comment on pain in butts, asses, keisters, tuchuses & dupas. And for those of you who don’t speak Polish, well, that’s exactly what that last one was. So, don’t say I never taught yez nuthin, ‘kay?

Just think of user researchers as big pillows on the hard, small bicycle seat of terrible UI