It took me a while to understand the need for QA Design.

But what is it, after all? While traditional QA focuses on functional bugs, design QA ensures visual fidelity and a consistent experience.

In small teams, QA often boils down to validating if something works. But after a few frustrations, I realized the importance of reviewing the design before production.

I started structuring these reviews to help the development team and maintain visual consistency. Screen by screen, feature by feature.

When we're the only UX on the project, details can slip through the cracks. Creating UI and UX checklists helps avoid mistakes and keeps the project aligned.

Development Follow-up

The focus here is to review the screen before delivery.

In my case, developers are involved from the project's conception, ensuring the proposed solution is feasible from the start, reducing rework.

In the last 4 projects, I reviewed all screens and flows (avoiding having creative dev ideas go straight into production hehe), validating fidelity to Figma and interaction quality. Additionally, I tested (even informally) with users — because design fidelity doesn't necessarily mean good usability.

This process brought more refined deliveries, fewer production errors, and more confidence for everyone. In the end, we launched projects with great usability and accessibility.

How I incorporated QA Design into my routine:

Three practices make all the difference:

• QA Reviews: UX + dev meetings to review flows together and ensure alignment.

• Figma Documentation: Visual notes make it easier to correct issues and optimize the team's work.

• Heuristic Testing: Reviewing whether Nielsen's heuristics are being followed ensures consistency in the experience.

I still have a lot to learn, but I’ve already seen the benefits in practice.