Como Surgiu O Design Thinking

O que era antes do conceito existir

Antes de ter nome, a prática já acontecia em estúdios de arquitetura e escritórios de engenharia. As pessoas resolviam problemas observando o que funcionava e o que quebrava, sem chamar isso de metodologia. O termo design thinking só apareceu porque algum consultor precisava vender um pacote de workshops para grandes empresas que estavam tendo problemas para lançar produtos.

como surgiu o design thinking

A origem mais documentada remete a trabalhos na Stanford University no início dos anos 1950, quando designers começaram a discutir se era possível sistematizar o processo criativo. O conceito foi cunhado formalmente por Herbert Simon em seu livro "The Sciences of the Artificial" (1969), mas ficou praticamente sem circulação até os anos 1980 e 1990. O marco que transformou isso em algo commercializável foi a fundação da IDEO em 1991, quando a empresa se formou a partir da fusão de três escritórios de design. David Kelley, Tim Brown e outros começaram a empacotar o que já faziam — observar usuários, prototipar rápido, iterar — como um método replicável. A Stanford d.school chegou em 2005, consolidando o termo no universo corporativo.

Não é uma coisa linear. Houve influências paralelas de áreas como a engenharia industrial, a psicologia cognitiva e o movimento Bauhaus. Tudo convergiu depois. Na prática, o que as pessoas chamam de design thinking hoje é um conjunto de cinco fases que qualquer equipe pode seguir: empatia, definição, ideação, prototipagem e teste. Não é uma religião, é um fluxo. Funciona porque tira o problema do campo da intuição e coloca no campo da observação.

O problema é que a maioria dos times interpreta mal essas etapas. A fase de empatia vira uma pergunta rapidinha num formulário de dez linhas. A prototipagem vira um slide no Figma que ninguém vai testar com usuário real. A ideia é correta, a execução não. Eu já vi isso acontecer na prática há alguns anos, num projeto de redesign de um fluxo de onboarding para um app financeiro. A equipe passou duas semanas inteira mapeando perfis de usuário e entregou cinco personas detalhadas. Eu perguntei quantas delas tinham sido validadas com conversas reais. Silêncio. Eles tinham construído os perfis com base no que o produto já sabia sobre os clientes, não em observação direta. O resultado? O redesign foi reprovado nos testes com usuários porque resolvia um problema que não existia.

A correção foi simples e chata: paramos tudo, fizemos entrevistas semitruturadas com doze usuários reais, gravamos as sessões e dejamos a equipe assistir. Depois de ver uma pessoa frustrada tentando entender uma tela que o time achava "óbvia", a direção do projeto mudou completamente. Levou três dias a mais no cronograma, mas evitou meses de retrabalho. Um insight que poucos aprendem cedo é que a fase de definição é onde o projeto ganha ou perde direção, não a fase de ideação. A maioria das pessoas quer pular direto para soluções porque é mais divertido criar. Mas se o problema está mal definido, ideias boas resolvem a coisa errada. A fase de definição serve para transformar uma dor abstrata do usuário numa pergunta acionável. Algo como "como podemos reduzir o tempo para o usuário realizar a primeira transferência do app para menos de dois minutos?" é diferente de "queremos melhorar a experiência". Uma você consegue testar. A outra não.

Outra coisa que começa a dar problema em escala: design thinking exige tolerância a ambiguidade. Isso é difícil para equipes que operam sob KPIs estritos e prazos apertados. Quando a pressão por entrega é alta, o processo colapsa para uma forma acelerada e rasa. Você ainda chama de design thinking, mas na prática está fazendo uma sprint de ideias sem validação. Isso acontece com frequência em consultorias grandes, onde o cliente quer ver resultado rápido e não quer esperar duas semanas de imersão. Em projetos altamente técnicos ou regulados, o método também sofre. Se você está desenvolvendo software para o setor financeiro com compliance rigoroso, nem toda ideia passa por uma fase livre de ideação. Existem barreiras regulatórias que não cedem. Nesse cenário, o que funciona melhor é adaptar o pensamento — usar a empatia e a testagem com protótipos de baixa fidelidade, mas accepting que a fase de implementação será muito mais estruturada e com checkpoints obrigatórios.

Se o seu time não tem experiência prévia com o método, comece pequeno. Não tente aplicar as cinco fases num projeto inteiro de primeira. Pegue um problema específico e limitado, faça uma rodada de entrevistas com cinco usuários, monte um protótipo de papel e teste. Se der certo, repita. Se não der, analise onde o processo travou e ajuste. O design thinking não é um certificado que você obtém e nunca mais precisa consultar. É uma disciplina que melhora com uso, mas exige honestidade sobre o que está funcionando e o que não está.