Sakura Sushi

El problema

La mayoría de las apps de reservas tratan el proceso como una transacción simple: elige una fecha, elige una hora, listo. Pero para usuarios con restricciones dietéticas, alergias o quienes organizan comidas grupales, la falta de información nutricional y de menú accesible los obliga a salir de la app — buscar en la web del restaurante, llamar con antelación o directamente elegir otro sitio.

Sakura Sushi nació de una pregunta: ¿y si la experiencia de reserva también ayudara a los usuarios a tomar decisiones informadas sobre lo que van a comer?

Investigación y Descubrimiento

Empecé con la suposición de que la mayoría de los usuarios solo quieren reservar rápido y seguir con su día. Las primeras entrevistas desmontaron esa idea directamente.

Las conversaciones con usuarios potenciales revelaron dos grupos desatendidos: personas que gestionan alergias alimentarias y necesitan detalle a nivel de ingredientes antes de comprometerse con un restaurante, y usuarios que organizan comidas para otros — padres con hijos que tienen necesidades dietéticas médicas, o profesionales que reservan para grupos con preferencias variadas. Para ambos grupos, una reserva sin confianza en el menú era una reserva que no harían.

Esto redirigió el diseño de “reserva rápida” hacia “reserva informada” — la velocidad seguía importando, pero no a costa de la información que los usuarios realmente necesitaban para sentirse seguros eligiendo un restaurante.

Personas

De la investigación surgieron dos personas que anclaron las decisiones de diseño:

Rachel, 26 — Desarrolladora Web Junior. Vive con múltiples alergias alimentarias. No reserva en ningún sitio sin revisar los ingredientes primero. Su proceso actual implica cruzar información entre la web del restaurante, apps de alergias de terceros y a veces llamar directamente. Necesita transparencia de ingredientes integrada en la experiencia, no añadida como un parche.

Thomas, 35 — Director de Operaciones. Reserva cenas frecuentemente para clientes y compañeros con necesidades dietéticas diversas. No puede permitirse una reserva que termine en una situación incómoda en la mesa. Necesita evaluar rápidamente si un restaurante puede acomodar a un grupo — no solo si hay mesa disponible.

Proceso de diseño

Del papel a los píxeles

Empecé con bocetos en papel para explorar opciones de layout sin apegarme a los detalles visuales. El concepto inicial colocaba reservas, menú e información del restaurante en pestañas separadas — un patrón convencional que en papel parecía lógico.

Lo que revelaron las pruebas

Las pruebas de usabilidad con cinco participantes expusieron tres problemas que no había anticipado:

1. La app no se leía como una herramienta de reservas. Como el contenido de menú y recetas era prominente, varios participantes asumieron que la app era una plataforma de recetas. La función principal — reservar — no quedaba clara a primera vista.

2. La reserva se sentía fragmentada. Dividir los campos de reserva en varias pantallas creaba fricción innecesaria. Los participantes perdían el hilo de sus selecciones y querían ver todo en un solo lugar antes de confirmar.

3. Todos preguntaron por el acceso sin cuenta. Sin que se les preguntara, varios participantes cuestionaron por qué era necesario crear una cuenta. Para una reserva de restaurante, la expectativa era de bajo compromiso — más cercano a pedir un café que a registrarse en un servicio.

Estos hallazgos impulsaron tres rondas de iteración, cada una vinculada directamente a un insight específico del testing.

Soluciones

Replanteando la pantalla principal

El primer rediseño priorizó reservas y acceso al menú como las dos acciones principales en la pantalla de inicio. El contenido de recetas — que los usuarios valoraban pero confundían con el propósito de la app — se reposicionó como función secundaria. Este único cambio resolvió la confusión de identidad sin eliminar funcionalidad.

Reserva en Una pantalla con confirmación

Todos los campos de reserva se consolidaron en una sola interfaz: fecha, hora, tamaño del grupo y preferencias de asiento visibles a la vez. Se añadió una pantalla de confirmación como paso final, mostrando cada detalle antes del envío. Los participantes en el testing posterior reportaron sentirse más en control del proceso.

Autenticación Flexible

Se introdujeron tres vías: inicio con Google para rapidez, registro por email para usuarios que querían guardar preferencias, y acceso como invitado para quienes hacían una reserva puntual. Esto eliminó el mayor punto de fricción sin sacrificar los beneficios de las cuentas para usuarios recurrentes.

Recetas como función de retención

En lugar de eliminar la sección de recetas, se reposicionó como valor añadido — una forma de que los usuarios recrearan platos del restaurante en casa. Esto respondía a un patrón de comportamiento real observado durante la investigación: los usuarios que disfrutaban una comida solían buscar recetas similares después. Mantener esta función sostenía el engagement más allá del momento transaccional de la reserva.

Reflexiones finales

La mayor lección de este proyecto fue lo rápido que las suposiciones iniciales se desmoronaron con la investigación. Lo que empezó como un brief de “hacer la reserva más rápida” se convirtió en un problema más matizado sobre confianza informativa — los usuarios no solo querían reservar, querían reservar sabiendo que habían tomado la decisión correcta.

Si continuara iterando, me centraría en dos áreas: añadir filtrado de alérgenos directamente en la experiencia de navegación del menú, y explorar cómo el caso de uso de Thomas — reservas grupales con necesidades dietéticas mixtas — podría estar mejor soportado con previsualizaciones de reserva compartibles.

Este proyecto reforzó algo a lo que sigo volviendo: las decisiones de diseño más útiles nacen de observar a las personas luchar con algo que creías obvio.