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 Figma 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 les permitiría incrementar su actividad académica - es decir, no resolvía la razón de fondo por la que el instituto quería esta herramienta.
El diagnóstico real: el modelo operativo era eficiente, pero el cuello de botella no estaba en el software - estaba en la falta de una persona dedicada a la administración y asistencia de tutores y estudiantes.
"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ó.