Como uma pesquisa aprofundada transformou um lançamento estagnado em 2 milhões de pedidos.

O Cardápio Digital foi o produto white-label do iFood para restaurantes: uma ferramenta que permitia ter seu próprio canal de delivery e receber pedidos diretamente, sem a comissão do iFood. A oportunidade de mercado era clara: cerca de 29 milhões de pedidos por ano aconteciam fora da plataforma, pelo WhatsApp, Instagram e telefone. O produto fazia sentido estratégico. Mas após o lançamento, não decolava.

  • Product Design
  • Pesquisa UX
  • Designer End-to-end

Empresa

iFood

Duração

10 meses

Papel

Product Designer, UX Research

Ferramentas

Figma, Amplitude, Hotjar, Survey Monkey.

iFood Cardápio Digital case study hero

Oportunidade

Um mercado de 29 milhões de pedidos escondido à vista de todos.

Os restaurantes parceiros do iFood já vendiam fora da plataforma: pelo WhatsApp, telefone e redes sociais. O iFood enxergou um mercado endereçável de aproximadamente 29 milhões de pedidos por ano e criou o Cardápio Digital para capturá-lo: uma ferramenta gratuita e white-label que dava aos restaurantes seu próprio menu digital e canal de pedidos, sem comissão nos primeiros 100 pedidos por mês. A proposta de valor era forte no papel. O desafio era fazer os restaurantes verem da mesma forma.

Market opportunity

Público

Dois públicos, um produto.

O Cardápio Digital atendia dois grupos distintos, cada um com seus próprios pontos de fricção e motivações. Entender os dois era essencial para o design.

Restaurantes parceiros do iFood

Parceiros do iFood que já vendem fora da plataforma pelo WhatsApp ou telefone, e precisam de uma forma mais simples de gerenciar isso.

Cardápio Digital app and partner panel

Clientes dos parceiros

O consumidor final que faz pedidos diretamente pelo Cardápio Digital do restaurante, sem passar pela plataforma do iFood.

End-to-end, do pré-lançamento ao crescimento.

Entrei no projeto cerca de dois a três meses antes do primeiro lançamento, como a única product designer. Trabalhei em todo o produto: aprimorando o V1 antes do lançamento, conduzindo um teste A/B fake door para validar o posicionamento de aquisição, liderando a pesquisa pós-lançamento junto com uma colega designer, e desenhando as funcionalidades que surgiram dela.

A PM, os engenheiros e uma colega pesquisadora foram meus principais colaboradores.

Pré-lançamento: Validando o posicionamento

Antes de lançar, testamos como falar sobre o produto.

Uma das primeiras perguntas que enfrentamos não era sobre o produto em si, era sobre como posicioná-lo. Fizemos um teste A/B fake door na landing page de aquisição para entender o que levaria os restaurantes a se cadastrar.

Versão A: destacava a gratuidade do produto, sem taxas, sem comissões. Performou ligeiramente melhor e virou a mensagem principal. Versão B: destacava a dor que resolvia, substituindo o caos de gerenciar pedidos pelo WhatsApp e telefone. O resultado foi próximo o suficiente para não descartarmos essa abordagem: mantivemos essa narrativa ao longo do restante da página.

Os dois ângulos ressoavam. Só precisávamos saber qual usar na abertura.

A/B test landing page

O problema que a pesquisa revelou

O produto foi lançado. Três meses depois, ainda não sabíamos por que não estava funcionando.

O lançamento aconteceu no prazo. Mas três meses depois, os números estavam bem abaixo do esperado. Tínhamos 12 mil restaurantes ativos e 172 mil pedidos, contra uma meta de 200 mil pedidos naquele ponto, a caminho de 3 milhões até março de 2022. O primeiro instinto do time foi pressionar mais: mais ligações para restaurantes, mais contatos, mais follow-up. Passamos cerca de um mês fazendo exatamente isso. Gerou alguns dados, mas nada profundo o suficiente para explicar a fricção real.

O que faltava não era esforço. Era compreensão. Não tínhamos uma visão clara de quem eram de fato nossos restaurantes, como operavam fora do iFood, se haviam entendido o que o produto fazia, ou por que hesitavam em adotar algo que era, para a maioria deles, totalmente gratuito. Foi quando minha colega e eu propusemos fazer isso da forma correta.

A pesquisa

Entender a diferença entre se cadastrar e realmente usar o produto.

Um estudo em duas fases que partiu de histórias individuais para padrões identificados em mais de 13 mil restaurantes.

Qualitativa

22 entrevistas · 11 engajados, 11 desengajados.

Na primeira fase, fizemos entrevistas qualitativas com 22 parceiros: 11 usando ativamente o produto e 11 que tinham parado. O objetivo não era só encontrar problemas, era entender o que motivava ou desmotivava os parceiros a usar o Cardápio Digital. A divisão foi intencional: se conseguíssemos entender o que fazia o grupo engajado funcionar, poderíamos avaliar se isso era replicável.

Quantitativa

13.944 respondentes.

Esses achados moldaram completamente a segunda fase. Com um panorama mais claro dos pontos de fricção, construímos uma pesquisa quantitativa enviada a 13.944 parceiros. Foi aí que tivemos a dimensão real: a escala dos gaps de compreensão, como o comportamento diferia da percepção, e exatamente quais gaps de funcionalidade bloqueavam a adoção na base mais ampla.

O que descobrimos

O problema central não era o produto. Era compreensão e confiança.

A maior parte dos restaurantes na plataforma eram pequenos negócios informais, não times de marketing com estratégias de crescimento. Para eles, uma nova ferramenta digital significava risco, confusão e mais uma coisa para resolver. Entre os parceiros desengajados, dois padrões apareciam repetidamente:

Gap de compreensão

Os restaurantes não entendiam o que era o produto, como configurá-lo ou como divulgá-lo para seus próprios clientes. O branding do iFood na URL fazia seus clientes pensarem que estavam pedindo pelo iFood, o oposto do que queriam.

Gap de confiança

Eles temiam que o iFood fosse cobrar em algum momento. Mesmo quando viam valor no produto, essa dúvida era suficiente para bloquear a adoção.

Entre os parceiros engajados, o feedback era diferente.

Eles entendiam o produto e queriam continuar usando, mas três funcionalidades ausentes os seguravam:

Sem pagamento online

Os clientes só podiam pagar na entrega. Os restaurantes queriam suporte a cartão de crédito.

Sem Pix

O método de pagamento mais usado no Brasil, completamente ausente.

Sem opção de retirada

Os clientes não tinham como fazer pedido para retirar no local. Para restaurantes sem entregador próprio, isso era um impeditivo.

O time recebeu a pesquisa com muita energia

O Head of Product olhou para os nossos achados e disse: esse é o nosso roadmap. Seguimos por ele.

Quick win

A solução mais rápida não foi uma funcionalidade, foi um guia.

Grande parte da fricção que identificamos não era sobre funcionalidade ausente, era sobre compreensão. Os restaurantes não sabiam o que era o produto, que era gratuito ou como divulgá-lo para seus próprios clientes.

Propus criar um guia educativo construído diretamente a partir das dúvidas coletadas nas entrevistas qualitativas. A PM estava cética, então me ofereci para fazê-lo no meu próprio tempo. Foi lançado em um evento para parceiros focado em promover e explicar o produto, e teve uma ótima recepção.

Depois disso, não foi algo pontual: o guia foi incorporado às comunicações contínuas com os restaurantes parceiros e disponibilizado diretamente no portal do parceiro.

Partner educational guide

O trabalho complexo: pagamento online e Pix

Os restaurantes nos disseram exatamente o que faltava. Nós construímos.

A maior lacuna de funcionalidade era clara: os restaurantes queriam que seus clientes pudessem pagar online, por cartão de crédito ou Pix, não apenas na entrega. Não era uma adição simples. Significava desenhar o fluxo completo de login e cadastro para os clientes finais, incluindo validação por email e SMS, conformidade com privacidade e segurança, considerações de LGPD e integração com a infraestrutura de autenticação existente do iFood.

Payment flow design

O fluxo tinha quatro etapas conectadas: escolher o método de pagamento, fazer login ou criar uma conta, validar a identidade e, por fim, inserir os dados do cartão ou código Pix.

Cada etapa tinha casos de borda que exigiam decisões explícitas de design: o que acontece quando o código SMS não chega, como tratar clientes que já têm conta no iFood, como apresentar o ambiente de autenticação do iFood sem fazer o cliente sentir que está pedindo pelo iFood.

Acertar esse último ponto era particularmente delicado: precisávamos que a infraestrutura do iFood parecesse um sinal de confiança, não uma fonte de confusão.

Authentication flow design

Evolução do produto

A pesquisa não só respondeu perguntas. Ela reescreveu o roadmap.

V1 product

O V1 que recebi cobria o fluxo central de pedidos: navegação no menu, carrinho e checkout básico. O que a pesquisa deixou claro foi o quanto faltava para os restaurantes realmente operarem seu negócio por ele.

V2 product

O V2 que construímos a partir desses achados era um produto substancialmente diferente. Os novos fluxos incluíam gerenciamento de endereço e opções de retirada, redesign completo do catálogo e checkout, métodos de pagamento (Pix, cartão de crédito, dinheiro na entrega), autenticação de conta iFood, acompanhamento de pedido e melhorias de UX identificadas na análise heurística. Não foi uma iteração. Foi uma reconstrução baseada no que passamos a conhecer.

Aprendizado contínuo

Construímos ciclos de feedback para nunca mais ficar sem dados

Um dos aprendizados dos primeiros meses, quando o time operava sem dados reais, foi o custo de não ter visibilidade contínua sobre o comportamento dos usuários. Após a pesquisa, colocamos quatro canais em funcionamento:

Amplitude

Acompanhava o funil completo, do acesso ao menu até a conclusão do pedido. Taxas de conversão, pontos de abandono e volume de pedidos.

Widget de feedback do Hotjar

Disponível em cada etapa do fluxo de compra para capturar sinais de fricção em tempo real.

Gravações de sessão

Filtradas por rage clicks e abandono de fluxo para identificar problemas de usabilidade que não apareciam nas pesquisas.

Check-ins com usuários engajados

Conversas regulares com os restaurantes parceiros mais ativos à medida que novas funcionalidades eram lançadas.

Resultados

De 172 mil para 2 milhões de pedidos em quatro meses.

Em janeiro de 2022, aproximadamente quatro meses após a conclusão da pesquisa e o lançamento das primeiras melhorias, o Cardápio Digital havia atingido 2 milhões de pedidos. A curva de crescimento havia mudado completamente. Ainda não havíamos atingido a meta de março de 3 milhões, mas o time sabia que estávamos no caminho certo. Acompanhei o produto até março de 2022, quando saí do projeto.

  • Set/21: 12 mil restaurantes ativos, 172 mil pedidos

  • Jan/22: 2 milhões de pedidos realizados

  • Escala da pesquisa: 22 entrevistas qualitativas + 13.944 respondentes

Reflexão

Os dados sempre estiveram disponíveis. A gente só não tinha ido buscá-los do jeito certo.

O mês que passamos fazendo ligações e enviando mensagens antes da pesquisa não foi desperdiçado: nos mostrou que o contato informal tinha um limite. A pesquisa estruturada gera algo com o que você pode agir em escala.

Os achados não só responderam nossas perguntas. Deram a todo o time uma linguagem compartilhada para priorizar e entender o porquê. O outro aprendizado que carrego deste projeto: educação é uma decisão de produto. O guia que criei não era um ativo de marketing. Era uma resposta a um gap real de compreensão que o produto não havia endereçado. Quando funcionou, mudou a forma como o time pensava sobre onboarding.

Próximo

Quer ver os achados completos da pesquisa e os designs do V2? Fale comigo.