Quase todo material sobre design thinking mostra o mesmo diagrama: cinco caixinhas, setas circulares, a palavra “empatia” em destaque. O que quase nenhum mostra é um projeto de verdade, com empresa real, problema real e um resultado que alguém de fora avaliou.
Este post é um exemplo de design thinking nesse segundo formato. Um desafio da Bayer, cinco alunos de administração do Insper, mentoria da Northern, e a primeira vez que a abordagem foi usada no REP Insper. O projeto terminou como melhor do semestre.
O caso em uma olhada
| Contexto | REP Insper, disciplina obrigatória do sexto semestre de administração, em que os alunos aplicam o conhecimento da graduação a um problema real de uma grande organização, acompanhados por mentores. |
|---|---|
| Organização | Bayer |
| Desafio | Diagnosticar e entender os atritos existentes em uma das plataformas de treinamento da empresa. |
| Abordagem | Design thinking, usado pela primeira vez no REP Insper. |
| Papel da Northern | Mentoria do time ao longo do projeto. |
| Resultado | Melhor projeto do semestre. Premiação individual Green Belt ou Yellow Belt para todos os alunos, e os mentores entre os melhores do semestre. |
Uma ressalva de honestidade antes de seguir: os números internos da plataforma da Bayer não são públicos, e não vamos inventá-los aqui. O que este exemplo entrega é o caminho, etapa por etapa, e uma avaliação externa do resultado. É o que falta na maioria dos materiais sobre o tema.
As etapas do design thinking, percorridas no projeto
Design thinking é uma abordagem de resolução de problemas centrada em quem usa a solução. Na formulação mais difundida, ela tem cinco etapas. Vale ver o que cada uma significou neste projeto, em vez do que ela significa no diagrama.
1. Empatia: sair da sala e ir ver
O time não começou propondo melhorias na plataforma. Começou tentando entender o atrito de três formas complementares: entrevistas de empatia com os usuários, observação direta de pessoas usando a plataforma, e por fim percorrendo a jornada do usuário eles mesmos, de ponta a ponta.
As três coisas respondem perguntas diferentes. A entrevista revela o que o usuário diz que faz. A observação revela o que ele faz. Viver a jornada revela o que ninguém verbaliza porque já se acostumou. Um diagnóstico feito só com entrevista costuma parar no primeiro nível de explicação, e é aí que o método dos 5 porquês ajuda a furar do sintoma até a causa.
2. Definição: transformar observação em um problema formulado
De posse das observações, e junto com a alta gerência da Bayer, o time construiu as personas. Essa etapa é a que mais se pula na pressa, e é a que decide o resto: o mesmo conjunto de evidências permite formular problemas muito diferentes, e cada formulação abre um leque distinto de soluções.
Trazer a alta gerência para dentro dessa construção não foi detalhe de agenda. É o que faz a solução ter dono depois, quando o projeto acaba e alguém precisa decidir sobre orçamento.
3. Ideação: gerar muito antes de escolher
Com o problema formulado e as personas na mesa, veio a co-criação de possíveis soluções, também com a gerência da empresa. A regra desta etapa é a que mais desconforta quem vem de gestão tradicional: quantidade antes de qualidade, e nenhum julgamento durante a geração.
4. Prototipação: construir o suficiente para aprender
O resultado da co-criação foi prototipado. Protótipo aqui não é a solução em versão pequena: é o objeto mais barato que consegue provocar uma reação real de um usuário real. Essa distinção é a mesma que separa o que é um MVP de produto digital do que só parece um.
5. Teste: iterar até a solução que o usuário quer
O protótipo foi testado com os usuários, corrigido nos detalhes que os testes apontaram e submetido a novos testes, até chegar ao que o time chamou de solução WOW: aquela desejada por quem de fato vai usar.
Repare que as etapas não terminam numa entrega, terminam num ciclo. É a mesma lição da Marshmallow Challenge, em que os grupos que testam cedo e várias vezes vencem os que planejam uma única solução perfeita.
| Etapa | O que foi feito no projeto | O que costuma dar errado |
|---|---|---|
| Empatia | Entrevistas, observação e a jornada percorrida pelo próprio time | Só entrevista, e o time acredita na primeira explicação |
| Definição | Personas construídas com a alta gerência | Pular para a solução antes de formular o problema |
| Ideação | Co-criação com a empresa, sem julgar durante a geração | A primeira ideia do chefe fecha o leque |
| Prototipação | Protótipo do resultado da co-criação | Construir a solução inteira antes de mostrar a alguém |
| Teste | Teste, correção e novo teste, em ciclo | Testar uma vez e tratar o retorno como aprovação |
O duplo diamante: por que divergir antes de convergir
Existe uma forma de ler essas cinco etapas que explica melhor por que elas funcionam nessa ordem: o duplo diamante. São dois movimentos de abrir e fechar em sequência. No primeiro diamante, você abre o entendimento do problema e depois o fecha numa formulação. No segundo, abre o leque de soluções e depois o fecha numa escolha testada.
No projeto da Bayer, o primeiro momento de divergência foi exatamente a fase de campo: entrevistas, observação e jornada, sem nenhuma solução na mesa. A convergência veio com as personas e a formulação do problema. Só então o segundo diamante abriu, na ideação, e fechou no protótipo testado.
O erro mais comum na gestão tradicional é começar já no segundo diamante, com uma solução na cabeça, e usar a fase de campo para confirmá-la. O nome disso não é design thinking, é justificativa. Quando isso acontece, o projeto costuma entregar exatamente o que a liderança já tinha decidido antes de começar.
O que esse exemplo ensina para a sua empresa
O contexto era acadêmico, mas o desafio era corporativo e real. Cinco coisas se transferem direto.
- Atrito de plataforma raramente é problema de tela. O desafio da Bayer era uma plataforma de treinamento, e o diagnóstico exigiu entender o processo em volta dela. Redesenhar a interface sem isso troca a aparência do atrito de lugar.
- Quem vai usar precisa ser ouvido antes, não no aceite. Colher a opinião do usuário no fim do projeto não é pesquisa, é homologação. A diferença aparece no custo de mudar, que no fim é alto e no começo é quase zero.
- Formulação do problema é a decisão de maior alavancagem. É o que define o escopo, e escopo mal formulado é o que faz projeto digital estourar prazo. O raciocínio está detalhado em como definir o escopo do primeiro produto digital.
- Protótipo serve para aprender, não para impressionar. Confundir os dois é o que produz o entregável bonito que ninguém usa. Vale ler MVP não é site barato: o que valida uma ideia.
- A observação vira ativo se for registrada. Boa parte do que o time descobriu em campo é o tipo de informação que a empresa já tinha, dispersa, e não usava. É o mesmo padrão de por que as empresas não usam os dados que já têm.
Vale notar também de onde vem o valor econômico desse tipo de trabalho. Entender o atrito antes de construir é o que evita pagar duas vezes pelo mesmo software, e essa conta aparece com clareza em quanto custa desenvolver um produto digital. Empresas que institucionalizam esse hábito é o que se costuma chamar de transformação digital, quando o termo é usado com algum rigor. E abordagens centradas no usuário são também a raiz de boa parte da inovação disruptiva: a oferta que reorganiza um mercado quase sempre resolve um atrito que os incumbentes tratavam como normal.
Quando design thinking não é a ferramenta certa
Um exemplo honesto precisa dizer onde a abordagem não serve, senão vira propaganda.
Design thinking é forte quando o problema é mal definido e o usuário é a fonte da resposta. Ele é fraco, ou simplesmente caro demais, em três situações. Quando o problema já está bem definido e é de execução: aí o que resolve é método de entrega, como Scrum. Quando a resposta está em dado quantitativo que a empresa já possui, e o que falta é leitura, não campo. E quando a decisão é de estratégia de mercado, não de experiência, caso em que o recorte importa mais do que a empatia, como na beachhead strategy.
Há também uma armadilha de vocabulário. Workshop de post-it não é design thinking. Sem ida a campo, sem protótipo e sem teste com usuário, o que acontece é uma reunião mais colorida, com as mesmas premissas de sempre. As cinco etapas só valem alguma coisa quando as cinco acontecem. Se você está avaliando trazer alguém de fora para conduzir esse tipo de diagnóstico, os critérios estão em o que é consultoria de tecnologia e quando contratar.
Os créditos do projeto
O trabalho foi dos alunos. O projeto foi conduzido por Roberta Casarini, Lívia Araujo Costa, Manuella Maggi, Felipe Bacellar e Giovanni Farjoni, alunos de administração do REP Insper, com mentoria de Dani e Neto, da Northern, que também figuraram entre os melhores mentores do semestre.
Perfis dos alunos no LinkedIn: Roberta Casarini, Lívia Araujo Costa, Manuella Maggi, Felipe Bacellar e Giovanni Farjoni.
Perguntas frequentes
O que é design thinking?
Design thinking é uma abordagem de resolução de problemas centrada em quem usa a solução. Em vez de partir de uma ideia e buscar validação, ela parte da investigação do atrito real do usuário e só depois abre o leque de soluções. Na formulação mais difundida tem cinco etapas: empatia, definição, ideação, prototipação e teste, percorridas em ciclo e não em linha reta.
Quais são as etapas do design thinking?
São cinco. Empatia: ir a campo entender o atrito por entrevista, observação e vivência da jornada. Definição: transformar as observações num problema formulado, com personas. Ideação: gerar muitas soluções possíveis sem julgar durante a geração. Prototipação: construir o objeto mais barato capaz de provocar reação real. Teste: testar com usuários, corrigir e testar de novo, em ciclo.
Qual é um exemplo real de design thinking?
O projeto descrito neste post: um desafio da Bayer para diagnosticar os atritos de uma de suas plataformas de treinamento, conduzido por cinco alunos de administração do Insper com mentoria da Northern, na disciplina REP Insper. Foi a primeira vez que a abordagem foi usada naquele programa, e o projeto foi premiado como melhor do semestre.
O que é o duplo diamante no design thinking?
É a leitura das etapas como dois movimentos de abrir e fechar em sequência. No primeiro diamante você abre o entendimento do problema e depois o fecha numa formulação; no segundo, abre o leque de soluções e o fecha numa escolha testada. O erro mais comum é começar já no segundo diamante, com a solução decidida, e usar a fase de campo apenas para confirmá-la.
Workshop de post-it é design thinking?
Não. Sem ida a campo, sem protótipo e sem teste com usuário real, o que acontece é uma reunião mais colorida com as mesmas premissas de antes. As cinco etapas só valem alguma coisa quando as cinco acontecem. A dinâmica de sala é uma ferramenta da etapa de ideação, não a abordagem inteira.
Design thinking e Scrum são a mesma coisa?
Não, e resolvem problemas diferentes. Design thinking serve quando o problema é mal definido e o usuário é a fonte da resposta: ele ajuda a descobrir o que construir. Scrum é método de entrega, e serve quando o problema já está definido e o desafio é executar em ciclos. Os dois se combinam bem em sequência, mas um não substitui o outro.
Quando design thinking não é a ferramenta certa?
Em três situações. Quando o problema já está bem definido e o desafio é de execução, caso em que método de entrega resolve melhor. Quando a resposta está em dado quantitativo que a empresa já tem, e o que falta é leitura, não pesquisa de campo. E quando a decisão é de estratégia de mercado em vez de experiência, caso em que a escolha do recorte pesa mais do que a empatia.
Quem criou o design thinking?
A abordagem não tem um inventor único. Ela se consolidou a partir do trabalho da consultoria de design IDEO e da d.school de Stanford, e foi popularizada no meio corporativo principalmente por Tim Brown, da IDEO, em artigo na Harvard Business Review em 2008 e no livro Change by Design, de 2009. As raízes conceituais são anteriores, na literatura de design e de resolução de problemas.
Como fazer a etapa de empatia do design thinking?
Com três métodos complementares, porque cada um responde uma pergunta diferente. A entrevista revela o que o usuário diz que faz. A observação direta revela o que ele faz. E percorrer a jornada você mesmo, de ponta a ponta, revela o que ninguém verbaliza porque já se acostumou. No projeto da Bayer os três foram usados, e é essa combinação que evita o diagnóstico que para no primeiro nível de explicação.
Por que ouvir o usuário só no fim do projeto não funciona?
Porque colher a opinião do usuário no fim não é pesquisa, é homologação. A diferença aparece no custo de mudar: no começo é quase zero, no fim é alto, e é por isso que o retorno recebido tarde raramente vira alteração. Quem vai usar precisa ser ouvido antes de o escopo ser fechado, e não no aceite, quando a única resposta possível é aprovar ou atrasar.
