Quando assumi como Head of Product Design na meutudo., o time de design estava crescendo mais rápido do que os processos. O que funcionava para 3 designers começava a travar com 7. Entregas duplicadas, componentes divergentes, decisões tomadas sem visibilidade para quem precisava delas. O problema não era falta de talento — era falta de sistema.
## O erro que quase todo Head comete
A tentativa instintiva é criar mais documentação. Um Figma com guidelines. Uma Notion page com regras de nomenclatura. Reuniões de alinhamento semanais.
Isso não é DesignOps. Isso é burocracia com nome bonito.
DesignOps real tem uma pergunta central: **como o time entrega valor de forma repetível, sem depender de heróis individuais?**
A resposta tem três eixos:
1. **Sistema** — o Design System como produto interno, não como artefato
2. **Processo** — upstream e downstream em sincronia, com métricas combinadas antes do escopo
3. **Pessoas** — autonomia real, não autonomia gerenciada
## Design System como produto interno
A mudança de mentalidade mais importante que fiz na meutudo. foi tratar o Design System como produto — com as mesmas ferramentas que usamos para qualquer produto digital:
- **Discovery com os consumidores**: entrevistei as squads para mapear jobs-to-be-done dos componentes. Quais eram usados mais? Quais causavam mais dúvidas? Quais geravam mais divergência?
- **Roadmap priorizado por impacto**: frequência de uso × custo de manutenção. Não prioridade por preferência estética.
- **Métricas de adoção**: quantos componentes do DS vs. componentes customizados em produção. Tracking em dashboard, visível para todo time.
- **Releases versionados com changelogs**: cada designer sabia o que mudou, por quê, e como migrar.
O resultado em 18 meses: de 11 variantes divergentes por tipo de componente para 1. Eficiência operacional +36%.
## A métrica que ninguém mede
A maioria dos times de design mede output — telas entregues, componentes criados, sprints completadas.
Nenhum desses números importa para o C-level. O que importa é **Time-to-Market** e **impacto em métricas de negócio**.
Quando estruturei o DesignOps na meutudo., passei a medir:
- **Lead time de design**: tempo entre abertura do ticket e entrega do Figma aprovado
- **Tempo de ramp-up de novos designers**: quanto tempo até a primeira contribuição autônoma ao DS
- **Taxa de reaproveitamento**: % de componentes novas telas que usam DS vs. criam do zero
Essas métricas transformaram como eu conversava com o C-level. Paramos de falar em "entregamos 40 telas esse sprint" e passamos a falar em "reduzimos o lead time em 22% nos últimos 60 dias".
## Upstream e downstream em sincronia
O segundo grande problema que resolvi: a desconexão entre discovery e entrega.
Na maioria dos times, discovery e entrega são mundos separados. O time de research faz o estudo, apresenta, e a entrega começa do zero sem memória do que foi descoberto.
Minha solução foi acoplada: **discovery contínua alimentando a esteira de entrega**. Pesquisa abre o campo, execução decide o jogo. Especificamente:
- Service blueprints compartilhados com engenharia e produto desde o início
- Validações em ondas curtas (não esperamos o design finalizado para testar)
- Decisões registradas com contexto — o que testamos, o que descartamos e por quê
- Métricas de sucesso combinadas antes do escopo, não definidas depois do retrospect
Na Remessa Online, onde atuo hoje, isso se traduz em: −25% em lead time, +15% de aceleração no desenvolvimento via Design System como produto interno.
## O que DesignOps não é
Para fechar com clareza:
- DesignOps não é um cargo. É uma prática distribuída no time.
- DesignOps não é ferramenta. O Figma certo não resolve processo errado.
- DesignOps não é documentação. É sistema que funciona quando você não está.
A pergunta certa não é "que ferramenta vamos usar?". É "o que torna o design repetível neste contexto específico?"
Essa resposta vai ser diferente para cada time, cada empresa, cada momento de maturidade. Mas a lógica de chegar lá — partir do comportamento do time, medir o que importa, criar sistema antes de processo — essa parte é universal.
---
*Mailton Lima é Head of Product Design na Remessa Online. Escreve sobre liderança de design, DesignOps e produto. [Entrar em contato](mailto:mailton.lima.mag@gmail.com) ou [conectar no LinkedIn](https://www.linkedin.com/in/mailtonlima-designleadership/).*