A lot of design QA happens too late. The engineer opens a pull request. The designer reviews it. Then the comments arrive.
The spacing is off. The mobile view wraps badly. The loading state was never built. The button label changed. The empty state looks unfinished.
None of these are pull request problems. They are build problems that waited too long to be noticed.
A pull request is a bad place to discover basic design issues. By then the work already feels finished. The code is organized. The files are changed. Everyone is thinking about approval.
That makes design feedback feel heavier than it needs to. A comment like "this should wrap differently on mobile" is easy to handle while the component is still being shaped. It feels annoying after the engineer has already cleaned up the branch and asked for review.
Design QA works better when it happens while the interface is still soft.
Most design bugs hide outside the happy path. The screen looks good when there is one perfect example of data. Then real states show up.
Before opening a PR, check the obvious ones:
If you are building a team member card, do not only test "Ava Chen, Designer." Try a long name. Remove the avatar. Add a long role. Make the invite pending. Make the action fail.
That is where the actual component shows up.
Responsive bugs are easy to find and expensive to discuss. Drag the browser narrower before you ask anyone else to look.
You do not need a full device lab for every change. Start with a simple pass:
Watch what happens to the important parts. Does the primary action stay visible? Does the table overflow on purpose? Do filters wrap in a way that still makes sense? Does a card become too tall because one title wrapped?
A design is not responsive because it uses percentages. It is responsive when the important relationships survive the resize.
Keyboard QA catches problems that visual review misses. Press Tab through the new UI once.
Ask simple questions:
This is not only accessibility work. It is interaction quality. If focus disappears, the product feels broken for anyone who uses the keyboard.
Copy often looks fine in isolation and wrong in the product. A button label may be clear but too long. A helper sentence may push the form out of rhythm. An error message may explain the problem but not the recovery.
Read the UI as if you are using it, not as if you are reviewing text.
For example, "Your request could not be processed" is technically an error message. But "We could not save your changes. Try again." is more useful because it tells the user what failed and what to do next.
Design QA does not need to become a huge process. Most of the value comes from one short pass before the PR.
The goal is not to catch everything. The goal is to catch the obvious product issues before they become review comments.
A better PR is not just cleaner code. It is an interface that has already been used once by the person who built it.