Designers depend heavily on feedback. It helps validate ideas, uncover problems, and align a product with what users or clients expect. But there is a problem that every designer eventually runs into: people are not always reliable predictors of their own behaviour.
A user may say they love a new feature, promise they would use it every day, and describe it as something that would make their life easier. Then the feature launches, they try it once, and never return.
A client may enthusiastically approve a design during a presentation, only to later discover that real customers barely notice it.
This does not necessarily mean anyone was being dishonest. More often, it means the design process confused what people say they want with what they actually do when faced with real choices.
That difference is one of the most important things designers, product teams and developers need to understand.
The Difference Between Intentions and Behaviour
Imagine asking a group of users whether they would use a new productivity feature.
Most of them respond positively.
They say it sounds useful. They can imagine themselves using it. Some may even describe exactly how it would improve their daily routine.
The product team sees strong feedback and invests months designing, developing and testing the feature.
It launches.
Initial curiosity is high.
Then usage collapses.
The people who said they wanted it simply return to whatever they were doing before.
At first, it is tempting to conclude that the users lied during research.
But that is usually the wrong interpretation.
They probably genuinely believed they would use the feature when they were asked.
The problem is that intention exists in an imaginary future, while behaviour happens in the real world.
And the real world introduces friction, interruptions, established habits, time pressure, competing priorities and dozens of other influences that were absent when the question was originally asked.
Users Are Often Honest — And Still Wrong
One of the biggest mistakes in user research is assuming that inaccurate predictions mean dishonest answers.
People are usually being sincere.
If you ask someone whether they would exercise more if they had access to a gym five minutes from their house, they may genuinely believe the answer is yes.
If you ask whether they would use a feature that automatically organises their files, they may sincerely think it sounds useful.
If you ask whether they care about privacy when choosing an app, most people will probably say they do.
But what people believe about their future behaviour and what they eventually do are not always the same thing.
Humans are surprisingly poor at predicting how they will behave once convenience, habit, emotion and context enter the equation.
For designers, that means feedback should be treated as evidence, not as absolute truth.
Why People Say Things They Don't Eventually Do
There are several reasons why stated preferences often fail to predict real behaviour.
One of the biggest is social desirability.
People naturally want to appear helpful, reasonable and engaged.
Put someone in front of a design team and ask whether they find a new feature useful, and they may feel uncomfortable saying, "I don't care about this at all."
They know somebody spent time designing it.
They may therefore soften their criticism or give a more positive answer simply because they do not want to appear rude.
This happens with clients too.
A stakeholder might approve a concept during a meeting because everyone else seems enthusiastic, only to become uncomfortable with it once the design is actually deployed.
Memory Is Less Reliable Than We Think
Another problem is that people do not remember experiences with perfect accuracy.
Human memory is reconstructive.
We tend to remember moments, impressions and emotions rather than precise sequences of events.
Ask someone how they normally use an application and they may describe what they think they usually do.
Watch them use the application, and the behaviour may be completely different.
They may claim they always use the navigation menu when they actually rely on search.
They may insist a particular button is important even though analytics show almost nobody clicks it.
They may describe a workflow as simple while unknowingly performing several inefficient steps every time.
This is why retrospective interviews can be useful, but they should rarely be the only source of evidence.
People Do Not Always Understand Their Own Decisions
There is also a deeper psychological issue.
People frequently make decisions without fully understanding what influenced them.
Afterwards, they create a logical explanation.
Someone may say they bought a product because it had better specifications.
In reality, the branding, packaging, familiarity or recommendation from a friend may have played a much bigger role.
A user might say they abandoned a page because it did not contain enough information.
Session recordings could reveal that they actually left because the page took too long to load.
These post-hoc explanations are not necessarily deliberate attempts to mislead researchers.
People simply do not have perfect access to every subconscious process influencing their decisions.
For designers, this creates an important distinction:
What users say explains their perception. What users do reveals their behaviour.
Both matter, but they answer different questions.
Mockups Exist in an Artificial World
Another major source of inaccurate feedback is what could be called the abstraction problem.
Users are often very good at reacting to something directly in front of them.
Show someone three button styles and they can tell you which one they prefer.
Ask them how they would behave six months from now if an entirely new workflow existed, and the answer becomes much less reliable.
This is why beautiful mockups can sometimes receive overwhelmingly positive feedback while the finished product performs poorly.
A mockup exists without waiting times, interruptions, notifications, deadlines or competing tasks.
The real product does not.
During a design presentation, users focus entirely on what is being shown to them.
In everyday life, your product may be competing with emails, phone calls, social media, meetings and dozens of other distractions.
A feature that looks wonderful in isolation may simply not be important enough to earn attention in the real world.
Habit Is More Powerful Than Good Design
One of the strongest forces influencing behaviour is habit.
Designers often underestimate how difficult it is to persuade users to abandon established workflows.
A new feature may technically be better.
It may require fewer clicks.
It may produce better results.
It may even be objectively easier to use.
None of that guarantees adoption.
If users have been performing a task the same way for five years, changing that behaviour requires effort.
Humans frequently prefer a familiar, slightly inefficient method over an unfamiliar method that is theoretically superior.
That is why simply making something "better" is not always enough.
Good product design also has to consider how much behavioural change it is asking from the user.
Friction Quietly Kills Good Ideas
Another powerful factor is friction.
Every additional click, form field, confirmation screen or decision creates a small cost.
Individually, those costs may seem insignificant.
Together, they can completely change behaviour.
Consider a feature that requires users to navigate through four screens before they can access it.
During a usability test, participants may happily complete the process because they were specifically asked to do so.
In normal life, many of them may decide that the feature simply is not worth the effort.
They may not consciously think, "This workflow contains excessive friction."
They just stop using it.
This is why behavioural metrics can reveal problems that interviews often miss.
Users may describe something as useful while their actions quietly demonstrate that the effort required exceeds the perceived value.
Context Changes Everything
People also behave differently depending on where and when they are using a product.
A participant sitting quietly in a usability laboratory has plenty of time to study a screen.
The same person using the product at work may be dealing with three phone calls, an impatient customer and a meeting starting in five minutes.
A banking interface tested comfortably at home may feel completely different when someone is standing in a crowded shop trying to make a payment quickly.
A healthcare system used during a controlled demonstration may behave very differently once nurses and doctors are dealing with real clinical pressure.
This is why contextual research can be so valuable.
Understanding where a product is used can sometimes reveal more than asking users what they think about it.
The Environment Shapes Behaviour Too
Behaviour does not happen in isolation.
Physical and social environments influence how people interact with products.
A feature might work perfectly for one employee but fail completely for another because their organisation has different policies.
A mobile application may be easy to use indoors but frustrating under bright sunlight.
A collaborative feature may look appealing during testing but never get adopted because nobody wants to be the first person on the team to change the established process.
Tools, workplace culture, hardware availability, network conditions and even the people surrounding the user can all affect behaviour.
Design research becomes much stronger once these environmental factors are considered.
Stop Treating Interviews as Predictions
None of this means designers should stop talking to users.
Interviews remain extremely valuable.
The mistake is expecting them to predict behaviour with perfect accuracy.
Ask users about their problems.
Ask what frustrates them.
Ask how they currently complete a task.
Ask them to explain what happened the last time they encountered a particular situation.
Those questions are grounded in real experiences.
Questions about hypothetical futures are much weaker.
"Would you use this feature?" sounds useful, but it often produces unreliable answers.
A better approach is to let someone actually try the feature and see whether they naturally return to it later.
Watch What Users Actually Do
Behavioural observation is one of the strongest tools available to designers.
Instead of asking someone whether navigation is confusing, watch them navigate.
Instead of asking whether a button is easy to find, see how long it takes them to locate it.
Instead of asking whether a workflow feels efficient, measure how many attempts it takes them to complete it.
Pay attention to hesitation.
Watch where people repeatedly click.
Notice the shortcuts they invent.
Observe the workarounds they create.
Users often communicate usability problems far more clearly with their behaviour than they ever could through a survey response.
Sometimes the most valuable research moment happens when a user says nothing at all and simply pauses for five seconds because they do not know what to do next.
Measure Behaviour, Not Just Satisfaction
Customer satisfaction scores are useful, but they should not be confused with behavioural success.
Someone can say they love a product and rarely use it.
Another person might complain about an application constantly while depending on it every day.
That is why product teams should combine qualitative feedback with behavioural metrics.
Look at things such as:
These measures tell you what is actually happening.
A survey tells you how users feel about it.
You usually need both.
Prototype Before You Build
One of the best ways to avoid the designer's trap is to test ideas before committing heavily to them.
Do not assume positive survey responses prove that an idea deserves six months of development.
Build something smaller first.
Create a prototype.
Develop a limited version.
Test the workflow with real users.
If possible, expose the feature to a small percentage of the audience and measure what happens.
Every design concept is ultimately a hypothesis.
You are saying:
"We believe this change will cause users to behave in a particular way."
Testing determines whether that belief is actually correct.
The goal of research is not to prove the designer right.
It is to discover whether the assumption survives contact with reality.
A/B Testing Can Reveal What People Cannot Explain
Behavioural testing becomes particularly useful when users struggle to articulate why they prefer something.
Imagine testing two checkout designs.
When interviewed, users may say both are easy.
But version A converts 12% more customers than version B.
That difference matters.
You can investigate why it happened afterwards, but the behaviour itself has already revealed something important.
The same applies to typography, onboarding flows, button positioning, recommendation systems and navigation structures.
People do not necessarily need to explain why one design works better.
Sometimes the data makes the difference clear before the explanation does.
Do Not Blindly Follow Analytics Either
There is an important counterpoint.
Behavioural data is powerful, but it can also be misunderstood.
Analytics can tell you what happened, but not always why it happened.
If users abandon a particular screen, analytics may show the exit rate clearly.
But perhaps the screen is confusing.
Perhaps users already accomplished what they needed.
Perhaps the feature is broken.
Perhaps they were redirected somewhere else.
Behaviour should therefore complement user feedback, not replace it.
The strongest design decisions usually come from combining several sources:
what people say, what people do, and the context in which they do it.
When all three point in the same direction, confidence increases substantially.
Design for Needs, Not Requests
Users are excellent at describing problems.
They are not always equally good at designing solutions.
A customer might say:
"Add another button here."
The underlying problem may actually be that the current navigation structure is confusing.
Another user might request:
"Give me an export-to-Excel feature."
What they may really need is a better reporting system.
If designers simply implement every requested feature literally, products quickly become cluttered.
The better question is:
What problem is this person trying to solve?
Once the underlying need is understood, the design team may discover a completely different solution.
This is one of the reasons experienced designers listen carefully without automatically treating every suggestion as a requirement.
Iteration Turns Observation Into Better Design
No first design is perfect.
And expecting it to be perfect creates unnecessary pressure.
A healthier process treats the first release as the beginning of learning rather than the end of design.
Launch something.
Observe behaviour.
Identify friction.
Change it.
Measure again.
Repeat.
Small behavioural discoveries compound over time.
Maybe users repeatedly miss a particular action.
Maybe they hesitate at the same step.
Maybe a feature that everyone requested is barely touched.
Maybe an unexpected workflow becomes enormously popular.
Those discoveries help shape later versions.
Great products are rarely created from a single brilliant design decision.
They are usually the result of many small corrections guided by real behaviour.
The Designer's Real Job Is Interpretation
The conclusion should not be that users have no idea what they want. That interpretation goes too far. Users understand their goals, frustrations and experiences better than anyone else. What they may not know is exactly which design solution will best address those needs—or how they will behave in a hypothetical future.
That is where the designer comes in. Design is partly an exercise in interpretation. Listen to what users say. Observe what they do. Understand their environment. Identify patterns. Then translate all of that information into a solution. The skill lies in knowing which signals deserve the most weight.
Final Thoughts
The designer's trap begins when feedback is treated as prediction. Someone saying they would use a feature does not mean they will. Someone praising a design does not guarantee they will interact with it. Someone requesting functionality does not necessarily mean that functionality solves their actual problem.
Words remain valuable because they provide context, emotions and explanations. But behaviour reveals what survives the realities of habit, friction, pressure and environment. That is why the strongest design process does not choose between listening and observing. It does both.
Ask users what they think. Watch what they do. Measure what happens. Test your assumptions. Then iterate.
Because ultimately, good design is not about building what people say they want. It is about understanding what they genuinely need—and designing something useful enough that their behaviour proves it.
Comments 0