Definição no Design Thinking

Empresas gastam milhões desenvolvendo produtos que ninguém pediu.

Governos criam políticas públicas que não resolvem a dor real da população.

Startups pivotam três, quatro, cinco vezes até perceber que estavam respondendo à pergunta errada desde o início.

Isso raramente é incompetência: é um viés cognitivo profundo, quase primitivo, que faz o cérebro humano preferir pular direto para a solução, porque construir é mais recompensador do que diagnosticar.

A regra central desta fase é simples e definitiva: a qualidade de uma solução nunca supera a qualidade da definição do problema que a originou.

Da empatia à definição

Se a fase de Empatia é o momento de mergulhar no mundo do usuário e absorver tudo como uma esponja, a fase de Definição é o momento de torcer essa esponja e extrair significado do oceano de dados brutos coletado.

O cérebro humano tem uma necessidade quase patológica de encontrar padrões, mesmo onde eles não existem, fenômeno que a psicologia cognitiva chama de apofenia.

Na fase de Definição, a apofenia é o principal risco a ser gerenciado.

Síntese de insights e Affinity Mapping

Depois da fase de Empatia, a equipe tem um volume grande de material: entrevistas transcritas, anotações de campo, fotos, citações diretas de usuários.

A síntese de insights é o processo de olhar para essas peças e identificar o que elas significam em conjunto, não isoladamente.

Um usuário reclamando de tempo de espera é uma anedota; vinte usuários descrevendo a mesma frustração de formas diferentes já é um insight.

Dado não é insight.

Dado é matéria-prima; insight é o que surge quando dados aparentemente desconectados se cruzam e revelam um padrão que ninguém tinha percebido antes.

A técnica mais usada para chegar lá é o Affinity Mapping (Mapeamento por Afinidade): cada observação, citação ou dado relevante é escrito em um post-it individual, sem edição nem filtro, e depois os post-its são agrupados não por categoria pré-definida, mas por afinidade natural, deixando os próprios dados revelarem sua organização.

Por que fazer isso com post-its físicos

Manipular fisicamente os dados ativa circuitos neurais diferentes daqueles usados na leitura de uma planilha: o córtex motor entra em ação e a memória espacial é recrutada, um fenômeno que os neurocientistas chamam de cognição incorporada (embodied cognition). Um estudo publicado no Journal of Cognitive Psychology mostrou que a manipulação física de informações melhora a capacidade de categorização em até 30% em comparação com interfaces puramente digitais.

Clusterização e padrões emergentes

Cada agrupamento de post-its com identidade própria é um cluster, e cada cluster é candidato a um insight-chave: uma verdade não óbvia sobre o comportamento ou a necessidade do usuário, capaz de redirecionar toda a estratégia do projeto.

Um insight-chave não é "os usuários querem rapidez" (algo óbvio), mas algo como "os usuários não querem rapidez, eles querem previsibilidade, porque a ansiedade da espera incerta consome mais energia cognitiva do que a espera em si".

O primeiro tipo de observação leva a acelerar um processo; o segundo leva a redesenhar toda a experiência de espera.

São soluções radicalmente diferentes nascendo de níveis diferentes de compreensão do problema.

Quando a síntese é bem feita, os clusters começam a se conectar entre si, revelando padrões emergentes, ou seja, a lógica oculta do sistema estudado.

Ler esses padrões, e não apenas aplicar a ferramenta corretamente, é o que separa um profissional júnior de um sênior.

Point of View (POV)

Sair da fase de Empatia com insights ricos não é suficiente se a equipe escreve uma definição genérica do tipo "precisamos melhorar a experiência do usuário", que é um desejo vago disfarçado de estratégia.

A técnica do Point of View (POV) resolve isso com uma fórmula específica: identificar um usuário arquetípico, descrever uma necessidade profunda desse usuário e revelar o insight que sustenta essa necessidade.

Fórmula: "[Usuário], que é [tipo de pessoa], precisa de [necessidade], porque, surpreendentemente, descobrimos que [insight]."

POV fraco x POV poderoso

Ao redesenhar o aplicativo de um banco, um POV fraco seria "usuários precisam de um app mais intuitivo". Um POV poderoso seria: "Maria, 62 anos, aposentada, precisa pagar suas contas pelo celular sem depender dos filhos, porque descobrimos que, para ela, pedir ajuda com tecnologia não é uma questão prática, é uma questão de dignidade e autonomia." O segundo POV abre um universo de soluções completamente diferente: em vez de botões maiores, a equipe passa a pensar em como preservar a autonomia de uma pessoa.

Essa mudança de enquadramento é frequentemente o momento mais transformador de um projeto.

O antropólogo Gregory Bateson chamava isso de "diferença que faz diferença": em qualquer sistema existem infinitas variáveis, mas apenas algumas, quando alteradas, produzem mudanças significativas no resultado.

Redefinir o problema é justamente encontrar essa variável-chave.

Duas características de um problema bem definido

1. Nem específico nem amplo demais: um problema específico demais ("precisamos de um botão verde na tela inicial") é uma solução disfarçada de problema. Um problema amplo demais ("precisamos tornar o mundo melhor") não guia ninguém a lugar nenhum.
2. Acionável: a equipe precisa ter capacidade real de resolvê-lo dentro das restrições existentes de tecnologia, orçamento e tempo. Um problema acionável provoca a reação imediata de "consigo começar a pensar em soluções para isso agora".

How Might We (HMW)

A técnica How Might We (Como Poderíamos) conecta a fase de Definição à fase de Ideação.

Cada palavra da fórmula foi escolhida com cuidado: "How" (como) implica que existem múltiplas soluções possíveis; "Might" (poderíamos) remove a pressão de encontrar a resposta certa, abrindo espaço para especulação criativa; "We" (nós) estabelece que é um esforço coletivo.

HMW derivado do POV da Maria

"Como poderíamos permitir que Maria pague suas contas de forma independente, preservando seu senso de autonomia e dignidade?" Essa pergunta não prescreve uma solução, ela abre um espaço de possibilidades: assistente de voz, interface simplificada, tutorial gamificado, atendimento presencial redesenhado. Todas essas respostas continuam válidas.

Matriz CSD: Certezas, Suposições e Dúvidas

Todo problema é definido dentro de um contexto de incerteza, e ignorar essa incerteza é receita para o fracasso.

A Matriz CSD é um exercício de honestidade intelectual que classifica tudo o que a equipe acredita saber sobre o problema em três categorias:

• Certezas: o que se sabe com base em evidências concretas, dados de pesquisa e fatos observados diretamente.
• Suposições: o que a equipe acredita ser verdade, mas ainda não tem prova suficiente.
• Dúvidas: o que simplesmente não se sabe e precisa ser descoberto.

Em quase todo projeto em que essa ferramenta é aplicada, a coluna de Certezas é embaraçosamente curta, a de Suposições é longa e a de Dúvidas é ampla.

Isso não é fraqueza, é lucidez: saber o que não se sabe é o primeiro passo para construir algo que funciona.

Cada suposição listada é um convite à investigação; cada dúvida é uma pergunta de pesquisa esperando para ser formulada; e cada certeza é uma base sobre a qual a equipe pode construir com confiança.

A matriz também define prioridades de investigação: as suposições mais arriscadas, aquelas que, se estiverem erradas, derrubam toda a estratégia, precisam ser testadas primeiro.

Foco estratégico

Uma equipe pode identificar dezenas de problemas legítimos durante a pesquisa, mas não pode resolver todos ao mesmo tempo.

A fase de Definição também é sobre escolher batalhas, com dois critérios centrais: critérios de sucesso claros (as métricas que, mais adiante, dirão se a solução funcionou) e alinhamento com o negócio (viabilidade econômica, técnica e estratégica).

Design não existe em um vácuo: uma solução brilhante que não se sustenta financeiramente ou não é tecnicamente viável é, na prática, uma fantasia bonita.

Validação do problema

Antes de avançar para a Ideação, vale a pena validar se o problema definido é de fato o problema certo.

Tudo o que foi feito até esse ponto, síntese, mapeamento, clusterização, POV, é uma interpretação dos dados, e interpretações podem estar erradas.

A validação normalmente envolve voltar ao campo e apresentar a definição do problema aos próprios usuários: se a pessoa se reconhece na definição, há uma validação forte; se ela discorda, ainda há trabalho a fazer, e isso não é falha, é o processo funcionando.

Errar na definição e corrigir agora custa pouco; errar na definição e só perceber depois de meses de desenvolvimento custa muito mais.

Uma análise da CB Insights com mais de 100 startups que faliram encontrou que a razão número um de fracasso, citada em 42% dos casos, foi "não havia necessidade de mercado para o produto".

Resolver brilhantemente o problema errado

O Google Glass era uma proeza de engenharia que resolvia um problema que quase ninguém tinha. O Segway prometia revolucionar o transporte urbano, mas ignorou o quanto andar nele fazia a pessoa se sentir deslocada. A Kodak inventou a câmera digital e definiu o problema como "como protegemos nosso negócio de filme" em vez de "como lideramos a fotografia digital". A definição do problema não apenas direciona a solução, ela determina se a equipe está jogando o jogo certo.

Fechamento

A fase de Definição é onde se troca o luxo da ambiguidade pelo compromisso da precisão: onde a empatia vira estratégia, os dados viram direção e o caos da pesquisa se cristaliza em um farol que vai guiar cada decisão seguinte.

A frase atribuída a Einstein, de que gastaria 55 minutos pensando no problema e 5 minutos pensando na solução, provavelmente é apócrifa, mas descreve bem o espírito desta etapa.

No fim das contas, a inovação não começa com uma ideia genial, começa com uma pergunta bem formulada, com a coragem de olhar para os dados sem viés e de admitir o que ainda não se sabe.

Da próxima vez que alguém perguntar "qual é a solução?", vale a pena responder com outra pergunta: "qual é o problema?"