Produto SaaS B2B de alta complexidade com esteira compartilhada entre Produto, Design, QA e Desenvolvimento, em um fluxo com alta dependência entre áreas.
Design operava sem fronteiras claras de atuação, absorvendo discovery mal direcionado, detalhamento de regras de negócio, estruturação de escopo e apoio a validações que extrapolavam seu papel.
Estruturei uma proposta de Design Ops para reorganizar a atuação de Design na esteira e redesenhar o handoff. A análise do processo indicava potencial de recuperar até 17 dias de sprint antes consumidos por espera, ajustes e burocracia operacional.
O problema não estava apenas no handoff. Ele começava antes, na forma como Design era acionado e operava dentro da esteira de tecnologia.
Essa análise partiu de uma percepção minha sobre recorrências no processo: o time de Design não apenas desenhava a solução, mas também absorvia parte da definição funcional, da preparação do escopo, do apoio à validação e da compensação entre áreas ao longo da entrega.
Com isso, o ciclo ficava mais lento, menos previsível e mais sujeito a refação. O handoff era um sintoma visível, mas o problema era estrutural.
Antes da proposta, o processo fazia o Design atuar como ponto de compensação da esteira. A demanda chegava pouco estruturada e o time seguia absorvendo lacunas até a entrega final.
PM passava o problema para Design, mas o card não era escrito no Azure com o nível de definição necessário para orientar o trabalho.
O designer iniciava a exploração com base em conversas e reuniões no Teams, sem uma diretriz formal clara de problema, escopo ou critério de sucesso.
Sem direcionamento sólido, o discovery levava de 30 a 60 dias para retornar uma possível solução.
Quando a proposta chegava, ela ainda era revisada até se ajustar ao que PMs ou outros stakeholders tinham imaginado, gerando novas rodadas de refação.
Como a solução já chegava atrasada, não havia tempo suficiente para testar antes de seguir na esteira.
O designer passava a desenvolver a solução detalhando conteúdo, regras de negócio e elementos necessários para que QA conseguisse montar o roteiro de teste.
As USs eram quebradas pelos designers, e não por Desenvolvimento, o que ampliava ainda mais a carga operacional sobre o time.
Depois de pronto, o protótipo ainda passava por uma análise de Desenvolvimento para validar viabilidade técnica. Isso gerava refação e redistribuição de USs já após o desenho da solução.
QA apontava o que estava faltando no escopo para que os critérios de teste existissem, o que mostrava que parte da definição de responsabilidade das cadeiras estava difusa.
Mesmo depois disso, sem uma reunião consistente de refinamento, o escopo seguia mudando devido a legados e restrições tecnológicas não identificadas antes.
Após publicação, Design validava interface e QA voltava a apontar faltas em regras de negócio ou pontos já documentados no Notion. Isso levava a repetições exaustivas do processo.
O resultado era um fluxo em que Design acumulava descoberta, definição, detalhamento, preparação do escopo e compensação entre áreas. Isso não só tornava o handoff mais pesado. Tornava a atuação de Design estruturalmente ineficiente dentro da esteira.
Ao mapear esse fluxo, identifiquei gargalos que não eram pontuais. Eles revelavam um problema de distribuição de trabalho e de fronteiras de atuação entre as áreas.
Os principais gargalos estavam em cinco pontos:
Além de gerar retrabalho e ambiguidade, o modelo anterior também produzia um custo operacional mensurável.
Ao analisar os dados da equipe, identifiquei que o processo baseado em “escopo”, pausas e ajustes consumia o equivalente a 17 dias de sprint. Esse tempo não estava sendo investido em discovery, validação ou evolução da solução. Estava sendo perdido entre espera, reinterpretação, refação e compensações do fluxo.
Esse dado foi importante porque tornou o problema visível em termos de capacidade produtiva. A discussão deixou de ser apenas sobre desconforto operacional e passou a ser sobre desperdício real de tempo dentro da esteira.
O diagnóstico mostrou que o problema não era apenas de execução. Era de modelo operacional.
Na prática, a esteira tratava “escopo” como se fosse handoff. Mas os dois não cumpriam o mesmo papel. O escopo anterior concentrava regra de negócio, critérios de teste, decomposição de histórias, detalhamento funcional e compensações de lacunas do processo. Isso transformava o arquivo de Design em repositório de tudo o que a esteira não tinha resolvido antes.
Esse acúmulo distorcia o papel do Design. Em vez de atuar com foco em problema, solução, fluxo e qualidade da experiência, o time passava a absorver definições e responsabilidades que deveriam estar distribuídas entre Produto, Desenvolvimento e QA.
O resultado era previsível: discovery lento, refação frequente, validação técnica tardia, escopo instável e um handoff pesado demais para cumprir bem sua função.
A resposta para esse cenário não era ajustar uma etapa isolada. Era reorganizar a atuação de Design dentro da esteira e, a partir disso, redesenhar o handoff.
Estruturei a proposta em duas frentes complementares. A primeira revisava o fluxo de atuação entre Produto, Design, QA e Desenvolvimento. A segunda redefinia o papel do handoff (antigo escopo), tornando a documentação mais útil para implementação e menos carregada com definições que não deveriam estar concentradas no Design.
Revisão dos pontos de entrada, do encadeamento entre áreas e das responsabilidades ao longo do ciclo.
Reorganização da documentação para apoiar implementação sem transformar o Design em dono do escopo inteiro.
A primeira frente da proposta foi redesenhar o fluxo de atuação entre Produto, Design, QA e Desenvolvimento.
O objetivo era reduzir validações tardias, evitar que o Design assumisse definições que não eram suas e criar uma progressão mais clara entre problema, solução, viabilidade técnica, testes e publicação.
O fluxo proposto redistribui responsabilidades ao longo do ciclo de produto e reduz a dependência do design para atividades operacionais que deveriam estar compartilhadas com outras áreas.
Redesenhar o fluxo sem redistribuir responsabilidades manteria o mesmo problema com outra aparência.
Por isso, a proposta também explicitava o que passava a ser responsabilidade de Produto, Design, Desenvolvimento e QA em cada etapa. O objetivo era tirar o Design da posição de compensação do processo e devolver previsibilidade ao ciclo.
A matriz operacional ajudou a separar responsabilidades que antes ficavam concentradas no design, especialmente em definição de negócio, planejamento de testes e detalhamento técnico.
Uma parte importante do trabalho foi mostrar que o modelo anterior de “escopo” não equivalia a handoff.
O escopo usado até então funcionava como um documento de compensação da esteira. Ele misturava definição de negócio, critérios de teste, decomposição funcional, observações para QA e informações de interface em um mesmo artefato. Na prática, isso sobrecarregava o Design e tornava a documentação mais pesada, menos clara e mais vulnerável a lacunas.
A proposta de handoff partia de outra lógica. Em vez de concentrar tudo no Design, o handoff passava a documentar a solução: fluxos, estados, comportamentos, referências visuais e informações úteis para implementação. Regras de negócio, critérios de aceite e planejamento de testes deixavam de ser tratados como responsabilidade implícita do arquivo de Design.
Essa mudança não era apenas de formato. Era uma mudança de papel. O handoff deixava de ser “escopo ampliado” e voltava a ser documentação da solução dentro de uma esteira com responsabilidades mais bem distribuídas.
Depois, o handoff passou a organizar a solução de forma mais objetiva e mais útil para implementação.
Na prática, a nova estrutura passou a priorizar:
Também deixava mais claro o que não deveria continuar no handoff:
A proposta não tratava apenas de melhorar um entregável. Ela redefinia a participação do Design na esteira de tecnologia.
Com isso, o Design deixava de operar como ponto de compensação entre áreas e passava a atuar com fronteiras mais claras. Produto ganhava mais responsabilidade sobre definição inicial. Desenvolvimento entrava antes para validar viabilidade. QA deixava de funcionar como última camada de descoberta do escopo. E o handoff voltava a cumprir seu papel como documentação da solução.
Isso aumentava a previsibilidade do ciclo, reduzia refação e criava uma base mais madura para colaboração entre Design, Produto e Engenharia.
Este projeto não surgiu apenas para melhorar um handoff. Ele partiu de um problema mais estrutural: a forma como Design vinha atuando dentro da esteira de tecnologia, assumindo responsabilidades além do seu papel e operando em um fluxo com baixa previsibilidade.
A proposta buscava reorganizar essa atuação. Isso incluía rever o fluxo entre áreas, redistribuir responsabilidades e redefinir o papel da documentação de Design, para que o handoff deixasse de funcionar como compensação de falhas do processo e voltasse a cumprir sua função como documentação da solução.
Mesmo sem um ciclo completo de consolidação depois da proposta, o trabalho foi importante por tornar esse problema visível, dar forma a uma alternativa mais clara de operação e mostrar que parte relevante do tempo da equipe estava sendo consumida por ajustes, esperas e definições que poderiam estar melhor distribuídas ao longo da esteira.
Mais do que redesenhar um entregável, este projeto ajudou a estruturar uma forma mais coerente de atuação de Design dentro do ciclo de produto.
Vamos conversar sobre seu projeto ou oportunidade.
Estou disponível para novos desafios e colaborações.
Baixar Curriculo
