Dia 04 — afinal, qual problema estamos resolvendo?
Nos últimos três dias deste desafio, uma ideia continuou aparecendo de formas diferentes.
No Dia 01:
Product Design não começa pela solução. Começa pela compreensão do problema.
No Dia 02, percebi que esse problema também precisa ser observado pelas perspectivas das pessoas, do negócio e da tecnologia.
No Dia 03, o Duplo Diamante mostrou a importância de explorar antes de decidir.
Mas agora surge uma nova dificuldade.
Depois de entrevistar pessoas, observar comportamentos, analisar dados e levantar hipóteses, podemos acabar com uma quantidade enorme de informações.
E então precisamos responder:
Como transformar tudo isso em um problema de Design que realmente ajude a orientar o projeto?
Porque “temos muitos dados” e “sabemos qual problema precisamos resolver” são duas coisas muito diferentes.
Uma solução disfarçada de problema
Existe um erro bastante fácil de cometer.
Imagine que alguém diga:
Precisamos criar um chatbot para ajudar pacientes a marcar consultas.
Parece que temos um problema definido.
Mas não temos.
Temos uma solução.
O chatbot já apareceu antes mesmo de entendermos o que está acontecendo.
Talvez exista dificuldade para marcar consultas.
Mas por quê?
As pessoas não encontram horários?
Não sabem qual especialidade escolher?
Não entendem o processo?
Precisam de atendimento fora do horário comercial?
O sistema apresenta erros?
Ou talvez o problema nem esteja no agendamento.
Quando escrevemos o problema já incluindo aquilo que pretendemos construir, diminuímos drasticamente o espaço de exploração.
Problema não é funcionalidade
Essa distinção parece pequena, mas muda bastante o projeto.
Solução disfarçada de problema
Precisamos adicionar filtros melhores na busca.
Problema
Pessoas têm dificuldade para encontrar resultados relevantes entre muitas opções disponíveis.
No primeiro caso, o filtro já foi escolhido.
No segundo, ainda podemos investigar diferentes possibilidades.
Talvez filtros sejam a solução.
Talvez busca inteligente.
Talvez recomendações.
Talvez categorização.
Talvez o problema esteja na quantidade de opções mostradas.
Definir bem o problema não significa saber a resposta.
Significa saber o que precisa melhorar.
Um bom problema cria direção sem fechar o caminho
Uma definição de problema precisa fazer duas coisas que parecem quase contraditórias.
Ela precisa ser específica o suficiente para orientar o trabalho.
Mas não pode ser tão específica a ponto de determinar antecipadamente a solução.
Se for ampla demais:
Precisamos melhorar a experiência dos pacientes.
Quase qualquer coisa cabe nessa frase.
Melhorar como?
Para quem?
Em qual momento?
Por quê?
Mas se for fechada demais:
Precisamos criar um botão que permita selecionar especialidades com ícones.
Já estamos desenhando.
Entre esses dois extremos existe um espaço muito mais útil.
Quem, necessidade, contexto e impacto
Uma estrutura que considero útil para organizar um problema é procurar responder quatro perguntas:
Quem?
Quem está enfrentando essa situação?
Não precisa ser necessariamente uma persona completa.
Precisamos apenas identificar o grupo ou comportamento relevante para aquele problema.
O que essa pessoa precisa conseguir fazer?
Qual necessidade está envolvida?
Aqui é importante evitar transformar a necessidade em uma funcionalidade.
Em qual contexto?
Quando ou em que situação esse problema acontece?
Qual é o impacto?
Por que isso importa?
O que acontece quando o problema não é resolvido?
Quem enfrenta a situação?
O que precisa conseguir fazer?
Quando e onde acontece?
Por que isso importa?
Essas perguntas não formam uma fórmula obrigatória.
São apenas uma maneira de evitar definições vagas ou excessivamente orientadas à solução.
Voltando ao aplicativo de consultas
Nos dias anteriores, usei um exemplo de um aplicativo para agendamento médico.
Imagine que a pesquisa tenha mostrado o seguinte:
Muitas pessoas entram no fluxo de agendamento, chegam à escolha da especialidade e abandonam o processo.
Depois de investigar, descobrimos que parte delas sabe que precisa procurar um médico, mas não sabe qual especialidade corresponde ao que está sentindo.
Uma definição ruim poderia ser:
Precisamos criar uma busca por sintomas.
A busca por sintomas pode ser uma ótima ideia.
Mas ainda é uma solução.
Uma definição mais aberta poderia ser:
Pessoas que desejam marcar uma consulta, mas não sabem qual especialidade procurar, têm dificuldade para avançar no agendamento e acabam abandonando o processo.
Agora conseguimos enxergar:
Quem: pessoas que precisam de atendimento, mas não conhecem a especialidade.
Necessidade: conseguir identificar o caminho adequado para continuar.
Contexto: durante o processo de agendamento.
Impacto: abandono.
E ainda temos espaço para imaginar diferentes soluções.
Evidência antes de convicção
Outra coisa importante:
uma definição de problema não deveria existir apenas porque alguém acredita que aquele é o problema.
Precisamos procurar evidências.
Dados quantitativos podem mostrar onde algo acontece.
Pesquisa qualitativa pode ajudar a entender por que.
Atendimento ao cliente pode revelar padrões recorrentes.
Analytics podem mostrar comportamentos.
Entrevistas podem revelar dúvidas, expectativas e motivações.
Observação pode mostrar comportamentos que nem sempre aparecem quando simplesmente perguntamos.
O problema precisa nascer do que conseguimos aprender sobre o contexto.
Não apenas da opinião de quem está na sala.
Sintoma e problema não são a mesma coisa
Essa talvez seja uma das partes mais traiçoeiras.
Às vezes enxergamos um sintoma e imediatamente o tratamos como problema.
A conversão caiu.
Isso é um dado.
Não necessariamente o problema.
As pessoas estão abandonando o checkout.
Isso é um comportamento observado.
Ainda precisamos entender por quê.
Pode existir:
- surpresa com o valor do frete;
- obrigatoriedade de cadastro;
- erro no pagamento;
- falta de confiança;
- pouca clareza sobre prazo;
- lentidão;
- algum problema técnico.
O abandono é o que conseguimos ver.
O problema pode estar algumas camadas abaixo.
Os “5 porquês” como ferramenta de investigação
Uma técnica simples que pode ajudar nessa investigação é perguntar repetidamente:
Por quê?
Imagine:
As pessoas abandonam o cadastro.
Por quê?
Porque não querem preencher todos os campos.
Por quê?
Porque algumas informações parecem desnecessárias.
Por quê?
Porque não está claro por que a plataforma precisa delas.
Agora a conversa já mudou.
Talvez o problema não seja simplesmente:
“O formulário é longo.”
Talvez exista também uma questão de confiança e transparência.
Os “5 porquês” não garantem que encontraremos uma causa definitiva.
Mas podem nos impedir de parar na primeira explicação disponível.
Reenquadrar muda as soluções possíveis
A maneira como descrevemos um problema influencia diretamente o tipo de solução que imaginamos.
Compare:
Como podemos criar um menu melhor?
com:
Como podemos ajudar pessoas a encontrar o que procuram com menos esforço?
A primeira pergunta já pressupõe um menu.
A segunda permite considerar:
busca, navegação, recomendações, atalhos, categorização, personalização ou até mudanças na própria estrutura do conteúdo.
Por isso, definir um problema também é um exercício de linguagem.
As palavras que escolhemos abrem ou fecham possibilidades.
“Como poderíamos...?”
Depois que conseguimos definir melhor o problema, existe uma pergunta muito usada em processos de Design:
Como poderíamos…?
ou, em inglês,
How Might We…?
A ideia é transformar o problema em uma pergunta que convide à exploração.
Voltando ao exemplo médico:
Problema:
Pessoas que não sabem qual especialidade procurar abandonam o agendamento porque não conseguem identificar o caminho adequado.
Podemos perguntar:
Como poderíamos ajudar essas pessoas a encontrar o atendimento adequado sem exigir que elas conheçam previamente uma especialidade médica?
Agora estamos começando a entrar no espaço da solução.
Mas ainda não escolhemos uma.
Uma boa pergunta não entrega a resposta
Existe diferença entre:
Como poderíamos criar um chatbot para orientar pacientes?
e:
Como poderíamos ajudar pacientes a entender qual caminho de atendimento é mais adequado?
Na primeira, a resposta já está escondida dentro da pergunta.
Na segunda, ainda existe espaço para descobrir.
Talvez seja chatbot.
Talvez não.
Essa diferença parece semântica.
Mas pode mudar completamente a direção de um projeto.
Prática editorial
O exercício do Dia 04
Hoje o exercício é pegar um problema de algum produto que utilizo e tentar escrevê-lo de três maneiras.
1. A versão espontânea
Escrever o problema exatamente como ele aparece primeiro na minha cabeça.
Sem tentar melhorar.
2. Procurar soluções escondidas
Perguntar:
Estou mencionando alguma funcionalidade?
Estou dizendo qual interface precisa existir?
Estou presumindo uma causa que ainda não investiguei?
Estou confundindo um sintoma com o problema?
3. Reescrever
Tentar incluir:
- quem enfrenta a situação;
- qual necessidade está envolvida;
- em qual contexto;
- qual impacto é percebido.
Depois transformar a definição em uma pergunta:
Como poderíamos…?
E verificar se essa pergunta permite mais de uma resposta possível.
Um pequeno teste para a definição do problema
Antes de seguir para ideação, posso fazer algumas perguntas:
Consigo explicar quem enfrenta esse problema?
Tenho alguma evidência de que ele existe?
Estou descrevendo uma necessidade ou uma funcionalidade?
Minha definição permite diferentes soluções?
Entendo por que resolver isso importa?
Se a resposta para várias delas for “não”, talvez ainda seja cedo para começar a desenhar.
Saber o problema não significa saber a solução
Talvez essa seja uma das ideias que mais estou carregando desses primeiros dias.
Existe uma pressão enorme para produzir alguma coisa visível.
Uma tela.
Um protótipo.
Um fluxo.
Algo que faça parecer que o projeto está avançando.
Mas definir melhor o problema também é trabalho de Design.
Às vezes, uma boa definição evita semanas construindo algo que nunca deveria ter sido construído.
Clareza antes de velocidade.
Dia 04 — meu ponto de partida
Se eu tivesse que resumir o aprendizado deste dia em uma frase, seria:
Um problema bem definido mostra onde precisamos chegar sem decidir antecipadamente qual caminho devemos usar.
Talvez desenhar a solução seja uma das partes mais visíveis do Design.
Mas escolher corretamente o que merece ser resolvido pode ser ainda mais importante.
04 de 100
Este é o quarto registro do 100 dias de Design, meu desafio pessoal de estudar Product Design, UX e produtos digitais durante cem dias e transformar cada etapa em uma publicação neste site.
100 dias.
100 assuntos.
100 postagens.
4 concluídos. 96 pela frente.
Comentários
Carregando comentários…