Da dispersão
ao padrão.

De onde isso veio.

Partiu de uma agenda da tribo onde realizamos uma dinâmica na planilha de Health Check da tribo, onde cada designer avaliou a saúde do dia a dia, com espaço reservado para sugestões e oportunidades de melhoria.

Fig. 01: Health Check da triboO recorte que disparou o projeto: "Sinto que o processo funciona no meu contexto", nota baixa, sem consenso sobre o porquê.

Cada squad decidia no feeling o que era suficiente para avançar de fase.

O tema processos teve neutralidade generalizada, e puxava junto outros indicadores como "Valor final", "Produtividade" e "Cadência".

O processo de design não tinha padrão, cada squad decidia no feeling o que era "suficiente" antes de avançar de fase, algo que só ficou visível quando o time parou pra falar sobre isso. Faltava um documento de requisitos mínimos, dizendo o que precisa estar pronto antes de avançar do entendimento para solução.

Criar um documento de planejamento prévio por iniciativa.

Criar um documento de planejamento prévio por iniciativa, pra oficializar o processo, prever tempo de execução e definir métrica de sucesso antes de desenvolver. E uma agenda semanal para o time trocar ideia sobre processo e iniciativas.

Encabecei o projeto do início ao fim, puxando a colaboração dos outros designers.

Peguei o resultado disperso do Health Check e transformei em um projeto com escopo definido: o que ia ser investigado, com que método, e até onde ia. Conduzi a fase de fundamentação: catalogar os 29 livros e frameworks, mapear a prática documentada das mais de 10 empresas de benchmark, desenhar as três perguntas da dinâmica aplicada ao time. Defini também a metodologia de cruzamento: sobrepor teoria, benchmark e prática real pra achar onde as três lentes discordavam, em vez de escrever o guia a partir de uma única fonte.

Quando a versão inicial ficou pronta, a decisão mais deliberada que tomei foi não terminar sozinho. Abri os seis templates que faltavam e distribuí um pra cada designer construir, e usei a nova agenda semanal (a Mesa Redonda) como espaço de revisão coletiva antes de publicar. Puxar a colaboração não foi delegar tarefa: foi garantir que quem ia usar o guia todo dia também tivesse assinado embaixo dele. Um documento imposto de cima pra baixo vira burocracia; um documento que o time ajudou a escrever vira ferramenta.

Como sustentamos o guia: base de evidência do projeto.

Para evitar suposições, fundamentamos cada diretriz em fontes rastreáveis, apoiando-nos em três pilares: teoria consolidada, referências de mercado e práticas atuais do nosso time.

Fig. 02: Board de catalogaçãoEtapa 2 (Benchmark) e Etapa 3 (Catálogo de referências) organizadas lado a lado. Cada rótulo de card cita a fonte.

01

Teoria: 29 materiais catalogados

Catalogamos 29 livros e frameworks, de Continuous Discovery Habits (Teresa Torres) a Shape Up (Basecamp), passando por DACI, RAPID, Kanban e o Double Diamond. O aprofundamento que mais rendeu veio do DesignOps Handbook (Dave Malouf). Cada requisito carrega o nome do autor entre parênteses. Rastreabilidade da origem de cada decisão.

Fig. 03: Parte do material catalogadoDe Continuous Discovery Habits ao DesignOps Handbook, cada um virou requisito rastreável no guia.

02

Benchmarking: 10+ empresas analisadas

Olhamos prática documentada de mais de 10 empresas (IBM, Intercom, Google, Amazon, Pinterest, Meta, Basecamp, InVision, Spotify, Microsoft e Airbnb), separando o que é processo publicado pela própria empresa do que é só princípio sem artefato público.

Fig. 04: Empresas analisadasIBM, Intercom, Pinterest, Spotify, Meta, entre outras: processo publicado, não só princípio sem artefato.

Fig. 05: Levantamento individualSeis designers, seis leituras do mesmo processo. A primeira evidência de que não havia um entendimento único do fluxo.

O resultado expôs uma fronteira nebulosa entre Discovery e Define. Discovery teve consenso máximo: 7 itens com 6 de 6 menções. Define teve consenso quase nulo. Só 1 item passou de 1 menção, e 16 cards migravam livremente entre as duas etapas conforme quem respondia. "Review" foi a única prática unânime como "sempre aplico" entre as 22 analisadas. Discovery concentrou 46 menções (44%) do que foi visto como inegociável, contra apenas 13 (12%) em Define.

Fig. 06: Consolidação por consensoDiscovery concentrou o maior consenso; Define, o menor. O sinal objetivo por trás da fronteira nebulosa.

Fig. 07: Frequência real de aplicaçãoO mesmo processo, visto pela frequência: o que o time diz que sempre faz nem sempre bate com o que o processo formal prevê.

O que os dados revelaram

Sobrepondo teoria, benchmarking e a dinâmica com o time, apareceram três versões do mesmo processo que quase nunca coincidem.

Da pesquisa ao guia

Chegou uma demanda. E agora?

Um guia de uso diário, escrito em tom de conversa, com os termos técnicos explicados no próprio texto. A demanda chega e só cruza a seta quando o mínimo de cada etapa estiver respondido.

O fluxo completo, do intake ao delivery

• IntakePergunta se é problema ou solução disfarçada.
• Dados geraisTraça o retrato inicial da demanda, com o PM.
• Kickoff 1Alinha expectativas antes de investigar.
• DiscoveryExecuta o plano e entende antes de agir.
• DefineTraduz entendimento em direção.
• Kickoff 2Abre o trabalho oficialmente.
• DevelopProduz e testa a solução.
• DeliveryEntrega e mede o resultado.

Todo requisito que pedia um artefato preenchível possui um template. Seis templates criados, cobrindo todas as etapas do fluxo.

Fig. 08: Central de templatesSeis peças, seis donos. O avatar em cada template é o designer responsável por ele.

• Kickoff: recepção de demandas. Capta e tria qualquer pedido antes de entrar na fila do design: reúne o problema (não a solução), quem pede, por que agora, e a matriz de certezas e riscos do primeiro Kickoff.
• Dossiê de Definição: registra a cadeia Fato → Insight → Oportunidade que fecha o Discovery, a prova por trás do Brief para quem entra no projeto depois.
• Brief: fecha em uma página a direção decidida: valor, público, escopo, prazo e aprovador nomeado. Autoriza a passagem do Define para o Kickoff 2.
• Critique: padrão único para critique de jornada, usado por Produto, Design, Engenharia, Dados e CS, jornada completa ou mudança pontual, convergindo para o mesmo fechamento.
• Cronograma (Trio Sync): dá visibilidade contínua de onde a demanda está agora, sem ninguém precisar perguntar. Documento vivo, atualizado sempre que a realidade muda.
• Roadmap do Quarter: decide com o PM a ordem e o corte do que será entregue, o elo entre a lista de oportunidades fechada e o Brief.

Ainda em validação. E isso está exposto, não escondido.

Diferente dos outros cases, aqui o impacto não é retrospectivo. É hipótese estruturada, com baseline levantado e coleta prevista.

A coleta de adoção real do MVP começa em Q4.

O que esse projeto ensina sobre puxar padronização sem impor de cima para baixo.

• Feedback vago é sintoma, não diagnóstico. Processo mal avaliado só virou problema acionável depois de decompor o que estava por trás daquela nota baixa
• Padrão não nasce de opinião, nasce de cruzamento. Teoria sozinha vira dogma. Benchmark sozinho vira cópia. Ouvir só o time sem contraponto externo perpetua o viés que já existe. Foi juntando as três lentes que a fronteira nebulosa entre Discovery e Define apareceu
• Distribuir a autoria aumenta a adesão. Cada template teve um designer dono, em vez de uma pessoa sozinha escrevendo regra para os outros seguirem
• Rastreabilidade é parte do produto, não só da pesquisa. Cada requisito citando sua fonte (autor, empresa ou dado do próprio time) tornou o guia auditável, em vez de uma lista de regras arbitrárias
• Nem todo impacto é imediato, e dá para dizer isso com honestidade. Documentar a hipótese em validação, em vez de esperar o resultado fechado para publicar, é coerente com o próprio princípio do projeto: decidir com o mínimo necessário, não com certeza total

Equipe envolvida

• Igor LimaCondução do projeto
• Anna MoreiraTemplate Brief
• Vanessa WavrikCronograma e Roadmap
• Caio RibeiroDossiê de Definição
• Jéssica LoureiroCritique
• Danielle PeredelskiPD Lead