O que é Design Thinking?

Práticas de design centrado nas pessoas têm várias raízes; não há um inventor único do Design Thinking. A IDEO ajudou a difundir o termo e a aplicação em produtos, serviços e estratégia. Lideranças como David Kelley, Tim Brown e Jane Fulton Suri contribuíram para torná-lo conhecido. Tim Brown publicou um artigo de referência sobre Design Thinking em 2008.

A Stanford d.school popularizou um modelo didático com cinco modos: Empathize, Define, Ideate, Prototype e Test. Seu material os apresenta como ferramentas flexíveis, que podem ser retomadas em qualquer ordem. O modelo ajuda a ensinar a abordagem, mas não delimita todas as formas legítimas de praticá-la.

A abordagem começa por uma tensão: organizações precisam tomar decisões, mas raramente compreendem inteiramente o problema antes de trabalhar nele. Design Thinking cria espaço para investigar a experiência das pessoas, formular o desafio com cuidado, explorar opções e aprender com representações concretas. A pergunta deixa de ser apenas “como executar a solução pedida?” e passa a incluir “que necessidade real estamos tentando atender?”. Essa mudança pode evitar uma implementação elegante de algo irrelevante.

Pessoas no centro não significa obedecer a toda preferência declarada. Uma entrevista ajuda a entender objetivos, dificuldades e linguagem, mas o que alguém diz que faria pode diferir do que faz. Observe o contexto, tarefas reais e limitações. Inclua pessoas afetadas que normalmente não aparecem nas reuniões, como quem atende o serviço, quem precisa de acessibilidade ou quem lida com exceções. Uma amostra pequena pode revelar perguntas, não representar automaticamente a população.

Desejabilidade, viabilidade e possibilidade. A IDEO descreve três lentes: o que importa às pessoas, o que pode ser realizado tecnicamente e o que pode se sustentar para a organização. Uma ideia desejável pode falhar por inviabilidade econômica; uma solução lucrativa para a empresa pode ser inútil ou prejudicial ao usuário; um protótipo tecnicamente simples pode não resolver o problema. O equilíbrio não nasce de um slide com três círculos, mas de investigação concreta das restrições e consequências.

Empatizar e definir. Na linguagem da d.school, empatizar envolve aprender com pessoas em seu ambiente, ouvindo e observando sem antecipar a solução. Definir exige sintetizar o que foi encontrado em um problema específico, com público e contexto. “Precisamos de um aplicativo” é proposta de solução; “pessoas que precisam alterar um agendamento não sabem se perderão a vaga atual” aponta uma situação para explorar. O enunciado pode mudar quando novas evidências surgirem.

Idear. Com o problema formulado, o grupo busca mais de uma maneira de responder. Esboços individuais antes da discussão podem reduzir o efeito da opinião dominante. Alternativas podem envolver interface, comunicação, mudança de processo ou até retirar uma etapa do serviço. Ideação não é competição para produzir centenas de post-its. Seu valor está em revelar opções que possam ser comparadas segundo a necessidade, a viabilidade e as restrições.

Prototipar. Um protótipo é uma representação construída para aprender, não uma versão quase final por obrigação. Pode ser um desenho em papel, uma conversa encenada, um fluxo clicável, um rascunho de política ou parte executável do sistema. Escolha a fidelidade conforme a dúvida. Se quer saber se alguém entende um texto, uma versão simples basta; se quer medir desempenho técnico, a simulação visual não responde. Declare quais elementos são reais e quais foram encenados.

Testar e iterar. Em vez de apresentar uma ideia e pedir aprovação, ofereça uma tarefa realista e observe o que a pessoa compreende, tenta, ignora ou não consegue fazer. Pergunte o motivo sem sugerir a resposta. Sintetize padrões e divergências, refine o enunciado do problema e volte a modos anteriores quando necessário. O ciclo não termina quando a pessoa diz que gostou. Aprendizado inclui evidência contrária e a decisão de abandonar uma solução.

Os cinco modos da d.school não são estágios com portões obrigatórios. Um teste pode mostrar que a definição do problema estava errada. Uma restrição técnica pode pedir uma nova rodada de pesquisa. A equipe pode começar com um protótipo existente e usá-lo para aprender com usuários. O importante é preservar a ligação entre problema, alternativa, evidência e decisão.

Design Thinking não substitui Product Discovery, que é o trabalho contínuo de reduzir incertezas de produto; pode fornecer métodos para esse trabalho. Um Design Sprint concentra algumas atividades num período curto. O Double Diamond oferece outro mapa para alternar exploração e escolha. Esses conceitos se aproximam, mas nenhum é sinônimo perfeito do outro.

Como escolher participantes. Envolva pessoas que conhecem usuários, operação, tecnologia e resultado de negócio. Nenhuma função tem monopólio da criatividade. Também convide pessoas com poder de decisão para que o aprendizado não morra ao final da oficina. Participação ampla não implica que todas devam assistir a cada entrevista ou desenhar cada tela. Distribua o trabalho conforme expertise e mantenha a síntese compartilhada.

O que medir. Antes de testar, anote o que deseja aprender e que observação alteraria a decisão. Para uma tarefa de navegação, conte dificuldades e erros observados e descreva onde ocorreram. Para impacto em conversão, é preciso evidência quantitativa adequada depois, possivelmente com experimento em produto real. Uma sessão qualitativa não mede retenção futura, assim como um painel de cliques não explica sozinho o motivo de uma dificuldade.

Ética e acesso. Pesquisa com pessoas exige respeito ao tempo, consentimento e cuidado com dados. Prototipar um serviço também pode reproduzir exclusões, como linguagem incompreensível ou uma jornada inacessível. Inclua condições de uso diferentes e avalie quem fica de fora. A decisão de produto não deveria considerar apenas o segmento mais fácil de recrutar.

Diferencie evidência, interpretação e escolha. Uma pessoa não encontrou o botão no protótipo: isso é observação. “A hierarquia visual o escondeu” é hipótese explicativa. “Vamos aumentar o botão” é opção de solução. Se o time mistura essas três camadas, pode mudar a interface sem entender o motivo da dificuldade. Pergunte o que mais poderia explicar o comportamento: linguagem, expectativa anterior, distração, contexto de uso ou tarefa artificial. Registre a decisão e a evidência que a motivou para revisá-la depois.

Faça síntese sem apagar diferenças. Agrupar falas semelhantes ajuda a encontrar temas, mas pessoas com necessidades incompatíveis podem estar usando o mesmo serviço. Um usuário experiente quer velocidade; outro, orientação passo a passo. Forçar uma única persona média pode prejudicar ambos. Segmente situações de uso, avalie a importância de cada uma e examine custos de atender a diferentes caminhos. Quando uma exceção envolve acessibilidade ou segurança, baixa frequência não significa baixa prioridade.

Combine descoberta com entrega. Aprender com protótipos é útil antes de construir, mas a operação real traz perguntas que o teste não antecipou. Planeje como medir o comportamento depois do lançamento e quem ouvirá reclamações, dúvidas e efeitos inesperados. Uma solução que funciona numa sessão acompanhada pode falhar sem a ajuda do pesquisador, em conexão lenta ou diante de uma regra rara. A equipe deve manter canais de feedback e capacidade de corrigir.

Facilite conflitos produtivos. Pessoas de negócio, design, tecnologia e atendimento podem atribuir pesos diferentes aos mesmos dados. Isso não precisa virar disputa sobre quem conhece melhor o cliente. Explicite a restrição de cada perspectiva e escolha qual hipótese pode ser testada. Quando a decisão depende de valores, como privacidade ou inclusão, não a disfarce de questão puramente técnica. Registre quem decide e por quê.

A abordagem é útil tanto para uma equipe de software quanto para redesenhar atendimento, política interna ou serviço físico. O material muda, mas a lógica permanece: observar pessoas, formular a pergunta certa, experimentar possibilidades e rever a decisão. Sua força está em tornar hipóteses visíveis e baratas de testar antes de comprometer muito trabalho. Seu limite está em não dispensar operação, engenharia, economia nem acompanhamento após a entrega.

Produto digital. Imagine um aplicativo hipotético de transporte em que muitos usuários desistem após escolher o destino. A equipe acredita que precisa redesenhar o botão de pagamento. Em 8 conversas exploratórias e observações, percebe que 5 pessoas não entendem quando o preço final pode mudar. Esses números apenas ilustram o caso e não autorizam generalizar uma taxa. O problema muda de “botão pouco visível” para “incerteza sobre o custo da viagem”. O grupo esboça três formas de explicar a estimativa, prototipa duas e observa tarefas reais com pessoas do público. Antes, trabalharia semanas em um botão; depois, sabe qual informação precisa esclarecer e quais dúvidas ainda exigem teste em produção.

Serviço fora de TI. Imagine uma biblioteca de bairro em que as pessoas telefonam repetidamente para saber se um livro reservado já pode ser retirado. A primeira proposta é comprar um aplicativo. Observando o balcão e conversando com leitores, a equipe encontra um problema de comunicação: o aviso não informa prazo e local de retirada. Em vez de começar pela compra, testa uma mensagem em papel e por telefone com 12 reservas hipotéticas. A solução inicial é barata, mas precisa respeitar preferências e acesso de quem não usa celular. Antes, a biblioteca escolheria tecnologia; depois, investiga se uma comunicação clara resolve parte do problema.

Operação em escala. Imagine uma rede hipotética com 20 unidades que deseja reduzir dúvidas no primeiro atendimento. Entrevistar apenas gestores centrais produziria uma visão limitada. A equipe combina observações em unidades de perfis diferentes, reúne atendentes e clientes e identifica duas causas: instruções contraditórias e exceções que o sistema central não registra. Prototipa uma orientação revisada em duas unidades e acompanha perguntas recebidas. Antes de expandir, avalia diferenças locais, acessibilidade e treinamento necessário. Os números são apenas cenários de raciocínio, não dados de um cliente da K21.

Nos três contextos, o aprendizado pode mostrar que a hipótese de partida estava errada. Isso não significa que o processo falhou. Descobrir cedo que o botão, o aplicativo ou a instrução central não atacam a causa evita ampliar uma resposta inadequada. Também não significa que um teste curto prove a eficácia final. Depois do protótipo, a equipe ainda precisa construir, operar e acompanhar resultados reais.

Cursos K21 recomendados