Aprender diseñando en Informática: una guía adaptable para secundaria

Learning by Design y andamiaje distribuido para planificar proyectos de programación, con referencias al currículo de la Ciudad de Buenos Aires.

Revisión editorial y bibliográfica: 5 de octubre de 2026.

Learning by Design (LBD), o aprendizaje mediante el diseño, organiza el aprendizaje alrededor de desafíos en los que los estudiantes diseñan, construyen, ponen a prueba y revisan una solución. La actividad práctica por sí sola no garantiza que se comprendan los conceptos: el diseño de la propuesta debe ayudar a que el alumnado explique qué aprendió, use ese conocimiento para mejorar el producto y pueda transferirlo a otros problemas. Esa relación entre proyecto, reflexión y transferencia está en el centro del enfoque descrito por Kolodner.^[1]

En programación, un desafío puede ser crear una aplicación sencilla que atienda una necesidad concreta. El ciclo no tiene que seguir una secuencia rígida: se puede volver a definir el problema, investigar, probar una idea o revisar criterios a medida que aparecen nuevas preguntas. Una representación útil es comprender el desafío → proponer y construir → probar y recibir comentarios → revisar y explicar.

El enfoque puede favorecer oportunidades para practicar resolución de problemas, colaboración y comunicación, pero esos resultados no son automáticos. Dependen de los objetivos, las consignas, los apoyos, el tiempo de trabajo y la evaluación.

Qué significa distribuir el andamiaje

El andamiaje distribuido consiste en coordinar apoyos a lo largo del proyecto y entre distintos recursos, actividades y personas. No significa que exista una herramienta única que resuelva todas las dificultades. Puntambekar y Kolodner distinguen tres escalas de apoyo que pueden combinarse y retirarse o ajustarse según lo que necesite cada grupo:^[2]

• Macro: orienta el recorrido general y hace visible en qué etapa del desafío se trabaja, qué se busca aprender y qué decisión viene después.
• Micro: ayuda con acciones concretas dentro de una etapa: descomponer una tarea, formular una condición, probar un caso o interpretar un error.
• Metacognitivo: impulsa a planificar, supervisar y revisar el propio razonamiento: “¿Qué evidencia muestra que esta solución cumple el criterio?” o “¿Qué cambiaríamos después de esta prueba?”.

Estos niveles son una manera de describir apoyos, no una receta fija. Pueden aparecer en una consigna, una conversación docente, una guía de pruebas, una bitácora o una instancia de revisión entre pares.

Una secuencia posible para un proyecto de programación

Ejemplo adaptable: en equipos, diseñar un programa breve que ayude a resolver una necesidad de la comunidad escolar. Antes de comenzar, el docente define el contenido que quiere enseñar —por ejemplo, condicionales, ciclos o manejo de datos— y acuerda criterios observables para valorar tanto el proceso como la solución.

1. Delimitar el problema. ¿A quién ayudaría la solución? ¿Qué tendría que hacer? ¿Qué queda fuera del alcance?
2. Explorar conceptos y referentes. Analizar ejemplos, identificar qué se sabe y anotar qué es necesario investigar o practicar.
3. Prototipar. Representar la lógica con pseudocódigo, diagramas o una versión inicial del programa.
4. Probar con criterios. Ejecutar casos de prueba previstos, incluidos casos límite pertinentes, y registrar qué ocurre.
5. Revisar y comunicar. Usar los resultados y comentarios recibidos para justificar cambios y explicar qué conceptos se pusieron en juego.

Apoyos concretos durante el trabajo

Bitácora o diario de diseño

Puede ser individual o compartido, en papel o digital. Conviene que sea breve y que sirva para pensar, no solo para documentar al final. Algunas entradas posibles:

• ¿Cómo describimos el problema y para quién diseñamos?
• ¿Qué concepto o herramienta necesitamos aprender para avanzar?
• ¿Qué esperábamos que ocurriera y qué ocurrió al ejecutar la prueba?
• ¿Qué decisión tomamos y qué evidencia la respalda?

El docente puede ofrecer plantillas, ejemplos o alternativas orales y visuales para que el registro no se convierta en una barrera ajena al objetivo de programación.

Revisiones de prototipos y comentarios entre pares

Las sesiones de presentación breve, galerías o pin-ups permiten mostrar una versión temprana y recibir observaciones antes de la entrega. Kolodner describe estas rutinas como parte de la organización del aprendizaje mediante diseño.^[1] Para que sean útiles, acuerden criterios y normas de conversación: primero describir lo observado, luego hacer preguntas y finalmente sugerir mejoras vinculadas con los criterios. La revisión entre pares complementa la orientación docente; no reemplaza la enseñanza ni convierte al alumnado en responsable de calificar a sus compañeros.

El rol del docente

El docente diseña el desafío, explicita los aprendizajes esperados, modela estrategias cuando hace falta y observa dónde se traban los equipos. Puede responder con una pregunta, un ejemplo parcial, una mini explicación o un recurso específico; también puede retirar apoyos cuando dejan de ser necesarios. La intervención conecta las decisiones de diseño con los conceptos que se busca aprender.

Herramientas y evaluación formativa

Recurso o rutina	Cuándo puede servir	Para qué usarlo
Bitácora de diseño	Durante el proyecto y al cerrar una iteración	Hacer visibles decisiones, dudas, pruebas y aprendizajes.
Tablero de tareas	A lo largo del trabajo en equipo	Organizar tareas, responsables y avances. Una herramienta como Trello es opcional: usar un tablero no convierte por sí mismo una actividad en aprendizaje basado en proyectos.
Revisión de prototipo	Cuando ya existe algo que se puede probar o discutir	Obtener comentarios tempranos y decidir qué revisar.
Casos de prueba y conversación docente	En cada iteración	Comprobar el comportamiento y valorar si el estudiante puede explicar los conceptos usados.

La evaluación puede combinar evidencias del programa, las pruebas, las explicaciones y las decisiones documentadas. Revisar durante el proceso permite ajustar el andamiaje y dar devolución a tiempo; al cierre, el docente puede valorar por separado la calidad de la solución y la comprensión de los contenidos.

Relación con el currículo de CABA

El Diseño Curricular de 2015 para el Ciclo Orientado del Bachillerato en Informática de la Ciudad de Buenos Aires incluye el diseño de algoritmos, lógicas de programación, desarrollo de aplicaciones web, resolución de problemas y proyectos con trabajo activo y colaborativo.^[3] Por eso, esta propuesta puede dialogar con esos contenidos. El documento curricular no prescribe Learning by Design: cada docente debe ajustar el desafío al año, la orientación, los contenidos vigentes en su institución y las condiciones reales del curso.

Dos aplicaciones posibles: Scratch y App Inventor

Las siguientes propuestas ilustran cómo llevar el ciclo de diseño al aula. Son ejemplos para adaptar al curso y a los contenidos que se quieran enseñar; no son secuencias oficiales de las plataformas. Scratch permite crear historias, juegos y animaciones interactivas; MIT App Inventor permite diseñar aplicaciones móviles con un editor visual de componentes y bloques.^[4][5]

Scratch: un juego para comunicar una idea

Desafío: crear un juego breve que enseñe o comunique algo relevante para la comunidad escolar —por ejemplo, separar residuos, cuidar el agua o practicar contenidos de una materia—. El equipo define quién jugará, qué decisiones tomará y cómo sabrá si avanzó. Se pueden trabajar eventos, secuencias, condicionales, ciclos, variables y mensajes entre objetos.

1. Delimitar el problema. Conversar sobre el público y el contenido que comunicará el juego; formular una meta y criterios de éxito, como que las reglas se entiendan y que la información sea correcta. En una bitácora de diseño, cada estudiante registra su interpretación del desafío, sus preguntas y una idea inicial. El docente apoya a escala macro al mostrar el recorrido del proyecto y hace preguntas metacognitivas: “¿Qué queremos que el jugador aprenda o decida?”. Un tablero de tareas (en papel o digital) permite acordar responsables y pendientes.
2. Explorar conceptos y referentes. Revisar un proyecto inicial de Scratch y reconocer cómo se usan eventos, condiciones o puntajes. El apoyo micro puede ser una tarjeta breve sobre un bloque o mecanismo puntual; se ofrece cuando hace falta y se retira gradualmente. La bitácora recoge qué ejemplo sirve y qué habría que adaptar. Se pueden consultar los proyectos iniciales oficiales de Scratch.
3. Prototipar. Dibujar la pantalla, escribir las reglas y construir una versión mínima jugable. El tablero muestra el avance; la bitácora guarda decisiones y cambios. El docente observa los equipos y ofrece una explicación breve o una pregunta, por ejemplo: “¿Qué evento inicia esta acción?” o “¿Qué condición cambia el resultado?”.
4. Probar con criterios. Hacer una sesión de pin-up o revisión de prototipos: otro equipo juega sin recibir instrucciones orales, sigue una pequeña lista de tareas y registra qué entiende, dónde se traba y qué error encuentra. La prueba recurrente comprueba reglas, interacciones y puntaje; no se limita al final del proyecto. La bitácora registra resultados y la pregunta metacognitiva “¿Qué evidencia tenemos de que cumple el criterio?”.
5. Revisar y comunicar. El equipo prioriza comentarios, modifica el juego y explica qué concepto de programación sustenta cada cambio. El tablero cierra o actualiza tareas; la bitácora compara el prototipo con la versión revisada. En la muestra final, se evalúan tanto la comprensión disciplinar como el funcionamiento y la capacidad de justificar decisiones.

App Inventor: una aplicación para una necesidad cercana

Desafío: diseñar una aplicación móvil sencilla que atienda una necesidad acordada con sus posibles usuarios, como una lista de tareas para un evento escolar, una guía de espacios de la escuela o un cuestionario de repaso. Antes de elegir funciones, conversar sobre qué datos son necesarios y evitar recopilar información personal que el proyecto no requiera. Se pueden trabajar eventos, condicionales, variables y listas, junto con componentes de interfaz.

1. Delimitar el problema. Entrevistar o conversar con posibles usuarios, acordar qué tarea ayudará a realizar la aplicación y establecer criterios observables (por ejemplo, completar una tarea o responder un cuestionario). En la bitácora, cada estudiante anota necesidades, dudas y criterios. El docente brinda apoyo macro con las etapas del proyecto y preguntas metacognitivas: “¿Qué necesita hacer el usuario y qué información es indispensable?”. El tablero de tareas ayuda a distribuir el trabajo.
2. Explorar conceptos y referentes. Revisar un tutorial de App Inventor y reconocer componentes de pantalla y bloques de eventos. El apoyo micro puede enfocarse en conectar un botón con una acción, validar una entrada o actualizar una lista. La bitácora registra qué se aprendió y qué se adaptará. MIT ofrece tutoriales de inicio y recursos para docentes.
3. Prototipar. Dibujar las pantallas y construir una versión mínima que cubra la tarea principal. El equipo actualiza el tablero y registra en la bitácora las decisiones de interfaz y programación. El docente observa, propone una mini lección si varios grupos tienen la misma dificultad y pregunta: “¿Qué acción del usuario dispara este bloque?” o “¿Qué pasa si el dato está vacío?”.
4. Probar con criterios. Un compañero o usuario de prueba realiza una tarea breve con la aplicación; el equipo observa sin guiarlo y registra confusiones y resultados. Probar entradas esperadas y situaciones como campos vacíos ayuda a revisar el comportamiento. Se puede hacer una sesión de pin-up con prototipos y comentarios guiados por criterios. La prueba puede usar el emulador o dispositivos disponibles, según la infraestructura del aula.
5. Revisar y comunicar. El equipo prioriza observaciones, ajusta bloques o pantallas y vuelve a probar la tarea. La bitácora permite comparar versiones y explicar qué cambió; el tablero permite cerrar tareas y preparar la presentación. La evaluación considera si la aplicación cumple la necesidad acordada, si el código responde a los casos probados y si el alumnado puede explicar los conceptos que utilizó.

En las dos propuestas, los recursos de la tabla cumplen funciones complementarias: la bitácora conserva el razonamiento individual; el tablero de tareas hace visible la organización grupal; la revisión de prototipos aporta comentarios antes del cierre; y los casos de prueba junto con la conversación docente permiten evaluar y ajustar apoyos durante cada iteración. Trello es solo una opción de tablero: puede reemplazarse por una lista o un afiche en papel.

En ambos entornos, el producto final importa, pero también importa que el alumnado pueda explicar sus decisiones, mostrar qué pruebas realizó y relacionar las mejoras con los conceptos aprendidos. Así, el proyecto funciona como medio para aprender y no solo como una actividad de construcción.

Referencias

1. Kolodner, J. L. (2002). “Learning by Design™: Iterations of Design Challenges for Better Learning of Science Skills”. Cognitive Studies: Bulletin of the Japanese Cognitive Science Society, 9(3), 338–350. https://doi.org/10.11225/jcss.9.338. Ficha y resumen en J-STAGE.
2. Puntambekar, S., & Kolodner, J. L. (2005). “Toward Implementing Distributed Scaffolding: Helping Students Learn Science from Design”. Journal of Research in Science Teaching, 42(2), 185–217. https://doi.org/10.1002/tea.20048. Registro y resumen en ERIC.
3. Gobierno de la Ciudad Autónoma de Buenos Aires, Ministerio de Educación (2015). Diseño Curricular para la Nueva Escuela Secundaria: Ciclo Orientado del Bachillerato, Informática. Documento curricular oficial (PDF).
4. Scratch Team. Starter Projects. Proyectos iniciales oficiales; y tutoriales de inicio.
5. MIT App Inventor. Jump In and Start Programming y Teach with App Inventor. Tutoriales para principiantes; recursos de enseñanza.