“One small change” is a wonderful phrase. It can mean moving a heading. It can also mean turning the brochure website into a booking system with accounts, payments and a discreet little calendar. The adjective has not been briefed on the difference.
These commandments are for clients and developers sharing a web project. The examples are invented. Nobody’s private email has been recruited into the joke, and the developer does not get a special exemption for writing the rules.
Clear assumptions matter inside the implementation too. These fictional variable-name examples show how a small label can either answer or create the next reader’s question.
Settling the product explanation is part of the brief. Our piece on why startup landing pages look alike shows why a more specific example can matter more than another background treatment.
The newer tools add another set of assumptions to settle. These client commandments for 2026 focus on AI prototypes, delivery proof and the practical handoff.
1. Name the job the visitor needs to do
A website can look impressive while making its visitor work unnecessarily hard. Start with a concrete task: find the opening hours, compare two services, request an appointment. “Feel our brand” is difficult to turn into a useful button.
The GOV.UK guidance on user stories separates the person, their need and their goal. You do not need to adopt a government’s entire process to ask who needs the page and what they should accomplish there.
For our fictional repair shop, the first assignment is helping someone find out whether a broken lamp can be repaired. The animated philosophy of illumination can wait.
2. Bring the words before approving their container
A layout filled with short sample sentences is making a quiet promise about the final copy. A paragraph three times longer will have opinions about that promise.
Supply representative headings, service descriptions and awkwardly long names early. The developer should ask for them, explain what is missing and show what happens when content expands. Neither side should pretend that placeholder text is a rehearsal of the real page.
If the actual heading is “Specialist restoration of inherited decorative lighting,” test that heading. “Our services” is not a suitably difficult substitute.
3. Choose who can settle a disagreement
Five people can offer useful feedback. Five people issuing separate final decisions produce a website with five steering wheels.
Name a person who can consolidate the response and resolve conflicting requests. This does not require silencing everyone else. It requires deciding what happens when one reviewer wants the page shorter and another wants the company history above the fold.
The developer has a matching responsibility: make the decision understandable. Show the competing outcomes. Do not send a technical vocabulary quiz and call the resulting silence approval.
4. Explain what you like about the example
“Make it like this site” leaves a surprising amount of room for interpretation. The client means the clear navigation. The developer notices the typography. A third person falls in love with the enormous video, which nobody has budgeted to produce.
Point to the useful feature and explain its job. “The service names are visible before I scroll” gives the team something concrete to discuss. It also leaves room to solve the problem in a way that fits this business.
Even a tiny visual preference can deserve a clear explanation. Our square corners with CSS article takes one such choice seriously enough to make the joke useful.
5. Describe what done looks like
“The form works” could mean the button changes color. It could mean the right person receives a complete request and the visitor gets a clear confirmation. Those are different levels of reassurance.
The same GOV.UK guide describes acceptance criteria as outcomes used to check whether the user’s need has been met. For the fictional lamp shop, a request should include the agreed information, reach the intended destination and show the visitor what happens next.
Write the expected result before the final review. Otherwise, the last meeting becomes a live competition to invent the meaning of finished.
6. Give a change somewhere to land
A new feature has consequences even when everyone likes it. Ask what it changes about the agreed work, the schedule or the amount of ongoing care. A feature does not become weightless because it was described cheerfully.
The developer should explain the consequence in ordinary terms. “This adds another system that needs testing” is more useful than a dramatic sigh. The client should be able to choose among understandable options.
Our imaginary booking calendar can be valuable. It still needs an owner, appointment rules and a plan for unavailable times. The little calendar has brought luggage.
7. Send one usable round of feedback
Put related comments together and identify the page or element involved. “The second paragraph on the repair page repeats the first” is actionable. “Something is off” is the beginning of a conversation, not its completion.
Distinguish a broken requirement from a preference. Both can matter, but they call for different decisions. The developer should acknowledge what changed and flag anything still unresolved.
Endless revision can become a way of avoiding release, as the fictional writer in Why I Will Never Make Digg Popular discovers. A coherent review is more useful than another lap.
8. Include people who use the site differently
Your mouse, screen and eyesight are not the complete audience. Accessibility belongs in design and review, while changes are still being made.
W3C WAI’s guidance on involving users explains why disabled people should be part of evaluation and why user experience matters alongside standards checks. One person’s successful visit does not establish that the whole site is accessible.
For this project, that means treating a keyboard problem as a real problem, rather than an unusual preference. The visitor should not need the designer’s exact equipment to repair a lamp.
9. Report the steps that produced the problem
A useful bug report says where you started, what you did, what you expected and what happened. Include the relevant device or browser when known. Avoid sending private information that the team does not need.
The developer should make reporting easy and help reproduce uncertain failures. “Works for me” is a location report. It does not settle what happened to the other person.
10. Decide who looks after it tomorrow
Launch is a handover into ordinary use. Someone needs to update the opening hours, notice failed requests and know whom to contact when the site misbehaves.
Record those responsibilities in plain language. Make sure the named person can actually perform the task. A document that says “the team” can leave a remarkably empty room when a form stops arriving.
Then the repair shop can get back to repairing lamps. The website has a job, the people have responsibilities and the small change has finally been measured.