Escalando seu Front-end com Design System e Storybook
Design System é essencial para a evolução de um produto, aumentando a eficiência e mantendo sua consistência na implementação e desenvolvimento de novas features, muitas vezes visto como um projeto, ele é um produto que impacta diversas áreas em uma empresa de tecnologia. Por conter a palavra “design” em seu nome, as pessoas tendem a acreditar que a responsabilidade de cuidar e evoluir é apenas do time de Design. Essas conclusões acabam se tornando uma barreira na adoção do Design System na empresa, pois além de sobrecarregar o time de Design, afetam também o engajamento de outros times por não se identificarem com o produto no seu dia a dia.
Design System não é responsabilidade somente do time de Design.
Portanto, quando for sugerir o uso do Design System não comece com a frase “Precisamos ter um Design System”. Inicie explicando as dores que ele irá resolver, como a padronização de códigos e interfaces, retrabalho de tarefas, explique também os papéis de cada equipe e defina objetivos a curto, médio e longo prazo, dessa forma, a aceitação e engajamento de toda a empresa no Design System será maior, evitando conceitos e opiniões errôneas e enviesadas.
O Design System é um produto que serve outros produtos, e por isso, não tem fim, ele se trata de um organismo vivo, no qual novos componentes acabam surgindo, componentes existentes são atualizados e rebranding da marca se torna às vezes necessário.
Mas qual é o momento certo de criar um Design System?
Particularmente acredito que o melhor momento é quando as equipes de Design e Desenvolvimento já identificaram os componentes necessários, definiram frameworks que serão utilizados e amadureceram o Brand do produto, pois quanto mais estável o produto for, melhor e mais assertiva será a atuação e entregas do time de Design ao time de desenvolvimento.
Uma vez que os times de Design e Desenvolvimento definiram as especificações do Design System e os Designers já colocaram a mão na massa desenvolvendo style guides, UIKits e outras definições de estilos. Quando e como essas entregas do time de Design serão refletidas nos produtos front-ends da empresa?
A resposta é: Quando existir uma documentação clara e concisa das melhores práticas com demonstrações de uso de seus componentes e tokens, quando existir uma biblioteca que centralize e externalize seus componentes e estilos implementados, e uma maneira de fazer isso é através do Storybook.
Em poucas palavras, o Storybook é uma ferramenta com o objetivo de criar um ambiente isolado para criação e demonstração de componentes, facilitando os testes unitários e servindo também como uma vitrine de componentes do nosso Design System, no qual podendo ser utilizado como peças de Lego para construção de cada tela dos produtos front-ends, economizando de forma exponencial o tempo de desenvolvimento, aumentando a qualidade e padronização do código, e mantendo a homogeneidade do branding e da experiência do usuário nos produtos front-ends da empresa.
Agora que definimos o uso do Storybook para ser nosso centralizador de componentes e ferramenta de documentação do Design System, precisamos ter em mente por onde começar a trabalhar e uma boa dica é começar pelos itens já validados pelos Designers como tokens de:
- Cores;
- Tipografia;
- Bordas;
- Acessibilidade;
- Grids;
- Breakpoints;
- Etc…
Pode ser que você não precise de todos esses itens inicialmente, mas já é um bom ponto de partida, outro ponto de atenção é nas definições de padrão de nomenclatura, sendo o Atomic Design o mais difundido, também existem outras escolhas como:
- Elements, Modules, Prototype
- Elements, Components, Modules
Seja qual nomenclatura você escolher, o importante é que os times de Design e Desenvolvimento conversem a mesma língua.
Enfim, chegado a hora de implementar o primeiro componente do nosso Design System no Storybook, surge uma dúvida:
Devo criar meus componentes baseado em algum framework ou devo implementar de forma agnóstica?
Aqui, acredito que a resposta mais coerente seria “Depende”, pois em um contexto geral não existe certo ou errado. Ambas abordagens têm prós e contras e o mais importante é que esta decisão seja alinhada com os desenvolvedores e líderes técnicos, pois vale lembrar que aqui os usuários não são o cliente final, mas, sim, os desenvolvedores. Dito isso, prefiro escolher o caminho de usar o framework da stack do time, é uma escolha no qual trará ganhos de performance de entregas, uma curva menor de aprendizado e uso de códigos já testados e validados pelos usuários do framework escolhido, porém de certa forma ficaremos presos a ele sendo necessário uma refatoração geral caso seja necessário a migração para um novo framework e ficaremos reféns as suas atualizações de versão.
Implementar os componentes de modo geral não é um dos maiores e mais complexos desafios técnicos, a não ser que a interface dele seja muito disruptiva. Acredito que o mais difícil é o conceito de criar componentes genéricos que tenham reuso e fácil manutenção. Componentes com forte acoplamento geralmente são complicados de serem implementados no Storybook, pois dependem muitas vezes de outros componentes ou libs como Vuex, Axios e etc. Uma solução para esses componentes é utilizar a estratégia de “Container View”, onde o componente em questão é implementado de forma simples no storybook e encapsulado por outro componente com seus acoplamentos, permitindo que esse componente pai o controle de forma dinâmica. Outra dica é se policiar para que os componentes tenham coesão, que sejam fáceis de adicionar variantes e modificar as existentes.
Saindo um pouco dos desafios técnicos, vamos entrar em um desafio super importante e delicado, que é o desafio cultural de implantar o uso do Design System junto com o Storybook no dia a dia dos desenvolvedores e designers, e também no fluxo de desenvolvimento da empresa. E é normal surgirem diversas dúvidas a respeito das diretrizes de seu uso como:
- Qual squad será a responsável pelo Design System ?
- Como iremos priorizar suas tarefas ?
- Quais squads podem contribuir ?
- Ele será open-source ?
- O uso dele será orgânico ou top-down?
Estas dúvidas devem ser sanadas o quanto antes pela diretoria e devem estar bem claro para todo o time para que o produto consiga evoluir.
Um canal de comunicação no Slack, um board no Jira ou até mesmo uma planilha de Excel são super válidos para divulgar aos desenvolvedores quais componentes estão prontos para serem utilizados, quais estão sendo implementados e quais estão na fila de prioridade para implementar.
Por fim, o Design System é um produto, e como todo produto se não for lançado rapidamente como uma versão beta, ele ficará sempre naquele limbo do quase pronto. Não se prenda ao preciosismos, inicie com um MVP, valide-o em um projeto, anote as dificuldades e colha os feedbacks e como qualquer outro organismo vivo, vá evoluindo ele aos poucos.
Deixarei logo abaixo alguns cases de inspiração:
Aproveito o espaço para me apresentar…
Eu me chamo Lucas Porto e sou Teach Lead Front-end na Mercafacil, uma empresa GPTW com missão de potencializar a conversão de vendas no varejo a partir da melhor experiência de consumo.
Nossos valores são:
- A partir das pessoas;
- Transparência em tudo;
- Impulsionados pela criatividade;
- Ser sempre melhor que ontem;
- Obcecados pelo WOW;
- Inteligência inspiradora;
- Criadores de experiências positivas.
Para quem se interessar, temos muitas vagas em aberto para nosso time de Engenharia!
E para quem gostou desse artigo, temos muitos outros como:
