Evidence first, redesign second
A systematic CRO process - diagnose with data, form hypotheses, test, and iterate.
Where this usually breaks down
Changing a button colour and calling it CRO is how most "optimisation" fails quietly. Teams under pressure to move a number reach for whatever change feels obvious - a new hero image, a reworded headline, a brighter call-to-action - and ship it without ever confirming that was the thing actually stopping people from converting.
The deeper problem is that a redesign based on internal opinion treats every visitor drop-off as the same kind of problem, when in practice a confusing form, a slow page, and a mismatched offer all look identical in a top-line conversion rate but need completely different fixes.
What this service actually solves
Conversion rate optimisation done properly starts with evidence - heatmaps, session recordings, and funnel data that show what visitors actually did, not what the team assumes they did. A hypothesis gets formed from that evidence, prioritised against the effort it takes to test, and only then does a variant get built.
Conversion rate optimisation is the systematic process of diagnosing where and why visitors fail to convert, then testing specific, evidence-backed hypotheses instead of redesigning on instinct.
How we run it
We run diagnostics before we run tests. That means heatmaps and session recordings on the pages losing the most people, a funnel breakdown to confirm where the actual leak is, and a prioritised backlog of hypotheses scored by expected impact against effort to implement. Every test that follows has a sample size calculated before launch and a minimum run time long enough to capture a full weekly traffic pattern - a test called early because a number looked good creates false confidence, which is worse than no test at all.
Capabilities & deliverables
Diagnostic Research
- Heatmap and scroll-depth analysis
- Session recording review
- Form and field-level drop-off tracking
Hypothesis Prioritisation
- Impact-versus-effort scoring
- Backlog management across multiple pages
Test Design & Execution
- A/B and multivariate test builds
- Cross-device and cross-browser QA
Statistical Validation
- Sample size calculation before launch
- Significance and guardrail metric checks
Rollout & Documentation
- Winning variant rollout
- Searchable test history and learnings
What's in scope, area by area
| Area | What we deliver |
|---|---|
| Diagnostic Audit | Heatmap and session recording review plus a funnel analysis report identifying where visitors actually drop off |
| Testing Roadmap | Prioritised hypothesis backlog scored by expected impact and effort to implement |
| Test Execution | Build, QA, and launch of each test with a pre-calculated sample size |
| Reporting | Statistical readout at test end with a clear rollout, iterate, or kill recommendation |
How an engagement runs
Diagnostic Audit
Heatmaps, session recordings, and funnel data establish where visitors are actually dropping off before anything is proposed.
Hypothesis Formation
Each finding gets turned into a specific, testable hypothesis about why the drop-off is happening.
Prioritisation
Hypotheses are scored by expected impact against effort, so the highest-leverage tests run first.
Test Design & Sample Size
Sample size and minimum run time are calculated before a single line of the test is built.
Test Execution & Monitoring
The test runs to its planned duration - we do not call it early because an early number looks good.
Rollout & Documentation
Winning variants get rolled out, and the result - win, loss, or inconclusive - is documented for the next test.
How this compares
| Diagnostic-Led CRO | Redesign by Instinct |
|---|---|
| Every test starts from a specific, evidence-backed hypothesis | Changes are made based on internal preference or a competitor trend |
| Sample size is calculated before a test launches | Tests are called early because a number looked good |
| Wins and losses are documented and compound over time | Each redesign starts over with no institutional memory |
This does not mean a full redesign is never the right call - sometimes the diagnostic points that way. It means the decision follows the evidence rather than preceding it.
What this changes for the business
- Conversion decisions are based on what visitors actually do, not what the internal team assumes
- Wasted spend on redesigns that would not have moved the needle is avoided
- A documented backlog of validated learnings builds up instead of resetting with every new project
Who needs this
Sites with decent traffic but a stalled conversion rate
If traffic is healthy and revenue growth has flattened, the constraint is usually on the page, not in the ad account.
Teams about to commission a full redesign
Worth diagnosing first - a redesign fixes what it happens to fix, whether or not that was the actual problem.
Related work
We're still building out published proof for this specific service — ask us directly and we'll walk through relevant examples.
Common questions
A specific, evidence-backed statement of why a change should affect behaviour - not just "try a new headline." A good hypothesis names the observed problem, the proposed fix, and the expected effect, which makes the result interpretable whether the test wins or loses.
It helps but is not required - if tracking is missing or broken, that gets fixed as part of the diagnostic phase, since testing on top of unreliable data just produces confident wrong answers faster.
Enough to keep the backlog moving without running tests on overlapping traffic or the same page at the same time, which muddies which change caused which result. The right number depends entirely on traffic volume.
It gets documented as a real result, not treated as a failure. An inconclusive test tells us the variable tested probably was not the actual constraint, which redirects the next hypothesis rather than wasting a repeat test.
No - anyone promising a fixed percentage before running a diagnostic is guessing. What we commit to is a disciplined process: real hypotheses, properly powered tests, and an honest read of what the data actually shows.
Not sure if a redesign will actually fix anything?
We'll run a diagnostic before recommending a single change.
Talk to us →