Estudio de caso2025BoliviaEdTech · Consultoría

LMS · ProductoResearchRecomendación estratégica

El research que
recomendó no
construir.

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.

Rol
Consultor de Producto / UX
Equipo
3 personas
Duración
6 semanas
Estado
Recomendación aceptada
Entregables
Research · PRD · FRD · Prototipo Figma · Pruebas de uso · Recomendación estratégica
01 - Contexto

El problema que se veía y el que había que encontrar.

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.

02 - Qué hacía el sistema
Rol - Estudiante

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.

Rol - Docente

Gestión de estudiantes asignados, clases, reprogramación y pagos pendientes por horas impartidas. Lanzamiento de reuniones Google Meet desde la app.

Lógica de negocio diseñada

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.

03 - Prototipo Figma
04 - Proceso de research
Fase 01Especificació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.

Fase 02Pruebas de uso

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.

05 - El hallazgo

Usabilidad impecable.
Impacto académico limitado.

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."

06 - La recomendación

No construir todavía.
Contratar primero.

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.

Recomendación aceptada y adoptada como estrategia de lanzamiento
07 - Por qué importa este caso
Hallazgo inesperado

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.

Lógica como lente

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.

Honestidad sobre los límites

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ó.