Design system multimarca: quando desenhei um design system para 3 marcas globais

A Signify tinha acabado de comprar a Cooper Lighting e tinha um desafio: unificar seus portais B2B. Era o e-commerce B2B de quem compra iluminação em escala: clientes, agents que vendem para o cliente final, distribuidores e escritórios de arquitetura de iluminação, do projeto na planta baixa até o pedido.

A venda, a compra, a gestão de pedidos e a personalização moravam em 4 sistemas legados, com linguagens e perfis separados. A compra ainda passava por e-mail: o cliente pedia ao agent, o agent pedia à Signify, a área de preço aprovava, e a proposta voltava por e-mail.

Entrei no projeto, chamado internamente de Paragon, em 2021, pela Tech Mahindra. Uma consultoria de estratégia tinha feito a estratégia de negócio e passou o bastão para a implementação. Fiquei com a versão final de design, isto é, aonde o projeto queria chegar no visual e na estrutura, e com a liderança de um time de 7 product designers.

Componentes

744

Tokens

186

Marcas

3

O que o projeto não tinha

O projeto corria separado do resto da empresa e não tinha nem uma lib de design no Figma dedicada a ele, muito menos um design system. A Signify tinha sistemas em outros projetos, mas eles não conversavam entre si, e este seria o primeiro multimarca da empresa. O framework dos devs era o UI5, engessado para responsividade, e o Figma ainda não tinha variables.

Um desses limites apareceu no input. As telas já tinham muita informação, e os campos muitas vezes tinham pouco espaço para existir. O input padrão do UI5 deixaria tudo mais pesado. Levei o meu desenho, com a label dentro do campo, sempre visível e em bold, e os devs customizaram o componente. Com a label dentro, a tela passa a sensação de cada coisa no seu lugar. Saiu barato: eles desenharam uma vez e toparam sem discussão.

Antes de abrir a biblioteca, alinhei o cenário com a head de design e destrinchei o material que existia das marcas, que não estava completo para todas. Conversei com os devs para entender a linguagem deles e os limites do UI5. Depois escrevi princípios de design e levantei o inventário de componentes em produção e no Figma.

Com o inventário na mão, o trabalho tinha dois problemas pela frente: fazer um sistema só servir 3 marcas e, mais tarde, fazer o meu próprio time usar a biblioteca.

Três marcas numa plataforma só

A plataforma precisava servir Signify, Cooper Lighting e Genlyte, e só a Signify tinha tokens prontos. O trabalho que a consultoria tinha deixado também estava fora do mínimo da identidade e do site já no ar, nas cores, na tipografia e na estrutura das páginas.

Fiz um design system único, com um tema para cada marca. Parti dos tokens da Signify e montei os da Cooper Lighting e da Genlyte do zero, a partir do site público e dos manuais de identidade de cada marca. Refiz as cores e a tipografia, e redesenhei a estrutura das páginas pelo que o produto precisava.

Comecei antes de o Figma ter variables, com um arquivo só, montado à mão, item por item. Ele trocava a skin das 3 marcas em poucos cliques, quase sem redesenhar elemento. Quando as variables chegaram, a troca passou a ser de um clique só, acelerei a criação e fechei uma versão robusta da biblioteca, com os tokens como variables.

Pesei montar bibliotecas separadas e descartei a ideia. A plataforma era praticamente idêntica nas 3 marcas, e só mudavam o tema e algumas telas bem pontuais. Também segui a arquitetura dos outros sistemas da Signify, para que fosse fácil plugar o nosso neles se um dia unificassem.

O time não usava a biblioteca

A resistência ao sistema veio do meu próprio time, que insistia em usar componentes que não existiam na biblioteca. Parte disso era falta de familiaridade com a ferramenta: muitas vezes o designer só não sabia customizar um item que já estava componentizado.

Revisei todas as telas antes do handoff, marcando o que estava fora da lib, e treinei o time no Figma. Para o que faltava, criei um arquivo no Figma que chamei de parking lot. O designer punha ali o componente que tinha criado, e eu revisava, ajustava o que estava fora do padrão e promovia para a lib.

1. Componente novo
2. Parking lot
3. Minha revisão
4. Biblioteca

Antes do handoff, toda tela passava pela mesma revisão.

Em volta do sistema, cuidei da governança, com changelog e lançamento de versões, e criei os fluxos de trabalho do time: pedido de componente novo, validação e auditoria de telas, handoff e uma checklist de aceite depois do desenvolvimento.

Em cerca de 2 meses, o time passou a montar as telas só com o sistema e a pedir o que precisava. O preço apareceu no tempo: o sistema levou cerca de 2 anos para ficar sólido, porque só eu olhava para ele enquanto fazia toda a gestão do time. E o projeto mudou de rumo no meio do caminho, o que me fez refazer algumas coisas.

Tentei travar o uso de componente de fora por regra e não consegui. A revisão funcionou porque sair do sistema sempre custava refazer muita coisa, e o time entendeu isso na prática.

Liderar o time e depois pôr a mão na massa

No começo, o meu papel tinha muita gestão: feedback recorrente, 1:1, crítica de design, PDI por iniciativa minha, input nas avaliações e reuniões de time. Calibrei a base que o time usava, que era o design system, as rotinas de equipe e a visão de design de onde queríamos chegar.

Com o time mais independente, entrei na squad core para desenhar as funcionalidades principais, sem largar de todo a liderança. A alocação de pessoas era decisão da conta, e com o tempo o time encolheu até sermos eu e mais 2 designers.

A primeira frente foi o configurador de produtos, o core do negócio. Testamos algumas versões com usuários reais (os testes eu conduzi junto com outra pessoa do time), e o configurador foi um dos pontos mais elogiados pelos clientes até a minha saída. A trilha cresceu até abraçar praticamente todo o e-commerce, com a negociação de preço dentro da plataforma no lugar do e-mail.

O resultado

Os 4 sistemas viraram 1 plataforma, usada em 3 continentes por clientes, agents, distribuidores e arquitetos. Cada marca tem o seu portal, com nome próprio; o da Cooper Lighting está no ar como PRISM Portal. De dentro de um portal, um agent, por exemplo, troca para o de outra marca para achar os produtos dela. O design system viveu os 5 anos em que estive no projeto.

Não havia painel de métricas, então medi com o que eu tinha: o fechamento das tarefas de design no Jira e o meu tempo na squad. Quando os padrões amadureceram, o tempo de desenho e entrega das telas ficou de 50% a 70% menor. Na auditoria de acessibilidade, contraste e tipografia quase sempre passavam, porque a biblioteca nasceu seguindo essas regras.

Antes · fluxo simples3 dias

Com os padrões prontos1 dia

O time ganhou autonomia de decisão, passou a se comunicar de forma assíncrona e a refazer menos.

O que eu faria diferente

Era um mercado em que eu nunca tinha trabalhado, e demorei para entender o que a empresa fazia. Eram várias inseguranças, e por causa delas coloquei pouco da minha visão de produto e do refinamento visual, mesmo tendo autonomia para isso.

Também faltou um roadmap claro de funcionalidades e telas, cascateado por prioridade de entrega, e o trabalho ficava meio perdido. Foi um erro meu e da gestão do projeto. Eu definiria uma linha de base no primeiro dia, para mostrar o antes e o depois com números, e forçaria mais contato com o design de fora do projeto.