Exercise 2 · The Build–Measure–Learn Loop
Website Analysis & Interface Design — Session 1 practice · Estimated time: 45 minutes
Background
Websites are never "finished." Effective teams improve them in a continuous loop: build a change,
measure its effect, learn from the result, and repeat. The loop turns opinions ("I think the button should
be green") into experiments ("we believe a green button will raise clicks by 10%; let’s test it").
Objective
Design one complete iteration of the Build–Measure–Learn loop for a website improvement, without
writing any code.
Instructions
1. Pick one weakness you found in Exercise 1 (or any website problem you know well).
2. Write it as a hypothesis using the template: "We believe that [change] will cause [effect] for
[audience], and we will know it worked when [metric] changes by [amount]."
3. Fill in the loop planner below.
4. Decide in advance what you will do if the experiment succeeds, fails, or is inconclusive.
Loop planner
Stage Your plan
BUILD — What exactly will you change? Keep it
small enough to ship in one week.
MEASURE — Which metric will you watch? What is
its current value (baseline)?
MEASURE — How long will you run the test, and
how much traffic do you need?
LEARN — What result would confirm the
hypothesis? What would refute it?
NEXT LOOP — If it works, what do you build next? If
it fails, what do you try instead?
Reflection questions
Why is it dangerous to run the loop without a baseline measurement?
What is the smallest version of your change that would still teach you something?
Which stage of the loop do teams most often skip, in your experience, and what does it cost them?
Remember
A failed experiment that teaches you something is a success. The only true failure is a change you
never measured.
Worked example (for reference)
A worked hypothesis from the GreenLeaf Tea example: "We believe that adding customer reviews and a
satisfaction guarantee to product pages will increase add-to-basket rate for first-time visitors, and we
will know it worked when the add-to-basket rate rises from its 3.2% baseline to at least 3.8% over two
weeks of traffic." The BUILD is deliberately small: reviews on the five best-selling products only, not the
whole catalogue. The MEASURE stage defines the metric (add-to-basket rate, first-time visitors only),
the baseline (3.2%), and the duration (two weeks, roughly 8,000 sessions). The LEARN stage is written
before the test starts: above 3.8% confirms; between 3.2% and 3.8% is inconclusive and the test extends
two more weeks; at or below baseline refutes, and the next candidate — visible contact details —
moves to the top of the queue.
Common mistakes to avoid
Changing several things at once. If you add reviews, rewrite the headline, and change button colors
together, you cannot attribute the result to any of them.
Stopping the test the moment the number looks good. Early results wobble; decide the duration in
advance and hold to it.
Defining success but not failure. If no result would make you abandon the idea, you are not running
an experiment — you are decorating a decision you already made.
Measuring a metric your change cannot plausibly move. A footer change will not move homepage
bounce rate; pick the metric closest to the change.
Bonus challenge
Write hypotheses for your next three experiments in the same template, and rank them by expected
impact multiplied by ease of implementation. This ranked backlog is exactly what a professional growth
team maintains — and it means the loop never stalls waiting for the next idea.