Product Discovery
A importância de entender o verdadeiro problema que você quer resolver
Antes de começar a falar sobre a metodologia em si, acho interessante fazer uma reflexão: Se você vai a um médico buscando tratamento e ele afirma que você precisa operar, sem ao menos te pedir alguns exames, você confiaria nesse profissional e seguiria com a operação? Provavelmente não, certo?
Como UX designers, nossa forma de examinar os “pacientes” e entendermos quais problemas estão causando dor é justamente através do Product Discovery.
Ok, mas o que é isso?
Product Discovery nada mais é do que um nome sofisticado para o momento inicial no qual o designer busca entendimento sobre o produto que ele irá trabalhar.
O entendimento pode ser: do produto em si, seus clientes, as regras de negócio que o regem, as métricas atuais (performance) e quais os principais problemas que estão prejudicando a experiência do usuário no cenário atual.
Sua importância cresce quando é preciso atuar em um novo projeto não existente ou quando você acaba de começar em uma nova empresa (momento que estou vivendo atualmente inclusive, rs).
Essa nomeclatura (Product Discovery) foi popularizada com o surgimento dos famosos UX frameworks como: Service Design, Google Design Sprint, Design Thinking, etc. Mas a ideia da metodologia já é antiga e vem sendo utilizada desde as concepções e práticas mais básicas de ergonomia e antropologia.
Não vou me aprofundar em nenhum framework em específico, pois meu objetivo aqui é ressaltar a importância desse momento do entendimento do produto antes de gerar soluções em si e em como ele irá ajudar você em seus projetos.
Mas pesquisa demora muito, minha empresa nunca vai aceitar…
Aqui na OLX o conceito e a importância da pesquisa já fazem parte de nosso dia-a-dia e é inclusive considerado o primeiro entregável dos times de Design. Mas a realidade nem sempre foi assim e nenhuma conquista vem sem “luta”.
Além disso, já passei por empresas em que a simples menção da palavra pesquisa gerava arrepios na espinha do stakeholder, pois ele associava sempre o termo atraso ou demora nas entregas “de valor” como layout e wireframes.
O importante quando você quer introduzir pesquisa em um ambiente avesso a ela é mostrar o valor e o retorno (ROI) que ela pode trazer para o projeto. Prepare uma defesa sólida e coerente e vá à luta!
Algumas formas de agir:
- Destacar que o período de pesquisa serve para tornar o projeto mais assertivo, ou seja, ele minimiza (mas não elimina) o risco de errar. Já perdi as contas de quantos problemas consegui evitar de irem para o ar simplesmente criando uma Blueprint. Um outro exemplo clássico é acreditar que determinada funcionalidade vai ser um game changer do seu produto, mas ao entrar em contato para ouvir os clientes reais descobrir que uma entrega muito mais rápida e menor vai gerar um valor muito maior para o produto.
- Outro exercício útil é apresentar para seu stakeholder principal o custo, em hora/ homem, de realizar a pesquisa versus o custo de consertar o produto já no ar. Destaque também os danos de imagem causados a marca!
- Priorize uma ou duas metodologias chave para seu projeto e se comprometa a entregá-las em um ou dois sprints. Isso quebra a imagem de que as entregas são demoradas e vai te permitir aos poucos ir introduzindo metodologias mais complexas e demoradas no futuro.
Lembre-se sempre: “The difference between zero and even a little bit of data is astounding.” (Jakob Nielsen)
Metodologias, Técnicas e Entregáveis
Existem dezenas de metodologias e entregáveis, e falar sobre cada uma individualmente iria requerer mais de um artigo. Porém, aqui vou destacar as que costumo utilizar com mais frequência ao assumir um projeto, mas não existe um guia do que é certo ou errado.
Para seus projetos, escolha metodologias que se sinta a vontade em aplicar, que se adequem ao seu orçamento e que se adequem em seus sprints.
CDS (Certezas Dúvidas e Suposições)
É uma técnica rápida e simples de implementar, que confere um entendimento geral do status atual do produto.
O time de UX se reúne com stakeholders e membros do time de TI para listar, em colunas separadas, todas as certezas, dúvidas e suposições que eles possuem sobre o produto.
O ideal é que sempre existam mais dúvidas do que certezas, pois são as dúvidas que irão gerar insumos para novas funcionalidades, atualizações, descoberta de potenciais problemas, etc.
Tempo de aplicação: Entre 2h a 3h
Recomendado para entender: Visão geral do produto
Para se aprofundar:
https://medium.com/educação-fora-da-caixa/matriz-certezas-suposições-e-dúvidas-fa2263633655
User Journey / Service Blueprint
Das metodologias que vou listar, esta é minha favorita, pois permite entender como seu usuário se relaciona com seu produto em diversos momentos e em quais pontos de contato existem problemas.
Ambas possuem algumas semelhanças e muitas vezes são confundidas como sendo a mesma documentação. Mas, a principal diferença entre elas é que enquanto a User Journey está mais focado na experiência do cliente ao longo da navegação e que tipo de emoções ele sente ao usar o produto, a Service Blueprint é mais focada no processo que entrega o serviço, isso é, ela detalha interações de front e back stage, quais sistemas estão interligados, quais as operações de suporte a operação principal, etc.
Geralmente opto pela Service Blueprint quando estou em um novo projeto que não existe ainda, ou quando o redesign do produto for muito complexo e disruptivo. Para os demais casos utilizo a User Journey.
Para essa documentação, o importante a fazer é realizar uma imersão nos processos da sua própria empresa e outra com seus clientes para mapear de que forma eles utilizam seu produto. Se possível, passe um dia atuando como se você mesmo fosse um cliente e um operador. Sua percepção irá mudar completamente.
Tempo de aplicação: Entre 2 a 3 semanas
Recomendado para entender: Todo o ecossistema atual do produto, regras de negócio, falhas na operação, Emoções do usuário, Pontos de contato
Para se aprofundar: https://www.cooper.com/journal/2015/5/journey-map-or-service-blueprint
Survey
Talvez a metodologia mais conhecida e tradicional mostrada neste artigo, pesquisas quantitativas sempre irão te dar insumos valiosos sobre seus usuários, além de relevância estatística para tomar decisões.
Porém muito cuidado para não ser tendencioso e induzir os participantes a responderem o que você quer ouvir, uma pesquisa mal aplicada pode ser pior do que a inexistência de dados.
Dispare para sua base de clientes, que estejam dentro da segmentação a ser estudada, e com uma taxa de abertura boa, em uma semana você já possuíra dados a sua disposição.
As vantagens de utilizar esta técnica é a fácil implementação, gratuidade (Google Forms), tabulação de dados automática e relevância estatística.
Tempo de aplicação: 2 a 3 dias para montar o form + 1 a 2 semanas para receber os resultados
Recomendado para entender: Perfil demográfico, hábitos de uso, feedbacks sobre o produto, Público Alvo
Para se aprofundar: http://uxmastery.com/better-user-research-through-surveys/
Entrevista com usuário
Esse tipo de pesquisa qualitativa irá gerar dados mais profundos e qualificados pois você estará ouvindo direto da boca do usuário o que ele sente e passa ao utilizar seu produto.
O segredo para coletar um bom feedback, no entanto, está na abordagem inicial: faça com que seu entrevistado se sinta a vontade em criticar e opinar e de forma alguma informe que você é a pessoa que está desenvolvendo o produto, pois isso fará com que ele fique com receio de dar opiniões sinceras.
A abordagem que costumo utilizar é me apresentar como sendo parte do time de atendimento ao cliente e informo que meu objetivo é ouvir a opinião sincera dele para a partir daí saber como melhorar o produto atual.
Sobre a realização da entrevista de forma presencial ou remota, sinceramente, fique a vontade para escolher a solução que melhor lhe atende.
Obviamente na presencial você terá um poder maior sobre a moderação e conseguirá medir reações físicas e faciais do entrevistado, entretanto minha percepção é de que entrevistas remotas tendem a gerar feedbacks mais sinceros pois o usuário fica mais confortável estando no “anonimato”.
Tempo de aplicação: 2 a 3 semanas para recrutamento e aplicação + 1 semana para tabulação de dados e transcrição
Recomendado para entender: Hábitos de uso, feedbacks sobre o produto, problemas mais críticos para o usuário
Para se aprofundar:
https://www.nngroup.com/articles/interviewing-users/
Teste de Usabilidade
Se você estiver trabalhando em um produto que já está no ar é fundamental testar suas funcionalidades com seus usuários para identificar os pontos de atrito e potenciais problemas na experiência. Repare que não estou falando em testar novas funcionalidades, no momento do Discovery, você quer testar o que já existe!
Prepare um roteiro com os cenários de uso mais comuns e estimule sempre seu usuário a utilizar a técnica de Think Aloud durante o teste. Você vai conseguir ter uma ideia melhor de como ele pensa enquanto realiza a tarefa e perceber os problemas e dificuldades que ele está tendo.
Se você não consegue recrutar seus reais usuários, realize testes de “Guerrilha” com pessoas de dentro da empresa mesmo, mas atenção ao recrutar os participantes, opte sempre por pessoas que tenham pouco ou nenhum contato com o produto em si. Funcionários do RH, limpeza, manutenção são boas opções.
Se sua empresa possuir softwares de gravação de tela, como Crazy Egg ou Hotjar por exemplo, cruze os resultados dos testes com as descobertas das gravações e os resultados serão ainda melhores.
Tempo de aplicação: 1 a 2 semanas para recrutamento e aplicação + 1 semana para tabulação de dados e transcrição
Recomendado para entender: Hábitos de uso, feedbacks sobre o produto, problemas mais críticos para o usuário
Para se aprofundar:
http://www.experienceux.co.uk/faqs/what-is-usability-testing/
Outras metodologias interessantes:
Focus Group, Stakeholder’s Map, Card Sorting, User Diary, Análise de Métricas, Personas, etc.
Agora, mãos à obra!
Agora que você sabe o quão importante o Design Discovery é para seu produto e principalmente para seus usuários, não deixe de inseri-lo em sua rotina de trabalho e em suas entregas.
Adotar a cultura de projetar de forma data driven não é uma tarefa simples no curto prazo, porém extremamente recompensadora no longo prazo.
Quer tirar alguma dúvida? Debater algum tópico do artigo?
Manda um e-mail pra gente, vai: design@olxbr.com.
Estamos buscando designers incríveis para completar nossa equipe.