- Bemol Digital
- Senior Product Designer
- Design system · Fundações e componentes
- App e site mobile
- Em produção · Storybook público em breve
O sistema veio depois do produto
A maioria dos cases de design system começa do zero. Este não. O produto já rodava havia anos, entre app e site mobile, com decisões já tomadas, só que não escritas, e não tomadas num lugar só.
Então a primeira metade do trabalho foi arqueologia, e não design: achar onde uma decisão já tinha sido tomada, decidir se valia manter, e dar a ela um endereço único.
Ninguém precisava decidir como um botão deveria ser. A parte difícil era achar os onze lugares que já tinham decidido, e escolher um.
Três problemas, nomeados separadamente
A mesma decisão existia em várias versões
Espaçamento, raio e tamanho de texto tinham se afastado entre telas construídas por pessoas diferentes em momentos diferentes. Nenhuma versão estava errada sozinha. Juntas, significavam que nenhuma tela era montada sem redecidir o que já deveria estar resolvido.
Documentação que ninguém abre não é documentação
Um sistema só se sustenta se o designer responde a dúvida mais rápido consultando do que perguntando. Isso é requisito de usabilidade sobre a própria documentação, e define o formato: resposta curta, um lugar só, achável sob pressão.
Design e código tinham fontes de verdade separadas
Biblioteca de componente que concorda com o arquivo de design só no instante em que é escrita vai discordar na sprint seguinte. O sistema precisava ser definido de modo que os dois lados lessem os mesmos valores, em vez de copiá-los.
Nenhum destes componentes carrega raio ou espaçamento próprio. Mexa num controle e tudo acompanha, porque cada elemento lê a variável em vez de guardar um valor. É o argumento inteiro da camada de tokens, e é o que print nenhum mostra.
Estado é derivado, não desenhado
No momento em que os estados de um componente são desenhados à mão, eles começam a divergir: uma tela tem anel de foco, outra esqueceu, uma terceira inventou um diferente.
Definir estado como matriz (cada variante contra cada estado) transforma uma questão de design em conferência de completude. Célula vazia é buraco no sistema, visível antes de virar bug em produção.
| variante | default | hover | focus | disabled |
|---|---|---|---|---|
| primary | ||||
| secondary | ||||
| ghost |
Reconstruído aqui com os tokens deste site. O ponto é que a grade pode ser lida à procura de buraco, coisa que um botão sozinho nunca oferece.
Acessibilidade é propriedade de sistema
Ou ela sobrevive no nível do sistema, ou não sobrevive.
Visibilidade de foco, contraste e tratamento de erro são as primeiras coisas a sumir quando cada tela é construída em separado, porque cada uma é fácil de pular e ninguém percebe até uma auditoria.
Colocadas no sistema, deixam de ser decisão por tela. O campo abaixo reserva o espaço que a mensagem vai ocupar, então o layout nunca pula quando a validação aparece: regra pequena, aplicada em todo lugar de uma vez.
Digite algo sem @ para ver o estado de erro. Nada se move.
O que não foi para produção
Um componente para cada padrão do produto
Alguns padrões aparecem numa tela só e nunca vão se repetir. Sistematizar isso adiciona custo de manutenção e não compra nada: sistema que cobre tudo é sistema que ninguém consegue mudar.
Sincronização automática de token entre design e código
É a resposta certa, e estava fora de alcance neste ciclo: exige trabalho de pipeline que não foi priorizado. Os valores são definidos uma vez e propagados à mão, com o risco de divergência anotado em vez de fingido.
Refazer todas as telas legadas de uma vez
Reescrever um produto em produção inteiro para satisfazer o sistema é como sistema é abandonado. Trabalho novo usa; trabalho antigo migra quando for tocado por outro motivo.
Quem fez o quê
- Consolidação das decisões espalhadas num conjunto único de fundações
- Estrutura e formato da documentação, para responder dúvida mais rápido do que perguntar para alguém
- Estados de componente definidos como matriz, e não tela a tela
- As regras que vêm antes dos componentes: grid, ritmo vertical, hierarquia
- Biblioteca de componentes, construída com a designer do time, ainda em andamento
- Implementação e API dos componentes em código, com engenharia
- Revisão do texto de interface, com a parte do time que cuida de writing
Onde está agora
Escrito como estado atual, não como história fechada.
As fundações e as regras de montagem de tela estão resolvidas e em uso. A biblioteca de componentes ainda está sendo construída junto com uma designer do time, e a versão que vai sustentá-la não está pronta.
Dizer o contrário seria a versão fácil deste case, e cairia na primeira pergunta de qualquer entrevista.
Reflexões
O entregável é acordo, não arquivo.
Todo artefato aqui (token, matriz, regra) é uma forma de guardar um acordo para não precisar chegar a ele de novo. Esse é o produto de verdade.
A medida que eu usaria não tem nada a ver com número de componente. É quantas perguntas deixaram de ser feitas, e quantas telas passaram a ser construídas sem ninguém redecidir o que já estava decidido.