Contexto
El brief supone un gimnasio donde recepción atiende ingresos y consultas mientras administración revisa cuotas. La persona que opera el sistema necesita resolver una situación concreta sin recorrer todo el historial del socio. No se presume un estudio previo: roles, permisos y reglas de ingreso forman parte de lo que habría que definir.
Se contempla que un pago pueda estar pendiente, registrado o sujeto a revisión, y que esas diferencias afecten tareas distintas. Un vencimiento no debería confundirse con un acceso rechazado. La propuesta evita tratar al socio como una fila aislada: su estado requiere contexto y una referencia clara al registro que lo explica.
El desafío
El problema es decidir qué atender primero cuando conviven tareas administrativas e ingresos en tiempo real. Un dashboard lleno de cifras no explica qué necesita acción. Además, un rechazo sin motivo puede generar una discusión en recepción; el diseño debe distinguir información operativa, decisión del sistema y acciones autorizadas para resolverla.
Alcance de la propuesta
Se prevén dashboard de pendientes, listado de socios, ficha individual, registro de pagos y control de accesos. Los recorridos incluirían búsqueda de una persona, revisión de su situación y consulta del motivo de ingreso. No se propone desarrollar cobros, lectores físicos ni reglas automáticas: esas integraciones necesitarían especificaciones propias.
Decisiones de diseño
Pendientes antes que cifras
El dashboard se organizaría por tareas que requieren revisión, con enlaces al registro correspondiente. Los pendientes incluirían una explicación y no solamente una cantidad. Así recepción o administración podrían entender qué corresponde hacer, evitando que un indicador general compita con una situación que necesita atención inmediata.
Estados de pago explícitos
En socios y pagos, cada estado tendría texto, fecha de referencia cuando exista y acceso al detalle. El color acompañaría, pero no reemplazaría la etiqueta. La intención es distinguir una cuota pendiente de un registro en revisión y evitar que una marca visual se interprete como una sanción.
Explicar el acceso
La pantalla de accesos mostraría permitido o rechazado junto con el motivo y el socio identificado. También indicaría la fuente de la condición y las acciones disponibles según permisos. Esto permitiría explicar la situación sin suponer que la persona operadora puede modificar cualquier dato o autorizar excepciones.
La solución
Una persona llega al gimnasio y recepción busca su registro. Pulso presentaría el resultado de acceso y su explicación. Ante una condición pendiente, se podría abrir la ficha, revisar el pago relacionado y derivar la tarea a administración. El registro del ingreso conservaría su contexto, incluso si posteriormente cambia la situación del socio.
Adaptación móvil
En móvil, las tareas pendientes y la búsqueda serían el punto de entrada. Las tablas se convertirían en registros resumidos con detalle desplegable, sin esconder los estados. El resultado de acceso ocuparía un bloque legible y la información personal quedaría limitada a lo necesario para identificar al socio en esa situación.
Qué resuelve la propuesta
El diseño propone una operación basada en acciones y motivos, no en indicadores aislados. Requeriría validar las prioridades de cada rol, la interpretación de estados y el manejo de excepciones. Antes de implementar habría que definir permisos, actualización de pagos, privacidad y comportamiento cuando el sistema no puede confirmar un acceso.