iFood à Mesa
Pedir comida é simples. Decidir junto pode ser melhor.
Duas pessoas querem pedir comida. Uma prefere uma opção vegetariana; as duas precisam respeitar um limite de gasto. Antes de escolher o prato, há uma decisão em comum: onde pedir, o que cabe no orçamento e quem vai organizar tudo.
O iFood à Mesa propõe reunir essas condições em um plano que acompanha a escolha até a confirmação.
Este projeto autoral foi desenvolvido com apoio de IA, sem vínculo com as marcas. Pesquisa primária e impacto de negócio permanecem como etapas a validar.
A tarefa parecia escolher comida. O desafio era decidir junto.
Enquadrar a experiência antes de desenhar
Olhar para o que acontece entre as telas
O ponto de partida foi um cenário de pedido para duas pessoas. Quem organiza precisa conciliar vontades, reunir escolhas, conferir taxas e assumir o pagamento. O produto pode oferecer muitos restaurantes e, ainda assim, deixar parte dessa coordenação para conversas e contas feitas fora do fluxo.
Transformar o cenário em uma pergunta
Como ajudar duas pessoas a escolher no mesmo restaurante, com preferências diferentes e um limite total explícito? Esse enquadramento deslocou a atenção do volume de opções para a qualidade da decisão. A pergunta passou a orientar o que seria necessário mostrar e em qual momento.
Definir o valor que a proposta deveria entregar
Para quem organiza, a intenção é tornar escolhas e custo completo compreensíveis. Para quem participa, é oferecer autonomia com contexto. A hipótese de produto é que um plano compartilhado possa diminuir revisões no fechamento. Essa fricção ainda precisa ser investigada com usuários; aqui, ela orienta um exercício de design, não um diagnóstico medido do app atual.
As referências ajudaram a escolher uma direção.
Interpretar princípios, em vez de somar funcionalidades
Preservar o que já é familiar
O iFood foi a referência de contexto: busca, loja, sacola e acompanhamento compõem uma linguagem conhecida de delivery. As fontes também mostram iniciativas de IA, como o Ailo. Isso trouxe uma decisão: o projeto não precisaria justificar sua relevância por introduzir mais um assistente.
Aprender com coordenação e percepção de valor
A publicação da Uber Eats descreve pedidos em grupo, divisão de pagamento, prazos e lembretes. O princípio aproveitado foi permitir que cada pessoa escolha seu prato. Já a comunicação da 99Food sobre preço e acesso reforçou a importância de explicar quanto a experiência custa, sem transportar promoções históricas para o conceito.
Dar às referências um papel no projeto
A síntese foi conectar critérios antes da exploração: orçamento para a mesa, preferência e prazo. Daí surgiu a proposta de comparar composições equivalentes, mantendo o contexto até a revisão. O benchmark é documental e considera períodos e mercados específicos; não representa uma auditoria de todas as versões dos aplicativos.
Antes de defender a solução, é preciso entender o hábito.
O que investigar e de quem precisamos aprender
Separar a observação da hipótese
As referências públicas sustentam a existência de iniciativas de IA e de pedidos coletivos. Elas não explicam, por si só, como as pessoas negociam um almoço, quando descobrem o total ou por que abandonam uma escolha. Essa lacuna definiu o plano de pesquisa.
Investigar episódios reais
A proposta é entrevistar de 6 a 8 pessoas que tenham organizado ou participado de pedidos coletivos recentes. O roteiro parte do último episódio: como escolheram a loja, quando conheceram o custo, o que mudou no caminho e como resolveram divergências. O objetivo é compreender comportamento antes de pedir opinião sobre a funcionalidade.
Projetar considerando duas perspectivas
Para desenvolver o cenário, foram definidos dois perfis provisórios. Quem organiza precisa reunir escolhas e confirmar a conta; quem participa precisa entender loja, limite e pagamento antes de escolher. Esses perfis orientam a interface, mas ainda não são personas validadas. Na pesquisa, consentimento, anonimização e rastreio das evidências devem permitir uma síntese responsável, inclusive se houver apoio de IA.
Um bom recorte dá profundidade a cada escolha.
Hipóteses, escopo e trade-offs
Concentrar o problema em três hipóteses
A primeira é que mostrar o total com taxas melhora a compreensão da comparação. A segunda é que combinar critérios antes da lista evita refazer escolhas. A terceira é que separar a escolha individual da revisão coletiva torna mais clara a responsabilidade pelo pedido. Juntas, elas criaram critérios para avaliar as telas além da aparência.
Escolher o que caberia na primeira versão
O recorte inclui duas pessoas, uma loja, um endereço, preferência vegetariana, teto total, comparação e convite. O pagamento fica com quem organiza. Essa decisão mantém o fluxo verificável e permite aprofundar a relação entre seleção, composição de preço e confirmação.
Reconhecer o custo das alternativas
Dividir a cobrança parece uma evolução natural, mas exige lidar com autorização, expiração, desistência e estorno de cada participante. Por isso ficou fora do MVP, assim como mais participantes e agendamento. O primeiro objetivo é descobrir se o plano compartilhado faz sentido; depois, avaliar quais camadas adicionais merecem investimento.
O plano precisa acompanhar a pessoa até o fim.
Conectar etapas, papéis e informações
Organizar o percurso
A jornada foi estruturada em seis momentos: combinar, explorar, escolher, revisar, confirmar e acompanhar. O organizador define o plano; o convite leva esse contexto ao participante; as escolhas se encontram na sacola antes do pagamento. Assim, a experiência não depende de todos terem começado pela mesma tela.
Dar estrutura à colaboração
A mesa reúne critérios, participantes, restaurante e sacola. Cada item pertence a uma pessoa. O pedido só nasce depois da revisão e da confirmação. Essa separação ajuda a distinguir uma escolha ainda em construção de uma compra efetivamente confirmada.
Manter continuidade quando algo muda
Voltar de um prato deve preservar o plano. Trocar de restaurante exige explicar o efeito sobre a sacola. Uma alteração de preço precisa aparecer antes da cobrança.
Essas regras surgem da arquitetura e passam a orientar os estados da interface, em vez de ficarem como correções posteriores.
Primeiro, decidir o que aparece. Depois, como isso será lido.
Estrutura, hierarquia e conteúdo
Tornar o raciocínio visível
Os wireframes organizaram o plano antes da lista e colocaram os mesmos critérios na comparação. Na baixa fidelidade, rótulos e valores tornaram explícitos o limite com taxas e o pagamento único. Essa passagem permite revisar hierarquia e entendimento antes de investir no acabamento visual.
Uma decisão que atravessou as versões
O total ganhou prioridade sem esconder sua composição.
A intenção é que a pessoa compare uma refeição para a mesa, e não o preço de um prato com o custo completo de outra opção.
As regras do produto também precisam de consistência visual.
Fundação, componentes e acessibilidade
Construir uma base reutilizável
Com o fluxo definido, a interface foi organizada em um sistema conceitual próprio: grid de 8 pontos, margem mobile de 24 px, tipografia sem serifa e superfícies neutras. Vermelho profundo orienta ações; verde apoia confirmações e condições atendidas. Não se trata da biblioteca oficial do iFood.
Transformar padrões em contratos
Botões, filtros, campos monetários, cards, linhas de participante, composição de preço e alertas compartilham tokens e regras de conteúdo. Os contratos definem o que muda em foco, seleção, carregamento, indisponibilidade e erro. A finalidade é evitar que a mesma regra ganhe interpretações diferentes entre telas.
Projetar além do estado ideal
Texto, status e mensagens complementam as cores. Os pares centrais passaram na verificação de contraste por script. Reflow, ampliação, teclado e leitor de tela ainda exigem implementação e avaliação próprias. O pacote técnico reúne tokens, catálogo e especificações para essa continuidade.
A escolha começa com condições em comum.
Como a direção se transforma em interface
Definir o plano sem interromper outros usos
A home oferece uma entrada opcional para pedir junto. O organizador informa participantes, teto total, preferência e prazo. O plano não aumenta o orçamento nem remove um critério silenciosamente para produzir mais resultados.
Comparar o mesmo tipo de informação
A lista apresenta sugestões para dois pratos com entrega e serviço. Na comparação, total, prazo, opção vegetariana e avaliação ocupam posições equivalentes. Ao entrar na loja, o contexto permanece visível. Esse encadeamento procura reduzir a necessidade de lembrar valores entre etapas.
Explicar o limite da estimativa
O total antecipado vale para uma composição definida. Adicionais ou mudanças precisam de recálculo. Se catálogo e taxas não estiverem disponíveis, o produto deve explicar a limitação em vez de apresentar precisão aparente.
Autonomia para escolher. Contexto para participar.
Do prato individual à mesa compartilhada
Detalhar o que sustenta a escolha
A tela do prato reúne composição, preço e opção de talheres. A preferência vegetariana orienta o cardápio; não equivale a uma garantia sobre alérgenos ou preparo. Essa distinção evita que uma simplificação de interface comunique uma segurança que não pode assegurar.
Levar o plano a quem recebe o convite
Depois de adicionar seu prato, o organizador pode convidar a outra pessoa. O convite explica restaurante, limite e responsabilidade pelo pagamento. O participante escolhe dentro desse contexto, sem precisar reconstruir toda a conversa que antecedeu o pedido.
Dar visibilidade à coordenação
A mesa mostra quem escolheu e quem está aguardando. Cada item fica associado ao participante, enquanto a revisão continua com quem paga. A divisão exibida serve de referência para o grupo; não inicia cobranças ou transferências individuais.
O total deixa de ser um número isolado.
Relacionar escolhas, taxas e compromisso
Uma conta que pode ser conferida
Dois pratos de R$ 26,00 somam R$ 52,00. Com R$ 4,90 de entrega e R$ 1,99 de serviço, o total chega a R$ 58,89: R$ 1,11 abaixo do limite. A referência por pessoa é R$ 29,45 + R$ 29,44; o centavo residual permanece explícito.
Dar à revisão uma função real
Antes de confirmar, endereço, pagamento e estimativa de entrega aparecem junto ao valor completo. O CTA informa o compromisso que será assumido. Lojas, pratos e preços são exemplos fictícios, utilizados para manter a lógica do projeto consistente entre as telas.
Conectar interface e regra de negócio
Em produção, os valores seriam armazenados em centavos e revalidados no servidor. A confirmação precisaria de proteção contra duplicidade. Esses contratos sustentam a confiança que o desenho procura comunicar; a tela sozinha não resolve uma cobrança inconsistente.
Quando o plano muda, a decisão volta para a pessoa.
Vazio, alteração de preço e estados do pedido
Preservar o que já foi combinado
Se não houver opções, a interface propõe ampliar o prazo mantendo orçamento e preferência. Editar os critérios continua disponível. A recomendação oferece um caminho sem reconfigurar o plano por conta própria.
Tornar uma mudança impossível de ignorar
Se a entrega passar a R$ 6,90, o total sobe para R$ 60,89. A diferença e o limite excedido aparecem antes da cobrança, com opção de editar ou aceitar. A sacola permanece disponível, evitando transformar uma mudança de condição em perda de trabalho.
Continuar depois do pagamento
O acompanhamento apresenta estados compreensíveis, atualização da estimativa e acesso à ajuda. No handoff, isso pede contratos para falha de pagamento, indisponibilidade e confirmação pelo servidor. O objetivo é manter clareza também quando a jornada deixa de seguir o caminho ideal.
A IA entrou para acelerar o trabalho que se repete.
Produção assistida, automação e revisão
Usar a ferramenta em atividades concretas
A IA apoiou o enquadramento, a pesquisa documental, alternativas de microcopy, dados sintéticos e o código gerador de telas e documentos. O ganho buscado foi tornar mais rápida a passagem entre regra, conteúdo e representação visual, mantendo a revisão das decisões como parte do trabalho.
Transformar consistência em verificação
Scripts geraram CSS a partir dos tokens e conferiram contraste, cálculos em centavos, presença de arquivos e rotas da navegação. Essas verificações foram executadas. Elas ajudam a encontrar divergências reproduzíveis, mas não demonstram compreensão ou satisfação de quem usa.
Manter a origem das informações clara
Os dados são fictícios e os usos de IA estão registrados no pacote. Não foram criados depoimentos, entrevistas ou métricas como se fossem evidências de campo. Também não foi medida economia de tempo.
O registro permite distinguir o que foi produzido, o que foi checado e o que ainda depende de validação.
Entender a intenção sem esconder os critérios.
Uma evolução possível para o conceito
Partir de uma necessidade compreensível
Uma evolução seria permitir “almoço para dois, até R$ 60 e uma opção vegetariana” como entrada. A proposta não é tratar um assistente como novidade absoluta: Ailo já é uma referência pública de IA no iFood. O interesse está em conectar a intenção ao plano compartilhado.
Separar interpretação de decisão
O modelo extrairia participantes, orçamento e preferência. Esses critérios apareceriam para confirmação e edição antes de consultar catálogo e taxas. A ordenação precisaria se apoiar em dados verificáveis; o modelo não inventaria preços, disponibilidade, cupons ou prazo e não confirmaria pagamentos.
Prever ambiguidade e falha
Se a intenção não estiver clara, o sistema pergunta. Se a IA estiver indisponível, os mesmos filtros continuam acessíveis manualmente. Essa camada ainda não foi integrada ao protótipo: antes de um piloto, seria necessário avaliar extração de critérios, tratamento de erro e comportamento com dados reais.
A proposta fica mais forte quando pode ser questionada.
Observar entendimento antes de medir impacto
Testar o raciocínio da experiência
O próximo ciclo propõe 5 a 6 sessões formativas. A tarefa é organizar um almoço para duas pessoas, uma vegetariana, até R$ 60 no total. Comparação, entrada pelo convite e mudança de taxa devem aparecer sem o moderador indicar os caminhos.
Observar o que importa
Concluir sem ajuda crítica é apenas parte da avaliação. A pessoa precisa explicar o total, reconhecer quem paga, perceber quando o limite é excedido e encontrar edição e ajuda. Erros, tempo por tarefa e momentos de hesitação devem ser ligados a decisões específicas de interface para orientar a iteração.
Preparar uma avaliação de produto
Em um piloto, o funil acompanharia início da mesa, critérios, seleção, participação, revisão e pagamento confirmado pelo servidor. Conclusão e revisões seriam analisadas junto a cancelamentos e dúvidas de cobrança. Metas e experimento dependeriam de baseline e jornadas comparáveis; nesta entrega, não há testes com participantes ou ganho de negócio medido.
Uma jornada construída a partir de decisões conectadas.
Telas em três níveis de fidelidade. Entrega de design, não uma métrica de impacto.
O projeto reúne 14 telas em três níveis de fidelidade, Design System conceitual, protótipo offline, documentação e automações. A proposta conecta condições da mesa, escolha individual e revisão coletiva. Compreensão do total e redução de coordenação são objetivos a testar, não resultados já alcançados.
O aprendizado que orienta a continuidade
A principal reflexão é que colaboração exige contexto em cada entrada da jornada. Não basta reunir pratos em uma sacola: participantes precisam entender as condições, e quem paga precisa reconhecer o compromisso. O próximo passo é observar esses comportamentos, revisar as hipóteses e aprofundar a implementação com design e tecnologia.