SAM

La columna vertebral del diseño instruccional

David Gutiérrez 2 comentarios

La fórmula mágica para el aprendizaje no es excesivamente complicada. Así en breve: pon a alguien a hacer algo, dale ayuda cuando la necesite, explícale por qué comete fallos, dale oportunidades para practicarlo de forma sostenida y espaciada y pídele que te cuente lo que hace y por qué.

En función de las circunstancias concretas para las que estemos diseñando la experiencia de aprendizaje, este proceso tiene mil matices y condicionantes que complican una aplicación directa. Sin embargo sí hay una serie de pasos derivados de él que consigo aplicar con un éxito razonable siempre que la formación busque (y mida) resultados reales. En los cursos cuyo objetivo es que existan cursos, francamente, no hay mucho que rascar.

Esa ruta crítica que vincula mi trabajo de diseñador instruccional con el núcleo del proceso de aprendizaje tiene cinco pasos:

1. Aíslo los objetivos y determino cómo medirlos.

De esto ya hay mucho escrito, pero nunca viene mal insisitir en que los objetivos de una formación no son los mismos para quien la diseña que para quien la recibe. Además, la medición tiene que incluir indicadores de resultado y de proceso (o sea, la meta y que las acciones para llegar a ella sean las apropiadas).

2. Defino los modelos que permiten llegar al objetivo.

Está claro que para aprender cómo llegar a una meta hay que trabajar los pasos que conducen a ella. Sin embargo, diseñar la formación centrándonos en las acciones puede hacer que perdamos la imagen global. Para transmitir la lógica de un flujo de trabajo hay que proporcionar dos cosas: modelos que la muestren y ejemplos que la reflejen. Todos usamos una guía cuando queremos conseguir algo: cuando es algo procedimental puede bastar el recuerdo mecánico de los pasos a seguir, pero frecuentemente buscamos una lógica para lo que hacemos. Contar con un modelo permite inferir las acciones correctas aunque la memoria falle y predecir lo que pasará en una situación determinada, anticipando qué hacer.

3. Defino la práctica

Sin práctica la lógica de una tarea no se asimila. Para que sea escalonada empiezo por el caso más difícil posible y voy eliminando elementos para llegar a las prácticas intermedias, añadiendo ayudas o reduciendo exigencias. El orden al hacerlas será inverso, pero así me aseguro de que hay una continuidad entre los distinos niveles de andamiaje. Además, me es más fácil proporcionar feedback alineado con el resultado final cuando bajo escalones de dificultad, mostrando las consecuencias de un error y pistas para que reflexionen sobre cómo encaja con el modelo del paso anterior. La práctica, además, debería ser recurrente, entrenando varias veces la misma habilidad en contextos más o menos diferentes. Las competencias que funcionan aisladas son algo raro, así que viene bien intercalarlas en ejercicios que no las tengan como objetivo principal (y de paso conseguimos un espaciado muy útil).

4. Busco ejemplos que faciliten la transferencia

Los ejemplos deben referirse al modelo, incluyendo explicaciones de la lógica y una historia bien narrada que los haga memorables y con la que el público objetivo pueda identificarse. Lo explica estupendamente Clark Quinn: varios ejemplos que exploran distintos contextos para la misma habilidad establecen el espacio en el que puede darse la transferencia de la formación al mundo real. Ojo, al multiplicarse los contextos aumenta la probabilidad de que variables extrañas capturen la atención, así que hay que procurar que estén muy centrados y que no dejen lugar a dudas de qué se está haciendo y, muy importante, por qué.

5. Defino la información mínima imprescindible a incluir

Este paso se lo debo a Cathy Moore, cuyo modelo a estas alturas es ya merecidamente mainstream. La idea es que la información tiene que colgar de la práctica y no al revés: en una situación de aprendizaje idónea los datos necesarios para completar una tarea pueden recabarse en el momento apropiado como parte del proceso de andamiaje, exigiendo poco a poco alcanzar los objetivos sin recurrir a esas ayudas (a menos que existan también en el entorno real en el que se usará la habilidad: se pueden eliminar para aumentar la dificultad de la práctica, pero teniendo en cuenta que nos salimos de la réplica del entorno real).

Uno de los aspectos más delicados de estos pasos (y en mi experiencia más problemáticos) es evitar que se transformen en un proceso lineal. Encuentro que trabajar con prototipos de forma iterativa ayuda mucho, y no es casualidad que el modelo de aproximaciones sucesivas (SAM) sea mi metodología de trabajo por defecto desde hace años. Se nota especialmente en que los objetivos, los ejemplos y la práctica se retroalimentan entre sí y la información y los ejemplos corrigen la forma de representar la lógica del modelo. No es raro que haya cambios hasta por lo menos la tercera iteración en unos u otros aspectos, algo a tener en cuenta al abordar cada paso por primera vez para sobreponerse al ansia (propia o del cliente) de tenerlo todo definido a la primera.

Uso y evaluación de prototipos en e-learning

David Gutiérrez 1 comentario
Uso de prototipos en e-learning

El trabajo con prototipos en diseño instruccional proporciona validaciones tempranas, en estadios en los que a veces el análisis de necesidades formativas ni siquiera está finalizado (la triste e inevitable frecuencia del fast tracking es uno de los motivos por los que ADDIE no me gusta), pero sí tenemos ya información suficiente para hacer propuestas concretas de formato y estructura de contenidos didácticos. Aunque lo idóneo es hacer esta validación con usuarios finales, no es raro que en este primer momento solo participen usuarios avanzados, o a veces incluso directivos.

Los problemas de evaluar un prototipo con usuarios finales son varios (genera expectativas sobre el resultado final, suelen fijarse en detalles y buscan contenido más que uso y presentación) pero prescindir de ellos lo pone más difícil aún. Cuando son usuarios avanzados, expertos y directivos los que validan este trabajo temprano, su atención suele estar en qué cuentas y cómo, en lugar de qué problemas resuelves (que suele ser el foco de los usuarios finales).

Expectativas frente a prototipos en diseño instruccional

Típico resultado de una mala gestión de expectativas ante un prototipo

En estas condiciones, ¿qué tipo de evaluación tiene sentido para un prototipo?

  • Objetivos: normalmente será pronto para una validación de contenidos, pero sí puede verse si los materiales responden a los objetivos de aprendizaje perseguidos. Si quieres que aprendan a hacer una tarea necesitarás recursos para transmitir su lógica, para ver ejemplos y para practicarla, y cada función puede hacerse con un tipo diferente de material (infografías, estudios de caso, prácticas guiadas, escenarios…).
  • Usabilidad: si los usuarios se pierden en el prototipo, seguramente se perderán en los recursos finales (aquí tienes algunas pautas para evitarlo)
  • Estructura del contenido: resulta muy sencillo preparar un prototipo para mostrar cómo será la navegación no ya desde el punto de vista de la usabilidad, sino cómo y cuándo se incluirán conceptos, práctica, evaluaciones, feedback, recapitulaciones, esquemas…
  • Estructura de la información: muy relacionada con la anterior, muestra cómo distintos tipos de información se transmiten de distinta forma: qué va en un esquema (aunque el esquema en sí sea ilustrativo solamente), qué en forma de estudio de caso, qué en forma de ejemplo…

¿Cómo facilitar la evaluación?

  • Crea un prototipo enfocado a los objetivos de aprendizaje que quieres evaluar. Si vas a centrarte en usabilidad y estructura, por ejemplo, que esos dos factores estén bien trabajados, aunque dejes otros por el camino. Recuerda que un prototipo siempre es provisional y deberías tardar en producirlo el tiempo justo para que no te frustre descartarlo, si es necesario. Eso implica recortes.
  • Escoge los indicadores apropiados para medir esos objetivos de aprendizaje, y planea una tarea de evaluación que esté enfocada a recoger esas medidas.
  • Controla las expectativas: deja claro a los usuarios, desde el principio (quizá con un mensaje en el propio material), que es un prototipo, que está incompleto y que procuren centrarse en los objetivos de esta tarea concreta.
  • Automatiza la recogida de datos: si haces el prototipo en una herramienta de wireframes plana (o en powerpoint sin ir más lejos) no podrás sacar mucha información, pero si haces el prototipo directamente con la herramienta de autor que vayas a usar al final, puedes usar los datos que recoja. Es bastante laborioso y solo recomiendo hacerlo si el prototipo está avanzado y la evaluación debe ser muy exhaustiva.

Recuerda que los resultados de la evaluación serán tan fiables como avanzado esté el prototipo, por lo que es importante usarlo para validar solo aquello que refleja claramente (o sea, no tengas en cuenta comentarios sobre el diseño gráfico en un prototipo de estructura de la información, porque va a ser feo seguro). Y sobre todo, calibra el esfuerzo que dedicas a los prototipos con el resultado que vas a obtener, para que te sea más fácil superar la aversión a la pérdida.

Cómo gestionar un proyecto de formación: dejando atrás ADDIE (II) – SAM1

David Gutiérrez 3 comentarios

El Modelo de Aproximaciones Sucesivas (SAM) para la gestión de proyectos e-learning, y que ya comenté en una entrada anterior, proporciona una estructura ágil para sustituir a ADDIE como esquema de trabajo. SAM tiene dos variaciones sobre el mismo tema: SAM1 para pequeños proyectos unipersonales (y en mi caso también para gestionar mi parte de trabajo en proyectos compartidos), y SAM2 para aquellos casos en los que es complicado integrar diseño y desarrollo; normalmente proyectos de tamaño considerable.

Ciclo de trabajo

SAM1 es el que uso habitualmente, y responde a un esquema muy sencillo:

Un ciclo de SAM-1

Un ciclo de SAM-1

Este proceso se repite al menos tres veces, comenzando y terminando con la evaluación:

  • En la primera iteración evalúo la situación, necesidades, objetivos y opciones, que luego organizo en la fase de diseño para trasladarlas a distintas posibilidades de formato y medios de distribución. En la fase de desarrollo transformo estas decisiones en prototipos básicos, sin trabajar aún la presentación del contenido sino únicamente la estructura. Finalmente, lo presento a las partes implicadas para que lo fusilen a críticas.
  • La segunda iteración es, con diferencia, la más laboriosa: evalúo hasta qué punto la primera cumplió sus objetivos y recojo los puntos a cambiar o mejorar. A continuación traslado esos cambios a un nuevo diseño (o una variación del primero si he tenido buen ojo), y lo aplico a un nuevo prototipo en la fase de desarrollo. A menos que haya tenido que empezar de cero, que a veces ocurre, en este punto el prototipo da una idea clara de cómo va a ser el contenido final, ya con textos, interacciones y demás. También es el momento de hacer pruebas de distribución, usabilidad y seguimiento, y de validar el contenido y los conceptos tratados.
  • La tercera y posteriores iteraciones son básicamente repeticiones de la segunda hasta conseguir un producto final adecuado. En general se trata de diseñar cambios en función de los resultados de las pruebas de uso y de los comentarios de los expertos en la materia. El peso de las iteraciones lo lleva la producción más que el diseño, y en mi caso tienden a ser ciclos cada vez más cortos.

Problemas

Allen dice que más de tres iteraciones no deberían ser necesarias en la mayoría de los casos, porque el equilibrio entre esfuerzo y resultados disminuye con cada una de más. Le doy la razón en esto último, pero hasta ahora siempre he necesitado al menos un par de ciclos más para quedar contento. Concuerdo en que a partir de ahí se entra en una espiral de perfeccionamiento que alarga los plazos a lo tonto. Desde luego, la situación ideal es poder lanzar el producto final, recoger datos durante un tiempo, y hacer un nuevo ciclo a partir de ahí para pulir todo lo que se quedó en el tintero… pero pocos proyectos se permiten ese lujo.

El otro gran riesgo, que desde mi punto de vista es el mayor, es poner demasiado esfuerzo en la primera iteración, especialmente en el diseño. Descartar prototipos siempre es complicado; al fin y al cabo, los has hecho así porque parecía una buena opción. No es fácil encontrar el equilibrio para que el prototipo se entienda y a la vez no se haya comido más tiempo del que estoy dispuesto a tirar por la ventana (la dichosa aversión a la pérdida), pero es la clave para no frustrarse nada más empezar.

Conclusiones

SAM1 es sencillo, fácil de explicar a los clientes (a todo el mundo le encantan los prototipos, aunque a la hora de revisar se haga un poco cuesta arriba) y, si se vigilan los dos problemas explicados arriba, sobre todo es práctico. Sin dobleces, sin procesos largos y con una reducción de la incertidumbre que, en mi opinión, es su mayor ventaja. Lo he adoptado como metodología por defecto, así que mi valoración es claramente positiva. Si no te preocupa trabajar con algunos desajustes entre el modelo y la ejecución puedes usar la versión iterativa de ADDIE,y seguramente no notarás mucha diferencia; pero si te gusta que teoría y práctica encajen, SAM1 es para ti.

Cómo gestionar un proyecto de formación: dejando atrás ADDIE (I)

David Gutiérrez 3 comentarios

Análisis-Diseño-Desarrollo-Implementación-Evaluación es una cantinela que todos los que diseñamos formación nos hemos aprendido en algún momento. Es un método directo y sin complejos de gestión de proyectos de e-learning, posiblemente el más extendido, pero se le pueden hacer críticas muy válidas. La mía se basa sobre todo en que es un modelo de fases en el que faltan procesos.

¿Cuál es el problema de ADDIE?

Borradores blog - Google Docs - Google Chrome_2

A nadie se le escapa que comprobar si estás avanzando en la dirección correcta mientras trabajas es importante. Medir resultados al final y ver qué tal lo has hecho es fundamental, pero es francamente un mal momento para descubrir que tu idea no era buena desde el principio. Incluso si haces esa evaluación al final de cada fase, como sugieren las últimas variaciones de la secuencia A-D-D-I-E, sigue habiendo un riesgo muy alto de que sea demasiado tarde para hacer todas las correcciones necesarias, no digamos ya para cambiar de enfoque. Por eso la mayoría incluimos pequeños ciclos de diseño, desarrollo y evolución dentro de cada una de las fases, probablemente incluso para cada entregable de cada fase. No es exactamente una novedad: los métodos ágiles de gestión de proyectos van por ahí. Pero en este campo por algún motivo lo hacemos escondiendo esos ciclos dentro de ADDIE y sin documentarlo, como si romper la ortodoxia del modelo no mereciera figurar en nuestros informes. Puede que me equivoque generalizando, pero creo que casi nadie aplica ADDIE en su forma más pura, sino que proliferan los apaños caseros.

El título de esta entrada no es, por tanto, exacto: nunca he aplicado ADDIE tal cual, así que no puedo abandonarlo. En algún proyecto de largo recorrido ni siquiera he estado cerca, y he trabajado con un modelo ad hoc, pero ese es un lujo viable únicamente cuando tienes muchos meses para pulirlo.

El modelo de aproximaciones sucesivas (SAM).

Una metodología fiable permite empezar con paso firme, sabiendo que no te vas a dejar nada por el camino. Y buscando algo que no fuera un nuevo parche dí con SAM, desarrollado por Michael Allen. Allen es un habitual en los círculos de debate del e-learning y la formación corporativa, y tiene un discurso sensato, así que parecía una buena apuesta. Lo es en términos generales, porque pone negro sobre blanco lo que describía al principio de la entrada: cómo incluir pequeños ciclos de trabajo en las distintas etapas de un proyecto, para generar y validar entregables que permitan ver si vas por buen camino o no. Allen se pasa medio libro diciendo que su modelo no es un ADDIE con iteraciones, pero la verdad es que no me ha convencido de ello, y creo que los paralelismos son fáciles de encontrar:

Borradores blog - Google Docs - Google Chrome

Tampoco es raro, porque las fases de ADDIE son tan obvias, quizá tan naturales, que no creo que haya que romperlas necesariamente: simplemente hacía falta que alguien describiera lo que todos hacemos.

No llego tan lejos como el autor, achacando a un mal modelo de gestión el origen de los males de la formación corporativa. De hecho creo que la mayor parte de la responsabilidad cae sobre el diseño didáctico. Pero sí le doy la razón en que una mala gestión de los riesgos y poca flexibilidad, especialmente en la producción, tienden a generar resultados muy poco adaptados a las necesidades de los alumnos. Me gusta especialmente el énfasis que pone en la exploración de diseños alternativos, y en el análisis de necesidades continuado (que obviamente van de la mano).

Las bases de una buena gestión.

Allen considera que hay cuatro criterios fundamentales en los que debe basarse cualquier proceso de gestión de proyectos:

  1. Debe ser iterativo, para hacer las correcciones que toquen cuando suponen menos coste
  2. Debe facilitar la colaboración, no tanto para mejorar el resultado final sino para acortar los tiempos.
  3. Debe ser eficiente y efectivo (menuda sorpresa), lo que implica tanto evitar el perfeccionismo como detectar cuándo vale la pena invertir un esfuerzo extra para mejorar el resultado final.
  4. Debe ser manejable, en el sentido de que deje claro quién hace cada cosa y permita predecir el impacto de los cambios hechos sobre la marcha.

Son criterios de sentido común y bastante amplios; posiblemente, sobre el papel, cualquier modelo de gestión cumple con ellos. Sin embargo, me parece interesante cómo SAM logra convertirlo en acciones concretas con sencillez. Como estos objetivos no dependen de las mismas variables en proyectos grandes y pequeños, SAM tiene dos variantes: un nivel uno (SAM1) apropiado para proyectos o equipos pequeños y sin demasiadas complicaciones tecnológicas, y un nivel dos (SAM2) para los que tienen más miga.

En una próxima entrada repasaré SAM1, que está ya en mi vida en plan no-sé-cómo-no-lo-he-hecho-así-siempre-porque-es-de-cajón. SAM2 son palabras mayores y no he tenido ocasión para probarlo en condiciones, así que dejaré su revisión para más adelante.