Como iniciar um processo de discovery
Antes de qualquer coisa: estamos fazendo discovery da forma correta?
É muito importante que a gente saiba analisar se o que é descoberto é uma solução ou um problema que gera inúmeras hipóteses de solução.
O discovery é um espaço de tempo alocado para explorar o problema antes de qualquer desenvolvimento ou protótipos nascerem.
Discoveries podem ser diferentes para cada tipo de produto em termos de tempo que se leva, quem está envolvido e qual o resultado esperado desse processo.
O propósito é entender todos os aspectos e cenários desse problema para que ele possa ser refinado e resultar em um Problem Statement. O que nos auxilia a entender qual problema de fato vamos resolver e se ele se desenrola em processos, pessoas, produto, tecnologia ou numa mistura de tudo isso.
Problem Statement é uma descrição sintetizada de um problema a ser analisado ou uma condição a ser melhorada. Ele nos trás uma visão a fim de que seja possível encontrar os gaps entre o to be e o as is de um processo ou produto. Concentrando-se em evidências fortes, a definição do problema deve ser projetada para abordar todos os aspectos do cenário e se orientadas a uma dor do usuário tende a ser mais objetivo.
Alguns pontos que você pode ter entendido errado:
1- Discoveries não são sinônimos de pesquisa.
Se você está realizando um teste de usabilidade, você não está explorando o problema e sim coletando feedbacks e entendendo o cenário de uma das propostas de solução.
2- Discoveries necessitam de pesquisa!
E existe um equívoco nesse entendimento sobre quão forte é a ligadura os dois.
Infelizmente esse equívoco acontece mais do que gostaríamos quando temos uma timeline de entrega que não condiz com o tempo hábil para pesquisas, ou quando uma área de negócio/stakeholders dificultam a conexão entre o responsável por ux e usuário da solução de fato.
A não realização dessa análise prévia deixa com que o cenário esteja tão controlado ao ponto de ser uma validação sobre o que se sabe (ou acha que sabe) sobre o problema. Tomar uma decisão quando você só mapeou estes termos pode resultar em uma evidência fraca.
Dica: Comece desenvolvendo propostas de experimentos de recrutamento e/ou engajamento e apresente essa proposta para o cliente, e qual o objetivo final desse experimento, por exemplo: transformar uma proto persona em uma persona real!
3- Discovery é do time!
Muitas vezes vemos a responsabilidade caindo sobre apenas uma pessoa: um UX designer ou UX researcher. Enquanto parte do time decide sobre tecnologia, arquitetura ou premissas do negócio.
O que acontece é que talvez exista uma “solução” do time para um problema do qual eles não conhecem, e assim sem mais nem menos o problema já se encaixa numa proposta de solução. Na maior parte do tempo ela pode não fazer muito sentido e deixa frágil a tomada de decisão pois a solução normalmente é só uma maneira de resolver o problema. Isso também significa que apenas a perspectiva de uma pessoa absorve e interpreta o problema é trazida para a discussão, ao invés de ser uma discussão de um time multidisciplinar com perspectivas, culturas e experiências de vida e profissionais diferentes.
4- Discovery não existe para VALIDAR hipóteses.
E a chave desse entendimento está na palavra descobrir (discovery), que é aprender sobre algo que você desconhece. E para isso é necessário ter uma mente aberta e escuta ativa para conhecer sobre o Problem Space e como podemos aprender sobre ele.
Problem Space consiste em explorar explorar e entender sobre o problema ou oportunidade por diferentes perspectivas. Ele pode acontecer em fases, na primeira fase: entender onde a atuação diverge e procura trazer algumas variáveis do problema uma dica é utilizar de uma ferramenta do design thinking como: 5W (Who, What, When, Where e Why). Na segunda fase: observar auxilia a convergir para delimitar e definir o problema a fim de gerar um POV — Ponto de Vista. Onde é aplicado uma forma de visualizar o problema a partir da visão do usuário.
Para auxiliar o problema pode ser transformado em um objetivo de valor para o time: “Nós queremos ajudar <persona> a <proposta de valor/ação a ser definida> quando o <contexto>.
Só assim vai ser possível começar a criar consciência sobre o que realmente é o problema e a melhor forma de resolvê-lo. Infelizmente muitos times ainda optam por trabalhar o solution space e aí realizam um discovery para validar o que foi presumido sobre os usuários (necessidades, dores, ganhos e como eles interagiriam com aquele entregável)
Solution Space: brainstorming de ideias para resolver ou abraçar uma nova oportunidade através de pessoas, processos, produto e ou tecnologia.
Essa é uma prática péssima e facilmente identificada como uma perda de tempo e dinheiro. Você pode acabar estocando insights (hipóteses) que invalidem o que foi presumido/assumido. Ou você acaba cego para receber novas visões/perspectivas sobre o problema.
5- Discovery não é design sprint, e lançei a braba!
Design sprints são muito efetivos para produzir mvps (mínimo produto viável) e nivelar stakeholders de forma efetiva. Mas realizar workshops de ideação não são de fato um discovery. Não é nos juntar em uma sala por alguns dias (ou numa chamada no teams, rs) em uma sessão de ideação e ter um entendimento real sobre o problema. E o objetivo do discovery não é produzir protótipos de alta fidelidade, e sim de realizar todo o trabalho necessário para que o time realmente entenda o que permeia o problema, a melhor forma de lidar com ele e de forma rápida para que seja possível com experimentar hipóteses.
Então: o que é discovery de verdade?
Essa fase envolve a condução de pesquisas com pessoas que são afetadas diretamente pelo problema como: personas e proposta de valor, análises e testes de usabilidade, entrevistas in-depth, estudos etnográficos(antropologia social sobre tribos, subculturas, esfera pública e organizações) e netnográficos (comunidades online), sombra e etc…
Também inclui atividades explorativas sobre viabilidade técnica, definindo e polindo arestas sobre o problema, refinando e descobrindo o que são entregáveis de valor para a organização
Dada a amplitude das diferentes atividades, uma descoberta real requer uma abordagem multidisciplinar, é um esforço de equipe. E, por último, é uma mentalidade de que não sabemos todas as respostas. Portanto, precisamos de um tempo dedicado para investigá-lo adequadamente.
