Montando um backlog de produto a partir de pesquisa com usuários
Nesse texto vou contar como eu, pesquisadora de experiência, ajudei meu time a construir um backlog de produto por meio de pesquisa. Vamos lá?
Um pouco de contexto
Eu atuava como pessoa pesquisadora, também chamada de UX Researcher. E o que eu fazia no time? Pesquisa com usuários, análises de funcionalidades e também análises de oportunidades no produto que era meu objeto de estudo diário. O produto era uma plataforma de eventos e meu time, chamado de Content Discovery, focava na descoberta de conteúdo na plataforma. A plataforma era um marketplace (os organizadores criavam seus eventos e na plataforma os usuários acessavam os eventos de interesse, retirando ingresso). Aqui é um exemplo do quão multidisciplinar era o meu time:
Certo dia meu líder falou comigo:
Precisamos estudar sobre a funcionalidade ‘Favoritos’ porque a ideia é sermos uma plataforma de eventos omnichannel. ‘Favoritos’ já tem no Aplicativo. Queremos agora colocar na versão Web.
📖 Omnichannel: nesse contexto se resumia a intenção de oferecer uma experiência aproximada entre os canais em que uma funcionalidade se encontrava (no caso Web e App).
Diante dessa necessidade, a primeira pergunta que eu me fiz foi: ‘Favoritos’ é só ‘copiar e colar’ na Web?
Ai começou o meu trabalho como pesquisadora. 🕵️♀️🕵️♀️🕵️♀️
Passo 1: investigando 'Favoritos'
Diante dessa pergunta se era só 'copiar e colar' 'Favoritos' na Web, minha primeira atitude foi buscar entender porque 'Favoritos' existia, qual era a sua entrega de valor e, já que existe no App, se os usuários usavam. Para ganhar esse contexto, fui conversar com a Ex-Group Product Manager Mobile que acompanhou a funcionalidade desde o início até o seu lançamento. Nessa conversa, descobri que:
- ‘Favoritos’ existia muito em função de um comportamento identificado no Google Analytics;
- O objetivo de 'Favoritos' era facilitar a encontrabilidade de eventos para que o usuário o acessasse com facilidade quando quisesse;
- Existia uma deficiência do recurso de busca da aplicação. O sistema de busca não era nem um pouco prático. Logo, 'Favoritos' ganhava relevância e espaço por encurtar o acesso a eventos que o usuário demonstrava interesse em ir, favoritando-os;
Passo 2: entender o que queria descobrir
Dado que agora eu tinha contexto sobre a funcionalidade e, sobretudo, entendido o conceito de 'Favoritos', eu precisava entender como as pessoas se comportavam diante da necessidade de 'guardar' informações (já que esse era a essência da funcionalidade 'Favoritos') e também, uma vez que 'Favoritos' estava implementado no Aplicativo, eu tinha algumas dúvidas:
Será que as pesssoas sabem como funciona? Para que serve? O que acham sobre a funcionalidade? Atende as suas expectativas?
Dessa forma, entendi que eu precisava de metodologias que me respoderiam o COMO as pessoas usavam e O QUE as pessoas achavam sobre 'Favoritos'. Nessa hora, recorri ao excelente texto da querida Elisa Volpato sobre como escolher os métodos de pesquisa. Em seguida, parti para a elaboração de perguntas para entrevista e questionário.
Passo 3: com os dados em mãos, é hora de analisar
Depois de executar e coletar informações das entrevistas e questionário, chegou a hora de analisar os resultados obtidos. Nesse momento, gosto de aplicar a abordagem de Atomic Research que busca democratizar e tornar mais acessível os aprendizados de pesquisa. De modo geral, Atomic Research consiste em desdobrar, a partir de técnicas aplicadas, quais são os fatos, descobertas e conclusões que se tira de tais técnicas. Olha esse exemplo na prática:
Suponha que você ou o seu time de pesquisa tenham aplicado algumas técnicas/experimentos. Em cima desses experimentos, podemos extrair fatos ou evidências. São dados concretos que foram observados no experimentos. A partir deles, descobrimos certas informações Y, o que nos faz concluir Z. Essa é a ideia por trás de Atomic Research. No final, você contruiu uma linha de raciocínio e de causalidade (uma informação quando interpretada gerou outra).
Considerando a funcionalidade que eu estava estudando, coloco abaixo um exemplo fictício de uma linha de raciocínio baseada em Atomic Research:
Acho que uma das partes mais legais dessa abordagem é o final: o que você, enquanto pesquisadora, descobre. Me sinto uma verdadeira detetive (risos). 🤓🤓🤓
Como ilustrado acima, alguns itens na coluna de 'Conclusão' revelaram problemas na funcionalidade de 'Favoritos' e problemas são oportunidades de design, oportunidades para se propor soluções, ideias, pensar em algo funcional, em se projetar algo. Diante dessa situação no estudo, vi que poderia ser interessante propor uma etapa colaborativa com todo o time, já que ele era muldisciplinar como comentei no início do texto. Essa multidisciplinaridade poderia ser aproveitada em uma dinâmica colaborativa em que cada um poderia colaborar com a sua especialidade.
Passo 4: qual método escolher para resolver problemas?
Acessei o site www.designkit.org, que é uma grande biblioteca de métodos de design, para analisar qual método se encaixaria nessa etapa de propor soluções a problemas. Eu já tinha lido um pouco sobre o método ‘How Might We’ no LinkedIn e fazendo buscas na internet. Aproveitei e fiz uma busca também no www.designkit.org sobre 'How Might We' e, segundo a descrição, percebi que seria uma super oportunidade pratica-lo junto ao meu time.
E qual é a ideia por trás do 'How Might We'? Dado que você tem um problema, você o transforma em uma pergunta a qual vai instigar o time a encontrar respostas/ideias. Olha só um exemplo da aplicação de 'How Might We':
A partir da pergunta elaborada, as pessoas envolvidas começam a pensar em várias ideias que podem atender o problema em questão.
Passo 5: dando contexto ao time e facilitando uma ideação colaborativa
Depois de definir o método da ideação colaborativa que iria apoiar o time a encontrar soluções para os problemas identificados por meio de pesquisa, eu tinha que dar contexto do estudo para o meu time. Até aquele momento, tinha sido um processo super solitário como pesquisadora. Se eu quero que meu time ajude a encontrar soluções, é preciso primeiro dar CONTEXTO. Por isso, meus passos foram:
- Montar uma apresentação explicando sobre o estudo de 'Favoritos', métodos aplicados e, sobretudo, os fatos, descobertas, conclusões e problemas identificados. Convoquei todo o meu time nessa reunião;
- Elaborar um workshops para o time resolver os problemas em conjunto, sendo direcionado 25 minutos para cada problema e tendo em mente criar soluções básicas e evolutivas;
💡 Preciso fazer uma observação sobre o 'How Might We':
É um método que instiga a criatividade. Isso é ótimo, mas é preciso ter o pé no chão e considerar a realidade atual. Logo, meu líder sugeriu um desafio que era elaborar ideias que considerassem a nossa tecnologia atual, ou seja, nós enquanto time teriamos condição de implementar e, também, elaborar ideias que seria necessária uma atualização da tecnologia atual. Dessa forma, teriamos em mãos ideias compatíveis com a nossa realidade atual e outras nem tanto assim, mas viáveis mediante algumas atualizações de tecnologia.
A ideação aconteceu na ferramenta MURAL, versão gratuita.
Passo 6: resultado da ideação
Nossa! Vou te contar que foi muito legal a ideação. Foi lindo ver um time pensando em conjunto, unindo conhecimento em prol de um objetivo em comum. Vou destacar alguns pontos observados por mim durante a ideação:
- Discussões em conjunto: não foi uma atividade onde cada pessoa colocava o seu post-it. Era uma discussão, pessoas em conjunto conversavam para encontrar juntas uma solução;
- Habilidades diferentes fortalecem a discussão: a ideação uniu pessoas com habilidade diversas que orientaram decisões durante a discussão;
- Resultados da pesquisa sendo relembrados durante a ideação: durante as discussões de ideias, os fatos, descobertas e conclusões foram lembrados para guiar as decisões. As ideias não foram baseadas em opiniões e sim em evidências;
- Criação de soluções viáveis e soluções que demandam atualização na tecnologia: no final da ideação, o time criou soluções consideradas básicas para 'Favoritos' e soluções que necessitariam atualizações da tecnologia atual;
No final dessa ideação, o time em conjunto tinha criado um backlog de produto. Isto é, uma lista de itens ou estoque de atividades para fazer sobre a funcionalidade de 'Favoritos'.
Passo 7: próximos passos
Depois desse momento colaborativo, eu compartilhei com o meu líder o resultado da ideação, além de passar as minhas percepções gerais do exercício. Em seguinda, o desafio era:
- Definir prioridades de curto, médio e longo prazo de acordo com a estratégia e resultado que a empresa quer alcançar: era importante elencar como as ideias seriam entregues para garantir uma entrega de valor recorrente;
- Construir a experiência do usuário, interações e fluxos da funcionalidade: como a experiência do usuário se desdobra ao longo do tempo, os cenários de uso, as regras, se o usuário tocar no botão acontece o que?;
- Acompanhar métricas após o lançamento: tinhamos que verificar se o que tinha sido proposto estava mesmo gerando resultado esperado;
No final de todo o processo, fiquei super orgulhosa de ver as pessoas em conjunto buscando soluções a partir de pesquisa com usuários. Gostaria de compartilhar alguns tópicos importantes na atuação de uma pessoa pesquisadora, como:
- Entender o problema a fundo (‘detetive’ da experiência): não assumir nada como verdade, questionar tudo, buscar evidências e não opiniões;
- Definir estratégias de como entender melhor o problema: dado que eu tenho um problema, qual técnica responde melhor as minhas dúvidas?
- Aprender e disseminar conhecimento sobre o usuário: não basta só a pessoa pesquisadora conhecer os usuários, o time todo tem que entender como elas pensam, agem, para buscar construir algo mais assertivo, usando tal conhecimento aprendido para desenvolver um produto ou serviço melhor;
- Facilitar atividades colaborativas: acredito muito no trabalho colaborativo e que o resultado pode ser surpreendente e enriquecedor se envolvermos pessoas com pontos de vistas e habilidades diferentes;
Aprendizados
Depois desse processo que demorou algumas semanas, deixo aqui os meus aprendizados:
- Uso de pesquisa ou métodos de análise reduziram riscos de produto: aquela pergunta que eu comentei no início se era só ‘copiar e colar’ a funcionalidade caiu por terra porque com as pesquisas, além de mostrar que a funcionalidade atual entregava pouco valor, fez com que o time revisasse a própria funcionalidade
- A redução de riscos (no caso por meio de pesquisas) gerou mais confiança no time, pois o que será desenvolvido tem valor para o usuário e para o negócio: processo de pesquisa revelou problemas não vistos ou mapeados antes, o que gerou um sentimento maior de que o que será entregue será mais assertivo do que algo que não passou pelo processo de pesquisa
- Um time quando tem contexto do problema pode pensar em soluções em conjunto: percebi na dinâmica que todas as pessoas do time propuseram soluções e conversavam em conjunto trazendo aspectos da pesquisa como evidência. Isso mostra que as pessoas realmente entenderam o problema e que as reuniões para passar todo o contexto fizeram sentido.
Essa foi a minha experiência como pessoa pesquisadora dentro de um time multidisciplinar. Eu acabei saindo da empresa em que atuei como UX Researcher. Espero em breve conferir na plataforma as soluções criadas pelo time.
Me conta aí nos comentários o que você tem aprendido atuando no papel de pessoa pesquisadora. Não conhecia o papel de pessoa pesquisadora? Espero ter mostrado um pouco do dia a dia dessa profissional que pesquisa sobre usuários e gera conhecimento e valor para uma empresa/time.
Escrevi o artigo ao som de Lulu Santos.
Referências:
