Transformando Dados em Aprendizados — Parte 4

Mauro Tavares
the product discovery
7 min readNov 19, 2020

Transformando o conhecimento em aprendizado

Sobre a série

Este artigo é a última parte de uma série de 4 artigos em que falamos, em algumas pílulas de conhecimento, um pouco sobre como um dado bruto de uma pesquisa pode se tornar um aprendizado compartilhável e aplicável na construção de produtos.

Parte 1 — Coletando os dados

Parte 2 — Transformando dados em informação

Parte 3 — Transformando informação em conhecimento

Parte 4 — Compartilhando os aprendizados (este aqui que você está lendo)

Boa leitura 😉

Ilustração de Neil deGrasse Tysson com as duas mãos para cima

“… Dados tornam-se informações, informações tornam-se conhecimento, conhecimentos tornam-se sabedoria …” — Neil deGrasse Tyson

Transformando o conhecimento em aprendizados

A efetividade de uma pesquisa não se dá apenas pela aplicação única para qual ela foi proposta. Quando geramos algum conhecimento, ele deve ser compartilhado, assim podemos gerar novos insights. Esse processo pode ser chamado de aprendizado ou quando chegamos a uma definição de um conceito e temos ciência de algo, podemos dizer que é uma sabedoria, como diz Neil deGrasse Tysson em sua frase.

Dois balões de conversa cruzados com a imagem do meme mind blowing no espaço entre os dois

Falando do processo de Design, ou ainda mais específico, do processo de Product Discovery, Marty Cagan em seu livro Inspired diz que um dos princípios para se ter um bom discovery é ter aprendizados compartilhados. E se tratando de aprendizados compartilhados, não estamos falando apenas de um ritual onde o time compartilha o que aprendeu no dia ou na semana, mas também de algumas práticas operacionais que tornam isso possível, como por exemplo, a organização e rastreamento das informações, práticas de apresentação de resultados e aplicabilidade de tudo isso nos produtos/serviços.

Organizando informações

Um time de design, produto, ux, marketing, tecnologia ou qualquer outro, possui uma premissa básica: Nunca trabalham sozinhos.

Logo, devemos ter um cuidado com o entendimento das informações com que lidamos. No momento de organização de conhecimentos para outras pessoas usufruírem, é de grande importância a preocupação de carregar junto com esse conhecimento o contexto, pois quando geramos algo e não damos um contexto a isso, nada mais é do que um pensamento.

Em um episódio (não me lembro qual) de Ricky e Morty, eles vão para um planeta onde existe uma consciência única, ou seja, se estou falando com uma pessoa sobre um assunto, posso virar para a pessoa do lado e continuar a conversa. E a visão que devemos ter em tornar os conhecimentos compartilhados, para que se tornem aprendizados, é mais ou menos essa. Todo o conteúdo que o time gera deve estar disponível para todos os envolvidos. Dessa forma, é possível utilizar os resultados de uma pesquisa quantitativa feita recentemente em uma outra iniciativa que possuí hipóteses similares, por exemplo.

Alguns meses atrás, no time em que trabalho, tivemos longas discussões sobre o que significava alguns termos dentro de nosso contexto. Demoramos para chegar em um acordo, e só entramos em um consenso quando embasamos o que antes era um achismo em alguma referência. Mas você deve estar se perguntando, o que isso tem a ver? Simples, para criar um aprendizado, precisamos nos comunicar, para nos comunicar precisamos de uma linguagem em comum, para ter uma linguagem em comum precisamos ter claro e definido os conceitos que sabemos. Ou seja, uma peça chave para a geração de aprendizados é ter claro o que é cada coisa entre o próprio time primeiramente, a começar pela definição de termos simples de nosso cotidiano, como oportunidade, hipótese, solução… para posteriormente podermos entender o que outras pessoas querem nos dizer. Para um time uma hipótese pode ser encarada de uma forma e paro outro de outra forma. Ter essa preocupação e a maturidade de tentar entender o que o outro está tentando dizer antes de dizer que está errado, auxilia no compartilhamento de conhecimento de uma maneira mais fluída.

Métodos e ferramentas como instrumentos de comunicação

O aprendizado não é adquirido apenas com conhecimento, mas da união com a comunicação. Para que essa união realmente gere aprendizados, dentro do contexto de design e produto temos diversas ferramentas, metodologias e frameworks que podem servir de um grande apoio no momento em que precisamos compartilhar algo.

Quando estamos falando de um resultado de uma pesquisa, na qual foi realizada com objetivo de servir de insumo para construção ou iteração de um produto, é necessário que o resultado dela sirva de embasamento para decisões. E na maioria das vezes ferramentas que utilizamos rotineiramente podem facilitar este proce. Para explicar isso melhor vou contar um pouco sobre minha experiência de quando iniciei em UX Research alguns anos atrás.. Sempre que finalizava alguma pesquisa, transformava todo o dado bruto em um relatório gigante de pesquisa, onde apresentava ou enviava por e-mail para o grupo de trabalho, porém depois de um tempo comecei a ficar com uma pulga atrás da orelha e me perguntar:

  • Como que esse relatório vai virar um produto?
  • Como vou garantir que a necessidade que mapeie realmente será atendida?
  • Como vou medir o que foi atendido ou não?
  • Até que ponto eu coloquei meu viés nesse resultado?
  • Será que realmente alguém ligou para minha apresentação?
  • Será que alguém leu o relatório?

Foi então que depois de um tempo cheguei a uma conclusão: estava comunicando da forma errada o conhecimento gerado. Depois de começar, junto com o time em que estou atualmente, a trabalhar com Atomic Research, abriu uma porta de possibilidades de novas formas que poderia compartilhar o resultado de alguma atividade. Como por exemplo, em vez de um relatório com as diversas jornadas do usuário lindas e completas com bullet points que ninguém ia ler em um ppt bonitão cheio de pirotecnia em que gastei horas trabalhando, criamos um blueprint onde temos uma visão da jornada do usuário e de como cada solução se encaixa em cada necessidade, com isso conseguimos dar uma visão geral para o grupo de trabalho e discutir em cima da ferramenta e já tirar pontos acionáveis e de atenção. Este é apenas um exemplo, podemos fazer isso desde de um canvas até um protótipo.

Product Blueprint

O link para este template esta em nosso Notion de ferramentas: bzz resources

Com esta abordagem, com um pouco menos de glamour da pirotecnia dos ppts e cercados de planilhas, conseguimos algumas vantagens:

  1. Redução de tempo gasto fazendo documentos para nunca serem lidos. Quando precisamos realmente fazer uma apresentação, temos as informações a nossa disposição e organizada;
  2. Conseguimos rastrear de uma maneira mais fácil qual necessidade estamos atendendo com uma certa solução e, metrificar isso;
  3. Criamos uma “linguagem” em comum entre o time;
  4. Informações a nossa disposição quando precisamos de evidências;
  5. Reduzimos o viés nos resultados das pesquisas.

E claro que com essa abordagem, passamos a ter alguns problemas também. Deixo tais pontos aqui contando como resolvemos (ou não):

  1. Toneladas de planilhas: Não digo que resolvemos esse problema totalmente, mas tentamos minimizar unificando alguns artefatos que possuíam relação;
  2. Cada iniciativa com artefatos totalmente diferentes: fizemos um trabalho com o time de definição de um conjunto de artefatos mínimos quando se passava por determinada fase de construção do produto;
  3. Lembrar de manter todos documentos atualizados: sem resolução. Parece simples, mas não é, na correria do dia a dia acabamos esquecendo de registrar e evidenciar tudo. Porém, isso deve ser um hábito a ser adquirido.
  4. Ter um versionamento que funcione: Quando lembramos criamos uma nova versão do arquivo na pasta, mas na maioria das vezes isso não acontece e acabamos perdendo uma parte desse histórico de evolução.

O impacto de um aprendizado

Para finalizar este artigo e esta série, deixo aqui um último aprendizado sobre todo esse processo de lapidar algo que construímos. Assim como citei nos primeiros parágrafos um dos princípios de discovery do Marty Cagan, é tudo aquilo que aprendemos no processo de construção de um produto ou serviço ou até um processo de pesquisa sozinho, deve ser compartilhado. Só assim, é possível trazer pontos de vista além do nosso e tornar todo esse processo algo extremamente rico e cheio de experiências que podem gerar impactos na vida de muitas pessoas.

Takeaways

  • Nunca estamos trabalhando sozinhos, ou seja, qualquer tipo de informação e conhecimento que geramos deve ser pensada para que outra pessoa/time também possa usufruir disso;
  • Aproveite o máximo de ferramentas que possuem artefatos, como canvas, planilhas, gráficos, tabelas […] utilizando para comunicar o resultado de suas pesquisas e do seu trabalho. Assim, pessoas que não estão habituadas com isso também podem aprender coisas novas. Mas não se esqueça do que falamos na Parte 2 desta série onde abordamos também sobre a comunicação correta com cada tipo de stakeholder;
  • O aprendizado vem da união do conhecimento e da comunicação.

Inscreva-se em nossa newsletter para receber mais conteúdos sobre desenvolvimento de produtos digitais!

Revisão: Bruna Werthajm e Caio Almeida

--

--