Visual Review
Look with a designer's eye. Does it look right? Compare what you see to what was designed. Every difference is a bug.
1 The Hook
A Queenstown tourism site launched their winter campaign. White text sat on a snow-capped mountain photo. On cloudy days the background loaded grey clouds. The white text vanished. Visitors saw a blank banner and left. The bug was in the design. A visual review would have caught it in five seconds.
Senior engineer insight
Visual review changed for me the day I realised the design file is a contract, not a suggestion — and that most developers treat it as a rough guide. The moment you start quoting pixel values and hex codes back to a developer, bugs stop being subjective ("looks a bit off") and become objective ("spacing is 12px, spec says 16px"). That shift from opinion to evidence is what makes a tester credible in design conversations.
The most common mistake Grad testers make: they eyeball spacing and colour without opening the design file, so they report genuine bugs as "feels slightly wrong" and developers dismiss them.
From the field
A central government agency was rebuilding its main citizen-facing portal to meet the NZ Digital Service Design Standard. The team assumed that because the components were sourced from the NZ Government Design System, visual compliance was essentially free. What they discovered: NZGDS gives you components, not placement — and every team had interpreted spacing, heading hierarchy, and button sizing differently across six separate squads. A single cross-squad visual review session against the Figma master revealed 34 deviations, 11 of which would have failed the Design Standard's visual consistency criterion. The lesson: a shared design system removes maybe 60% of visual risk; the other 40% lives in how teams compose those components together, and only a deliberate review finds it.
2 The Rule
Compare what you see to what was designed. Every difference is a bug.
If the design says the button is blue and the website shows green, that's a bug. If the design says 16px font and the site shows 12px, that's a bug. Trust your eyes.
3 The Analogy
Proofreading a printed brochure against the design file.
A designer sends a brochure to a printer. When it arrives, you hold the printed copy next to the design file. Is the logo in the right place? Are the colours the same? You are checking if the printed version matches the design. Visual review is the same job, but for websites.
4 Watch Me Do It
Follow these four steps every time you check how something looks.
- Open the design file side-by-side with the website
- Check colours, fonts, spacing, and alignment
- Test every interactive state Hover over buttons. Tab through links.
- Resize the browser and check on a real device
| Check | What to look for | Result |
|---|---|---|
| Text over images | White text over clouds = unreadable | Fail |
| Macron characters | Māori words render correctly | Fail |
| Touch targets | Buttons big enough to tap on a phone | Fail |
| Logo | Same size and position as design | Pass |
Three failures found in two minutes. That's the power of looking.
Responsive design break reveals visual bugs across device sizes
A button looks perfect on desktop (blue, 200px wide) and mobile (blue, full width). But on tablet at 768px, the button overlaps text because the layout shifts at a non-standard breakpoint. The tester tested desktop and mobile but never 768px.
| Screen Size | Visual State | Issue? |
|---|---|---|
| 1920px (desktop) | Button: blue, left-aligned, 200px | Correct |
| 1024px (tablet landscape) | Button: blue, full width, readable | Correct |
| 768px (tablet portrait) | Button: blue, full width, overlaps text | BUG |
| 375px (mobile) | Button: blue, full width, readable | Correct |
5 When to Use It / When NOT to Use It
✅ Do it when...
- A new page or component is built
- A designer says "it's ready for QA"
- You are testing on different screen sizes
❌ Skip it when...
- You need to test logic or data
- You need to prove security
- There is no design file
Before you apply this technique, ask:
- Is your app visual-heavy (e.g., design tool, dashboard, e-commerce)?
- Do you have a design file to compare against?
- Can you test on multiple screen sizes and browsers?
- Is the design finalized, or still being iterated?
6 Common Mistakes
🚫 Only testing on your own laptop
I used to think: If it looks good on my screen, it's fine.
Actually: Test on a phone. Test on a different browser. Things break in surprising ways.
🚫 Ignoring hover, focus, and disabled states
I used to think: The normal state is the only state that matters.
Actually: Users hover with a mouse. They tab with a keyboard. Each state should match the design.
🚫 Trusting your eyes alone
I used to think: I can spot everything by looking.
Actually: Use a design file as your source of truth. Without it, you are guessing.
🚫 Missing subtle responsive design breaks
I used to think: If it looks good on desktop and mobile, it's fine.
Actually: Test the in-between sizes too (tablets, landscape phones). Designs often break at specific breakpoints you'll never find by testing just two sizes.
When this technique fails
Visual review fails when you test on only one device size or one browser. Also fails if you have no design file to compare against; you're just guessing. It also fails if your app is data-heavy or logic-focused (APIs, databases). Visual review is for UI-forward products.
7 Now You Try
Scenario: A designer gives you a design for a NZ café booking page. The live site shows a green button on the left, a heading in black, and the phone number as 0800 100 199 with spaces. The design shows: blue button centred, dark grey heading, phone 0800-100-199.
Your task: How many visual bugs do you see?
Three visual bugs:
| # | Bug | Design says | Site shows |
|---|---|---|---|
| 1 | Button colour | Blue | Green |
| 2 | Button position | Centred | Left-aligned |
| 3 | Heading colour | Dark grey | Black |
Note: The phone format might be a style guide difference. When in doubt, ask the designer.
Why teams fail here
- Testing only on the tester's own machine — a 27-inch 4K monitor is the worst device to catch responsive bugs because everything looks fine until you see it on a 375px phone.
- No design file, so visual review becomes a matter of personal taste — developers argue, testers back down, and real regressions ship.
- Skipping interactive states (hover, focus, active, disabled, error) because "the happy path looks fine" — these states carry critical brand and accessibility information and are almost never checked by developers in their own testing.
- Treating visual issues as low priority because they are "just cosmetic" — in customer-facing NZ government services, a misrendered macron, wrong contrast ratio, or broken touch target can directly breach the Digital Service Design Standard and exclude users with disabilities.
Key takeaway
Visual review is not about having good taste — it is about holding the product to a signed-off standard, and that only works when you have the design file open next to the browser.
8 Self-Check
Click each question to reveal the answer.
Interview Questions
What NZ hiring managers ask about Visual Review at the Grad level.
Q1. What is visual testing and what kinds of defects does it find that functional testing misses?
Strong answer: Visual testing checks the appearance of the application — layout, fonts, colours, spacing, images, and responsive behaviour. Functional testing verifies that actions produce correct outcomes but does not check that the page looks correct. Visual testing finds: broken layouts (elements overlapping or outside their containers), wrong fonts or colours (CSS regression), truncated text, images not loading, responsive design failures at certain screen sizes, and accessibility issues like insufficient colour contrast. A form can be functionally correct (submits data correctly) while visually broken (submit button invisible at 320px width).
Q2. You notice a pixel-level misalignment in a design. Is it worth reporting?
Strong answer: It depends on severity and context. A 2-pixel misalignment in a background decoration is usually not worth reporting. A 20-pixel misalignment in a navigation element that causes a call-to-action button to partially overlap a form field is worth reporting. I use the rule of thumb: would a user notice this? Would it affect their ability to use the page? Does it violate the brand guidelines or design system? I report with a clear screenshot annotating the issue and its location, with a note about whether it appears on mobile, desktop, or both.
Q3. How do you test visual responsiveness across many screen sizes efficiently?
Strong answer: I use browser DevTools' responsive design mode to quickly check at the key breakpoints: 320px (small phone), 375px (iPhone SE), 768px (tablet), 1024px (small desktop), and 1440px (large desktop). I note any layout issues at each breakpoint. For production sites, I also test on at least one real iPhone and one real Android device because DevTools emulation does not perfectly reproduce real device rendering. For systematic regression, I use visual regression tools like Playwright's screenshot comparison to automatically detect visual changes between releases.
Q1. What is the most important tool for a visual review?
The design file. You can't judge "right" without knowing what right looks like.
Q2. A button turns purple on hover. The design says dark blue. Is this a bug?
Yes. Hover states are part of the design. If the colour doesn't match, it's a bug.
Q3. Why should you resize your browser during a visual review?
Layouts break on different screen sizes. A page that looks perfect on a monitor might overlap on a phone.