Design thinking, passo a passo, e onde ele dá errado

Design thinking é uma forma de resolver problemas que começa pelas pessoas que os têm. Na prática, ele segue cinco etapas: entender as pessoas, definir o problema, gerar ideias, fazer um protótipo rústico e testá-lo com usuários reais, voltando atrás sempre que o teste ensinar algo. As etapas são simples; as equipes erram em lugares previsíveis, e este artigo mostra onde e como evitar cada um deles.

A versão em cinco etapas é a ensinada pela d.school de Stanford (empatizar, definir, idear, prototipar, testar). O Double Diamond do Design Council do Reino Unido, criado em 2003 e divulgado publicamente a partir de 2004, descreve a mesma jornada em quatro fases: descobrir, definir, desenvolver, entregar. Use o vocabulário que sua organização já conhece. O que importa é a ordem das perguntas, não os nomes nos slides.

Se você ainda está decidindo se o design thinking é a abordagem certa, leia primeiro design thinking vs lean vs agile vs design sprint. Para o mapa mais amplo de ferramentas, veja qual ferramenta de inovação usar?.

Antes de começar: monte o desafio

O design thinking falha com mais frequência antes da primeira etapa. Resolva três coisas antes da primeira entrevista.

1. Um patrocinador que seja dono da decisão. Dê nome à pessoa que vai agir sobre o resultado. Se ninguém pode dizer sim ao resultado, o projeto produz um relatório.
2. Um briefing que nomeie uma área de problema, não uma solução. "Melhorar como os novos funcionários atravessam o primeiro mês" é um briefing. "Criar um app de onboarding" é uma solução disfarçada e encerra o projeto antes de ele abrir.
3. Uma equipe central pequena e diversa, com tempo protegido. Quatro a seis pessoas, incluindo alguém que entrega o serviço no dia a dia. Meio dia por semana durante seis semanas vale mais que uma imersão heroica de três dias que ninguém acompanha depois.

Etapa 1: Entender as pessoas (empatizar)

O que você faz. Vá até as pessoas que convivem com o problema. Faça entrevistas com stakeholders com oito a doze pessoas que cubram a variedade de usuários, não só os mais simpáticos. Acrescente observação contextual: observe a tarefa acontecendo onde ela acontece.

O que sai daí. Anotações com as palavras das próprias pessoas, fotos do ambiente real e um primeiro mapa de empatia para cada tipo principal de usuário.

Onde dá errado.

• A equipe entrevista colegas ou gestores sobre os usuários, em vez dos próprios usuários.
• As perguntas pedem que as pessoas prevejam o próprio comportamento futuro ("Você usaria…?"), algo que elas fazem mal.
• A pesquisa é terceirizada, e a equipe lê um resumo em vez de ouvir as pessoas diretamente. A mudança de pensamento acontece na sala, não no relatório.

Correção. Pergunte sobre a última vez que algo aconteceu ("Me conte da última vez que você…") e garanta que cada membro da equipe central participe de pelo menos duas entrevistas. Mais sobre isso em 5 erros de pesquisa que desperdiçam suas entrevistas.

Etapa 2: Definir o problema

O que você faz. Espalhe as descobertas e agrupe-as com um diagrama de afinidade. Procure tensões e surpresas, não só as reclamações frequentes. Escreva uma declaração de ponto de vista: um usuário específico, uma necessidade e um insight sobre por que ela importa. Transforme-a em duas ou três perguntas Como poderíamos.

O que sai daí. Uma declaração do problema acordada e um conjunto curto de perguntas "como poderíamos", aprovados pelo patrocinador.

Onde dá errado.

• A equipe pula esta etapa porque "já conhecemos o problema". Normalmente conhece o sintoma.
• A declaração é tão ampla ("Como poderíamos melhorar a experiência do cliente?") que qualquer ideia cabe nela, ou tão estreita ("Como poderíamos adicionar um chatbot?") que já traz a resposta escondida.
• O patrocinador não vê a declaração e depois rejeita as ideias porque tinha outro problema em mente.

Correção. Trate a aprovação da declaração do problema como um portão. Um guia completo está em sua declaração do problema é o projeto inteiro.

Etapa 3: Gerar ideias (idear)

O que você faz. Comece em silêncio. Use brainwriting ou Crazy 8s para que todos produzam ideias sozinhos antes de o grupo discutir. Busque quantidade primeiro. Depois agrupe, construa sobre as ideias uns dos outros e afunile com uma matriz de impacto e esforço ou uma ferramenta parecida.

O que sai daí. Duas ou três ideias que valem um protótipo, cada uma ligada à pergunta "como poderíamos" a que responde.

Onde dá errado.

• Discussão aberta desde o primeiro minuto, e a pessoa mais sênior ou mais barulhenta define a direção.
• A equipe se apaixona por uma ideia e para de gerar.
• As ideias são escolhidas por mãos levantadas, sem perguntar quais respondem melhor à declaração do problema.

Correção. Separe gerar de julgar, no tempo e nas regras. Para os argumentos contra o brainstorming aberto e o que usar no lugar, veja o brainstorming não funciona; veja o que funciona.

Etapa 4: Prototipar

O que você faz. Faça a coisa mais barata que permita a uma pessoa real reagir à ideia. Um protótipo em papel de uma tela ou formulário, um storyboard de um serviço, uma carta simulada, uma conversa de balcão encenada. Antes de construir, liste as premissas mais arriscadas com um mapa de premissas e garanta que o protótipo as teste.

O que sai daí. Um protótipo rústico por ideia, mais uma nota escrita do que você espera aprender com ele.

Onde dá errado.

• O protótipo é caprichado demais. As pessoas são educadas com coisas que parecem prontas e param de dar feedback honesto, e a equipe passa a relutar em jogar fora um trabalho que levou semanas.
• O protótipo testa a parte fácil (a aparência da tela) em vez da parte arriscada (se alguém traria os documentos certos).
• A TI ou um fornecedor é chamado para construir um piloto, e o projeto vira, sem alarde, uma implementação.

Correção. Defina um limite de um ou dois dias para um protótipo. Se levar mais, está detalhado demais.

Etapa 5: Testar e voltar

O que você faz. Coloque o protótipo diante de uns cinco usuários reais. Faça um teste de usabilidade moderado: dê uma tarefa, observe e fique quieto. Registre os resultados numa matriz de captura de feedback: o que funcionou, o que não funcionou, dúvidas levantadas, ideias novas.

O que sai daí. Uma decisão clara para cada ideia: refinar, descartar ou levar adiante para um piloto. Muitas vezes você também descobre que o problema foi enquadrado um pouco errado, o que o manda de volta à etapa 2.

Onde dá errado.

• A equipe explica o protótipo antes do teste e depois mede o quanto as pessoas entenderam a explicação.
• O teste é tratado como uma prova final a ser aprovada, e resultados negativos são justificados até sumirem.
• Depois do teste, não existe caminho para a entrega, e o protótipo fica numa gaveta.

Correção. Combine de antemão qual resultado faria vocês descartarem a ideia. E, antes de testar, combine com o patrocinador quem vai levar uma ideia bem-sucedida para a entrega e com qual linha de orçamento.

Um exemplo prático

Ilustrativo. A biblioteca de uma universidade numa cidade grande quer que mais estudantes usem seu serviço de apoio à pesquisa. O uso é baixo, e a chefe dos serviços da biblioteca supõe que o problema é falta de divulgação.

Entender. A equipe de cinco pessoas entrevista dez estudantes e observa o balcão de atendimento durante três tardes. Os estudantes sabem que o serviço existe. O que os trava é que o agendamento exige descrever o tema de pesquisa num formulário, e muitos sentem que o tema ainda não está "bom o bastante" para mostrar a um bibliotecário.

Definir. O ponto de vista fica assim: "Estudantes do primeiro ano da pós-graduação precisam de uma forma de baixo risco para pedir ajuda cedo, porque se sentem julgados quando a ideia de pesquisa ainda está nebulosa." A pergunta "como poderíamos": "Como poderíamos fazer pedir ajuda parecer normal antes de o tema estar claro?"

Idear. Uma rodada de brainwriting produz quarenta ideias. A matriz de impacto e esforço deixa três: plantões sem agendamento para "tema ainda nebuloso", um formulário de agendamento com um único campo opcional e bibliotecários visitando o primeiro seminário de cada programa.

Prototipar. Uma placa impressa para os plantões e uma versão em papel do formulário mais curto, ambas feitas numa manhã.

Testar. Em duas semanas, os plantões atraem um fluxo constante de estudantes, enquanto o formulário mais curto faz pouca diferença. A equipe descarta o formulário, mantém os plantões num piloto de um semestre e combina com a chefe dos serviços da biblioteca quais horas da equipe vão cobri-los.

A premissa original, de que os estudantes não conheciam o serviço, teria resultado numa campanha de cartazes. O processo produziu outra resposta.

O que fazer e o que evitar

Faça

• Tenha um patrocinador nomeado e um briefing sem solução antes da primeira etapa.
• Faça a equipe central ouvir os usuários diretamente.
• Obtenha a aprovação da declaração do problema antes da ideação.
• Prototipe em horas, não em semanas.
• Planeje o caminho para a entrega antes de testar.

Evite

• Não trate o design thinking como um workshop. Um único dia pode cobrir a ideação; o processo completo leva semanas.
• Não pule a etapa de definição para ganhar tempo. Ela custa mais tempo depois.
• Não dê acabamento aos protótipos nem os explique antes do teste.
• Não conduza o processo para justificar uma decisão já tomada. As pessoas percebem, e você as perde para o próximo projeto.
• Não pense nas etapas como estritamente lineares. Voltar atrás é o método funcionando.

Perguntas frequentes

Quais são as 5 etapas do design thinking? No modelo da d.school de Stanford: empatizar, definir, idear, prototipar e testar. O Double Diamond do Design Council agrupa o mesmo trabalho em quatro fases: descobrir, definir, desenvolver e entregar.

Quanto tempo leva um projeto de design thinking? Para um problema de serviço bem delimitado, conte com quatro a dez semanas de trabalho em meio período de uma equipe central pequena. Um design sprint pode comprimir as etapas finais em cinco dias, mas só quando o problema já está razoavelmente bem entendido.

Por que o design thinking falha nas organizações? Normalmente por motivos organizacionais, não de método: nenhum patrocinador dono do resultado, um briefing que já contém a solução, pesquisa pulada ou terceirizada e nenhum caminho de um protótipo testado até a entrega.

Para onde ir agora

Os guias de método de cada etapa: entrevistas com stakeholders para a etapa 1, declaração de ponto de vista e perguntas Como poderíamos para a etapa 2, brainwriting para a etapa 3 e protótipo em papel para as etapas 4 e 5. Para testar com mais profundidade, leia como testar uma ideia antes de construí-la.