First rule of usability? Don’t listen to your users

You probably know the value of a user-centered approach to Product Design, with user interviews, surveys, ethnographic studies, and usability testing at the forefront.

User-Centered Design (UCD) or Human-Centered Design (HCD) is by many considered the only right way to design.

At the same time though, one of the OGs in the field, Jakob Nielsen (of the Nielsen Norman Group), has long been touting what he calls the First Rule of Usability? Don’t Listen to Users.

If you just read the headline and decided to run with it, which I know some people did, I get why you’re confused. So which is it? To listen or not to listen to users?

What “Don’t listen to your users” really means

We have plenty of opportunities to listen — or not to listen — to our users. The first rule of usability applies to all of them. Formal user research in the form of interviews, focus groups, or surveys. Direct product feedback from usability testing or polls.

Ideation and co-creation workshops with your users. Questions, complaints, and requests via Customer Support.

There’s nothing wrong with listening to your users in any of these situations. The problem isn’t the listening per se. And that’s exactly what Jakob Nielsen says as well if you go beyond the catchy headline. Immediately after stating the rule in the video below, he says:

Or, maybe more precisely, don’t do what the customers SAY that you should do.- Jakob Nielsen

That’s the super important point that some people seem to miss. Listening to your users isn’t inherently bad. Quite the opposite! You just have to do it right and do more than listening. Blindly following requests and feedback from your users will likely lead to trouble.

“Don’t listen to your users” really means “Don’t do what your users tell you to do.”

Why you shouldn’t do what your users tell you to do

Your users aren’t Designers

I won’t get into the whole “Everyone’s a Designer” discussion right now, but rather just make my point: Unless you work for Figma, Adobe, InVision, or Sketch, your users aren’t professional Product Designers. Even if you work at one of these places, your users don’t have the insider’s perspective on your business.

Your users don’t have the skills or processes to uncover the underlying problem they want solved, consider potential solutions, and decide on the best one.

Not just the best one for them, but the best one for your roadmap, your strategy, your budget, and your human resources.

It’s your job to design the best possible product for your users, not just the product they ask for.

I assume you wouldn’t go to your mechanic or personal trainer and tell them exactly how to solve your problem. They’re the experts on cars and human physiology. Let them do their job. You’re the expert on Design. Do your job.

Don’t think you’re being a good Designer by doing what your users tell you to. You’re not. You’re doing them a disservice.

Don’t go with your user’s first idea because you’re pressed for time and need to check off the “User research” box on your to-do list.

Instead, take your user’s feature request or design suggestion as a sign of an underlying problem or unmet need.

Your job is to uncover and understand what sparked your user’s idea in the first place.

Only once you’ve done that should you go into solution mode. Your user’s idea may still be on the table, perhaps it’s even the best one. Or it may no longer be relevant at all.

Your users can’t accurately describe their behavior

The human memory is fallible in general. How could you expect your users to remember the details about colors, copy, button placement, menu structure, and exactly how they used and did certain things with your interface?

Don’t ask your users to recollect how they normally use a certain feature, how long it takes them to do something, how often they do something, or where they struggle. Instead, let them show you

Do a usability study where you observe your users using your product or service, with either concurrent or retrospective think-aloud. Measure the completion time for key tasks and other relevant metrics.

Track and measure your real users’ behavior with your live product or website, and make conclusions with quantitative data. Supplement with a tool like Inspectlet to watch real-life user sessions.

Don’t ask your users to describe what can be observed.

I often see a mismatch between a test participant’s post-test recollection and what I saw them do 10 minutes earlier. This sometimes includes rationalizing their behavior and making indirect design suggestions such as “I would have seen the button if it had been bigger.”

All you know is that they didn’t see the button. Now go design a better solution.

Your users don’t know what they want

Your users don’t know what they want or what they’re likely to do or use in the future. Yet they’re happy to speculate, whether you ask them to or not. They’ll even do it on behalf of others when asked about their opinion on a new feature or product.

The problem is further exacerbated by people’s tendency to tell others what they think they want to hear. In other words, your users are too polite.

Don’t show someone a drawing of a product or feature and ask if they’d buy or use it if you create it. They will assume you’re looking for a “yes” and be more likely to give you one.

The “no”s are likely to be wrong as well. Instead, let them put their money where their mouth is and show some commitment before you invest your time and money in a project with no tangible validation of demand.

Don’t show your users two different designs and ask which one they’d prefer using. Instead, let them use both and analyze their actual behavior with each option. Depending on the project and your budget, this can be done with clickable prototypes or as an A/B experiment in actual code.

Explanations of behavior will lead to misunderstandings

Let’s say your users can predict the future and have perfect recall. There’s still a problem with listening to explanations of their behavior. Or reading about it in a Support inquiry for that matter. Misunderstandings.

If you’ve ever tried guiding someone over the phone, to accomplish a task with some kind of digital product, you know what I’m talking about. If you’ve done it over text, without any visuals to support you, wow…

Don’t just listen to or read your user’s explanation of what they do or how they did it. Again, observe them! Let them show you. Let them go through the flow with your product,

let them point at the screen, let them draw on paper. Whatever it takes. Just don’t rely on the spoken or written word to describe something as complex as behavior in a digital world.

Your most vocal users may not be representative

Most types of user feedback happen through invitation, not through a random sampling of all your users. This is true for your Support inquiries, surveys, usability testing, focus groups, user interviews, and so on. This can cause a self-selection bias. The users who choose to engage aren’t necessarily representative of your average user.

Don’t uncritically sample participants for your usability test, interviews, or focus groups. Instead, do your best to segment your user base on relevant criteria beforehand. Sample participants from all your segments or at least be aware of your bias when certain segments aren’t represented.

Don’t take Support inquiries as truth. A very vocal minority can easily make it seem like you just launched the worst redesign in the history of redesigns, even though the 95% actually loves it.

Or that all your users hate the new feature you just launched. Be clear about your success metrics and track them meticulously to gauge your success.

For a great example of this, check out this case study by Gillian Morris, on the launch and scaling of an app called Hitlist.

Key takeaways

Don’t use this to get out of doing user research

Just as Jakob Nielsen’s first rule of usability can be misinterpreted if you don’t read beyond the headline, so can the words of Henry Ford and Steve Jobs who are often quoted by people who think they’re too smart for user research.

“If I had asked people what they wanted, they would have said a faster horse.”- Henry Ford“A lot of times, people don’t know what they want until you show it to them.”- Steve Jobs

There’s no good argument against properly executed user research. Not even quoting these gentlemen.

Apple has always been extremely user-centered. Don Norman, the other half of the Nielsen Norman Group and grandfather of UCD, coined the term “user-friendly” (later “user experience”) in 1982 while working with Apple.

It’s your job to go beyond listening

What both Henry Ford, Steve Jobs, and Jakob Nielsen realized was that you shouldn’t just ask people what they want. You should observe, listen, engage, and get to know their real needs.

Don’t blindly follow their design suggestions and feature requests (I guess a faster horse would fall under the category of performance optimization), or take their word for it when they describe how they use your product.

Don’t twist the words of Henry Ford, Steve Jobs, or Jakob Nielsen to get out of user research.

Learn how to get the feedback you need from your users, and use it to design the best possible product for them. That’s your job — not your users’.

Originally published at techmoneyculture.com on June 23, 2020.