A surprising number of website changes begin with a solution before anyone has properly defined the problem.
Someone thinks the headline sounds weak. The pricing page feels crowded. The call-to-action button needs stronger wording. A competitor has added a comparison table. A manager wants the testimonials moved higher up the page.
Any of those suggestions could turn out to be useful. But none of them, on its own, is a good reason to change the website.
They’re ideas for solutions. What’s missing is the diagnosis.
That’s where teams often get stuck in a cycle of constant activity without much useful learning. Pages are rewritten, redesigned and rearranged, but nobody becomes much clearer about why customers are behaving the way they are.
A website change should have to earn its test.
Before a proposed change is built, approved or tested, it should answer three questions:
- What specific customer problem are we trying to solve?
- What observable behaviour suggests that problem is real?
- What measurable outcome would tell us the change helped?
If those answers aren’t clear, you probably don’t have a test yet. You have a preference.
Consider a suggestion such as, “Let’s make the call-to-action stronger.” It sounds reasonable, but it hides several possible problems.
Maybe the wording is unclear. Maybe visitors don’t notice the button. Perhaps they see it but don’t understand what happens next. They might be interested but hesitant because the next step feels too risky. Or they may already be clicking and then abandoning the process later.
Those are different problems. They would require different responses.
If you jump straight to rewriting the button, you’re making an assumption about which problem exists before you’ve checked whether that assumption holds up.
Start with the customer problem
A useful problem statement describes friction, uncertainty, confusion or mismatch from the customer’s point of view.
“The pricing page needs work” doesn’t do that.
Neither does “conversion is low”. That tells you something about the result, not the cause.
A more useful statement might be:
“Visitors reach the pricing page but can’t tell which package is right for them.”
Now the problem is specific enough to work with. You’re no longer debating whether the design should look cleaner or whether a competitor’s layout is more appealing. You’re trying to understand whether a qualified visitor can make a confident choice.
The solution might eventually be clearer package names, a comparison table, a short “best for” explanation beneath each option, or something else. But those are possible responses to the problem. They shouldn’t be where the thinking starts.
The next step is to look for behaviour that supports the diagnosis.
Customer problems are easy to imagine, especially when a team has been looking at the same website for months. Observable behaviour gives you something firmer to work with.
If you suspect people are confused by the pricing options, what might that confusion look like?
Visitors could move back and forth between package descriptions. They might spend time on the page but leave without choosing anything. They may repeatedly open FAQs about the differences between plans. Sales enquiries might include the same question again and again: “Which package do I need?”
None of those signals proves the diagnosis on its own. But together, or in the right context, they give you evidence worth investigating.
This is where another distinction becomes useful: the metric is not the problem.
A low conversion rate tells you that fewer people are completing an action than you want. It doesn’t tell you why.
Clicks, scroll patterns, abandoned forms, customer questions, session recordings and funnel drop-offs are clues. Their value comes from whether they support or weaken a specific explanation.
Imagine a web consultancy selling a fixed-price website package to small businesses.
Someone suggests changing the homepage headline from:
“Websites That Grow Your Business”
to:
“A High-Converting Website Built For Your Small Business”
The second version may sound more specific. The team may even prefer it immediately. But preference isn’t enough.
Now imagine a different situation. Sales conversations regularly reveal that small-business prospects assume the consultancy mainly works with larger companies. The site uses enterprise-style language and showcases complex projects, so smaller businesses aren’t always sure the service is meant for them. Analytics also show that people reach the homepage but relatively few continue to the small-business package.
That gives the headline change a much clearer purpose.
The problem is no longer, “Our headline could be better.”
It becomes:
“Small-business prospects may not recognise quickly enough that this service is intended for businesses like theirs.”
The observable behaviour could include prospects asking whether the company works with small businesses, limited movement from the homepage to the relevant service page, or visitors viewing portfolio content without progressing towards the offer.
Now there’s something worth testing.
The hypothesis could be expressed plainly:
“If we make the intended customer more explicit in the opening message, more qualified small-business visitors should recognise the offer as relevant and continue towards the appropriate service.”
That changes the nature of the test.
You’re not simply comparing two headlines to see which one gets more clicks. You’re testing an explanation about recognition and relevance.
If the new version performs better, you’ve learned something useful about the message. If it doesn’t, that’s still informative. Perhaps the diagnosis was wrong. Perhaps the real issue sits in the offer, proof, traffic source or package positioning.
Either way, the reasoning survives the result.
Decide what evidence would count
The third part of the process is the measurable outcome.
This is where vague goals usually need tightening.
“Improve engagement” isn’t specific enough.
“Make the page clearer” isn’t either.
“Build more trust” may be a worthwhile goal, but only if you can identify behaviour that would reasonably suggest trust has improved.
In the small-business homepage example, a useful primary outcome might be a higher proportion of qualified homepage visitors continuing to the relevant service page or enquiry flow. You might also watch whether basic questions about eligibility become less common.
The goal isn’t to measure everything that moves. It’s to decide, before you make the change, what evidence would make your explanation more or less believable.
That discipline matters because results are easy to rationalise afterwards.
If you can’t say what success would look like before the test, there’s a fair chance the problem hasn’t been defined clearly enough.
The same reasoning applies to smaller changes.
Suppose someone says, “We should shorten the enquiry form.”
That may be sensible. But first ask what customer problem the shorter form is supposed to solve.
“People don’t like long forms” is still an assumption.
What behaviour supports it?
Perhaps analytics show a sharp drop between starting and completing the form. Session recordings show visitors leaving when they reach a cluster of detailed project questions. Sales staff report that some prospects choose to phone instead because they don’t want to provide so much information before they’ve spoken to someone.
Now the problem becomes more useful:
“Qualified prospects are being asked for more project detail than they’re ready to provide at the first-contact stage.”
A suitable outcome might be more completed enquiries without an unacceptable drop in enquiry quality.
That last part matters.
A shorter form may increase the number of submissions while creating another problem by generating more poorly qualified leads. A useful test doesn’t only ask whether the headline number improved. It also asks whether the change produced the behaviour you wanted without introducing a trade-off that makes the result less valuable.
The practical sequence is simple:
Customer problem → observable behaviour → measurable outcome.
It gives teams a way to think before they start changing things.
It also makes internal discussions much easier.
If someone says, “Move the testimonials above the pricing,” there’s no need to argue about taste. Ask what customer problem the move is intended to solve.
Perhaps the reasoning is that visitors are seeing the price before they’ve seen enough proof to feel confident.
Fine. What behaviour suggests that?
Maybe prospects repeatedly ask whether the service has worked for businesses like theirs. Perhaps visitors leave the pricing page and return to case studies before enquiring. Maybe sales calls regularly have to establish credibility that the website should have built earlier.
Now the suggestion has a basis.
If there’s no evidence of that problem, the idea doesn’t have to be dismissed as bad. It simply hasn’t earned priority.
The same rule helps when competitors start influencing the conversation.
A competitor may add a calculator, quiz, sticky button or live chat feature. You can see what they added. What you usually can’t see is the customer problem, evidence and reasoning behind the decision.
Their customers may behave differently. Their offer may create different objections. Their buying process may require different information.
Copying the visible feature without knowing whether you share the underlying problem is how websites become cluttered.
Instead of asking, “Should we have this too?”, ask:
“Do we have evidence of the customer problem this feature appears to solve?”
That question shifts the website from being something you decorate into something you diagnose.
Every page asks a visitor to do something mentally or physically. They need to understand, believe, compare, choose, continue or act. When one of those decisions breaks down, the job is to find the friction and test a reasonable explanation for it.
That means one of the most useful optimisation skills isn’t coming up with more ideas. It’s knowing which ideas don’t yet deserve time.
So when the next website suggestion appears, don’t start by deciding whether it sounds good.
Ask three things: What customer problem is this meant to solve? What behaviour suggests that problem is actually happening? What measurable outcome would tell us we improved it?
If those answers are clear, the change has earned its test.
If they aren’t, the next step isn’t redesign. It’s investigation.
Try This With AI
Use the AI you’re already using: ChatGPT, Claude, Gemini, Grok, Meta AI, Copilot, or another general-purpose AI assistant. Replace the example information inside the brackets with your own information, then copy and paste the complete prompt into your AI.
AI Prompt
