Construindo um design system

Da necessidade de reduzir tempo de produção e melhorar consistência entre design e front-end, surge a evolução de um style guide para um design system.

Projeto de: Maio 2023 - Atual

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

O time: Ysrael Santos (Product Designer Jr.), que prestou ajuda excepcional. Contei também com suporte importante de Ulisses Hein (Dev front-end Flutter), Iara Leite (Product Designer) 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.

Pesquisa

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. Estruturando e validando tokens

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.

Título da seção

Subtítulo da seção

Cada site tem uma história e seus visitantes querem ouvir a sua. Esse espaço é uma ótima oportunidade para compartilhar informações pessoais com seus seguidores. Clique duas vezes na caixa de texto para editar seu conteúdo e certifique-se de adicionar informações relevantes que você deseja que os visitantes saibam.

Se você é um negócio, fale sobre sua jornada profissional, seus valores, seu comprometimento com os clientes e como você se destaca no mercado. Adicione uma foto, galeria ou vídeo para ter um engajamento melhor.

Construindo um design system

Da necessidade de reduzir tempo de produção e melhorar consistência entre design e front-end, surge a evolução de um kit UI para um design system.