How Clients Should Review a Website Mockup: A Practical Checklist

You do not need design software or design vocabulary to review a website mockup well. Your role is to explain whether the design supports the project goals, represents the business accurately and makes sense to the intended audience. A useful review describes what you noticed and why it matters.

Start with the agreed goal

Read the brief or project goals before opening the preview. Write down the main audience, the most important action and the key message. Then look at the design without trying to redesign it in your head. Ask: can a new visitor tell what the organization offers, who it serves and what to do next?

Review in five passes

1. First impression: After a few seconds, what do you think this business does? If your answer differs from the brief, explain the mismatch.
2. Content accuracy: Check names, prices, services, contact details, claims and calls to action. Flag facts that are wrong or missing.
3. Page flow: Scroll from top to bottom. Does the order answer likely visitor questions? Note where information feels too early, too late or absent.
4. Visual clarity: Identify anything hard to read, confusing or competing for attention. State the location and the effect, not just “make it pop.”
5. Device context: Inspect the desktop, tablet and mobile compositions if supplied. Look for cramped text, overlapping elements, hidden actions and content that becomes difficult to scan.

Use a focused feedback format

For each comment, include four details: page or section, what you observed, why it matters, and the change or question you want considered.

Vague: “The services section feels off.”
More useful: “On the services page, the three packages look equally important. Our brief says the managed plan is the main offer. Could we make that option easier to identify?”

You do not need to prescribe the exact design solution. Explain the customer need and let the designer propose a response.

Separate facts, preferences and new requests

Mark factual corrections clearly. Label a personal preference as a preference rather than a user problem. Put new pages, features or content requests in a separate list so the team can discuss scope and timing before treating them as small visual edits.

Coordinate feedback before sending it

If several colleagues review the mockup, choose one person to collect comments and resolve contradictions. Ask reviewers to comment on the same version and use one agreed channel. A single consolidated set is easier to assess than scattered messages arriving over several days. See Swelik’s stakeholder feedback guide for a simple consolidation approach.

Close with a decision

End with one of three outcomes: approved for the next agreed stage, approved with a short list of corrections, or more review needed because a decision or piece of information is missing. This gives the designer a clear next step without pretending every detail must be perfect on the first pass.

Client review checklist

• I checked the mockup against the project goal.
• I verified key business facts and content.
• I reviewed the full page, not only the first screen.
• I noted the exact page or section for each issue.
• I separated required changes from preferences and new requests.
• Our team has one consolidated response and one decision owner.

Prepare before opening the preview

Ask the project contact for the latest version, the pages included, the review deadline and the decisions needed. If you are reviewing a long homepage, set aside enough time to scroll through the full page. If the brief is unclear, ask which business goal should take priority before commenting on visual choices.

Make one pass without writing notes. This gives you a first impression of the page as a visitor might experience it. On a second pass, capture questions and corrections. This reduces the chance that the first detail you notice, such as a color preference, dominates the whole review.

Sort your comments before sending them

Group comments under three headings: required correction, question to resolve, and optional preference. Add page and section names so the designer can find each item. Mark anything that changes scope, such as a new page or booking feature, as a separate request. Avoid combining five unrelated changes in one paragraph.

For each item, include the reason. “Use the shorter headline” is an instruction. “The current headline wraps to four lines on the mobile frame and pushes the main action below the initial screen; could we test a shorter version?” gives the designer context and a useful objective.

What to do when something feels wrong

Describe your reaction and ask a question about the cause. Perhaps the design feels busy because there are too many competing actions, the page lacks spacing, or the content does not explain the offer. You do not need to identify the exact visual fix. Your observation is most valuable when it connects a specific point in the page to a likely visitor problem.

If you are reviewing as a group, do not send individual contradictory notes in parallel. Have one person gather them and check whether the team agrees on the final decision. The feedback examples guide provides more before-and-after phrasing.

Frequently asked questions

Should a client suggest design solutions?

You can share examples or ideas, but explain the problem first. That gives the designer room to solve the underlying need.

What if I do not understand a section?

Describe what you expected to find and what remained unclear. Confusion is useful evidence when it is tied to the page and visitor goal.