Un estudio conceptual de Webtrix de una app de reparto de comida de barrio, pensada para el pago contra reembolso, en francés y árabe.
Tipo
Estudio conceptual (producto ficticio)
Duración
5 semanas
Herramientas
Figma, Useberry
Equipo
Estudio de diseño de Webtrix
Contexto
MunchRun es una app ficticia de reparto de comida imaginada para una ciudad marroquí, que conecta a clientes con restaurantes locales. El encargo es específico del mercado: muchos clientes aún pagan en efectivo en la puerta, usan el francés y el árabe indistintamente y esperan que se les cuente con palabras sencillas qué pasa con su pedido.
El estudio abarca todo el recorrido de pedido, desde encontrar un restaurante hasta valorar la entrega, con foco en la rapidez, la claridad y la confianza.
2
Idiomas: francés y árabe (RTL)
3
Vías de pago: efectivo, tarjeta, monedero
22
Pantallas clave diseñadas
El recorrido de pedido hoy
Las apps de reparto pierden clientes en el mismo punto: cuando personalizan un artículo y pagan. Patrones confusos, falta de información en vivo y un pago que da por hecho la tarjeta empujan a la gente al teléfono o a WhatsApp. Estos son los problemas que asumimos como punto de partida y frente a los que diseñamos.
- La personalización de un artículo se reparte entre varias pantallas
- Hacer un pedido lleva muchos minutos porque nada se recuerda
- El seguimiento del pedido muestra una estimación fija en lugar de lo que está ocurriendo
- Los clientes habituales no tienen una vía rápida para repetir un pedido
- El pago contra reembolso se trata como algo secundario y no como una vía de pago de primer nivel
Descubrimiento
Un descubrimiento documental: recorrimos seis apps de reparto, mapeamos los tres recorridos que importan y anotamos dónde cada una pide al cliente pensar más de lo necesario.
6
Apps de reparto analizadas
3
Recorridos mapeados
2
Idiomas considerados en el diseño
Lo que destacó
- Las pantallas de personalización piden demasiadas decisiones a la vez
- Se espera seguimiento en vivo, pero la mayoría de las apps da una estimación fija
- Repetir un pedido es la tarea más frecuente y la menos diseñada
- El descubrimiento de restaurantes carece de filtros que reflejen los hábitos locales (abierto ahora, acepta efectivo, reparte en mi barrio)
Direcciones exploradas
Un sprint de diseño de dos días con preguntas «¿cómo podríamos…?», mapeo de afinidades y storyboards produjo dos direcciones sólidas.
Elegimos «QuickFlow»: un concepto pensado para reducir la fatiga de decisión con valores predeterminados inteligentes, preferencias guardadas y repetición del pedido con un toque en cada punto de contacto.
Tres recorridos
Mapeamos tres recorridos: un cliente nuevo que descubre un restaurante, un cliente habitual que repite un pedido y el seguimiento del pedido en vivo. El objetivo de diseño es un pedido realizado en menos de tres minutos.
- Del descubrimiento al carrito - feed personalizado con filtros inteligentes y fichas de restaurante con tiempos de espera en vivo
- De la personalización al pago - configurador de artículo en una sola pantalla, con ventas adicionales integradas y preferencias guardadas
- Seguimiento posterior al pedido - vista de mapa en vivo con notificaciones push y cuenta atrás de la hora estimada de llegada
Wireframes
Objetivo de diseño: un pedido realizado en menos de tres minutos, en efectivo o con tarjeta.
Wireframes de 22 pantallas clave, de bocetos a maquetas de fidelidad media a lo largo de tres iteraciones, con cada pantalla dibujada en francés (de izquierda a derecha) y en árabe (de derecha a izquierda).
Objetivo de diseño: un pedido realizado en menos de tres minutos, en efectivo o con tarjeta.
Estilo visual
La dirección visual debe resultar enérgica y apetecible sin perder rapidez ni funcionalidad: un sistema cálido y de alto contraste, con una paleta de azafrán y carbón y componentes redondeados que mantienen un tono cercano.
Cómo lo probaríamos
El prototipo de alta fidelidad está construido en Figma. No se ha probado con clientes reales; este es el plan que ejecutaríamos antes de desarrollar, usando Useberry para sesiones remotas.
6 Participantes previstos por ronda 3 Rondas de pruebas previstas 90% Objetivo: tasa de éxito en las tareas
La prueba de un flujo de pedido de comida es sencilla: ¿puede alguien con hambre pedir sin pensar?
Iteraciones de diseño
Iteración 1: Un flujo de personalización de cuatro pasos condensado en una sola hoja inferior. Objetivo de diseño: menos pantallas entre elegir un plato y añadirlo.
Iteración 2: Se añadió un acceso directo permanente «Repetir pedido» en la pantalla de inicio para clientes habituales. Objetivo de diseño: que la tarea más frecuente sea la más rápida.
AntesDespuésEl diseño propuesto
La propuesta, «QuickFlow», es una experiencia de pedido rápida con una identidad visual fuerte. Sus funciones principales:
- Repetir pedido con un toque, con preferencias y última dirección de entrega guardadas
- Descubrimiento inteligente de restaurantes con indicadores de tiempo de espera en tiempo real
- Personalización de artículos en una sola pantalla con complementos integrados
- Seguimiento del pedido en vivo con mapa animado y avisos de entrega
- Feed de inicio personalizado según el historial de pedidos y la hora del día
- Efectivo contra reembolso, tarjeta y monedero como vías de pago equivalentes, con gestión clara del cambio y del recibo
- Francés y árabe con diseños completos de derecha a izquierda
- Estándares de contraste WCAG AA y de áreas táctiles como objetivos de diseño
Objetivos de diseño
< 3 min
Objetivo: tiempo para hacer un pedido
1 toque
Repetir pedido para clientes habituales (diseño)
-30%
Objetivo: abandono del carrito
Son objetivos de diseño de un estudio conceptual, no resultados medidos: la app no se ha construido ni probado con clientes reales.
En una app de comida, la rapidez y la confianza importan más que la riqueza visual.
Lo que nos enseñó el estudio
- En las apps de comida, la rapidez y la confianza importan más que la riqueza visual
- Los flujos de repetición de pedido reciben poca inversión en la mayoría de las apps de reparto, pese a ser el caso de uso más frecuente
- El movimiento y las microinteracciones mejoran de forma notable el rendimiento percibido
- Diseñar con menús reales de restaurantes (y no con contenido de relleno) revela los casos límite pronto
- Tratar el pago contra reembolso como una vía de primer nivel cambia el pago, el recibo y el flujo del repartidor
Si esto se construyera
- Validar el flujo con el plan de pruebas anterior antes de cualquier desarrollo
- Añadir pedidos en grupo para oficinas y familias
- Convertir el sistema de diseño en una biblioteca de componentes compartida con ingeniería
- Añadir sugerencias de comidas solo cuando exista un historial real de pedidos
