120/365 · Crear recursos que se reutilizan (o: cómo una herramienta para una cosa acabó sirviendo para todo lo demás)

Llevo dos días hablando de cuándo parar, de no obsesionarse con el último 20%, de lanzar rápido y pulir después — y todo eso está muy bien, pero hay algo que descubres cuando llevas tiempo creando herramientas: que las mejores (las que de verdad te hacen la vida más fácil) son las que NO sirven sólo para lo que pensaste en un principio. Son las que, de repente, un martes por la mañana, descubres que resuelven un problema completamente distinto al que tenías en mente cuando las creaste.

Y esto no es casualidad. No es magia. Es diseñar pensando en la reutilización desde el principio — aunque al principio no sepas exactamente para qué más va a servir.

Te cuento un ejemplo real, de esos que te hacen pensar "¿cómo no me di cuenta antes?". Cuando empecé con Motion EDUmind, la idea era clara: una herramienta para que mi alumnado pudiera crear stopmotion de forma sencilla. Grabar fotogramas, montarlos, exportar el vídeo. Punto. Eso era lo que necesitaba para un proyecto de Ciencias Naturales donde íbamos a trabajar con las relaciones entre seres vivos como simbiosis o parasitismo de una forma autónoma, donde en tercero de primaria, un contenido poco atractivo aparentemente se convierte en una historia... es chulísimo.

Pero un día, preparando una clase de Plástica, me di cuenta de algo: ¿y si en lugar de usar Motion para que ELLOS crearan stopmotion, lo usaba YO para mostrarles paso a paso un proceso creativo? Configuré la herramienta en modo bucle, fui capturando cada fase de cómo hacer un dibujo con técnica mixta, y de repente tenía un recurso visual que podía proyectar en clase mientras ellos trabajaban. No tenía que explicar veinte veces "primero haces esto, luego lo otro" — estaba ahí, en bucle, visible, paso a paso. Y funcionó MEJOR de lo que había funcionado para el stopmotion original.

Ahí me cayó la ficha: había creado una herramienta pensando en UN uso, pero el diseño permitía OTROS usos que ni siquiera había contemplado. Y eso, pedagógicamente, es oro puro.

El diseño modular (sin que suene a ingeniería espacial)

En desarrollo existe un concepto que se llama diseño modular — básicamente, crear componentes que pueden funcionar de forma independiente y combinarse de distintas maneras. No es algo exclusivo del software: en educación llevamos años hablando de esto aunque con otros nombres. El Diseño Universal para el Aprendizaje (DUA), por ejemplo, propone crear materiales flexibles que se adapten a diferentes necesidades y contextos.

El equipo de CAST, que desarrolló el marco del DUA, lo tiene claro: cuando diseñas con flexibilidad desde el principio, estás permitiendo múltiples formas de representación, de acción, de implicación. Y eso es exactamente lo que pasa cuando creas una herramienta reutilizable: no estás cerrando los usos posibles, los estás abriendo.

Yo no soy ingeniero (soy maestro de primaria, funcionario de carrera, y chapucero informático cutre cuando hace falta), pero he aprendido que si diseñas algo pensando "esto tiene que servir SOLO para X", te estás limitando. En cambio, si diseñas pensando "esto tiene que resolver X de forma sencilla, y si mañana sirve para Y, mejor", estás construyendo herramientas que escalan — que crecen contigo, con tu aula, con tus necesidades.

Cómo saber si estás creando algo reutilizable (antes de pasarte meses desarrollándolo)

Vale, la teoría mola. Pero cuando estás ahí, con el cursor parpadeando, empezando a darle forma a una idea, ¿cómo sabes si lo que estás haciendo va a ser reutilizable o va a acabar siendo una herramienta de un solo uso que se queda olvidada?

Yo me hago estas preguntas (y ojo, no siempre acierto — he creado cosas que pensaba que iban a ser súper versátiles y luego solo las he usado una vez):

¿Estoy resolviendo un problema específico o un tipo de problema? Si tu herramienta resuelve "cómo hacer un quiz sobre el ciclo del agua", es muy específica. Si resuelve "cómo crear cuestionarios interactivos sobre cualquier tema", es reutilizable. La diferencia está en el nivel de abstracción.

¿Otra persona (o yo dentro de seis meses) podría usarlo para algo distinto sin modificar el código? Si la respuesta es no, igual estás siendo demasiado específico. La reutilización implica que alguien (incluso tú mismo en otro momento) pueda ver tu herramienta y pensar "oye, esto me sirve para aquello otro".

El equilibrio entre flexibilidad y simplicidad (que no es fácil, eh)

Aquí viene la parte complicada — y es algo con lo que todavía lucho. Porque crear herramientas reutilizables implica cierto nivel de flexibilidad, pero si te pasas de flexible, acabas con algo tan genérico que no sirve bien para nada. Es como esos recursos "comodín" que valen para todo y para nada a la vez.

John Sweller, con su teoría de la carga cognitiva, nos recuerda que el exceso de opciones puede ser contraproducente. Si tu herramienta tiene cincuenta configuraciones posibles y veinte formas distintas de usarse, la carga cognitiva para entenderla y usarla es tan alta que la gente (incluido tú) acaba por no usarla. Así que el truco está en encontrar el punto medio: suficientemente flexible para adaptarse a distintos usos, pero suficientemente simple para que no necesites un manual de 40 páginas.

Yo lo que hago (y repito, no siempre me sale) es diseñar para DOS o TRES usos posibles. No para veinte. Si puedo imaginar dos o tres contextos diferentes donde mi herramienta tendría sentido, probablemente estoy en el punto medio. Si solo se me ocurre uno, igual estoy siendo demasiado específico. Si se me ocurren quince, probablemente estoy haciendo algo demasiado genérico (o demasiado complicado).

Mañana seguimos. Probablemente con algo que al principio pensé que servía para una cosa y luego resultó que servía para tres más.