Your Website Doesn’t Need More Best Practices. It Needs More Experiments
There is no shortage of advice about what makes a website convert.
Shorten the form. Put the CTA above the fold. Use fewer navigation options. Add social proof. Make the button more noticeable. Simplify the checkout. Personalize the experience.
Some of that advice is good. Some of it is probably even right for your website.
But “probably” is doing a lot of work there.
Best practices are built from patterns. They tell us what has worked across other websites, audiences, industries, and situations. They can help us spot potential problems and give us useful places to start.
What they can’t tell us is whether the same change will work for your customers, on your website, in this particular moment.
That’s where experimentation changes the conversation.
Instead of asking, “What’s the best practice?” you can start asking, “What do we think will make this experience better, and how could we find out?”
That distinction matters because even experienced teams are often wrong about what customers will respond to. In Optimizely’s analysis of more than 127,000 experiments, only 12% produced a statistically significant improvement on the primary metric.
At first, that number can sound like an argument against experimentation. Why test if most experiments aren’t going to produce a measurable win?
We think it makes the opposite case. If most reasonable-sounding ideas don’t meaningfully change customer behavior, testing becomes one of the best ways to find out which ideas are actually worth implementing.
It also makes a strong case for being thoughtful about what you test. Optimizely found that experiments with four variations delivered 3.5 times the expected impact of a typical A/B test, while experiments combining three or more types of changes produced the strongest gains. In other words, running more small tests isn’t necessarily the answer. Testing meaningful ideas, tied to meaningful questions, gives experimentation a much better chance of producing useful results.
That’s not an argument against expertise. It’s an argument for using expertise to develop stronger hypotheses, then giving those hypotheses a way to be tested.
At Anala, we don’t think that means best practices are useless.
We use them. We recommend them. We look for patterns in UX, conversion behavior, content, analytics, and customer journeys because experience gives you a much better starting point than guessing.
But a starting point isn’t proof.
And when an assumption could lead to a meaningful investment of time, budget, or development resources, we think it deserves more scrutiny than “this is the best practice.”
The problem begins when a best practice turns into a rule. “People don’t read.” “Shorter forms convert better.” “Nobody clicks that far down the page.” “This is how SaaS websites do it.” Suddenly, something that should have helped generate a hypothesis is being used to end the conversation.
We think your website should do the opposite.
It should give you a place to question assumptions, test meaningful ideas, learn from real behavior, and use what you discover to make the next decision better.
That doesn’t mean testing every button color or refusing to make an obvious improvement until it survives an A/B test. Experimentation isn’t useful because it makes every website decision more complicated.
It’s useful because it gives you a better way to handle the decisions where you don’t actually know the answer yet.
And there are probably more of those than most of us would like to admit.
1. Best Practices Are Clues, Not Conclusions
Best practices exist for a reason.
If years of usability research show that people expect a logo to take them back to the homepage, you probably don’t need to run an experiment before making it clickable. If a form asks for information you don’t need, removing unnecessary fields is a reasonable improvement. If your mobile navigation is difficult to use, fixing it isn’t something that needs to sit in a testing queue for three months.
Experience matters. Research matters. Patterns matter.
The mistake is assuming that every pattern is equally applicable to every website.
The Context Behind the Best Practice Matters
Take a common recommendation like “lead with the benefit, not the feature.”
It makes intuitive sense. Customers care about what a product or service can do for them, not simply how it works.
But which benefit?
Speed? Simplicity? Expertise? Cost savings? Control? What if the feature itself is the thing that makes your offer meaningfully different? What if different audiences value completely different outcomes?
Suddenly, “lead with the benefit” isn’t an answer.
It’s a hypothesis.
The same thing happens with plenty of familiar website advice. Long pages are bad. Carousels don’t work. Pricing should always be visible. Navigation should have a certain number of options. CTAs need to appear above the fold.
Each recommendation may be backed by a pattern worth paying attention to. But the moment you apply it to a specific website, you’re introducing context that wasn’t part of the original rule.
Your audience is different. Your offer is different. Your traffic sources are different. Your customer journey is different. The decision you’re asking someone to make may be completely different.
That’s why we think the most useful question isn’t “Is this a best practice?” It’s “Why might this work here?”
That question forces you to understand the reasoning behind the recommendation instead of simply copying the recommendation itself.
Know When to Fix and When to Test
This doesn’t mean every website improvement needs an experiment.
Sometimes the evidence is already strong enough to act. A broken form should be fixed. An inaccessible interaction should be corrected. Outdated information should be updated. A confusing error message doesn’t need two variations competing for traffic before you make it understandable.
Experimentation becomes more valuable when reasonable people could disagree about what will work better.
Should the page lead with the product or the problem it solves? Would showing pricing earlier help qualified visitors move forward or cause them to leave before they understand the value? Would a shorter form increase meaningful conversions or simply create more low-quality leads?
Those aren’t questions a checklist can answer for you.
They’re questions your customers can help answer through their behavior.
Try This: Turn One Best Practice Into a Question
Find one website recommendation your team has discussed recently.
Instead of writing it as a solution:
“We should lead with the benefit.”
Rewrite it as a question:
“Would leading with the outcome our customers care about most make the value of this offer clearer?”
Then ask what you’d need to observe to answer it.
Would you measure engagement with the page? Clicks to the next step? Completed conversions? Would you need to look at behavior further down the journey to understand whether the message attracted the right people?
You haven’t designed an experiment yet.
But you’ve done something important: you’ve stopped treating someone else’s answer as your conclusion and started turning it into something you can learn from.
That’s where useful experimentation begins.
2. Not Every Question Deserves an Experiment
Once you start questioning assumptions, it’s easy to swing too far in the other direction.
If best practices aren’t proof, should we test everything?
Probably not.
Experimentation takes time, traffic, attention, and resources. More importantly, every experiment has an opportunity cost. While you’re testing whether one change matters, there are dozens of other questions you could be learning from instead.
So the goal isn’t to run as many experiments as possible.
It’s to spend your experiments on questions worth answering.
Start With the Decision, Not the Test
It’s tempting to begin with an idea.
Let’s test a new headline. Let’s try a different CTA. Let’s move the form. Let’s add testimonials.
But before deciding how to test something, ask a more useful question:
What decision will we be able to make differently because of what we learn?
Imagine you’re considering two ways to position a service. One emphasizes speed. The other emphasizes expertise.
That’s not just a headline test. You’re asking a bigger question about what customers value when they’re deciding whether to work with you.
If one message clearly resonates more, that learning could influence more than the page you’re testing. It might shape campaign messaging, sales conversations, email content, or how you talk about the service elsewhere on the website.
That’s a much more valuable experiment than changing a button from “Get Started” to “Learn More” simply because you can.
At Anala, we think the best experiments earn their place by helping you make a better decision afterward.
Look for Uncertainty With Consequences
The most interesting experiments often sit where two things overlap:
You’re not sure what will work, and the answer matters.
Maybe you’re unsure whether visitors need more information before they’re ready to convert. Maybe two teams have different opinions about how an offer should be positioned. Maybe analytics show a meaningful drop-off, but you don’t know what’s causing it. Maybe you’re planning a larger redesign and want evidence before committing to a particular direction.
Those are useful places to experiment because the learning can change what you do next.
Compare that with a test where the outcome won’t meaningfully affect a decision.
If Version A wins, what happens?
If Version B wins, what happens?
If the honest answer is essentially the same thing either way, the experiment probably isn’t a priority.
Bigger Changes Can Create Better Learning
Website experimentation has a reputation for being about tiny changes.
Button colors. Headline wording. CTA placement.
Small changes can absolutely matter, especially on high-traffic experiences where even a modest improvement has meaningful business value.
But small isn’t automatically smart.
Sometimes the more useful question requires testing a bigger idea. You might compare two different ways of explaining an offer, change the amount of information provided before a form, reorganize an important part of the journey, or test whether visitors respond better to a completely different value proposition.
Those experiments may require more effort, but they can also teach you more.
The size of the change should match the size of the question you’re trying to answer.
Try This: Give Your Experiment a Reason to Exist
Take one experiment your team is considering and answer three questions:
What are we uncertain about?
What will we learn if we test it?
What decision could that learning change?
If you can answer all three clearly, you probably have the beginning of a useful experiment.
If you can’t, don’t start by designing more variations.
Start by finding a better question.
Because the goal of experimentation isn’t to prove that your team is testing.
It’s to learn something valuable enough to change what you do next.
3. A Good Experiment Starts With a Good Hypothesis
“We should test the homepage headline” isn’t a hypothesis.
Neither is “Let’s see if a more benefit-focused headline works better.”
Those are test ideas. And while they may eventually become useful experiments, they’re missing the part that makes experimentation valuable: an explanation of why you think the change might improve the experience.
A strong hypothesis connects what you’ve observed to what you want to learn.
Instead of:
We should test a more benefit-focused headline.
Try:
We’ve seen visitors engage with our service content but leave before exploring how we work. We think leading with our expertise and hands-on approach will make the value of the service clearer and increase the number of qualified visitors who continue to the consultation page.
Now you have something to work with.
You know what prompted the experiment. You know what you’re changing. You know what you expect to happen. And you’ve identified an important guardrail: increasing submissions isn’t necessarily a win if the additional leads aren’t useful.
Evidence Gives the Hypothesis Somewhere to Start
The best hypotheses don’t appear in brainstorming sessions out of nowhere.
They usually start with a signal.
Maybe analytics show an unusual drop-off. Session recordings reveal visitors repeatedly struggling with the same interaction. Customer interviews surface a question the website isn’t answering. Search data shows people using language that’s different from the language on the page. Sales hears the same objection over and over.
For a closer look at how visitor behavior can shape your testing ideas, explore Bluvia’s guide to turning behavioral insights into better experiments.
Sometimes the evidence is quantitative. Sometimes it’s qualitative. Often, the most interesting opportunities appear when you can connect the two.
The point isn’t to gather enough evidence to prove your hypothesis before you test it. If you already knew the answer, there wouldn’t be much reason to experiment.
The evidence gives you a reason to ask the question.
Be Specific About What You Think Will Change
A vague hypothesis creates a vague experiment.
“We think this page could perform better” doesn’t tell you much.
Better how?
More people clicking the CTA? More people completing the form? More qualified leads? Fewer people abandoning a particular step? More customers reaching the next stage of the journey?
Being specific forces you to define what success would mean before you see the results.
That’s important because experiments can move multiple metrics at once, and not always in the same direction.
A more benefit-focused message might increase engagement without changing completed conversions. Showing pricing earlier might reduce total inquiries but increase the percentage that become customers. A more prominent CTA might attract more clicks without changing completed conversions.
If you only decide which metric matters after seeing what moved, it’s surprisingly easy to find a reason to call almost any experiment successful.
Decide what you’re trying to improve before the results give you a reason to change the question.
Don't Forget the “Because”
One simple way to strengthen an experiment is to make yourself finish this sentence:
If we change ________, we believe ________ will happen because ________.
The last part is usually the most valuable.
“Because” forces you to explain the customer logic behind the idea.
If we simplify the comparison page, we believe more visitors will continue to the product pages because the current experience asks them to evaluate too many options at once.
If we add pricing context earlier, we believe more qualified visitors will complete the consultation form because they can determine whether the service is within their budget before committing to a conversation.
Now you’re not just testing a design or a piece of copy.
You’re testing your understanding of the customer.
Try This: Add the Missing “Because”
Take one change your team wants to make and write it using this structure:
If we change __________, we believe __________ will happen because __________.
Then look closely at the final blank.
Can you support that “because” with something you’ve observed in analytics, customer feedback, research, sales conversations, usability testing, or behavioral data?
If you can, you have a stronger foundation for an experiment.
If you can’t, that doesn’t necessarily mean the idea is bad. It may mean the next step isn’t testing the solution yet. It’s learning more about the problem.
That’s an important difference.
Because experimentation works best when Version B isn’t just another idea.
It’s an idea with a reason behind it.
4. A Losing Test Can Still Be a Good Experiment
Nobody launches an experiment hoping the new version loses.
You’ve identified a problem, developed a hypothesis, created a variation, and put it in front of real visitors. Of course you want to see an improvement.
But if the only experiments you consider successful are the ones where Version B wins, you’re leaving a lot of value on the table.
Sometimes the most useful result is finding out that the thing you were convinced mattered didn’t matter nearly as much as you thought.
A Result and a Learning Aren't the Same Thing
Imagine you believe visitors aren’t moving forward because they don’t understand what makes your service different.
You rewrite the positioning around the benefit your team believes matters most. Run the experiment. And behavior doesn’t meaningfully change.
The result is that the new positioning didn’t win.
The learning could be much more interesting.
Maybe the positioning wasn’t the real source of friction. Maybe visitors already understood what made the service different but weren’t convinced it was right for them. Maybe an important question wasn’t being answered elsewhere in the journey. Maybe the people reaching the page weren’t the right audience in the first place.
The experiment hasn’t told you exactly which of those explanations is correct.
But it has helped you eliminate one assumption and ask a better question next.
That’s progress.
Don't Keep Testing the Same Idea in Disguise
This is where experimentation can go wrong.
A team believes strongly in an idea. The test doesn’t support it. So they change the wording slightly, adjust the design, and run essentially the same idea again.
And again.
At some point, you’re no longer following the evidence. You’re trying to convince the evidence to agree with you.
At Anala, we think an experiment should be allowed to change your mind.
That doesn’t mean abandoning an idea after one inconclusive result. Tests can fail for plenty of reasons, including weak execution, insufficient traffic, measurement problems, or a variation that didn’t meaningfully represent the hypothesis.
But before automatically running another version, ask whether the result changed what you believe about the original problem.
If it didn’t, why not?
Inconclusive Isn't the Same as Useless
Not every experiment produces a clean winner and loser.
Sometimes the difference is too small to support a confident decision. Sometimes different audience segments behave differently. Sometimes an experiment exposes a measurement problem you didn’t know you had.
Those outcomes can be frustrating, especially when a team has invested time in getting the test live.
But they can still tell you something important about what to do next.
Maybe the change wasn’t meaningful enough. Maybe you need more evidence before pursuing the idea. Maybe the metric you chose isn’t capturing the outcome you really care about. Or maybe the potential upside simply isn’t large enough to justify more effort.
“We don’t know yet” is a legitimate result when the evidence doesn’t support a stronger conclusion.
It’s a much better result than pretending the data said something it didn’t.
For practical guidance on planning experiments and interpreting their results, explore Bluvia’s guide to running A/B tests.
What You Learn Should Outlive the Experiment
The biggest waste isn’t a losing test.
It’s an experiment everyone forgets.
If the results live in a dashboard, presentation, or testing platform but never influence another decision, the organization has paid for learning it doesn’t use.
Over time, experiments should create a body of knowledge about your customers.
What messages consistently resonate? Where does additional information help? Which types of friction matter most? Which assumptions have repeatedly turned out to be wrong? Are there patterns that show up across different journeys or audiences?
That knowledge can make future experiments better, but it can also improve decisions that never become experiments at all.
The goal isn’t just to build a website that tests more. It’s to build an organization that remembers what it learns.
Try This: Write the Learning Without Using “Won” or “Lost”
Take the results from a recent experiment and describe what happened without using the words won, lost, winner, or loser.
Instead, finish these sentences:
We believed __________.
We observed __________.
This changes what we think about __________.
Our next question is __________.
If those sentences are difficult to complete, the problem may not be the result.
It may be that the experiment was designed to produce a winner rather than produce useful learning.
And that’s an important distinction, because the best experimentation programs don’t just accumulate wins. They accumulate knowledge.
5. The Real Goal Is Better Decisions
Accumulating knowledge only matters if it changes what happens next.
That’s where experimentation becomes bigger than a testing program. The real opportunity isn’t simply to launch more tests. It’s to bring evidence into decisions that might otherwise be driven by habit, preference, hierarchy, or whoever makes the most convincing argument in the room.
At Anala, we don’t think the goal is to turn every website into a testing machine. The goal is to create a website and a team that can learn before assumptions become expensive decisions.
Experimentation Can Make Bigger Decisions Less Risky
Website decisions have a habit of getting expensive quickly.
A new page becomes a new template. A new template becomes part of a redesign. A messaging change spreads across dozens of pages. A new customer journey requires development, integrations, content, and training.
By the time the work is finished, the organization may have invested heavily in an idea it never really validated.
Experimentation gives teams a way to learn earlier.
Can you test the new positioning on one high-value page before rewriting the entire website? Can you experiment with a different journey before rebuilding the underlying experience? Can you learn whether customers respond to a new offer before creating a large campaign around it?
You won’t be able to test every decision this way, and you shouldn’t try.
But when an assumption sits underneath a significant investment, learning something earlier can be worth far more than squeezing another percentage point out of a button.
Make Experimentation Part of the Conversation
One of the clearest signs that experimentation is becoming part of how a team works is when people start asking different questions.
Instead of:
“Which version do we like?”
The conversation becomes:
“What do we know about what customers need here?”
Instead of:
“Can you change this?”
Someone asks:
“Is there a way to learn whether changing this would help?”
Instead of two teams debating whose recommendation is right, they can ask whether the website gives them a reasonable way to gather evidence.
That doesn’t eliminate judgment, expertise, or debate. Those things still matter.
Experimentation simply gives them somewhere productive to go.
Build for the Next Question
A good experiment rarely gives you the final answer.
It gives you a better next question.
You learn that customers respond to one value proposition more than another. Now you want to understand why. You discover that simplifying a step doesn’t improve conversion. Now you look elsewhere for the friction. You find that one audience responds differently from another. Now you have a reason to investigate what makes those journeys different.
Over time, those questions can change how the website evolves.
Instead of waiting until the next redesign to rethink the experience, the team can continuously identify problems, explore ideas, learn from customers, and carry those lessons into whatever comes next.
That’s a very different relationship with your website.
It stops being something you periodically fix and starts becoming something you continuously understand better.
Try This: Find One Decision You'd Rather Learn About First
Look at your website roadmap, backlog, or list of requested changes.
Find one decision that is:
Important enough that getting it wrong would matter.
Uncertain enough that your team doesn’t really know the answer.
Small enough that you could learn something before committing to the full solution.
Then resist the urge to ask, “What’s the best practice?”
Ask:
What’s the smallest useful thing we could learn before we make this decision?
That might lead to an A/B test. It might lead to a prototype, usability study, customer interview, or deeper look at behavioral data instead.
And that’s okay.
Because the Anala view of experimentation isn’t that everything needs a test.
It’s that important assumptions deserve evidence before they become expensive decisions.
Best Practices Can Start the Conversation. They Shouldn't End It.
Best practices are useful because they give us somewhere to begin.
They bring research, experience, and patterns from thousands of other digital experiences into the room. Ignoring all of that in the name of experimentation wouldn’t make your decisions smarter.
But neither does treating those patterns as answers.
Your customers don’t experience a best practice. They experience your website, your message, your offer, and your customer journey.
That’s why the most useful website teams know when to apply what they already know and when to get curious about what they don’t.
They fix the obvious problems. They use established patterns where the evidence is strong. But when an important decision depends on an assumption about what customers will understand, value, or respond to, they look for a way to learn before committing to the answer.
Sometimes that’s an A/B test. Sometimes it’s usability testing, customer research, behavioral data, or another form of experimentation.
The method matters less than the mindset.
Don’t use experimentation because you need more tests. Use it because you have questions worth answering.
That’s the difference between a website that simply follows best practices and one that gets smarter over time.
What Assumption Is Your Website Making?
Every website is built on assumptions.
Some are backed by years of evidence. Others came from a meeting six months ago and somehow became permanent.
The interesting part is figuring out which is which.
Turn Your Next Question Into an Experiment
The hardest part of experimentation shouldn’t be getting the experiment itself onto your website.
That’s one of the reasons we built Bluvia, Anala’s WordPress-native A/B testing and behavioral insights platform. Bluvia lets teams create and manage website experiments directly within WordPress, so you can move from a question worth answering to a live test without adding another disconnected experimentation workflow.
You can run A/B tests, use heatmaps and session recordings to understand how visitors are interacting with the experience, and bring what you learn back into the next experiment.
And you don’t need to build a full experimentation program before you start. Bluvia’s free plan includes unlimited A/B tests, giving you a practical way to take one of the assumptions you’ve identified in this article and find out what your customers actually do.
Because the goal isn’t to test everything.
It’s to make the decisions that matter with better evidence.
Start Experimenting With Bluvia.
By Mike Reall
By Rebecca Streeter
By Emily Vadali