How to QA your own design before it goes to engineering

Engineering finds design problems that design didn't. Not because engineers are more careful, but because the process of translating a design into code exposes questions the design never answered: what does this look like when loading? What happens if this text is twice as long? Which of these three slightly different red values is correct?

The gap isn't inevitable. A designer who reviews their own work the way an engineer builds it will surface most of these questions before handoff. The result is faster implementation, fewer revision cycles, and less time spent interpreting which of three shades of gray the button border is supposed to be.

Start by reading it as a list of decisions

Before looking at any individual component or screen, read the design as a set of decisions that will need to be implemented. Every color value, every spacing unit, every font size, every border radius. Ask whether each one is intentional or incidental.

Incidental values accumulate when designers work visually: you drag something until it looks right, and the number it lands on is 23px because the snap grid wasn't enabled and 23px happened to look right. To an engineer, 23px is a valid spacing value. To a design system, it's a violation that will quietly propagate if nobody catches it.

Running a quick pass for off-scale values, anything that isn't in the spacing scale, type scale, or color tokens, catches most of this. In Figma, the Inspect panel shows exact values; a component using a 1px border radius instead of the 6px token is obvious once you're looking for it.

Check every state, not just the happy path

The screen that ships is the screen that handles every state. Most Figma files contain the loaded, populated, success state and nothing else. Before anything goes to engineering, every component in the design should have an answer to the following: what does it look like when loading? When empty? When it contains an error? When the data is at the minimum expected volume and the maximum?

If the component doesn't have variants for these states, engineering will invent them. Sometimes the invention is fine. More often it's inconsistent: a spinner in one place, a skeleton in another, an empty div in a third. The inconsistency is invisible until it's in production and someone is looking at it in context.

Empty state and error state design is covered elsewhere, but the QA process is the moment to confirm those states exist in the file, are linked from the relevant screen or component, and are complete enough to implement from. "We'll design that in the ticket if it comes up" is how gaps become tech debt.

Simulate the keyboard, not just the mouse

Most design QA is done with a mouse or trackpad. Most accessibility failures are discovered by keyboard users and screen reader users after shipping.

The minimum QA pass for keyboard accessibility is to trace the tab order through every interactive element in the design and confirm it's logical. A modal that opens and leaves focus behind the overlay fails this check. A form where tabbing through the fields skips one of them fails. A custom dropdown that can't be opened by pressing Enter fails.

The design file rarely surfaces tab order problems because Figma doesn't simulate keyboard navigation. This means the check has to be intentional: the designer traces through the expected tab order manually, in the correct sequence, and confirms that every interactive element is reachable and operable.

Focus states are a related gap. Many design files show a hover state for interactive elements. Fewer show a focus state. Without an explicit focus state in the design, engineering will either default to the browser's focus ring (which may not match the visual language) or remove it (which is an accessibility violation). If the focus state isn't in the file, add it.

Check what happens at real text lengths

A component that works beautifully at the text length used in the mockup might fail at the text length it will actually contain. This is the category of problems that's most reliably caught during design QA and most reliably missed.

The check is simple: take every string in the design and ask whether you've used a realistic value. Button labels that are longer in some locales. Error messages that are longer than the success messages they replace. Names that are 40 characters. Description text that someone wrote in a rush and didn't edit.

The most useful versions of this check use actual extreme values: the longest known user name in the system, the longest string returned by the API, the translated string in the most verbose supported language. If those aren't available, synthetic extremes are the next best thing. Use them.

Annotation is QA documentation

Good annotation is what separates a design file that can be implemented from one that generates ten Slack messages per day. The annotation is the designer telling the engineer: here is what I decided and why, so you don't have to guess.

Useful annotation covers the things that aren't obvious from looking at the design: which behaviors are interactive and which are decorative, what the hover and focus and active states are, what happens when content overflows, which values are tokens and which are hardcoded exceptions, and why any exception exists.

The format matters less than the completeness. Figma comments, a side panel, a separate annotation layer: any of these work. What doesn't work is annotating only the interesting parts and assuming the rest is self-explanatory. To a designer, the expected behavior of a card hover is obvious. To an engineer implementing a card for the first time, the question of whether the shadow animates or appears instantly, and at what speed, is a 20-minute rabbit hole without a spec.

Run it in the browser before calling it done

The fastest way to find problems that only appear in production is to build a rough prototype in the browser, or to ask for a rough implementation early before the design is treated as final.

Designs in Figma are static approximations of an interface. They don't render fonts the same way. They don't scroll the same way. The spacing that looks right in a 1440px frame might feel off in an actual browser window where the scrollbar takes 15px. Color values render differently on screen than on Figma's canvas, particularly for anything with transparency.

None of these differences are fatal, but catching them before the engineer has built the full component at spec is better than flagging them afterward. A 15-minute review of an early implementation catches rendering issues, spacing anomalies, and font rendering problems that no amount of Figma inspection will surface.

---

The designer who ships a well-prepared file isn't just being thorough. They're making a choice about where design problems get solved: before implementation, when they're cheap to fix, or after, when they've already been built.