Visão geral
Design QA é uma técnica de entrega usada para garantir que o produto implementado corresponde às intenções de design — detectando desvios de espaçamento, tipografia, cores, comportamentos e acessibilidade antes que cheguem ao usuário final. A utilidade dela está menos no ritual em si e mais na forma como ajuda o time a transformar uma dúvida de projeto em evidências, decisões ou próximos passos observáveis.
Ela faz sentido quando use antes de qualquer lançamento ou merge de feature, ao revisar implementação de componentes novos do design system, ou ao detectar regressões visuais após atualizações de dependências. Ao aplicar Design QA, o time deve chegar a lista de desvios com severidade e evidência e Aprovação ou bloqueio para lançamento, mantendo rastreabilidade entre o que foi observado, o que foi decidido e quais limites ainda precisam ser considerados.
Como entra no fluxo
Design QA entra quando já existe uma pergunta de trabalho clara e o time precisa conduzir uma atividade estruturada antes de avançar para decisão, protótipo, priorização ou entrega.
Atenção ao usar
QA manual não escala para produtos com muitos fluxos e estados.
Combina bem com
- Accessibility Annotation
- Heuristic Evaluation
- Wireframing
Para que serve
Garantir que o produto implementado corresponde às intenções de design — detectando desvios de espaçamento, tipografia, cores, comportamentos e acessibilidade antes que cheguem ao usuário final.
Quando usar
Use antes de qualquer lançamento ou merge de feature, ao revisar implementação de componentes novos do design system, ou ao detectar regressões visuais após atualizações de dependências.
Contexto
Objetivos
Outputs
Situações ideais
- equipe desalinhada
Como executar
Pré-requisitos
- Implementação disponível em ambiente de staging ou preview
- Especificações de design acessíveis para comparação
- Critérios de aprovação definidos — o que é blocker vs. nice-to-have
Materiais
- Acesso ao ambiente de staging
- Arquivo de design para comparação
- Planilha de issues com severidade
- Ferramenta de anotação de screenshot
Passo a passo
- 1Percorra os fluxos implementados com as especificações ao lado.
- 2Verifique espaçamentos, tipografia, cores e componentes contra o design.
- 3Teste comportamentos de interação — hover, focus, estados, transições.
- 4Verifique responsividade nos breakpoints especificados.
- 5Teste com teclado e leitor de tela se acessibilidade é requisito.
- 6Documente desvios com screenshot, severidade e referência ao design original.
- 7Compartilhe o relatório com o time para triagem e correção.
Critérios de qualidade
- Critérios de severidade (blocker/major/minor) são definidos antes da revisão
- Issues têm screenshot e referência ao design correto — não só descrição textual
- Comportamentos interacionais são testados, não só aparência estática
- Desvios são comunicados sem julgamento — o objetivo é qualidade, não culpa
Dicas
- Faça QA em múltiplos dispositivos — não só no desktop do designer.
- Separe blocker (impede lançamento) de minor (pode ir com ticket aberto).
- Use pixel overlay tools para comparação precisa — olho nu erra muito.
- Inclua QA no definition of done do time — não como etapa separada opcional.
Antes (entradas)
- Implementação em staging
- Especificações de design
- Critérios de aprovação
Depois (saídas)
- Lista de desvios com severidade e evidência
- Aprovação ou bloqueio para lançamento
Variações
QA Visual Automatizado
Usa ferramentas como Percy ou Chromatic para comparar screenshots automaticamente a cada deploy — detectando regressões visuais sem revisão manual de cada fluxo.
QA de Design System
Revisão periódica de todos os componentes do design system para garantir que implementação e documentação estão alinhadas após updates de dependências ou mudanças de especificação.
Uso estratégico
Quando evitar
- Implementação ainda está em desenvolvimento ativo — QA prematuro gera retrabalho
- Time não tem acordado o que é blocker — revisão vira debate subjetivo
Limitações
- QA manual não escala para produtos com muitos fluxos e estados
- Não detecta problemas de performance ou comportamento em condições reais
Riscos
- QA virando gatekeeping onde designer bloqueia lançamento por preferência pessoal
- Issues de baixa severidade atrasando lançamentos importantes
Exemplos de uso
- 01Revisar implementação de novo fluxo de checkout antes do go-live.
- 02Auditar componentes de design system após migração de versão do framework.
- 03Verificar responsividade de novo dashboard antes de lançar para mobile.
Perfis responsáveis
Também conhecido como
Referências e leitura
Ajude a melhorar este conteúdo
Encontrou erro, lacuna técnica ou exemplo fraco? Envie uma correção com contexto para revisão.
