: :
os agilistas

ENZIMAS #193 – Da pesquisa ao desenvolvimento: como trabalhar resultados?

ENZIMAS #193 – Da pesquisa ao desenvolvimento: como trabalhar resultados?

os agilistas
: :

Marcelo Szuster: Bom dia, boa tarde, boa noite, este é mais um episódio de Enzimas, breves reflexões que te ajudam a catalisar o agilismo em sua organização.

Sofia Orsini: Oi pessoal, tudo bom? Meu nome é Sofia Orsini, sou capitã do chapter de design de uma aldeia aqui da DTI e hoje eu trabalho como design de serviço e UX strategy em um cliente que a gente atende, mas eu sou formada em psicologia, e não em design, então isso traz uma intersecção interessante para a minha atuação em pesquisa e como que eu trabalho os resultados das pesquisas que eu atuo hoje no nosso contexto, e é sobre isso que eu vim falar um pouquinho aqui nesse enzimas. Quando a gente faz uma pesquisa em um contexto de UX é muito importante que a gente saiba pegar as informações que a gente coleta durante essa pesquisa e transformar em alguma coisa que seja útil para os nossos objetivos, porque o objetivo de fazer uma pesquisa sempre vai ser uma tomada de decisão dentro do contexto do produto. Podem ser vários tipos de tomada de decisão, pode ser a criação de uma nova feature, uma mudança de prioridades, pode ser pivotar o nosso produto completamente, pode ser excluir uma tarefa de uma sprint, são coisas bem diversas que a gente pode tirar a partir de uma pesquisa, essa tomada de decisão é o denominador comum do porque a gente faz pesquisa. Então a missão da pessoa que está fazendo essa pesquisa é coletar os dados e levar aos responsáveis pela tomada de decisão, que pode não ser essa própria pessoa, podem ser stake holders diversos no contexto do nosso produto. E essa tomada de decisão precisa ser habilitada através de insights que sejam realmente acionáveis, então a gente não vai só apresentar dados crus para esses stake holders ou para essas pessoas, a gente precisa apresentar de uma determinada maneira. Então para isso a gente precisa saber transformar realmente o dado cru nesses insights. Geralmente quando a gente faz uma pesquisa, seja ela qualitativa ou quantitativa a gente tem um grandes volumes de dados na nossa frente, não é? De vários tipos, dados que a gente precisa ler, fazer conta analisar e criar relações entre eles para conseguir comunicar esses resultados de forma efetiva. O que a gente chama de dados, uma definição para isso, seriam fatos crus que não são processados e que são coletados por diversos meios e métodos diferentes. Se a gente garante um planejamento de pesquisa bem feito, com amostra apropriada para os nossos objetivos e os métodos corretos a gente sabe que a gente pode confiar nos dados que a gente obteve, mas ele raramente vão ser o que a gente precisa para tomar uma decisão por si só, a gente precisa então transformar eles em insights, que são o fruto da análise desses dados e informações diversas para entender o contexto e obter uma visão mais holístico do fenômeno que a gente está olhando ali com a nossa pesquisa. Então se a gente for pensar assim no fluxo que esses dados passam até se transformar em um insight de fato a gente começa com o dado cru, como eu comentei antes, mas para a gente conseguir chegar em um pedaço de informação de fato, esses dados a gente precisa olhar para eles de forma a resumir e organizar e encontrar padrões. Aí a gente tem o que a gente vai chamar de informação aqui, que é um conjunto de dados ou um dado mais processado. Com essas informações a gente vai olhar para elas e a gente precisa questionar elas. Nem sempre o que a gente obtém em uma pesquisa é uma verdade absoluta, raramente é, inclusive. Então a gente precisa questionar, precisa perguntar o porquê daquilo, daquela informação que a gente está olhando, precisamos empatizar com a informação que a gente está consumindo, levando em consideração quem nos deu aquela informação ou de onde saíram aqueles dados, para api a gente entender de fato o que são as necessidades ou motivações e dores, como nossa próxima etapa de transformação do nosso dado. A partir dessas necessidades a gente entende, enquanto pessoas que trabalham com produto digital, a gente considera o contexto desse produto e o contexto do nosso negócio também, todas as regras que a gente sabe que regem aquele ambiente para aí adicionar essas informações e realmente ter o nosso insight. Então a gente juntar o que veio da nossa pesquisa, o que veio do nosso usuário com as informações contextuais para poder levar isso para alguém que vai tomar a decisão de uma forma que ela possa tomar uma decisão mais acertada em cima disso, em cima do nosso insight acionável. Então, talvez para complementar, que não é um insight, porque o que é eu já passei um pouquinho, mas saber o que não é nos ajuda também. Os dados por si só não são insights, como eu já falei, as observações por si só não são insights. Se a gente está fazendo um processo de shadow, por exemplo, com um potencial usuário do nosso produto e a gente observa que ele toma uma determinada série de ações antes de chegar no nosso produto. Isso é apenas uma observação, não é um insight em si só, a gente precisa analisar isso dentro do contexto, fazer perguntas para ele, adicionar mais alguns dados para realmente transformar em informação e depois entender as necessidades e as dores, para aí ter o nosso insight, como eu comentei antes. E aí uma coisa muito importante, que é um erro que a gente comete com muita frequência é que falas ou pedidos diretos dos nossos usuários não são insights. O seu usuário pode estar te falando adoraria ter uma feature que faz X, Y e Z, mas isso não é seguro o suficiente para você ir lá e desenvolver X, Y e Z só com base nisso, porque muitas vezes a o que a pessoa fala realmente faz, a gente precisa algo para além do declarativo, a gente precisa de algo comportamental. Então a gente vai usar esse dado e juntar com dados de pesquisas mais voltadas para o comportamental para entender se realmente vale a pena desenvolver aquela feature, ou enfim, aquele produto como um todo. Então beleza, a gente está fazendo esse processo de transformar os dados que a gente obteve nas pesquisas nesses insights acionáveis que a gente deve levar para os nossos stake holders. Durante a etapa que a gente precisa encontrar os padrões, resumir e organizar os nossos dados têm algumas ferramentas que podem nos ajudar a fazer isso melhor. São ferramentas bastante famosas que a gente encontra em vários de materiais de UX que se chamam mapeamento de afinidade e análise temática, vou explicar cada uma delas, são bem simples, mas são partes muito centrais do processo de análise de dados que podem ajudar de várias formas diferentes. O mapeamento de afinidade basicamente é a gente organizar dados relacionados em grupos, que muitas vezes é chamado pelo nome em inglês de clusters, muita gente se refere a isso como clusterização, mas isso facilita a nossa análise. Se a gente tem muitas e muitas informações de, por exemplo, dez entrevistas com usuários, a gente vai ter muitos dados transcritos dessas entrevistas, mas que tem muita coisa em comum, coisas que vários usuários diferentes falaram que são parecidas, ou coisas sobre um determinado tema que apenas um usuário falou, então a gente vai fazer essa análise dos grupos que estão ali, não só do pedaço de informação isolado. A partir dessa análise dos grupos a gente pode fazer uma análise temática. Para isso a gente cria o que a gente chama de códigos ou tags talvez seja uma palavra mais fácil de entender o que eu estou me referindo aqui, para auxiliar a gente a organizar essas informações, então a gente pode nessa análise de dez entrevistas que eu comentei a gente pode ter vários grupos que são relacionados a dores do usuário, por exemplo e a í a gente classifica esses grupos com essa tag, ou esse código, para que isso a gente consiga depois olhar para esse grupo de dados ou informações e aí realmente trabalhar em cima disso para chegar em nosso resultado esperado. Então criar esses temas, códigos ou tags nos ajuda bastante a resumir mesmo as informações e transformar aquilo em alguma coisa. Não tem muito como a gente definir isso a priori, em alguns casos faz sentido, e a gente já sabe mais ou menos os grupos que a gente vai encontrar, os temas que a gente está olhando e aí vale a pena a gente iniciar essa análise já olhando para esses grupos, em outros casos eles vão aparecer conforme a gente analisa. Então a gente vai olhando para grupos e percebendo quais são os temas que se apresentam ali para a gente, esse processo é bastante orgânico. Quando a gente pensa no momento, que eu comentei antes, de transformar as informações nas motivações ou dores dos usuários a gente fala muito de empatizar, e para isso é muito importante, uma coisa que é muito básica do design, que a gente vê sempre, tem muitos conteúdos sobre design, de mapeamento de jornada e dos elementos da experiência do usuário, dessa pessoa que está conversando com a gente. O mapeamento da jornada nos ajuda a entender realmente o que está em torno daquela pessoa que nos deu aquele dado, ou das pessoas que a gente entrevistou, daquelas 10 pessoas que a gente fez entrevista a gente vai tentar sintetizar tudo aquilo que elas nos falaram em uma jornada, e entender quais são os problemas, de onde está saindo aquele problema, que elementos da experiência que também podem estar melhorando ou piorando esse processo, e a partir disso a gente vai ter uma visão melhor do que são as dores e as necessidades nesse contexto. E aí para considerar o contexto e o negócio que a gente vai realmente finalizar e transformar no nosso insight acionável aí vem de pesquisas e conhecimentos anteriores, isso a gente tem uma questão muito forte na pesquisa que a gente acha que a gente nunca sabe o suficiente, mas a gente sabe sim algumas coisas sobre o nosso contexto que a gente consegue afirmar com uma relativa certeza. Essas coisas a gente usa para analisar nossas futuras pesquisas. Usando esse conhecimento de causa, digamos, a gente vai conseguir transformar o nosso dado em um insight mais acionável. Para finalizar vou tentar dar um exemplo aqui no formato de áudio. A gente pode imaginar que um dos nossos dez entrevistados, das entrevistas que a gente fez no meu exemplo nos falou. Eu gostaria de ter uma visão detalhada de todos os meus pedidos em tempo real no portal do cliente. Um caminho seria a gente pegar isso e falar vamos desenvolver uma visão detalhada de todos os pedidos em tempo real no portal do cliente. Mas, durante outras pesquisas, ou durante a mesma pesquisa a gente foi encontrando outras coisas. A gente encontra que essa pessoa também nos falou que toda semana ele atualiza o sistema manualmente com o status dos pedidos, então ele atualiza isso uma vez por semana. Hoje ele tem uma feature que resolve um problema parecido de uma forma mais simples, e ele acessa essa feature quatro vezes por mês, uma vez por semana mais ou menos. E a gente sabe, enfim, por conhecimentos gerais no mundo, que com a pandemia, por exemplo, a logística a nível global ficou muito caótica, e a gente não tem muita visibilidade. Nesse grupo de informações que a gente conseguiu a gente consegue extrair um tema, que é mais ou menos gestão de material e reabastecimento, por exemplo, de uma pessoa que precisa fazer pedidos e controlar esses pedidos, se eles vão chegar a tempo. A gente também tem algumas informações sobre esse mercado, nesse mercado ficar sem o estoque significa ter um prejuízo milionário, imagina que esse estoque é algo essencial para a produção desse cliente, dessa pessoa, se ela fica sem ela perde muito dinheiro. Mas a gente também sabe que a gestão de pedidos demanda muito trabalho manual e contato por e-mail, então essa pessoa que nos fez essa fala passa muito tempo tendo que falar com representante de diferentes fornecedores tentando harmonizar todas as entregas, gerenciando espaço em almoxarifado, em armazéns para conseguir trabalhar com todo esse volume de dados e todo esse fluxo está muito caótico. E a gente também sabe, do nosso contexto do nosso produto que é possível a gente fazer uma integração com o sistema, que 80% dos nossos clientes usam. A gente nem sabe talvez se aquela pessoa que nos fez aquela fala inicial usa esse sistema, mas a gente sabe que olhando para o todo 80% dos nossos clientes usam, e a gente tem um direcionamento estratégico da nossa empresa de redução de working capital, por exemplo, que é reduzir o dinheiro que está parado, essencialmente, e a partir disso a gente consegue pensar em um insight que eu formulei aqui como exemplo. Acreditamos que nosso usuário se beneficiaria por uma integração direta com o sistema de gestão de reabastecimento, com notificações de atraso enviadas com antecedência apropriada, ou seja, ele não é exatamente o que aquela pessoa nos pediu lá no início, mas com base em todas as informações que a gente juntou, todos os outros dados que a gente integrou naquele dado inicial a gente tirou esse insight, que nos dá um pouquinho mais de segurança sobre o que desenvolver. Lógico, a partir daí a gente vai desenhar experimentos para testar nossas hipóteses e fazer todo o processo de experimentação que antecede o desenvolvimento de uma feature idealmente. Mas fazendo esse processo de transformar o dado em um insight acionável já nos ajuda a economizar um pouquinho do tanto que a gente vai dar tiro no escuro nesse contexto. E aí, por fim, tendo esses insights acionáveis em nãos chega o momento te apoiar a tomada de decisão. De novo, nem sempre somos nós mesmo que vamos tomar as decisões, mas o que a gente precisa fazer é apresentar os nossos insights para os stakeholders de forma sintetizada e que seja facilmente compreensível, seja isso da maneira como for mais apropriado no contexto, uma apresentação de slide, um mural, (inint) [00:11:11], isso vai variar muito de organização para organização, e também apontar as conexões significativas que esses insights que a gente está trazendo tenham com a estratégia da organização e do produto, além de oferecer um contexto útil que possa impactar na priorização, por exemplo. Nem sempre um insight por si só vai nos dar a resposta da decisão, mas olhando para o contexto de todo o time, ou do produto como um todo a gente vai conseguir priorizar de formas diferentes. Passei um pouquinho por um processo que pode nos ajudar a transformar esses dados de pesquisa nos insights para realmente conseguir trabalhar os resultados das nossas pesquisas, mas e novo, não é um processo fechado, é uma coisa muito orgânica que a gente vai aprendendo conforme a gente vai exercitando. A minha recomendação aqui é que usando esses princípios básicos vocês testem o que funciona para o contexto de vocês, vão inteirando e melhorando cada vez mais esse processo para que a gente consiga tomar decisões cada vez mais acertadas nos nossos produtos.

Marcelo Szuster: Bom dia, boa tarde, boa noite, este é mais um episódio de Enzimas, breves reflexões que te ajudam a catalisar o agilismo em sua organização. Sofia Orsini: Oi pessoal, tudo bom? Meu nome é Sofia Orsini, sou capitã do chapter de design de uma aldeia aqui da DTI e hoje eu trabalho como design de serviço e UX strategy em um cliente que a gente atende, mas eu sou formada em psicologia, e não em design, então isso traz uma intersecção interessante para a minha atuação em pesquisa e como que eu trabalho os resultados das pesquisas que eu atuo hoje no nosso contexto, e é sobre isso que eu vim falar um pouquinho aqui nesse enzimas. Quando a gente faz uma pesquisa em um contexto de UX é muito importante que a gente saiba pegar as informações que a gente coleta durante essa pesquisa e transformar em alguma coisa que seja útil para os nossos objetivos, porque o objetivo de fazer uma pesquisa sempre vai ser uma tomada de decisão dentro do contexto do produto. Podem ser vários tipos de tomada de decisão, pode ser a criação de uma nova feature, uma mudança de prioridades, pode ser pivotar o nosso produto completamente, pode ser excluir uma tarefa de uma sprint, são coisas bem diversas que a gente pode tirar a partir de uma pesquisa, essa tomada de decisão é o denominador comum do porque a gente faz pesquisa. Então a missão da pessoa que está fazendo essa pesquisa é coletar os dados e levar aos responsáveis pela tomada de decisão, que pode não ser essa própria pessoa, podem ser stake holders diversos no contexto do nosso produto. E essa tomada de decisão precisa ser habilitada através de insights que sejam realmente acionáveis, então a gente não vai só apresentar dados crus para esses stake holders ou para essas pessoas, a gente precisa apresentar de uma determinada maneira. Então para isso a gente precisa saber transformar realmente o dado cru nesses insights. Geralmente quando a gente faz uma pesquisa, seja ela qualitativa ou quantitativa a gente tem um grandes volumes de dados na nossa frente, não é? De vários tipos, dados que a gente precisa ler, fazer conta analisar e criar relações entre eles para conseguir comunicar esses resultados de forma efetiva. O que a gente chama de dados, uma definição para isso, seriam fatos crus que não são processados e que são coletados por diversos meios e métodos diferentes. Se a gente garante um planejamento de pesquisa bem feito, com amostra apropriada para os nossos objetivos e os métodos corretos a gente sabe que a gente pode confiar nos dados que a gente obteve, mas ele raramente vão ser o que a gente precisa para tomar uma decisão por si só, a gente precisa então transformar eles em insights, que são o fruto da análise desses dados e informações diversas para entender o contexto e obter uma visão mais holístico do fenômeno que a gente está olhando ali com a nossa pesquisa. Então se a gente for pensar assim no fluxo que esses dados passam até se transformar em um insight de fato a gente começa com o dado cru, como eu comentei antes, mas para a gente conseguir chegar em um pedaço de informação de fato, esses dados a gente precisa olhar para eles de forma a resumir e organizar e encontrar padrões. Aí a gente tem o que a gente vai chamar de informação aqui, que é um conjunto de dados ou um dado mais processado. Com essas informações a gente vai olhar para elas e a gente precisa questionar elas. Nem sempre o que a gente obtém em uma pesquisa é uma verdade absoluta, raramente é, inclusive. Então a gente precisa questionar, precisa perguntar o porquê daquilo, daquela informação que a gente está olhando, precisamos empatizar com a informação que a gente está consumindo, levando em consideração quem nos deu aquela informação ou de onde saíram aqueles dados, para api a gente entender de fato o que são as necessidades ou motivações e dores, como nossa próxima etapa de transformação do nosso dado. A partir dessas necessidades a gente entende, enquanto pessoas que trabalham com produto digital, a gente considera o contexto desse produto e o contexto do nosso negócio também, todas as regras que a gente sabe que regem aquele ambiente para aí adicionar essas informações e realmente ter o nosso insight. Então a gente juntar o que veio da nossa pesquisa, o que veio do nosso usuário com as informações contextuais para poder levar isso para alguém que vai tomar a decisão de uma forma que ela possa tomar uma decisão mais acertada em cima disso, em cima do nosso insight acionável. Então, talvez para complementar, que não é um insight, porque o que é eu já passei um pouquinho, mas saber o que não é nos ajuda também. Os dados por si só não são insights, como eu já falei, as observações por si só não são insights. Se a gente está fazendo um processo de shadow, por exemplo, com um potencial usuário do nosso produto e a gente observa que ele toma uma determinada série de ações antes de chegar no nosso produto. Isso é apenas uma observação, não é um insight em si só, a gente precisa analisar isso dentro do contexto, fazer perguntas para ele, adicionar mais alguns dados para realmente transformar em informação e depois entender as necessidades e as dores, para aí ter o nosso insight, como eu comentei antes. E aí uma coisa muito importante, que é um erro que a gente comete com muita frequência é que falas ou pedidos diretos dos nossos usuários não são insights. O seu usuário pode estar te falando adoraria ter uma feature que faz X, Y e Z, mas isso não é seguro o suficiente para você ir lá e desenvolver X, Y e Z só com base nisso, porque muitas vezes a o que a pessoa fala realmente faz, a gente precisa algo para além do declarativo, a gente precisa de algo comportamental. Então a gente vai usar esse dado e juntar com dados de pesquisas mais voltadas para o comportamental para entender se realmente vale a pena desenvolver aquela feature, ou enfim, aquele produto como um todo. Então beleza, a gente está fazendo esse processo de transformar os dados que a gente obteve nas pesquisas nesses insights acionáveis que a gente deve levar para os nossos stake holders. Durante a etapa que a gente precisa encontrar os padrões, resumir e organizar os nossos dados têm algumas ferramentas que podem nos ajudar a fazer isso melhor. São ferramentas bastante famosas que a gente encontra em vários de materiais de UX que se chamam mapeamento de afinidade e análise temática, vou explicar cada uma delas, são bem simples, mas são partes muito centrais do processo de análise de dados que podem ajudar de várias formas diferentes. O mapeamento de afinidade basicamente é a gente organizar dados relacionados em grupos, que muitas vezes é chamado pelo nome em inglês de clusters, muita gente se refere a isso como clusterização, mas isso facilita a nossa análise. Se a gente tem muitas e muitas informações de, por exemplo, dez entrevistas com usuários, a gente vai ter muitos dados transcritos dessas entrevistas, mas que tem muita coisa em comum, coisas que vários usuários diferentes falaram que são parecidas, ou coisas sobre um determinado tema que apenas um usuário falou, então a gente vai fazer essa análise dos grupos que estão ali, não só do pedaço de informação isolado. A partir dessa análise dos grupos a gente pode fazer uma análise temática. Para isso a gente cria o que a gente chama de códigos ou tags talvez seja uma palavra mais fácil de entender o que eu estou me referindo aqui, para auxiliar a gente a organizar essas informações, então a gente pode nessa análise de dez entrevistas que eu comentei a gente pode ter vários grupos que são relacionados a dores do usuário, por exemplo e a í a gente classifica esses grupos com essa tag, ou esse código, para que isso a gente consiga depois olhar para esse grupo de dados ou informações e aí realmente trabalhar em cima disso para chegar em nosso resultado esperado. Então criar esses temas, códigos ou tags nos ajuda bastante a resumir mesmo as informações e transformar aquilo em alguma coisa. Não tem muito como a gente definir isso a priori, em alguns casos faz sentido, e a gente já sabe mais ou menos os grupos que a gente vai encontrar, os temas que a gente está olhando e aí vale a pena a gente iniciar essa análise já olhando para esses grupos, em outros casos eles vão aparecer conforme a gente analisa. Então a gente vai olhando para grupos e percebendo quais são os temas que se apresentam ali para a gente, esse processo é bastante orgânico. Quando a gente pensa no momento, que eu comentei antes, de transformar as informações nas motivações ou dores dos usuários a gente fala muito de empatizar, e para isso é muito importante, uma coisa que é muito básica do design, que a gente vê sempre, tem muitos conteúdos sobre design, de mapeamento de jornada e dos elementos da experiência do usuário, dessa pessoa que está conversando com a gente. O mapeamento da jornada nos ajuda a entender realmente o que está em torno daquela pessoa que nos deu aquele dado, ou das pessoas que a gente entrevistou, daquelas 10 pessoas que a gente fez entrevista a gente vai tentar sintetizar tudo aquilo que elas nos falaram em uma jornada, e entender quais são os problemas, de onde está saindo aquele problema, que elementos da experiência que também podem estar melhorando ou piorando esse processo, e a partir disso a gente vai ter uma visão melhor do que são as dores e as necessidades nesse contexto. E aí para considerar o contexto e o negócio que a gente vai realmente finalizar e transformar no nosso insight acionável aí vem de pesquisas e conhecimentos anteriores, isso a gente tem uma questão muito forte na pesquisa que a gente acha que a gente nunca sabe o suficiente, mas a gente sabe sim algumas coisas sobre o nosso contexto que a gente consegue afirmar com uma relativa certeza. Essas coisas a gente usa para analisar nossas futuras pesquisas. Usando esse conhecimento de causa, digamos, a gente vai conseguir transformar o nosso dado em um insight mais acionável. Para finalizar vou tentar dar um exemplo aqui no formato de áudio. A gente pode imaginar que um dos nossos dez entrevistados, das entrevistas que a gente fez no meu exemplo nos falou. Eu gostaria de ter uma visão detalhada de todos os meus pedidos em tempo real no portal do cliente. Um caminho seria a gente pegar isso e falar vamos desenvolver uma visão detalhada de todos os pedidos em tempo real no portal do cliente. Mas, durante outras pesquisas, ou durante a mesma pesquisa a gente foi encontrando outras coisas. A gente encontra que essa pessoa também nos falou que toda semana ele atualiza o sistema manualmente com o status dos pedidos, então ele atualiza isso uma vez por semana. Hoje ele tem uma feature que resolve um problema parecido de uma forma mais simples, e ele acessa essa feature quatro vezes por mês, uma vez por semana mais ou menos. E a gente sabe, enfim, por conhecimentos gerais no mundo, que com a pandemia, por exemplo, a logística a nível global ficou muito caótica, e a gente não tem muita visibilidade. Nesse grupo de informações que a gente conseguiu a gente consegue extrair um tema, que é mais ou menos gestão de material e reabastecimento, por exemplo, de uma pessoa que precisa fazer pedidos e controlar esses pedidos, se eles vão chegar a tempo. A gente também tem algumas informações sobre esse mercado, nesse mercado ficar sem o estoque significa ter um prejuízo milionário, imagina que esse estoque é algo essencial para a produção desse cliente, dessa pessoa, se ela fica sem ela perde muito dinheiro. Mas a gente também sabe que a gestão de pedidos demanda muito trabalho manual e contato por e-mail, então essa pessoa que nos fez essa fala passa muito tempo tendo que falar com representante de diferentes fornecedores tentando harmonizar todas as entregas, gerenciando espaço em almoxarifado, em armazéns para conseguir trabalhar com todo esse volume de dados e todo esse fluxo está muito caótico. E a gente também sabe, do nosso contexto do nosso produto que é possível a gente fazer uma integração com o sistema, que 80% dos nossos clientes usam. A gente nem sabe talvez se aquela pessoa que nos fez aquela fala inicial usa esse sistema, mas a gente sabe que olhando para o todo 80% dos nossos clientes usam, e a gente tem um direcionamento estratégico da nossa empresa de redução de working capital, por exemplo, que é reduzir o dinheiro que está parado, essencialmente, e a partir disso a gente consegue pensar em um insight que eu formulei aqui como exemplo. Acreditamos que nosso usuário se beneficiaria por uma integração direta com o sistema de gestão de reabastecimento, com notificações de atraso enviadas com antecedência apropriada, ou seja, ele não é exatamente o que aquela pessoa nos pediu lá no início, mas com base em todas as informações que a gente juntou, todos os outros dados que a gente integrou naquele dado inicial a gente tirou esse insight, que nos dá um pouquinho mais de segurança sobre o que desenvolver. Lógico, a partir daí a gente vai desenhar experimentos para testar nossas hipóteses e fazer todo o processo de experimentação que antecede o desenvolvimento de uma feature idealmente. Mas fazendo esse processo de transformar o dado em um insight acionável já nos ajuda a economizar um pouquinho do tanto que a gente vai dar tiro no escuro nesse contexto. E aí, por fim, tendo esses insights acionáveis em nãos chega o momento te apoiar a tomada de decisão. De novo, nem sempre somos nós mesmo que vamos tomar as decisões, mas o que a gente precisa fazer é apresentar os nossos insights para os stakeholders de forma sintetizada e que seja facilmente compreensível, seja isso da maneira como for mais apropriado no contexto, uma apresentação de slide, um mural, (inint) [00:11:11], isso vai variar muito de organização para organização, e também apontar as conexões significativas que esses insights que a gente está trazendo tenham com a estratégia da organização e do produto, além de oferecer um contexto útil que possa impactar na priorização, por exemplo. Nem sempre um insight por si só vai nos dar a resposta da decisão, mas olhando para o contexto de todo o time, ou do produto como um todo a gente vai conseguir priorizar de formas diferentes. Passei um pouquinho por um processo que pode nos ajudar a transformar esses dados de pesquisa nos insights para realmente conseguir trabalhar os resultados das nossas pesquisas, mas e novo, não é um processo fechado, é uma coisa muito orgânica que a gente vai aprendendo conforme a gente vai exercitando. A minha recomendação aqui é que usando esses princípios básicos vocês testem o que funciona para o contexto de vocês, vão inteirando e melhorando cada vez mais esse processo para que a gente consiga tomar decisões cada vez mais acertadas nos nossos produtos.

Descrição

Como podemos transformar dados em insights? Como organizar informações e lidar com o processo de soluções digitais, desde a pesquisa até o desenvolvimento? No Enzimas de hoje, convidamos a Capitã do Chapter de Design e Designer de Serviço e UX Strategy Sofia Orisini para falar sobre o assunto. Dá o play!

Quer conversar com Os Agilistas? É só mandar sua dúvida/sugestão para @osagilistas no Instagram ou pelo e-mail osagilistas@dtidigital.com.br que nós responderemos em um de nossos conteúdos!

See omnystudio.com/listener for privacy information.