Bate-papo onde Huxley Dias abordou um processo básico que você e sua equipe precisam saber para começar a fazer experimentos em design e produto.
No dia 01/09/2020 o professor do nosso curso de UX Metrics, o Huxley Dias (Design Manager na Loft), fez um bate papo aberto ao público através do Zoom para compartilhar sua experiência e suas dicas sobre o processo básico que as equipes precisam saber para começar a fazer experimentos em design e produto dentro das empresas. Como de costume, o bate-papo ficou registrado no nosso canal do Youtube, e além do vídeo você também pode ler a descrição da conversa inteira logo abaixo. Então, faça bom proveito 🙂
[Transcrição da fala de Huxley Dias]
Isso aí pessoal, então vamos lá. Boa noite todo mundo, mais uma vez muito obrigado por comparecerem, espero que esse seja um bom momento que a gente vai compartilhar juntos, vai ser uma conversa bem rapidinha. Como o próprio tema diz, é o básico que a gente precisa saber para fazer, iniciar com experimentação. Vou mostrar para vocês, trazer um processo também, e aí no final a gente pode bater um papo e tirar algumas dúvidas, vai ser muito mais uma conversa do que simplesmente só trazer uma série de conteúdos aqui. Bom, vou compartilhar minha tela aqui. Podem ir deixando perguntas no chat, tá, galera? Vai comentando no chat também, acho que vai ser ótimo ter a interação de todos vocês aqui… Pronto, vamos ver… Boa, então me confirmem aí se vocês estão vendo a minha tela, pode dar um “ok” no chat ou dar um “joinha” aqui na tela no Zoom mesmo. Conseguem ver? Maravilha. Vários “joinhas” na tela, é muito legal, vocês não tem nem noção, ver os “joinhas” na tela (risos). Vamos lá. Depois eu vou querer ouvir um pouco de vocês aí também. Quem quiser abrir a câmera aí também para eu ficar vendo vocês enquanto isso, eu estou vendo vocês aqui na tela lateral também, vai ser legal também captar um pouco das expressões de vocês. Beleza? Então prometo que eu vou tentar ser breve aqui. Vamos começar. Mais uma vez, obrigado a todo mundo que se dispôs a se juntar a nós, nesse momento.
Então a ideia aqui é o básico que nós precisamos saber para começar a fazer experimentação, esse foi o nosso objetivo da conversa aqui, para a gente começar a trabalhar com hipóteses, fazer validação de hipóteses, e eu trouxe para vocês aqui um conteúdo bem simples, bem mastigadinho, que a proposta é mostrar algo para vocês e vocês terem a opção de adaptar para o dia-a-dia de vocês também. Beleza? Então olha só: isso aqui é uma conversa muito sobre contexto, processo, comunicação, execução e aprendizados. Eu acho que o que vai ficar muito externalizado para vocês nesse papo de hoje é sobre o processo, tá bom? Todos esses outros pontos dependem única e exclusivamente de você, do seu contexto, da sua equipe, do produto que você trabalha, e vocês vão ter que trabalhar isso internamente, então só você consegue ter profundidade e contexto da situação em que você está inserido. Trabalhar comunicação é um grande desafio que todos nós temos, mas fica aí essa dica, não precisa fazer sozinho, pode pedir ajuda. Capacidade de execução também é uma coisa que é uma característica bem ali do time, ou de uma pessoa que está em um time mais enxuto e acaba fazendo as coisas sozinha, seja você um UX, seja um PM, ou você mesmo quer executar algumas coisas, também depende muito de você. Agora, o resultado desses experimentos que trazem muitos aprendizados para todo mundo, é super a consequência positiva disso tudo. Quando eu falo “aprendizados”, a gente aprende coisas que dão certo e coisas que dão errado, e é super normal. Beleza?
Então, como eu disse, a gente vai focar aqui no processo. Por que que eu sempre gosto de trazer processo para algumas das coisas? O processo garante uma certa coerência e escalabilidade em tudo que você vai fazer. Tem uma frase de um escritor que escreveu um livro chamado “Check List” que fala uma coisa que me marcou bastante, ele já… Há bastante tempo, em que ele fala que “a maioria dos erros são cometidos não por falta de conhecimento, mas por negligenciamento de processos”. Esse autor é um médico cirurgião que adotou um processo de check list, nada mais que check list, é um passo a passo do que se fazer quando você recebe uma vítima de um acidente grave no hospital, e com isso ele conseguiu reduzir em 80% a taxa de infecção hospitalar, só fazendo a equipe dele seguir essas check lists, e ele teve uma série de aprendizados com isso, ele ganhou prêmio da Organização Mundial da Saúde… Depois, não satisfeito, ele foi fazer check lists na área de construção civil, aviação civil, e em todos eles ele foi bem sucedido, então está aí um pouco do meu apreço por processos — não processos que burocratizam e engessam as coisas, mas o mínimo processo é o que garante que você vai conseguir fazer as coisas de forma repetitiva, que você vai conseguir repetir aquilo outras vezes e não ser uma iniciativa pontual, super desconectada com o restante do seu contexto de trabalho e dia-a-dia.
Quando eu falo de processos, tem alguns que são super conhecidos, esse primeiro aqui é o processo do… O Tim Brown trouxe essa ideia, do Circular Design, é um processo cíclico, onde você vai incrementando ali, fazendo pequenas descobertas, fazendo release e aprendendo com isso, não é um modelo que está muito longe do que nós conhecemos, que é o Lean Startup, também é um processinho de construção, aprendizado e a gente segue nesse ciclo, e a gente tem o tão, tão já conhecido de longa data, que é o PDCA, que é um método também de processo cíclico onde você faz, planeja, verifica e toma ações a partir disso, então não é novidade. De todos esses processos, tem um que é super recente e que eu gosto bastante que traz bastante essa ideia de experimentação, que é o processo de Growth, ou Growth Model, que é esse especificamente é da Reforge, está aqui do lado os créditos, eles trazem muito essa questão da equipe ao redor, e você tem o modelo de Growth, que eles chamam de modelo de crescimento, depende da sua empresa, do seu contexto. Tem a questão de como o seu usuário consome, se relaciona com o seu produto ou serviço, e para você aprender sobre esse contexto e melhorar a sua experiência, melhorar os objetivos da empresa, você vai fazendo uma série de experimentos e vai aprendendo de forma incremental. Então, de forma resumida, fazer esses experimentos é muito sobre eu ter aprendizados rápidos, reduzir riscos, não fazer grandes investimentos de tempo, esforço e dinheiro em coisas que não vão dar certo, eu consigo ir mitigando e ir reduzindo a minha margem de dúvida sobre alguma coisa que eu estou tentando entregar para o meu usuário no final do dia.
E aí, pensando no que é o nosso contexto dessa conversa, como que eu consigo tangibilizar isso em um processo que faça mais sentido para o meu dia-a-dia? Beleza? Então é isso que a gente vai pegar agora, eu vou trazer aqui o processo linear de forma geral e depois eu vou falar o que que é importante, o que que são pontos de atenção em cada uma dessas etapas, beleza? Mais uma vez, entenda que esse processo é uma coisa que eu adoto com os times que a gente está atuando, funciona para a gente, pode não fazer sentido alguma etapa ou outra para você, você pode ficar totalmente livre para adaptar, não estou dizendo que essa é a verdade absoluta! É só um processo para dar ideia de como vocês podem começar. Então a primeira coisa é o alinhamento de objetivos, é muito importante, quando você fala de experimentação, e que você cria na sua cabeça a ideia da experimentação, abre procedente para você experimentar qualquer coisa, certo? Qualquer coisa que vier na sua cabeça. A empresa começa a saber que começou a crescer uma cultura de experimentação na empresa e eles querem testar tudo agora, acham legal e querem testar tudo, então… Estar sempre alinhado e olhando para o objetivo garante, e quando você chegar principalmente na fase de priorização, que eu vou falar em breve, você só vai priorizar o que tem a ver com o seu objetivo, e o seu objetivo pode ser um objetivo momentâneo, pode ser um quarter, pode ser um objetivo geral da empresa, pode ser um objetivo específico de uma feature de um produto, é bom estar alinhado com o objetivo. Daí você vem com a fase de investigação, o que que eu considero como investigação? Toda aquela análise de dados que você já tem, das suas ferramentas de web analytics, dados que você tem de contatos com o usuário, NPS, avaliação, central de atendimento, qualquer informação de pesquisa quantitativa ou qualitativa, tudo que você já conhece do seu usuário está aqui nesse grupo. E aí você vai vir com uma fase de ideação, onde você vai chover hipóteses aqui, pode ser muito daquela ideia que a gente faz do duplo diamante, “divergir, convergir, divergir…”, aqui é a hora de divergir, você pode divergir bastante porque na hora de priorizar você vai convergir novamente, ver o que que faz sentido ou não, e aí você mais uma vez faz aquela amarração, vou priorizar o que tem a ver com o meu objetivo, e o que estiver muito longe disso… Não é que eu não posso ter ideias nesse sentido, mas dificilmente vai passar no seu processo de priorização, dificilmente vão ser as primeiras grandes apostas que você vai testar. Depois vem a fase de design, e aí não se preocupem, galera, eu estou passando um pouco rápido por essas fases porque eu vou voltar explicando cada uma delas, então depois a gente volta para a fase de design aqui, que é você desenhar, exatamente, o experimento que vai viabilizar sua hipótese, para você testar sua hipótese, e eu acho muito importante a gente ter uma camada de alinhamento e sincronização, principalmente quem trabalha em empresas grandes, com times grandes, com um monte de pessoas… Como que você vai testar coisas, vai botar hipóteses no ar sem comunicar às pessoas? Você pode assustar uma pessoa, você pode causar uma série de confusões, você pode entrar em uma thread ou no meio de uma jornada de comunicação de outra pessoa, então precisa de muita sincronização aqui. E depois que você rodou o seu experimento você vai analisar os seus aprendizados, e esses aprendizados você vai documentar o que foi aprendido ali. Aprendi coisas que funcionam? Beleza. Aprendi coisas que não funcionam? Também é um aprendizado. Mas assim, vamos olhar o que exatamente acontece em cada uma dessas etapas, para a gente não ficar nessa camada mais lúdica ou tanto quanto aspiracional. O que é importante vocês terem em mente? Isso de uma forma geral, e vocês provavelmente vão descobrir no seu dia-a-dia, no seu contexto, que tem outras coisas que são pontos de atenção em cada uma dessas etapas.
Quando eu estou falando de alinhamento de objetivos, tem que estar muito alinhado com a sua equipe, seja a equipe micro, a que está mais perto de você no dia-a-dia, ou a equipe que está mais em um nível gerencial ou estratégico, mas tem que estar alinhado. Eu deixei só o “OKR” aqui como exemplo, muitas empresas hoje usam OKR como forma de alinhar os objetivos da empresa, e que são, sabemos que os OKRs são temporários, eles são voláteis, eles mudam, geralmente usam-se quarters, a cada quarter você muda o seu OKR, mas tem empresa que não trabalha com OKR que vai funcionar do mesmo jeito, você só tem que ter um repositório de objetivos muito claro para você seguir. Quando eu falo de investigação, eu estou falando de dados qualitativos, quantitativos, em olhar para o produto que você já tem, produto ou serviço, as features que ele já tem, olhar o que você já conhece sobre o usuário, você tem personas? Você tem um repositório de feedbacks tipo NPS, CSAT, comentários nas stores? O que é que você já sabe? Tem estudos de mercado de usuários que não são exatamente seus clientes ainda, mas são potenciais? É olhar para tudo isso. Quando chego aqui em ideação, basicamente olhando qual é o meu objetivo nesse momento e você vai precisar fechar um escopo, por quê? É muito comum em uma sessão de ideação você perder o foco, ou por ter muita coisa para atacar para você sair com coisas muito pulverizadas e não conseguir ter um grupo de hipóteses, de ideias de hipóteses que se conectam uma com a outras ou que a cada vez que você testar uma, uma vai te dar uma resposta, e quando você testar outra, uma vai incrementando, ela vai complementando, e talvez com três hipóteses testadas você vai ter uma resposta mais concisa, que uma incrementa o valor da outra. Então, um exemplo nesse caso aqui, que eu sei que é um pouco difícil de ficar imaginando assim: vamos supor, se você tem um baita de um produto, e é muito comum a gente dividir por fe ature, por tipo de persona, ou o que a gente chama de “etapa do funil” — aquisição, retenção, engajamento, referral — então vamos supor que eu quero, eu estou falando do meu tipo de persona… Eu posso ter clientes B2B, B2C, então eu estou falando do meu cliente B2C na fase de aquisição. Então quando você for trazer uma dinâmica de ideação ou pedir às pessoas para colaborarem com ideias para essa hipótese, seja mais específico, porque se não, a pessoa pode dar ideias sobre os clientes B2B e B2C misturados, falando de todas as fases do funil ou falando de todas as jornadas, têm produtos e têm equipes que são divididos por etapas da jornada da experiência do usuário… Então tenta ter foco, ainda mais se você estiver começando, senão você vai ter uma série de opções e vai acabar tendo coisas que não se complementam. Beleza? Quando eu falo de priorização, aqui você pode usar o framework de priorização que fizer mais sentido para você, para a sua equipe, não tem um padrão. Muita gente usa Matriz Esforço/Impacto, tem gente que usa SWOT, tem gente que usa ICE, tem gente que usa RICE… A que for mais adequada. Você precisa priorizar o que fizer sentido para o ritmo e o que a sua equipe já estiver acostumada a trabalhar e fizer mais sentido com o objetivo que você precisa naquele momento, você precisa priorizar, porque senão, tudo vai acabar passando ali, e aqui tem um exercício muito grande de você, na hora de priorizar, voltar e olhar para o objetivo! O objetivo aqui envolve o objetivo da empresa naquele momento, qual que é o core business da empresa, para você não querer testar uma coisa que não tem nada a ver com o core business, que você pode testar depois mas nunca vai ser implementado, o que que entrega valor para o usuário… Então isso aqui é um dever de casa que só quem está imerso no business do negócio vai conseguir fazer bem. Quando eu falo da etapa de design, o que que é isso? O que é fazer o design de um experimento? Pra fazer, você tem diferentes tipos de experimento, tem experimento que você faz em duas horas, tem que você gasta um dia para desenhar ele, e tem experimento que talvez você vai demorar uma semana, por quê? Vou pegar um exemplo bem simples, e assim, não acho que é um mega experimento que agrega valor e que descobre coisas mirabolantes, mas só para usar como exemplo básico: você pode querer trocar a cor de um botão, através de uma interface web que você consegue fazer isso em uma hora de trabalho, configurando ferramentas você consegue fazer isso, mas pode ser que você queira trocar o Copy e o direcionamento de uma jornada, ao invés de ir por um caminho você testar um caminho diferente para ver se comunica melhor, se performa melhor, e aí talvez você já vá gastar um pouco mais de tempo, tem que prototipar uma tela… Então quando eu estou falando de design, é o que que você precisa. Eu vou precisar de gente de Copy? de UX Writing? Vou precisar de UI/UX? Vou precisar usar o meu Design System para ter velocidade de criar uma landing page talvez, para testar algo? E se eu tenho uma hipótese que eu possa viabilizar através daquelas ferramentas de formulário? Vou ter que codar alguma coisa? Meu experimento é um nível de codar? E se você precisa separar sua base, que não é uma base randômica, é uma base identificada, você vai precisar do seu pessoal de Data Analytics para separar o grupo A e o grupo B? O grupo de controle e o grupo de teste? Então a parte do design é para vocês concentrarem e dar detalhes da sua hipótese, o que que você precisa para viabilizar ela. Beleza? E aqui tem aquela parte de sincronizar os times que eu comentei, é você falar com as pessoas “olha, nós temos aqui esses experimentos que vão entrar no ar nesse dia, pretendemos que eles fiquem no ar durante tanto tempo…”, às vezes você vai ter que disputar um calendário com outras pessoas, então pensa, se você precisa viabilizar um experimento que para chegar até os usuários, você expor aquela sua hipótese para os usuários vai ter que comunicar com ele via push notification, ou via e-mail, você vai ter que falar com o pessoal de comunicação, ou de réguas de comunicação, entrar no calendário deles, esses canais são super disputados, quase todo mundo quer usar o canal de push notification, de e-mail… Você vai ter que achar uma brecha ali! Precisa de muito alinhamento. Como é que eu não vou assustar uma pessoa quando ela estiver navegando e ver que o fluxo mudou? Ela vai ativar o suporte e dizer “ei, tem um erro no fluxo!”, e não, é a equipe que está testando… Então aqui cada um vai ter o seu cenário particular. O que é importante também nesse tempo de sincronização? Será que não tem outros times trabalhando em coisas semelhantes ao que eu quero testar? Ou será que o meu teste não vai ajudar outros times que, se eu não fizesse a sincronização, nem ficariam sabendo? Então isso aqui é muito importante. E mais uma vez, pensem na realidade de vocês, como é que isso se encaixa e como se aplica, eu tenho certeza que vocês já vão pensar e prever cenários em que pode isso acontecer. Quando eu rodei o meu experimento eu vou olhar qual foi o resultado dele, então vou olhar para as minhas métricas quantitativas, qualitativas, vou ver se eu recebi feedbacks, qual que foi a adoção daquela funcionalidade que eu entreguei para o meu usuário, qual que é o potencial que aquilo tem, então eu penso… Isso é uma coisinha bem básica, você pode… Quem não for muito da parte técnica ou numérica pode pedir ajuda para o pessoal de Data Analytics ou algo do tipo. É assim: “se eu expus o meu experimento para 5% da minha base e eu tive isso, na minha base eu tenho um total de 50.000 usuários, se eu expor para todo mundo, qual que é o meu resultado potencial?”, então essa é uma regrinha de três, super simples de fazer, que é algo que você pode considerar na hora da sua análise. Aí aqui tem uma parte interessante de documentar a entrega, eu vou documentar o aprendizado, vocês têm que reverberar o que que vocês aprenderam com isso para toda a empresa, mais uma vez, seja um sucesso, seja um fracasso, é um aprendizado. Então, se foi algo que deu super certo, você vão ter que decidir se é algo que vira um produto, vira uma feature ou não, e o que que precisa para viabilizar isso, então tem que documentar, “olha, testamos essa coisa a partir dessa hipótese, com esse grupo de usuários, por esse período, medimos através disso e tivemos esse resultado aqui”, e aí você vai conseguir dar um insumo para o time que for construir aquilo de fato começar a dar os primeiros passos, porque nem sempre o time que testa é o time que vai construir a solução final. Beleza? Sem contar o time framing, o tempo de uma etapa para a outra aqui. Então você concluiu o experimento e teve o aprendizado, pode ser que a solução definitiva que vai para o ar só vai aparecer daqui a um mês, dois meses… Então se você não tiver um documento sólido sobre aquilo, pode se perder no tempo. Beleza?
Onde que métricas aparecem nisso aqui? Eu acho que já talvez tenha até ficado bastante óbvio para todo mundo, então na fase de investigação principalmente vocês podem usar bastante dados, não só qualitativos, quantitativos e de N formas e N plataformas, e também na parte de análises, é super importante vocês terem esse radar que nesses dois pontos de contato vocês vão ter essa disciplina muito forte, e eu acho que é uma excelente oportunidade você botar a prova, usar o que vocês aprenderam de métricas até aqui.
Bom, a provocação que eu trago aqui para vocês, como vocês poderiam fazer para isso funcionar no seu contexto? Então mais uma vez, pedindo para vocês interagirem com a gente também, vai deixando aí no chat, faz sentido para vocês? Sim? Não? Você vê que tem aplicação no seu dia-a-dia, no seu produto? “Não precisa adaptar/Eu acho que sim/Eu acho que não/Eu mudaria isso/Eu mudaria aquilo/Acrescentaria isso ou aquilo outro”… Vamos fomentar essa discussão aí, eu acho que a gente pode ter uma troca bastante interessante. E aí quando eu falo de processo e cultura, tem duas coisas que a gente vai ter que trabalhar aqui, o processo bem definido, talvez eu vou precisar de uma série de ferramentas para suportar isso, e tem que ter as pessoas que puxam, você pode identificar quem são os parceiros dentro da empresa que vai te ajudar a manter isso vivo, quem puxaria isso junto com você, qual que é o ciclo de cadência que eu tenho que comunicar, fazer treinamentos, apresentações dos resultados, pensem nisso também. Então, agora que a gente tem uma visão geral do experimento, qual é a anatomia básica de uma boa hipótese? Isso aqui, talvez quem já está estudando essas coisas de experimentação ou já deu uma zapeada por aí ou vai continuar estudando, vocês vão ver que isso vai se repetir para vocês. Como que a gente estrutura uma boa hipótese? Ela sempre vai ter esse conjunto de informação, “com base em”, onde você vai dizer com base em que você nasceu essa hipótese, “nós acreditamos que irá mudar/impactar em quê/o quê” e “nós vamos medir o resultado isso para saber se funcionou ou não através de qual métrica?”. Então, só como exemplo aqui, não exatamente um exemplo direto, mas com base nas informações da pesquisa qualitativa, com base no feedback dos usuários no NPS ou no CSAT, com base em comentários na loja de aplicativos, com dados que eu vi no meu Google Analytics, Mixpanel ou Amplitude, da etapa X do Funil… Seja lá o que for, você precisa embasar isso aqui. Acreditamos que o quê? Talvez o número de agendamentos possa aumentar. Eu preciso sempre definir “aumentar em quantos %”? “Aumentar em 10%”, “15%”? A não ser que você já tenha um histórico consolidado de outros experimentos da mesma natureza, que vocè tenha uma ideia do baseline de mudança, talvez você possa arriscar dizer “olha, eu acho que vai mudar 2%, 10%…”, mas se você não sabe não tem problema nenhum assumir que você não sabe o quanto isso vai mudar, até porque isso é uma hipótese, eu não sei se é verdade ou se é mentira, então nem sempre você vai precisar colocar o numérico no seu embasamento da hipótese, isso aqui acaba sendo uma pressão em cima de algumas pessoas, mas se você não sabe você não precisa colocar, por isso que eu deixei aqui as interrogações. E nós vamos medir através de quê? Qual é a minha fonte da verdade, que eu digo se deu certo ou deu errado? Então nós vamos medir através do número de agendamentos no período. Então está clara aqui a anatomia da hipótese, e daqui você enriquecer a sua hipótese com uma série de coisas, trazer os relatórios que chegaram até ali, trazer o tipo de interface que você quer modificar, quais são os documentos que você vai precisar, tudo aquilo que eu falei da parte de design. O que que eu vou precisar? Eu vou precisar de Copy, eu vou precisar da base de dados separada, vou precisar de um UI/UX para viabilizar, preciso de um DEV… Então você pode enriquecer a documentação.
Vamos falar então aqui, esse é o último tópico desse conjunto de dicas, algumas ferramentas que eu tenho usado nos últimos anos e que têm me ajudado bastante. Mais uma vez: eu acho que o mais importante é você estabelecer um processo que faça sentido, tentar trabalhar pela cultura, comunicar e tentar trazer as pessoas para junto, comprarem a ideia, mas algumas ferramentas vão facilitar você a fazer isso. Então a primeira que eu queria mostrar para vocês é essa daqui que se chama GROWS. Essa ferramenta, GROWS — depois eu posso escrever aqui no chat, ou se vocês escreverem no Google “GROWS”, da Growth Tribe — é uma ferramentinha que vai ser o seu repositório de ideias, e dentro desse repositório de ideias vocês podem classificar se ela é uma ideia de aquisição, de retenção, se está associada à feature X ou Y, é da persona A ou da persona B… Está aí um repositório, e depois você vai conseguir fazer um score de classificação, que é a parte de você priorizar qual hipótese você testa primeiro, e os resultados… Também vai ficar um “backlogzinho” de lições aprendidas. Nessa mesma linha, e um pouco mais completa, tem essa outra ferramenta que chama Experiments, — o Jefté mandou já o link no chat da GROWS, quem quiser acessar… A GROWS tem uma entrada gratuita, quem quiser aí já começar a fazer alguns testes, navegar e ver como que é, consegue entrar gratuitamente nela. Essa segunda que eu estou mostrando aqui é a ferramenta que chama Experiments, no passado recente ela se chamou NorthStar. Eu uso ela bastante, eu usei nos outros times que eu trabalhei, gosto bastante porque ela tem o conjunto de funcionalidades que eu preciso, e ela sai do mesmo princípio: eu vou cadastrar um objetivo, para esses objetivos eu vou cadastrar hipóteses, vou classificar em onde que essa hipótese está, se ela está em alguma etapa do funil, se ela está associada a algum tipo de persona, se está associada a um pedaço da jornada, eu vou poder priorizar essas hipóteses, então esses números que você está vendo do lado de cada uma das hipóteses é a classificação, ela tem dois métodos de priorização que você escolhe na hora de fazer o setup da ferramenta, eu em particular gosto de usar o método ICE, que é de impacto, confiança e facilidade, do termo em inglês, por isso que é “ICE”, e ela também vai ter aqui, como vocês podem ver na lateral aqui, ela mostra meio que um “to do list”, um backlog, quando você fala aqui “esse experimento vai entrar no ar, está pronto para análise, já tem aprendizados”, quando você diz que está pronto e que já tem aprendizados ele vem para essa seção aqui que se chama “aprendizados”, então você vai ter backlog de todos os aprendizados categorizados, filtráveis, de tudo que você experimentou na sua vida, no seu time, e todo mundo do time ou da empresa pode ir ali e acessar esse recurso para ver o que que já foi aprendido e o que que não foi. Mais uma vez o nosso personal descobridor de ferramentas já mandou o link aqui no chat também dessa ferramenta (risos) muito obrigado. É Jefté, não é? Eu espero que seja assim, Jefté. Ou então, vou (te) chamar só de Macêdo. E aqui, um outro recurso que eu queria trazer também para vocês que ela também facilita é a questão da comunicação, e aí como você faz todo mundo ficar sabendo o que você está testando, quais são os seus objetivos? Ela tem uma integração direta com o Slack, com outras ferramentas, com o Jira, com o Google Optimizer, Google Analytics, Trello, uma série de integrações, e essa aqui em específico é bem legal porque ela vai fazer um push dentro do seu Slack toda vez que um novo objetivo ou um novo experimento for cadastrado. Toda vez que um novo experimento for concluído ele também vai exibir aqui dentro, e isso facilita bastante a comunicação. Beleza, galera?
Deixa eu ver como é que está o nosso tempo… Temos 20 minutinhos de perguntas, maravilha. Então, pessoal, eu vou abrir para perguntas aqui, fiquem super à vontade, eu vou até voltar aqui o compartilhamento para que a gente possa nos ver (a partir desse momento a tela é aberta e os participantes do bate-papo aparecem, 30:48).
“Vamos ter algum exemplo de experimento?”, claro! Não pode faltar! Então a Renata já pediu um exemplo aqui, eu vou mostrar uns exemplos para vocês, mas eu já queria incentivar vocês a trazer perguntas, observações… Podem escrever aqui no chat ou, se se sentirem à vontade, pode abrir o microfone também e falar.
A Stephanie perguntou aqui “como convencer o cliente a confiar no processo?”. Olha, realmente isso eu não sei, não tenho nenhuma dica super efetiva, mas eu acho que é um trabalho, assim… De longa data, de relacionamento, de se mostrar disponível a dar referências, talvez alimentar com “olha o que que o mercado está fazendo, olha os resultados…”, tem muita coisa sobre experimentação, eu digo… Tem muito mais coisas online, coisas recentes online, eu conheço só dois livros que são voltados para essa parte de experimentação, e são literaturas, eu diria, já um tanto antigas… Mas eu acho que tem muito de relacionamento aí, e também se o cliente contratou ele deveria minimamente confiar… Eu sei que não é fácil.
Deixa eu ver aqui o que mais que a gente tem… Opa, já tem cupom de desconto aqui, da Mergo! Para o curso de UX Metrics, legal!
Vou aproveitar enquanto não tem nenhuma outra pergunta, eu vou mostrar um exemplo de um experimento que segue muito essa linha que, quem foi que perguntou… Quem perguntou foi a Renata Matos, “vamos ter um exemplo?”, sim.
“Lívia: quais são os livros? Compartilhe os nomes”, olha, os livros são os seguintes, um se chama You Should Test That, esse infelizmente não tem em português, ele é só sobre coisas que você pode testar, ele é muito focado em otimização de landing page… Eles chamavam em um passado recente de CRO — Correction Rate Optimization -, ele é muito focado em coisas transacionais, não só exatamente testes para você validar, MVP ou proposta de valor ou melhorar a experiência do usuário, ele tem um aspecto muito transacional, focado em e-commerce… “acabei de achar o link…” Mano, o Macêdo é fera! O Macêdo ou A Macêdo, eu nem sei… (Em uma das telas, abaixo da tela de Huxley, um homem branco, careca, com barba e vestindo uma camiseta preta sorri e aponta para si mesmo com as duas mãos). Ah, aqui! É o Macêdo, então! Está aqui, está do meu ladinho aqui. Perfeito, muito obrigado. E o outro, esse já tem em português, se chama Landing Page Optimization, ou ele vai ter em português “Otimização da Página de Entrada”. O autor, se eu não me engano, é o Tim Ash. Posso estar enganado com o nome do autor mas eu acho que é isso, eu tenho esse livro aqui em algum lugar mas não está ao meu alcance agora, senão eu mostrava a capa para vocês.
Mas vou aproveitar aqui, e vou mostrar um exemplo. Olha só, eu vou voltar o compartilhamento (de tela)… Eu vou passar bem rápido aqui pela parte da contextualização e eu vou focar mais no experimento em si, então olhem só, um exemplo aqui para a gente pensar, não sei se todo mundo sabe mas eu passei um tempo no time de Growth Marketing da Loggi, então a gente cuidava de uma série de coisas lá, que não vem ao caso agora, e eu vou contar sobre o nosso contexto, era uma plataforma de logística com três tipos de clientes, B2B, B2C e o motoqueiro ali, o entregador, a gente também estava em uma empresa de rápida e grande situação (de crescimento) e eu trabalhava no time de Growth Marketing. Então a gente usava aquela ideia de objetivos, eu vinha do objetivo, alinhava, via como é que eu posso viabilizar isso em pequenas iniciativas e pequenas tarefas. A gente tinha um objetivo de conseguir um número X de entregadores ativos, que são os motoqueiros. Então vou pular essa parte aqui… E vou direto para o “como”, aqui. Então como que nós pegamos alguns desafios que a gente tinha naquele período? E aumentar a base de motoqueiros ativos tinha muito a ver com tirar fricção do processo de aquisição, e a gente sabia de uma série de fricções. E o que que nós fizemos? Nós mapeamos toda a jornada de Onboard, e aqui nós usamos uma ferramentinha que é bastante conhecida do Design de Serviço, que chama Service Design Blueprint, e aí tem N formas de você fazer Blueprint, obviamente, eu sempre uso as ferramentas adaptadas à minha maneira, o importante é como você aplica e se ela tem utilidade. Então nós fizemos um Blueprint, que é você mapear cada fase da etapa do cadastro e onboard e identificar quais são os pontos de contato, quais são os pontos de dor, que a gente chama de fricção, quais são os gatilhos que aquilo gera, ao longo dessa jornada quais os canais de comunicação que eram ativados, ao longo dessa jornada ele recebia uma push notification? Um SMS? Um WhatsApp? Um e-mail? Identificando tudo isso, e fica identificando onde é que estava doendo mais, e para fazer isso a gente envolveu uma série de pessoas, veio PM, veio UX, Comunicação, Growth, Data, pessoal que cuida de CRM, tudo, então não existe um produto que é um produto só digital, principalmente em uma empresa com uma operação grande, tem muita gente envolvida, então está aqui a importância daquilo que eu falei do alinhamento e da comunicação. Então aqui é um exemplinho de como nós fizemos isso, aqui na parede, um Blueprint fora daqueles templates bonitinhos da internet é nada mais do que uma parede feia com Post It, mas só para vocês entenderem, aqui são as fases “macro”, aqui do lado tem qual é a interface que ele está tendo contato nesse momento, quais são as dores que ele tem, quais os canais que ele tem contato, e aqui o backstage, o que que ativa no nosso sistema, é uma coisa que tem mais a ver com o nossos sistema, o usuário não vê, mas que a gente usava como insumo. Alguém falou alguma coisa aí? Só para eu concluir aqui, depois a gente volta às perguntas. Beleza, então isso derivou uma série de hipóteses, mesmo já tendo bastante clareza dos pontos de dúvida a gente lançou algumas hipóteses, então a primeira delas foi refazer o cadastro em um typeform, por exemplo. Será que o cadastro no typeform tem menos fricção do que o cadastro nativo no aplicativo? E a segunda hipótese é: será que teremos que reconstruir um cadastro nativo? E aí tem uma série de desdobramentos. Esse é um ponto. E eu queria trazer aqui, agora com um pouco menos de detalhes, a gente tinha uma outra hipótese também, na Loggi, que era muito pautada sobre a parte de aquisição de motoqueiros também, e quando eu falo de experimentação, é muito sobre você cortar etapas, reduzir custos, reduzir tempo, e ter uma resposta mais rápido para aquela resposta te dar mais confiança para dar o próximo passo ou não. Olha esse exemplo aqui, que legal: a gente tinha uma hipótese de se vídeos convertiam mais ou não para trazer mais usuários para a plataforma, para se cadastrarem, e toda vez que a gente tocava no assunto “vídeo” vinha à tona a questão de “gente, mas eu preciso contratar uma produtora, fazer os textos com a comunicação, aprovar com o Legal, cadastrar esse fornecedor na área de compras, e eu acho que vai demorar pelo menos um mês ou dois para a gente ter o primeiro vídeo, para a gente saber se converte mais ou não”, eu falei “gente! Mas eu acho que a ideia vai muito para o lado de te dar uma liberdade e velocidade. Não vale o esforço, o trabalho e a dor de fazer isso tudo, de ter que gastar tempo, contratar uma mega produtora, que deve ser super caro, passar pelo processo de aprovação de compras, cadastrar fornecedor, etc etc… Vamos ver se funciona primeiro e depois a gente faz isso?”, então primeiro nós fizemos um vídeo, não exatamente um vídeo amador, mas um vídeo de baixo custo, com um produtor independente, que sozinho ele ajudou a montar o roteiro, a filmar, a editar… Aqui sou eu segurando o tripé de luz, dá pra perceber que fazer experimentação não é só a ver com a parte digital, às vezes você tem que ir lá e botar a cara à tapa, e nós mesmos gravamos. Esse aqui é um designer da equipe (referindo-se ao rapaz vestido de motoqueiro na imagem), que foi o ator, e depois que a gente tinha o resultado pronto a gente foi lá com o chefe de operação, pediu ajuda dele para aprovar com o Legal para ver se era ok veicular aquela peça que era o experimento com o rosto de um funcionário, de um colaborador, e se a gente não falou nada que não era permitido no roteiro e assim a gente conseguiu, e sim! A gente teve melhores resultados, que obviamente eu não posso falar aqui sobre esses números exatos, mas a gente teve resultados que… A gente já tinha um bom feeling de que vídeo convertia mais, porque a gente já estava olhando todos os outros players fazendo, só que a gente não tinha, então dessa forma, em dois dias a gente conseguiu ter o vídeo, e com uma semana a gente deixou a campanha rodando e já conseguiu coletar o resultado esperado. Então é muito sobre isso, galera, de como que eu consigo alinhar o meu objetivo daquele momento, em que é o meu contexto, meu negócio, meu produto, seguir um processinho, repetir, reduzir etapas, fricções e tudo mais, e ter resultados rápidos a partir de experimentação. Beleza? Deixa eu ver se tem mais alguma coisa…
[Fim da transcrição da fala de Huxley Dias]
Início do bate-papo com outros participantes
Ana: Que métricas vocês estavam olhando em relação a isso? A esse case.
Huxley: Desculpa, fala de novo?
Ana: Ah, não, eu queria saber, vocês fizeram todo o Blueprint e vocês queriam ver se o vídeo convertia. Que métricas vocês utilizaram para saber que realmente estava convertendo?
Huxley: Ah, não, vocês entenderam que são duas coisas diferentes? O Blueprint era sobre o cadastro e o Onboard, o vídeo era sobre campanhas de aquisição, só para a gente primeiro fazer essa distinção.
Ana: Sim, sim, mas um processo acaba levando ao outro, não é? Você faz o planejamento através desse Blueprint e aí você vai para as ações, que no caso seria a aquisição. Mas está certo.
Huxley: Não exatamente, o Blueprint ali não era um planejamento, ele era um mapeamento para a gente entender onde é que eram os principais pontos de dor e os pontos de contato que a gente poderia atuar em cima dele, aí a partir dali a gente define quais são as hipóteses que eu vou atacar, tipo, é a hipótese que se eu tirar a validação do número do celular da pessoa eu vou conseguir fazer ele avançar mais rápido e depois eu peço para ele validar o número dele depois que ele já chegar em uma etapa mais avançada? Mais engajado com a plataforma? Uma outra hipótese: será que se eu tirar por exemplo o input do… Era uma etapa supercrítica para a gente, será que se eu não pedir nesse momento o input do — lá para você ser entregador, você tinha que ter um CNPJ, mesmo que fosse um MEI — será que se eu pedir o MEI depois e não complicar isso ele vai avançar mais etapas? Então estou dando hipóteses aleatórias, a gente nem testou essa hipótese, não era viável para a gente, a gente já conhecia, mas eu só estou te dando exemplos. Uma vez que a gente mapeia todas as etapas e o que que é ponto de fricção, eu começo a lançar hipóteses, e aí quando chega na parte de priorização eu olho muito para o meu contexto, que é aquilo que eu falei, por que eu disse que tirar o pedido do CNPJ é uma hipótese que a gente não quer testar? Porque não fazia sentido para o nosso negócio. Sem CNPJ ele não conseguiria usar a plataforma, então mesmo que fosse um super ponto de dor eu não poderia tirar aquilo, então é uma hipótese já que cai por terra.
Ana: Está certo, obrigada.
Huxley: De nada, Ana, obrigada aí pela pergunta. Deixa eu ver o que tem aqui no chat…
Sara: Huxley, desculpa, eu posso perguntar uma coisa? Dá tempo?
Huxley: Pode sim!
Sara: Tudo bem, gente? Boa noite! Huxley, eu queria perguntar um negócio. Eu trabalho com Growth também, e às vezes eu tenho uma curiosidade de pedir um dashboard para ficar vendo métricas em tempo real, mas eu não sei se isso é muito útil para mim como designer. Você acha que é importante a gente ter essas métricas ao vivo ou é melhor a gente fazer essa experimentação e comunicação com o time para pedir essas métricas depois e discutir todos juntos?
Huxley: É, Sara, tem uma série de poréns aí no seu contexto que eu vou tentar desmembrar. A questão de ver métricas ao vivo, que nós chamamos de Real Time, a gente só faz a avaliação se é necessária mesmo, se você está vendo alguma coisa que você quer muito… Ativo-reativo emergencial, alguma coisa que mudou e tem que atuar automaticamente em cima e se eu tenho autonomia para fazer isso. Então, esse tipo de métricas Real Time, é muito mais usado pelo pessoal de marketing mesmo, tipo, é uma campanha que está performando mal? Desliga! (Nesse momento são ouvidos ruídos de um dos microfones) Vou pedir à Cristiane para desligar o microfone dela um pouquinho, deixa eu desligar aqui, deixa eu ver se eu consigo “mutar”… Aí, beleza. Só porque estava fazendo um barulhinho. Se quiser falar depois, Cristiane, pode abrir à vontade. Então, para o marketing, se você pilota as campanhas de marketing, você tem autonomia, então faz sentido você ter métricas em Real Time, aí esse é o ponto do Real Time, se não, se é uma coisa muito mais de deixar acumular um grupo de dados e analisar depois, não precisa ser necessariamente em Real Time, (pode ser) de dois em dois, ou três dias, ou uma semana, depende do ciclo e velocidade do produto. Sobre a questão de se é melhor as pessoas compilarem e depois trazerem para a gente, tem muito a questão da confiança. A plataforma que coleta o dado é confiável? A plataforma em que você visualiza o dado também é confiável? As pessoas conseguem te dar clareza de onde veio e como foi tratado esse dado antes de só te levar uma informação compilada? Esse é um dos grandes mitos que a gente tem, de receber o dado totalmente pronto, manipulado, e fica “puta, será que eu confio ou não confio nessa informação?”, então é complexo. O que eu tenho visto é o que a gente chama de uma democratização, de oferecer plataformas mais acessíveis para acompanhar dados e não aquelas ferramentas de dashboard super complexas, que você tem que… Ou, se você não tiver o conhecimento técnico, você tem que fazer o SQL, ou montar o próprio dashboard, então tem algumas coisas que são mais fáceis. As ferramentas que nós chamamos de Product Analytics, Web Analytics, elas têm interfaces mais simples na maioria das vezes, mas depende de uma boa implementação também. Tem outras ferramentas que já lêem dados de bancos de dado consolidado e etc que também têm se mostrado super amigáveis, então tem o Data Studio, o Looker é mais ou menos… Não é o mais amigável de todos mas é legalzinho… O que eu mais gosto desse conjunto, que é até open source, é o Metabase. O Metabase é super tranquilo, ele é baseado em questões ali, você faz uma pergunta, “quantos novos cadastros…”, aí você aplica o filtro na fase pendente, e aí você consegue escolher o modelo do gráfico, então tem esse conjunto de situações aí. (Huxley faz um sinal de joinha com a mão).
Huxley: Mais? Quem mais vai perguntar? Temos três minutinhos aí, hein. Gente, pode perguntar à vontade, não tem pergunta certa, não tem errada… Então agora eu queria perguntar para vocês, o que vocês acharam do conteúdo? Ajudou vocês a ter uma clareza? Eu vou mandar o slide para vocês, então vai me dando feedback aqui no chat, o que que vocês acharam… “Qual o nome desta última ferramenta?” Metabase.
Bruno: Huxley, eu tenho uma pergunta.
Huxley: Pode perguntar.
Bruno: Eu queria saber… Acho que devem ter vários níveis de maturidade para Growth, e aí, como é que você enxerga isso hoje? Tipo assim, a gente poderia criar uma cultura de experimentação dentro de uma squad, por exemplo, ou isso já seria uma coisa fora do ambiente squad, mais cross na empresa? Como é que você enxerga esses diferentes níveis? Pelo final das contas, a ideia é só validar uma hipótese mais rápido, o que já seria a ideia do ágil… Mas enfim.
Huxley: Exatamente. Acho que você trouxe um bom ponto, e eu vejo hoje… Deixa só eu pegar o link aqui, só para mandar para vocês e eu volto aí, só um minutinho…
Bruno: Essa pergunta também nasceu pelo gancho que você falou, comentou aí de botar, “será que a gente deveria botar o typeform?”, e você não continuou a contar a história, você parou aí. Aí eu não sei se vocês testaram o typeform, se não testaram… Como é que foi?
Huxley: Entendi. Claro, tem alguns detalhes que eu não posso trazer aqui para vocês, eu não podia quando eu trabalhava lá, hoje eu nem trabalho mais na empresa, eu estou em outra empresa. Então realmente, nesse detalhe eu não posso entrar, mas foram hipóteses que nós criamos, consideramos, e aí eu não posso trazer muito sobre o que veio depois disso aí, até umas coisas… Estratégias do negócio e tudo mais. Vou mandar aqui o link da apresentação no chat. Mas assim, o que eu acho, Bruno, tem várias formas de fazer, eu vejo que tem gente que não é um time de experimentação, não é um time de Growth nem nada e faz experimentação no seu dia-a-dia. Às vezes é uma pessoa sozinha, é um exército de um homem só, que tem no seu DNA, no seu jeito de trabalhar, a experimentação na veia, e ele pode fazer independente. Pode ser um time inteiro, um squad inteiro, que para uma determinada situação decidiu fazer uma coisinha mais rápida, um MVP, um protótipo para experimentar, mas que o trabalho padrão desse time é construir coisas maiores, um produto com todas as fases, com todas as etapas do processo de design, do discovery, do refinamento, da prototipação, teste e tudo mais? Pode ser. E tem o cenário que tem times 100% focados em fazer experimentação, então por exemplo, lá na Loggi eu trabalhava em um time de Growth e Marketing, então a gente fazia Marketing, fazia o básico do Marketing ali, de comunicação, canais e etc, e fazia Growth em diferentes camadas, podia ser Growth para produto, podia ser testar coisas que dava escalabilidade para a companhia inteira e que não tinha nada a ver com o produto que ia para o usuário final, eram coisas para o produto interno, então tem cenários e cenários e eu não considero que tem um certo e um errado, eu acho que é o que faz sentido para o seu contexto. Eu já vi cenários que começavam com pessoas experimentando dentro de uma squad específica e depois virou um time de Growth dedicado, parou de pegar projetos tradicionais e começou a fazer só experimentação… Então tem cenários e cenários.
Bruno: Legal.
Huxley: Alguém perguntou aqui… Espera aí, espera aí, são duas perguntas? São duas perguntas… “Eu senti falta de ver um exemplo do começo ao fim, não precisa ser um caso real. Hipóteses até a confirmação ou refutação da hipótese, talvez por ser um cenário iniciante”. É, realmente eu acho que trazer um cenário detalhado aqui ia demorar bastante, para dar detalhes de todo o contexto… Eu acho que o exemplo ali do Onboard é um caso que tem bastante detalhe no meio do caminho, tem muita verificação, não caberia aqui exatamente. E não acho que… Qual que é a questão, qual que é a ideia desse papo de hoje: externalizar um processo. Que vocês possam entender, aterrissar e ver o que que funciona para o dia-a-dia de vocês. Experimentação é muito diferente em todo lugar, eu posso dar N exemplos aqui, mas se vocês não absorverem o processo, que é o mais importante, vocês não vão conseguir replicar o mesmo experimento que eu fiz em lugar nenhum, se o seu produto é diferente, cultura é diferente. Então eu focaria muito mais em tentar absorver o processo do que ter um exemplo de um experimento específico no meu contexto, que pode ser que nunca vá ter aderência com o contexto de vocês.
Um curso! (Risos) Legal! Eu acho que o Will Sertório tem um curso nesse sentido, eu só não sei se ele está executando nesse momento, mas ele tem um curso de experimentação. E assim, obviamente, pessoal, quem tiver interesse, tem N cursos. Tem, por exemplo, se você… Tem conteúdos dentro de Product Discovery que são experimentação! Talvez de uma forma mais sucinta, mas é. Eu fiz uma especialização no começo desse ano na Reforge, que é uma escola do Vale do Silício, que é uma especialização só de Growth, então lá eles falam de estratégias, de processo de experimentação… É um conteúdo super denso, são quase três meses de treinamento que pega no detalhe, então não é uma coisa que a gente vai conseguir aprender em uma hora. Então podem ficar tranquilos, que não é uma coisa assim que vai fazer muita falta, porque talvez esse seja o primeiro contato, ou é uma explanação geral, e aí quem tiver interesse vai aprofundar.
Qual é a mensagem final que eu queria deixar para vocês: primeiramente agradecer todo mundo por terem participado aqui, é sempre legal compartilhar com todo mundo. Já deixei o link do slide aqui, mais para cima o perfil da Mergo deixou um link para quem tiver interesse em fazer o curso de UX Metrics, que é o curso que eu ministro na Mergo, onde a gente ensina você a entender o básico de métricas, entender a parte mais avançada de métricas, de análise comportamental, que é o que dá uma série de insumos para vocês fazerem geração de hipóteses, então eu diria que a parte de experimentação é até um segundo passo depois de vocês entenderem métricas de produto e de experiência. Então fica aqui sempre o nosso convite, a gente já faz esse treinamento há três anos, a gente gosta bastante de trocar com a galera, quem tiver interesse, já deixaram o linkzinho aí com desconto. Se conectem aí com a Mergo e comigo no LinkedIn, e também lá no site da Punk Metrics, no punkmetrics.com eu deixo artigos — na verdade você pode ir até direto no meu Medium — eu deixo artigos lá sobre Product Analytics e tudo mais, e agora eu vou tentar transformar esse conteúdo que a gente falou aqui em um conteudozinho lá com os principais tópicos, já deixo esses links de referência… Então vou ver se consigo transformar isso em um textinho lá até o final de semana. Beleza? Mais uma vez obrigado, galera, até a próxima, e a gente se vê por aí! Demorou? Um abraço! Valeu galera!