Rediseño de la agenda
Una agenda pensada para reservas con más de un servicio
- Mi rol
- Diseño de producto e implementación del front
- Estado
- Exploración con el front funcionando en staging, sin backend ni testeo con usuarios
- Origen
- El proyecto estaba en el roadmap del producto
Rediseñé la agenda de un SaaS de reservas, la pantalla donde los negocios pasan la mayor parte del día, y la implementé yo mismo en código hasta staging. Por confidencialidad no muestro pantallas: cuento el problema, las decisiones y por qué quedó como exploración.
El problema
Los comercios de belleza (peluquerías, manicuras, centros de estética) pedían mucho una forma de reservar varios servicios para un mismo cliente, consecutivos o simultáneos, en el mismo día.
El sistema registraba cada servicio como una reserva independiente, sin ninguna conexión con las demás. Eso generaba dos problemas:
- Agendar llevaba más tiempo, porque cada servicio se cargaba por separado.
- La agenda se desordenaba. Si un cliente cambiaba el día de su cita y alguien movía una sola de sus reservas, las otras quedaban en el horario anterior. Con más de una recepcionista trabajando sobre la misma agenda, el problema se multiplicaba.
A eso se sumaban dos límites de la interfaz: la reserva se creaba en un modal que tapaba la agenda, con varias tabs cargadas de información, y un sidebar de filtros persistente ocupaba gran parte de la pantalla.
Decisiones
Reservas multiservicio Una reserva puede incluir varios servicios, consecutivos o simultáneos. Los servicios quedan vinculados y se editan en conjunto: si el cliente cambia de día, se mueven todos juntos. Cuando hace falta, se pueden desconectar para manejarlos por separado. También se pueden mover con drag and drop.
De modal a panel lateral La reserva se crea en un panel lateral, así la agenda sigue a la vista mientras se completa. Quien agenda puede consultar la disponibilidad sin cerrar nada.
Menos información visible, los mismos accesos Las tabs del modal mostraban demasiado a la vez. En el panel dejé visible solo lo necesario para reservar, y moví el resto a un menú “más”. Cada opción de ese menú se abre en una pantalla aparte, para no cortar el flujo de la reserva.
Microinteracciones con propósito Al crear una reserva, una animación la señala en la agenda para que sea fácil encontrarla. Si queda fuera de la parte visible, la agenda hace scroll hasta ella.
Filtros en línea Reemplacé el sidebar persistente por filtros en línea en la parte superior, y la agenda ganó el espacio que ocupaba.
Implementación
Después del diseño, implementé el front en código hasta dejarlo funcionando en staging. Poder llevar una idea de este tamaño del Figma a algo que se puede usar es lo que más me interesa mostrar de este proyecto.
Por qué no llegó a producción
Era un proyecto ambicioso y la empresa cambió de prioridades. Se despriorizó antes de conectarlo con el backend y de testearlo con usuarios, así que quedó el front activo en staging.
Lo que me llevo
- Un cambio de estructura, como vincular reservas, resuelve más que cualquier mejora visual. El problema real estaba en el modelo, no en la pantalla.
- En un proyecto de este tamaño, testearía antes con una versión mínima, por ejemplo solo el multiservicio sobre la agenda actual, para validar con usuarios mientras el resto avanza.