Visual QA, and turning user behaviour into design decisions

Attention to detail is a skill you can practise, not a personality trait. It means spotting the gaps between a design and what was built, the inconsistencies inside a product, and the difference between what users do and what the team assumed they would do.

This part has two halves. The first is visual QA: checking your own files, then checking the build. The second is research: watching real behaviour and turning it into decisions you can defend.

Check your own design first

Before anyone else reviews a file, run through it yourself. Most of these take seconds once they become a habit.

• Spacing. Is every gap a token on the spacing scale? Look for stray values such as 13px or 17px.
• Colour. Does every fill come from a variable, or are there detached hex values?
• Type. Is every text layer using a system text style, with no local overrides?
• Alignment. Does every element sit on an edge or the grid?
• Icons. One set, consistent sizes, the same stroke width.
• Radius and shadow. The same values for the same kind of surface.
• States. Hover, focus, disabled, loading, empty and error are all designed.
• Stress cases. Long text, a small screen and a lot of data: what happens to each?
• Accessibility. Contrast and touch target size pass.
• Copy. Consistent capitalisation (usually sentence case), punctuation and terms.
• Layers. Names and structure a developer can follow.

Check the build against the design

Design QA, sometimes called UI review, happens once a feature reaches a staging or preview link. Plan for it; it is the step that catches what handoff missed.

1. 01Open the build and the design side by side.
2. 02Use browser DevTools to inspect spacing, font size and colour on the real elements.
3. 03Overlay a screenshot of the design on the build where small differences are hard to see.
4. 04Run the whole flow with only the keyboard, then again at 200% browser zoom.
5. 05Check other breakpoints, other browsers and dark mode.
6. 06Log each issue with a severity.

Writing an issue engineers can act on

A good issue answers where, what was expected and what actually happened, with evidence. It should be fixable without a meeting.

Title     [Create database] Primary button uses the wrong hover colour
Where     /databases/new, step 2, desktop 1440px, Chrome
Expected  Hover background = color.bg.brand.hover  [Figma link]
Actual    A lighter blue, not from the token set   [screenshot]
Severity  Low

Audit the whole product

An inconsistency audit looks across the product rather than at one feature. Take screenshots of every screen and group them by kind on one board: every button, every modal, every table header, every empty state. Seen together, the differences are obvious. A board showing how many different buttons a product has is often the most convincing argument for investing in a design system.

From behaviour to insight

Good design decisions rest on what users do and what they say, not on what the team guesses. Research methods can be mapped on two axes: behavioural (what people do) against attitudinal (what they say), and qualitative (why) against quantitative (how many). Nielsen Norman Group’s overview of research methods uses this same framing.

Usability testing

Watching people try to complete real tasks is often the most useful research a team can do. Jakob Nielsen’s well-known guidance is that small rounds with around five users uncover most of the major problems, and that several small rounds beat one large one.

• Give a task, not instructions. “Create a PostgreSQL database with three replicas”, not “click New, then choose PostgreSQL”.
• Ask people to think aloud while they work, so you hear their reasoning as it happens.
• Avoid leading questions. “Was that easy?” suggests an answer. “How did that step feel?” does not.
• Measure what you can: task success, time on task, error count, and a standard questionnaire such as SUS.

Analytics and other behavioural signals

• Funnels show the step where people drop off.
• Heatmaps and click maps show where people click, and where they don’t.
• Session recordings show rage clicks, clicks on things that aren’t clickable, and people backing out of a page.
• Feature adoption shows how many people use something new.
• Support tickets and sales calls are research too. Repeated “where do I find…?” questions point to a discoverability problem.

Google’s HEART framework

Kerry Rodden, Hilary Hutchinson and Xin Fu at Google proposed HEART as a way to choose user-centred metrics. Each letter is a category; for each, a team picks goals, the signals that show progress, and the metrics that track them.

Observation is not insight

“Users don’t click this button” is an observation. “Users don’t realise it is clickable, because it looks like a label” is an insight. An insight always contains a why, and the why is what points to a design change.

Observation   Many users drop off at the "Configure" step
                ↓  why? Watch session recordings, interview a few users
Insight       Users don't know what "storage class" means
              and are afraid a wrong choice will break the setup
                ↓
Design idea   A recommended default, a short inline explanation,
              advanced options tucked away
                ↓
Measure       Compare drop-off before and after, or run an A/B test

• Affinity mapping: group notes from research into themes.
• Personas and Jobs to be Done: “When I…, I want to…, so I can…”.
• Journey maps: steps, actions, feelings, pain points and opportunities along one path.

Next in the series

Craft and research only count if other people can follow your reasoning. Part 13 covers the job itself: working with product and engineering, writing clearly, building a design system case study, and preparing for interviews.