O Design Thinking É Uma Abordagem Que Se Estrutura

Como o design thinking funciona na prática e por que a maioria erra

A maioria dos profissionais de produto e inovação ouve sobre design thinking e imediatamente pensa em post-its coloridos e sessões de brainstorming descontraídas. Isso é uma meia-verdade. O design thinking é uma abordagem que se estrutura em torno de iterações cíclicas de empatia, definição, ideação, prototipagem e teste, mas o cerne disso tudo não é o visual ou a estética do processo. É a forma como você lida com problemas mal definidos (os chamados "wicked problems") e a disposição de abandonar hipóteses caras cedo demais. Vou ser direto sobre o que isso significa na prática e onde as pessoas costumam falhar. A estrutura tem cinco fases, mas elas nunca são lineares. Você entra na fase de prototipagem, testa com usuários, descobre que a definição do problema estava errada, volta para a fase de empatia e reentrevista as pessoas. Isso não é um bug do método. É o método funcionando como deveria.

o design thinking é uma abordagem que se estrutura

Essa frase que aparece em muitos manuais resume parte do que é o design thinking, mas costuma ser mal interpretada. A palavra "estrutura" aqui não se refere a um flowchart rígido ou a um documento de requisitos bem escrito. Refere-se a uma arquitetura mental — um conjunto de pressupostos sobre como aprender algo novo sobre usuários e soluções de forma barata e rápida. O primeiro erro comum é tratar o design thinking como sinônimo de workshop. Workshops são eventos. Design thinking é uma disciplina de resolução de problemas. Um workshop pode ser parte do processo, mas se você faz um workshop de duas horas e depois volta para a rotina normal semitestar hipóteses com usuários reais, você não fez design thinking. Você fez uma reunião criativa. O segundo erro é mais sutil e custa caro. As pessoas aplicam as etapas em sequência, como se fossem um checklist. Eles fazem pesquisa de empatia, depois definem o problema, depois geram ideias, depois constroem protótipos e só então testam. Se o teste falhar — e ele vai falhar —, eles passam para o próximo projeto em vez de retroceder e refinar a definição do problema. Isso é um desperdício enorme de tempo e orçamento.

No meu trabalho com equipes de produto, eu já vi isso acontecer repetidamente. Tem um caso específico que ainda me incomoda: trabalhamos em uma plataforma de onboarding para usuários B2B. Passamos três semanas fazendo entrevistas de empatia, documentamos persona, journeys e mapas de dor. Definimos o problema como "o onboarding é muito longo". Geramos ideias, construímos um protótipo simples e fizemos testes com cinco usuários. Dois deles conseguiram completar o fluxo. Três desistiram no segundo passo. O que aconteceu? O problema não era o comprimento do onboarding. O problema era que os usuários não entendiam o valor da plataforma nos primeiros 30 segundos. Nós estávamos otimizando a velocidade de um funil que ninguém queria atravessar. A correção foi voltar para a fase de empatia, refazer as entrevistas com uma pergunta diferente — "o que te fez clicar neste link?" — e descobrir que o verdadeiro problema era o copy de entrada, não a interface. Em vez de cortar campos do formulário, reduzimos o texto explicativo inicial e colocamos uma demo interativa logo de cara. O fluxo de conversão dobrou em uma semana. O protótipo inicial tinha sido útil, apenas para nos mostrar que tínhamos identificado o problema errado. Esse é um exemplo clássico de por que o design thinking não é linear. A estrutura existe para te forçar a voltar atrás quando os dados mostram que sua suposição inicial estava errada. Se você não tem permissão institucional para voltar atrás — se seu gestor quer um cronograma fixo e entregas em datas determinadas —, o design thinking vai esbarrar nessa barreira. Neste caso, recomendo combinar o método com sprints curtas de duas semanas, onde cada sprint tem um teste real com usuário como critério de aceite, não como opcional.

As cinco fases explicadas sem romantismo

A fase de empatia é onde você coleta informações sobre o usuário real, não sobre o usuário que seu stakeholders imaginam que existe. O trabalho aqui envolve entrevistas qualitativas, observação contextual e, quando possível, análise de dados comportamentais. O detalhe que poucas pessoas levam a sério é que entrevista mal feita gera viés de confirmação. Se você já tem uma hipótese de qual é o problema, tende a fazer perguntas que levam o entrevistado a concordar com ela. Um truque simples que uso é fazer a pergunta "me conta como foi a última vez que você tentou resolver isso" antes de qualquer pergunta direcionada. Isso geralmente revela lacunas entre o que as pessoas dizem e o que elas realmente fazem. A fase de definição transforma padrões observados em insights acionáveis. Não é sobre resumir entrevistas. É sobre sintetizar observações contraditórias em uma declaração de problema clara. A declaração de problema mais útil que eu já vi tinha esta estrutura: "O usuário X precisa de Y porque Z", onde Z era baseado em comportamento observado, não em declarações dos próprios usuários. Os usuários raramente sabem dizer o porquê profundo das suas ações. Eles dão razões socialmente aceitáveis. O observador dá a razão real. A fase de ideação é muitas vezes confundida com brainstorming livre. Brainstorming sem restrições gera ideas genéricas que ninguém usa. O que funciona na prática é a restrição técnica ou orçamentária. Quando você define um limite claro — "precisamos resolver isso sem adicionar mais de três telas ao fluxo atual" —, a criatividade se concentra em soluções reais, não em ideias de departamento de marketing. Eu já vi equipes gerarem trinta ideias em uma sessão e none delas serem implementáveis dentro das restrições do produto. Com restrições claras, a mesma sessão gera três ideias viáveis e uma delas costuma ser testável em uma semana.

A prototipagem é a fase mais negligenciada e a mais importante. Protótipo não é produto. Protótipo é uma representação de baixa fidelidade feita para responder a uma pergunta específica. Se o seu protótipo leva mais tempo para construir do que o tempo que você economizaria evitando construir o produto errado, você está prototipando errado. Wireframes em Figma, protótipos cliques-em-html, até mesmo desenhos em papel valendo como protótipos são todos válidos. A fidelidade deve corresponder exatamente ao nível de incerteza que você quer reduzir naquele momento. A fase de teste não é uma validação final. É um novo ciclo de aprendizado. O resultado esperado de um teste bem feito não é "passou no teste". O resultado esperado é "sabemos agora que nossa premissa sobre X estava errada e precisamos ajustar Y". Se seu teste não te obriga a mudar alguma coisa, ele não foi bem feito.

Quando o design thinking não funciona

Existe um cenário em que o design thinking é efetivamente inútil: problemas com alta Clareza de Requisitos e Baixa Ambiguidade. Se o problema já está bem definido, se você sabe exatamente o que precisa construir e só precisa executar, usar design thinking é perder tempo. Métodos ágeis tradicionais, Kanban, ou simplesmente um bom backlog priorizado resolvem isso mais rápido. O design thinking também falha quando você não tem acesso real aos usuários. Há equipes que tentam aplicar o método usando dados secundários, pesquisas online genéricas ou feedback de clientes que já são viciados no produto. Isso é empatia de segunda mão. Ela é útil para gerar hipóteses, mas não substitui a observação direta. Eu já vi times passarem uma semana inteira em "pesquisa de empatia" usando respostas de um formulário NPS de 2022. Não tem como derivar insights verdadeiros de dados agregados de satisfação sem contexto. Outro ponto: o design thinking depende de cultura organizacional. Se sua empresa pune o fracasso e rewardea apenas o cumprimento de prazos, você vai ter equipes que seguem o processo no papel mas nunca vão realmente testar hipóteses arriscadas. O método exige tolerância a falhas pequenas e frequentes. Sem isso, você acaba com um processo vazio — reuniões marcadas, documentos bonitos, zero aprendizado real.

Como começar sem transformar tudo em um ritual caríssimo

Você não precisa de consultoria externa nem de certificação para aplicar design thinking. O mínimo funcional é: entrevistar três usuários reais sobre um problema específico, escrever uma declaração de problema baseada em observações, não em suposições, construir um protótipo que leve no máximo quatro horas para ficar pronto, e testá-lo com cinco usuários. Se você fizer isso duas vezes por mês durante um trimestre, já terá mais aprendizado do que a maioria das empresas produz em um ano inteiro de "inovação estratégica". O diferencial entre quem aplica design thinking corretamente e quem apenas copia a estética do método é a disposicao de ser brutalmente honesto com os dados, mesmo quando eles contradizem tudo o que a equipe achava que sabia. O método não te dá respostas. Ele te dá a ferramenta para matar suas próprias ideias favoritas mais cedo.