A design review works best when it checks whether a page communicates and behaves as intended. Start with the visitor’s task, then examine hierarchy, content, layout, and interaction states. This checklist helps designers, clients, and product teams explain what needs attention without turning the review into a collection of personal preferences.
Start with the purpose of the page
Write one sentence describing the audience, the job they came to do, and the next step the page should support. For a service page, that might be: a business owner needs to understand whether this service fits their problem and request an assessment. Use that sentence when deciding whether a prominent image, heading, or button earns its space.
Review the page before opening the design file. Read its main heading and scan the sections in order. Can you identify the offer, the qualification details, and the action? If the design reference contains placeholder text, it cannot settle whether the finished page communicates well. Use approved, realistic content during the review.
- Check that the heading identifies the subject rather than relying on a vague slogan.
- Check that the main action describes what happens next, including any commitment the visitor makes.
- Check that proof, limitations, and pricing details appear where someone needs them to decide.
- Check that secondary actions help the task instead of competing with the primary one.
Review hierarchy, readability, and consistency
Look at the visual relationships rather than requesting isolated changes. A large secondary card can overwhelm a modest primary action even when both meet the brand guidelines. When everything is emphasized, the visitor has to work out the hierarchy themselves. Explain which relationship causes confusion and what the hierarchy should communicate.
| Area | Question to ask | Evidence to attach |
|---|---|---|
| Hierarchy | Does the page make the intended order of attention clear? | A screenshot with the competing elements identified |
| Typography | Can real headings, labels, and body text be read without clipping? | The affected text and viewport size |
| Spacing | Do related items read as a group, with clear separation from other groups? | The section and surrounding context |
| Imagery | Does the image support the message, and does its crop preserve the subject? | Desktop and narrow-screen views |
| Consistency | Do repeated controls use the same language, alignment, and behavior? | Two specific component instances to compare |
Compare a sample of each page family: home, detail, listing, and forms. Then examine shared components across those pages. A spacing exception can be intentional, so record the rationale before applying a global rule. Avoid asking a developer to change every instance when the issue belongs to one unusually long title.
Include responsive layouts and interaction states
Resize the browser through intermediate widths, not only the sizes in the original mockup. Check long headings, navigation labels, translated copy if supported, and lists with more items than the happy-path example. A component that looks balanced with three short entries may overflow with the content it will actually receive.
- Open menus, dialogs, and accordions. Check whether their placement obscures the task or traps the reader in an unclear state.
- Inspect empty, loading, error, and success states. Ask whether each explains what happened and what the person can do next.
- Use a keyboard for the main path and inspect the visible focus indicator. Include the controls hidden behind menus.
- Enlarge text and inspect narrow layouts. Look for overlapping labels, hidden actions, and paragraphs that require horizontal scrolling.
W3C’s design guidance covers contrast, identifiable interactive elements, and feedback. Its reflow explanation describes preserving information and functionality when content is enlarged or narrowed. These are useful review references; a visual checklist alone does not establish WCAG conformance.
Write feedback that gives the designer room to solve it
Describe the observation, its consequence, and the desired outcome. Add a proposed solution when you have one, but distinguish that suggestion from an approved requirement. This keeps the review useful when the first proposed fix would create another problem on smaller screens.
Observation: On the service page, the testimonial card draws attention before the service description. Consequence: A visitor cannot quickly tell which problem the service solves. Desired outcome: Make the offer and next step clearer before supporting proof. Suggestion: Try reducing the card’s emphasis or moving it below the explanation. Context: Staging build rc-7, 1280 × 800 viewport. Decision needed from: Design lead.
Pin a comment to the relevant page area when possible. Annot8 can collect pinned feedback, screenshots, and page and browser context. Screen recording is available on paid plans when the issue depends on movement. Do not let the attachment replace the explanation: “this looks bad” still leaves the implementer guessing.
Use the checklist as a decision worksheet
Copy the worksheet and remove checks that do not fit your project. Give each finding an owner and record whether it is an agreed correction, a question, or a new design direction. Verify accepted changes against the intended outcome on the next build. If the result meets the goal through a different solution, record that decision instead of reopening the original suggestion.
