Every time I hear an executive demand that someone "produce the next iPod," I want to respond, "Can you make yourself the next Steve Jobs?" (Carl Turner)

To be honest, all I really want the people at the “top of the house” (I hate the business jargon, but you know what I mean) to just leave me alone.   

And, over the years, I’ve been pretty lucky. There was only one time where I really had to deal with meddlesome execs.  Boy, though, was it a doozy.

What I was dealing with was a C-suite exec who wanted to incorporate some social media trope on a financial services site. I won’t tell you what that was, as it might give the game away. So, let’s just call them “awards.”

I think the idea was to gamify the boring task of handling one’s money. Now, there’s nothing wrong with gamification. It just needs to be done in the right context. Social media is a great example of that context, as are things like self-improvement, learning, and so on. Finances, however, can be a little dicey. 

Looking at an old report, I see that my users agreed with me: “You know, like I don't really expect to have to a earn an award. You know, this isn't a game – this is my bank account.”

They also pointed out how task-oriented they typically are on a finance site: “I’m here for one real purpose.  This is just extra noise that I don’t need when I’m really just trying to do some online banking.”

They also mentioned that they wanted to get something out of it:

• “It doesn’t look like I gain anything from them, which is another reason why they’re not super interesting to me.  If it was something like, once you’ve been a member for two years, you’ll get a higher interest rate, then I might be interested in the badges.”
• “So, unless it's gonna be pertinent to things that are happening to me that are affecting my bank account, I probably wouldn't wanna see them over there.”

Finally, users felt a little talked down to: “It’s like they're trying to gamify saving, which I feel like is kind of silly, and like they're treating me kind of like a child.”

Did they pay attention to my results? Of course not. It launched with few if any changes.

What’s interesting is that, once it was launched, the feedback was about the same. I lost track of what happened from there, I’m afraid.

Here’s hoping, though, that the exec got some understanding that that wasn’t such a brilliant idea after all, and that he should leave that sort of stuff to the professionals who he’s hired and pays good money to. Heck, I could have let him know both of those things right off the bat, and saved the company a lot of time and money.

Carl’s LinkedIn page lists him as a “chaos wrangler,” though I know him better as a usability engineer

Research that isn’t shared is research that hasn’t been done. (Lindsey Redinger)

It’s so tempting to just throw a research report over the transom. I’ve usually got another project in the works (if I’m not already juggling it), and it’s so much easier to not deal with politics and difficult personalities.  I just want to say, “Here’s the results,” and move on.  Prep, facilitation, and analysis are a lot more fun, and much more basic to what I do.

I figure the least I can do, though, is hold a meeting to go over the results.  I figure that it’s at least important to field questions, to make sure everyone understands what you’re trying to get across, to make sure there are no outstanding issues.

But, you know, for that to go over well, it really does help to get the team involved before that point.  And that means observers, and debriefs, and topline reports, and sharing tapes, and updates in team meetings.  Heck, it all really starts with good intake and planning meetings.

But it’s not all about the stuff that happens up to the report either. What happens after is just as important.  I’ve found that if you really want to have an impact, and actually have someone address the issues that came up in your research, there is no shortage of follow up you have to do.  And that means design meetings, and prioritization meetings, and technical meetings, and emails, and Slack messages, and hallway discussions.  

Writing a good report is kind of like getting a fish on the line.  That’s nice, but you’ve also got to hook him, land him, filet him, and cook him.  Now, I’m not sure how a fishing metaphor got in here but, heck, I’ll take it.

Maybe a better way to look at it is through writing fiction (something my wife does, and where that expression "throwing it over the transom" comes from).  It’s not enough just to send it to a publisher.  You may have to snag an agent first.  And to snag an agent, you’re going to have to do some schmoozing.  These days, you may even have to print, sell, and market it yourself.  I’m not sure an Emily Dickinson would have much luck in 2022.

To get back to UX research though …  One thing I’ve found over the years is that research ≠ report.  Honestly, sometimes it seems that once you’ve put your final touches on that great report of yours, your job has only really just begun.

Lindsey is head of research at Etsy

Love means never having to say you’re sorry. (Love Story)

Whuh? Huh? What the heck does that have to do with usability?

Oh, also, it’s a terrible quote. My wife and I have been married for almost  30 years. We say “sorry” quite a bit (and “thank you” as well).

Now, if this means you’re automatically forgiven, I guess that’s okay. They could have been a little more explicit though. Can you tell I'm an engineer?

I digress … How exactly does this apply to user research? For me, it kind of reminds me of my users. I’m sure we’ve all experienced – and probably been frustrated by – test participants who say things like, “I’m not good at computers” or “I shoulda got that” or “Oh, that’s my fault.”

Heck, the type even made it onto my typology of users. They’re called the “Charlie Brown” type. Note to millennials … Charlie Brown was the main character in the Peanuts cartoon. He was a sad sack character famous for his bad luck, morose disposition & for blaming himself when things go wrong.

I approach this user in several, graduated ways. If it’s just once or twice, I just let it go. If it comes up again, I usually give them a little encouragement – you know, “You’re doing just fine,” “This is good feedback,” “This is a test of the system, not of you” … 

If it’s still persistent (and these users can be persistent) and really starting to get in the way, I usually go into full pep talk mode. And that’s something along the lines of, “You can do no wrong here today. If there’s an issue, it’s an issue with the [site / app / software]. And I want to know about it.” I might also mention that they are the perfect user for this system, and if they can’t use it, other people won’t be able to either.

When it comes down to it, I really do love my users. All I want to do is make them feel comfortable sharing their thoughts – and never having to say they’re sorry for anything.

There is a big difference between what people think they want to know, what they say they want to know, and what they really want to know. (Carl Zetie)

When I used to work on-site, a familiar hallway or elevator greeting for me was often, “How’s the test going?”  How I answered could take many forms, depending upon who asked. The business usually simply wanted to know about test logistics (“Yup, halfway through”), the design team typically wanted to hear how cute their “baby” was (“very cute” was the proper response), and fellow UEs wanted to hear the horror stories (the worse, the better).

Report-outs are very similar. In this case, though, everyone usually wants to hear just the good stuff. Oh yeah, there are always hard-nosed business types or super-experienced designers who really do want to know what needs to be fixed. In general, however, most people really want to sit back, rub their hands together & “call it a wrap.”

It’s in test plan meetings, though, where you get the really interesting responses. Often, I get a lot of crickets, or blank faces. In that situation, I go straight into interview mode. Some of the things I ask involve: questions they want to get answers to, anything that seemed particularly problematic during design, anything that they argued over or are split on, anything that is crucial to the success of the product, their expected outcomes, what would constitute success to them …

Alternatively, I might get some super hair-splitting detail that often seems to come from someone’s particular bugaboo. In this case, I typically have to explain how 1) that might be rather hard to get feedback on, and 2) that’s really not what this test is for. (As for that last point, it’s not too surprising to find newbies who aren’t totally sure what a usability test is. A little education – especially that a usability test is not QA, a focus group, a survey, or an interview – is in order.)

I also have several generic topics that I can throw out anytime. These include things like navigation, content, look and feel, flow, graphics …

Finally, I also try to do my own quick review of the digital property in question beforehand and see what strikes me. Sharing my own thoughts and queries – “Do you think x, y and z are terms that this audience will know?” “Will the user know what to do on this page?” “Isn’t that link a little buried over there?” – often gets the ball rolling for the team as well.

Interestingly, I’ve even found that a test plan meeting where topics like these are addressed can sometime help down the road as well. If the team knows upfront there might be some possible issues with a particular page or flow or bit of wording or what have you, they’re more likely to remember that point throughout testing and in reporting out the results. 

I also find an added benefit is that you’re often able to share some good news as well. Remember that modal we were worried about? Absolutely no issues. That content that legal and compliance insisted on throwing in there? Nobody batted an eye. That graphic you all were arguing over? The users loved it!

Carl has been doing this stuff for quite awhile; has worked for IBM, Accenture, HP & Oracle; and is the author of Practical User Interface Design.

If I had asked people what they wanted, they would have said faster horses. (Henry Ford)

 Ah, yes, innovation. Where does it come from? It never seems to result when you simply ask users what they want. They simply don’t know, or would never be able to articulate it if they did. 

Steve Jobs said something very similar: “A lot of times, people don't know what they want until you show it to them.” I’ve already covered this elsewhere, so I’d like to try and put this idea in a little different context this time, a context a little closer to a user researcher’s heart.

I often get clients coming to me asking for faster horses. And by that, I simply mean that they ask me for what they already know. Usually, this means a survey, an interview, or a focus group. Everybody’s heard of those, right? 

In this situation, it’s my job to ask questions, to get at what they’re really after, to ignore the how and focus on the what and why. As a result, I will typically be giving them something new and innovative, something that they may never have heard of before. And what I’ll be suggesting to them is a usability test. 

Now, a usability test may not be all that new and innovative – if you’re a user researcher, that is.  For them, though, it definitely can be.

And that brings another thought to mind. We already have so many tools in the toolbox. Why is it so important for researchers to be always coming up with some new method?

Yes, new tools do definitely come along. And it’s super-important to be aware of them, add them to your arsenal, and be able to apply and use them in the right context.

I really do think, though, that innovation in research tools is overemphasized. Why might that be? I guess it’s a combination of not-invented-here-syndrome, looking good at your performance appraisal, impressing the higher-ups, giving your small consultancy a differentiator, wanting to get a publishing credit, etc.

The toolbox, though, is pretty well jam-packed with a number of tried-and-true, absolutely brilliant methods that have already passed the test of time and usefulness across the industry – usability testing itself, remote testing, unmoderated testing, ethnography, card sorts … I think the real skill is in understanding all the available tools, educating your clients on those, picking the right one & doing a bang-up job applying it.

BTW, I find this quote particularly rich coming from Henry Ford. I mean, wasn’t he the same guy who said, “You can have them in any color you want, boys, as long as they're black”?

His real innovations came in the factory

Stop trying to help. You’re making it worse. (Jenny Lawson)

Remember pop ups? Remember the bad old time before pop-up blockers? Man, talk about something that totally shot the user experience.

Well, believe it or not, they’re still around. This time, though, they’re for the site you’re already on. Sign up for our email (which you already get)! Watch this dumb video (about the article you’re already halfway through)! Don’t leave us (though you already know I’ll be back tomorrow)!

They remind me of commercials for the TV channel you’re already watching. What’s the matter – couldn’t you sell any advertising time? Is the content so weak that you think I’ll never be back? Don’t I already watch this channel all the time anyway?

I mean, this sort of thing could be helpful for the user/viewer. Maybe I’m new, and need to know all that you have to offer. Maybe I do want to follow you on social media. Maybe there is related content that I might be interested in.

And, then again, maybe not. My guess is that all these distractions are more helpful for the business than the user. Indeed, it’s a fine line between helping the business and annoying the user.

Unfortunately, it seems this particular issue has also bled from simple marketing into actual functionality. There certainly are a lot of things popping up within software these days that would fit the bill. It seems I can't move my cursor around without a million little things invading my screen – coachmarks, tool tips, little messages, menus …

Take, for example, the MS task bar. If I move my cursor down that way, little pics shows me what’s currently in that particular application. Unfortunately, they stay on the screen until I click elsewhere. (And, whatever you do, don’t click the x in the corner of the pic – it’ll shut that app down.)

While bashing MS, let me also include the Design Ideas that pop up every time I start a PowerPoint presentation. I’ve never used these and doubt I ever will. Could they just not show them? At least let me say “don’t show it to me again” on the first time I see it, and not force me to do so on the second. But, then again, what do you expect from the folks who brought you Clippy?

Now, let’s take a look at some folks I really respect, and whose stuff I use all the time – UserTesting. Par exemple, when I go to the timeline at the bottom of a tape (to go to a certain spot, to make a clip, etc.), I have to move my cursor through something I think they call the “sentiment bar.” It includes what they think are positive or negative comments, shown by little green and red markers. Clever idea, but I don’t really use it, and every time I go down to the timeline, the actual good or bad comments pop up and get it in my way.

Now, this all might seem a little niggly, but for me at least, it’s typically death by a thousand cuts, if not the ol’ Chinese water torture. 

Once again, it seems we’ve got something that’s possibly useful, but really probably just distracting. In a way, it’s really just marketing for the software. I’m marketed to enough already. Please limit your invasions to a minimum in what I once thought was a safe space – the software I use to do my job.

Jenny Lawson turned mom blogging into a career as an author

It’s a poor carpenter who blames his tools. (anonymous)

Once again, I beg to differ. 

Internal tools, for example, are notoriously hard to use. These are typically sold on feature sets and price, with the poor employee who has to use the thing usually having no input whatsoever. In addition, that unfortunate person simply can’t just walk away from their tool, like they can if they were a consumer on a bad website or looking to upgrade some personal software and shopping around. Internal tools can have a surprisingly long shelf life. 

Now, all that is pretty much a given. Everyone knows that even the best companies are not going to give the same effort and attention to internal tools that they will to customer-facing ones. It’s just a fact of life.

What I really don’t like, though, is the rather blase, blame-it-on-the-user attitude that this quote implies. If it’s not something that we would ever do with customers, why is it so okay with internal users? 

As an anonymous programmer said on a discussion group I found:

“Da Vinci with a mop and a bucket of mud may be a better painter than you, but he would never beat Da Vinci with quality tools.”

And how many Da Vincis are you surrounded by at work? Also, isn’t ease of use part of “quality” anyway? 

I guess I’m commenting on this now because I’ve been seeing a lot of this lately in the newer tools that come out. Every tool out there seems to have so many implicit functions, so many cryptic icons, and so little text explaining anything. And they all seem to assume we are all expert users who use their platform all the time (and likely no others). 

Building on top of that is the number of tools the average employee is expected to master. For me, it’s the Microsoft Office suite, plus a dozen usability and market research tools, some designer tools (Invision, Sketch, Axure …) plus “productivity” tools (Jira, Confluence, Trello …), just as many “communication” tools (Slack, Teams, email …), and dozens of internal nightmares (i.e., different vendors for travel, expenses, training, benefits, insurance …).

Maybe the issue is really just TMT – too many tools!  So, take 100 different tools (all with competing UIs – and most of very questionable quality), mix together, shake vigorously, and watch the chaos ensue!