Design System LexDoor — Arthur Duran

01 Por que um sistema

Construindo o avião e a fábrica

Quando comecei a desenhar o LexDoor, ainda não existia interface, nem design system. O produto cobria muita coisa: entrada de demandas, relatórios de dados, uma base de conhecimento, um construtor de formulários e ferramentas de resposta a incidentes. É tela demais para um designer só manter consistente de cabeça.

Então comecei o sistema no primeiro dia, em paralelo com o próprio produto. Não porque está na moda, mas porque eu sabia que o meu eu do futuro ia agradecer muito, e os devs do futuro mais ainda.

Fig. 01LexDoor, um produto da UnitedLex. Trabalho em inglês, com stakeholders de negócio, tecnologia e produto.

02 Fundamentos

Uma fonte de marca que veste um número acima

As diretrizes da marca foram direto para o sistema: estilos de cor, pesos de ícone, estilos de texto. A parte interessante era a tipografia. A Poppins é arredondada e generosa, então nos tamanhos de sempre ela parece bem maior que uma fonte neutra como a Inter.

Em vez de brigar com ela tela por tela, mexi na base: o rem base saiu dos 16px de sempre para 14px. De repente, tudo que herda dele ficou do tamanho certo.

Poppins e Inter no mesmo tamanho, com a Poppins parecendo maior — Fig. 02Mesmo tamanho, presenças diferentes: a Poppins, fonte da marca, ao lado da Inter.

Escala tipográfica e cores de aplicação, cada uma ligada a um token — Fig. 03Cores e tipografia da marca aplicadas à interface, e cada uma delas virou token.

03 Um ritmo de 7px

Tudo em múltiplos de sete

Um efeito colateral feliz do rem de 14px: paddings, margens, gutters, espessuras, alturas e larguras podiam se alinhar em múltiplos de 7px. Isso deu a cada componente e a cada tela o mesmo ritmo tranquilo, aquele tipo de coisa que ninguém percebe até faltar.

Anatomia de um modal com cada espaçamento medido em múltiplos de 7px — Fig. 04A anatomia de um modal depois da troca para o rem de 14px.

Anatomia de um componente molecular construído no grid de 7px — Fig. 05As mesmas regras, um nível acima: um componente molecular.

04 Feito para reutilizar

Componentes que se comportam

A parte mais importante de um design system não é a aparência. É ter componentes bem estruturados, com nomes consistentes e totalmente reutilizáveis em cada arquivo do Figma que depende deles. Bonito e frágil não ajuda ninguém.

O componente de campo de texto com suas variantes e propriedades — Fig. 06O humilde campo de texto, bem configurado para ser reutilizado em qualquer lugar sem surpresas.

05 Um lugar para consultar

Tokens que designers e devs entendem igual

Um design system fica útil de verdade quando é mais do que um arquivo bonito. Organizei os tokens de forma semântica, para designers e desenvolvedores consultarem tudo no mesmo lugar e falarem a mesma língua. Cada token aponta para um valor de componente, e esses valores batem com os componentes que foram de fato construídos.

Bibliotecas de estilo e variáveis ficaram sincronizadas, para o arquivo de design e o código continuarem amigos próximos, e não primos distantes.

Um componente de botão com seus tokens anotados — Fig. 07Um botão simples e os tokens por trás dele.

A lista completa de variáveis do design system — Fig. 08Todas as variáveis, configuradas para o sistema continuar flexível.

06 O que mudou

Stories mais rápidas, handoffs mais leves

Como todo design system, esse ficou em casa: ele segue vivo no Figma da UnitedLex, e eu guardei uma cópia para lembrar como ele cresceu.

3vitórias

Três coisas melhoraram bastante. As stories de UX andaram muito mais rápido, as conversas com os desenvolvedores ficaram mais fáceis e o produto se manteve consistente enquanto crescia. Nada mal para um time de uma pessoa só.

Ficou curioso? O arquivo do design system está aberto para você explorar: LexDoor Design System no Figma ↗

Um design system de uma pessoa só