2023–2025 UX/UI · Dev
POS System
El rediseño completo de un ecosistema de tres apps para la restauración. Partiendo de cero — literalmente.
Transformar un producto que funciona pero al que nadie quiere tocar en un ecosistema coherente, deseable y eficiente — para tres usuarios con necesidades radicalmente diferentes.
01 El contexto
Primera diseñadora de un producto que nunca tuvo una
BonApp es una startup de Lausana (family office MGMT) que crea una solución POS para restauración. Cuando llegué, el producto ya existía, funcionaba y tenía clientes reales. Con un detalle: nadie había hecho jamás trabajo UX/UI en él. Ni una maqueta, ni una investigación, nada en Figma.
El producto funcionaba por la pura fuerza de su lógica de negocio — y se las arreglaba sin la menor consideración por el usuario. Ahí entro yo, como primera diseñadora del equipo.
02 Parte I
El punto de partida
Seamos honestos: funcionaba, pero no estaba pensado para quienes lo usaban.
Estado de la cuestión
Interfaz poco atractiva, incoherente de pantalla a pantalla, y una lógica de uso que pedía al usuario adaptarse a la máquina y no al revés. Para un producto destinado a ser manipulado a toda velocidad durante el servicio, o por un cliente apurado por pagar, era un verdadero freno a la adopción.
Conservo estas capturas con cariño. No por nostalgia, sino porque cuentan la mitad de la historia: un rediseño solo se mide frente a su punto de partida.
El desafío
¿Cómo transformar un producto que funciona pero al que nadie quiere tocar en un ecosistema coherente, deseable y eficiente — para tres usuarios con necesidades radicalmente diferentes?
El cliente, que quiere pedir y pagar desde su móvil sin pensar. El camarero, que no tiene tres segundos que perder en plena hora punta. El manager, que pilota su restaurante y quiere controlarlo todo de un vistazo. Tres mundos, tres lógicas, un solo sistema que tenía que mantenerlos juntos — sobre un producto vivo, en producción, donde nuevas features caían regularmente.
03 Parte II
Tres apps, tres oficios
Tres usuarios con lógicas opuestas — un solo sistema que tenía que mantenerlos juntos.
01 Aplicación
Customer — la evidencia como objetivo
Pedir y pagar desde el móvil, sin fricción ni tutorial. El target es todo el mundo: del nativo digital al cliente que descubre que puede pagar su café con un QR code.
El desafío era hacer el recorrido tan evidente que no se notara.
02 Aplicación
Waiter — la velocidad como restricción
Esta no existía. La idea: permitir al restaurante centralizar todo sobre el mismo sistema, sin depender de que el cliente use o no su móvil. Participé en la definición de las features y los requirements.
Concretamente, el camarero puede seleccionar mesas, navegar por los menús disponibles, pasar comandas, cobrar, imprimir tickets y acceder a las transacciones. Todo pensado para la velocidad: en plena hora punta, cada tap cuenta.
03 Aplicación
Manager — el puesto de pilotaje
Horarios, menú, precios, QR codes, estadísticas, transacciones, gestión de equipo. Donde el restaurador retoma las riendas de su establecimiento.
El desafío: hacer legible una cantidad considerable de parámetros, sin transformar la pantalla en cabina de avión.
04 Parte III
Las decisiones clave
Dos momentos donde el proyecto pivotó — la creación de un design system, luego la app Waiter diseñada desde cero.
01 Decisión clave
Crear el design system
Tras unas semanas, una constatación: pasaba muchísimo tiempo rediseñando componentes que ya había dibujado en otra parte. Con cada nueva pantalla, partíamos un poco de cero.
Así que tomé la iniciativa de crear un design system completo en Figma. No por amor al método por el método, sino porque era la única forma de mantener tres apps coherentes en evolución permanente.
El impacto no se hizo esperar: una verdadera coherencia entre las tres aplicaciones, un onboarding mucho más rápido para las nuevas personas, menos errores de diseño, y una colaboración con los desarrolladores notablemente más fluida.
02 Decisión clave
Diseñar la app Waiter
La app Waiter es mi terreno de juego de la página en blanco. Nada existía, todo había que inventarlo — y es probablemente el proyecto cuyo desafío era el más operacional.
El desafío central: diseñar una herramienta usable en plena hora punta. Un camarero que toma una comanda no tiene tiempo de buscar, de pensar en la navegación, o de corregir un error de manipulación. La interfaz debía desaparecer en favor del gesto.
Trabajé la definición de features con el equipo partiendo de las restricciones reales del servicio: rapidez de selección, legibilidad inmediata, recorrido de cobro sin desvío.
El puente diseño / código
Las manos en el código
Aquí está la parte que no había previsto amar tanto: puse las manos en el código, principalmente CSS, en React.
Primero por una razón simple — con ojo de diseñadora, el resultado final era inmediatamente más fiel a la intención. Los detalles que hacen que una interfaz sea “justa” se juegan a menudo a unos pocos píxeles, y esos píxeles, mejor regularlos yo misma.
Pero el verdadero regalo estaba en otra parte: tocar el código me hizo entender las restricciones técnicas desde dentro. Aprendí a diseñar no en abstracto, sino en función de la realidad de los medios que teníamos para realizar las cosas. Un diseño irrealizable es un bonito dibujo, no una solución.
No la que dibuja y tira sus maquetas por encima del muro esperando lo mejor, sino la que acompaña el producto hasta el píxel final.
05 Balance
El resultado en el terreno
Adopción, satisfacción, estructura: un producto que tomó suficiente importancia para construir un equipo a su alrededor.
Resultados
El producto fue adoptado por los restaurantes, los clientes estaban satisfechos, y constatamos una reducción de errores de uso. Partíamos de lejos — es precisamente lo que hace el resultado satisfactorio.
Y una señal que dice mucho: durante un año y medio, fui la única diseñadora. Luego el equipo creció con una persona, y me convertí oficialmente en Head of Design. El trabajo había tomado suficiente importancia para estructurar un equipo alrededor.
06 Aprendizajes
Lo que este proyecto me enseñó
Este proyecto me enseñó a diseñar para un producto vivo — que cambia, crece, y no espera que el diseño sea “perfecto” para avanzar. Me enseñó que los mejores diseños nacen en la intersección de lo deseable y lo factible, y que entender el código no quita nada a la creatividad: la vuelve operante.
Y me hizo pasar de diseñadora a Head of Design, es decir, de “dibujo pantallas” a “pienso un sistema y acompaño a un equipo”.
Nada mal, para un producto que ni siquiera tenía archivo Figma cuando llegué.
Trabajemos juntos
El próximo proyecto podría ser el tuyo.
luciebelleudy@outlook.com