The research session went brilliantly.
Participants liked the idea. Several said they would use it. One called it “exactly what I need.” Another asked when it would be available.
Three months later, the feature launched.
Almost nobody touched it.
This is one of the more uncomfortable moments in product research because nothing obviously went wrong. The participants were real. The questions seemed sensible. The feedback was positive.
Yet behaviour told a completely different story.
Researchers often call this the say-do gap: the distance between what people report they will do and what they eventually do when the decision becomes real.
Understanding that gap is one of the most useful skills a ux researcher can develop.
Why Do Users Say One Thing and Do Another?
Usually, people are not lying.
The problem is that answering a research question and making a real-world decision happen under completely different conditions.
Imagine asking someone:
“Would you use a feature that automatically categorises your monthly spending?”
Sitting in an interview, the idea sounds useful.
Of course they want to understand their spending better.
But using the feature later might require connecting another bank account, reviewing categories, correcting mistakes and remembering to return every week.
Now usefulness is competing with effort.
That effort did not exist when the question was asked.
People are often good at describing frustrations they have already experienced. They are much less reliable when predicting their own future behaviour.
“Would You Use This?” Is Usually a Weak Research Question
It feels like the most direct question possible.
Unfortunately, it often produces very little useful evidence.
Someone looking at a concept knows a researcher has spent time creating it. They may want to be supportive. The feature may also sound sensible in isolation.
“Yes, I would use that” costs nothing.
Actually using it might cost time, attention, money, learning or a change in routine.
Those costs change behaviour.
A better user researcher will usually move away from hypothetical enthusiasm and towards past behaviour.
Instead of asking:
“Would you use a tool that helps organise your household bills?”
Try:
“Tell me about the last time you had to organise all your household bills.”
Then keep going.
Where were the bills stored?
What did they do first?
Did anyone else need access?
What went wrong?
Which tools did they use?
Did they create a workaround?
Past behaviour is not a perfect prediction of future behaviour either, but it usually gives the researcher something firmer than imagined intent.
People Like Ideas That Do Not Survive Their Real Lives
Many products test well because the research environment removes everyday inconvenience.
Consider a meal-planning app.
During an interview, a participant might love the idea of planning five dinners every Sunday. They like the healthier choices, lower grocery spend and reduced decision-making.
Then Sunday arrives.
One child refuses pasta.
Someone is working late on Tuesday.
There are leftovers from Saturday.
Nobody knows what Thursday will look like.
Takeaway wins.
The participant did not deceive the researcher. The concept collided with real life.
This is why context matters so much.
A good user experience researcher is not only interested in whether someone understands or likes an idea. They want to know whether the idea can survive the person's routines, competing priorities and existing habits.
Compliments Can Be Surprisingly Dangerous
Positive feedback is pleasant to hear, which makes it easy to overvalue.
“This looks great.”
“I love how simple this is.”
“I would definitely try it.”
None of these statements are useless. They are simply not behavioural evidence.
A participant can genuinely think an interface looks excellent while having no meaningful reason to use the product.
This becomes particularly risky during concept testing. Teams sometimes count positive reactions almost like votes.
Eight out of ten participants liked Concept B.
Concept B wins.
But what did “liked” actually mean?
Did participants understand it faster?
Would it solve a problem they currently experience?
Would they switch from their existing method?
Was anything valuable enough to justify changing behaviour?
Those are harder questions, but they are closer to the product decision.
Watch What People Already Do When Nobody Is Asking
Some of the richest research comes from ordinary behaviour.
A team building an expense-management platform might hear employees say they want powerful expense categorisation.
Observation could reveal something else.
Employees photograph receipts immediately because losing them is their real worry. They submit expenses late because they cannot remember which project code to select. Managers keep separate spreadsheets because the approval view does not show enough context.
Suddenly, “better categories” may not deserve top priority.
This is where experienced UX research becomes especially valuable. Interviews can uncover motivations, but usability testing, behavioural analysis, diary studies and journey research can show how those motivations survive contact with real tasks.
A ux researcher needs both sides of the story.
The Say-Do Gap Can Appear Inside Usability Testing Too
It is tempting to think observation automatically solves the problem.
Not always.
A participant completing a task in a research session knows they are being observed. They may spend longer trying to understand something than they would at home.
In real life, they might simply leave.
They may also behave more carefully because they know the session is about the product.
Suppose a participant spends two minutes successfully locating a setting buried inside an account menu.
Technically, the task was completed.
But would a real customer spend two minutes looking for it?
Maybe not.
This is why task completion should not be the only thing a user experience researcher watches.
Hesitation matters.
Backtracking matters.
Repeated reading matters.
The sentence “I guess I would click here” matters.
Sometimes success during testing contains evidence of failure.
Research Should Separate Preference From Commitment
There is a useful difference between:
“I like this.”
and:
“I would change something I already do because of this.”
Product teams often need the second answer.
Imagine a new subscription dashboard that automatically recommends ways to reduce monthly costs.
People may love the concept.
But would they connect all their subscriptions?
Would they provide financial access?
Would they cancel services based on its recommendations?
Would they return next month?
Each step introduces a different level of commitment.
A user researcher should therefore look for what has to change in the person's current behaviour before the proposed experience can succeed.
If adoption requires five new habits, positive feedback alone should make the team cautious.
How Can UX Teams Reduce the Say-Do Gap?
Ask About the Last Time, Not the Imaginary Next Time
Specific memories usually reveal more than hypothetical questions.
“Tell me about the last time you booked a doctor” will often uncover more useful detail than “What would your ideal healthcare booking app include?”
Look for Existing Workarounds
Workarounds are valuable because they show that a problem matters enough for someone to do something about it.
Spreadsheets, screenshots, WhatsApp messages, notes taped to monitors and strange manual processes can all be stronger signals than stated feature preferences.
Add a Cost to the Question
If somebody says they would use a service, explore what using it actually requires.
Would they pay?
Create an account?
Upload documents?
Change providers?
Ask their manager?
Use it every week?
Intent becomes more realistic when consequences appear.
Compare What People Say With Product Data
Interviews explain why something may be happening.
Behavioural data can show whether it happens at scale.
Neither should automatically replace the other.
The useful insight often appears when the two disagree.
FAQs About the Say-Do Gap in UX Research
What is the say-do gap?
The say-do gap is the difference between what people say they believe, prefer or intend to do and how they behave when facing the real situation.
Does the say-do gap mean user interviews are unreliable?
No. Interviews are excellent for understanding experiences, motivations, expectations and meaning. Problems arise when hypothetical answers are treated as reliable predictions of future behaviour.
What should a UX researcher ask instead of “Would you use this?”
Ask about recent, specific behaviour. Questions such as “Tell me about the last time you did this” usually produce more useful evidence.
Can usability testing reveal the say-do gap?
Yes, particularly when researchers watch hesitation, mistakes and workarounds rather than focusing only on task completion. However, testing itself is still an artificial environment.
Which research methods help reveal actual behaviour?
Contextual research, diary studies, usability testing, analytics, behavioural observation and longitudinal research can all provide evidence that complements interviews.
Why does positive concept feedback sometimes fail to predict adoption?
Liking an idea requires very little commitment. Adoption may require effort, trust, payment, habit change or abandoning an existing solution. Those pressures often appear only after launch.
When Behaviour Disagrees With Feedback, Pay Attention
Users saying they love an idea is not bad news.
It simply is not the end of the research.
The interesting work starts when a researcher asks what that enthusiasm means in the context of someone's actual life.
Will they make room for the product?
Will they change an existing habit?
Will they trust it with something important?
Will they still choose it when another option is faster, cheaper or already familiar?
Good UX research does not treat people's words as irrelevant. It puts those words beside behaviour and looks carefully at the distance between them.
Because sometimes the most valuable research finding is not:
“Users loved it.”
It is:
“Users loved it, but here is why they still would not use it.”
That is the insight product teams can actually build around.
Sign in to leave a comment.