Buena parte de mis proyectos se desarrollan en el sector sanitario, apoyando la implantación de sistemas informáticos de historia clínica electrónica y gestión de pacientes. Estas operaciones generan muchas necesidades de formación y soporte, tanto por el número de usuarios (que pueden ir de un centenar a varios miles) como por las mil situaciones diferentes que pueden encontrarse. Eso por no hablar del grado de alfabetización tecnológica que tengan.

En cualquier caso, estas necesidades se cubren normalmente con un esfuerzo muy grande en formación inicial, sea presencial, online o una combinación. La formación de base sirve para familiarizar al personal con las tareas y asumir la lógica subyacente a los flujos de trabajo (o «por qué esto se hace así»), pero difícilmente va a resolver las dudas que surgen sobre la marcha, o a prevenir malas prácticas. Conforme al enfoque 70:20:10, con el tiempo la necesidad de soporte en el puesto de trabajo (que también está ahí desde el principio) va ganando peso relativo, es decir, la mayoría de las intervenciones serán de soporte y no de formación.

Esta demanda suele canalizarse a través de servicios de soporte, formaciones de refuerzo y usuarios avanzados que sirvan como nodos de conocimiento y referencia para el resto. Solo cuando ha pasado el tiempo y los gestores se preguntan por qué sigue habiendo problemas (y ya no queda presupuesto para formaciones masivas) surge la reflexión: ¿cómo puedo hacer que haya menos errores y que dejen de llamar a soporte para resolver dudas?

El objetivo: favorecer la autonomía

Siempre va a haber carencias funcionales, porque siempre va a haber una diferencia, por pequeña que sea, entre las mejores prácticas y la forma de trabajar del conjunto de usuarios de un sistema. Y no hay curso que acabe con eso. Sin embargo, sí es posible reducir esa diferencia procurando que el conocimiento no tenga que estar en mi cabeza, sino en el entorno, fácil de encontrar y rápido de consultar.

La idea es simple pero potente: si me atasco cuando estoy en la pantalla X haciendo la operación Y, tendré un enlace ahí mismo que me llevará, idealmente, al recurso que me explica qué hacer. Un sistema de ayuda para estas situaciones será básicamente una estructura que aloja los recursos de ayuda (fichas, guías paso a paso, pequeños vídeos…) y los enlaza desde los puntos de la aplicación en los que resultan relevantes.

La clave: estructura y formato de los recursos

Para quitar dependencia de la memoria o de la familiaridad con una tarea, un sistema de ayuda debe cumplir dos principios: acceso (fácil de encontrar) e inteligibilidad (se aplica rápido porque se entiende rápido). Es decir, hay que poner el esfuerzo en planificar la estructura (cómo están organizados) y el formato (qué muestran y cómo) de los recursos.

Estructura de los recursos

Obviamente hay un paso previo, que es contar con los recursos necesarios, y que lleva un buen trabajo de análisis de necesidades (incluyendo errores comunes y dudas frecuentes) , y en este sentido no es muy diferente del que se haría para otro tipo de intervención. Pero una vez dado este paso, la clasificación que se haga debe contar con que cada recurso puede ser accesible desde diferentes lugares que generen problemas similares. Esto significa que harán falta contenidos neutros que tengan sentido independientemente de si se accede a ellos desde el flujo de trabajo A o B, o bien contenidos casi duplicados, para recoger esas diferencias. Ambos casos tienen pros y contras y, claro está, puede aplicarse una u otra solución caso por caso.

Como estamos hablando de múltiples enlaces a un mismo documento, que deben ubicarse en los lugares donde hay más posibilidades de que se necesite, trabajaremos con dos estructuras paralelas: una en función del contenido y otra en función del acceso. La primera se organiza de forma jerárquica, por ejemplo en función de la complejidad del contenido (a la izquierda en la figura de abajo). La segunda tiene una organización hipertextual, en forma de red, donde cada recurso se conecta con varios puntos de enlace dentro de las aplicaciones, lo que genera una estructura paralela (representada por colores en la figura):

Formato de los recursos

La forma en que presentamos la información debe ser consecuente con la función que cumple. Una explicación inicial destinada a que alguien comprenda por qué hay que hacer un determinado flujo de trabajo puede incluir un diagrama con la lógica subyacente, unos objetivos y posiblemente una recapitulación final. Un recurso destinado a aprender cómo se hace ese mismo flujo será idealmente una práctica más o menos guiada, o en su defecto una demo clara y sencilla. Una ayuda de trabajo, a su vez, tendrá forma de ficha (como un esquema con las partes principales), una lista de puntos clave (un checklist, vaya) o un diagrama de pasos. Una breve demo puede ser de ayuda si se trata de un flujo de cierta complejidad que quedaría demasiado confuso con una explicación de texto e imágenes.

La idea general es ofrecer un recurso lo más claro, sintético y minimalista posible, adaptado a la situación en la que se va a usar, y con la información imprescindible (y usando un concepto muy restrictivo de imprescindible).

El riesgo: mantener actualizado el contenido

Puedes tener el mejor sistema de ayudas de trabajo del mundo, que si no se mantiene al día sirve de muy poco. Cualquier cambio en los flujos de trabajo debe verse reflejado en la documentación con la mayor rapidez posible, bien a través de nuevos documentos, bien corrigiendo los ya existentes. Si hay una buena indización de los contenidos será fácil localizar los afectados para hacer los cambios oportunos. Algunos sistemas facilitan este mantenimiento usando, por ejemplo, imágenes almacenadas en un repositorio único que luego son insertadas en los documentos individuales, de forma que, cambiando la fuente, la nueva imagen se refleja automáticamente en todas sus réplicas.

La guinda: integración correctiva

El uso de recursos de ayuda bajo demanda facilita resolver dudas y errores, pero deja en el aire la aplicación de buenas prácticas. Cuando un usuario consigue lo que necesita, normalmente no se dedicará a ver si hay una forma mejor de hacerlo (al fin y al cabo, tiene el resultado que quiere). Esto implica que los malos aprendizajes y los atajos indebidos se enquistan y difícilmente se corrigen.

Ahora, imaginemos que un sistema de ayuda puede leer los flujos de trabajo de un usuario y sugerir un documento que corrija una mala práctica. La aplicación de trabajo enviaría sentencias tipo «Alicia hizo esto» (la sintaxis que usa xAPI) que serían reconocidas por el sistema de ayuda y servirían para lanzar una acción predeterminada, como sugerir un documento.

Esto ni siquiera es una inteligencia artificial, pero supone un paso de gigante en la eficiencia de la formación. Capacitar en sistemas de información tiene la gran ventaja de permitir este tipo de integraciones, que son objetivos realistas y necesarios a marcarse por cualquiera que se dedique al diseño didáctico en este ámbito.