Open Library: Um sistema sem favorecidos
O desafio vai além de apenas criar uma biblioteca, é fazer que ela se adapte à identidade visual de centenas de clientes diferentes.
Este case ainda está em implementação — ele não fecha com resultado medido. Ele mostra como pensei a arquitetura sob uma restrição real, antes de qualquer componente existir.
Período
Mar/2026 - Atualmente
Papel
Product Designer
Empresa
OpenCON/OpenMEI
Interface
Mobile/Desktop
Cenário
A plataforma cresceu como um sistema legado, sem um sistema visual estruturado por trás. Cada tela nova herdava parte da lógica da anterior, sem regras formais que garantissem consistência. O resultado aparecia em três frentes: no volume de bugs de usabilidade, na velocidade de quem desenhava e desenvolvia novas telas, e na primeira impressão de quem usava o produto.
Havia ainda uma camada extra de complexidade: por ser whitelabel, cada cliente sobe com sua própria cor e logotipo. Assim, o design system não podia ser apenas um guia de estilo, precisava funcionar em qualquer combinação de marca, sem depender de curadoria manual caso a caso.
Responsabilidades
A proposta de construir o design system foi minha, apresentada ainda em 2025. A PM comprou a ideia de imediato, mas a decisão foi levada ao CEO, que optou por adiar. O projeto só ganhou luz verde no início de 2026,, quase um ano depois da proposta original.
Fui responsável pela construção visual completa do design system: definição de tokens, guidelines, e o desenho de todos os componentes e páginas usados tanto na plataforma quanto no aplicativo. A brand guideline já existia antes do projeto; meu papel foi atualizá-la em parceria com o time de marketing, garantindo que o novo sistema mantivesse coerência com a marca já estabelecida. Hoje sigo responsável pela documentação no Figma e pela governança do sistema.
Restrições
O prazo era curto para o tamanho da tarefa: repensar toda a linguagem visual de uma plataforma em produção, sem parar o desenvolvimento de novas funcionalidades no meio do caminho. E existia a restrição estrutural do whitelabel, qualquer decisão de cor, espaçamento ou hierarquia precisava sobreviver a centenas de combinações de marca diferentes, não apenas uma.
Equipe
Uma product manager, um designer (eu, que liderei o projeto do início ao fim), um dev sênior de frontend, um dev júnior de frontend, um dev sênior de backend.
Problema
Três sintomas diferentes, uma mesma causa
Bugs de usabilidade
Cerca de 80 chamados mensais relacionados a inconsistência visual e de comportamento entre telas.
Velocidade de criação
Cada tela nova era desenhada e construída quase do zero, sem componentes reutilizáveis. O que significava retrabalho constante tanto para design quanto para desenvolvimento.
Percepção de amadorismo
Botões diferentes para a mesma ação, hierarquias diferentes para o mesmo tipo de conteúdo. Não era só uma questão estética, a falta de padrão comunicava, sem querer, que o produto não era maduro.
Processo
A regra muda, a marca do cliente não
A pergunta que guiou o projeto inteiro não foi "como criar um design system bonito", mas sim: como construir um sistema que não quebra, independente de qual cliente esteja usando a plataforma no momento.
Essa diferença de perspectiva foi essencial, pois deslocou o foco da estética para a robustez. Em vez de buscar apenas um visual atraente, o objetivo passou a ser garantir consistência e estabilidade em qualquer cenário de uso, considerando que cada cliente possui suas próprias personalizações e necessidades específicas.
Diagnóstico
A primeira hipótese, sugerida pelos desenvolvedores, foi limitar a personalização dos clientes, "proibindo" cores ou logos que fugissem do padrão do sistema. Ao validar essa direção com os outros setores, foi unânime que a restrição não seria negociável comercialmente, já que o cliente final precisa ver a própria marca sem concessão. Diante disso, optei por não seguir com essa hipótese.
Solução
Em vez de restringir a marca do cliente, a solução foi mudar onde a regra vive. Construí uma paleta de 9 cores em OKLCH, com todos os tokens do sistema calculados matematicamente (luminosidade, contraste e hierarquia) em vez de definidos visualmente cliente a cliente. Isso resolveu o problema mais comum: quando a cor de marca era clara ou escura demais para manter legibilidade, a própria paleta absorvia a correção, sem exceções manuais.
Arquitetura
As decisões mais importantes do projeto vieram logo no início: hierarquia tipográfica e escala de espaçamento. Um sistema que nasce com essa base malfeita já está fadado ao fracasso, pois qualquer inconsistência ali se multiplica em cada componente construído em cima dela depois. Rodei várias iterações de escala até chegar a uma proporção que se sustentasse tanto em telas densas de dados financeiros quanto em telas mais simples do aplicativo.
Visual
A segunda decisão de craft foi definir o tom visual da plataforma como um todo, priorizando o público-alvo em vez de tendências de mercado. Contadores e MEIs do Simples Nacional não têm, em média, alta maturidade digital, algo que já suspeitávamos e que testes com usuários confirmaram depois. Isso significou optar por um visual mais conservador em pontos como o menu, em vez de arriscar um padrão de navegação mais moderno, porém menos familiar para esse público.
Componentização
Cada componente precisava resolver, ao mesmo tempo, modo claro e escuro baseados nos tokens, adaptação a qualquer paleta de cliente e reuso entre mobile e desktop sem perder coerência. Isso gerou várias refações, e nenhum componente ficou pronto na primeira tentativa. O exemplo mais claro foram as tabs: com várias subpáginas em uma mesma seção, o desafio foi garantir navegação óbvia sem confundir o usuário sobre onde estava. Rodei testes A/B com clientes reais, descartando por completo as variações com desempenho inferior.
Limpeza
Com o design system como justificativa para revisitar a plataforma inteira, aproveitamos para corrigir problemas de usabilidade que não dependiam diretamente do sistema visual, mas que estavam represados havia tempo. Esse foi só o primeiro corte, um replanejamento mais profundo de funcionalidades segue em andamento, fora do escopo imediato do design system.
Desafio
Vender tempo para quem queria velocidade
O maior atrito do projeto não foi técnico, foi de prioridade. Parte dos stakeholders enxergava os testes A/B de componentes como tempo tirado do cronograma, e não como parte do trabalho. Defender esse espaço, insistindo em testar antes de finalizar um componente que se repetiria centenas de vezes pela plataforma, significava argumentar repetidas vezes que um erro de decisão em um token ou componente base custaria muito mais caro depois de replicado do que naquele momento, ainda em fase de desenho.
A restrição do whitelabel foi resolvida na arquitetura, através da paleta OKLCH, mas a adoção interna do sistema é uma segunda batalha, ainda em curso. Sem dado formal de medição até agora, o papel que venho ocupando é o de "design system advocate" dentro do time: reforçar, na prática do dia a dia, por que usar o sistema, mesmo quando parece mais rápido no curto prazo desenhar algo pontual, é o que mantém a manutenção viável no médio prazo.
Resultado
Uma vitória quase completa
Já aconteceu
Redução do menu de mais de 30 funcionalidades para menos de 10;
Remoção de 8 funcionalidades com menos de 1% de uso, identificadas via Mixpanel.
Correção geral de lógicas, regras de negócio mal implementadas e bugs.
Dado
Descrição
Dado
Descrição
Dado
Descrição
Projeção
A estimativa interna é reduzir os cerca de 80 bugs mensais de usabilidade para uma faixa de 10 a 15, uma redução de aproximadamente 5 vezes. Além disso, espera-se uma redução de 50% no tempo de criação de novas telas, graças à componentização.
Dado
Descrição
Dado
Descrição
Aprendizado
Produto com sem dono morre de fome…
Diferente do BPO Financeiro e do EmitaZap, este case não fecha com um resultado medido, mas com uma arquitetura resolvida e uma adoção ainda em construção. A decisão mais defensável do projeto não foi visual, foi estrutural: em vez de restringir a marca do cliente para proteger o sistema, o sistema foi construído para absorver qualquer marca sem quebrar.
Os próximos passos são claros e ainda em aberto: definir onde e como a documentação completa vai viver, já que o Figma sozinho não escala para o tamanho que o sistema já tem, e desenhar um modelo de governança formal. Na prática do whitelabel, isso significa administrar apenas dois modelos de sistema (claro e escuro), em vez de centenas de exceções por cliente, mas ainda sem regras escritas sobre quem aprova o quê.
