One thing I’ve learned about Voice of Customer research is that customers don’t always have the right words to describe what is wrong.
They might say a workflow is confusing.
They might ask for a new button.
They might say a feature is difficult to use.
But sometimes the most useful insight comes from simply watching them try to accomplish something.
That’s where usability testing becomes a powerful part of Voice of Customer research.
Customers Tell You What They Think
Traditional VoC methods often rely on what customers tell you.
Interviews, surveys, support tickets, and feedback forms can reveal what customers like, dislike, want, or struggle with.
That’s valuable.
But there’s a limitation.
People aren’t always able to accurately explain their behaviour.
A customer might say:
“The reporting feature is difficult to use.”
That’s useful, but it doesn’t tell you exactly where the difficulty occurs.
Are they unable to find the feature?
Do they misunderstand the terminology?
Are there too many steps?
Do they expect something to work differently?
You can learn much more by watching them use it.
Usability Testing Shows the Gap Between Saying and Doing
Imagine asking a customer:
“How easy is it to create a report?”
They might answer, “Pretty easy.”
Then you ask them to create one.
They spend two minutes looking through the navigation, click the wrong option, go back, open another menu, and eventually find the reporting page.
They completed the task.
But you just discovered several usability problems.
This is why usability testing complements VoC so well.
VoC tells you what customers perceive. Usability testing shows you what happens when they act.
Don’t Tell Users How to Complete the Task
One common mistake is turning usability testing into product training.
Instead of saying:
“Click Reports, then select Create Report.”
Give them a goal:
“Imagine your manager has asked you to create a report showing last month’s performance. Please show me how you would do that.”
Then observe.
Where do they hesitate?
What do they click first?
What do they misunderstand?
What do they expect to happen?
Where do they ask questions?
These moments are often more valuable than their final opinion.
Look for Behavioural Signals
During usability testing, pay attention to more than whether the task was completed.
Look for:
- Hesitation
- Repeated clicks
- Backtracking
- Misinterpretation
- Searching
- Skipping
- Asking for help
- Unexpected workarounds
A user doesn’t always need to say, “This interface is confusing.”
Their behaviour can tell you.
If five out of six participants make the same wrong assumption, you’ve probably found something worth investigating.
Connect Usability Problems to Customer Value
Not every usability issue deserves immediate attention.
A minor navigation inconvenience may not matter if users rarely encounter it.
A small amount of friction in a critical workflow might matter enormously.
That’s why usability findings should be connected to the broader customer journey.
Ask:
Does this problem prevent users from reaching value?
Does it increase errors?
Does it slow down an important workflow?
Does it create unnecessary support requests?
This helps distinguish cosmetic usability issues from meaningful product problems.
Combine Usability Testing With Other VoC Sources
Usability testing shouldn’t replace interviews or surveys.
It should complement them.
Imagine your support team receives repeated complaints about a difficult workflow.
Customer interviews tell you that users find the process frustrating.
Analytics show significant drop-off halfway through the workflow.
Usability testing reveals that users repeatedly misunderstand one particular step.
Now you have multiple forms of evidence pointing toward the same problem.
That’s much stronger than relying on any single source.
Don’t Assume the User Is the Problem
When users struggle with a workflow, it’s tempting to think they simply don’t understand the product.
But usability testing should make you question the design before questioning the user.
If several people make the same mistake, the product may be communicating something incorrectly.
A good interface shouldn’t require users to think like the person who designed it.
Turn Observations Into Insights
Avoid documenting findings as:
“Three users couldn’t find the button.”
Go one level deeper.
Perhaps:
“Users expected the reporting workflow to start from the dashboard, but the entry point is located under the administration menu.”
Now you have a potential product problem rather than an isolated observation.
That makes the finding much easier to discuss, prioritize, and act on.
Final Thought
Voice of Customer isn’t only about listenin

Leave a Reply