Construindo um Design System

Criando um Design System na idealização de simplificar e unificar processos, trazer consistência de forma multidisciplinar e agilizar criações e modificações.

Projeto de: Maio a Setembro de 2023 (oficialmente, porque é contínuo).

Minha função: Product Designer pleno. Fiz o planejamento do processo, metodologias a serem utilizadas, pesquisas com desenvolvedores, planejamento de governança, reformulação do UI Kit e desenvolvi a semântica dos tokens.

O time: Ysrael Santos (Product Designer Jr.), que prestou ajuda excepcional. Contei também com suporte importante de Iara Leite (Product Designer), Ulisses Hein (Dev front-end Flutter) e Tiago Freire (Tech Leader).

Overview

Contexto e desafio

Em uma empresa de e-commerce, encaramos vários problemas de inconsistência de interface e lentidão no processo por falta de repositório de componentes. Evoluir a biblioteca para um Design System poderia resolver isso e mais.

Processo

Reunimos e redefinimos componentes, investigamos formas de facilitar integração com os devs e desenvolvemos design tokens. Validamos realizando testes em wireframes e provas de conceito.

Resultados ✨

O Design System economizou significativas horas em processos de design, que puderam ser realocadas para outras tarefas, e sucedeu bem nos testes com tokens, recebendo feedbacks positivos dos desenvolvedores.

O desafio: Evoluir uma biblioteca pouco estruturada para um sistema evolutivo

A biblioteca existia, assim como alguns fundamentos de marca e componentes, no entanto seu crescimento desordenado e sem documentação resultou em uma série de inconsistências para designers e desenvolvedores, principalmente quando se falava de cross-plataform. Surge então nosso desafio.

Dessa forma, a maior das batalhas foi a construir um sistema de componentes que reaproximasse as equipes e funcionasse para desenvolvedores em multiplataforma que também tinham pouco tempo para dedicar ao projeto. Esse seria um Design System que compartilhasse entre devs e designers decisões de design. O sistema então deveria:

Englobar os produtos e componente que já temos;
Ser construído de uma forma que facilitasse comunicação entre times de design e de desenvolvimento;
Fosse escalável para produtos futuros da empresa;
Fosse flexível para mudanças dando suporte para casos de apps e sites whitelabel.

Etapas e processos

1. Revisão e classificação de elementos existentes

Então existia uma biblioteca e diversos elementos construídos a partir dela, apesar de não possuírem total consistência. Primeiro reunimos estes elementos em busca de classifica-los, revisando cada detalhe para documentar os novos padrões. A maioria dos "core components" já estavam sendo utilizados entre nós (desginers) e os devs e grande parte dos ajustes feitos foram relacionados a padronizações de cores, tamanhos e espaçamentos.

Tendo decomposto e observado esses componentes - de cores e tipografia a componentes mais complexos - foi fácil vê-los no nível molecular como proposto pela metodologia do Atomic Design, separando átomos, moléculas e organismos. Essa mesma classificação seguiu conosco até as últimas etapas do projeto.

2. Escolha do escopo de desenvolvimento

Com nossos componentes redesenhados e classificados, tomei a dianteira de já sugerir aos desenvolvedores uma primeira versão de tokens para passar uma ideia de onde gostaríamos de chegar. Esse primeiro contato foi bem aceito, e além do requisito de ser mais customizável, foi preciso fazer um recorte dentre os produtos para os próximos passos, principalmente considerando que trabalhamos com multi-plataforma. Ou seja, escolhemos um produto da prateleira para focar em seus componentes e a forma que era desenvolvido.

Esse produto foi o aplicativo de Ingressos, que era menor e tinha planos de evolução futura. Nele, o time trabalhava com o Flutter e bebia muito da fonte do Material Design - o que foi ótimo, porque no design nós também. Dessa forma, o que definíssemos no Design System seria customizado em cima dos componentes do MD UI.

Reduzir o escopo contribuiu para que nosso pequeno time conseguisse focar e fazer entregas mais rápida. Nesse escopo baseamos o restante do projeto, de forma que planejamento de governança, componentezação dos tokens e templates seriam feitos em cima dele.

3. Criação e validação dos design tokens

Ter reduzido o escopo ajudou bastante a manter o foco e testar um processo que funcionasse. Em pouco tempo criamos as semânticas de tokens e validamos a primeira versão com os devs. Aqui eles tiveram uma participação essencial no projeto e os tokens realmente ganharam potencial de linguagem em comum entre devs e desginers.

A maioria dos "core components" já estavam sendo utilizados entre nós (desginers) e os devs. Grande parte dos ajustes feitos foram relacionados a padronizações de cores, tamanhos e espaçamentos.

Design Tokens

Por essa etapa tivemos um carinho especial. A empresa é composta principalmente por engenheiros e uma das prioridades do projeto era aproximar o design do desenvolvimento, além de ajudá-los a compor a biblioteca que irão usar. Aqui, a ideia é os design tokens serem como uma linguagem especial entre os dois times e portanto foi cuidadosamente pensado.

a) Camadas de tokens: Antes de começar, compreendemos os nossos componentes e suas formações; componentes que são formados por outros componentes, que são formados por valores brutos. A imagem deve explicar melhor, mas imagine um sanduíche, formado por pão e queijo, que por sua vez são formados por trigo e leite.

Nessa etapa aconteceu a maior peculiaridade do nosso sistema também. Com o envolvimento dos engenheiros nos foi solicitado camadas especiais de tokens para atender nosso modelo de negócio e assim surgiram os "inside alias tokens", que são quando alias tokens ganham particularidade por causa de um token de componente; dessa forma um detalhe de botão que fosse solicitado poderia ser mudado sem mudar todos.

b) Semântica: A semântica é basicamente por significado lógico nos códigos que criamos para que o sistema seja lido com facilidade. Uma vez compreendido, apenas lendo os tokens já se pode ter uma compreensão do que se trata.

c) Validação: Quanto a validação, a temos para o time de design e de engenharia. Para design foi rápido e definitivo, uma vez que estávamos acostumados a usar biblioteca. Mas para a engenharia, antes de partir para a ação, decidimos fazer testes em POC (prova de conceito), testando tokens e componentes em num menor produto possível antes de irmos de fato para nossos produtos publicados. A altura que escrevo, o POC não foi finalizado, então não posso concluir aqui, mas as expectativas são das melhores.

E o que pode vir por aí...
Resultado é um trabalho contínuo.

Trabalhamos no Design System como um produto interno que funciona como SaaS, com nosso objetivo de facilitar entregas de produtos escaláveis e consistentes, mas adaptáveis a nossos clientes internos e externos. Parte importante desse processo foi entender necessidades de negócio, de design e de engenharia para que as peças se encaixassem e nesse meio tempo evangelizar uma equipe com baixa maturidade em design para os benefícios que esse sistema poderia trazer.

Dentro do time de design, o DS trouxe resultados imediatos de diminuição do tempo produzindo e organizando peças de alta fidelidade, o que nos permitiu usar mais tempo para pesquisas e entregas de qualidade. Referente à engenharia, o DS tem passado por todos os testes até agora, mas ainda não chegamos aonde planejamos, no entanto agora temos entregas consistentes.

Nossa expectativa é que com o tempo - seja em curto prazo, dedicando tempo específico para para construção de biblioteca, ou em longo, através das entregas e pequenas mudanças - serão de grande serventia, tornando mudanças mais práticas e modulares.

Fazer esse trabalho com uma equipe baixa senioridade foi um desafio pessoal, mas que funcionou bem. No final pudemos ver um avanço de experiência do time e um pouco mais de maturidade em design na área de tech. Agora é esperar para ver os próximos passos e resultados desse processo. :)