Design system: conectando desenvolvedores e designers
Como a construção de um design system otimiza o trabalho de times multidisciplinares da Quero
A criação de um design system é um passo importante para a empresa porque, além de refletir a identidade de marca, é um documento vivo que facilita a comunicação entre os times e garante atualizações simplificadas entre os diferentes projetos.
Quando bem definido com o time de Design, desenvolvedores podem interligar o código ao branding da empresa, com tom de voz e posicionamento viabilizados por meio de componentes. Isso transforma o trabalho dos frontenders, melhorando a comunicação do ponto de vista técnico, deixando tudo mais reutilizável e acelerando entregas.
Devido às inconsistências do antigo design system da Quero e sua usabilidade deficiente, decidimos por criar o Zilla, nosso novo sistema de design atômico, flexível e escalável.
A tentativa anterior
O PG (Product Guidelines), a primeira versão do Design System da Quero, foi implementado há anos de maneira pouco estruturada, sem um processo e arquitetura bem elaborados. Naquela época, os times de Design e Engenharia não estavam muito bem alinhados. Os designers entregavam handoffs incompletos ou com desvios do padrão, enquanto a Engenharia não se preocupava tanto em usar componentes genéricos, com boas práticas ou desacoplados o suficiente. E até hoje o Quero Bolsa possui partes que nem se encontram oficialmente no PG.
Entendemos que o grande benefício de trabalharmos com componentes é que, caso haja modificações no código no futuro, das pequenas às maiores (como um possível rebranding), tais mudanças poderiam ser feitas facilmente e a entrega, bem mais rápida.
Portanto, a tarefa era clara: não queríamos e nem deveríamos colocar o Zilla como um Product Redesign. Nossa decisão foi elaborar o design system em conjunto desde o início. E, para isso, criamos primeiramente a versão beta.
Versão beta e os primeiros testes
A versão beta do Zilla foi primeiramente utilizada pelo time de Pagamentos e Admissões, setor de customer service da Quero Educação, no semestre passado (entre outubro de 2018 e abril deste ano). Testamos nesse time para entendermos se conseguiríamos atingir os resultados esperados após a implementação final:
Consistência das telas e interações com a reutilização dos componentes
Redução do lead time de Engenharia e de Design
Redução de dead clicks
Aumento de conversão no CTA (ação de conversão e de sistema diferentes)
Aumento de brand awareness
Melhorias de acessibilidade
Com os resultados dessa versão beta, decidimos dar uma pausa na execução, pois precisávamos repensar nossa arquitetura e processos.
Uma nova arquitetura e o nascimento da versão 1.0
O processo de implementação da arquitetura do PG, na sua concepção, não possuía um fluxo de validação fora do contexto de uma página. Naquela época nos preocupávamos apenas com o entregável das tarefas, com uma visão mais de curto prazo.
O primeiro passo para conseguirmos criar a sinergia entre o Design e a Engenharia da Quero foi o setor de Tecnologia assumir que a formulação do Zilla seria favorável a todos. Assim, um time de desenvolvedores foi escolhido para poder fazer essa cooperação acontecer. Foi então que propusemos um fluxo diferente de validação e com um catálogo de componentes separado, uma galeria viva para servir como documentação, exemplo de markup e playground.
Construímos os componentes antes de implementar as páginas, diferentemente do que estava sendo feito anteriormente (implementando o componente nas páginas e tentando separar depois). Com o processo já definido, estávamos prontos para fazer o Zilla avançar.
Implementação e desafios
Decidimos que a implementação de alguns elementos do site, como componentes do checkout e cores dos links e botões, não deveriam ser feitas de maneira drástica, então aplicamos testes A/B.
De certo modo, isso ia contra a visão inicial dos designers, em que deveríamos evitar que as páginas fossem mistas, com partes do PG e do Zilla mesclados. Inclusive, eles já haviam passado a fazer os mockups inteiramente com o Zilla, mas isso requer uma abstração do desenvolvedor ao enxergar o Zilla e implementar em PG.
Quando o teste A/B foi finalizado, implementamos o estilo desses elementos globalmente, dando uma prévia do novo visual e facilitando o trabalho dos desenvolvedores, flexibilizando a implementação e liberando apenas a zillagem de componentes que estão sofrendo alteração.
Para que o Zilla ocorra da maneira que foi idealizada, enquanto o design ops e outros designers propõem melhorias, os membros da Guilda de Front são responsáveis por sugestões de padronização e pelos code reviews.
E, para que o processo de validação dos componentes pelos designers tenha um escopo definido, criamos ambientes de homologação temporários e independentes. Depois de validado, testes unitários são implementados e após o code review por dois desenvolvedores, o componente está pronto para ser inserido em diferentes projetos e a ser vinculado a seus contextos e especificidades.
No processo, a migração em si está sendo um grande desafio. Não conseguimos identificar, por exemplo, quantas páginas já foram migradas. Para isso, pensamos na possibilidade do próprio componente identificar onde ele estaria inserido para saber a real porcentagem de migração.
Outra questão é manter as variantes do Zilla versionadas e cada componente versionado de acordo com a versão de design. Na prática, podemos enfrentar algum nível de defasagem entre uma e outra variante — o que seria resolvido com a atuação do time de desenvolvimento para que as bibliotecas estivessem no mesmo nível de evolução.
Porém, o maior desafio deste processo é o próprio design system. Não estamos construindo um layout, mas peças que serão encaixadas para construir todo o sistema. Por isso, devemos criar um sistema separado para que a empresa toda consiga contribuir e desenvolver junto e com rapidez.
Para implementarmos e superarmos todos esses obstáculos ao colocarmos o processo em prática, criamos padrões de documentação e guias de contribuição. O próximo passo é mensurar, por meio de pesquisas qualitativas (usuário, hotjar) e quantitativas (analytics, testes A/B), além de monitorar a redução do tamanho de tarefas, tanto dos desenvolvedores, quanto dos designers.
O resultado será a satisfação de qualquer desenvolvedor front-end: poderemos focar mais em inovação em vez da programação do layout inteiro.
Tudo pronto para zillar!
Com a definição de todo o processo, queríamos que, na prática, tudo acontecesse da seguinte forma: assim que um componente fosse finalizado, seja pelo squad de plataforma, seja por um squad de produto, os outros times poderiam utilizá-los nas páginas que estivessem implementando.
Em nosso planejamento, decidimos que o plano principal seria focar nestas etapas:
Checkout com Zilla core
Happy path (core)
Happy path (Vue)
Elementos globais
Whitelabels
A Engenharia mapeou mais de 70 componentes e vários deles já foram implementados.
Escolha das tecnologias
Estamos utilizando o SASS para definir os estilos em nosso pacote Core e temos pacotes de componentes para Vue e React, já que utilizamos essas bibliotecas na Quero, e um para ícones.
Para falarmos a mesma língua dos designers e definir temas, temos um pacote de design tokens baseado no AWS Style Dictionary. Por último, um para CLI (command-line interface), usado para criação de novos componentes. Todos os pacotes estão em um monorepo baseado em Lerna.
Como galeria viva, optamos por utilizar o Storybook. Além disso, no fluxo de validação, fazemos deploy via Gitlab no Netlify em cada merge request, para que os designers possam fazer a validação no seu ritmo.
Cada componente implementado é associado a uma versão congelada de design, que é um retrato semanal da evolução dos mockups.
Para que o vocabulário entre desenvolvedores e designers seja o mesmo, também estamos usando uma linguagem de tokens, que representa as variáveis de cores, espaçamentos e tipografia.
Sinergia, um aprendizado
Queremos otimizar e agilizar o processo de desenvolvimento sem deixar de manter a qualidade do nosso código mais alta possível. Aprendemos, ao longo desses últimos anos, que isso só é possível quando trabalhamos como time, sempre ao lado dos designers.
Olhar para o Zilla como design system, seja você um engenheiro ou designer, é entender que isso só acontece com cooperação e sinergia de ambos os times.
Como resultado, alcançaremos, junto aos designers, os objetivos iniciais do Zilla:
Atender a promessa de marca e visão de produto
Atender aos padrões de usabilidade e código
Reforçar o branding da Quero
Permitir uma camada fina de tematização
Após toda a implementação do processo, é nosso dever apenas manter o design system funcionando, com inclusão, evolução e deprecação de componentes e também com a live library.
E, se futuramente tivermos que fazer qualquer mudança nos componentes, seja para melhorar a informação do produto, o preço ou até aumentar a conveniência do usuário, assim o faremos de forma fácil, simples e rápida.
Quer fazer parte do nosso time da Engenharia? Estamos com vagas abertas.
