Tornando o caminho de valor visível no trial — gamificação como arquitetura de ativação, não engajamento artificial
Growth Design
Behavioral
Trial Conversion
Gamification
Activation
Contexto
69% dos usuários em período de trial nunca chegavam à tela de contratação. O produto tinha valor real — mas o caminho até esse valor era invisível para a maioria dos usuários.
Problema
Nenhum mecanismo estruturado para guiar o usuário do trial até as ações que predizem conversão. Quem chegava à tela de contratação convertia em taxas altas — o problema era que poucos chegavam.
Abordagem
Componente de progresso embutido no painel principal, com lista curada de tarefas mapeadas diretamente aos critérios de ativação. Recompensa tangível (extensão do período de trial) atrelada à conclusão de ações reais de produto.
Resultado
+500% em conversão de trial para assinatura · +55,71% em trials impactados · +120,34% em engajamento — em base isolada, antes da iniciativa ser pausada estrategicamente.
Resultados
+500%Conversão trial → assinaturaBase isolada de teste
+55,71%Trials impactadosAlcance na base
+120,34%Engajamento e usoAtividade no trial
Atuação
Fui o único designer nesta iniciativa, trabalhando com PM Luccas Trombetta, DM Maicon Andre Zanette e Tech Lead Marcos Daniel Budtinger. Minha responsabilidade cobriu o arco completo: diagnóstico do comportamento de trial, definição das tarefas a serem gamificadas, design do componente de progresso, estrutura da mecânica de recompensa e especificação de escopo para o MVP.
O trabalho incluiu decisões explícitas sobre o que não gamificar — tarefas secundárias foram excluídas da lista para evitar engajamento artificial desconectado do valor real do produto. Incluiu também navegar limitações reais do Design System: o componente de lista de tarefas foi montado como um collapse adaptado (sem versão azul e sem suporte a ilustração no DS), badges de recompensa ficaram distantes das tarefas por conta das colunas do sistema, e a visibilidade no menu azul da topbar ficou aquém do planejado — cada uma dessas restrições foi documentada e virou insumo para o plano de evolução.
Estratégia
A taxa de ativação no trial era de 0,15%. Benchmarks de ERPs SaaS indicam conversão possível entre 10–20% — uma lacuna de duas ordens de magnitude. Trials mais longos já tinham sido testados (30 dias e 7 dias): nenhuma das duas variações gerou conversão eficiente; a extensão de prazo apenas prolongou o ciclo de vendas e reduziu urgência sem criar direção.
O OKR desta iniciativa era aumentar a taxa de ativação de 0,15% para 5% durante o período de trial. Chegar aos 5% significava quintuplicar a base, sem alterar o produto central — apenas tornando o caminho de valor visível.
O diagnóstico que guiou o design foi diferente do diagnóstico padrão de “baixo engajamento”. Usuários que chegavam à tela de contratação convertiam em taxas altas. O produto não era o problema — a ausência de arquitetura de ativação era. Usuários não sabiam o que fazer para chegar ao valor; gamificação mal aplicada teria resolvido o problema errado, criando movimentação sem conversão.
O fundamento conceitual foi o Hook Model (Nir Eyal): Gatilho externo/interno → Ação → Recompensa Variável → Investimento. O objetivo não era criar entretenimento dentro do trial — era criar hábito de uso do produto nas ações que predizem retenção de longo prazo.
Processo
1. Análise de dados e benchmark Partida: taxa de ativação documentada de 0,15% contra benchmarks de ERPs de 10–20%. Histórico interno de variações de prazo (30 dias, 7 dias) sem ganho de conversão. A hipótese que emergiu: o problema não era duração de trial, era ausência de direção dentro dele. Apenas 5% dos usuários chegavam a pedir extensão de trial — a maioria abandonava sem tentar ativar.
2. Desk research + fundamento conceitual Estudo do Hook Model de Nir Eyal como estrutura para desenhar a mecânica: as quatro fases (Gatilho → Ação → Recompensa Variável → Investimento) mapeadas ao contexto de trial. O objetivo era projetar para criação de hábito, não para engajamento pontual.
3. Benchmark de gamificação em SaaS Análise de referências com gamificação eficaz: Duolingo, Grammarly, Twitch, Etsy, Vanta, Bonsai, UXcel, Mem IA. Padrões identificados: blocos de progresso em destaque na tela inicial, tarefas exibidas com clareza e objetividade, cores contrastantes para sinalização de estado.
4. Mapeamento de tarefas com Customer Success Dinâmica com CS (Luccas Trombetta definiu a lista macro) para identificar a perspectiva de primeira experiência do usuário. A lista foi progressivamente reduzida para focar no segmento de serviço — o core do trial. Cada tarefa foi mapeada ao fluxo real no produto, com identificação de gaps e dificuldades de execução. Os dois critérios de ativação centrais — emitir nota fiscal e criar uma cobrança — exigiam ações não triviais: configurar certificado digital e homologação da cidade (para NF), e abrir conta PJ na Conta Azul (para cobrança). Esse mapeamento foi determinante para a curadoria da lista final.
5. Decisão de escopo MVP com PM e DM Alinhamento com PM Luccas e DM Maicon (via Slack): escopo limitado a componente na dashboard + topbar do menu. Melhorias visuais mais profundas e integração com Appcues foram postergados para não atrasar a validação da hipótese central.
6. Definição de recompensas com Vendas Recompensas definidas em duas camadas: +3 dias de trial por tarefa completada; 10% de desconto viabilizado via redirecionamento para WhatsApp de vendas (sem automação de cupom, por velocidade). O desconto de 10% foi definido pelo diretor de vendas Ricardo Nogueira. A recompensa de extensão de trial foi escolhida por ser tangível e diretamente ligada ao produto — mais tempo para experimentar o valor real.
Diagnóstico
Pergunta: Qual é a lacuna real entre a taxa de ativação atual e o que é possível em produtos comparáveis?
O que foi feito: Levantamento da taxa de ativação interna (0,15%) e benchmarks de conversão em ERPs SaaS (10–20%). Revisão do histórico de variações de prazo de trial já testadas (30 dias e 7 dias).
Achado principal: A lacuna é de duas ordens de magnitude — não marginal. Extensões de prazo já testadas não geraram conversão; a hipótese de “tempo insuficiente” foi descartada. O problema era ausência de direção dentro do trial, não duração.
Artefato: Documentação de baseline e OKR: aumentar ativação de 0,15% para 5%.
Pergunta: Qual framework conceitual melhor descreve a mecânica que precisamos construir — e quais armadilhas ele nos ajuda a evitar?
O que foi feito: Estudo do Hook Model: mapeamento das quatro fases (Gatilho externo/interno → Ação → Recompensa Variável → Investimento) ao contexto de trial SaaS. Análise de como gamificação mal aplicada cria engajamento com tarefas arbitrárias sem impacto em conversão.
Achado principal: A fase de Investimento é o diferencial crítico: tarefas que criam dados e histórico no produto (como emitir uma nota fiscal real) aumentam o custo de abandono e predizem retenção. Gamificação que não chega à fase de Investimento é entretenimento, não ativação.
Artefato: Framework de seleção de tarefas: apenas ações que chegam à fase de Investimento entram na lista gamificada.
Pergunta: Como produtos com gamificação eficaz estruturam a apresentação de progresso e recompensas — e o que podemos adaptar para um ERP?
O que foi feito: Análise de referências: Duolingo, Grammarly, Twitch, Etsy, Vanta, Bonsai, UXcel, Mem IA. Foco em padrões de UI para progresso, hierarquia de tarefas e sinalização de recompensa.
Achado principal: Padrões consistentes entre as referências: blocos de progresso em destaque na interface inicial, tarefas exibidas com objetividade (sem copy motivacional excessivo), cores contrastantes para estado de conclusão. ERPs têm menor tolerância para elementos de UI de alta saliência — o componente precisaria ser compacto por padrão e expansível, não imersivo.
Artefato: Moodboard de benchmarks com análise de padrões aplicáveis ao contexto de ERP.
Pergunta: Quais tarefas um usuário do segmento de serviço precisa completar para experimentar valor real — e onde estão os gaps que impedem essa conclusão?
O que foi feito: Dinâmica com CS: lista macro de tarefas definida por Luccas Trombetta; refinamento pela perspectiva de primeira experiência do usuário; redução da lista para foco no segmento de serviço. Mapeamento de cada tarefa ao fluxo real no produto, com identificação de dificuldades de execução (ex: configuração de certificado digital para NF, abertura de conta PJ para cobrança).
Achado principal: Os dois critérios de ativação centrais tinham barreiras técnicas reais antes do componente de gamificação. Isso informou a decisão de não incluir essas tarefas como “simples” — e de deixar claro no componente que há etapas prévias necessárias.
Artefato: Lista curada de tarefas por segmento, com mapeamento de gaps e dependências técnicas.
Solução
Problema: Usuários abriam o produto e não tinham visibilidade sobre o que fazer primeiro. O painel principal mostrava dados, não direção. A taxa de ativação de 0,15% confirmava que o problema não era motivação — era ausência de caminho.
Decisão de design: Componente compacto por padrão, expansível sob demanda — para não dominar a tela de quem já sabe o que fazer, mas estar acessível para quem precisa de orientação. Lista curada de tarefas com estado de conclusão visível — progresso acumulado como motivação intrínseca, não como sistema de pontos arbitrário. O componente foi montado como um collapse adaptado do Design System — sem versão azul disponível e sem suporte a ilustração. As colunas do DS posicionaram os badges de recompensa mais distantes das tarefas do que o ideal para escaneabilidade; o problema de redimensionamento de tela foi documentado como débito técnico. Essas limitações foram aceitas conscientemente para não atrasar a validação da hipótese central — e registradas como insumo para a versão com Appcues.
Visuais: componente nos estados recolhido e expandido · lista de tarefas com estados de conclusão · badge de recompensa
Problema: Como criar incentivo para completar tarefas sem transformar o trial em um sistema de gamificação desconectado do produto? Como viabilizar recompensas sem automação de cupom disponível no tempo do MVP?
Decisão de design: Duas recompensas complementares: +3 dias de trial por tarefa completada (tangível, diretamente ligada ao produto — mais tempo para experimentar o valor real) e 10% de desconto na assinatura, viabilizado via redirecionamento para WhatsApp de vendas sem automação de cupom. O desconto foi definido pelo diretor de vendas Ricardo Nogueira; a ausência de automação foi uma troca deliberada de velocidade por precisão de implementação, com risco documentado. A escolha de extensão de trial como recompensa principal foi estratégica: reforça o valor do produto sem o custo de percepção negativa que descontos automáticos podem gerar — desconto no checkout sinaliza desespero de venda; extensão de trial sinaliza confiança no produto.
Visuais: mecânica de recompensa · estados de tarefa completada · fluxo de redirecionamento para WhatsApp
Resultado: +500% em conversão de trial para assinatura na base isolada de teste.
Iniciativa pausada estrategicamente por interferência de outro teste no checkout — não por baixo desempenho.
Reflexão
O que este projeto realmente foi
Este projeto foi a construção de arquitetura de ativação onde havia só ausência de direção. A taxa de 0,15% não era evidência de produto ruim — era evidência de que nenhum mecanismo estruturado traduzia “abriu o produto” em “chegou ao valor do produto”. O componente de gamificação não criou valor novo: tornou visível o caminho até o valor que já existia.
O dado de +500% de conversão em base isolada confirma a hipótese. O que é mais revelador do que o número é o que ele implica sobre o produto: se +500% de conversão é possível apenas tornando o caminho de valor visível, o problema nunca foi o produto — foi a ausência de arquitetura de ativação. O problema nunca precisou de uma solução complexa — precisou de uma solução que removesse a invisibilidade do caminho.
O que permaneceu depois
A pausa estratégica não apagou o trabalho conceitual. Antes de pausar, o processo gerou um plano de evolução documentado que virou arquitetura para as próximas versões: fluxos no Appcues (com modais de início e conclusão de jornada), novos canais de notificação (WhatsApp, email), testes com variações de UI, expansão para outros segmentos além de serviço, e automação de cupom para eliminar a dependência do redirecionamento via WhatsApp. Esse roadmap não foi gerado especulativamente — foi gerado a partir das limitações reais encontradas no MVP: cada restrição de DS, cada gap de automação, cada comportamento não capturado virou um item de evolução com justificativa técnica.
O que eu faria diferente
Validar as recompensas com usuários antes de lançar. +3 dias e 10% de desconto foram definidos com velocidade — pelo diretor de vendas, sem validação com clientes. O risco foi documentado e aceito. Mas uma rodada de entrevistas com usuários de trial antes do lançamento teria gerado hipóteses mais fortes sobre o que é percebido como recompensa real vs. recompensa arbitrária nesse contexto.
Especificar o componente com mais detalhe antes de entrar no DS. As limitações do Design System (collapse sem versão azul, badges distantes, problema de resize) foram descobertas durante o design, não antes. Uma análise prévia dos componentes disponíveis teria permitido especificar a adaptação com mais antecedência — ou negociar a criação de um componente novo antes do MVP, ao invés de adaptar durante.
Vamos trabalhar juntos?
Disponível para full-time · remote · freelancer
Aberto a novos projetos, oportunidades e conversas.