A new layout can look more convincing than the old one without solving the problem that prompted it. Before calling a website change an improvement, keep a record of the question it was meant to answer.
For a small business, web design intelligence can be a straightforward habit: observe a problem, propose an explanation, try a bounded change, and review what happened. You do not need to describe the website as intelligent. You need enough evidence to make the next decision.
Separate what happened from why you think it happened
Suppose a fictional repair business hears several callers ask whether it works on commercial equipment. That is an observation. “Our service page hides the eligibility information” is one possible explanation.
Others remain possible: callers may not have visited the page, or they may want reassurance before arranging a repair. Write down those alternatives. A plausible explanation is worth investigating, but it has not yet been demonstrated.
This distinction follows the GOV.UK research-analysis guidance, which separates what researchers saw or heard from their interpretation and the actions they choose.
Make the proposed change answer one question
For the repair business, the question could be: “Can a prospective customer tell whether this service covers commercial equipment?” The team could review a clearer eligibility sentence near the service introduction.
Changing the headline, photographs, page order, and inquiry route at once would make it harder to judge which change mattered. Start with the smallest useful version of the idea, provided it does not leave an obvious defect unresolved.
Record the current page, the proposed version, the reason for the change, and what you expect to observe. Keep the earlier copy so you can compare it accurately or restore it if needed.
Try the question with people who might use the service
Ask a likely customer to use the page to answer the question. Avoid pointing to the new sentence or asking whether they like your improvement. Watch where they look, what they understand, and where they hesitate.
The GOV.UK usability-testing guide recommends realistic tasks and neutral instructions that do not reveal the answer. A useful task here would be: “You need a repair for equipment at your workplace. Find out whether this business could help.”
Keep notes about the behavior, with permission where recording is involved. If the same person reviews both versions, acknowledge that familiarity with the first may affect how they use the second.
Keep the conclusion as narrow as the evidence
A few sessions may reveal a specific misunderstanding. They do not establish how common it is across your whole audience or prove that the revised page will generate more business. Treat a small review as guidance for the next decision, not a percentage improvement to publish.
If you also review inquiries after a live change, note other changes in the period, such as a promotion or different services being offered. A busier week alone does not identify the cause.
Decide whether to keep, revise, or investigate
Close the review with a short decision note:
- What did people understand or struggle with?
- Did the change address the original question?
- What remains uncertain or untested?
- Will you keep it, revise it, or gather different evidence?
“We still do not know” is a valid outcome when the evidence is limited. It tells you what the next review needs to resolve.
For a proposed change to an existing site, discuss it with Imbark through website support. Bring the page, the observation, and the question. That provides a clearer starting point than a request to make the site smarter.
