Module 4: Testing
Everything before this module was expert judgment — and judgment, even good judgment, is still guessing until it's tested. This module turns you into a researcher: what to test first, how to run a clean test, and how to read the data your visitors are already giving you.
What to test first
Most first-time testers start with button color. It's the least impactful thing on the page. Memorize the test-priority hierarchy — the order in which changes move the needle. One: the offer itself — what the visitor gets and what it costs them. Two: the headline — the promise, which decides whether anyone reads further. Three: proof — the evidence, which decides whether anyone believes. Four: the call to action — the ask, its wording and placement. Five: layout — the order of sections. Six, last and least: styling — colors, fonts, button shapes.
The iron rule of testing: one variable at a time. If you change the headline, the hero image, and the CTA together and conversions rise, you've learned nothing — you don't know which change did it, and you can't repeat it. One test, one change, one lesson. It's slower per test and infinitely faster per insight, because every result is usable.
Pick your first test from your Module 0 diagnosis. Weak clarity score? Test the headline. Weak trust? Test adding a testimonial beside the CTA. High friction? Test the shortened form against the long one. Test the weakest variable first — that's where the biggest wins hide. Testing your strengths while your weaknesses bleed visitors is rearranging deck chairs.
The test-priority hierarchy — start at the top
Build brief
Look at your Module 0 diagnosis — your weakest variable. Write 3 test ideas for your most important page, ordered by the hierarchy (offer, headline, proof, CTA, layout, styling). Which one will you run first?
Saved
Running a clean test
Every test starts with a written hypothesis in one sentence: "I believe [change] will cause [effect] because [reason]." Example: "I believe replacing our headline with the outcome-focused version will increase quote requests because the 5-Second Test showed visitors couldn't tell what we do." The hypothesis forces you to state your reasoning before the data arrives — which is what stops you from inventing explanations after the fact. No hypothesis, no test; that's the rule.
Then the mechanics. Split your traffic between the original (A) and the new version (B) — free A/B testing tools and most website platforms can do this, or you can run versions in alternating weeks if traffic is low. Measure the metric tied to the page's one job: quote requests for a service page, signups for a blog — not clicks, not time on page. Vanity metrics will happily tell you version B "engages" better while converting worse.
How long? Until you have enough conversions to trust the result. For most small sites, that means at least one to two full weeks (to cover weekday/weekend patterns) and at least a hundred conversions per version as a rule of thumb. Two days is never enough — early leads are noise, and stopping the moment your preferred version pulls ahead is just guessing with extra steps. Let the test finish. The data doesn't care which version you like. When it's done, the winner becomes the new A, and you test the next hypothesis.
Build brief
Write a proper hypothesis for your first test using the format: "I believe [change] will cause [effect] because [reason]." Then note: what metric will you measure, and how long will you run it?
Saved
Reading heatmaps, scrollmaps, and analytics
Your visitors are already telling you what's wrong — you just need to read the instruments. Start with analytics basics: conversion rate per page (completions divided by visitors — the one number that matters), traffic source breakdown (which sources bring buyers vs. browsers — double down on the buyers), and the exit pages (where people give up). Check these monthly; they're the vital signs.
Then the visual tools. A heatmap shows where visitors click and hover: red means heavy interaction, blue means ignored. What to hunt for: dead clicks — heavy clicking on something that isn't a link (your hero image, a headline) means visitors expect it to do something; either make it clickable or stop it looking clickable. Rage clicks — rapid repeated clicking — mean something looks broken or unresponsive. And ignored CTAs sitting in blue zones mean the button is in the wrong place, not that the offer is wrong. A scrollmap shows how far people get: if only 20% ever reach your testimonials, the fix isn't better testimonials — it's moving proof up.
Finally, session recordings: anonymized replays of real visits. Watch ten. You'll see hesitations no chart shows — the cursor hovering over the pricing section, the scroll-up-scroll-down around the form, the tap on the phone number that isn't linked. Ten recordings teach more than a hundred charts. Data tells you what happened; recordings show you why. Watch them before every redesign, and you'll redesign the right things.
Build brief
If you could see one heatmap of your site tomorrow, which page would it be and what would you look for? Write down 3 specific things you'd hunt for (dead clicks, ignored CTAs, scroll depth) and what each would tell you to fix.
Saved
Sam wants to improve his consulting site's contact page. He has time for one test this month. His analytics show visitors read the whole page but rarely submit the 9-field form. What should he test?
Your turn: Write a complete test plan: the page, your hypothesis ("I believe... because..."), the one variable you'll change, the metric you'll measure, how you'll split traffic, and how long you'll run it. One page, one plan.
Saved.
Test-win revenue estimator
A winning test isn't a percentage — it's money. See what a lift is worth.
New conversion rate:0
Extra customers/month:0
Extra revenue/month:0
Your next 24 hours
Write one hypothesis for your highest-traffic page and set up the test — even a simple before/after with a dated note in your changelog counts. The habit of testing beats the perfection of testing.
Steal this template
THE A/B TEST ONE-PAGER
Page: ___ · Page's one job: ___
Hypothesis: I believe [change] will cause [effect] because [reason].
Version A (current): ___
Version B (one change): ___
Metric (tied to the page's job): ___
Traffic split: ___ · Run length: ___ weeks · Conversions needed per version: ___
Result: ___ · Next test: ___
Module 4 cheat sheet
- Test order: offer → headline → proof → CTA → layout → styling. Never start with button color.
- One variable per test — or the result teaches you nothing.
- Hypothesis format: "I believe [change] will cause [effect] because [reason]."
- Run 1–2 full weeks minimum; ~100 conversions per version as a rule of thumb.
- Heatmaps: red = attention, blue = ignored. Hunt dead clicks, rage clicks, ignored CTAs.
- Scrollmaps show reach: if proof sits below where 80% stop scrolling, move proof up.