Why evaluations fail
A common outcome of a website review is a thorough document that nobody acts on. The findings are accurate, the discussion is lively, and then ordinary work takes over. Weeks later the same issues are still there. This is not usually a knowledge problem. It is a follow-through problem, and it has simple, if unglamorous, remedies.
An evaluation is effective when it changes something about the site or the way it is managed. Everything below is aimed at that outcome. None of it promises better search results, since those depend on many factors, but it makes it much more likely that the work you identified is actually done and checked.
Decide what the evaluation is for
Before the review starts, write a sentence about the decision it should support. For example: “Decide which five fixes to complete this quarter,” or “Find out why the product pages are not being found.” A review with a purpose produces focused findings. One without a purpose produces a long catalog of everything that could be better.
Having a purpose also makes it easier to ignore findings that are true but irrelevant to your aims.
Limit the output
A shorter list is more likely to be completed. After sorting your findings, choose a small number that will be acted on in the next period. The rest can sit in a backlog. Techniques for ranking by effort and benefit are covered in the article on fix prioritization, and the audit priorities article discusses which issues tend to deserve attention first. The key point for follow-through is that the committed list must be small enough to finish.
Give every task an owner
A task without a name beside it is a task nobody does. For each item, name one person responsible. If you run the site alone, the owner is you, and writing it down still helps because it turns a vague intention into a commitment.
Where several people are involved, such as a writer, a developer and a manager, be specific about who does what. Shared ownership usually means no ownership. One person can be the owner while others help.
If the owner lacks the access or skill to complete the task, solve that at the outset. It is better to know on day one that a developer is needed than to discover it at the deadline.
Set realistic deadlines
Attach a date to each task. Make it a date you could keep, taking into account the other demands on the owner’s time. A deadline set without thought tends to be ignored, and ignored deadlines teach everyone that dates do not matter.
For larger tasks, break them into steps with their own dates. “Rewrite product descriptions” is vague; “rewrite the descriptions for the first ten products” is something a person can finish in a week.
Allow time for review and testing. A change that goes live without a check can create new problems, especially when it touches templates, addresses or redirects.
Define what “done” means
Write a short statement of what completion looks like. For a task like “fix broken links on the main pages,” done might mean “no broken links found on these pages in a fresh check.” Without this, people may stop at different points and disagree about whether the job was finished.
Include the check method. Who will verify, and how? The person who made the change is not always the best person to confirm it, because they know what they intended and may overlook what actually happened.
Schedule the follow-up check
This is the step most often skipped. For each completed task, set a date to look again. Two kinds of follow-up are useful:
- A technical check soon after the change. Does the page load? Does it look right on a phone? Did anything else break?
- An outcome check later. After a few weeks or more, has the thing you wanted to improve moved? Because results are slow and noisy, be modest in your conclusions. Absence of change does not necessarily mean the work was wasted, and a positive change is not always proof that your fix caused it.
Recording these in a change log makes it easier to look back; the article on change logs explains how.
Keep a simple status view
You do not need project software. A table with columns for task, owner, due date, status and notes is enough. Use plain statuses such as “not started,” “in progress,” “waiting,” “done” and “checked.” Review it briefly on a regular basis, perhaps weekly for active work. The point of the review is to notice what is stuck and to remove obstacles.
When an item slips, decide deliberately: extend the date, reduce the scope or drop it. Silent slippage is what turns a plan into wishful thinking.
Report in a way people can use
If others need to know the outcome, share a short summary rather than a full audit. It should say what was found, what was done, what remains and what you will check next. The article on writing an audit report others can act on goes further on format.
Repeat the cycle
An evaluation is not a one-time event. After the committed items are done and checked, look at the backlog, add anything new, and choose the next set. Over several rounds you build both a better site and a habit of acting on what you learn. A realistic cycle might be a full review every few months with lighter checks in between, adjusted to the size of your site and the time you have.
A short checklist
- Is the purpose of the review written down?
- Is the action list short enough to finish?
- Does every task have one owner and a date?
- Is “done” defined, and who verifies it?
- Are follow-up dates scheduled?
- Is there a place where everyone can see status?
If you can answer yes to these, your evaluation has a far better chance of making a real difference.