O que é Design Thinking e como começar

Design Thinking é uma abordagem para resolver problema partindo de quem tem o problema, e não da solução que alguém já imaginou. Ela organiza o trabalho em cinco etapas, empatizar, definir, idear, prototipar e testar, mas essas etapas não são lineares: cada teste pode devolver o time para qualquer uma das anteriores.

Repare que chamei de abordagem, e não de metodologia. A escolha da palavra não é preciosismo.

Metodologia cria a expectativa de uma fórmula aritmética, que se aplica igual em qualquer contexto e devolve o mesmo tipo de resultado. Quando a expectativa é essa, a primeira vez que o teste contraria a ideia que todo mundo já tinha vira sinal de que "o processo não funcionou". E é exatamente o contrário: era o processo funcionando.

De onde vem a ideia de projetar como forma de pensar

A noção de design como forma de pensar é mais antiga que o termo da moda.

Aparece em 1969, nas ciências, com The Sciences of the Artificial, de Herbert A. Simon. Depois na engenharia, em 1973, com Experiences in Visual Thinking, de Robert McKim. Rolf Faste, professor de Stanford, definiu e popularizou "design thinking" como forma de ação criativa, e a adaptação para organizações passou por Stanford e pela IDEO, consultoria de design fundada por David Kelley, que também fundou a d.school de Stanford.

O momento em que isso virou assunto fora do meio de design tem data: 1999, quando o programa Nightline, da rede americana ABC, exibiu o episódio "The Deep Dive". A reportagem acompanhou uma equipe multidisciplinar da IDEO redesenhando um carrinho de supermercado em uma semana, com um modelo funcional em quatro dias.

Depois, em 2009, Tim Brown, então CEO da IDEO, publicou Change by Design, que no Brasil saiu como Design Thinking: Uma Metodologia Poderosa Para Decretar o Fim das Velhas Ideias. Vale registrar a ironia: o título brasileiro chama de metodologia justamente o que o livro trata como abordagem.

E uma observação prática antes de seguir: isso não é assunto de designer. O nome atrapalha. A equipe do carrinho de compras tinha engenheiro, psicólogo e designer, e é essa mistura que produz o resultado. Time formado só por uma especialidade tende a chegar em solução que aquela especialidade já sabia fazer.

As cinco etapas, e por que elas não são uma fila

A leitura mais comum, e a mais problemática, é tratar as cinco etapas como cinco passos em sequência. Elas alternam abrir e fechar o escopo, e é o fechamento que quase sempre é pulado.

Empatizar

O time mergulha no problema por várias perspectivas, tentando entender como aquilo aparece na vida de quem enfrenta. Não é levantar requisito, é entender contexto, cultura e o que a pessoa realmente tenta resolver.

Serve aqui qualquer coisa que traga informação de fora: entrevista, observação, pesquisa de mercado, benchmarking, análise de forças e fraquezas. O critério é sair do escritório.

Se você conhece o inimigo e conhece a si mesmo, não precisa temer o resultado de cem batalhas. Se você se conhece, mas não conhece o inimigo, para cada vitória ganha sofrerá também uma derrota.

Sun Tzu, A Arte da Guerra

A frase é sobre guerra e serve bem para produto. A maior parte das decisões ruins de escopo vem de conhecer bem a própria capacidade e mal o problema de quem vai usar.

Definir

Esta etapa gera menos entusiasmo e é onde o processo se ganha ou se perde.

A imersão produz muito material, e agora é preciso escolher um problema. Não os cinco que apareceram, um. Organizar o material, achar padrão, representar visualmente, e sair com um enunciado claro do que se pretende resolver.

Time que pula essa etapa chega na fase de ideias com trinta alternativas para problemas diferentes, e nenhuma delas conversa com as outras.

Idear

Agora abre de novo. Brainstorming, e o objetivo é quantidade e variedade antes de qualidade.

Aqui existe uma condição que não é sobre técnica: as pessoas precisam poder errar em voz alta. Medo de crítica inibe a ideia menos óbvia, que é justamente a que vale. Vale o mesmo que escrevi sobre a Lean Inception: presença de quem avalia desempenho reduz o que a sala produz.

Prototipar

O protótipo existe para a pessoa entender e reagir, não para ser usado de verdade.

Essa distinção é importante e costuma se confundir com MVP. Protótipo não precisa funcionar. Pode ser papel, tela estática, encenação. Em software, é como construir só a interface: o comportamento real vem depois, se a ideia sobreviver.

MVP é outra coisa: é colocado em uso real justamente porque o dado que interessa é comportamento. Protótipo colhe reação, MVP colhe uso.

Testar

O público-alvo usa o protótipo e diz onde ele não resolve. Layout, fluxo, e principalmente se aquilo endereça o problema que foi definido lá atrás.

E aqui está a razão de a seta do diagrama voltar. O teste pode indicar que o protótipo está errado, que a ideia está errada, que o problema foi mal definido, ou que a imersão não entendeu o contexto. Os quatro resultados são úteis, e nenhum deles é fracasso do processo.

Onde isso costuma travar em organização grande

A parte técnica do Design Thinking é a mais fácil. As cinco etapas se explicam em uma hora.

O que trava é outra coisa. A abordagem pressupõe acesso a quem tem o problema, tempo para descobrir que a hipótese inicial estava errada, e disposição para mudar de direção depois de ter apresentado uma ideia internamente.

Na minha visão, é por isso que tanta iniciativa de inovação para no workshop. O workshop é confortável: gera post-it, engajamento e uma sensação boa de colaboração. A parte desconfortável é o que vem depois, quando o teste contraria a ideia que já tinha patrocinador.

Na sua organização, quando a pesquisa com usuário contraria a hipótese de quem pediu o projeto, o que costuma mudar: a hipótese ou a pesquisa?