"Cada sensei lleva su propio Excel, y alguien tiene que juntarlo todo a mano."

Así describió el dueño del Dojang el problema en nuestra primera conversación. No llegó pidiendo una app: llegó describiendo una operación que ya había crecido más allá de lo que una hoja de cálculo por instructor podía sostener.

La investigación no fue un ejercicio simulado — fue un cuestionario real, respondido por el dueño real del negocio.

No hubo entrevistas formales con múltiples usuarios ni sesiones de investigación de agencia. El discovery fue directo: un cuestionario estructurado que Leonel, dueño de IDAR, respondió describiendo cómo opera su escuela hoy. Sus respuestas, no mis suposiciones, definieron el alcance del sistema.

Cuatro personas reales, no arquetipos inventados.

No construí personas ficticias con biografías de agencia: construí perfiles a partir de necesidades reales que el sistema de roles y permisos tiene que resolver todos los días, verificadas directamente con el flujo de trabajo que describió el cliente.

No se sistematiza todo a la vez — se sistematiza lo que más duele primero.

El problema completo (alumnos, pagos, clases, cintas, exámenes, diplomas, informes) era demasiado grande para atacarlo de un solo golpe sin arriesgar meses de desarrollo sin nada usable. Prioricé junto con el cliente los dos procesos que generaban más fricción diaria: el control de asistencia y el seguimiento de pagos. No por coincidencia, eran los que más tiempo le costaban a la administración central de consolidar a mano cada mes.

Dos roles, una fricción mínima.

La decisión de diseño más importante del proyecto: los padres de familia nunca instalan nada. Solo reciben un mensaje de WhatsApp con el comprobante. Toda la complejidad vive del lado del instructor.

De un prototipo funcional a un producto con identidad propia.

El primer MVP funcionaba perfecto, pero se veía como cualquier tutorial de React Native: azul de Material Design por default, sin tipografía jerárquica, sin iconografía. Definí un sistema de tokens real (color, tipografía, radios, espaciado) y lo apliqué de vuelta al código, pantalla por pantalla.

El prototipo no fue el final del proceso, fue el punto medio.

Diseñé 14 pantallas de alta fidelidad en Figma (incluyendo estados vacíos y de error, no solo el camino feliz) y las llevé directo a código: Expo (React Native) para la app, Supabase como backend con Row Level Security real, y un modelo de datos que creció de 3 tablas iniciales a 7 tablas relacionadas conforme el sistema de roles y el modelo de negocio se volvieron reales.

De un número en el dashboard a una acción concreta.

"Pagos pendientes" ya existía como métrica desde el primer MVP, pero era solo un dato: no decía quién debía ni qué hacer al respecto. Este módulo lo convierte en una lista accionable: el sistema compara cada alumno contra los pagos registrados del mes actual y separa automáticamente quién está al día de quién no.

Cuatro roles, un mismo dato, permisos distintos.

Dueño, administración, sensei y auxiliar ven la misma base de datos, pero nunca la misma información. Esto no se resuelve escondiendo botones en la pantalla: un botón oculto no protege nada si alguien puede llamar a la base de datos directamente. Se resuelve en el servidor, con Row Level Security de Postgres evaluando cada consulta según quién la hace.

El límite del plan gratuito no vive en la interfaz — vive en la base de datos.

Cada regla de negocio de este proyecto tuvo que traducirse en una decisión de arquitectura concreta, no solo en una nota de producto. "Administración no debe ver ingresos totales" se convirtió en una función de base de datos con validación de rol. "Tres grupos gratis, después se paga" se convirtió en un trigger de Postgres, no en un mensaje de la interfaz que cualquiera podría ignorar editando la petición directo a la API. Antes de ofrecer esto a una segunda escuela, necesitaba un plan free real. Definí los límites con la operación real del Dojang como referencia: su propia estructura de grupos fue el piso mínimo del plan gratuito, no un número arbitrario.

Un piloto en manos del cliente cambia qué es "urgente" construir.

Con el sistema base ya funcionando, el trabajo se volvió menos sobre arquitectura y más sobre fricción real de uso: cosas que solo aparecen cuando alguien que no eres tú, sin tu contexto, intenta dar de alta a un colaborador nuevo un martes en la noche.

El cliente reportó un error. La causa no estaba en el código que revisé primero.

Leonel intentó consultar el perfil de un alumno y le apareció "no se encontró este alumno", con la cuenta de dueño, que tiene todos los permisos. El error no era de permisos: era que su base de datos de producción no tenía las columnas que el código nuevo esperaba.

Construir en código real significa que las cosas se rompen — y eso también es parte del producto.

A diferencia de un prototipo en Figma, aquí hubo errores de sintaxis, cache corrupto, archivos que se sobrescribían entre sí, y navegación que fallaba silenciosamente. Documentar ese proceso, no solo el resultado, es parte de lo que hace este case study distinto.

Lo que funcionaba para un Dojang tenía que funcionar para la escuela de al lado.

Con el piloto estable, la pregunta cambió de "¿le sirve a Leonel?" a "¿le serviría a una escuela que nunca he visto?". Eso obligó a revisar cada decisión que daba por hecho que el usuario era un Dojang de Taekwondo, y a resolver lo que un producto público necesita y un piloto no: cobrar, proteger datos y conseguir usuarios.

Lo que este proyecto cambió en mi forma de pensar como product designer.

El piloto ya es un producto público. Lo que sigue es escalarlo.

Diseñar Academia Check-in me confirmó dónde quiero pararme como product designer.