oi, pode me chamar de Carol

Diana
no Portal

O primeiro produto do time construído inteiro com vibe coding, da concepção à produção, por designers.

Carolina Zamprônio Product Designer · IA aplicada a produto · iFood · 2026

O contexto

Ninguém vende antes de terminar o setup

Todo parceiro novo do iFood passa por um portal de ativação. São seis etapas obrigatórias, cerca de 40 minutos de configuração, antes da loja ir ao ar.

Pagamento · 1 min Entrega · 10 min Horário · 5 min Minha loja · 5 min Financeiro · 10 min Cardápio · 10 min Conclusão

O problema

E, quando travava, ele travava sozinho

Evidência qualitativa

A mesma dor, pesquisa após pesquisa

Entrevistas e forms recorrentes no produto apontavam falta de suporte durante a ativação.

O que o portal oferecia

Um FAQ estático

Perguntas frequentes no rodapé da tela. Nenhum canal para tirar dúvida no momento em que ela aparece.

Volume desatendido

17.258 sessões web

Entre janeiro e março de 2026, sem nenhuma ajuda em tempo real no caminho.

A leitura: o parceiro não desistia por falta de vontade. Ele parava numa dúvida que ninguém estava lá para responder.

A oportunidade

A ajuda já existia. Só não estava onde a dúvida acontecia.

A Diana é o agente de onboarding do iFood. Ela já funcionava como canal autônomo de captação e cadastro, e também respondia dúvidas sobre a plataforma.

  • Tudo isso acontecia só pelo WhatsApp, fora do fluxo de quem estava configurando a loja
  • Quem estava no portal, no meio do setup, não alcançava nada disso

A hipótese

Se a inteligência da Diana estivesse dentro do portal, o parceiro resolveria a dúvida sem sair do fluxo e chegaria ao primeiro pedido mais rápido e com mais qualidade.

O obstáculo: pelo roadmap normal levaria meses para entrar na fila de desenvolvimento, e exigiria alinhar a prioridade de dois times. O portal e a Diana são times separados, com backlogs próprios.

A aposta do time

Total Football

Na Vibe Coding Week, o time testou uma ideia: com IA, o mesmo profissional atua em mais de uma área sem perder a profundidade da sua especialidade.

Para mim não era experimento novo. Eu já vinha subindo código no produto, adequando componentes ao design system e ajustando conteúdo direto na interface.

a semana só abriu espaço para ir mais longe

Antes de construir

Entender a arquitetura com quem a construiu

Quadro branco com o desenho do fluxo entre portal, Kong e Diana
O quadro onde desenhamos
PORTAL webchat no setup KONG gateway DIANA · agent graph pergunta resposta /v1/message start enrichment supervisor revisor end auth faq menu perfil agentes especializados canal = portal POST sessionId · mensagem · canal chat completion · resposta síncrona fluxo do portal fluxo do WhatsApp
O recorteSó a funcionalidade de tirar dúvidas foi para o portal, não a Diana inteira.
A decisãoO mesmo endpoint do WhatsApp, com roteamento por canal no supervisor.
O custoCerca de 15 linhas no core, retrocompatível e coberto por testes.

Meu processo

01Esboço no Figma

Estados, hierarquia e comportamento definidos antes de qualquer linha de código. É aqui que eu decido o que o componente precisa fazer.

02Tradução no Claude Code
03Refino das microinterações

Meu processo

01Esboço no Figma
02Tradução no Claude Code

O esboço vira contexto. O componente nasce dentro dos padrões do repositório, lendo a documentação que o próprio time escreveu.

03Refino das microinterações
claude code · diana-agent-squad

>criar o webchat a partir do frame do Figma

Read docs/PORTAL_API_CONTRACT.md

Write WebChat.tsx +128

Edit ChatLauncher.tsx +34

Edit tokens.css +12

Bash npm run build ✓ sem erros

Meu processo

01Esboço no Figma
02Tradução no Claude Code
03Refino das microinterações

Transição, brilho e resposta ao hover, ajustados iteração a iteração até o gesto parecer natural.

estados do launcher
?

repousohoveraberto

duração240 ms
escala1 → 1,07
brilho0 → 100%

Divisão do trabalho

Quem fez o quê

Eu

Front-end, design e microinterações

A interface do webchat e o comportamento de cada estado, codados com Claude Code.

Outro designer

Back-end

Roteamento por canal e o contrato de API para o time do portal.

Engenharia

Revisão e a rota no Kong

A camada de gateway, mais delicada, ficou com quem tem a profundidade para isso.

Dia 1

Entender a arquitetura com os devs

Dias 2 a 4

Construir front e back, abrir os MRs

Dia 5

MVP rodando internamente, já usável

Depois

Iterações e ajustes finos da engenharia

A solução começa aqui

Tem alguém ali, não um FAQ

O ícone de dúvida vira a Diana quando o mouse se aproxima. É o convite, antes de qualquer conversa.

A solução

Diana consultora,
dentro do setup

  • O ícone de ajuda vira a Diana quando o parceiro passa o mouse
  • Quick questions por etapa: no financeiro ela sugere perguntas de financeiro, no cardápio sugere perguntas de cardápio
  • A mesma base do WhatsApp, agora com resposta síncrona e adaptada ao portal

O que a solução entrega

Responsiva, no padrão do produto e fluida de usar

Responsivo

Do desktop ao celular

O mesmo chat se ajusta à largura da tela, sem uma versão separada pra cada tamanho.

Design system

Tokens, não valores soltos

Cor, texto, espaço e raio vêm do design system do produto, e o componente já nasce no padrão.

Fluidez

A pergunta certa, na etapa certa

A Diana sugere o que o parceiro provavelmente quer saber agora e responde sem tirá-lo do fluxo.

Antes do usuário real

Testamos com usuários sintéticos

  • Quatro personas sintéticas, do dono tradicional que nunca usou IA ao jovem nativo digital, construídas pelo time de dados, também na Vibe Coding Week
  • Cada uma conversando com a Diana em cenários reais de setup
  • Um agente avaliador pontuando turno a turno: objetivo cumprido, eficiência, classificação
  • As falhas viraram backlog antes de qualquer parceiro de verdade ver a tela
Cenário Turnos Juiz LLM Eficiência Classificação Veredicto
Definir horários 7 1,0 0,44 1,0 aprovado
Adicionar itens · Drop Burger 7 1,0 0,83 1,0 aprovado
Criar cardápio do zero 20 0,6 0,00 0,5 reprovado
Adicionar itens · Sabor Carioca 8 0,8 0,67 0,5 parcial

Scorecard do agente avaliador · quatro cenários, turno a turno

Resultados · teste A/B, base crescente (30/30 → 50/50) · 26.08 a 21.09

Um setup com mais qualidade leva o parceiro à primeira venda

Ativado → 1º pedido

+1,60 p.p.

51,00% para 52,68%

Impacto absoluto

~100

primeiros pedidos incrementais no período

O que mudou foi a qualidade do setup, e isso apareceu na etapa seguinte: mais parceiros chegando à primeira venda.

O que eu tirei disso

Aprendizados

A fronteira ficou invisível, a profundidade não

Consigo construir e subir código. A rota no Kong continua sendo da engenharia, e saber onde eu paro é parte do trabalho.

Qualidade de código com IA não se garante na revisão

Tiramos as boas práticas da cabeça dos devs e viramos documentação. Quem entrou depois no time herdou o padrão.

O gargalo migrou

Antes o difícil era construir. Agora é decidir o que vale construir, e isso continua sendo decisão de produto e design.

Dois times, um atalho

O que destravou não foi só a ferramenta. Foi conseguir provar a hipótese sem disputar a prioridade de dois backlogs.

Não foi um projeto isolado

Como a IA entrou no meu dia a dia

No produto

Design system direto no código

Reformulei os componentes do nosso produto atualizando o design system, com ganhos medidos em conversão sem mudar a jornada.

A Diana no portal nasceu daí.

No time

Guilda de IA e workshop

Toco a guilda de IA do time de parceiros, com cerca de 15 designers.

No workshop que conduzi, todos abriram o primeiro merge request com um componente.

Fora do trabalho

Construo o que eu preciso

Criei meus próprios aplicativos para organização e acompanhamento de desempenho.

É onde eu testo ferramenta nova antes de levar para o time.

Ferramentas no dia a dia

Claude Code Claude VSVS Code Wispr Flow Figma Vercel GitLab Supabase
Capa
1 / 18