Assinatura de Pontos
Como transformei a complexidade de um produto de fidelidade em um sistema que qualquer gestor consegue operar
Função
Product Designer
Empresa
NDA
Duração
4 meses
O cenário que abriu a oportunidade
O consumidor brasileiro está mais sensível a preço, mais seletivo e cada vez mais orientado a valor no curto prazo. Nesse contexto, empresas de diferentes segmentos aumentaram o investimento em programas de fidelidade, impulsionadas por um ROI consistente e pela necessidade crescente de retenção de clientes. Mas havia um problema estrutural nesse movimento que poucos estavam endereçando: a maioria desses programas ainda funcionava como iniciativa de marketing, e não como produto.
O resultado prático desse desalinhamento se manifestava de três formas. O engajamento era esporádico e dependente de campanhas para se manter vivo. A progressão dentro do programa era lenta, o que reduzia a percepção de valor ao longo do tempo. E do ponto de vista do negócio, não existia nenhuma previsibilidade de receita, tornando impossível planejar com base no comportamento dos usuários.
Foi nesse cenário que surgiu a oportunidade de criar algo diferente: um sistema de assinaturas integrado a programas de fidelidade, capaz de gerar recorrência, progressão e valor contínuo, tanto para o usuário quanto para o negócio.
A Sarah e o problema real
Para entender onde o produto precisava chegar, foi preciso entender primeiro quem o operaria. A Sarah não é apenas uma persona de projeto. Ela representa o perfil de gestor que, sem uma ferramenta clara, fica preso entre a estratégia que quer executar e o sistema que não consegue operar com autonomia.
O problema central que a Sarah carregava era objetivo: fidelidade precisava deixar de ser um incentivo pontual e passar a funcionar como um sistema que sustentasse relacionamento de forma contínua. Mas para que isso fosse possível na prática, ela precisava de uma ferramenta que conseguisse operar com autonomia, sem depender de times técnicos a cada ajuste e sem precisar reaprender o sistema a cada nova campanha.
Essa era a tensão estrutural do projeto. O produto precisava ser sofisticado o suficiente para suportar um modelo de assinatura complexo, e claro o suficiente para que a Sarah conseguisse configurar, ajustar e evoluir tudo sozinha. As duas exigências eram reais e precisavam coexistir na mesma solução.
A oportunidade de produto
A análise competitiva foi o ponto de partida para entender o espaço que o produto poderia ocupar. Dois modelos bem estabelecidos no mercado apresentavam limitações opostas e complementares.
Os programas de fidelidade tradicionais tinham foco em acúmulo futuro e entregavam baixa percepção de valor imediato. Os modelos de assinatura, por outro lado, tinham valor claro e recorrência garantida, mas ofereciam pouca flexibilidade para personalização conforme a estratégia de cada empresa evoluía.
A oportunidade estava exatamente na interseção entre os dois: combinar a recorrência previsível das assinaturas com a progressão e personalização dos programas de fidelidade. Um modelo que entregasse valor imediato percebido pelo usuário final, previsibilidade de receita para o negócio e capacidade de configuração autônoma para gestores como a Sarah. Esse posicionamento se tornou o norte de todas as decisões de escopo e design que vieram a seguir.
Estruturando o problema antes de desenhar qualquer tela
Antes de qualquer wireframe, conduzi uma sessão de matriz CSD com todos os envolvidos no projeto. O objetivo era separar o que já era claro do que ainda precisava ser validado, evitando que suposições não testadas guiassem decisões de produto.
O exercício deixou evidente que havíamos mapeado o que era necessário (recorrência, painel administrativo robusto, configuração de planos) e revelou o que ainda precisava ser investigado, especialmente o comportamento real dos gestores ao configurar um programa pela primeira vez e como eles percebiam o valor das funcionalidades disponíveis.
Mais importante do que o mapeamento em si, a CSD trouxe à tona o principal risco do produto: dois perigos opostos convivendo no mesmo escopo.
Com base nos insights da CSD, agrupamos as ideias em temas e aplicamos o framework MoSCoW para definir o escopo do primeiro ciclo. A decisão mais importante não foi o que entrou, mas o que ficou deliberadamente de fora.
O foco foi garantir o essencial para viabilizar o modelo: criação e gestão de planos, definição de regras de pontos e benefícios, e estrutura de pagamento. Tudo que aumentaria a complexidade operacional sem validar o valor central do produto foi postergado. Essa contenção foi crítica porque permitiu construir algo funcional desde o início, sem comprometer a capacidade de evolução nas versões seguintes, e garantiu que a Sarah conseguisse usar o sistema sem treinamento extenso desde o primeiro acesso.
A solução: um sistema, não uma tela
O resultado foi um painel administrativo onde gestores como a Sarah conseguem estruturar, testar e evoluir suas estratégias de fidelização com autonomia total. A experiência começa com uma visão centralizada dos planos ativos, projetada para que qualquer decisão relevante esteja acessível sem navegação desnecessária ou múltiplos cliques para chegar ao ponto certo.
A criação de um plano foi desenhada em etapas que refletem as decisões reais que um gestor já toma mentalmente ao estruturar um benefício. Primeiro, define-se o modelo: nome, valor e configuração dos benefícios inclusos. Depois, a percepção: visual do plano, ordenação e destaque na página. Essa sequência não é arbitrária. Ela replica o raciocínio que a Sarah já faz naturalmente, o que reduz a carga cognitiva e torna o processo intuitivo mesmo para quem está acessando pela primeira vez.
Um dos pontos mais estratégicos do produto foi permitir que a empresa configurasse não só o plano em si, mas toda a experiência de assinatura do usuário final. A edição da página funciona como um CMS com pré-visualização em tempo real, onde é possível estruturar conteúdos, benefícios, FAQs, cards de suporte e ordenação de planos sem nenhuma intervenção técnica.
O que os testes revelaram
Para validar a solução, conduzi testes de usabilidade com 6 usuários internos, divididos entre as áreas de OPS e CS, com perfis diferentes de familiaridade com a jornada de assinatura. Foram 5 tarefas no total, cobrindo desde a navegação inicial até criação, edição, inativação e exclusão de planos.
Os resultados foram consistentes: em 4 das 5 tarefas, todos os 6 participantes concluíram com sucesso e sem fricção relevante. A criação de planos, a vinculação, a edição e os controles de gestão funcionaram de forma intuitiva, com múltiplos participantes elogiando especificamente a customização e a pré-visualização em tempo real como diferenciais claros da experiência.
O único ponto de fricção consistente foi a nomenclatura "cards de suporte" na tela de edição de página, que gerou confusão em 5 dos 6 usuários. Não era um problema de fluxo nem de arquitetura. Era um problema de linguagem. Os usuários sabiam o que queriam fazer, mas o termo não comunicava o conceito com clareza suficiente para que agissem com confiança. O encaminhamento foi direto: revisão de microcopy, reforço visual com tooltips explicativos e ajuste na hierarquia de informação daquela seção específica. A taxa de sucesso geral nas tarefas ficou em 96%, com facilidade percebida alta em todas as sessões.
Trade-offs e o que o projeto ensinou sobre alinhamento
O projeto também trouxe desafios relevantes fora da interface. A troca de Product Managers ao longo do processo gerou realinhamentos que impactaram decisões já validadas com o time, resultando em retrabalho e em diferenças entre o que foi desenhado e o que foi efetivamente implementado no lançamento oficial em dezembro. Componentes que dependiam de integrações mais complexas chegaram ao ar com inconsistências em relação ao Figma.
Esse cenário reforçou algo que vai além desse projeto: design não garante o produto final. Alinhamento organizacional garante. A qualidade da entrega de um produto complexo é diretamente proporcional à estabilidade do processo de decisão ao redor dele, e isso é uma responsabilidade que ultrapassa a camada da interface. Em projetos com múltiplos stakeholders e instabilidade de liderança, o designer precisa atuar como guardião da coerência, documentando decisões, rastreando impactos de mudança e mantendo o fio condutor do produto visível para todo o time, mesmo quando o contexto ao redor muda.
Resultado
O primeiro cliente a operar o sistema em ambiente real foi o Lance!, que entrou como piloto em agosto e validou o modelo de assinatura com usuários reais antes do lançamento oficial. Essa validação confirmou que a proposta de valor central funcionava na prática: gestores conseguiam configurar e ativar planos de forma autônoma, sem suporte técnico, desde o primeiro acesso.
Do ponto de vista estratégico, o produto reposicionou fidelidade de uma ferramenta de incentivo para uma camada de relacionamento contínuo, abrindo espaço estrutural para retenção de longo prazo, frequência de uso e geração de receita recorrente. São as hipóteses que o produto foi construído para validar, e que o piloto com o Lance! deixou em posição favorável para responder com dados reais ao longo do tempo.
Aprendizados
Esse projeto consolidou uma visão que carrego para qualquer produto de alta complexidade: organizar não é simplificar. A Sarah não precisava de um sistema mais fácil. Precisava de um sistema mais claro. Há uma diferença fundamental entre os dois: simplificar remove funcionalidade, enquanto organizar distribui complexidade de forma que cada decisão apareça no momento certo, para quem precisa tomar aquela decisão.
A outra aprendizagem foi sobre influência sem autoridade. Em projetos com múltiplos stakeholders e instabilidade de liderança, o designer precisa ser o guardião da coerência, não apenas da interface. Isso significa documentar decisões, rastrear impactos de mudança e manter o fio condutor do produto visível para todo o time, mesmo quando o contexto ao redor muda com frequência.