A Design QA Pass After the Page Is Built
A page that has just come back from the build is a peculiar object. It compiles. It renders. The buttons do the thing they were asked to do. And still, standing in front of it, something feels off in a way that resists the bug tracker, because nothing is technically broken. The design QA pass exists for exactly this gap: the stretch of work between "it functions" and "it is right," where most of the real quality of an interface gets decided and most teams quietly run out of patience.
Call it a pass, singular, because it should have an end. A design QA that sprawls forever becomes a second design phase with none of the authority of the first, and it will lose. The pass has a start, a scope, and a moment when someone signs off and the page ships. Treating it as an ongoing vibe check is how teams end up with a staging environment full of half-finished tweaks and a launch date that keeps sliding.
The page that passes every test and still looks wrong
The most common failure mode is a page that satisfies its acceptance criteria to the letter. The spacing values match the spec. The colors are the approved hex codes. The breakpoints fire at the documented widths. And the whole composition reads as slightly dead, because specs describe individual properties and never describe how those properties behave when they sit next to each other at three in the morning on a cheap laptop.
A button spec might say 16px vertical padding. It will not say that the button now sits four pixels too close to the paragraph above it because the paragraph's bottom margin collapsed against the container. That four-pixel gap is invisible in a spec sheet and immediately visible to a person scrolling. Design QA is the discipline of noticing the things a spec cannot contain.
Render the page at the sizes nobody tested
The build almost always gets checked at the two or three canonical widths: desktop, tablet, phone. Those are the widths in the design file, so those are the widths in the QA script. The trouble lives in between. A page checked at 1440 and 375 has almost certainly never been looked at at 1024, or at 768 in landscape, or at 320 on a device that still exists in the wild.
Dragging the browser window slowly from wide to narrow, watching the layout reflow in real time, is more diagnostic than any set of fixed screenshots. Watch for the moment a two-column arrangement collapses into one and whether the reading order survives that collapse. Watch whether a heading wraps to a single orphan word. Watch whether a long button label refuses to wrap and pushes a card wider than its parent. These are cheap to fix during the pass and expensive to fix after a client sees them on their own monitor.
One more width deserves its own slot: the very large one. A layout designed for a 1440 screen and dropped onto a 2560 display will often reveal a paragraph line length that runs to 140 characters, a joyless wall of text that the designer never saw because their monitor was smaller. Constrain the reading column or accept that half the audience is reading a newspaper broadsheet.
Follow the first three seconds of a cold load
By the time a designer reviews a page, they have loaded it forty times. The fonts are cached. The hero image is in memory. The layout is settled before the first paint. That experience has almost nothing in common with the person arriving from a search result on a mid-range phone over a mediocre connection.
The QA pass should include a hard reload with the cache disabled, ideally on a throttled connection, watching what appears first. If the page renders in a fallback font and then visibly snaps to the brand font, that snap is a real moment in a real person's experience of the brand. If the hero image loads last and shoves the headline down the page, every visitor sees the page jump. Neither issue is a bug. Both are design problems, and both belong in this pass.
Counting the layout shifts on a cold load is a useful habit even without tooling. Watch the page like a hawk for the first two seconds and count how many times content moves. More than one visible jump is worth a conversation.
Read the copy out loud, in the built page
Copy gets approved in a document, in a font the page will never use, at a size the page will never render. Then it gets poured into the build and nobody reads it again, because everyone has already signed off. This is a mistake. A headline that looked punchy in a Google Doc can turn into a three-line monster inside a 600px container, and a subhead that read fine in isolation can now sit directly under a button and look like a caption for it.
Reading the rendered page aloud catches things the eye skips: a label that no longer fits its button, a form field whose helper text has wrapped into an awkward two-liner, a navigation item that now truncates with an ellipsis. It also catches the tonal collisions that happen when copy from three different writers gets assembled into one scroll. A jaunty CTA sitting above a somber legal paragraph is a design issue, and it is one that only shows up when the words are in their final positions.
Keyboard, focus order, and the tab walk
Somewhere in the pass, close the mouse. Tab through the entire page from the address bar to the last interactive element, and pay attention to the order things light up. The focus ring is a design element whether or not it was designed; if it is the browser default, it will be a thin blue outline that may or may not be visible against the background colors that were actually chosen.
The order matters as much as the visibility. A tab sequence that jumps from the header to the footer and then back into a sidebar tells a keyboard user that the page's structure is decorative. A focus ring that disappears entirely against a light gray card means a person navigating without a mouse has no idea where they are. Neither of these shows up in a visual review, and both are design failures in the plainest sense: the page does not communicate its own state.
This is also the moment to check the small interactive states that designers mock up and builders approximate. Hover, active, focus, disabled, error, and success. Six states per control, and the built page will typically have three of them. The missing ones are what a person hits when something goes wrong, which is precisely when the interface most needs to be legible.
Squint at the whole page before zooming into details
Zoom out. Way out, to 50 percent or less, until the text is unreadable and the page becomes a set of gray blocks. At that scale, the composition either holds together or it does not. Uneven vertical rhythm shows up as clumps. A section with too much air reads as a gap in the flow. Two adjacent sections with similar background colors blur into one undifferentiated slab.
This is a crude test and an honest one. It strips away the individual decisions and shows the skeleton, which is the part most likely to have drifted during build. A designer who has been staring at 14px body text for an hour has lost the ability to see the page as a whole. Squinting gets it back in about four seconds.
Put the page on a real phone, outdoors, at arm's length
The devtools phone emulator is a useful lie. It gets the width right and the light wrong. A page reviewed on a bright monitor at 100 percent brightness, at a distance of two feet, is being reviewed under conditions no one will ever encounter it in. A real phone, held at arm's length, tilted away from a window, is closer to the truth.
At that distance, the failures are immediate. Body text at 15px is too small to read comfortably. A gray-on-white label that looked refined on a monitor becomes invisible in daylight. A tap target sized at 32px is technically tappable and practically a coin toss. The thumb has a habit of hitting the wrong thing, and the wrong thing is often an advertisement or a destructive action.
Spend five minutes actually using the page on the phone instead of judging it. Fill out the form. Open the dropdown. Hit back and see whether the scroll position survives. These behaviors live well outside the visual spec and squarely inside the experience the page is being built to deliver.
The end of the pass is a signed sheet, not a feeling
A design QA pass that ends with everyone vaguely agreeing the page looks good has no teeth and no memory. It ends with a list: the issues found, the ones fixed, the ones consciously deferred, and the name of the person who decided the deferred ones were acceptable. Not a formal document, necessarily, but a written record. The point is that a page shipped with known compromises is a decision someone owns, not an accident nobody noticed.
Lists like this tend to shrink the next pass. When the same class of issue (collapsing margins around cards, focus rings disappearing on tinted backgrounds, line lengths running wide on large monitors) shows up three builds in a row, it is no longer a QA finding. It is a missing rule in the design system, and it should be fixed once, upstream, so the next page arrives at its QA pass with fewer holes to plug.
Which is the quiet argument for doing the pass properly at all. Each one is a small audit of where the design intent and the build have drifted apart, and the drift is almost always the same handful of places. Sign the sheet, ship the page, and go fix the pattern that keeps showing up in the margin.
