Improve the system using evidence
The seven chapters now form one connected journey: a useful account, repeatable content, a resource and email relationship, an offer, a workflow and a response system. The next task is to check the whole experience and choose a small improvement.
A review is most useful when numbers have clear meanings and decisions remain proportionate to the evidence. Early results may be limited. You can still learn from actual setup tests, production effort and the questions people ask.
1. Follow the complete journey
Start from the same place as a new visitor. Read a post, visit the profile or page, request the resource, use the first instructions and find the relevant next step. Then try a support question.
Check whether the promises remain consistent. Does the resource contain what the post described? Does the email point to the right lesson? Does the offer explain its scope? Can someone recover when a link or step fails?
Record the observed issue and the point where it appears. A clear test record gives you a better improvement target than a general feeling that the website needs work.
2. Choose a small scorecard
Track measures that answer a useful business question. Guide visits help you understand whether content leads to deeper interest. Resource signups show a further action. Relevant software clicks show interest in a recommendation. Partner reports may show signups, qualifying paid customers or approved commissions.
Keep these stages separate. A free registration is not the same as a commission. Approved earnings and cash received are also different records. Use what each provider actually reports and avoid implying a connection that the available attribution cannot establish.
Include production time, operating cost and recurring support issues. A system that produces content but consumes too much maintenance may need a different improvement from one that attracts visitors who cannot find the resource.
3. Define each number
Write the source, date range and counting rule beside the measure. If you use a conversion rate, identify its numerator and denominator. Distinguish unique people, visits and events rather than mixing them in one percentage.
Use zero for an observed count of zero. Use “not measured” when the information is unavailable. This prevents a missing event connection from appearing to be a genuine lack of activity.
Compare like with like. A change in content topic, audience or traffic source can affect results alongside a page change. Treat a small early comparison as a signal to investigate rather than a settled causal conclusion.
4. Choose one friction point
Select an issue that matters to the journey and that you can change. It might be an unclear resource promise, a broken link, excessive production rework or a repeated support question.
Write an improvement statement: “We observed [issue]. We will change [specific element] because [reason]. We will check [evidence] on [date].” Keep the change small enough that its effect can be assessed.
If there is little audience data, improve a verified operational issue. A failed download or a confusing instruction is a useful problem to solve even before larger traffic arrives.
Prepare the alternating build and review rhythm
This is the first foundation review. From Week 8, the programme alternates an analytics and decisions episode with a practical build episode, producing one YouTube episode each week. Analytics episodes occupy even weeks through Week 20; practical builds occupy the intervening odd weeks. The first seven foundation episodes remain intact.
Check that measurement has been enabled for the live journey and that its sources can be accessed. Record the actual collection start, reporting period, tests excluded and known gaps. Week 8 uses this record to establish a verified baseline. If the business is not live, publish the method and clearly labelled tests rather than presenting planned results as history.
Choose one important next question. The website, booking and product modules are paths to adapt, not a requirement to operate three businesses. Keep the current promises working while deciding what additional system is justified.
Worked example
This example is illustrative. Several test readers find the Client Start Checklist but cannot identify the first action. The design educator adds a short “Start here” section and a completed example.
The next check asks new readers to complete the first three fields. The review records whether they can do it without extra explanation. This provides evidence about usability. A separate period of actual use would be needed before claiming a commercial effect.
5. Review the tool stack and next cycle
List what each tool does, its actual use, cost and maintenance needs. Keep tools that serve a clear job. Defer an upgrade until a specific requirement justifies it. Remove unused components carefully after checking that another part of the journey does not depend on them.
Choose the next review date and owner. Keep a short decision log so future changes have context. When a workflow or answer changes, update the relevant instructions and tests.
You are finished when: the complete journey has been tested, the scorecard distinguishes evidence from missing information and one next improvement has a clear action and review point.
Check your work.
The next decision is clear.
Saved only in this browser. You can change this any time.