Suitcase design system — da teoria à prática
Integrando o trabalho de design de produto entre diferentes times e tecnologias
Contexto inicial
No início de 2022, o escopo de trabalho das equipes de produto do Hurb vinha crescendo com novas demandas e a necessidade por projetos de interface que escalassem com mais eficiência tornava-se cada vez maior. Além disso, cresciam também as inconsistências considerando todo o ecossistema da empresa, seja no contexto de design ou entre as diferentes tecnologias Web, iOS e Android.
Para isso, integramos o primeiro time com pessoas exclusivamente dedicadas ao design system. Algumas iniciativas análogas corriam em paralelo, como bibliotecas de estilos e componentes no Figma, mas que ainda não eram fiéis ao que existia em produção. Do lado do time de front-end web já existia uma documentação técnica de componentes no Storybook, que viria a ser o principal ponto de partida para as nossas evoluções.
Durante a primeira fase do trabalho, conversamos diretamente com os principais envolvidos, seja em design, produto ou desenvolvimento. Montamos uma força-tarefa envolvendo os times técnicos para mapear o inventário existente e definir os próximos passos junto das lideranças.
Da mesma forma, a aproximação e o feedback dos designers de produto seria fundamental a cada progresso ou atualização, assim como o suporte prestado por nós com as melhores práticas especialmente para este período inicial, sempre estudando outros design systems no mercado e inovações.
Definição de escopo
Buscamos olhar para os “clusters” do que podemos considerar como importante para a manutenção e evolução de um design system e que, como resultado, ajudaria a definir os próximos passos:
Como está a saúde do design system?
Para um design system funcionar, refletindo no negócio e usuário final do produto, ele precisa estar saudável, espelhado em todas as suas frentes de atuação e com o menor número de falhas (ou bugs).
Só assim ele reflete positivamente no processo de desenvolvimento do produto, facilitando a comunicação entre design e desenvolvimento durante a etapa de handoff e validação (QA).
O quanto estamos ajudando no processo?
Não adianta ter o design system mais completo e saudável possível, se ele não está usável e alinhado com a rotina e processos das pessoas que o utilizam.
E aqui está o desafio: se designers entregam telas (imagens, protótipos) e os desenvolvedores linhas de código, como chegar em um consenso para apoiar ao máximo o dia-a-dia de ambos?
As frentes do DS estão consistentes?
Por fim, tudo isso vai resultar em entregas no produto “real” e que impactam usuários finais da companhia, portanto tudo isso deve convergir para algo consistente, coerente e muito bem alinhado com as diretrizes e posicionamento de marca da empresa, a tal da “padronização”.
Tudo isso vai muito além de usar a paleta de cores correta, a fonte definida na identidade visual ou respeitar os tamanhos do logo, mas também preservar a experiência entre os diferentes dispositivos, a aplicação e manutenção nas diferentes plataformas.
Monitorando esses pontos, conseguimos termômetros sobre o nosso design system para serem nossos guias, KPIs e triggers de iniciativas, tarefas e próximos passos.
Indicadores de sucesso
Nesse começo, em um ambiente com muitas inconsistências entre bibliotecas e gargalos nas etapas de handoff entre designers e desenvolvedores, mostrou-se necessário mapear os elementos desenvolvidos para entender o real cenário em cada frente de atuação.
Critérios de avaliação
Levantamos com todo o time alguns pontos principais para medir a qualidade de um componente do design system, critérios que seriam os nossos guias para manter os elementos saudáveis.
Design
Em design, definimos critérios que iriam garantir que o componente estava funcional para uso com a ferramenta e critérios perceptíveis de acordo com os princípios que foram definidos no produto e marca Hurb.
Tecnologia
Para o código a importância maior era garantir o funcionamento do elemento com revisões e testes definidos pelo time de engenharia e o alinhamento com as definições de design.
Documentação
Na documentação o principal objetivo era garantir que o bom uso do componente seja preservado.
Priorização
Por fim, definimos que alguns critérios também poderiam apoiar na visibilidade sobre os próximos passos, trazendo insumos para o dia-a-dia do time e definição de backlog.
Monitoramento
A partir dos critérios levantados, avaliamos todos os componentes da biblioteca web e relacionamos com o que tinha disponível nas outras bibliotecas, gerando uma fonte de dados para apoiar no mapeamento das evoluções quanto à saúde do design system.
Estrutura, processos e arquivos
Com o escopo de trabalho e nossos medidores de sucesso definidos, o desafio passa a girar em torno da organização enquanto equipe.
Nossa documentação interna na ferramenta Coda ganhava robustez a partir de estudos sobre onde os elementos do design system seriam manifestados e suas influências nas entregas do time.
Adotamos a metodologia kanban para evoluir de forma contínua, com etapas sempre alinhadas às tarefas de desenvolvimento para amarrar os processos e fluxos de trabalho.
Também definimos a organização dos arquivos no Figma para respeitar o momento de cada tarefa, desde a exploração de uma nova hipótese até as colaborações e validações finais.
Toda essa estrutura interna do time de design system ajudou a preparar o terreno para a organização dos arquivos de uso, entendendo como seria a melhor abordagem para as bibliotecas de design.
Roadmap
Conseguimos evoluir o dia-a-dia do time e gerar uma rotina de squad com um processo para guiar as tarefas, cerimônias semanais sobre evoluções contínuas e estrutura de bibliotecas e arquivos bem definidos, só faltava definir o caminho que queríamos percorrer.
Olhamos para os indicadores, algumas requisições, necessidades técnicas e conseguimos um norte para os próximos passos.
Definição da versão inicial
Ainda assim era importante para a empresa a gente ter um marco inicial, e definir uma primeira versão nos ajudaria na virada de chave para que todos os times de produto começassem a acompanhar as evoluções contínuas e assim dar início a um primeiro período de transição.
Começou a nascer a documentação de negócio, onde detalhamos todos os elementos definidos para a primeira versão e tudo o que os usuários precisam para utilizar a acompanhar a evolução do design system.
Lançamento Suitcase
Em abril de 2023, finalmente lançamos a primeira versão do design system, contando com a colaboração de todos os times para as sugestões e escolha do nome final. Criamos também uma identidade visual própria alinhada aos valores e conceito da empresa.
Optamos por utilizar a ferramenta Supernova para disponibilizar a documentação pública, contando com os recursos de integração com tecnologia que poderiam nos ajudar a entregar mais escalabilidade em versões futuras. Para o lançamento foi feito uma apresentação para toda a empresa contando um pouco sobre os principais desafios e como chegamos até aquele momento.
Foundations
Para atender aos critérios mínimos de saúde, após uma série de alinhamentos em design e tecnologia, chegamos a um denominador comum para as definições de estilos e elementos visuais para todos os times. Nossos design tokens seriam disponibilizados como uma única fonte da verdade, servindo a diferentes contextos de uso.
Design tokens manifestam decisões de design em variáveis de estilos únicas e absolutas, nomeadas semanticamente e distribuídas entre as ferramentas de design e linguagens de código.
Colors
Antes mesmo das definições de cores de uso, foram criadas paletas de cores que serviriam de suporte até para eventuais mudanças no futuro. Para equilibrar melhor os tons de cor usados não só em produtos digitais, mas até em ilustrações ou peças de marketing, foi criada uma paleta de cores primitivas. Utilizando ela, a paleta de cores semânticas carrega mais que apenas os nomes das cores, mas também funções específicas para elas.
No entanto, para atender a critérios de acessibilidade, peso visual e combinações, as cores de uso respeitam definições de aplicação, como em textos, ícones, fundos e bordas ou até mesmo estados de uso ou relevância. Ao utilizar as cores de contexto como dependência, poderíamos facilmente trocar temas e modos de contraste. Separamos ainda os tokens para uso geral dos que seriam de uso exclusivo para componentes, contendo estados e funções específicas.
Layout
Complementando as cores, definimos também tokens para medidas, formas e outras especificações de design e regras de uso mais claras, estabelecendo papéis hierárquicos e de melhor visibilidade para diferentes elementos do layout.
Icons
Organizamos a biblioteca de ícones disponíveis e documentamos os tipos de variação, onde devem ser aplicados na interface e o processo para a sugestão de novos ícones.
Typography
Para toda a parte de textos, foi feito um estudo à parte. Ao definir tokens para tamanhos, espaçamentos, pesos e mais, amarramos as possibilidades de estilos para uso, estabelecendo uma relação de hierarquia da informação e ainda respeitando as melhores práticas de responsividade.
Componentes
Para nossos componentes, seria fundamental desde o início monitorar a saúde deles através de critérios pré-estabelecidos. Numa etapa inicial espelhamos todos os componentes disponíveis na biblioteca de front end web e disponibilizamos aos designers como forma de reduzir os ruídos de implementações fora do padrão e entregar mais eficiência.
Em seguida, em conjunto com os times e seguindo nosso roadmap de evolução, passamos a atuar componente a componente, entendendo suas limitações e possíveis melhorias de design e acessibilidade e documentando regras de uso.
Branding e conteúdo
Como uma documentação a ser utilizada por toda a empresa, separamos também duas seções destinadas a unificar recursos e diretrizes alinhadas ao posicionamento e identidade visual da marca, assim como ela se comunica com seus clientes. Tudo isso sempre contando com a colaboração dos principais envolvidos em marketing e writing/content.
Novas entregas
Ufa! Chegamos em uma primeira versão, mas a atuação do time continua evoluindo e as novas entregas precisam ser definidas.
Alguns aprendizados ao longo do caminho ajudaram a refinar o roadmap, rever alguns pontos do processo e principalmente entender melhor o escopo de atuação.
Melhoria contínua
Durante todo o processo, algumas pesquisas com designers, gerentes de produto e desenvolvedores serviram como termômetro sobre as entregas das primeiras etapas, mas também já foi possível receber insights importantes para as próximas etapas.
Mantivemos a continuidade dessas pesquisas em paralelo das tarefas de rotina, criando a cultura de sempre ter um discovery contínuo para reforçar a adoção dos times e alimentar um board de insights e hipóteses para apoiar no refinamento das próximas etapas.
