Nem todo problema de design precisa de uma solução do zero
O case mais impressionante nem sempre é a decisão certa para o momento da empresa.
Como levar consistência visual para uma operação de alto volume, sem tempo nem orçamento para construir um design system do zero.
Entrei na BCR.CX como a primeira designer de produto da empresa, sem um cargo claro me esperando, e nas primeiras semanas defini a estratégia de design system que a empresa usa até hoje — priorizando velocidade e impacto real sobre o case mais bonito para mim.

Quando entrei na BCR.CX, não existia cargo de UX ou Product Design antes de mim. A empresa sabia que os projetos que eu havia feito como freelancer tinham dado certo — usaram minhas telas nas próprias apresentações comerciais para a Zendesk por meses — mas ninguém sabia exatamente o que fazer com uma designer de produto dentro de casa. Me colocaram como Head de Produto sem eu ter pedido o cargo, e topei aprender a função no processo.
Nas minhas primeiras semanas, mapeei tudo que existia de produtos e interfaces feitas até então. O cenário: nenhum padrão, cada tela com sua própria lógica visual, qualidade estética muito abaixo do que a empresa precisava para se apresentar como referência no mercado.
Antes da BCR.CX, passei três anos no Hub de Design da TOTVS como uma das responsáveis pela manutenção do Animalia Design System — um DS multimarca, com temas e acessibilidade madura. Eu sabia que conseguiria construir algo parecido do zero para o Conciex, e via um certo apelo nisso.
Decidi não fazer. A BCR.CX opera em ritmo de startup, sem tempo nem maturidade de design e tecnologia para sustentar a construção de um design system próprio naquele momento. O resultado importava mais rápido e mais barato do que o processo mais impressionante no papel.
Pesquisei as opções disponíveis olhando para o que os produtos da empresa realmente precisavam. A maioria dos produtos da BCR.CX são apps Zendesk, e a empresa se posiciona como uma das principais parceiras Zendesk do mercado. O Garden, design system open source da própria Zendesk, não era o mais completo nem o meu favorito — mas era a opção que resolvia a maior parte do problema, mais rápido, com menor risco.
Preparei um plano de evolução das interfaces em ondas e redesenhei telas conhecidas da empresa usando o Garden, para tornar a proposta tangível antes de apresentar.
Levei isso para o dono da empresa e o CTO. Aprovaram. Além da melhora estética, o argumento central era técnico: padronizar reduz erro de desenvolvimento, acelera entrega e deixa os produtos coerentes entre si e com o próprio ambiente Zendesk — mesmo exigindo que boa parte do time aprendesse a usar uma biblioteca que não conhecia.
A marca interna de produtos digitais, Conciex, já existia — mas com identidade visual inacabada e inconsistente. Contratei um designer gráfico para fechar o rebranding.
Com a identidade pronta, o passo seguinte foi puramente técnico: ajustar os tokens do Garden para refletir a cara da Conciex. Foi a mudança mais simples de todo o processo e a de maior retorno perceptível — em poucos meses, os produtos passaram a parecer nossos, não emprestados da Zendesk, e os elogios de clientes sobre a qualidade visual aumentaram visivelmente.
A terceira onda — construir a versão própria do design system a partir do que aprendemos com o Garden — é o trabalho que meu time está começando agora, com muito mais contexto do que teríamos se tivéssemos começado do zero.
Como Head de Produto, tenho autoridade direta sobre o meu time, mas não sobre todos os times da empresa. A maioria aceitou a proposta depois de eu apresentar o racional. Um time não aceitou: o time de Projetos, que atua em entregas mais pontuais para clientes (diferente do time de Produto, que sustenta os apps Conciex).
O único dev front-end sênior da empresa, responsável por esse time, decidiu não adotar o Garden — nem nenhuma outra biblioteca de componentes. A decisão final ficou com ele, por ser o único sênior de front-end da casa.
O resultado prático: telas inconsistentes nesse time específico, prazos mais apertados e, nos últimos meses, demanda extra recorrente para o meu time apoiar entregas de Projetos que não fecham a tempo — com a vantagem, nesses casos, de conseguirmos entregar com mais qualidade e mais rápido, por já operarmos com o Garden e nossos tokens prontos.
Foi a primeira vez, na minha posição, que esbarrei no limite entre influência e autoridade — ter responsabilidade por um padrão que não posso simplesmente exigir de todo mundo.
A decisão de adotar em vez de construir foi contra o meu instinto — e foi a certa. Esse projeto me ensinou que velocidade e contexto da empresa importam mais do que o processo mais elegante.
O case mais impressionante nem sempre é a decisão certa para o momento da empresa.
Adotar, depois rebrandear, depois construir — cada onda só fez sentido por causa da anterior.
O argumento que convenceu a liderança não foi "vai ficar bonito", foi "vai reduzir erro e acelerar entrega".
Ter responsabilidade por um padrão da empresa não significa poder de exigir adesão de todos os times — aprendi a operar dentro desse limite sem abrir mão do objetivo.
Se o seu time também precisa decidir entre construir do zero ou adotar e evoluir com o tempo — ou lida com os limites de influência de uma liderança nova — provavelmente estamos falando a mesma língua.