Prototype-Jam

Cómo se organiza

• Grupos de proyecto (los mismos del semestre — no es una actividad para mezclar gente nueva).
• Hasta 2 horas en total: 10' brainstorming + priorización · 100' ciclos de prototipado + documentación · 10' consolidación de la bitácora.
• Materiales: cartón abundante, tijeras, cúter, cinta, pegamento, palillos, hilo, elásticos, marcadores, smartphones de los propios grupos. Conviene tener una mesa de materiales común en vez de repartir por grupo.
• Entrega: al cierre de la sesión, el worksheet completado se sube como PDF al formulario del curso. No hay tarea posterior.

Mi rol como docente esta sesión

• Circular continuamente entre grupos. No quedarse en un solo grupo más de 5 minutos seguidos — esta actividad se rompe si un grupo monopoliza la atención del/la docente.
• Dar sugerencias concretas, no abstractas. En lugar de *tienen que pensar la interacción*, decir *prueben moviendo este cartón sobre este otro como si fuera el scroll de la pantalla*. La concreción desbloquea más que la teoría.
• Ofrecer atajos. Cuando un grupo está a punto de perder 30 minutos en algo que se resuelve con un truco, intervenir y mostrar el atajo. Hoy no estamos enseñando rigor de implementación, estamos enseñando a iterar rápido.
• Validar la fealdad. Los grupos que vienen de cursos más formales suelen avergonzarse del cartón mal cortado. Recordarles explícitamente que lo feo está bien hoy — la limpieza viene en la siguiente iteración.

Atajos típicos para prototipar rápido

1. Reemplazar pantalla por hoja de cartón con sticky notes movibles. Si el proyecto tiene una interfaz gráfica, no abrir Figma — dibujar la pantalla en cartón y usar post-its como elementos UI que se pueden mover, pegar y despegar para simular cambios de estado.
2. Smartphone como sensor + página HTML simple. Si necesitan acelerómetro, GPS, micrófono o cámara, una página HTML con las APIs del navegador se monta en 10 minutos y corre en el teléfono del grupo. Si ya conocen [[Protobject|micro-framework para prototipos físico-digitales rápidos del propio curso — convierte el smartphone en un nodo sensor sin escribir backend.]] del curso, este es su momento.
3. Wizard of Oz: alguien del grupo 'es' el sistema. Para funcionalidades que dependen de un algoritmo (reconocer una pose, clasificar una imagen, recomendar contenido), una persona del grupo se sienta detrás y simula la respuesta. Funciona sorprendentemente bien para validar si la idea de interacción tiene sentido antes de implementarla.
4. Volumen y voz humana en lugar de speech recognition. Si el proyecto usa reconocimiento de voz, hoy basta con que un compañero escuche y responda. Para detección de volumen, el micrófono del smartphone con una página HTML simple basta.
5. Cartón perforado + lápiz/flecha en vez de pantalla animada. Para mostrar progreso, niveles o estados que cambian, un trozo de cartón con un slot y un indicador que se mueve a mano simula una animación sin código.

Banderas amarillas — cuándo intervenir

• Un grupo que lleva 30 minutos planificando y no tiene nada en las manos. La planificación se está volviendo evitación. Intervenir con *elijan UNA funcionalidad — cualquiera — y construyan algo en los próximos 10 minutos, aunque sea horrible*.
• Un grupo que está perfeccionando una sola pieza en lugar de avanzar en otras. Recordarles la consigna: cantidad sobre perfección. Sugerir que congelen lo que tienen y pasen a la siguiente funcionalidad.
• Un grupo que pelea sobre detalles que el prototipo nunca va a resolver (color exacto, tipografía, copy de botones). Recordarles que esos detalles son para la siguiente iteración — hoy es sobre mecánica de interacción, no sobre acabado visual.
• Un grupo que quiere usar tecnología sofisticada (Arduino, sensores reales, microcontroladores) en una sesión de 2 horas. Guiarlos a hacer la versión de cartón primero. Si en 30 minutos tienen el cartón andando, entonces se puede pensar en sustituir por Arduino en la próxima sesión.

Criterios para asistir grupos atascados

• ¿Qué pasa entre el usuario y el sistema en los primeros 5 segundos? Si no saben responder, no tienen clara la funcionalidad — antes de construir, pedirles que la describan en voz alta como si contaran una escena.
• ¿Cuál es la entrada y cuál es la salida? Si la interacción no tiene un input claro (gesto, voz, objeto que se mueve) o un output claro (luz, sonido, movimiento, pantalla), el prototipo va a quedar borroso. Forzar la dicotomía.
• ¿Quién hace de algoritmo? Si la funcionalidad requiere lógica no trivial, preguntar quién del grupo va a hacer el Wizard of Oz. Eso desbloquea casi siempre.
• ¿Esto se puede mover, doblar o tapar? Las funcionalidades que solo se ven (pantalla estática) son aburridas en cartón. Empujar a los grupos a incorporar mecanismos físicos — algo que se desliza, se gira, se levanta — incluso si la funcionalidad final no tendría esa parte mecánica.
• ¿Pueden mostrarme la interacción en 30 segundos? Si el grupo no logra hacer una demo de 30 segundos de lo que llevan, le falta cuajar. Volver a la consigna anterior: input claro, output claro, alguien haciendo de algoritmo.