Build the improvement selected by evidence
This week implements the decision from Week 18. The default project is to improve the clarity of a website or resource journey, because that is a useful bounded exercise across the three business paths. Substitute another improvement when the actual review provides a stronger reason, and document the choice.
Keep the intended outcome visible while building. A change can become larger than necessary when new tools, extra pages and additional features appear attractive. Use the decision brief to determine which work belongs in the current project and which ideas should remain in the backlog.
1. Confirm the problem and completion criteria
Read the observed evidence, chosen hypothesis and review rule before changing the system. Check that the problem still exists and that the proposed solution is feasible with the available time and resources. If new evidence changes the decision, update the brief rather than proceeding solely to match a content calendar.
Write the customer-facing completion test. For the default project, a suitable reader should be able to choose the relevant path, locate the promised resource and explain the next action. For a delivery fix, the expected recipient should receive the correct access after the confirmed event.
Record the current version or configuration so the change can be understood and reversed if necessary. Capture only the evidence required for the review. Public examples should use aggregated records or illustrative inputs rather than identifiable customer information.
2. Make the smallest useful change
For a website clarity improvement, revise the relevant heading, explanation, action label and destination. Remove a competing step if it distracts from the intended task. Update related posts, emails or resource descriptions that would otherwise make an outdated promise.
For a workflow improvement, change the rule or handoff that causes the observed failure. Use native provider behaviour when it can meet the need. Add custom code or orchestration only where the remaining work justifies it. Keep the logic understandable independently of the implementation tool.
If AI helps draft content or code, provide the original task, relevant evidence and acceptance criteria. Review its output against those criteria. A fluent explanation or a successfully generated file does not establish that the customer journey works.
3. Verify the experience and its evidence
Repeat the task that exposed the original problem. Ask a suitable reader to complete it with the revised experience, or run the relevant controlled transaction in test mode. Record what happened, including unresolved confusion. Check mobile use, links, state changes and the appropriate exception path where these are affected.
Verify the measurement connected to the change. An event name or destination may need updating when a page or workflow changes. Keep definitions consistent where comparison is intended, and document any break in comparability. Exclude the controlled tests from operating results.
Check that the change has not introduced an obvious adjacent failure. A clearer button still needs to reach the correct destination. A revised delivery message still needs a working help route. Keep this verification proportional to the actual risks introduced by the change.
4. Record the change and allow time to observe
Save the change date, version, owner, affected journey and expected mechanism. Record the agreed observation window and other material changes happening at the same time. If an outcome needs time to mature, preserve that waiting period in the review plan.
Publish what was built, why it was chosen and what the controlled test established. Leave later business outcomes for the next review. A working test can establish that a link or rule behaves as intended; it cannot establish future revenue or a lasting improvement in customer behaviour.
Illustrative default project
A resource page presents three workbooks without explaining whom each is for. The revised page asks whether the reader is building an audience, selling services or delivering a digital product, then points to the corresponding first task. A fresh-reader check tests whether the distinction is understandable. Resource clicks provide later behavioural context, with attribution and sample limits stated.
If the best actual project is a different correction, retain the same structure: problem, evidence, bounded change, controlled test and later outcome review. This is the repeatable improvement method that the audience can apply to its own business.
You are finished when: The improvement is ready for an honest outcome review without premature claims.
Check your work.
The improvement is ready for an honest outcome review without premature claims.
Saved only in this browser. You can change this any time.