Design System Copastur
- Ana Paula Curtipassi
- há 4 dias
- 3 min de leitura
Atualizado: há 3 dias
Escalando produtos críticos com variabilidade controlada e governança
Papel: Líder de Design de Produto (UX/UI)
Responsabilidade: Estratégia, visão, governança e liderança do Design System
Contexto: Ecossistema de produtos financeiros e operacionais (CSO, Smart Client e plataformas internas)
Por que um Design System não era suficiente
Quando a Copastur iniciou a evolução de seus produtos digitais, rapidamente ficou claro que um Design System tradicional não resolveria o problema real.
Não se tratava apenas de padronizar botões, cores ou tipografia.O desafio era mais profundo:
Como escalar múltiplos produtos, com níveis distintos de complexidade e risco, mantendo consistência, velocidade e segurança — sem engessar a operação?
Sistemas financeiros e operacionais exigem densidade informacional, exceções frequentes e governança explícita. Um sistema rígido quebraria a operação. Um sistema flexível demais criaria caos.
Esse foi o ponto de partida da minha atuação como líder.
A tese que guiou o Design System
Desde o início, estabeleci uma tese clara para orientar decisões técnicas e estratégicas:
Um Design System só escala quando oferece variabilidade controlada dentro de padrões bem definidos.
Essa tese passou a ser o critério para:
Decidir o que padronizar
Onde permitir flexibilidade
Como evitar explosão de variantes
Como alinhar design, produto e engenharia
Ela se tornou um instrumento de governança, não apenas de UI.
Meu papel como líder
Minha atuação esteve concentrada em quatro frentes principais:
1. Direção estratégica
Definição da visão do Design System como infraestrutura de produto
Alinhamento com liderança de Produto, Tecnologia e Operação
Conexão direta entre decisões de design e KPIs do negócio
2. Arquitetura de experiência
Definição dos princípios estruturais:
Consistência sem rigidez
Clareza para contextos críticos
Escalabilidade como requisito, não consequência
Orientação sobre padrões de densidade, estados, hierarquia visual e feedbacks
3. Governança e processo
Criação de rituais, critérios de entrada e evolução do sistema
Definição de quando algo vira padrão e quando permanece exceção
Acompanhamento contínuo da adoção nos produtos
4. Desenvolvimento de pessoas
Mentoria direta do designer responsável pela construção do sistema
Validações estratégicas e direcionamento técnico
Garantia de autonomia com alinhamento claro de objetivos
O ponto de partida: fundações sólidas, mas insuficientes
O trabalho começou pelas bases clássicas:
Design tokens de cor, tipografia, grid e espaçamentos
Padronização inicial de linguagem visual
Essa etapa trouxe alinhamento rápido, mas também revelou algo importante:
as fundações resolvem consistência visual, não complexidade operacional.
O verdadeiro desafio apareceu quando entramos nos componentes mais complexos.
O dilema da variabilidade
Com o avanço do sistema, surgiram demandas legítimas dos times de produto:
Diferentes comportamentos para o mesmo componente
Contextos operacionais específicos
Exceções que não cabiam em um padrão único
Um pedido recorrente era a criação de inúmeras variações de componentes — especialmente botões e tabelas.
Aqui, meu papel foi mudar a pergunta do time:
Em vez de “quantas variações precisamos?”, passamos a discutir “quais variáveis realmente importam para o negócio e para o usuário?”
A solução: variabilidade como regra, não como exceção
A direção que defini foi clara:
Variabilidade, sim — mas explicitada, controlada e documentada
Nenhuma variação sem propósito funcional ou operacional
O uso de variáveis booleanas no Figma permitiu:
Combinar flexibilidade e padronização
Evitar duplicação de componentes
Tornar decisões visíveis e rastreáveis
Mais importante do que a solução técnica foi o modelo mental criado para o time.
A ponte com desenvolvimento
Desde o início, garanti que o Design System não fosse um artefato isolado do design.
Atuei diretamente na:
Conexão entre designers e front-end
Discussão de viabilidade, manutenção e escalabilidade
Decisão estratégica de adaptar uma biblioteca open-source como base
Essa escolha trouxe:
Velocidade de implementação
Padronização técnica
Redução drástica de ruídos no hand-off
O hand-off deixou de ser transferência e virou colaboração contínua.
Governança: mantendo o sistema vivo
Para mim, um Design System não é um projeto — é um organismo.
Implantei práticas de governança como:
Versionamento e histórico de mudanças
Documentação orientada a decisão, não só a uso
Roadmap evolutivo alinhado aos produtos
Critérios claros para inclusão, alteração ou depreciação
Isso garantiu que o sistema evoluísse sem perder coerência, mesmo com múltiplos produtos e squads.
Impacto no negócio
Os efeitos do Design System foram mensuráveis e estratégicos:
–85% no tempo de prototipagem(de semanas para dias)
Redução quase total de erros de hand-off
Aumento significativo de velocidade de entrega
Crescimento de tráfego, engajamento e usuários ativos em produtos-chave
Aumento da confiança de stakeholders na experiência digital
Mais do que eficiência, o sistema trouxe previsibilidade e confiança.
O aprendizado como líder
Este projeto reforçou uma convicção que levo para qualquer organização:
Padronizar não é limitar. É criar condições para que produtos, times e decisões escalem com qualidade.
Como líder, meu maior impacto não foi desenhar componentes —foi desenhar limites inteligentes, processos sustentáveis e uma visão compartilhada.
Conclusão
O Design System da Copastur é a materialização da minha forma de liderar design: estratégia clara, governança explícita, foco em pessoas e impacto real no negócio.
Não é uma biblioteca. É uma infraestrutura de crescimento.
Comentários