Revamp Foodservice SaaS Digital Experience

O SaaS de foodservice, já desatualizado, travava operações críticas dentro dos times de cozinha industrial, como a gestão de receitas e os pedidos.

O time completo era o VP de Produto, o Diretor Criativo Global, o líder de Engenharia, o time de desenvolvimento e nosso time de design UX/UI de duas pessoas. Com apenas 12 semanas pela frente, buscamos redesenhar a plataforma com uma UX moderna e mobile-first, que reduzisse atrito e deixasse as pessoas focarem na qualidade da comida.

Para acelerar o processo de design thinking, usei um vídeo sobre a enorme operação culinária da Royal Caribbean como método alternativo de pesquisa, para entender sistemas de food service em grande escala.

Isso me deu uma leitura valiosa dos fluxos reais, das hierarquias de time e dos desafios diários de mais de 500 pessoas na cozinha. Observar como cada função se conecta com logística, operações e higiene ajudou a fechar a lacuna entre o que o sistema fazia e o que as pessoas realmente precisavam.

Uma cozinha industrial é uma operação de precisão militar: uma orquestração de pessoas com um único objetivo, preparar uma refeição.

Imaginamos um sistema que desse a times de cozinha sem perfil técnico o mesmo controle e a mesma eficiência de uma plataforma enterprise de primeira linha. O projeto buscava transformar complexidade em clareza. Havia muitas camadas a melhorar, mas o objetivo central era ser mobile-first, responsivo e confortável em desktop, tablet e celular.

Como Senior Product Designer, liderei a estratégia de UX de um ERP de foodservice em grande escala, cobrindo as necessidades de mais de 10 tipos de usuário entre finanças, operações e compliance.

Com card sorting, testes rápidos e benchmarking, identificamos a navegação como a dor central. Junto a engenharia, jurídico e stakeholders executivos, reestruturei a arquitetura do sistema em torno de fluxos por função, para agilizar o acesso aos dashboards e listas críticos.

Revisões semanais com engenharia e PMs garantiram designs prontos para desenvolvimento, enquanto o feedback iterativo de jurídico, nutrição e equipe de cozinha foi moldando uma solução multidisciplinar e testada em piloto.

A partir do discovery surgiram ideias para que as pessoas fossem mais produtivas e passassem menos tempo diante da tela e mais diante da cozinha.

Exploramos vários caminhos para um software pesado e cheio de conteúdo. O menu ficou organizado em cinco categorias principais —Culinary, ERP, Financial, Analytics, Users— sobre pelo menos 70 áreas distintas para revisar como usuário admin.

Gerenciador de receitas: busca avançada, com uma grade de cards testada contra uma lista compacta para medir densidade de informação — quanto um chef consegue ler de relance contra quanto cabe na tela.

Ao mapear a arquitetura de informação, o objetivo principal era reduzir o atrito para pessoas que trabalham sob pressão e com pouco tempo de tela. Isso significava deixar as ações relevantes à mão e minimizar a carga cognitiva.

Dividimos o aplicativo em cinco módulos principais alinhados à operação real da cozinha:

• Planejamento de cardápio
• Inventário
• Pedidos
• Compliance
• Relatórios

Cada módulo foi estruturado em torno de funções concretas —nutricionistas, responsáveis de compras, chefs— para que os fluxos coincidissem com seus modelos mentais. Um chef principal precisava chegar às fichas de receita, à disponibilidade de ingredientes e ao ajuste de porções em um ou dois cliques. O responsável de inventário precisava de dashboards estruturados para acompanhar alertas de estoque baixo e aprovar envios de fornecedores.

Esses fluxos foram testados em sessões iniciais de wireframes e depois refinados com feedback de stakeholders e heurísticas de usabilidade. O resultado é um sistema modular pensado para crescer com a operação sem deixar de ser intuitivo e específico por função.

As bases do design system, construídas a partir das telas de receitas para fora, e não de um kit abstrato para dentro.

O gerenciador de receitas era a tela mais densa do produto, então virou a origem do conjunto de componentes em vez de um consumidor dele. Cards, filtros e linhas de lista foram desenhados ali primeiro e generalizados depois.

Doze semanas do primeiro workshop até um design system nas mãos do time de engenharia, com os fluxos de receita refeitos de ponta a ponta.

Ao avançar para a implementação, trabalhei de perto com o líder de engenharia e o time de front-end para garantir um handoff limpo. Todos os componentes foram entregues pelo Figma, com specs documentadas, guias de espaçamento e anotações de comportamento pensadas para layouts responsivos.

Fizemos check-ins semanais entre design e desenvolvimento para validar ambientes de staging, esclarecer comportamentos de componentes e priorizar ajustes segundo cenários de uso reais.

Uma melhoria chave foi otimizar os alvos de toque e a densidade do layout depois de ver a equipe de refeitório usar o sistema no celular com luvas, ou com pouquíssimo tempo. No lançamento, todas as jornadas principais —de navegar receitas aos resumos de pedido— estavam validadas em todos os breakpoints e funções.

A solução atualizada inclui hoje um design system com regras feitas com e para os usuários reais, e para nosso time de desenvolvimento trabalhando com a biblioteca Kendo React junto aos nossos primeiros componentes próprios.

Com instruções de design escritas na linguagem dos desenvolvedores, o objetivo era construir uma ponte entre as expectativas de design e a realidade do stack, dos recursos e do tempo disponível.