Revamp Foodservice SaaS Digital Experience

El SaaS de foodservice, ya desactualizado, frenaba operaciones críticas dentro de los equipos de cocina industrial, como la gestión de recetas y los pedidos.

El equipo completo era el VP de Producto, el Director Creativo Global, el líder de Ingeniería, el equipo de desarrollo y nuestro equipo de diseño UX/UI de dos personas. Con sólo 12 semanas por delante, apuntamos a rediseñar la plataforma con una UX moderna y mobile-first, que redujera fricción y dejara a la gente concentrarse en la calidad de la comida.

Para acelerar el proceso de design thinking usé un video sobre la enorme operación culinaria de Royal Caribbean como método alternativo de investigación, para entender sistemas de food service a gran escala.

Eso me dio una lectura valiosa de los flujos reales, las jerarquías de equipo y los desafíos diarios de más de 500 personas en cocina. Observar cómo cada rol se conecta con logística, operaciones y sanidad ayudó a cerrar la brecha entre lo que hacía el sistema y lo que la gente realmente necesitaba.

Una cocina industrial es una operación de precisión militar: una orquestación de personas con un solo objetivo, cocinar una comida.

Imaginamos un sistema que le diera a equipos de cocina sin perfil técnico el mismo control y la misma eficiencia que una plataforma enterprise de primer nivel. El proyecto buscaba convertir complejidad en claridad. Había muchas capas por mejorar, pero el objetivo central era ser mobile-first, responsive y cómodo en escritorio, tablet y celular.

Como Senior Product Designer lideré la estrategia de UX de un ERP de foodservice a gran escala, cubriendo las necesidades de más de 10 tipos de usuario entre finanzas, operaciones y compliance.

Con card sorting, testeo rápido y benchmarking detectamos que la navegación era el dolor central. Junto a ingeniería, legales y stakeholders ejecutivos reestructuré la arquitectura del sistema alrededor de flujos por rol, para agilizar el acceso a los dashboards y listados críticos.

Revisiones semanales con ingeniería y PMs garantizaron diseños listos para desarrollo, mientras que el feedback iterativo de legales, nutrición y personal de cocina fue dando forma a una solución multidisciplinaria y testeada en piloto.

A partir del discovery salieron ideas para que la gente fuera más productiva y pasara menos tiempo frente a la pantalla y más frente a la cocina.

Exploramos varios caminos para un software pesado y lleno de contenido. El menú quedó organizado en cinco categorías principales —Culinary, ERP, Financial, Analytics, Users— sobre al menos 70 áreas distintas para revisar como usuario admin.

Recetario: búsqueda avanzada, con una grilla de tarjetas puesta a prueba contra una lista compacta para medir densidad de información: cuánto puede leer un chef de un vistazo frente a cuánto entra en pantalla.

Al mapear la arquitectura de información, el objetivo principal era reducir la fricción para gente que trabaja bajo presión y con poco tiempo de pantalla. Eso significaba poner las acciones relevantes a mano y minimizar la carga cognitiva.

Dividimos la aplicación en cinco módulos principales alineados a la operación real de la cocina:

• Planificación de menú
• Inventario
• Pedidos
• Compliance
• Reportes

Cada módulo se estructuró alrededor de roles concretos —nutricionistas, responsables de compras, chefs— para que los flujos coincidieran con sus modelos mentales. Un chef principal necesitaba llegar a las fichas de receta, la disponibilidad de ingredientes y el ajuste de porciones en uno o dos clics. El responsable de inventario necesitaba dashboards estructurados para seguir alertas de stock bajo y aprobar envíos de proveedores.

Estos flujos se pusieron a prueba en sesiones tempranas de wireframes y después se refinaron con feedback de stakeholders y heurísticas de usabilidad. El resultado es un sistema modular pensado para crecer con la operación sin dejar de ser intuitivo y específico por rol.

Los cimientos del sistema de diseño, construidos desde las pantallas de recetas hacia afuera, y no desde un kit abstracto hacia adentro.

El recetario era la pantalla más densa del producto, así que se volvió el origen del sistema de componentes en lugar de un consumidor de él. Tarjetas, filtros y filas de lista se diseñaron ahí primero y se generalizaron después.

Doce semanas desde el primer workshop hasta un design system en manos del equipo de ingeniería, con los flujos de recetas rehechos de punta a punta.

Al avanzar hacia la implementación trabajé de cerca con el líder de ingeniería y el equipo de front-end para asegurar un handoff limpio. Todos los componentes se entregaron por Figma, con specs documentadas, guías de espaciado y anotaciones de comportamiento pensadas para layouts responsive.

Hicimos check-ins semanales entre diseño y desarrollo para validar entornos de staging, aclarar comportamientos de componentes y priorizar ajustes según escenarios de uso reales.

Una mejora clave fue optimizar los targets táctiles y la densidad del layout después de ver a personal de cafetería usar el sistema en el celular con guantes puestos, o con muy poco tiempo. Para el lanzamiento, todos los recorridos clave —de navegar recetas a los resúmenes de pedido— estaban validados en todos los breakpoints y roles.

La solución actualizada incluye hoy un sistema de diseño con reglas hechas con y para los usuarios reales, y para nuestro equipo de desarrollo trabajando con la librería Kendo React junto a nuestros primeros componentes propios.

Con instrucciones de diseño escritas en el lenguaje de los desarrolladores, el objetivo era tender un puente entre las expectativas de diseño y la realidad del stack, los recursos y el tiempo disponible.