Para avaliar a qualidade de um Design System, examine o que ele cobre, como é usado no produto real, se seus componentes funcionam com acessibilidade e como a equipe documenta e corrige problemas. Uma biblioteca extensa, por si só, não demonstra qualidade. O diagnóstico precisa comparar arquivos de design, código, telas publicadas e decisões da equipe, com exemplos verificáveis.
Este roteiro ajuda você a fazer essa avaliação sem transformar uma nota de maturidade em veredito. Ao final, cada problema deve ter uma evidência, um impacto observado ou plausível, um responsável e uma próxima ação. Se você ainda está definindo o sistema, comece pelo guia de Design System; aqui o foco é diagnosticar um sistema que já existe.
O que avaliar antes de dar uma nota ao sistema
Delimite primeiro o objeto da avaliação: quais produtos, plataformas, equipes e versões entram no recorte? Um sistema pode funcionar bem no aplicativo e ter implementação divergente no site. Registre a data da análise, a versão da biblioteca e os fluxos escolhidos. Isso permite comparar resultados depois de uma correção.
Selecione dois ou três fluxos importantes, como cadastro, busca e pagamento. Em cada um, escolha componentes frequentes e componentes críticos, especialmente formulários, mensagens de erro e navegação. Converse com quem desenha e desenvolve essas telas. A amostra é uma forma prática de começar, não uma prova de que todo o produto foi auditado.
| Dimensão | Pergunta de diagnóstico | Evidência que você pode coletar |
|---|---|---|
| Cobertura e consistência | O sistema atende aos padrões mais usados e mantém o mesmo comportamento entre canais? | Inventário de fluxos, componentes em design e código, variações em produção |
| Adoção | As equipes usam as versões oficiais onde elas resolvem o problema? | Amostra de telas e repositórios, exceções registradas, relatos das equipes |
| Acessibilidade | Os componentes funcionam com teclado, leitor de tela, zoom e estados de erro? | Testes manuais e automatizados, problemas reproduzíveis, critérios WCAG aplicáveis |
| Documentação | É possível escolher, implementar e adaptar um padrão sem adivinhar suas regras? | Página do componente, exemplos, estados, orientações de conteúdo e acesso |
| Governança | Há responsáveis e um caminho claro para propor, aprovar, publicar e corrigir mudanças? | Histórico de versões, decisões, solicitações e prazo de resposta |
Prepare uma amostra reproduzível
Monte um inventário simples com produto, plataforma, fluxo, URL ou tela, data e versão do sistema. Em seguida, selecione um fluxo de alto uso, outro com formulários ou decisões críticas e um fluxo recente que ainda está em evolução. A seleção deve refletir o produto que você quer melhorar, não apenas as telas mais fáceis de inspecionar.
Em cada fluxo, marque as ocorrências elegíveis de três a cinco padrões recorrentes. Guarde links permanentes para o arquivo de design, a documentação e o código quando acessível. Se a amostra incluir apenas desktop, anote essa limitação. Repita o recorte depois das correções, mantendo as mesmas regras de seleção.
Para organizar o trabalho em uma sessão curta, reúna uma pessoa de design, uma de desenvolvimento e alguém responsável pelo produto. Reserve uma etapa para inspecionar as telas sem consultar a biblioteca e outra para explicar as diferenças com a equipe. Isso reduz a chance de classificar uma exceção deliberada como erro.
Cobertura e consistência: compare o sistema com o produto
Liste os padrões recorrentes nos fluxos escolhidos e procure seus equivalentes na biblioteca de design, na implementação e na documentação. A ausência de um componente raramente é tão importante quanto a ausência de um comportamento necessário: validação de formulário, carregamento, erro, sucesso, responsividade e conteúdo podem mudar a experiência mesmo quando o botão parece idêntico.
Para cada divergência, anote onde ela aparece e se existe uma razão legítima. Uma variação pode atender a uma necessidade específica; outra pode ser dívida acumulada. Não force a padronização quando ela prejudicar a tarefa. O projeto de Design System do Sebrae/PR é um exemplo do acervo da CamaraUX para contextualizar o trabalho com um sistema existente, sem atribuir a ele os resultados deste roteiro.
A documentação de um componente é uma referência para comparação, não uma evidência de que o produto o implementa corretamente. Faça a inspeção dos dois lados: o que o sistema prescreve e o que a pessoa encontra na interface.
Adoção real: veja as telas publicadas e o código
Adoção não é o número de pessoas que abriu a biblioteca. Registre, na amostra definida, quantas ocorrências elegíveis usam o componente oficial, quantas usam uma adaptação aprovada e quantas foram recriadas localmente. Uma conta possível é ocorrências oficiais ÷ ocorrências elegíveis. Declare o recorte e as exclusões. Esse percentual é um sinal para investigação, não uma medida universal de qualidade.
Quando houver uma substituição local, pergunte por quê: falta de um estado, dificuldade de instalação, desempenho, incompatibilidade com a plataforma ou desconhecimento da documentação? O modelo de maturidade do U.S. Web Design System trata a adoção como evolução de princípios, orientações e código, em vez de exigir que toda equipe implemente tudo de uma vez.
Como interpretar a taxa de adoção
Suponha que 40 ocorrências na amostra poderiam usar um campo de texto oficial. Se 26 usam o componente oficial, 8 usam uma variação aprovada e 6 são implementações locais sem justificativa, a taxa estrita é 26 ÷ 40 = 65%. Registre também as oito variações aprovadas separadamente. Colocá-las no mesmo grupo das seis substituições esconderia uma diferença importante para a equipe.
A conta não explica sozinha a causa. Compare as versões em uso, verifique se o componente oficial atende aos estados necessários e pergunte aos times sobre barreiras de adoção. Se a implementação oficial tiver um problema, uma taxa maior pode apenas espalhar o mesmo problema por mais telas. Este exemplo é hipotético e os números servem somente para mostrar a leitura da amostra.
Acessibilidade: teste o componente e o fluxo completo
Um componente acessível no catálogo pode se tornar inacessível quando é combinado com outros elementos. Teste a versão publicada nas tarefas escolhidas: ordem e visibilidade do foco, operação pelo teclado, nome e estado anunciados por tecnologias assistivas, mensagens de erro, contraste, ampliação de texto e comportamento em telas pequenas. Use os critérios aplicáveis das WCAG 2.2 e registre o critério relacionado a cada falha.
A lista de acessibilidade do GOVBR-DS inclui contraste, tecnologias assistivas, formulários, responsividade, documentação e testes. Ela ajuda a planejar a inspeção, mas uma lista preenchida ou um teste automático sem erros não certifica a experiência completa. Inclua avaliação manual e, quando possível, pessoas que usam tecnologias assistivas.
Ao testar uma ação que envia dados, observe o botão antes, durante e depois da solicitação. Verifique se o foco continua previsível, se o andamento é perceptível e se um erro pode ser entendido e corrigido. Compare as recomendações do sistema com a tela publicada. O teste de acessibilidade deve incluir a combinação com o formulário, não somente a prévia isolada do botão.
Documentação e governança: alguém consegue usar e melhorar o sistema?
Escolha um componente sem pedir ajuda aos mantenedores e tente responder: quando usá-lo, quando evitá-lo, quais estados existem, como escrever seu conteúdo, como implementá-lo e como adaptar uma exceção? Se a documentação não permitir essa decisão, registre a dúvida e a consequência prática. Para um passo a passo de levantamento de um produto já publicado, veja como documentar um Design System de um site existente.
Depois, acompanhe uma solicitação real de mudança. Quem decide? Como a equipe avalia impacto no design, no código e nos produtos que já usam o componente? Há versão, registro de alteração, orientação de migração e canal para reportar problemas? A documentação de contribuição da Atlassian mostra uma distinção útil entre correções pequenas e mudanças que exigem coordenação em todo o sistema.
O que uma página de componente precisa responder
Uma página útil reúne propósito, anatomia, estados, variações, exemplos de uso e de mau uso, regras de conteúdo, comportamento responsivo, orientação para teclado e tecnologias assistivas, implementação e histórico de alterações. Não é necessário copiar a mesma informação em todos os lugares, mas deve existir um caminho claro entre design, código e decisão de uso.
Faça um teste de descoberta: peça a alguém que não manteve o componente para resolver uma tarefa concreta com a documentação, como criar um formulário com validação. Anote perguntas que precisaram de uma resposta por conversa privada. Elas são candidatas a melhorias da documentação ou a um ajuste no próprio componente.
Verifique se a governança resolve mudanças de verdade
Escolha uma solicitação recente e acompanhe o percurso da proposta ao lançamento. Veja como ela foi priorizada, quem aprovou, o que foi testado, como produtos consumidores foram avisados e quem acompanha a migração. Se não houver caso recente, simule uma alteração de alto impacto e identifique onde a responsabilidade fica indefinida.
Um histórico de versões ajuda a distinguir componente desatualizado de implementação local justificável. Também é útil registrar a condição de retirada de um padrão antigo. Sem esse caminho, uma biblioteca nova pode coexistir por tempo indefinido com variações antigas que ninguém sabe quando remover.
Como registrar o diagnóstico e priorizar correções
Use uma linha por achado. Registre fluxo, componente, evidência, alcance, efeito para a pessoa usuária, causa provável, ação, responsável e prazo. Separe o que foi observado da hipótese sobre a causa. Um relato de que “ninguém usa o sistema” precisa de uma amostra de telas e de uma conversa com as equipes antes de virar conclusão.
Exemplo hipotético: em três fluxos de cadastro, a equipe encontra cinco versões locais do campo de senha. Em duas, a mensagem de erro não é anunciada ao leitor de tela. O registro inclui links das telas, os passos para reproduzir a falha e as versões do componente. A primeira ação é corrigir o comportamento acessível e indicar a migração; consolidar variações visuais vem depois. Esse exemplo ilustra a decisão e não descreve um projeto da CamaraUX.
Priorize primeiro falhas que impedem uma tarefa ou afetam acesso, segurança e compreensão. Depois, considere frequência nos fluxos, quantidade de produtos atingidos e esforço de correção. Uma matriz de impacto e esforço ajuda a ordenar o trabalho, mas não deve rebaixar uma barreira grave de acessibilidade só porque é difícil resolvê-la. Defina uma data para repetir a mesma amostra e verificar se o problema desapareceu em produção.
Exemplo de registro preenchido
| Campo | Exemplo hipotético |
|---|---|
| Recorte | Cadastro web, versão examinada em 23/09/2026, formulário de criação de conta |
| Achado | Mensagem de erro do campo de senha não é anunciada após envio |
| Evidência | Gravação da navegação por teclado, passos para reproduzir e referência ao código da tela |
| Alcance | Duas de três telas observadas; demais fluxos ainda não examinados |
| Hipótese de causa | Implementação local anterior à versão atual do componente, ainda não confirmada |
| Ação | Corrigir o anúncio do erro, testar a tarefa completa e orientar a migração |
| Verificação | Repetir o teste nas mesmas telas depois da implantação |
O formato impede que uma hipótese sobre a causa seja apresentada como fato. Também dá à pessoa responsável uma definição verificável de conclusão: a falha deixa de ocorrer na mesma tarefa e nas mesmas condições, sem criar outra barreira.
Escolha uma sequência de correção
Agrupe os achados em quatro decisões: corrigir um defeito no componente oficial; corrigir a implementação de um produto; ampliar a documentação; ou aceitar e registrar uma exceção. Cada decisão pede um responsável diferente. Se o componente oficial já falha, corrigir apenas a tela auditada perpetua o problema. Se o catálogo funciona e uma tela usa uma versão local, a migração pode ser o caminho mais direto.
Ao apresentar o resultado, mostre de três a cinco achados prioritários com evidência visual e teste reproduzível. Inclua o tamanho da amostra, as áreas não examinadas e a data da próxima avaliação. Isso torna o diagnóstico útil para quem terá de decidir investimento e acompanhar a correção.
O resultado esperado da avaliação
Um diagnóstico útil termina com poucos achados comprovados e decisões executáveis: corrigir componentes críticos, esclarecer orientações, tratar exceções frequentes e melhorar o processo de contribuição. Compartilhe o recorte e as limitações, para que a equipe não confunda uma amostra com uma certificação do sistema inteiro. Para continuar explorando o tema, acesse o hub de Design Systems.
