Empresa
Soft house
Como a governança de componentes e o uso de variáveis no Figma aceleraram em 4x a velocidade de criação de layouts, eliminando gargalos com a engenharia e o QA em uma soft house.

Empresa
Soft house
Papel
Design Lead
Escopo
Design Ops / 2025
Equipe
Design, Engenharia e QA
Desafio
Arquivos sem padronização, ausência de Auto Layout e falta de componentização centralizada inflavam o tempo de desenvolvimento e criavam retrabalho constante entre Design, Engenharia e QA.
Estratégia
Conectar o PRD à stack técnica de cada projeto, espelhando a biblioteca real no Figma e usando tokens, variantes e Auto Layout como base operacional.
Resultados
Redução de 75% no tempo de tela, handoff mais limpo, mais de 100 componentes reutilizáveis, 90% de adoção nos projetos e maior previsibilidade de entrega.
4x
velocidade de criação
Tarefas repetitivas de layout passaram de 2 horas para 30 minutos.
+100
componentes reutilizáveis
Componentes padronizados com propriedades, variantes e estados reais de código.
90%
adoção nos projetos
Modelo implementado em projetos ativos e novos pela flexibilidade das bibliotecas.
Fragmentação técnica e operacional
Ao assumir a atuação na empresa, encontrei uma alta dívida de design acumulada. Os arquivos do Figma careciam de padronização estrutural: ausência crônica de Auto Layout, falta de componentização centralizada e estilos obsoletos sem variáveis ou tokens.
A empresa operava múltiplos projetos simultâneos, usando tecnologias variadas como React, Angular e Chakra UI de forma isolada. Sem um ecossistema de design conectado ao desenvolvimento, a falta de sincronia entre visual e código obrigava desenvolvedores a recriarem componentes a cada handoff.
Alterações simples de marca, cores ou tipografia exigiam refatoração manual tela por tela. Atualizações que deveriam ser instantâneas viravam dias de trabalho repetitivo.
O vaivém com QA também era constante por quebras responsivas e inconsistências de propriedades visuais. A meta foi reduzir atrito sem criar mais processo que o necessário.
Alinhamento técnico entre design, engenharia e QA
Para estancar o desperdício de tempo e estruturar governança de design sem gerar atrito cultural, a estratégia foi dividida em três frentes.
Antes do início de qualquer novo projeto, design e engenharia passaram a alinhar a stack diretamente no PRD. O Figma deixava de ser folha em branco e passava a espelhar a biblioteca real que seria usada no código.
A mudança foi sustentada por três pilares operacionais:
Como reduzir dívida de design sem gerar atrito cultural no time?
Dor
A fragmentação existia dentro de uma rotina ativa. Uma imposição rígida aumentaria resistência e custo de adoção.
Decisão
Conduzir observação e escuta ativa para mapear onde as maiores fricções técnicas aconteciam.
Como impedir que o design nasça desconectado da stack que será implementada?
Dor
Projetos em React, Angular e Chakra UI recebiam layouts sem correspondência direta com suas bibliotecas de código.
Decisão
Antes de qualquer novo projeto, mapear a stack no PRD e construir o Figma espelhando a biblioteca que seria usada no código.
Como tornar Auto Layout, variantes e variáveis parte do dia a dia sem burocracia?
Dor
O time via padronização como etapa extra, não como economia de tempo.
Decisão
Conduzir workshops focados em ganhos pragmáticos de produtividade com Auto Layout, variantes e variáveis nativas.
Solução
Transformando arquivos fragmentados em um ecossistema governado por padrões, tokens e colaboração.
Diagnóstico
Evidência do fluxo anterior: ausência de padrões globais, camadas desorganizadas e desalinhamento técnico que inflavam o tempo de desenvolvimento e o vaivém com o QA.

Handoff
Fluxo integrado: a escolha da tecnologia no PRD passou a governar a fundação dos arquivos de design, eliminando fricção de código customizado.

Tokens
Matriz de taxonomia: padronização semântica de variáveis exportadas via JSON para sincronização entre bibliotecas do Figma e repositórios de engenharia.
Arquitetura
Criamos um template operacional para orientar novos projetos: fundamentos, componentes e documentação passaram a dar uma base comum para designers e desenvolvedores, reduzindo curva de adoção e preservando memória técnica. Cada produto ainda podia variar conforme stack, contexto e maturidade, mas para a grande maioria dos cenários o modelo oferecia um ponto de partida claro e reutilizável.

Eficiência
Métrica de impacto operacional: ganho de eficiência no tempo de tela e adoção do novo modelo em 90% dos projetos ativos e novos após a maturidade do ecossistema de componentes.
A virada de chave no processo e a eliminação da dívida de design trouxeram métricas expressivas de eficiência para a operação.
4x
velocidade de criação
Tarefas repetitivas de layout passaram de 2 horas para 30 minutos.
+100
componentes reutilizáveis
Componentes padronizados com propriedades, variantes e estados reais de código.
90%
adoção nos projetos
Modelo implementado em projetos ativos e novos pela flexibilidade das bibliotecas.
-75%
tempo por tela
Manutenção e criação de telas ficaram drasticamente mais rápidas com tokens e componentes.
QA & Dev
retrabalho reduzido
A conformidade técnica dos componentes reduziu refatoração no handoff e ciclos de correção no QA.
PRD
previsibilidade de escala
O alinhamento técnico desde a especificação permitiu estimativas mais seguras.
O projeto reforçou que escala em design nasce quando arquivo, processo e stack técnica deixam de competir entre si.

UX/UI Design
Como o redesign do fluxo de inspeção garantiu mais eficiência e conformidade regulatória para o negócio.
Ver case

Sistema web e mobile app
Como a construção de um ecossistema unificado e o uso de voz (IA) eliminaram gargalos de comunicação e garantiram a segurança dos agentes.
Ver case