Short stories

A versão
curta

Nove decisões técnicas por trás de três produtos, um parágrafo cada.

01 / 09

Cupons

Daki · Regras & estados

Cada tipo de falha virou um estado de interface.

Stack
Talon.One
Escopo
Componente de cupom + bottom sheet do carrinho
Resultado
Sucesso no resgate de 35–40% para ~60% (novos usuários)

Problema

As falhas de cupom já vinham classificadas no dado, mas a interface mostrava uma única mensagem genérica para todas. 61% delas eram "Coupon Rejected by Condition": o cupom era válido, só que a pessoa não cumpria algum requisito e não tinha como saber qual.

Solução

Trazer a regra para dentro do componente. Cada cupom mostra seus requisitos (valor mínimo, produtos obrigatórios, limite de desconto). Quando um requisito ainda não foi atingido, o card fica bloqueado e diz quanto falta. O limite máximo de desconto ganhou um feedback próprio na inserção manual.

Rejeitado por condição · 61%Requisitos visíveis + bloqueio "faltam R$ X"
Limite máximo de descontoFeedback explicando o teto
Sem elegibilidadeCupom não aparece na carteira
Classe de falha → estado no componente
Ver o case completo →
Lista de cupons com requisitos em cada card e um cupom bloqueado indicando quanto falta.

02 / 09

Analytics

Daki · Dados & rollout

Montar o funil antes de abrir o Figma.

Stack
Looker · BigQuery · GA4
Recortes
Comportamento, dispositivo, status de promoção

Problema

"Os cupons dão erro" não é um problema que dá para desenhar. Era preciso saber em qual etapa as pessoas desistiam, de onde vinham os erros e quais segmentos eram mais afetados.

Solução

Funil de cupons montado no Looker sobre o BigQuery, cruzado com o GA4 e segmentado por comportamento, dispositivo e status de promoção. Ele mostrou que só 24% de quem via um cupom concluía o pedido, que 27% dos usuários "No Promo" abandonavam antes do checkout e que novos usuários eram o segmento mais afetado (34%).

Cupom visualizado100%
Selecionado61%
Aplicado43%
Checkout iniciado32%
Pedido concluído24%
Funil de uso de cupons
Ver o case completo →

03 / 09

Permissões

Too Seguros · Arquitetura & ops

Permissão por função, não por empresa.

Modelo
Perfil master → funções → abas
Base
14 entrevistas em 4 corretoras

Problema

O desenho inicial tratava "a corretora" como um único usuário. Em campo (4 corretoras, 14 entrevistas), ficou claro que cada corretora tem várias funções, cada uma responsável por uma parte do processo, e que elas não podem ver as mesmas informações.

Solução

Um modelo de acesso por perfil. Um perfil master define o que cada função enxerga, e a navegação por abas se monta a partir disso. O mesmo portal fica quase personalizado para cada corretora, sem uma versão por cliente. A separação reduziu ruído entre funções e erros operacionais.

perfil master
 └─ define, por função, o que cada pessoa vê

abas do MVP (consulta)
 ├─ apólices
 ├─ documentos
 └─ pagamentos
Modelo de acesso e navegação do MVP
Ver o case completo →
Gestão de perfis e permissões por corretora no Portal Parceiro.

04 / 09

Modelagem

Daki · Regras & estados

Os atributos do cupom vieram antes da tela.

Stack
Talon.One
Fontes
CRM, Brand, Influenciadores, BizDev
Segmentos
NRR: New, Onboarding, Retained, At Risk, Churn

Problema

Quatro times criavam cupons (CRM, Brand, Influenciadores e BizDev), cada um com seus tipos de campanha e regras de elegibilidade. Desenhar a carteira sem saber quais atributos existiam significaria uma tela que o motor de promoções não conseguiria alimentar.

Solução

Entrevistas com os quatro times para mapear casos de uso reais e, a partir deles, definir o que precisaria ser configurado no Talon.One: tipo, validade, elegibilidade, regras e limites. A elegibilidade passou a seguir a segmentação por NRR, então a carteira mostra para cada pessoa só o que vale para o momento dela na base.

cupom {
  tipo
  validade
  elegibilidade: NRR[New | Onboarding | Retained | At Risk | Churn]
  regras        // valor mínimo, produtos obrigatórios
  limites       // uso, desconto máximo
}
Atributos configurados no motor de promoções
Ver o case completo →
Diagrama: CRM, Brand, Influenciadores e BizDev alimentam a definição de cupons e os atributos no Talon.One.

05 / 09

Rollout

Daki · Dados & rollout

Quatro entregas, duas metades da base.

Stack
Maze · A/B 50/50
Cadência
Leitura semanal por segmento NRR
Resultado
+27% no uso de cupons entre assinantes · +R$18 de ARPU

Problema

A carteira mexia no carrinho e no checkout, os pontos mais sensíveis do app. Lançar tudo de uma vez tornaria impossível saber qual parte gerava resultado, ou qual quebrava alguma coisa.

Solução

A solução foi fatiada em quatro etapas, cada uma testada no Maze antes de ir para produção. O lançamento foi um A/B com 50% da base e análise semanal por segmento. No grupo teste, quase 40% dos assinantes usaram cupons, contra 15% no controle.

  1. E1 · nova UI para testers internos
  2. E2 · cupons elegíveis por NRR
  3. E3 · bloqueio dinâmico por requisito
  4. E4 · integração com assinatura
Entregas faseadas
Ver o case completo →
As quatro etapas de entrega, de E1 a E4.

06 / 09

Design system

Too Seguros · Arquitetura & ops

Um design system existente, um fluxo mobile-first.

Base
Design system da Too Seguros + adaptações mobile-first
Resultado
Compra do zero em ~3 min · +30% de conclusão

Problema

O público do seguro de moto é mobile-only, e o fluxo precisava rodar sobre o design system da Too, que pedia adaptações para um e-commerce no celular. Um formulário de seguro tem muitos campos obrigatórios para emitir a apólice, e cada campo a mais é um ponto de abandono.

Solução

A UI foi construída sobre o design system da Too, com adaptações para mobile-first em vez de componentes paralelos. O fluxo foi quebrado em etapas curtas, com autopreenchimento sempre que possível, sem abrir mão dos dados necessários para a emissão. Cartão e boleto como pagamento, seguindo a pesquisa.

Mercado LivrePagamento intuitivo, passo a passo ilustrado
YouseFormulários confiáveis, customização de planos
AdidasPreenchimento simplificado, conferência de dados limpa
Porto SeguroLanding page instrucional
Benchmark → princípio aplicado no fluxo
Ver o case completo →
Fluxo de contratação do Na Garupa Too no celular.

07 / 09

Assinatura

Daki · Regras & estados

Trial, renovação e saída como um fluxo só.

Stack
Stripe
Plano
R$9,99/mês · trial 30 dias
Benefícios
4 tokens de frete (MOV R$30, validade 30 dias) + R$80 em vouchers

Problema

Uma assinatura tem um ciclo de vida inteiro: entrada sem cobrança, renovação mensal, comunicação em cada virada e cancelamento. Se cada etapa fosse desenhada isolada, a experiência ficaria cheia de buracos, principalmente na saída.

Solução

Toda a jornada de assinatura e cancelamento foi integrada ao Stripe: trial de 30 dias sem cobrança imediata, auto-renovação mensal com comunicações automáticas e cancelamento livre pelo próprio app, sem passar pelo suporte. Os benefícios (4 tokens de frete grátis e R$80 em vouchers) ficam visíveis no perfil.

  1. Trial · 30 dias
  2. Ativo · renova todo mês
  3. Cancelado pelo app
Ciclo de vida da assinatura
Ver o case completo →
Mecânica do Tier 1: R$9,99 por mês com trial de 30 dias, 4 tokens de frete grátis e R$80 em vouchers.

08 / 09

Pesquisa contínua

Too Seguros · Dados & rollout

Instrumentar o portal para iterar com uso real.

Stack
GA · Hotjar · NPS trimestral
Resultado
−57% no tempo de emissão · −33% em tickets de suporte

Problema

Depois do MVP, era preciso decidir o que evoluir sem depender só de testes pontuais. Parte das dificuldades só aparecia no dia a dia das corretoras, fora das sessões de usabilidade.

Solução

Um ciclo de co-criação com os early adopters, com três fontes: NPS trimestral, Google Analytics e Hotjar para capturar o que não aparecia nos testes. Cada lançamento passava antes por teste de conceito e de usabilidade. O dashboard semanal de faturamento virou a tela de entrada padrão.

  1. Teste de conceito
  2. Usabilidade
  3. Lançamento
  4. GA + Hotjar
  5. NPS trimestral
Ciclo de cada entrega
Ver o case completo →
Listagem de apólices com status e datas de vencimento no Portal Parceiro.

09 / 09

Service design

OLX · Arquitetura & ops

Padronizar um serviço feito por pessoas.

Canais
WhatsApp · e-mail · área do anúncio
Parceiros
Time de Content · especialistas

Problema

No Autofácil, a negociação era conduzida por especialistas humanos, por chat e WhatsApp. Sem padrão, cada especialista teria seu tom e seu ritmo, e não haveria um caminho definido para quando alguém parava de responder.

Solução

Templates de WhatsApp e e-mail criados com o time de Content para padronizar a experiência entre especialistas, e réguas automatizadas para os casos de não-resposta. No digital, cada etapa da venda fica visível na área de gerenciamento de anúncios da plataforma.

  1. Anúncio publicado
  2. Contato do especialista em até 24h
  3. Negociação
  4. Visita com vistoria e transferência
Jornada do vendedor
Ver o case completo →
Gerenciamento do anúncio com as etapas da venda no Autofácil.

Quer a versão longa?

Ver os cases →