Design system por um desenvolvedor front-end, parte 2
Mais algumas reflexões sobre a construção de um Design System do ponto de vista da Engenharia
Se tem algo que nos orgulhamos muito de fazer aqui na Quero, isso é o Design System, que carinhosamente chamamos de Zilla. Há algum tempo, publiquei o início de uma lista do ponto de vista da Engenharia em relação a esse produto que beneficia toda empresa, mas principalmente nós mesmos — os desenvolvedores.
Design systems são essenciais para a evolução de um produto, mantendo sua consistência e aumentando eficiência no desenvolvimento e na implementação de novas features. Tendo experiência há algum tempo neste assunto e vendo com meus próprios olhos as vantagens desse produto, hoje, finalizo a lista para quem gostaria de encarar (e se apaixonar) por essa jornada chamada design system.
6 — Desafios técnicos
Não acho que um dos maiores desafios técnicos que podemos enfrentar aqui seja criar um Slider customizado no Stencil ou qualquer criação de componentes em si.
A não ser que seu produto use algum tipo de interface muito disruptiva, no final do dia é o bom e velho feijão com arroz, alguns mais complexos, mas no final tudo que você e seu time conseguirão realizar.
O mais difícil do meu ponto de vista resume em: reuso e manutenção. São os dois principais desafios que vejo e que basicamente se complementam.
Evite cair em armadilhas que te façam acoplar componentes que não deveriam estar acoplados, dificultando o reuso. E se policie para que os componentes tenham coesão, sejam fáceis de adicionar uma nova variante e modificar as existentes.
Mas acredito que entre a tríade: HTML, CSS e JS, a que mais precisamos estar atentos aos pontos acima, é o CSS.
Vamos supor que você esteja fazendo o seu Design System para React, provavelmente você usará Styled Components. Se amanhã a sua empresa chegar e definir: teremos mais um framework na stack ou queremos usar o DS em um projeto que está fora da nossa stack atualmente, o seu DS consegue atender?
Se o seu CSS está todo acoplado a uma particularidade de um framework X, como você vai reutilizar o CSS?
Eu acredito que o CSS de um DS deve ser desacoplado, isso garante que independente da tecnologia que precise utilizar para estruturar e interagir com os componentes, a camada de estilos está protegida e pode ser facilmente reaproveitada.
Qualquer projeto open source pode morrer, vide AngularJS. Se isso acontecer, você já terá que se preocupar em migrar para um framework diferente, com estrutura e interatividade conduzidas de formas diferentes. Imagine reescrever ou portar todo um CSS.
Claro que esse é o cenário do caos, mas como acredito que o maior trabalho em um DS está nas CSS, o melhor é elas serem isoladas e independentes.
7 — Desafios culturais
Como comentei acima sobre personas, é importante ter em mente que ao criar um Design System, estamos atuando com dois públicos distintos:
- Usuário final, que terá uma experiência mais consistente com o seu produto e com os princípios definidos pelo seu time;
- O desenvolvedor que vai passar pelo menos oito horas por dia usando o Design System.
É comum focarmos somente no usuário final, que, claro, é importantíssimo. Mas, sem o desenvolvedor para usar os componentes do seu Design System, seguindo os padrões criados, o usuário não terá o impacto positivo esperado.
As dificuldades culturais geralmente ocorrem quando algumas diretrizes não são bem definidas, por exemplo:
O responsável pelo Design System será uma squad específica ou um cross de outras squads?
Qual a priorização das tarefas de Design System?
Quem deve atualizar no projeto principal da empresa as versões impactantes do Design System?
Quem pode contribuir? Todas as squads?
O Design System será open-source?
A cultura de contribuição será orgânica ou top-down?
Vamos atuar como fiscais de quem passa por cima das regras do Design System?
Essas são perguntas que acredito que você deva ter uma resposta clara e direta da diretoria e isso precisa estar bem claro para todo o time. Isso evita telefone sem fio.
Não acho saudável uma cultura top- down — quanto mais imposições, mais reativas as pessoas se tornam. Porém, deixar em aberto “use quando quiser e como quiser” também pode ser um tiro no pé.
Acredito que o melhor caminho é um equilíbrio. Com o tempo você entenderá quais caminhos deverão ser impostos e quais deverão ser naturalmente absorvido pelos times.
8 — Tenha uma boa documentação
Uma boa documentação vai ajudar na longevidade e na adoção do Design System pelo seu time. Porém, tente sempre ter em mente ao escrever uma documentação que você deve buscar passar as informações de forma clara e concisa.
Por estarmos familiarizados com várias particularidades e nuances do Design System, acabamos deixando informações implícitas que na nossa cabeça parecem estar bem explícitas. Tome como ponto de partida que toda e qualquer informação deva estar explícita e muito bem exemplificada.
Não negligencie a documentação.
As pessoas têm a ideia errada de que “se gasta tempo escrevendo documentações”. Isso está longe de ser verdade.
Uma boa documentação vai poupar o tempo de quem primeiro pesquisa na documentação. E também poupa o seu tempo quando alguém pular a etapa de pesquisar e vier perguntar diretamente a você. Basta você redirecionar a pessoa para a documentação (RTFM!) e pedir que retorne caso a dúvida persista. Geralmente, se a documentação estiver bem explicada, não será necessário esse retorno.
Se você estiver recebendo muitas perguntas no privado de um mesmo assunto, é bem provável que haja margem para você melhorar a documentação.
Boas documentações são difíceis de escrever, por isso, é algo que deve ser levado muito a sério. Trate a documentação com a mesma seriedade que trata um código bem escrito.
Você pode começar uma do zero usando um Gatsby, você pode fazer uma mescla entre Zeroheight ou Invision DSM e Storybook ou você pode fazer tudo pelo Storybook usando MDX, o que for mais prático para designers e desenvolvedores.
9 — Status dos Componentes
É importante que os desenvolvedores que vão utilizar o seu Design System saibam exatamente quais componentes estão prontos para serem usados, quais estão sendo feitos, quais precisam ser feitos, quais estão sendo validados e quais foram descontinuados.
Você pode fazer isso desde uma planilha compartilhada com o time, tasks no Jira, ou criar uma informação de status em cada componente na documentação do Design System. É algo simples mas muito eficaz. Um bom exemplo de uso desse status é o Spectrum, Design System da Adobe.
10 — Lance, use, erre rápido
Como falei no começo, eu acho importante tratar o Design System como um produto que serve outros produtos e não um projeto.
E considero que um produto, se não for lançado rápido uma versão beta, ficará pra sempre em desenvolvimento. Porque sempre vão ter coisas a melhorar, sempre um componente poderia ter uma variação a mais, um código que poderia ter sido melhor escrito, uma documentação melhor explicada, uma ferramenta automática para ajudar o time, etc.
Se você se prender em só lançar o Design System quando estiver “pronto”, não irá lançar nunca.
Crie uma versão básica e minimamente estável. Valide com o projeto de maior expressão que sua empresa tenha. É nesse projeto que moram as principais dificuldades, os principais desafios e a principal falta de padronização. Se o seu Design System provar seu valor nesse cenário, vai provar em qualquer outro projeto mais simples da sua empresa.
Nesse caminho, não se assuste. Críticas vão surgir — das mais amigáveis até as menos amigáveis. Seja resiliente. Se prepare para lidar com isso de maneira saudável.
Absorva as críticas, mesmo as que por ventura tenham sido ríspidas, entenda que um feedback assim é porque a pessoa foi reativa a uma experiência ruim que o seu Design System proporcionou a ela. Aceite, entenda e melhore, não há outro caminho.
Design System é um produto e é só dar uma olhadinha nos comentários de aplicativos da Play Store ou Apple Store pra entender que os melhores feedbacks e possibilidades de melhorar um produto, surgem de comentários muitas vezes bem fortes. Se você souber olhar para eles como oportunidades, tirará bom proveito.
Tentei trazer as principais dúvidas que tive quando comecei, os erros e acertos que cometi e as possibilidades de ter feito algo diferente que vi no meio do caminho. Tudo é aprendizado e construir um Design System deve ser visto como evolução constante — tanto para seu produto, quanto para você e até mesmo para sua empresa de tecnologia.
E não se esqueça de ler a primeira parte desta lista: Design System por um desenvolvedor front-end, parte 1.
Leia também para conhecer o Zilla, do Design System da Quero Educação:
- Design system: conectando desenvolvedores e designers, por Ney Pimenta.
- Design System: da confusão à construção de um produto, por Jan Klever.
- OPS! Evoluímos nosso design system, por Jan Klever.
