Design que
chega à
produção.

Na ponta, o desalinhamento virava atrito.

No fluxo de doação pelo Totem, estados genéricos de processamento e erro deixavam o usuário sem saber se a operação havia sido concluída. A incerteza aumentava a busca por ajuda e a dependência da equipe da igreja.

Tornamos os estados mais explícitos, preservando velocidade sem comprometer segurança e compreensão.

O gargalo não era desenhar. Era preservar contexto até a produção.

• Conhecimento fragmentado
  Regras importantes viviam na memória de poucas pessoas.

• Fontes de verdade concorrentes
  Figma, documentação, DS e código podiam representar versões diferentes da mesma decisão.

• Baixa rastreabilidade
  Era difícil entender por que uma decisão existia e como deveria ser implementada.

• Entrega dependente de alinhamento manual
  Cada nova iniciativa exigia reconstruir contexto.

Nada chegava à produção sem o time.

• diagnostiquei o gargalo sistêmico,
• propus e defendi o Playbook 2.0,
• estruturei a arquitetura de contexto,
• estudei segurança, LLMs e orquestração,
• participei da definição dos agentes,
• conduzi ciclos de UX, validação e revisão,
• conectei design, documentação e operação.

• outros designers contribuíram com execução e memória histórica,
• Produto participou de priorização e refinamento,
• Engenharia validou viabilidade, integração e produção,
• decisões críticas permaneceram humanas.

Antes de virar contexto para agentes, o Playbook foi contexto para o time.

Propus o Playbook 2.0 como uma fonte compartilhada de regras, decisões, padrões e critérios de qualidade.

A iniciativa foi abraçada pela liderança e recebeu apoio de uma nova frente de trabalho. Junto a outros dois designers, consolidamos conhecimentos que estavam distribuídos entre arquivos, processos e pessoas com diferentes tempos de casa.

O objetivo não era produzir mais documentação. Era construir uma base capaz de acompanhar a entrega e reduzir a perda de contexto entre produto, design e engenharia.

Não era apenas um “guia de estilos” bonito. Era um sistema operacional que responderia:

Como trabalhamos? Por quê? Quando? Com quem?

• Design System Centralizado
  Componentes reutilizáveis, tokens de design, guidelines de acessibilidade em um único lugar. Mas mais importante: documentação que engenharia realmente usava.
• Processos Padronizados
  Workflows claros para discovery, design, handoff e QA. Cada etapa tinha um “dono” e critérios de sucesso. O objetivo era reduzir alinhamentos recorrentes sobre “como fazer”.
• Checklist de Qualidade 
  Critérios de acessibilidade, responsividade e alinhamento com a marca aplicados à revisão dos projetos. Não era sobre “confiar” – era sobre ter critérios objetivos.
• IA como Copiloto (Figma Make & Manus AI)
  Utilizei IA para minerar dados e automatizar documentação, liberando meu tempo sênior para estratégia. IA não fez o trabalho ela amplificou minha capacidade de escalar.

Documentar o contexto foi o começo. O próximo passo era torná-lo executável.

Como permitir que agentes trabalhassem com regras reais do produto sem perder segurança, consistência e supervisão humana?

Uma camada compartilhada entre decisão, interface e código.

• Brain: regras, decisões e memória do produto,
• Body: produto, componentes e implementação,
• Agentes: especialistas em interface, conteúdo, documentação e código,
• Integrações: Jira, Figma e repositório,
• Governança: permissões, revisão humana, testes e rastreabilidade.

O agente não decidia o que deveria ir para produção. Ele ampliava a capacidade de execução dentro de um contexto e de limites definidos pelo time.

Automação com limites, testes e rastreabilidade.

• Regras e estados: fluxos e exceções verificados,
• Aderência ao DS: componentes, tokens, idiomas e modos,
• Revisão humana: o time mantinha a decisão final,
• Rastreabilidade: entregas ligadas às histórias e critérios no Jira.

Evidências da transformação

Capacidade entregue

• DSV3 em produção;
• português, espanhol e inglês,
• light e dark mode,
• contexto legado incorporado,
• agentes especializados;
• integração com Jira e repositório,
• entregas rastreáveis,
• time de três designers operando o modelo.

• fricções antigas de UX passaram a ser tratadas em ciclos menores,
• o time reduziu esforço manual na criação e documentação de telas,
• design ganhou mais espaço para pesquisa, estratégia e decisão,
• maior proximidade entre design e engenharia,
• contexto deixou de depender exclusivamente da memória individual.

Estas medidas permanecem em acompanhamento. Não apresento percentuais de eficiência ou redução de retrabalho como resultados comprovados sem base e período definidos.

• lead time,
• retrabalho,
• volume de tickets,
• tempo de documentação,
• divergências entre design e produção.

• DSV3 levado à produção com uma base compartilhada entre Design e Engenharia
• Design System estruturado em português, espanhol e inglês
• Experiência preparada para os modos light e dark
• Regras, decisões e documentação conectadas ao fluxo de entrega
• Agentes especializados trabalhando com contexto versionado e limites definidos
• Entregas vinculadas às histórias e aos critérios registrados no Jira

• Automatizar antes de organizar o contexto apenas escala inconsistências.
• IA amplia a execução, mas decisões críticas continuam exigindo repertório, responsabilidade e revisão humana.
• Uma fonte de verdade só gera valor quando acompanha o trabalho até a produção.
• Aproximar Design e Engenharia é mais importante do que aperfeiçoar arquivos isoladamente.
• Senioridade também significa reconhecer limites, dividir a operação e construir capacidade com o time.
• Documentação viva é mais valiosa do que documentação perfeita.

O resultado não foi apenas um novo Design System ou um conjunto de agentes.

Foi a criação de uma capacidade que a empresa perseguia havia anos: transformar contexto complexo em decisões consistentes e fazer essas decisões chegarem ao produto.

A principal mudança não foi desenhar mais rápido.

Foi permitir que design, produto e engenharia trabalhassem sobre a mesma realidade.