Decisões e desafios de um Design System
Este artigo tem o objetivo de compartilhar um pouco da nossa visão que guiaram as decisões por trás da arquitetura do Design System e os desafios para aumentar e incentivar o uso.
Como surgiu a necessidade de ter um Design System?
O DS nasceu para resolver o problema de duplicação de código, cada desenvolvedor fazia o seu próprio componente no seu projeto como por exemplo um botão, e quando surgia um projeto novo, chegava a ter um certo nível de "reaproveitamento", onde o dev copiava o código dos componentes de um projeto para o outro e ajustava de acordo com a sua necessidade, mas com isso os componentes evoluíam em direções diferentes, depois de um tempo, já não era possível saber qual era o padrão correto a ser seguido, tendo diversos botões diferentes em diferentes produtos mas que deveria ter a mesma identidade visual.
Nesse momento surgia a holding frete.com que foi resultado da união da cargoX com a Fretebras, e cada empresa usava diferentes tecnologias na web, uma usava ReactJS e a outra usava VueJS, e com esse crescimento estavam nascendo vários produtos em áreas diferentes e com o DS era possível aumentar a produtividade, diminuir o tempo de desenvolvimento já que os componentes não precisariam ser feitos do zero, aumentar a consistência na identidade visual entre os produtos e reduzir a carga cognitiva dos Designers e desenvolvedores com decisões banais, permitindo que focassem em criar soluções, realizar testes de produtos de forma rápida e essa escalabilidade impulsionaria o crescimento da empresa.
Como foi definido a arquitetura que seria utilizada?
Como o momento atual da frete.com era de expansão e estava fazendo aquisição de novas empresas, ser agnóstico era a principal característica que o DS deveria ter, ele deveria ter integração com a maioria das tecnologias web, que permitisse uma troca facilitada de temas para adequar os componentes com a identidade entre os produtos das empresas da holding enquanto mantinha a consistência.
Assim criamos um monorepo utilizando lerna para gerenciar os seguintes pacotes:
- O pacote de fundações
Esse pacote é onde fica toda a base do DS, os Design Tokens que são escritos em JSON que é um formato agnóstico e usamos Style Dictionary que permitia que exportássemos os tokens para cada plataforma especifica como CSS, SASS, Android, iOS - O pacote de componentes
Aqui é onde desenvolvemos todos os componentes básicos e componentes composto*, ao invés de usar React para criar esses componentes, optamos por usar StencilJS que é um framework que permite criar os componentes usando as ferramentas mais atuais utilizadas no frontend como Typescript e JSX, também fornece suporte ao Virtual DOM, permitindo controle de estado dos componentes, implementa mais métodos de ciclo de vida para manipular os componentes além dos básicos connectedCallback() e disconnectedCallback() que são fornecidos pela API padrão de Web Components pelos browsers, e que no final após o build desse pacote os componentes são transformados em Web Components que pode ser utilizado na maioria dos browsers. - O pacote de componentes em React
O StencilJS também permite que exportemos os Web Components para diferentes frameworks web como ReactJS, VueJS e AngularJS, nesse pacote ficam os componentes buildados para React que é o framework mais usado nos projetos da empresa, o StencilJS adiciona uma “Casca” que compatibiliza os Web Components para funcionarem corretamente no React e transforma os componentes customizados HTML em componentes React.
<!-- Exemplo de um Web Component, uma tag de elemento HMTL customizada -->
<meu-componente>
...
</meu-componente>//Exemplo de um Web Component buildado para ReactJS
import { MeuComponente } from "meu-pacote-de-componentes-react"
<MeuComponente />Em um futuro não tão distante, pretendemos tornar o nosso Design System opensource, por isso separamos os nossos assets por conterem licenças em outras bibliotecas para uso interno:
- Biblioteca de Fontes
- Biblioteca de Ícones
- Biblioteca de Ilustrações
Desafios
Como a construção do DS aconteceu ao mesmo tempo de um dos nossos maiores produtos, que utiliza a arquitetura de microfrontend, muitos componentes que ainda estavam sendo feitos na nossa squad de DS, já estava sendo necessário nas squads de produto, e isso levou os devs a construírem os seus próprios componentes para conseguirem atender o prazo.
Quando os componentes do DS estavam prontos, não havia tempo para encaixar tarefas nas sprints para os devs voltarem e substituírem os componentes feitos localmente pelo os componentes do DS.
Então percebemos que não adiantaria ter a maioria dos componentes base no DS, se somente novos projetos iriam ser beneficiados, e os projetos que já existiam não fariam uso, com isso mudamos a priorização de quais componentes seriam implementados, mesclando componentes básicos que já estavam em uso e componentes que tentávamos prever o uso em um futuro próximo pelas squads, para quando os devs precisassem deles o DS já estaria pronto para auxiliar.
Mas como medir a quantidade de componentes do DS que cada projeto está utilizando?
Assim surgiu o Sniffer, nosso projeto que contém uma série de scripts para clonar os projetos, varre-los para coletar as versões de cada biblioteca do DS que está sendo usada, os componentes que são importados, e calcular a porcentagem de uso do design system, esse valor chamamos de Fidelity que é o quão o projeto está fidedigno ao DS, e com isso conseguimos acompanhar mês a mês a evolução de quais projetos estão aderentes ao DS, entender o motivo do porque não estão usando e se os componentes estão atendendo as suas necessidades.
Assim conseguimos atuar de forma mais assertiva junto das squad para aumentarmos a porcentagem de uso, e disseminar o DS dentro da empresa.
Espero que esse artigo contribua para ajudar outras pessoas que também estejam implementando um Design System.
Obrigado por ler.
