← Voltar

mLabs

Link de Pagamento Stone no Inbox — Fake Door

Como validei o interesse em uma integração com a Stone antes de uma única linha de código ser escrita.

Papel
Product Designer
Duração
Validação rápida
Ferramentas
Figma · Análise de eventos · Pesquisa qualitativa
Link de Pagamento Stone no Inbox — Fake Door

challenge.

A Stone propôs incluir um link de pagamento dentro do Inbox da mLabs — o chat unificado das redes sociais. Antes de mobilizar squads e gastar meses construindo uma integração, eu precisava responder duas perguntas: os usuários realmente querem isso? e como eles vendem e cobram hoje?. Construir pra descobrir saía caro. Perguntar direto também não funcionava — usuário diz que quer tudo. Precisava de um teste que medisse comportamento real.

how I solved.

Desenhei um fake door: um botão de fácil acesso no Inbox que, ao ser clicado, abria um modal perguntando se o usuário tinha interesse em enviar link de pagamento Stone direto na conversa. Sem feature por trás. Apenas instrumentação pra medir quantos acessavam o Inbox, quantos clicavam no botão e quantos confirmavam interesse. No mesmo modal, abri espaço pra pesquisa qualitativa: como o usuário vende hoje, quais soluções já usa, o que espera de um link de pagamento.

results.

14 respostas qualitativas estruturadas em 7 grandes temas: integração, personalização, segurança, competitividade de taxas, facilidade de uso, inovação (QR Code) e suporte. Os usuários validaram interesse e ainda entregaram, de graça, o benchmark da concorrência (Pagar.me, PagSeguro, Cielo, Safra Pay, Picpay). A conversa com a Stone deixou de ser sobre 'fazer ou não fazer' e passou a ser sobre como fazer pra ganhar do que já existe.

Funil do fake door Link Stone no Inbox da mLabs — ~8% dos usuários demonstraram interesse
Funil real do fake door — ~8% dos usuários que entraram no Inbox clicaram no botão Stone. Daily, 24/jul → 3/ago.

activities.

  • Fake door design
  • Instrumentação de eventos
  • Pesquisa qualitativa
  • Síntese de insights
  • Benchmark indireto
  • Análise quantitativa
  • Recomendação de produto

context.

O produto

A mLabs é uma plataforma de gestão de redes sociais. O Inbox é o módulo de chat unificado: o usuário responde DMs do Instagram, Facebook e outras redes em um só lugar. A Stone propôs integrar link de pagamento direto nessa conversa — o vendedor cobra o cliente sem sair do chat.

Meu papel

Atuei como Product Designer responsável por desenhar o fake door, definir os eventos de tracking, redigir a pesquisa qualitativa e sintetizar os achados em recomendações acionáveis pro time de produto e pra parceria com a Stone.

A premissa

Antes de mobilizar dev, design e integração com a Stone, era essencial ter dado de comportamento real — não opinião em entrevista. Fake door entrega isso: o usuário acha que a feature existe e clica (ou não).

Por que importava

Uma integração de pagamento entre duas plataformas (mLabs + Stone) é cara: contratos, squads, compliance, prazos. Errar na hipótese custa meses. Acertar com fake door custa uma semana de design.

methodology.

Fake door + pesquisa qualitativa embutida

O fake door isolado mede interesse. A pesquisa isolada mede opinião. Combinei as duas coisas na mesma jornada: o clique no botão dispara o modal, o modal valida interesse e abre espaço pra contexto qualitativo. Quantitativo direciona, qualitativo explica.

  1. 01

    Design do fake door

    Botão de pagamento Stone no header do Inbox, posicionado pra ser descoberto naturalmente no fluxo de conversa — sem banner, sem onboarding, sem aviso. O usuário precisa achar como acharia uma feature real.

  2. 02

    Instrumentação

    Três eventos: acesso ao Inbox, clique no botão Stone, confirmação de interesse no modal. O funil mostra quem viu, quem se interessou e quem cravou.

  3. 03

    Pesquisa qualitativa no modal

    Perguntas abertas dentro do próprio modal: como vende hoje, quais ferramentas usa, o que espera de um link de pagamento. Captura no momento de maior interesse — diferente de mandar formulário depois.

  4. 04

    Síntese em 7 temas

    Leitura cruzada dos 14 depoimentos, agrupamento por tópico, extração de citações marcantes e priorização do que vira requisito de produto.

  5. 05

    Recomendação

    Documento de achados estruturado pra alimentar tanto o time interno quanto a conversa com a Stone — com benchmark indireto incluído (concorrentes citados pelos próprios usuários).

discovery.

Entendendo o problema e levantando requisitos

A análise dos 14 depoimentos revelou um cenário diversificado — cada usuário trouxe uma camada diferente do problema. Sete temas se repetiram com força:

  1. 01

    Integração e check-out simplificado

    Usuários iniciando negócio online buscam fluxo de check-out direto, sem fricção. A integração nativa no Inbox responde a essa dor — ferramenta única, sem precisar pular pra outra plataforma.

  2. 02

    Personalização e múltiplos métodos

    Demanda clara por boleto, depósito, cartão de crédito parcelado e débito no mesmo link. O vendedor quer oferecer ao cliente a forma que ele preferir — não impor uma só.

  3. 03

    Segurança equivalente à maquininha

    Os usuários cobram a mesma confiabilidade da transação presencial, incluindo a possibilidade de antecipação. Segurança aqui não é só técnica — é percepção da marca.

  4. 04

    Taxas competitivas

    Vários compararam diretamente PagSeguro, Cielo e Safra Pay. Quem usa link de pagamento sabe exatamente quanto paga — e quanto pode repassar. Taxa alta mata a hipótese.

  5. 05

    Facilidade de uso e ampla aceitação

    Interface intuitiva e suporte a várias bandeiras/operadoras. O usuário não quer estudar a ferramenta; quer mandar o link e receber.

  6. 06

    Inovação — QR Code e pagamento por aproximação

    Sugestão recorrente de QR Code pra pagamento instantâneo, sem digitar dados. Sinal de que o usuário acompanha a evolução do mercado e espera o mesmo da mLabs.

  7. 07

    Suporte transparente

    Relato negativo com o Picpay (suporte inexistente quando a cliente pagou pra pessoa errada) mostrou que suporte é dealbreaker. Erro acontece — o que importa é como a marca responde.

O desafio identificado: validar interesse sem construir produto

Três tensões se cruzavam:

Tempo: a conversa com a Stone tinha prazo. Construir pra testar levaria meses. • Risco: entregar uma integração que ninguém usa queima credibilidade dos dois lados. • Profundidade: medir só o clique não basta — precisava entender o porquê do interesse e como o usuário compara essa solução com o que já usa.

impacto real

Pensa em um pequeno empreendedor que vende pelo Instagram. Ele responde DMs o dia todo no Inbox da mLabs, fecha pedido, e na hora de cobrar precisa: abrir outra aba, gerar o link no Pagar.me ou PagSeguro, copiar, voltar pro chat, colar. Cada etapa é uma chance de perder a venda — distração, link errado, cliente desistindo. O botão direto no Inbox encurta isso pra um toque. A pergunta era: o usuário percebe esse atalho como valor real, ou ele já se acostumou com a fricção?

proposed solution.

Botão no Inbox + modal de interesse + pesquisa embutida

A solução fake door foi propositalmente minimalista: um único botão no Inbox que abre um modal. Sem feature por trás. O foco era extrair sinal de comportamento real (cliques) e contexto rico (depoimentos) na mesma jornada — antes de qualquer linha de código de integração.

Principais features

  • +Botão de pagamento Stone visível no header do Inbox, posicionado no fluxo natural de conversa
  • +Modal acionado pelo clique perguntando se o usuário teria interesse na funcionalidade
  • +Campos abertos no modal pra capturar contexto: como vende hoje, ferramentas atuais, expectativas
  • +Tracking em 3 etapas (acesso ao Inbox → clique no botão → confirmação no modal) pra ler o funil
  • +Síntese qualitativa em 7 temas conectando opinião ao que o produto real precisa entregar
  • +Documento de achados pronto pra alimentar discovery interno e negociação com a Stone

A oportunidade

O fake door abriu três frentes de oportunidade pra integração real:

  • Posicionar a mLabs como hub de venda social — não só de gestão de redes
  • Diferenciar da Stone direta: aqui o link nasce no contexto da conversa, sem o vendedor sair de tela
  • Empilhar requisitos do produto a partir do que o usuário citou: múltiplos métodos, taxas competitivas, QR Code, suporte responsivo
  • Usar os 14 depoimentos como prova social pra acelerar a discussão de roadmap com a Stone

fake door in action.

Fake door em ação — Inbox da mLabs

Botão Stone no Inbox abrindo o modal de interesse — fluxo real testado em produção.

results.

De fluxo manual e fragmentado para rateio nativo no Financeiro

antes

  • Validação

    Hipótese baseada em opinião do time

  • Custo do teste

    Meses de squad + integração

  • Sinal de demanda

    Suposição — 'usuário deve querer'

  • Visão do usuário

    Sem dado qualitativo estruturado

  • Benchmark

    Pesquisa de mercado paga e demorada

  • Risco

    Construir feature que ninguém usa

Decisão no escuro, com risco alto e prazo longo

depois

  • Validação

    Comportamento real medido em 1 semana

  • Custo do teste

    Design + tracking, zero código de produto

  • Sinal de demanda

    Funil completo: viu → clicou → confirmou interesse

  • Visão do usuário

    14 depoimentos sintetizados em 7 temas

  • Benchmark

    Concorrentes citados pelos próprios usuários

  • Risco

    Conversa com a Stone embasada em dado de uso

Decisão informada, custo baixo, prazo de uma semana

conclusion.

O fake door do Link Stone mostrou na prática que discovery não precisa esperar produto pronto. Com um botão, um modal e instrumentação básica, gerei dado quantitativo (funil de cliques) e qualitativo (14 depoimentos) suficiente pra orientar uma decisão de parceria entre duas empresas. Mais do que validar a feature, o trabalho deixou um mapa claro do que o produto real precisa entregar pra ganhar do que já existe no mercado — integração simples, múltiplos métodos, taxas competitivas, segurança equivalente à maquininha e suporte transparente.

key takeaways.

O que esse case demonstra

  1. 01

    Fake door é o atalho mais honesto. Mede comportamento real, não intenção declarada. Em uma semana você sabe se vale construir — ou se a hipótese morre antes de virar squad.

  2. 02

    Quantitativo direciona, qualitativo explica. Saber quantos clicaram me diz se há interesse. Ler o que escreveram me diz por que clicaram — e o que precisa estar no produto pra eles continuarem clicando.

  3. 03

    O usuário entrega o benchmark de graça. Quando ele cita Pagar.me, PagSeguro, Cielo, Safra Pay e Picpay sozinho, ele tá te mostrando contra quem você compete e por quais critérios é comparado.

  4. 04

    Pesquisa no momento de interesse vale ouro. Modal aberto logo após o clique captura o usuário no pico de atenção. Formulário enviado depois nunca volta com a mesma qualidade.

  5. 05

    Suporte é parte do produto. O relato sobre o Picpay mostrou que falha técnica acontece — o que mata a marca é a ausência de resposta. Pra link de pagamento, suporte não é extra; é core.

skills demonstrated.

  • Discovery Design

    Design de fake door, definição de hipótese, escolha do método de validação e orquestração de quantitativo + qualitativo

  • Product Analytics

    Instrumentação de eventos, leitura de funil (acesso → clique → confirmação) e tradução de número em recomendação

  • User Research

    Pesquisa qualitativa embutida no fluxo, síntese de depoimentos em temas e extração de citações representativas

  • Strategic Design

    Benchmark indireto via menções dos usuários, conexão entre dor real e oportunidade de produto, recomendação acionável

  • Stakeholder Communication

    Documento de achados estruturado pra alimentar discovery interno e negociação com parceiro externo (Stone)

  • Lean UX

    Validação com o menor esforço possível antes de mobilizar squad — design como ferramenta de redução de risco

stack.

FigmaAnálise de eventosPesquisa qualitativa

thanks for reading.

Quer entender melhor como conduzo discovery? Vamos conversar.

Ver mais cases

Outros cases