01 · Resumen
Es una herramienta para centralizar la gestión diaria de negocios que funcionan con membresías: gimnasios, estudios y espacios donde las personas pagan por un periodo o por una cantidad de usos. Organiza quiénes son los clientes, qué plan tienen, cuándo vence su membresía, si asistieron hoy y si pueden entrar en este momento.
La utilizan las personas que operan el negocio: quien recibe a los clientes en el mostrador, quien administra sedes y usuarios, y quien necesita saber cómo va todo. Es necesaria porque esa información suele vivir repartida entre una hoja de cálculo, un chat y la memoria de alguien, y cada traspaso manual es una oportunidad para el error.
El reto no era añadir más funciones. Era hacer que la operación diaria pudiera entenderse y realizarse con menos pasos.
La escena de la izquierda resume cómo se gestiona hoy en muchos negocios; la de la derecha, cómo lo reúne el sistema.
02 · El problema
Estos no son hallazgos de un informe: son situaciones observadas durante el diseño y la construcción del producto, presentes en la forma en que operan hoy muchos gimnasios y negocios con membresías.
03 · Usuarios y contexto
No trabajamos con personas inventadas: definimos perfiles funcionales a partir de cómo se opera este tipo de negocio. Una misma interfaz no puede mostrarle lo mismo a todos, porque cada perfil necesita otra cosa y la necesita a otra velocidad.
04 · Objetivos del producto
Todo lo que el negocio necesita para operar vive en la misma herramienta, no en cinco.
Las tareas frecuentes —buscar, validar, renovar— se resuelven en el menor número de pasos posible.
El estado de una membresía se ve de inmediato, sin abrir nada ni interpretar nada.
Los permisos definen qué puede consultar o modificar cada usuario. Menos opciones a la vista, menos errores.
05 · Arquitectura de información
La estructura separa lo que se usa muchas veces al día de lo que se configura pocas veces al mes. Es la misma lógica que ordena la navegación real del sistema: la operación diaria siempre a un clic; la administración, agrupada y apartada.
Se agrupan porque comparten el mismo momento de uso: atender a una persona que está al frente.
Definen cómo funciona todo lo demás. Se separan para que la operación diaria no conviva con opciones delicadas.
Acompañan a todos los módulos sin pertenecer a ninguno.
Existen o se están construyendo. No las presentamos como terminadas.
06 · Flujos principales
Un flujo es, simplemente, la secuencia de pasos para completar una tarea. Estos cuatro son los que más se repiten, y cada uno se diseñó para resolverse sin salir del contexto donde empieza.
Cliente → plan → membresía → confirmación. El paso más frecuente al iniciar una relación con el negocio.
La vigencia se calcula a partir del plan elegido: quien registra no tiene que hacer cuentas de fechas.
Código o búsqueda → comprobación de vigencia → permitido o denegado → asistencia registrada.
Si el acceso es válido, la asistencia se registra sola. Nadie tiene que acordarse de anotarla después.
Perfil → historial → renovación → nueva vigencia. Todo ocurre dentro del perfil del cliente.
La renovación queda en el historial del cliente: se puede saber después quién la hizo y cuándo.
Seleccionar periodo → registrar congelamiento → extender la fecha final. Para viajes, lesiones o pausas.
Los días congelados no se pierden: la fecha final se extiende exactamente lo que duró la pausa.
07 · Decisiones UX
Cada una de estas decisiones existe en el producto y responde a un problema operativo específico. Aquí están tal como se tomaron.
Quien atiende necesita saber al instante si una membresía está activa, vencida, congelada o próxima a vencer. El estado aparece primero, en color y en texto; el detalle, después.
El perfil del cliente reúne membresía, historial, asistencias, notas y acciones principales. Lo que antes exigía abrir varios lugares, ahora es una sola pantalla.
Los permisos limitan qué puede consultar, crear, editar o eliminar cada usuario. La opción que no corresponde a tu rol no aparece: no hay que resistir la tentación de tocarla.
Renovar, congelar o consultar el historial se hace sin abandonar el perfil. Salir de la pantalla en la que estás trabajando es la forma más rápida de perder el hilo con alguien al frente.
Al validar un acceso, la respuesta es inequívoca: permitido o denegado, en texto y con contraste, visible desde lejos. Nadie debería tener que acercarse a la pantalla para interpretarla.
08 · Perfil del cliente
Casi todo lo que ocurre en el sistema —renovar, congelar, validar, anotar— empieza y termina en el perfil de un cliente. Por eso reúne sus datos, el estado de su membresía, su plan y vigencia, sus asistencias, su historial y las acciones principales.
Información inmediata. Nombre, estado y vigencia se leen sin hacer scroll ni abrir nada.
Acciones principales. Renovar y congelar están siempre a la vista, junto a la persona a la que afectan.
Historial. Renovaciones, congelamientos y eventos quedan registrados en orden.
Continuidad. Todo se resuelve aquí: no hay que saltar a otro módulo y volver a buscar.
Reconstrucción del perfil con datos de demostración.
09 · Validación de acceso
En la puerta no hay tiempo para interpretar. La pantalla de validación responde una sola pregunta —¿puede entrar esta persona?— y lo hace en texto, con contraste y sin ambigüedad. El color acompaña; nunca es el único indicador.
Los dos estados reales de la pantalla de validación. El motivo del rechazo siempre se explica en texto.
10 · Roles, permisos y sedes
Un sistema con varios usuarios necesita controlar qué puede hacer cada uno. En NIX Membership existen el propietario, la administración y la recepción, además de roles personalizados con permisos específicos y una sede asignada.
El objetivo no es mostrar más opciones de control: es evitar que cada usuario vea o modifique información que no necesita. Los permisos —qué puede consultar, crear, editar o eliminar alguien— forman parte de la experiencia, no son un detalle técnico.
11 · Multiempresa En evolución
El producto evoluciona hacia una arquitectura donde varias empresas pueden usar el mismo sistema sin ver nada de las demás. Cada una tiene sus propios clientes, planes, membresías, sedes, usuarios y configuración. Esta parte sigue en desarrollo, así que la contamos como lo que es: trabajo en curso.
12 · Sistema visual
La interfaz se construye con un conjunto corto de componentes: estados, botones, campos, filas de tabla y navegación. Cuantos más módulos crecen, más importa que estas piezas se comporten igual en todas partes.
Piezas reales del sistema, ampliadas. El color señala estados; la identidad se mantiene en violeta.
13 · Diseño y desarrollo
En NIX Membership, diseño y construcción no son etapas separadas: cada pantalla se dibujó sabiendo que tendría que funcionar con estados vacíos, membresías vencidas, varias sedes, permisos distintos, datos incompletos y acciones críticas.
El sistema está construido con HTML, CSS y JavaScript en el frontend, y Node.js con Express y una base de datos MySQL en el backend, con manejo de sesiones, control de roles y permisos, diseño responsive y una arquitectura que evoluciona hacia el soporte multiempresa.
14 · Desafíos y decisiones
Mantener los datos de cada empresa completamente separados dentro de una misma plataforma.
Toda consulta y toda vista nacen ya filtradas por empresa: la separación no depende de que alguien se acuerde de aplicarla.
Controlar usuarios que solo deben operar en su sede, sin ver las demás.
Cada usuario tiene una sede asignada, y esa asignación delimita lo que puede consultar y registrar.
Construir permisos suficientemente finos —consultar, crear, editar, eliminar— sin volver el sistema imposible de configurar.
Permisos agrupados por categorías con roles base ya armados; lo personalizado es la excepción, no el punto de partida.
Gestionar membresías que se miden distinto: por días, por meses o por cantidad de usos.
Un mismo concepto de vigencia con reglas propias por tipo, para que renovar y validar funcionen igual en los tres casos.
Impedir asistencias duplicadas cuando alguien valida dos veces seguidas.
El registro de asistencia comprueba duplicados antes de guardar: validar de nuevo no vuelve a contar la visita.
Conservar la coherencia entre renovación, congelamiento y vigencia, que se afectan entre sí.
Las fechas se recalculan en un solo lugar del sistema; ninguna pantalla hace su propia aritmética de vigencias.
Evitar que usuarios sin permiso lleguen a cargar secciones restringidas.
La restricción vive en el servidor, no solo en el menú: aunque se conozca la ruta, la sección no se entrega.
15 · Estado actual
Preferimos contarlo tal como está. NIX Membership no es una promesa ni un producto cerrado: es un sistema en uso interno y en desarrollo, que crece con lo que aparece al operarlo de verdad.
El producto mejora mediante uso, pruebas y necesidades nuevas que aparecen en la operación real. No publicamos porcentajes de avance: cambiarían antes que esta página.
16 · Aprendizajes
Una interfaz administrativa también merece diseño. Que la use personal interno no justifica que sea confusa; al contrario: la usan más horas al día que cualquier otra pantalla.
Simplificar no es quitar información. Es decidir qué se ve primero, qué se ve después y qué no hace falta ver nunca desde ese rol.
Los permisos son experiencia de uso. Definen qué existe para cada persona; una pantalla con opciones que no puedes tocar es una pantalla mal diseñada.
Un estado que hay que interpretar es un estado que va a fallar. “Activa”, “Vencida” o “Congelada” tienen que leerse igual con prisa que con calma.
Construir revela lo que el mockup esconde. Los datos incompletos, los estados vacíos y los casos límite no aparecen en una maqueta; aparecen en el uso.
La consistencia se vuelve más valiosa cuanto más crece el sistema. Con dos módulos, cada excepción se perdona; con once, cada excepción se paga.
Cuéntanos cómo trabaja tu negocio hoy. Estudiamos el proceso contigo y definimos si lo que necesitas es un sistema, una mejora de experiencia o una herramienta a medida.
