Design system: o que faltou nas especificações do CRM

Design system é, na definição do Nielsen Norman Group, “um conjunto completo de padrões destinado a gerenciar o design em escala, com componentes e padrões reutilizáveis”. Este CRM de cobrança chegou ao quarto incremento sem nenhum: as especificações definiam regras de negócio, critérios de aceite, acessibilidade e a marca, mas não como as telas se organizam. A falta não impediu nada. Os quatro incrementos foram publicados e os 219 testes automatizados passaram. O custo apareceu depois, como retrabalho em todas as telas. Este artigo mostra como isso aconteceu, o que foi decidido e quanto custa corrigir agora.

Quatro incrementos sem padrão de interface#

Cada especificação deste projeto descreve o que o sistema faz e como saber se faz, como no modelo de especificação de software que a série segue: regras com exemplos, critérios no formato “dado, quando, então”, desempenho percebido pelo usuário. Desde o início, duas exigências valiam para todas as telas: acessibilidade no nível AA da WCAG 2.2 e o manual da marca AreaCli, com cores, fonte e símbolo.

Nenhuma especificação disse como a navegação se organiza, que tipos de página existem, como um formulário se arruma ou o que o painel mostra primeiro. Cada tela foi desenhada por quem implementava, no incremento em que a funcionalidade chegou, e acrescentada ao que já existia. A ferramenta que escreve o código decidia o desenho da tela no mesmo passo em que escrevia a regra, e nenhuma dessas decisões passou por mim antes de virar tela.

O resultado foi coerente com o processo. O menu ganhou um item por incremento e chegou a sete, na ordem em que as funcionalidades foram feitas. “Importar” (uma ação) e “Importações” (um histórico) viraram itens separados. O resumo da carteira ganhou um bloco por incremento e chegou a 13, empilhados. A configuração do credor ficou em três telas com três formatos, cada política onde coube no momento em que surgiu.

Por que os testes não avisaram#

Os testes conferem o que está escrito. Cada critério de aceite virou um teste que abre o navegador, faz o que o usuário faria e verifica o resultado, e cada tela passa por uma verificação automática de acessibilidade, no computador e na largura de um celular. Tudo passou, porque tudo estava certo em relação ao que foi especificado.

Nenhum critério dizia “o operador vê os títulos e o formulário de contato sem rolar a página” ou “o painel começa pelos quatro números que o gestor olha primeiro”. Sem esse critério, não há teste que reprove uma ficha comprida ou um painel sem hierarquia. O padrão se repete: no terceiro incremento, os testes também passaram enquanto a confirmação de 200 mil pagamentos não terminava. O problema só apareceu quando alguém olhou as telas como usuário. Neste projeto, fui eu, e a reação foi direta: tela de entrada com “um grande vazio” à direita, painel que “parece um amontoado de tabelas e gráficos”, ficha do cliente “meio anos 90”. A pergunta que veio junto foi a certa: “será que faltou especificações/padrões de projeto no que toca a interface de usuário?”

Manual de marca não é padrão de interface#

A confusão que deixou o buraco passar é comum: ter um manual de marca dá a impressão de que a aparência está resolvida. O manual responde quais cores, qual fonte, qual símbolo. Ele não responde onde fica o menu, quantos indicadores cabem numa linha, onde vai a ajuda de um campo, como um gráfico mostra os dados para quem não enxerga a barra. Essas respostas são o que um design system, ou ao menos um conjunto de padrões de interface, organiza. Numa empresa, quem as daria é a área de design e experiência do usuário, junto com produto, antes do primeiro incremento.

O que foi decidido#

A especificação nova é transversal: vale para todas as telas, as existentes e as futuras, e não muda nenhuma regra de negócio. As decisões principais vieram com esboços para comparar.

A última linha não estava entre as perguntas. Veio como observação depois delas: “a configuração do credor também é um ponto que está ficando bem bagunçado”. Além das telas, a especificação tem 12 padrões gerais, que vão do lugar da ajuda nos formulários à regra de que nenhuma situação aparece só pela cor, e 13 critérios de aceite. Um deles é verificável por posição na tela: na ficha, sem rolar, o operador vê o cabeçalho, o resumo, os títulos em cobrança e o formulário de registro.

Quanto custa agora#

A falta de padrão não travou o trabalho em nenhum momento: quatro incrementos foram especificados, implementados, testados e publicados. Ela se acumulou, e agora o custo é este:

Se os padrões tivessem sido especificados antes do primeiro incremento, o custo seria um documento e cada tela já nasceria no formato certo. Agora, ao custo do documento, soma-se refazer o que já estava pronto e conferir de novo o que já passava. Num projeto comum, isso costuma aparecer mais tarde ainda, na homologação, quando o usuário vê o sistema pela primeira vez e a data de entrega já está marcada.

O prejuízo é pequeno porque o momento foi escolhido. A reforma vem antes do quinto incremento, de promessas e acordos, que traria mais telas no formato antigo para refazer depois.

Em números#

O que vem a seguir#

O plano técnico mantém as escolhas do projeto: nenhum framework de CSS, nenhum script de terceiros, tudo funcionando sem JavaScript. Os padrões viram três camadas reaproveitáveis: valores de cor, espaço e tipo; componentes de estilo com o nome do padrão; e trechos de tela compartilhados, inclusive um desenho único de campo de formulário que aplica o padrão a todos de uma vez. A reforma vai numa versão separada e só é publicada com a suíte inteira passando. Depois, o quinto incremento já nasce no formato novo.