Estudio de caso2025BoliviaEdTech · Consultoría
Un sistema diseñado para centralizar la coordinación de clases, horarios y pagos - y que terminó recomendando no construirse, al menos no todavía.
El Instituto Cervantes encargó la conceptualización de un sistema de gestión académica para resolver un problema operativo concreto: docentes y estudiantes coordinando clases, horarios y pagos sin una herramienta centralizada.
Lideré el equipo de 3 personas a cargo del research, la especificación de producto (PRD y FRD) y las pruebas de uso - en un ciclo de 6 semanas. Mi rol cubrió la dirección del research, el diseño de interfaz y, además, el diseño de la lógica de negocio del sistema.
Gestión de clases futuras y tablero centralizado de seguimiento de su actividad académica. Confirmación de asistencia dentro de ventanas de tiempo específicas.
Gestión de estudiantes asignados, clases, reprogramación y pagos pendientes por horas impartidas. Lanzamiento de reuniones Google Meet desde la app.
El sistema administraba automáticamente la disponibilidad del docente mediante un esquema de confirmación en dos ventanas de tiempo - 2 días antes o 30 minutos antes de la clase. Si el docente no confirmaba, el sistema asignaba un tutor de emergencia automáticamente. Esta regla de negocio fue diseñada por mí como parte de la especificación, no como requerimiento previo del cliente.
Vista del estudiante
Vista del docente
Vista de la institución
Construcción del PRD y FRD a partir de los objetivos del Instituto Cervantes, definiendo el alcance funcional antes de prototipar: gestión de clases, pagos, reprogramación y el esquema de confirmación con fallback a tutor de emergencia.
Prototipo funcional en Angular testeado con 4–6 docentes reales del instituto. Yo simulé el rol de estudiante durante las sesiones para evaluar interacciones entre roles sin depender de una segunda muestra.
Los docentes piloto describieron el sistema como funcional e intuitivo. No hubo fricciones de navegación ni confusión sobre cómo operar las funciones principales.
Pero en las entrevistas posteriores al testing surgió algo que no tenía que ver con la interfaz: los docentes expresaron que el sistema mejoraba su organización pero no cambiaría su disponibilidad real para asumir más horas académicas. Un docente con más tiempo libre no toma automáticamente más clases.
Ese era el problema de fondo: si los docentes no incrementaban su carga horaria, el instituto no vería crecer su base de estudiantes - y de todas formas tendría que contratar personas nuevas. El software resolvía la logística, pero no el cuello de botella real del modelo de negocio.
"El sistema resolvía el problema que se le pidió resolver. El problema real era otro, y solo apareció después de escuchar a los usuarios más allá de si la interfaz les resultaba fácil de usar."
En lugar de avanzar al desarrollo técnico del LMS, recomendé priorizar un cambio operativo: contratar una persona encargada de la administración y asistencia de tutores y estudiantes - antes, o en paralelo - de invertir en la construcción completa del sistema.
Tomar en serio una pista que no encajaba con el plan requirió ir más allá del testing de usabilidad: revisar documentación y conversar con quien tenía el contexto estratégico del cliente.
Diseñar la lógica del sistema - las reglas de confirmación, el fallback a tutor de emergencia - entrenó una mirada más amplia sobre el problema operativo completo.
No pude dar seguimiento al proyecto tras la decisión. Es una limitación real de este caso, y la menciono con honestidad en lugar de presentar un cierre que no ocurrió.