"Actions speak louder than words."

There is no truer statement than that when it comes to user research. In fact, the number one rule of usability is, "Don't listen to users!"

However, as with most user research (e.g. 5 participants per segment), there is a caveat. You can't just listen to our users; you have to observe them as well.

For example, imagine you're a researcher at an e-commerce company that sells model trains to customers around the world (my fiance collects model trains, so I had to feature them at some point). The designer you work with approaches you with a few designs to test out. They want to know which of the designs users prefer so they can iterate on the next steps. The designer has based these initial ideas on previous research where users have asked for specific ideas and functionality.

There are a few problems with this scenario:

• You shouldn't ask users about preference.
• Basing designs on what users believe they want can lead to poor usability and experience.

However, I have seen researchers approach a similar project with qualitative methods. They ask participants what they think of the designs and then guide the teams with these answers.

What's wrong with this? Again, don't listen to your users! Or, as Jakob Nielsen claims, "More precisely, don't do what the customers SAY that you should do."

Why you shouldn't do what your users say you should

There are many reasons why we don't put designs in front of users and ask them to swipe "like/dislike" as one might do on Tinder. If we could do this or ask users what they want and be successful, there would be no need for user researchers, designers, or product teams!

For us who work in the field, we can't blindly listen to our users because:

Users aren't designers

Just as I wouldn't go to my hairdresser and ask her to fix my computer, I wouldn't expect a user to solve a problem. Instead, when users request or suggest features, pivot your mindset to better understand the underlying problem the user is having.

For instance, if a user asks for a feature that allows them to search for trains by budget, I would dig to understand the problem they are trying to solve with that suggestion, rather than taking the solution.

Your job is to uncover and understand what sparked the idea or suggestion, and then you can go into solution mode.

Users can't accurately predict future behavior

51 million Americans waste $1.8 billion on unused gym memberships. About 67% of people who sign up for the gym don’t go, yet they still signed up.

They had every intention of going, but they didn’t. They failed to predict their future behavior correctly.

This is why, as user researchers, we never ask about the future. The only thing that can predict the future is the past.

Users can misrepresent their behavior

People have terrible memories. We can often misremember what and why something happened.

It is fine to ask users about stories to get their perception of an event. But when it comes down to how they interacted with an app/website/product, ask them to show rather than tell.

When users show you what happened, it will jog their memory and enable you to observe what really went wrong.

Users sometimes don't know what they want

Although they are happy to give you their opinion, participants don't know what they want. They don't understand usability metrics or design principles—and they shouldn’t. They’re not the experts and don't need to understand the possibilities of what you could build for them.

They want something that works easily, effectively, and efficiently. What could this be? It's up to you to uncover the pain points people are encountering and then brainstorm how to solve these in the best way.

Users want to give you a nice answer

This doesn't always happen, but many users want to give you a nice answer. This behavior is due to social desirability bias (and other cognitive biases).

If you ask a participant if they like or would use a prototype, they know you are looking for a "yes." Who would want to hear a "no?" In this case, they will say yes, you will invest your time and effort, and there is a good chance people will never use or buy that product.

Users may make up stories to explain their behavior

"I didn't buy it because I realized I didn't need it." Sure, this may be the case, but it might not represent the full truth.

Users may become dissuaded from using your app/website/product because of a poor user experience. However, you wouldn't know this unless you ask them to show you their last experience, versus just believing their last recall.

Users may be outliers

User research can lead to self-selection bias.

Generally, you ask people to participate in research for an exchange, and those who do are typically more engaged. Be sure to not just listen to the people screaming the loudest, but consider speaking with and observing all types of users.

Bonus points for recruiting people who aren't current users and watching them try to use your product for the first time!

Users might falsely rationalize behavior

I have heard participants say, "Oh, if that button were a different color, I definitely would have seen it!" So then, should you make the button bright pink? Most likely not.

The point is, the user didn't see the button. You can then choose how to solve that problem by brainstorming a few different ways and continuing with usability or A/B testing.

Observe instead!

We aren't doomed in the scenario above. There are ways you can get information without asking for preference or exact solutions from your users:

1. Run a moderated usability test
2. Run an unmoderated usability test
3. Use a tool like HotJar or FullStory to view live recordings
4. Run an A/B test
5. Conduct a diary study (with a lot of screen recordings, videos, and photos)

Honestly, the best and easiest way to observe users comes down to usability testing. With usability tests, you ask participants to complete the most important and crucial tasks on your website or app.

When you give users something to work with, they can show you exactly how they would (or have) completed these important tasks. This concrete evidence greatly reduces the uncertainty and risk from just listening to users or asking them what they want.

Alternatively, if you don't want users to complete a list of tasks, you can use the "walk the store" methodology. I utilize this method by asking users to "walk me through the last experience you had on our website, step-by-step." Together, we start at the beginning and go through each aspect of the website/app they interacted with and talk through the experience. This is one of my favorite methods and is a mix of usability testing and contextual inquiry.

Watching people perform certain actions and behaviors helps you understand what they would do in a real-life context. If you are confused about what they are doing, you can always follow-up with why to better understand the context. However, you may be surprised to find that some people don't know why they have acted in a certain way, which is why it is even more important to observe!

If you want to go a step further, I would recommend using website/app data and usage analytics to triangulate your qualitative research findings. What does this mean? If you see participants are struggling on a certain area of your product during a usability test, looking into usage data to see if you can find further evidence, such as a high bounce rate or error rates.

Either way, don't just listen to what they have to say! By listening and observing, you generate insights that can truly lead to a fantastic user experience.