Você passa por cima da fase de Discovery?

Uma fase para planejamento de um produto, serviço ou parte disso: uma fase de desecobertas.

Já sabemos que existem diversas ferramentas à disposição dos profissionais de produto, e faz parte das responsabilidades e atividades dessa pessoa identificar e aplicar as melhores ferramentas e fluxos para ter a melhor entrega possível de um projeto. Neste artigo falarei sobre a fase de Discovery. Uma fase bastante inicial que é extremamente importante e está presente principalmente quando se está planejando algo novo, seja um produto, serviço ou parte disso. Uma feature por exemplo.

Se você que está lendo esse artigo e é arquiteto ou engenheiro de software, acho que verá que apesar dessa fase de Discovery estar atualmente muito falada e quase sempre ligada à área de UX, pode ser transportada para outras áreas do desenvolvimento — claro que com algumas diferenças — mas conceitualmente idêntica.

Dentre vários projetos que participei como analista de sistemas, pratiquei inúmeras vezes o Discovery, inconscientemente e de diversas formas.

Existe um consenso geral entre os caras de produto (e de UX, claro) que a fase de Discovery é uma das partes mais importantes no processo de design, uma vez que é nesse momento que paramos, sentamos, damos um passo para trás e realmente pensamos sobre como iremos definir realmente os fundamentos para o restante de todo o processo da criação à entrega. Entendemos os porquês e refinamos o nosso target.

Envolve pesquisar o contexto, separar o problema (ou os problemas e dores) que devem ser solucionados e buscar uma quantidade suficiente de evidências que serão capazes de direcionar todo o time envolvido ao que deve ser feito.

E é neste momento de descoberta que podemos fazer uso de alguns recursos que irão nos ajudar na captura de informações para nos guiar ao entendimento do problema para que por fim consigamos o principal: a melhor solução para aquela dor.

Discovery não envolve testar hipóteses ou soluções! É focar na busca do problema certo para daí buscar construir a coisa certa. Quando os times buscam fazer o Discovery de um produto que eles já decidiram fazer, isso não é Discovery. Isso se tornará apenas um exercício de busca ou documentação de requisitos ou de validação da ideia, e isso como vimos, não é o propósito.

A fase de Discovery é muito bem definida se olharmos para o famoso Diagrama do Diamante Duplo do design thinking. Conceitualmente ele representa a busca pela inovação, onde as linhas se divergem enquanto os times exploram o problema de forma macro, em um contexto mais amplo, que na fase de definição o time se alinha novamente baseado nas evidências encontradas do problema e na visão de futuro. Já o segundo diamante é referente à construção do que foi identificado, em fases de ideação, desenvolvimento e testes.

Existem uma variedade de atividades que podemos fazer em uma fase de Discovery, e vou citar algumas que ao meu entendimento, são fáceis e estão presentes em quase todos os cases que acompanhei.

Pesquisa Exploratória

Sempre que usamos qualquer tipo de pesquisa, temos um resultado sempre bom: seja grande ou pequeno, sempre resulta em um aprendizado. Esse tipo de pesquisa é chamado de exploratória ou generativa pois o resultado dela resulta em ideias/insights novos. Quem participa traz para o time uma visão macro do problema, ou uma visão de oportunidades.

Tudo se inicia com a maior visão do contexto possível, colocando o problema ou dor a ser resolvida como sendo uma pequena parte quase que isolada de todo um universo, e a medida que vai se tendo conhecimento sobre tudo o que há em volta, vai se afunilando a busca pelo entendimento de questões mais próximas e ligadas ao problema. Sempre de olho nas melhores oportunidades.

Aqui deixo listado alguns métodos para se fazer essa pesquisa exploratória com um grupo de usuários ou possíveis clientes do produto:

• Entrevistas pessoais: Sessões de feedback são muito eficazes. São rápidas e fáceis e é a melhor forma de conhecer as percepções e como é a receptividade dada para uma possível solução do problema ou dor
• Análise de logs / diário: Avaliar um conjunto de registros que fazem parte de um processo nos dá a possibilidade de conhecer o passo a passo e diagnosticar em uma linha do tempo o comportamento de um usuário e suas necessidades. Excelente para definir requisitos de UX.
• Análise de campo: Sair do escritório e ir até o local onde os usuários estarão inseridos e onde eles estão (ou estarão) utilizando o produto em questão é o melhor método para visualizar como o local e as forças externas do ambiente físico podem impactar na experiência para esses usuários.

Questionário de UX

Uma outra atividade de Discovery que posso citar é um questionário de UX: Uma lista de perguntas que podemos fazer para o time ou para os stakeholders do projeto, para realmente começar a ter um certo alinhamento das expectativas bem como uma garantia de que estaremos num caminho certo para o resto de nosso desenvolvimento do projeto.

Criar e usar essas perguntas antes de mergulhar de cabeça em um desenvolvimento realmente nos prepara melhor para o sucesso que estará por vir e nos força a dar um passo para trás e questionar algumas coisas como:

• O que eu já sei?
• O que eu preciso saber?
• Como ter certeza de que todos estão alinhados e prontos para o próximo passo?

Hmmmm, isso está parecendo bastante com a Matriz CSD, descrita aqui nesse outro artigo. Sim, realmente parece e pode ser utilizada, porém em um detalhamento mais amplo, voltado para questões envolvendo o cenário inicial do projeto, subdividido ainda em tópicos como o time, as objetivos/metas, os usuários, estratégias, métricas de sucesso e por último e não menos importante, os riscos que podem ser enfrentados.

Uma prática que acho muito interessante e proveitosa é realizar uma cerimônia de Discovery reunindo todos os envolvidos no projeto para um bate-papo honesto e estar preparado para considerar todo tipo de perspectiva e história que os participantes têm com esse determinado produto ou serviço que está ali sendo debatido.

Se a conversa é sobre um produto completamente novo, com certeza teremos mais suposições do que certezas, e serão levantadas muitas questões que precisarão de mais pesquisa, MAS, se você fez um certo levantamento e pesquisa anterior e já tem esses dados, o ideal é que seja levados para essa reunião para dar o apoio as respostas das perguntas que surgirão.

E claro, nunca se tem todas as respostas para tudo. Durante essa cerimônia, não se preocupe em ter todas as respostas. Simplesmente marque essa dúvida de alguma forma, seja com um círculo, um flag, ou de outra cor para simbolizar que você precisa considerar aquilo com mais atenção. Na verdade, essas marcações são o grande valor gerado, resultado dessa cerimônia porque nos força a enxergar onde estão os pontos de atenção e onde o time está desconectado.

Eu considero algumas perguntas interessantes para começar uma cerimônia de Discovery, como por exemplo:

Quem no time ou na empresa é a pessoa que mais sabe da história desse produto?

Conhecer a pessoa que tem experiência e participou ou acompanhou as decisões até chegar naquele momento histórico certamente poderá identificar os próximos passos e os porquês das coisas terem sido feitas como foram feitas.

Quem tem influência sobre esse produto?

Saber quem são as pessoas chaves que podem influenciar de certa forma no produto é extremamente importante. Precisamos ser capazes de conversar abertamente com eles bem como conhecer suas preferências pois isso nos guiará para apresentar melhor nossas soluções para eles. Por exemplo, se seu projeto possui um stakeholder que é uma pessoa extremamente analítica, garanta que a apresentação da sua entrega seja baseada em dados. Conhecer a pessoa que toma as decisões nos faz entender porque algumas coisas foram feitas de certa forma no passado e porque elas tem que ser feitas diferente agora.

Quem está no time, por que estão e quem já teve experiência em solucionar um problema parecido?

Aqui todos passam a conhecer a história das pessoas que compõem o time com o produto em si ou com produtos relacionados, e que talvez possam trazer melhores insights para problemas do que você, fazendo um exercício de co-criação e vice-versa.

Qual são os objetivos desse projeto?

Essa pergunta parece obvia demais, mas existem tantos perfis de pessoas que a percepção de um projeto pode mudar muito entre cada um. O que é legal aqui é que se tem como resultado a produção de uma lista entrega que neste momento já podem ser de certa forma priorizada, até porque o designer de UX provavelmente não terá tempo suficiente para considerar todas as entregas de início (até porque isso é um processo contínuo). O que vale aqui é definir os objetivos chave.

Por que as pessoas vão usar esse produto e não o produto da concorrência?

É necessário entender o que fazer para que o nosso produto tenha uma experiência que sobressaia a dos concorrentes ou como podemos fazer para gerar mais valor para o cliente e ele decida escolher o nosso e não o deles.

Quais comportamentos do usuário podem ser convertidos em dinheiro?

Precisamos sempre tem em mente que fim das contas tudo é business, o que importa mesmo é gerar renda para a empresa e para os nossos stakeholders. Sendo assim é nosso dever ter a certeza que o nosso design converterá em valores financeiros, pontos estes que precisam ser mapeados e estar alinhados com todos do time.

Enfim, existem claro, um milhão de perguntas que se pode fazer em cima de qualquer projeto, e existe aqui no Medium um artigo do UX Collective que eu acho fenomenal, que é um apanhado de questões prontas já categorizadas. O link está aqui, coloca aí no seu bookmark que é sucesso: https://uxdesign.cc/questions-ux-designers-should-be-asking-bc9a6ba87a34

O Discovery pelo Discovery

Para mim o que vale mesmo é envolver não só pessoas de tecnologia ou com bagagem de UX ou estritamente ligadas ao core do projeto. Buscar pessoas de outros departamentos da empresa, ou até mesmo possíveis clientes do produto final, dará uma visão muito mais abrangente e mostrará perspectivas completamente diferentes sobre como resolver a(s) dor(res) que aquele produto se propõe. Acho que é aí que moram as grandes sacadas e diferenciais.

Existem outras inúmeras atividades de Discovery, e nada impede inclusive de criarmos as nossas próprias que nos revelarão novas visões, ideias e comprovações. Que seja workshops na empresa, hackatons, testes em concorrentes, benchmarking, escuta de ligações do suporte, entrevista com time de vendas, enfim…

Fases de Discovery bem feitas garantem que quaisquer soluções propostas nas próximas fases dos projetos serão desejos dos usuários, viáveis para a empresa e condizentes com a tecnologia escolhida para tornar isso possível.

É sempre interessante encerrar essas atividades com as definições de algumas metas a serem cumpridas para as próximas fases do projeto e que tudo seja transparente. Os objetivos compartilhados no time envolvido. Por exemplo, o meu objetivo aqui publicando esses artigos é ajudar as pessoas, fazê-las considerar novas ferramentas ou pelo menos encorajá-las a tentar. Também aproveito para contar um pouco como é o processo que hoje participo em meus projetos e consultorias e conseguir trocar experiências. Um aprendizado recíproco.