Make It Real! Online
Se consolida el componente digital de práctica que acompañaba a los materiales impresos.
mironlineCASE STUDY · EDTECH · 2021—2023Más allá del libro.
mironline combina práctica de inglés general y profesional con seguimiento académico para estudiantes y docentes de educación superior en Latinoamérica. Entre 2021 y 2023 participé en su etapa de modernización como UI/UX Designer + Frontend.
ROL
UI/UX Designer + Frontend
PERIODO
Oct 2021 — Oct 2023
PRODUCTO
Plataforma educativa de inglés
STACK
Figma · HTML · CSS · JavaScript · Bootstrap · jQuery · GitLab · Google Analytics
Contexto
mironline es una plataforma en línea de práctica de inglés para estudiantes y docentes de educación superior en Latinoamérica. Surgió como evolución de Make It Real! Online, el componente digital que complementaba una serie de libros con práctica adicional.
Origen y evolución
Adaptación para Latinoamérica
El producto se reestructura para educación superior y contextos latinoamericanos.
mironline
Se desarrolla el LMS y se amplía la práctica con General English y Professional English.
Modernización UX/UI
Periodo documentado en este caso: migración web, responsive, sistema de interacción, validación e iteración.
Producto
El producto fue creciendo hasta integrar General English y Professional English: actividades de gramática, vocabulario, lectura y escritura, seguimiento de progreso y contenidos especializados por área profesional. También incorporó audio, video, modelos 3D y experiencias 360°.
El libro marcaba parte de la secuencia académica; mironline extendía esa práctica en digital y conectaba lo que hacía el estudiante con la información que el docente necesitaba para dar seguimiento.
LIBROS
Contenido y secuencia
GENERAL ENGLISH
Práctica del idioma
PROFESSIONAL ENGLISH
6 áreas profesionales
SEGUIMIENTO
Progreso y desempeño
Usuarios
La experiencia conectaba dos necesidades complementarias: practicar y avanzar en el curso, y dar seguimiento académico. Las láminas resumen el contexto de cada perfil; aquí destaco únicamente lo que condicionaba la interfaz.
01
Usuario principal
Estudiante
Usa mironline para practicar y resolver actividades desde distintos dispositivos.
Instrucciones claras por actividad.
Contexto visible mientras responde.
Feedback y avance fáciles de entender.
02
Usuario de seguimiento
Docente
Usa la plataforma para revisar cómo avanzan sus grupos y detectar dónde hace falta seguimiento.
Consulta rápida por grupo y alumno.
Progreso, calificaciones y desempeño.
Seguimiento sin recorrer demasiadas pantallas.
Cómo se organizaba la información
mironline conectaba la práctica del alumno con la información que el docente necesitaba para dar seguimiento.
mironline
Estudiante
CursoContenido y actividadesFeedbackProgreso
Docente
GruposAlumnosCalificacionesSeguimiento
Flujo principal del estudiante
01Entrar al curso
02Abrir actividad
03Leer instrucción
04Responder
05Recibir feedback
06Revisar avance
Flujo principal del docente
01Entrar a la plataforma
02Revisar grupos
03Consultar alumnos
04Ver progreso y calificaciones
05Detectar necesidades
06Dar seguimiento
Cómo se relacionan
El estudiante genera actividad, respuestas y progreso; la plataforma organiza esa información para que el docente pueda revisar desempeño y dar seguimiento al curso.
Estos perfiles condensan patrones reales de uso observados en estudiantes y docentes a lo largo del proyecto.
El problema
El contenido académico seguía siendo útil, pero una parte importante de la experiencia dependía de tecnología que ya impedía usarla con normalidad.
Para 2021, mironline ya acumulaba años de cursos y actividades publicadas. Parte de ese contenido dependía de Flash*, una tecnología utilizada durante años para ejecutar experiencias multimedia e interactivas dentro del navegador.
Cuando los navegadores dejaron de soportarla, el problema se volvió visible para el usuario: pantallas en blanco, actividades que no abrían en celular, avisos de incompatibilidad o reproductores que tardaban demasiado.
La modernización no consistía en copiar cada pantalla antigua a HTML. Cada actividad debía conservar lo que buscaba enseñar o evaluar mientras se reconstruía para web responsive y navegadores actuales.
*Adobe terminó el soporte de Flash Player en 2020 y bloqueó su ejecución en 2021. La plataforma necesitaba sustituir esa dependencia por tecnologías web actuales.
Lo que la solución tenía que conservar
01
El objetivo académico de cada actividad.
02
Uso en computadora, tablet y celular.
03
Compatibilidad entre navegadores y equipos.
04
Reglas compartidas entre ejercicios diferentes.
Análisis del contexto
mironline no era sólo una colección de ejercicios. Las decisiones de interfaz convivían con un modelo pedagógico, distintos niveles de inglés y necesidades concretas de estudiantes y docentes.
El material de trabajo del proyecto conectaba análisis situacional, necesidades del estudiante, uso del inglés en clase, ciclos de enseñanza y autonomía. Esa estructura ayudaba a entender por qué una interacción no podía diseñarse únicamente por apariencia.
Para producto, esto se traducía en una condición simple: la tecnología debía hacer más accesible la actividad sin romper la intención académica que había detrás.
01
Contexto antes que patrón
Syllabus, necesidades de estudiantes y preparación docente condicionaban la experiencia.
02
Más de una forma de aprender
Texto, contenido, tareas, habilidades, comunicación y descubrimiento convivían en el mismo producto.
03
Distintos niveles
La experiencia debía funcionar para grupos mixtos y favorecer autonomía e interacción.
04
Diseñar sin perder el objetivo
Cada componente tenía que ser consistente sin convertir actividades distintas en la misma interacción.
LECTURA DEL NODO
Racional pedagógico
El material conectaba contexto, necesidades, enseñanza y autonomía dentro de una misma lógica.
Investigación
Después de identificar la fricción técnica, la investigación debía separar problemas de acceso de problemas de comprensión, carga cognitiva y seguimiento académico. La pregunta no era sólo si una actividad abría, sino si permitía aprender, responder y continuar sin perder contexto.
Alumnos con alguna incidencia
≈30%
Durante la transición, los tickets de soporte y el seguimiento del equipo situaban las incidencias en torno a 30% de los alumnos activos.
Señales de usuario sintetizadas
25
Estudiantes13 · 52%
Docentes12 · 48%
El board reunió 13 señales de estudiantes y 12 de docentes para encontrar patrones comunes entre uso, soporte y seguimiento académico.
Preguntas de investigación
¿En qué punto se interrumpe una actividad y qué impide continuar?
¿Qué cambia entre computadora, tablet, celular y distintos navegadores?
¿Qué información necesita permanecer visible mientras el estudiante responde?
¿Qué feedback confirma que una respuesta fue registrada y qué sigue después?
¿Qué necesita consultar el docente para detectar avance, rezago o dificultades?
¿Qué objetivo pedagógico debe mantenerse intacto aunque cambie la interacción?
Fuentes de evidencia
Soporte
Tickets y reportes sobre acceso, compatibilidad, navegación, pantallas vacías y actividades que no cargaban.
Google Analytics
Dispositivos, navegadores, tráfico y comportamiento general de uso.
Datos académicos
Progreso, calificaciones, desempeño y finalización de actividades.
Alumnos y docentes
Comentarios después de releases, dudas en clase y conversaciones directas sobre la experiencia de aprendizaje.
Hipótesis de trabajo
01
Acceso estable
Señal
Pantallas en blanco, incompatibilidad, carga lenta y actividades bloqueadas antes de comenzar.
Supuesto
Si eliminábamos dependencias heredadas y normalizábamos compatibilidad, más alumnos podrían iniciar y terminar la actividad sin soporte.
Validar con
Revisar tickets, carga correcta en navegadores actuales y finalización de actividades.
02
Contexto persistente
Señal
Lecturas e instrucciones desaparecían o quedaban separadas de la respuesta.
Supuesto
Si el contenido necesario permanecía cerca de la tarea, el alumno tendría que recordar menos y podría responder con mayor continuidad.
Validar con
Observar finalización, dudas reportadas y comentarios sobre lectura, instrucciones y feedback.
03
Menor carga cognitiva
Señal
Algunas actividades mostraban demasiada información, preguntas y controles al mismo tiempo.
Supuesto
Si cada paso mostraba sólo lo necesario, sería más fácil identificar la tarea actual y continuar sin perderse.
Validar con
Comparar variantes, revisar abandono y registrar dudas recurrentes durante el uso.
04
Seguimiento académico visible
Señal
Docentes necesitaban revisar grupos, progreso, calificaciones y desempeño desde información dispersa.
Supuesto
Si agrupábamos la información por grupo y alumno, sería más rápido detectar quién necesitaba seguimiento.
Validar con
Contrastar la consulta con docentes y revisar el uso de vistas de progreso y calificaciones.
Análisis
Al agrupar reportes, datos y observaciones aparecieron patrones repetidos. El problema no era una sola pantalla: había fricción técnica, inconsistencias entre actividades y momentos donde el estudiante perdía información necesaria para aprender y responder.
Hallazgos clave
Compatibilidad
Flash, navegadores y comportamiento desktop-first bloqueaban actividades que todavía tenían valor académico.
Continuidad
Lecturas, instrucciones y feedback necesitaban permanecer cerca de la tarea para evitar pérdida de contexto.
Consistencia
Actividades distintas resolvían controles, estados y navegación de formas diferentes.
Escalabilidad
Con decenas de tipos de interacción, resolver cada actividad desde cero ya no era sostenible.
Lectura heurística
Los hallazgos también podían leerse desde principios clásicos de usabilidad, útiles para convertir problemas observados en criterios concretos de diseño.
Visibilidad del estado del sistema
Carga lenta, feedback poco claro y dudas sobre si una respuesta había sido registrada.
La interfaz debía comunicar carga, respuesta, error, acierto y progreso de manera oportuna.
Consistencia y estándares
Controles, navegación y estados variaban entre tipos de actividad.
Patrones compartidos reducían el reaprendizaje entre ejercicios.
Reconocimiento antes que recuerdo
El alumno debía volver a buscar lecturas o instrucciones para responder.
El contexto relevante debía permanecer visible o recuperarse sin esfuerzo.
Prevención y recuperación de errores
Incompatibilidades, actividades bloqueadas y pérdida de avance interrumpían la tarea.
La experiencia debía prevenir estados sin salida y explicar cómo continuar cuando algo fallaba.
Definición
La síntesis no se convirtió en una lista de features. La usamos para definir qué debía mantenerse estable en cualquier actividad y qué podía variar según el objetivo de aprendizaje.
Reto de diseño
¿Cómo migrar más de 30 tipos de interacción a web responsive sin perder el objetivo académico ni diseñar cada actividad desde cero?
Principios de diseño
Contexto disponible
La información necesaria para responder debía permanecer cerca, especialmente en lecturas y ejercicios largos.
Foco por tarea
La pantalla debía mostrar lo necesario para el paso actual y reducir elementos que compitieran por atención.
Patrones compartidos
Botones, estados y feedback debían comportarse de forma parecida aunque cambiara el tipo de actividad.
Criterios de aceptación
01
Funcionar en navegadores actuales sin depender de plugins.
02
Adaptarse a computadora, tablet y celular.
03
Mantener instrucciones, contexto y feedback disponibles durante la tarea.
04
Reutilizar controles, estados y reglas entre distintos tipos de ejercicio.
Alcance y rol
Dentro de esa modernización, mi alcance cubría el recorrido entre contenido pedagógico, diseño de interacción y frontend. Las actividades solían comenzar como documentos preparados por docentes y diseño instruccional; el trabajo de producto consistía en convertirlos en una experiencia usable y consistente.
Mi responsabilidad incluía definir jerarquía, instrucciones, controles, estados, feedback y comportamiento responsive, además de implementar gran parte de esas decisiones en HTML, CSS y JavaScript. Diseño y desarrollo ocurrían muy cerca, así que una solución podía ajustarse mientras se construía y después de publicarse.
Flujo de trabajo
01
entender la actividad
02
definir interacción
03
probar o prototipar
04
implementar
05
publicar
06
revisar datos y comentarios
07
ajustar
Equipo
1 developer1 diseñador gráficodocentesdiseñadores instruccionalespedagogos
Exploración técnica
En integraciones como Sketchfab primero probaba qué permitía la API. Cuando la interacción ya funcionaba, documentaba ese patrón en Figma para reutilizarlo después.
Ideación
30+ patrones de interacción
A partir de esos criterios fui diseñando y reutilizando patrones para distintos objetivos de aprendizaje. Algunas actividades eran simples; otras mezclaban lectura, audio, video o modelos 3D.
Multiple choiceReadingFill in the blankMatching & orderingAudio + textoModelos 3D
Hipótesis e iteración
Una actividad de lectura concentraba el texto y diez preguntas en una sola vista. El problema no era el contenido académico, sino cuánto tenía que procesar el alumno al mismo tiempo.
↔
Primera propuesta
Decisión
Lectura completa y diez preguntas visibles en una sola vista.
Mantener la lectura disponible y mostrar una pregunta por paso.
Hallazgo
- Había demasiado contenido compitiendo por atención.
- La lectura debía seguir disponible mientras se respondía.
- Cerrar y volver a abrir el texto agregaba pasos que no aportaban al aprendizaje.
Hipótesis
Si reducíamos la información simultánea sin esconder el texto de apoyo, el alumno podía concentrarse en una pregunta sin perder el contexto de lectura.
Decisión
Mantener la lectura disponible y mostrar una pregunta por paso.
Resultado
La nueva variante recibió mejores comentarios y mostró mayor finalización frente a las versiones más densas.
Sistema de diseño
Con más de 30 tipos de interacción, resolver cada pantalla desde cero dejó de ser práctico. Fui construyendo componentes y reglas en Figma a partir de lo que ya funcionaba en producción.
colores y espaciados
botones e inputs
variantes y estados
feedback de error y acierto
componentes reutilizables
responsive
light y dark mode
Design → Code
Figma → componente → frontend → revisión
Code → Design
prueba en código → ajuste → patrón funcional → documentación en Figma
Adaptación responsive
El celular dejó de tratarse como una versión reducida del escritorio. Cada actividad se revisaba según el espacio disponible y el tipo de interacción.
01
Cambiar el orden del contenido cuando hacía falta.
02
Mantener controles y estados fáciles de encontrar.
03
Evitar acciones que dependieran de hover.
04
Revisar la actividad en distintos navegadores y tamaños.
Aplicación especializada
Professional English llevaba el mismo sistema a contenido relacionado con seis áreas académicas. La interacción tenía que adaptarse al tipo de vocabulario y a la situación que se quería practicar.
Áreas de Professional English
Agricultura y medio ambiente
Ciencias computacionales
Ciencias sociales y humanidades
Construcción e ingeniería
Ciencias de la salud
Economía y administración
Interacción 3D
En algunas actividades de Ciencias de la Salud trabajé con modelos preparados en Blender y 3ds Max e integrados con Sketchfab. Sobre el modelo agregaba hotspots, preguntas, pistas y feedback.
Flujo de interacción
explorarlocalizarconsultar una pistaresponderver feedback
3D interactivoVer en Sketchfab
Experiencia docente
La plataforma también tenía vistas para consultar grupos, calificaciones, progreso y seguimiento académico. Aquí el problema era ordenar más información sin volver lenta la consulta.
01
grupos y alumnos
02
calificaciones
03
progreso por curso
04
seguimiento académico
05
desempeño
Validación
No siempre había tiempo para hacer pruebas formales antes del desarrollo. Muchas veces validábamos internamente, publicábamos y después revisábamos el comportamiento real para decidir el siguiente ajuste.
Google Analytics
dispositivos · navegadores · tráfico · uso
Datos internos
progreso · finalización · calificaciones · desempeño
Soporte
errores · compatibilidad · navegación
Comentarios
alumnos · docentes · equipo académico
publicar→revisar→ajustar→volver a publicar
Resultados
El cambio se vio por dos lados: los reportes de compatibilidad dejaron de ser recurrentes y Analytics mostró una mayor participación desde mobile durante la transición responsive.
≈20%
crecimiento del uso mobile
Crecimiento aproximado observado en Analytics durante la transición responsive.
30+
tipos de interacción
Distintas actividades construidas sobre reglas compartidas.
6
áreas profesionales
Contenido de inglés aplicado a diferentes campos académicos.
Soporte
Antes era común recibir reportes de pantallas blancas, incompatibilidad de navegador o actividades que no abrían desde celular. Después de migrar más contenido a web y mejorar el responsive, ese tipo de reporte dejó de ser recurrente.
Adopción del producto
mironline empezó como complemento de los libros, pero terminó ocupando más espacio en demostraciones y congresos. Las experiencias interactivas y Professional English servían para mostrar el producto frente a otras instituciones.
Aprendizajes
Ver mironline en demostraciones y congresos cambió la perspectiva: fuera del equipo, una interacción tenía que entenderse sin explicación adicional.
Trabajar entre contenido pedagógico, diseño, frontend y soporte me dejó una regla simple: publicar no cerraba el diseño. El comportamiento real del producto era parte del siguiente ajuste.
“
Si alguien tenía que escribir a soporte para poder seguir aprendiendo, todavía había algo que diseñar mejor.
mironline
FIN DEL CASO
mironline
Este proyecto fue donde empecé a trabajar diseño e implementación como partes del mismo proceso.
GUIGOLO
Diseño con intención. Sistema con claridad. Experiencias que se sienten.
MODULE · FOOTER SIGNAL
LOGROS: —/8
Tip: si desbloqueaste algo, abre “Misiones” y presume tantito.
Navegación
© 2026 GUIGOLO · MODULE · FOOTER SIGNAL