Henrique Reis
8 de agosto de 202624 min

Design thinking process: etapas, ferramentas e limites do processo

Entenda como investigar, definir, idear, prototipar e testar sem transformar design thinking em uma sequência rígida ou promessa de inovação.
Nota de estudoDesign thinkingPesquisa com usuáriosPrototipagem
Fluxo iterativo entre investigação, definição, ideação, prototipagem e teste

Revisado em 8 de agosto de 2026.

Uma equipe reserva uma tarde, distribui post-its e termina com dezenas de ideias. Na manhã seguinte, as restrições continuam iguais, ninguém conversou com as pessoas afetadas e não existe responsável por transformar uma proposta em mudança real. Houve atividade. Não necessariamente houve design thinking. O processo de design thinking oferece modos de investigar experiências humanas, formular interpretações, tornar ideias concretas e aprender com o contato entre protótipo e realidade. Seu valor não está no ritual nem na quantidade de ferramentas usadas. Depende da qualidade da pesquisa, da diversidade de perspectivas, do entendimento das restrições e da capacidade de implementar o que foi aprendido.
Resumo

O que orienta este guia

  • Empatizar, definir, idear, prototipar e testar formam um modelo didático conhecido, não uma sequência universal.
  • Empatia não substitui pesquisa: entrevistas e observação precisam de recrutamento, registro, análise e limites.
  • Cada etapa deve produzir evidência ou uma decisão revisável, não apenas uma parede de artefatos.
  • Protótipo serve para responder uma pergunta com o menor nível de fidelidade suficiente.
  • Teste não comprova sucesso de mercado; revela problemas e reduz incertezas delimitadas.
  • Problemas estruturais, regulados ou de alta consequência exigem participação, conhecimento especializado e outras abordagens além de workshops.
Design thinking reúne práticas e modos de raciocínio associados ao trabalho de design: investigar situações, reformular problemas, explorar alternativas, materializar hipóteses e aprender por iteração. A expressão também passou a nomear programas de ensino, consultorias e métodos organizacionais. Esses usos não são idênticos. Não existe um ponto único de origem. Pesquisas sobre métodos de projeto, cognição de designers, arquitetura, engenharia e gestão contribuíram para debates diferentes ao longo de décadas. IDEO e Stanford d.school ajudaram a popularizar versões ensináveis, mas a própria IDEO afirma que não inventou o design thinking. Essa história importa porque evita duas simplificações. A primeira é atribuir toda a abordagem a uma empresa ou escola. A segunda é tratar uma versão corporativa recente como descrição completa das práticas de design. Lucy Kimbell, em Rethinking Design Thinking: Part I, distingue diferentes discursos sobre design thinking e critica generalizações que apagam a diversidade histórica e situada do trabalho de designers. Neste guia, design thinking é uma abordagem de investigação e aprendizagem por construção. Ele ajuda a tornar hipóteses discutíveis. Não garante inovação, consenso ou impacto. O Design Thinking Bootleg da Stanford d.school organiza ferramentas em cinco “modos”: Empathize, Define, Ideate, Prototype e Test. O material orienta começar onde fizer sentido e trata o conjunto como algo em evolução. A IDEO apresenta atualmente sete fases — enquadrar a questão, buscar inspiração, sintetizar para agir, gerar ideias, tornar ideias tangíveis, testar para aprender e compartilhar a história — e descreve um ritmo repetido de criar e fazer escolhas. Em outra síntese institucional, fala de inspiração, síntese, ideação/experimentação e implementação entrelaçadas. As diferenças de nome e quantidade não são um problema a ser resolvido escolhendo “o modelo correto”. Elas mostram recortes pedagógicos. Para facilitar a leitura, este artigo usa os cinco modos conhecidos e trata implementação, comunicação e medição como trabalho transversal que não pode desaparecer depois do teste.
Fluxo iterativo do processo de design thinkingInvestigar alimenta a definição; definir orienta ideação; ideias viram protótipos; testes podem devolver a equipe à investigação, à definição, à ideação ou à prototipagem.InvestigarDefinirIdearPrototiparTestar
Investigar alimenta a definição; definir orienta ideação; ideias viram protótipos; testes podem devolver a equipe à investigação, à definição, à ideação ou à prototipagem.
O diagrama mostra retornos, mas ainda é uma simplificação. Em um projeto real, pesquisa técnica pode acontecer junto da pesquisa com usuários; restrições podem interromper uma ideia; implementação pode produzir novas evidências; uma decisão pode encerrar o projeto.
Referência

O que cada modo precisa esclarecer

Métodos são exemplos. A escolha depende da pergunta, das pessoas afetadas, do risco e dos recursos disponíveis.

O primeiro movimento procura entender experiências, objetivos, comportamentos, ambientes, exceções e relações de poder. “Empatizar” é o nome popular, mas pode sugerir que boa intenção ou imaginação basta. Não basta. Entrevista ajuda a compreender acontecimentos, decisões, linguagem e interpretações. Pergunte por episódios concretos: “Conte sobre a última vez em que pediu reembolso”, não “Você usaria um aplicativo melhor?”. Relatos continuam sendo relatos; combine-os com outras evidências quando comportamento, frequência ou consequência importarem. Observar revela adaptações, interrupções e artefatos que podem não aparecer na memória ou no discurso. Isso exige consentimento, cuidado com privacidade e contexto. A presença de quem pesquisa também pode alterar a situação. Mapa de jornada organiza etapas, ações, dúvidas, canais e obstáculos ao longo de uma experiência. Ele é uma síntese baseada em pesquisa, não uma história decorativa sobre um “usuário médio”. Marque lacunas e diferenças entre grupos. Evidência esperada: notas rastreáveis, padrões provisórios, casos que contradizem o padrão e perguntas ainda abertas. Erro comum: entrevistar colegas convenientes e chamar o conjunto de “voz do usuário”. Recrutamento determina quais experiências podem aparecer. Definir não significa descobrir a frase perfeita escondida nos dados. Significa interpretar evidências, escolher um recorte e declarar o que a equipe acredita que merece ser enfrentado. Uma formulação útil identifica pessoas e contexto, necessidade ou resultado desejado, evidências disponíveis, restrições e sinais que permitiriam avaliar uma mudança. Ela não deve embutir a solução: “funcionários precisam de um chatbot” fecha alternativas; “funcionários não conseguem saber o estado do reembolso sem interromper o financeiro” descreve uma dificuldade observável. Perguntas “como poderíamos” abrem exploração sem apagar o recorte. “Como poderíamos permitir que a pessoa acompanhe o pedido sem exigir resposta manual do financeiro?” é mais produtiva do que “Como poderíamos digitalizar tudo?”. A pergunta ainda é uma hipótese e pode mudar. Evidência esperada: definição do problema, pressupostos, critérios, restrições e limites de escopo. Erro comum: agrupar post-its até chegar à interpretação que a liderança já defendia. Síntese precisa preservar divergências e mostrar de onde veio cada conclusão. Ideação procura evitar que a primeira solução plausível vire destino. Pode combinar produção individual silenciosa, compartilhamento, construção sobre ideias e busca por analogias. Brainstorming é uma técnica possível, não sinônimo do processo inteiro. Separe geração de avaliação por tempo suficiente para ampliar o conjunto. Depois, priorize com critérios visíveis: relevância para a necessidade, capacidade de testar, risco, viabilidade, dependências e consequências indesejadas. Evidência esperada: conceitos diferentes, hipóteses por conceito, critérios de escolha e razões para arquivar alternativas. Erro comum: votação por adesivos sem discutir poder, conhecimento ou viabilidade. Uma ideia popular pode apenas ser mais fácil de explicar. Protótipo torna uma hipótese concreta o suficiente para observar. Pode ser conversa encenada, roteiro, formulário em papel, sequência de mensagens, serviço simulado ou interface clicável. A fidelidade correta é a menor capaz de responder à pergunta. Para avaliar se as pessoas entendem a ordem de um fluxo, um esboço pode bastar. Para avaliar tempo de carregamento, integração ou acessibilidade com tecnologia assistiva, será necessário algo funcional. Evidência esperada: artefato, hipótese, tarefa e critérios de observação. Erro comum: usar acabamento para conquistar aprovação antes de testar estrutura. Quanto mais final parece, maior a tendência de discutir cor e detalhes — e maior o custo emocional de abandonar a ideia. Teste apresenta tarefas e observa como pessoas interpretam e usam o protótipo. O objetivo não é ensinar a interface nem defender o conceito. Prepare cenário, tarefa, roteiro, registro, consentimento e critérios de interrupção. Evite perguntas que pedem elogio ou previsão: “Você gostou?” e “Você usaria?” produzem sinais fracos. Observe o que a pessoa tenta fazer, onde hesita, que informação procura e como explica sua expectativa. Perguntas posteriores ajudam a compreender o comportamento sem substituí-lo. Evidência esperada: execução de tarefas, erros, estratégias, comentários contextualizados, gravidade e novas hipóteses. Erro comum: cinco pessoas não encontrarem um botão e a equipe concluir que “80% do mercado rejeitou a proposta”. Teste qualitativo identifica problemas no recorte estudado; não estima automaticamente prevalência populacional ou demanda comercial. Pesquisa com usuários investiga experiências, necessidades, comportamento e contexto. Pode orientar o que merece ser projetado e revelar como uma proposta é compreendida. Brainstorming gera possibilidades. Ele não produz evidência sobre usuários por si só e não corrige um problema mal enquadrado. Validação de mercado investiga se existe demanda suficiente sob condições reais de oferta, preço, canal e competição. Entrevista pode revelar linguagem e problema; experimento de oferta, vendas, uso e retenção responde perguntas comerciais diferentes. Uma solução pode ser desejável para participantes e inviável tecnicamente. Pode funcionar em teste e falhar na operação. Pode resolver uma tarefa e não sustentar aquisição ou receita. A IDEO organiza essa tensão entre desejabilidade, viabilidade e factibilidade; nenhuma oficina substitui a investigação de cada dimensão. Uma empresa com 45 pessoas recebe pedidos de reembolso por e-mail. Funcionários perguntam repetidamente sobre documentos e status; o financeiro mantém uma planilha paralela. O objetivo inicial não é “criar um app”. É reduzir incerteza e retrabalho sem enfraquecer controles.
Exemplo

Das primeiras entrevistas à decisão de implementação

1. Investigação. A equipe entrevista seis funcionários que solicitaram reembolso recentemente, duas pessoas do financeiro e uma liderança que aprova despesas. Também observa o processamento de três pedidos, com autorização e dados sensíveis removidos do registro.O que aparece. A suposição inicial era que o formulário tinha campos demais. As evidências mostram outra coisa: pessoas não sabem quais comprovantes servem, quando a liderança aprovou e por que um pedido voltou. O financeiro perde tempo reconstruindo contexto espalhado em e-mails.2. Definição. A equipe formula: “Quem solicita uma despesa precisa saber requisitos, estado e próxima ação sem depender de uma resposta individual do financeiro”. Mantém como restrições autorização, proteção de dados, integração limitada e prazo de implantação.3. Ideação. Surgem guia estático, modelo de e-mail, formulário com validação, página de acompanhamento e integração completa. A equipe não escolhe a opção mais abrangente. Seleciona um fluxo simples com orientações contextuais e status porque ataca as incertezas observadas e pode ser testado sem integração final.4. Primeiro protótipo. Um protótipo em papel apresenta requisitos antes do envio e três estados depois. No teste, quatro participantes entendem o envio, mas dois interpretam “em análise” como aprovação da liderança. A equipe volta à definição dos estados.5. Segunda versão. Os estados passam a representar eventos verificáveis: “enviado”, “aguardando aprovação”, “em conferência financeira”, “pago” e “devolvido para correção”. O teste revela que o comprovante recusado ainda não explica a próxima ação. É adicionada uma mensagem específica, não outro status.6. Decisão. A equipe implementa o fluxo mínimo e registra métricas operacionais: pedidos incompletos, contatos manuais por pedido, tempo entre etapas e abandono. O projeto permanece sujeito a revisão depois do uso real.Limite do exemplo. Esse processo não prova que o fluxo funcionará em qualquer empresa. Não substitui requisitos fiscais, segurança, acessibilidade, integração ou política interna. Mostra como evidências mudam o recorte e o protótipo.
O caso evita o teatro de resolver saúde, desigualdade ou mobilidade urbana em uma tarde. Problemas sociais complexos envolvem instituições, recursos, conflitos, história e pessoas que já atuam sobre eles. Ferramentas de design podem apoiar participação e experimentação; não conferem autoridade automática para definir o problema alheio. Ferramentas fáceis de ensinar podem ser separadas do conhecimento que lhes dá rigor. Jornada sem pesquisa vira ficção; persona sem evidência vira estereótipo; protótipo sem pergunta vira apresentação; workshop sem implementação vira evento. Quem formula perguntas, recruta participantes, agrupa achados e conduz priorização influencia o resultado. Facilitação não é neutralidade. Registre decisões, preserve interpretações divergentes e deixe claro quem possui poder para aprovar, financiar ou interromper. Participantes fáceis de acessar tendem a reproduzir a rede da equipe. Pessoas com deficiência, baixa conectividade, pouco tempo, outro idioma ou relação crítica com a instituição podem ficar de fora. Isso não é resolvido com uma persona “diversa” criada na sala. Ouvir pessoas sem dividir decisões pode transformar participação em extração de histórias. Os princípios da Design Justice Network propõem centrar quem é diretamente afetado, reconhecer experiência vivida e tratar o designer como facilitador em vez de especialista soberano. Nem todo projeto alcançará controle comunitário, mas toda equipe pode perguntar quem define o problema, quem assume riscos, quem recebe benefícios, quem é remunerado pela participação e quem pode contestar a interpretação. Desejabilidade não paga dívida técnica, não cria capacidade de atendimento nem resolve exigência regulatória. Engenharia, operação, jurídico, finanças, conteúdo e suporte devem participar cedo quando suas restrições definem o que pode existir. Um incidente de segurança pede resposta e investigação próprias. Uma consulta SQL lenta pede diagnóstico técnico. Uma decisão de preço exige evidência comercial. Uma política pública exige governança, participação e análise institucional além de protótipos de interface.
  • o problema ainda está mal compreendido;
  • comportamento e experiência humana influenciam o resultado;
  • existem interpretações concorrentes que podem ser investigadas;
  • é possível prototipar uma hipótese com risco controlado;
  • a organização consegue implementar e acompanhar aprendizados.
  • já existe pesquisa confiável e repetir descoberta seria desperdício;
  • o risco exige revisão ética, segurança, acessibilidade ou conhecimento especializado;
  • participação precisa acontecer ao longo do processo, não em entrevistas pontuais;
  • a solução depende de mudanças operacionais e não apenas de interface;
  • prazo e equipe pedem reduzir métodos sem abandonar perguntas essenciais.
  • a causa já é conhecida e o trabalho principal é execução;
  • há defeito técnico reproduzível que pede depuração;
  • a questão exige pesquisa quantitativa, experimento causal ou estimativa de mercado;
  • o domínio possui procedimento obrigatório de segurança ou conformidade;
  • o problema é sistêmico e pede análise de incentivos, políticas, infraestrutura e poder.
Design thinking pode conviver com discovery de produto, pesquisa científica, Lean, métodos ágeis, design participativo, análise de sistemas e engenharia. A pergunta não é qual rótulo vence, mas que incerteza e responsabilidade cada abordagem consegue enfrentar. Escreva qual decisão o trabalho precisa informar, quem será afetado e o que não pode dar errado. Reúna dados e pesquisas já existentes antes de recrutar. Converse e observe pessoas compatíveis com o contexto. Inclua casos centrais e divergentes. Registre consentimento, critérios de recrutamento e limites da amostra. Relacione cada padrão a notas ou evidências. Separe observação, interpretação e hipótese. Formule um recorte que não contenha a solução. Produza opções individualmente antes da discussão coletiva. Compare-as por necessidade, risco, viabilidade e potencial de aprendizagem. Escolha fidelidade pela pergunta. Defina tarefa, comportamento esperado e sinal que faria a equipe revisar a ideia. Registre o que ocorreu, gravidade e divergências. Decida avançar, alterar, pesquisar de novo ou parar. Nomeie responsável, dependências e como o resultado será acompanhado após implementação.
Ação

Antes de encontrar participantes

  • A decisão que a pesquisa ou o teste deve informar está escrita.
  • Observações, interpretações e hipóteses serão registradas separadamente.
  • O recrutamento corresponde às pessoas e situações afetadas, incluindo casos divergentes.
  • Participantes receberão contexto, consentimento e tratamento adequado de dados.
  • A equipe definiu remuneração ou outra forma justa de reconhecer a participação quando aplicável.
  • O roteiro evita perguntas que induzem elogio, concordância ou previsão abstrata.
  • O protótipo possui fidelidade suficiente para a pergunta — e não mais que isso.
  • Tarefas, critérios de observação e condições de interrupção estão preparados.
  • Pessoas com poder de decisão e implementação sabem como usarão a evidência.
  • Existe espaço para registrar achados que contradizem a hipótese ou o escopo inicial.
  • A equipe sabe que teste qualitativo não estima automaticamente tamanho de mercado.
  • Próximas decisões, responsáveis e limites serão comunicados depois da análise.
As etapas do design thinking são úteis porque dão linguagem a movimentos que equipes precisam coordenar: investigar, interpretar, divergir, tornar concreto e aprender. Tornam-se frágeis quando viram teatro de participação ou roteiro que sempre termina na ideia preferida. O critério não é quantos métodos foram usados. É possível rastrear a decisão até a evidência? Pessoas afetadas tiveram participação compatível com o impacto? Restrições foram incorporadas? O protótipo respondeu uma pergunta? A organização consegue implementar, medir e revisar? Para ampliar a base conceitual, leia o que é design. Para comunicar um processo sem transformá-lo em cronologia artificial, continue em como escrever um estudo de caso de UX. Se o foco é composição, consulte princípios do design visual.
Próximos passos

Comece por uma decisão real

  • Escolha uma dúvida que bloqueia uma decisão atual.
  • Liste evidências existentes e lacunas.
  • Selecione um método proporcional ao risco.
  • Prototipe apenas o necessário para aprender.
  • Registre o que faria a equipe mudar de direção.
Próximas leituras

Continue por assuntos próximos.