A Website Review Workflow for Teams

Before the session: choose the decision, not a page count

Write down the decision the review should inform: for example, whether a new customer can understand eligibility and submit a request without support. Choose the smallest flow that can answer that question. A broad ‘review the whole site’ assignment encourages shallow scanning and makes it difficult to know when the work is finished.

Prepare a stable URL, the account or data state, and one task per reviewer. Agree on what is in scope, what cannot be tested, and where findings will be recorded. If customers or representative participants are involved, obtain the permissions and consent your research process requires before recording them.

During the review: let each person inspect before the group discusses

Give reviewers a few minutes to complete the task independently. Ask them to capture observations, not fixes. Independent notes reduce the chance that the first confident suggestion becomes the only idea considered. When observing a participant, keep prompts neutral: ‘What are you looking for?’ is better than ‘Did you notice the blue button?’

Then compare notes. Merge duplicates only when they describe the same underlying issue. Keep different causes separate even if they occur on the same screen—for example, an unclear button label and a keyboard focus trap require different investigation.

Triage: make a decision that matches the evidence

For each finding, ask: can the task be completed; who is affected; is there a reliable workaround; what evidence supports the claim; and what is the cost of waiting? A blocker in a high-value journey usually deserves attention before a visual preference. A single unobserved concern may still merit investigation, but label it as a hypothesis instead of presenting it as a confirmed user failure.

Assign the next action and preserve the reason

Give accepted findings an owner and an outcome to check. Record the decision even when the team chooses not to change something: ‘Keep the current label because…’ prevents the same debate from restarting without new information. If the team cannot decide, name the missing evidence and who will gather it.

• Accepted: assign an owner and a concrete follow-up check.
• Needs evidence: define the question and the smallest useful research step.
• Not changing: record the rationale and the condition that would reopen it.
• Duplicate: link it to the retained finding so the original context is not lost.

Close the loop by repeating the task

After a change is ready, use the same starting point and task. Check that the intended outcome now happens, that the fix did not create a new barrier in another viewport or state, and that the result is visible to the reviewer. For complex changes, a second round with representative users may be needed; a team walkthrough is a useful check, not a substitute for user research.

GOV.UK Service Manual: user research in discovery