A mockup is approved. A live experience is verified.
The launch-day gap is a delivery problem
A site can be technically complete and still disappoint. A logo may sit low, type may wrap sooner, or the mobile layout may lose its calm hierarchy. Each difference is small, but together they make the live site feel diluted.
That gap rarely comes from a developer deciding to ignore the work. More often, it appears because the handoff described a single ideal screen rather than the rules that govern the interface. A static mockup cannot automatically explain what happens when content grows, when a user tabs through a form, or when a card has no image. Design QA turns those implied decisions into a shared, testable standard before launch.
This is why strong UI/UX design connects visual craft with product behaviour. The principles behind a clear interface still have to survive real content, devices, browsers, and inputs. Our guide to UI/UX design principles explains the choices that shape experience; design QA confirms that those choices remain intact in the build.
Make the handoff testable before development starts
A useful handoff records decisions that developers, project managers, and reviewers interpret the same way. It does not prescribe every CSS property; it captures the rules whose absence creates visible drift or broken interaction.
Specify a spacing and type scale, not isolated measurements
A mockup may show 24 pixels between one heading and a paragraph, 32 pixels between the next pair, and a new value later in the page. Without an underlying scale, those values invite guesswork and create near-misses during implementation. Name the spacing tokens, container widths, grid behaviour, font sizes, line heights, weights, and breakpoint adjustments that the system uses. State when an exception is intentional. Then a reviewer can ask whether a section follows the approved scale instead of debating whether it feels close enough.
That makes design delivery more durable: later pages reuse the same decisions, while engineering maintains fewer values.
Design the states beyond the ideal screen
Every component needs a behaviour contract, not only a default appearance. Define hover, pressed, focus, disabled, selected, loading, success, empty, validation, and error states where they apply. Note whether an alert moves the surrounding layout, whether an unavailable action is hidden or disabled, and where an inline error appears. A form with a graceful empty state is not an edge case; it is an ordinary version of the product that deserves the same design attention as the successful path.
The same applies to menus, accordions, filters, and data cards. If a state affects a user’s decision or progress, it belongs in the handoff.
Use real content lengths and awkward data on purpose
Placeholder copy makes every card cooperative; production content does not. Include short and long titles, missing images, long names, currency values, multi-line errors, and translated copy where relevant. Identify whether text truncates, wraps, scrolls, or changes component height. Provide intended image crops and aspect ratios.
Show the widest likely navigation and button labels.
Document what remains visible when a list has one item or none.
These examples prevent the familiar late-stage surprise of a design that matched until real copy was entered.
Run design QA as a structured review, not a final glance
Start design QA on a staging build close enough to release for findings to matter. Agree on the approved source, in-scope routes and components, test content, browsers, and the person who can confirm that a difference is intentional. Give the review an owner and closure list.
Compare the approved design and the build side by side
Open the reference frame and the live page at the same viewport width. Move through the page section by section, then use an overlay or rapid alternation to reveal shifts in alignment, whitespace, typography, image cropping, colour, and hierarchy. Start with the overall structure before chasing a one-pixel discrepancy. A changed container width can produce ten apparent spacing issues; finding the root rule is faster than logging each symptom.
Capture evidence at the actual viewport and route. A credible review checks repeated components and their variations, not one large screen alone.
Test interaction, keyboard use, and focus order
Clicking through a happy path is necessary but incomplete. Hover elements, open overlays, submit invalid forms, interrupt loading, and then use the keyboard from the top of the page. Focus should be visible, follow a logical order, reach every usable control, and remain contained where a modal requires it.
Accessibility testing belongs in this pass because it reveals both functional and visual defects. The practical priorities in our website accessibility guide are a useful companion when reviewing focus, contrast, labels, and feedback. A focus outline is not a development blemish to remove; it is a designed state to make legible.
Check repeated patterns before individual exceptions
Review buttons, cards, fields, headings, and modules wherever they recur. Correcting one shared component at the source may resolve a whole class of findings. Confirm that intentional variation has a documented reason.
Test responsive behaviour and motion under real conditions
Responsive QA is not a desktop review followed by a narrow simulator. Test the widths where navigation collapses, columns stack, labels wrap, hero crops change, or touch targets become cramped. Review defined desktop, tablet, and mobile widths, plus the awkward widths around each transition.
Use real viewport widths, not device names alone
A label such as tablet leaves too much room for interpretation. Specify the widths that preserve two columns, turn a control into an icon, and change horizontal padding. Resize slowly, not only at endpoints, to find orphaned headings, overflowing tab rows, and unbalanced cards.
Distinguish a component that can shrink from one that needs to recompose. A data table or dense filter row may need a small-screen alternative, not smaller type.
Treat motion as part of the interface contract
Motion communicates cause and effect: a panel opens, a save confirms, or a menu becomes available. Verify duration, easing, direction, interruption behaviour, and a reduced-motion alternative. Check that transitions do not conceal focus, block interaction, or leave content unexpectedly off screen.
Write defects that can be fixed without a second guessing round
“The hero feels off” may be true, but it forces diagnosis. Clear defect writing separates observable deviation from interpretation and makes verification straightforward.
Give each finding a location, evidence, rule, and expected result
Name the route, component, viewport, browser, and state. Attach evidence. Point to the approved frame, token, interaction note, or acceptance criterion that establishes expected behaviour. Describe the current and expected result, severity, and whether the condition is repeatable.
Observed: On the pricing page at 768 pixels, the annual-plan button wraps to two lines and pushes card heights out of alignment.
Expected: The approved tablet rule keeps plan cards aligned while preserving a readable button label.
Acceptance: All plan cards align at the defined tablet width with the real annual-plan copy.
That detail directs effort toward a testable outcome and makes verification independent of an earlier conversation.
Distinguish a defect from a late design change
A defect departs from an agreed decision: the build fails to match a specified layout rule, state, interaction, or accessibility requirement. A late design change introduces a new decision, such as a new filter or different hero copy after scope approval. Both may be valuable, but they need different owners, estimates, and release decisions.
Calling every new request a bug hides the cost of change; calling every mismatch a preference leaves quality unprotected. Keep the approved source available and triage findings with the designer and delivery lead. The aim is clarity, not winning a pixel argument.
Reduce future QA load with a design system
QA becomes lighter over time when the site has fewer one-off decisions to revalidate. A design system gives teams shared tokens, components, states, and usage rules. When a button’s focus treatment or a card’s spacing is fixed at the component level, a correction can improve every instance instead of producing a list of page-specific patches.
That does not eliminate review. It changes the review from repeatedly rediscovering basic rules to checking whether new work uses them correctly. For teams building in Framer, our article on a design system for a growing site shows why reusable foundations support consistency as pages multiply.
The most effective design systems are maintained through delivery. Add a newly clarified error state, responsive rule, or content constraint back to the component guidance. Over time, the handoff becomes more complete, visual drift declines, and each design QA pass can concentrate on genuinely new behaviour.
Make design QA a release gate, not a recovery task
The best time to protect design quality is before launch-day pressure turns every finding into an emergency. Define the handoff, build against testable rules, schedule a focused QA pass, and give the team a clear way to classify and close issues. The result is not a site that merely resembles a mockup. It is a live experience that carries the design’s hierarchy, confidence, and usability into the conditions users actually encounter.
If your next launch needs that level of continuity, a considered UI/UX design process can make design delivery and implementation easier to evaluate from the first wireframe through release.
