Como adotar o Padrão Digital de Governo no sistema do órgão

O que o padrão oficial entrega pronto

O Padrão Digital de Governo é o design system do governo federal, também chamado de design system gov.br. Segundo o README do core, ele é criado pelo SERPRO com a participação da comunidade. Na prática, reúne fundamentos, componentes, tokens e diretrizes, em código aberto, para que telas de órgãos diferentes tenham a mesma base visual.

Adotá-lo não termina em instalar um pacote. O padrão resolve a base. O que decide se o seu sistema fica consistente e acessível é como ele entra no código e o que a equipe produz depois: telas novas, textos, imagens, documentos.

Em um sistema que já está no ar, adotar o padrão é ligar o CSS aos tokens oficiais, migrar primeiro as telas de maior uso e manter uma camada própria para o que o padrão não cobre. Abaixo, o que vem pronto, o que continua com o órgão e como fazer essa migração. Os links oficiais ficam no site do padrão.

Fundamentos, componentes e tokens

O padrão se organiza em três camadas que se apoiam.

Os fundamentos são as decisões visuais de base: cor, tipografia, espaçamento, grid, iconografia. Os componentes (os componentes gov.br) são as peças de interface reutilizáveis, como campos, botões e menus, já com comportamento e estilo definidos. Os tokens são valores de design com nome, como uma cor ou um espaçamento, guardados em um arquivo em vez de repetidos no CSS de cada tela.

A ligação é direta. O fundamento define a regra, o token a guarda em forma de código, e o componente a usa. Trocar um token muda todas as telas que dependem dele.

O projeto também reúne modelos, padrões de uso, UIKits para quem desenha e ilustrações. A página do projeto no GitLab mostra o conjunto completo.

Bibliotecas por tecnologia

Quem desenvolve escolhe por onde entrar. Hoje há três caminhos oficiais:

• Core: biblioteca de componentes agnóstica de framework, o pacote @govbr-ds/core. Serve a qualquer projeto que consiga carregar HTML, CSS e JavaScript. O código está no repositório do core.
• Web Components: o pacote @govbr-ds/webcomponents, com wrappers oficiais para Angular, React e Vue. Um wrapper é uma camada fina que adapta o componente web ao jeito de cada framework. Veja o repositório.
• React: o pacote @govbr-ds/react-components, para quem trabalha só com React. Veja o repositório.

A escolha depende do que o sistema já usa. Um front-end em Angular pede um caminho. Um portal com páginas renderizadas no servidor pede outro. Vale decidir isso antes de instalar, porque trocar de biblioteca depois é retrabalho.

Diretrizes de acessibilidade e de escrita

O padrão traz material oficial sobre acessibilidade e sobre como escrever para a interface. Há um repositório de acessibilidade, e o monorepo principal inclui princípios de escrita.

Esse material orienta a equipe. Ele não garante, por si, que o sistema esteja em conformidade com o eMAG ou com a WCAG. Conformidade é resultado de teste, e não de dependência instalada.

O que continua sendo trabalho do órgão

Um sistema real tem mais do que o padrão cobre. É aqui que a adoção costuma ganhar ou perder consistência.

Componentes que o padrão não cobre

Todo sistema de gestão tem telas que ninguém imaginou num design system genérico. Fluxos específicos da área, visualizações de dados próprias, formulários longos com regras de negócio.

Quando o padrão não tem a peça, a tentação é montar cada tela do seu jeito. O resultado são três versões da mesma ideia em módulos diferentes. O caminho melhor é construir a peça uma vez, com os tokens do padrão, e reutilizá-la.

Integração ao codebase

Instalar o pacote é o começo. Alguns pontos pedem atenção:

• Dependências de base. A biblioteca React, por exemplo, exige que o projeto importe o CSS do core, o Font Awesome (ícones) e as fontes no ponto de entrada da aplicação. Esquecer isso gera componentes sem estilo ou sem ícone.
• Tokens como fonte única. O pacote @govbr-ds/tokens traz CSS, SCSS, JS e JSON. Se o sistema usa cor e espaçamento escritos à mão, o padrão fica só na superfície. Ligar o CSS do sistema aos tokens é o que mantém tudo alinhado quando o padrão evolui. O repositório dos tokens descreve os formatos.
• Temas claro e escuro. Os tokens trabalham com o atributo data-br-theme, que recebe light ou dark. A troca de tema fica concentrada em um ponto, desde que o código não fixe cores fora dos tokens.
• Versão fixada e atualizada. Fixe a versão do padrão no projeto, para que uma atualização não mude a interface sem ninguém decidir. E reserve tempo para atualizar, porque o projeto evolui. Confira a versão vigente no site oficial antes de começar.

Esse trabalho é de arquitetura de front-end: decidir onde ficam os tokens, como os componentes são empacotados e como a atualização do padrão chega ao sistema sem quebrar nada.

Acessibilidade no conteúdo

Um componente acessível não corrige texto alternativo ruim. Não torna legível um PDF escaneado. Não reescreve um link que diz "clique aqui".

O padrão traz componentes e orientações de acessibilidade como ponto de partida. Foco, semântica e contraste ainda precisam ser testados pela equipe. O que se publica depois continua sendo responsabilidade de quem publica. Sobre o que isso exige na prática, veja o que é o eMAG.

Adotar o padrão num sistema que já existe

Quase nenhum órgão começa do zero. O mais comum é um sistema com anos de CSS acumulado, telas de gerações diferentes e uma equipe que não pode parar para refazer tudo.

Comece pelos tokens e pelas telas de maior uso

A ordem que costuma funcionar:

1. Tokens primeiro. Cor, tipografia e espaçamento mudam a aparência de todo o sistema com pouco risco. É um bom primeiro passo.
2. Telas de maior uso depois. Login, listagens e formulários principais. É onde o usuário passa mais tempo e onde a inconsistência mais incomoda.
3. O restante conforme a manutenção. Tela que será mexida de qualquer forma já migra junto. Tela estável espera.

O esforço depende de fatores: tamanho do CSS atual, framework em uso, quantidade de telas, existência de testes. Por isso o plano precisa partir de um levantamento do sistema, e não de uma estimativa de fora.

Convivência temporária entre o estilo antigo e o novo

Durante a migração, o CSS antigo e o do padrão rodam juntos. É nesse período que aparecem os conflitos: uma regra global antiga muda o espaçamento de um componente novo, ou duas folhas disputam o mesmo seletor.

Alguns cuidados reduzem o problema:

• delimitar onde o novo estilo vale, por módulo ou por rota;
• evitar seletores globais no CSS legado que ainda precisa ficar;
• revisar visualmente cada tela migrada, nos dois temas, se o sistema usar ambos.

A convivência é temporária por definição. Sem data de saída para o estilo antigo, ela vira permanente.

Como saber que a adoção avançou

Não precisa de percentual. Dá para verificar de forma qualitativa:

• as telas principais usam componentes do padrão, e não cópias locais;
• cor e espaçamento vêm dos tokens, e não de valores escritos à mão;
• trocar o tema não deixa nenhuma tela com cor fora do lugar;
• uma atualização do padrão pode ser aplicada e testada sem susto;
• o teste com teclado e leitor de tela passa nas telas migradas.

Se a equipe consegue responder "sim" a essas perguntas, a adoção deixou de ser instalação e virou prática.

Padrão oficial e design system próprio podem conviver

Adotar o padrão não elimina a necessidade de organizar o que é específico do órgão. As duas coisas se complementam.

Quando o órgão precisa de camada própria

Uma camada própria faz sentido quando há peças e regras que o padrão não traz e que se repetem em vários sistemas do órgão. Um conjunto de componentes de domínio, convenções de nomenclatura, exemplos de uso para a equipe.

Ela se apoia nos tokens do padrão. Não o substitui nem o copia. O serviço de design systems trata justamente de organizar esse espaço entre o padrão oficial e as necessidades do sistema.

Quem mantém a camada própria

Camada sem dono envelhece. Decida desde o início:

• quem aprova uma nova peça;
• quem acompanha as atualizações do padrão e testa o efeito na camada própria;
• onde fica a documentação, para que um desenvolvedor novo encontre o que existe antes de criar outra versão.

Pode ser uma equipe pequena dentro do órgão, um papel dividido entre design e front-end, ou um apoio externo. O que importa é ter nome e rotina. O projeto do padrão é aberto e aceita contribuição por merge request, o que ajuda quando uma necessidade do órgão serve a outros.

Se o seu portal ou sistema precisa seguir o padrão e você quer ver o que está na base e o que está no código do órgão, a Evo Tech trabalha com design systems, arquitetura de front-end e criação de sites e portais institucionais. Fale com o nosso time e descreva o seu sistema: é o ponto de partida para um plano de adoção.