O que acontece quando você tenta aplicar o duplo diamante design thinking na prática
A primeira coisa que precisa entender é que o modelo não é linear. Muita gente desenha os dois diamantes no Miro e acha que já domina o método. Na minha experiência, pelo menos 60% dos projetos em que euo são equipes que já haviam feito uma leitura errada do framework e estavam usando apenas o segundo diamante, pulando a fase de descoberta por pressa do cliente ou deadline apertado. O duplo diamante design thinking foi criado pelo Design Council do Reino Unido em 2005, baseado em pesquisas com designers reais sobre como eles realmente trabalham. Os quatro fases são: Discover (descoberta), Define (definição), Develop (desenvolvimento) e Deliver (entrega). O primeiro diamante é sobre expandir e depoisir o problema. O segundo é sobre expandir eir a solução. A forma de diamante existe propositalmente porque o pensamento criativo não funciona em linha reta.
Como funciona o duplo diamante design thinking passo a passo
No Discover, você não tenta resolver nada ainda. Eu costumo recomendar rodar entre 8 a 12 entrevistas contextuais com usuários reais, gravando as sessões e fazendo anotacão em tempo real no Google Docs. O erro mais comum é começar a entrevistar sem um guia de discussão estruturado — e aí você gasta duas horas com o entrevistado só conversando casualmente sem coletar dados acionáveis. Prepare um roteiro com 5 a 7 perguntas abertas, mas esteja pronto para mudar de direção se algo interessante surgir no caminho. A convergência do primeiro diamante acontece na fase Define. Aqui é onde a maioria das equipes trava. Você precisa sintetizar todas as observações e transformar em insights acionáveis, não em opiniões. Uma técnica que funciona bem é o affinity diagram: imprimir todas as notas, colar na parede e agrupar por temas emergentes. Eu já perdi um dia inteiro com essa atividade porque minha equipe queria votar em vez de deixar os padrões emergirem dos dados. Resista à tentação de votar. Deixe os dados falarem.
O segundo diamante começa no Develop, onde você gera soluções em grande quantidade. Brainstorming estruturado, sketching, prototipagem rápida — tudo conta. O segredo aqui é volume antes de qualidade. Eu vejo muita gente pulando direto para a solução perfeita em vez de explorar 20 ideias ruins. A regra prática: produza pelo menos 20 ideias antes de escolher uma para prototipar. Isso parece exagero até você tentar e ver que as primeiras 10 ideias são sempre as mais óbvias e gastas. A entrega final, no Deliver, não é só entregar o produto. Envolve testar com usuários, coletar feedback, iterar. Protótipos de baixa fidelidade funcionam melhor do que você imagina — um papel e caneta já validam 80% dos problemas de usabilidade antes de qualquer código ser escrito. Testes com 5 usuários já revelam a maioria dos problemas críticos segundo a literatura de UX, então não precisa de 20 participantes para ter clareza suficiente para prosseguir.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Um problema específico que eu enfrentei recentemente envolveu um projeto de redesign de um app de saúde para pacientes crônicos. A equipe tinha feito a descoberta superficialmente — apenas 4 entrevistas ao invés das 12 recomendadas — e já estava no desenvolvimento quando percebi que o problema raiz era completamente diferente do que haviam definido. A solução? Parar tudo, voltar para o primeiro diamante, e refazer as entrevistas com um foco mais apurado em jornadas de uso real, não apenas intenções declaradas. Levou três dias adicionais, mas salvou o projeto de meses de retrabalho.
Limitações que ninguém conta
O duplo diamante design thinking tem desvantagens sérias que raramente são discutidas em cursos introdutórios. Primeiro, ele assume um ciclo de projeto longo — normalmente semanas ou meses. Em ambientes ágeis com sprints de duas semanas, o modelo inteiro não cabe. Nesses casos, você precisa adaptar, usando apenas fragmentos do framework por sprint, o que exige disciplina extra para não perder a visão do todo. Segundo, o modelo é centrado no usuário, o que é ótimo, mas pode ignorar constraints de negócio importantes. Eu já vi projetos paralisados porque a equipe de design descobriu um problema de usabilidade crítico que, ao ser comunicado, encontrou resistência absoluta da gestão porque exigiria refatoração completa de uma feature que já estava vendida para clientes. O framework não ensina a negociar isso.
Terceiro, a fase de Define é onde mais projetos falham. Sem uma definição clara e validada do problema, todo o trabalho no segundo diamante é direcionado para a solução errada. A métrica que eu uso é simples: se você não consegue escrever uma frase de problema que qualquer pessoa no time consiga repetir de cor e sem hesitação, você não terminou a fase Define ainda. Repita até conseguir. Para projetos muito pequenos ou com escopo restrito, eu recomendo considerar abordagens mais leves como o Design Sprint do Google Ventures, que condensa o processo em cinco dias com entregáveis concretos. O duplo diamante design thinking brilha em projetos de médio a grande porte onde o problema precisa ser bem compreendido antes de qualquer solução ser proposta. Fora disso, o custo-benefício pode não compensar.
O que separa uma aplicação competente de uma superficial é a honestidade com cada fase. Não adianta rushar a descoberta para chegar rápido ao desenvolvimento. Não adianta prototipar cedo demais sem antes definir o problema corretamente. Cada fase existe por uma razão específica, e pular etapas é a causa número um de projetos que entregam a solução certa para o problema errado.
