If you define yourself by your opinions, questioning them is a threat to your integrity. (Adam Grant)

Boy, do I run into a lot of defensiveness. Usability feedback almost always seem to generate some personal sensitivity. Heck, if this was my quote, I'd probably substitute "self" for "integrity."

But that’s understood. The design I might have been testing is usually at least somebody’s baby. And nobody likes it when their baby gets called ugly.

Now, I do try to mitigate that by including positive results as well; by being diplomatic with feedback overall; and by making sure that any feedback is backed up by numbers, quotes, and clips (and triangulation with other findings, and 3rd party research, and whatever else I can muster …).

There are some team members, though, who seem to always take user feedback as a personal affront. Over the years, though, I have sensed an inverse correlation between a designer or content person’s skill/experience/maturity and their likelihood of being offended. In fact, I’ve often joked that the best of these folks can’t wait to get something in front of users, while the worst will do everything in their power to make sure testing doesn’t happen (or that the results get ignored).

I guess my advice for the latter would be two-fold. First, have some basis for your design or content. Don’t just dash off and come up with something “kewl.” Have some reason why you’re using a new layout, or why you’re fore-fronting that particular bit of content or, really, any decision that you’ve had to make. Show that you’ve actually thought about this, that you’ve considered things from multiple sides, that you’ve done your homework. 

And as Grant points out, one of the best things you can do in this regard is to question your own opinions yourself. Don’t just wait for others to weigh in. 

Now, be sure to be open to others’ feedback as well. But, if you’ve already anticipated some of that, you’ll probably find yourself a lot less defensive, as well as a lot more confident in your opinions (and with good reason, this time!). And remember, it’s not about justification! It’s about being well-informed, and being able to engage in a good give-and-take.

Second, nothing is set in stone. Sure, you’ve probably come up with something pretty decent. Others, though, might be able to catch something you overlooked. And though peers, management, clients, and SMEs are important here (crits can be great), definitely don’t ignore the user.  

In fact, try to simply start thinking of them first. I’ve found that if you get that part right, it’s a lot easier to convince the other stakeholders as well. In general, all the other pieces just seem to fall into place.

Finally, just remember that your opinion is not you. Actually, another way to think about that is a little counter-intuitive … Your opinion should be a lot like you, an ideal you – open-minded, dynamic, open to change, ever evolving.

Adam is a prof at Wharton Biz School, where he specializes in organizational psychology

Don’t make me read. (William Hudson)

I think we’re all familiar with Steve Krug’s, “Don’t make me think.” I think a necessary corollary to that, though, is this gem. 

It’s kinda funny … I actually thought I had come up with this on my own. A quick search of the Interwebs, though, showed me that a lot of people liked to share this one (and maybe even thought they had come up with it themselves as well).

As far as I could ascertain, though, it seemed like Horton might have been the first. And he has indeed been around for quite awhile. 

I’ve probably got a half a dozen posts on here that treat on this very topic. I won’t repeat those here. To be honest, I’m mainly including think this quote because it sums them all up so well.

It also, though, brings up an interesting thing about Horton (and me as well). Though he was one of the founding fathers when it came to usability and usability-centered design, he quickly moved to instructional design, especially e-learning. I was also formerly an instructional designer, read his books way back when, and still remember him fondly.

And what that really goes to show is that reading is a not-so-popular activity in many situations. In training, though, this is particularly the case, and instructional designers have come up with many ways to address this. This is, in fact, behind what are called “multiple modalities.” And that’s just a fancy way of saying some people like to read (like in a textbook), some like to listen (say, in a classroom), others to view it (e,g,, in a video), and some to actually try it themselves.

And that is something that I’d like to see more of in online content in general, whether on a public site or an authenticated one. But that idea is something that instructional design anticipated as well.

It actually ties back to an idea called “Employee Performance Support Solutions.” Introduced back in the early 90s by Gloria Gery, it simply posits that anything that can support the user – text, video, exercises, sand boxes, knowledge management systems, Slack channels, whatever – should be right there, at the user’s fingertips. 

So, what means is that making content usable is a lot more than just simply editing text for length, or scannability, or hiding less important info behind links, or using a pyramid structure … What it really means is thinking about the user, and fulfilling their needs wherever they are, and whoever they might be. One thing it’s definitely not about is any kind of silos.

Horton actually moved from text altogether, switching from e-learning to making a living as a photographer

Visually simple appearance does not result in ease of use (Don Norman)

Just ran into this the other day. Basically, some of my designers wanted to combine some features on a stock screener, a page where you can enter multiple search criteria to find a stock you might be interested in purchasing.

In particular, they wanted to combine the search fields with x’s, to remove any particular criteria from the search. Before, we had made that a little bit more explicit with pills above the search results table to indicate the user’s search criteria. Their argument was that the pills had cluttered up the screen. 

I saluted their efforts, but brought up the idea that, though they had saved some space, they might have also made things more difficult to figure out. Will users see the x? Will they understand what it does? Will they get what is basically is now a modes issue?  Norman goes on to say that “simple appearance can make control more difficult, more arbitrary, require memorization, and be subject to multiple forms of error.”

I actually see this quite a bit. Another example is hiding controls – e.g., only showing them when the user mouses over them. Very subtle, minimal design is another favorite of designers. 

For the latter, I lay a lot of the blame on the Metro design style. That style makes quite a bit of the UI rather implicit. Can I click on this? Is this a header or a link? What does that icon mean? Is this supposed to be a tab? What happens if I mouse over here? To designers, though, it all just looks “sleek,” “elegant,” and “gorgeous.”

Whatever they happen to be coming up with, the designers I work with never quite seem to get my argument. That’s kind of ironic, as they love to talk about the idea of “affordance” (I think they may have picked that up from me). Unfortunately, I’m not quite sure they make the connection between the “clunky” things they are so busy getting rid of and the affordance that those things actually provide. 

Don and his famous cap

Even a bad usability test will help improve your software. (David Travis)

Hmm, not sure how I feel about this one. And I’ve seen plenty of bad usability tests over the years.

Now, I’m a firm believer that you can always get something out of a test. And maybe that’s all that Travis is getting at here. 

I know I’ve definitely screwed up at times. When it comes to users, for example, I’ve had not enough, overweighting in one area, a turkey or two … And there are also times when the prototype will be a little rough as well. Finally, I might also find that parts of my script might be less than ideal.

But those kind of things really don’t matter all that much. For users, for example, I find it’s pretty easy to just delete the ones that don’t work out. You can always reschedule new ones or, say, just go with 8 instead of 10.

As for prototypes, if it’s something major (e.g., it won’t even load), I’ll just scratch those tests as well, get that fixed & then try again. If it’s something minor (which is much more common) I’ll just keep the data, make sure the issue get fixed, and plow forward. That said, if it’s something that might affect very specific results, I might just throw out the data for those initial users, but write up the issue anyway.

Something very similar can also happen with script issues as well. To be honest, though, I’ve been doing this for 30+ years, so this is probably the thing that comes up the least.

Now, you’re probably thinking to yourself, Isn't there something missing here? And, yes indeed, there is – facilitation. Now, having stopped counting users at 5,000, I’ve pretty much seen everything. Though I did have some slip-ups & befuddlements in my earlier years, I feel pretty confident I can prep for & handle anything now.

If, however, you’re not a seasoned veteran, facilitation can be a real issue. Are you biasing the user? Are you giving away the answer? Are you interacting too much, turning your usability test into a friendly get-together with an old friend? Now, these can be biggies.

Something similar can happen with your screener too. A poor screener will simply give you the wrong audience, and what might be a problem for who you ended up getting may not be for your true audience (and vice versa, of course). But how would you ever know?

As for scripts, the cardinal sin here is typically giving the game away in the scenarios. You know, pseudo-tasks like "go to page x" - instead of going to page x for a very good reason (you want to buy y, you need to transfer money from a to b, you need to get from your house to place z …)

For prototypes, it’s mainly a question of whether it supports your tasks. And let’s hope those tasks are the right ones as well – common tasks, high-impact tasks & tasks that get at questions that your project team wants answers on. In other words, if you don’t have the right tasks, you’ll have incomplete (and possibly misleading) results.

You know, it could be just about anything in your test plan, to tell you the truth. What happens, for example, if your usability test should really be a focus group, or in-depth interviews, or an unmoderated test instead of a moderated ones?

Heck, though, if you’ve got methodology wrong, I’m not sure David’s quote would still stand. Hard to get orange juice out of an apple.

If you don’t know where you’re going, you’ll end up someplace else. (Yogi Berra)

I’ve been doing usability tests for 35 years now. And I still am never attempted to just “wing it.”

For me, even the simplest test needs at least some kind of test plan & some kind of script. In fact, I’m a firm believer that:

1. A good planning meeting means a good test plan
2. A good test plan means good prep
3. Good prep means easy facilitation
4. Easy facilitation means good test sessions
5. Good test sessions mean good data
6. Good data means good analysis
7. Good analysis means good reporting
8. Good reporting means your team’s actually motivated to changes that will affect the user experience in a positive way

Now, I’m not saying that every test needs to be a formal effort. If you’re at least cognizant of the above steps & maybe write some of them down on paper, you should be fine. The bigger the effort, though, the more formal you’ll probably want to make it.

Whatever the size of your project, probably the biggest benefit you’ll get out of good planning is something that you may not have considered, confidence. It might just be me, but I don’t work very well when I’m flustered. I forget things, I get things out of order, I say the wrong thing, I hem and haw, I don’t exactly inspire confidence in my user (or my observers) … 

Now, I do know some other folks who honestly do thrive under pressure. In fact, those kind of people often need a little jolt of some kind like to really get things rolling. You know the types – that guy in college who was always pulling all-nighters, the exec who can make off-the-cuff remarks in front of 200 people, that usability engineer who’s never run a pilot test in their life.

To each his own, but usability tests typically have way too many moving parts to ever really “wing it.”

Yogi and some cutting-edge tech (for the 1950s, that is) 

Effective error messages inform users that a problem occurred, explain why it happened, and provide a solution so users can fix the problem. (Microsoft)

Honestly, is this still a thing? If memory serves me correctly, my first conference presentation was about this very topic. Forgive me for having a little trouble remembering, though, as that was all the way back in the 1980s.

I guess, though, not everyone in UX these days was around back then. Heck, I would imagine the great majority of them probably hadn’t even been born yet. 

That said, I do see a lotta UXers without much background in UX as well these days – designers with fine arts degrees, content strategists who studied Shakespeare or did the sports beat at the local paper, project managers who have backgrounds in sports marketing … Funny, though – it was much the same when I started.

But I digress …

I’ve always liked to see these ideas in user terms – i.e., the things that a user might actually ask. Is something wrong?  What is it?  How do I fix it?

In addition to that, I think it’s also important to speak the same language as the user. So, no “invalid operators,” “bad requests,” or “system error codes.” (By the way, a lot of these come from the days when developers wrote error messages. Don’t be like them!)

Related to that is to “speak human.” Just think of that poor user, who is obviously already having problems. The last thing they need is a “fix” that doesn’t fix anything, or that talks down to them, or confuses them, or makes light of their situation. No better way to guarantee their going from mildly annoyed to seriously pissed off.

Finally, be specific. Be concrete. Use examples. This extends to both how to fix the problem as well as explaining what went wrong (within reason, for the latter – remember who this is being written for). So, no more “enter a valid number,” “please try again,” or “correct name and resubmit.” Human minds tend to be a lot more concrete that abstract. What exactly constitutes a valid number? I can try again, but is there something I should be doing differently? What exactly was wrong with the name I entered?

Overall, think in the terms that the user might. And that’s really the main idea here. No matter who you are or where you came from, just think like the user. And if you look at it that way, it is true – the basics never really go away.

The more things change …

There are downsides to everything; there are unintended consequences to everything. (Steve Jobs)

Unintended consequences are a huge part of the tech world.  Facebook was going to bring the world together, remember? Instead, we got fake news, reality filters, abuse & stalking, depression & alienation, erosion of privacy, and the destruction of local journalism. So much for social media.

How about the sharing economy? Well, for Uber, we’ve got price surging, physical abuse of drivers & passengers, drivers who can barely make ends meet, drivers with criminal records, cabbies being put out of business, and a corporate culture that looked like a cross between Animal House & The Wolf of Wall Street. For Airbnb, we’ve got party houses, destruction of historic neighborhoods, stolen & damaged items, breaking of local laws, exorbitant fees, and illegal subletting. So, so much for that.

Amazon? Twitter? WeWorks? Don’t make me laugh.

I wonder if Jobs had any regrets. I mean other than Foxconn suicides, sweatshops, slave & child labor, overpricing, walled gardens, planned obsolescence & incompatibility, anti-competitive practices, tax dodging, spin, secrecy, environmental issues, digital addiction, Apple maps, scandals (Fortnite, batterygate, John Wiley & Sons, Think Secret), as well as what an awful person Steve Jobs actually was ... 

Honestly, maybe the only unintended consequence he really cared about was getting found out.

Or maybe that reality distortion field really did work - perhaps even on himself.