.png)
Ask your customers what they want from your website and they will give you an answer. It will sound reasonable, it will often be delivered with conviction and it will frequently be wrong. They are not being dishonest. People are poor predictors of their own behaviour, and when asked a hypothetical question about a website, they answer with what sounds sensible rather than with what they would do.
A survey might come back saying customers want a more modern design, more detailed product information and a live chat. Watch the same customers use the site and you may find they never scroll past the first screen of product detail, they abandon at the shipping cost and they ignore the chat entirely. The survey describes the website they imagine they would use. The behaviour describes the one they do use, and that is the one producing your revenue.
For an established business planning a redesign or a round of improvements, the gap between what customers say and what they do is where most wasted budget goes. Building to stated preference produces a site that tests well in a meeting and underperforms in the market. Building to observed behaviour produces a site that answers the questions buyers have at the point they have them.
Why stated preferences mislead
Researchers call the two kinds of evidence stated preference and revealed preference. Stated preference is what people tell you. Revealed preference is what their choices show. The two diverge for predictable reasons, and knowing them helps you read feedback without dismissing it.
People describe solutions instead of problems
A customer who says "I want better filters" has a problem finding the right product. Filters are one possible answer, and better search, clearer category names or fewer, more distinct products might solve the same problem with less work. Treat every feature request as a clue to an underlying problem, then go looking for evidence of that problem.
People answer for an idealised version of themselves
Asked whether they read product specifications, most buyers will say yes. In practice, many scan for two or three facts and move on. Asked whether they would use a comparison tool, people imagine a careful, methodical version of their own shopping that seldom matches the hurried reality of buying on a phone between meetings.
The loudest feedback comes from the least typical customers
The customers who reply to surveys and email suggestions are more engaged than average. Their needs are real, but they are not representative. A request from one articulate repeat customer can carry more weight in a planning meeting than the silent behaviour of thousands of first-time visitors who left without buying.
Where the behavioural evidence lives
Most established businesses already hold more evidence about what customers do than they use. It is spread across systems and teams, and nobody has put it together in one place before a redesign.
Analytics
Exit pages, scroll depth, time on page and the paths visitors take through the site show where interest builds and where it drops away. Compare pages that convert well with pages that do not, and compare mobile with desktop. If the most visited product category has the lowest add-to-cart rate, that category needs attention before anything a survey suggested.
Session recordings and heatmaps
Tools that record anonymised sessions show what analytics cannot: the visitor who taps an image three times expecting it to enlarge, the one who scrolls up and down looking for the delivery cost, the form field that causes people to pause and leave. Watch twenty recordings of sessions that reached a key page and did not convert. Patterns appear quickly, and they are almost always more specific than anything a customer would think to report.
Site search
What visitors type into your search box is the closest thing to a customer telling you what they want in their own words, at the moment they want it. Searches that return no results show gaps in the range or in the naming. Frequent searches for information such as delivery times or returns show content that should be easier to find.
Support tickets and sales enquiries
The questions customers ask your support team are questions the website failed to answer. Export a few months of support emails and chat logs, group them by topic and count them. If a large share asks about shipping to Australia or about returns, the answer belongs on the pages where buyers make that decision as well as on the policy page linked from the footer.
Ask better questions
Talking to customers still matters. The value comes from asking about what they did rather than what they would do. "Tell me about the last time you bought something like this" produces far better evidence than "What would you like to see on our website?"
Ask recent buyers how they found you, what else they considered, what nearly stopped them and what finally made them decide. Ask people who enquired and did not buy what they chose instead and why. Those answers describe real decisions with real trade-offs, and they will tell you which information mattered and where it needed to be. Five or six of these conversations will tell you more than a survey of several hundred customers asked to rate features they have never used.
Run small tests before big changes
When the evidence points to a change, test it before rebuilding around it. Show one version of a product page to half your visitors and a different version to the other half, and measure which produces more purchases or enquiries. Keep tests focused on one change at a time, and run them long enough to cover a normal buying cycle.
Tests settle arguments that opinion cannot. A stakeholder convinced that buyers want long brand stories, and a sales manager convinced they want specifications, can both be right for different segments, and a test shows which matters more on which page. Our piece on why small details beat big redesigns covers how much can be learned and fixed through changes of this size.
The mistakes that come from building to stated preference
Adding features because they were requested
Every feature added to a site takes space, adds code and adds something for the team to maintain. A complex filtering system built because a handful of customers asked for it may go almost unused, while making the page slower and harder to scan for everyone else. Check how people find products now before adding a new way to do it.
Following trends no customer asked for
Live chat, recently-purchased notifications and pop-up offers are often added because competitors have them. Each one should be judged on its effect on your own buyers. Some help, some add clutter and some slow the site enough to cost more sales than they win. The same applies to recommendation features, which work when they are relevant and well chosen, as our guide to website personalisation sets out.
Solving the wrong problem
Customers say the checkout is frustrating, so the business funds a full checkout redesign. The analytics, had anyone looked, would have shown buyers abandoning at the step where a shipping cost first appears. Showing that cost earlier on the product page, or changing the free shipping threshold, would have addressed the real cause at a fraction of the cost.
Prioritise by evidence
Once you have a list of possible changes, rank each one on three things: the size of the commercial effect if it works, the strength of the evidence that the problem exists and the effort required. Changes with strong evidence, a meaningful commercial effect and modest effort go first. Changes supported only by a stated preference, with no behavioural evidence behind them, wait until the evidence appears.
That ranking also gives you a defensible answer when a stakeholder or a vocal customer pushes for something. The request goes on the list and gets the same scrutiny as everything else. If the evidence supports it, it moves up. If it does not, it waits, and the reason is on the page for everyone to see.
Bring the evidence into the project brief
A redesign or an ecommerce build starts with a brief, and the brief is where stated and revealed preference either get separated or get mixed together. Bring the analytics, the search data, the support themes and the notes from customer conversations into the first workshop, and flag which requirements come from evidence and which come from opinion. Our account of how we scope a website project shows where that evidence fits into discovery, and our guide to UX and UI design for conversion covers how it shapes the pages themselves.
Common questions
Why don't customer surveys tell me what to change on my website?
Surveys capture stated preference: what people believe they want or would do. People are poor predictors of their own behaviour and tend to describe solutions instead of problems. Surveys are useful for spotting themes, but changes should be backed by behavioural evidence such as analytics, session recordings, site search data and support tickets before you spend money building them.
What is the difference between stated and revealed preference?
Stated preference is what customers tell you they want, through surveys, interviews or feedback. Revealed preference is what their actual choices show, such as the pages they visit, the products they buy and where they abandon. When the two disagree, revealed preference is the better guide to what will change revenue, because it reflects decisions people made with real money.
How can I see what users actually do on my website?
Start with your analytics: exit pages, paths through the site and conversion by device. Add a session recording and heatmap tool to watch anonymised visits, and review your site search terms for what visitors look for in their own words. Support emails and chat logs then show which questions the site failed to answer for people who were close to buying.
How many customer interviews do I need before a redesign?
Five or six well-run conversations with recent buyers and lost prospects will surface most of the important themes, provided you ask about real past decisions rather than hypothetical preferences. Ask what they considered, what nearly stopped them and what made them decide. Combine those conversations with behavioural data so you are not relying on a small number of voices alone.
Should I ignore what my customers ask for?
No, but treat them as clues. Customer requests point to real problems, even when the suggested solution is not the right one. Record every request, work out the underlying problem and look for behavioural evidence that it affects buyers at scale. If the evidence is there, solve the problem in the simplest way that works, which may look quite different from the feature the customer suggested.
