Recentemente lançamos aqui no Convenia um MVP (Minimum Viable Product ou Mínimo Produto Viável) na nossa área de benefícios, com a principal motivação de entender se seria possível vender produtos de parceiros diretamente para os RHs das empresas, sem a necessidade de ter um intermediador (vendedor) no processo.

Mas para isso ocorrer deveríamos seguir fielmente o propósito de um MVP que é ter um produto bem feito, sem falhas, sendo uma versão mais "clean" e que resolva o problema que gostaríamos de validar, neste caso se o RH contrata ou não um benefício.

A primeira etapa foi desenhar a ideia, normalmente poderia ser feito em papel, ou em qualquer ferramenta de wireframes. Nosso time de UXs com o passar do tempo deixou de utilizar essas opções, e com a evolução do nosso design system normalmente entregam um esboço além das expectativas.

Além de pensar no MVP, o time de UXs já pensa em possíveis melhorias futuras, acrescentando outras áreas do sistema, simulando como poderia ser a evolução da área. Para o MVP, existe um alinhamento com o PO e com o time de desenvolvedores para entender o que seria viável para a primeira entrega em um curto espaço de tempo, e assim separando os principais itens para o processo de desenvolvimento.

Alinhada a expectativa entre produto, uxs e desenvolvedores, se inicia o desenvolvimento.
Neste caso específico o projeto durou um pouco menos de 8 dias trabalhados.
E o resultado foi:

Veja que o resultado foi bem mais simples do que o proposto pelos UXs em um primeiro momento.

MVP finalizado chegou a hora de ter maneiras de mensurar se o projeto foi bem sucedido ou se falhou em alguma etapa para conseguirmos atacar o problema, caso tenha.

Para esse teste específico utilizamos a dupla do barulho Tag Manager + Analytics.

Foi importante uma boa estruturação do código para conseguirmos emitir eventos por meio do Tag Manager. Veja abaixo como o call to action de visualizar informações de um benefício foi criado com um data atribute 'data-exclusive-benefit-open', nele é adicionado o nome do parceiro.

Já no Tag Manager criamos uma variável que ficaria responsável por mandar para o data layer o valor do nome do data atribute criado.

Com a variável criada criamos uma tag responsável por emitir um evento para o analytics, essa tag é a responsável por mandar junto do evento o valor da variável que criamos na etapa anterior e mais informações do usuário logado.

Feito isso só faltou criar um trigger para executar essa tag.

Seguimos esse padrão para as 3 etapas que gostaríamos de obter dados do MVP.

1 - Acesso a página de benefícios (neste caso sem a informação do parceiro)
2 - Clique o call to action
3 - Contratação do benefício

Com isso temos dados valiosos no analytics onde podemos por exemplo criar um funil de conversão e atacar possíveis problemas.

Por exemplo nesta imagem, por que apenas 5% dos usuários que acessaram a área de benefícios converteram?

E que se inicie uma nova etapa de entrevistas com os usuários, teste a/b entre outras formas de validação para identificarmos os problemas =)

E ai? Visualiza no projeto que está trabalhando alguma forma de aplicar um fúnil de conversão ou uma integração entre Tag Manager e Analytics?

Em caso de dúvidas fico a disposição =)

Além disso estamos sempre com vagas para o time de produto:
https://convenia.gupy.io

Abs