Prototype-Jam

Cómo se organiza

• Los últimos 5 minutos son la entrega, no el contenido. El reparto de arriba cubre los pasos; aparte hay que firmar la hoja (tres nombres y tres correos UC — sin eso el PDF no se descarga), generar el PDF y subirlo al formulario. Avisen a los 5 minutos del final: un grupo que se pasa contestando entrega en el pasillo, o no entrega.
• Grupos de proyecto (3 personas) (los mismos del semestre — no es una actividad para mezclar gente nueva).
• Hasta 2 horas en total: 10' Paso 1 planificación (grilla F1-F5 + plano de priorización) · 2' Paso 2 inventario de materiales · 98' ciclos de construir + documentar la bitácora (Paso 3) · 10' Paso 4 síntesis. Suma exacta: 120.
• De esas dos horas, la hoja se lleva ≈ 30 minutos: 10' del Paso 1 + 2' del Paso 2 + unos 3' por bloque de bitácora documentado (que van dentro de cada ciclo de construcción, no al final) + 7' de síntesis. Todo lo demás es cartón.
• 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.

Paso 1 — cómo leer el plano de priorización

• El plano tiene dos ejes: horizontal, factible con cartón hoy (de *imposible hoy* a *lista en 20 min*) y vertical, comunica la idea (de *detalle interno* a *es LA idea*). Los grupos arrastran las fichas F1-F5 que acaban de nombrar en la grilla de arriba, así que el plano solo funciona si esa grilla se llenó primero — si ven fichas sin nombre, ese es el problema, no el plano.
• Cómo se ve una priorización sana: las fichas repartidas, con una o dos arriba a la derecha — por ahí empiezan —, alguna arriba a la izquierda (importante pero cara: es la candidata natural a Wizard of Oz o a una versión reducida) y al menos una abajo, descartada a propósito. Descartar es la decisión que hace que el plano sirva de algo.
• Bandera roja · todo en una esquina. Cinco fichas arriba a la derecha no es una priorización: es declarar que todo es importante y todo es fácil. Intervención: *si solo pudieran construir una, ¿cuál? Súbanla y bajen el resto.*
• Bandera roja · todo apiñado en el centro. La misma evasión en versión tímida. Pídanles que separen al máximo dos fichas entre sí y que expliquen la diferencia en voz alta.
• Bandera roja · todo arriba a la izquierda (todo comunica, nada es factible): el proyecto está pensado en abstracto. Aquí el atajo — Wizard of Oz, smartphone como sensor — es la intervención, y casi siempre mueve una ficha a la derecha.
• Bandera roja · una diagonal perfecta de F1 a F5. Es la posición inicial de las fichas: nadie movió nada. En el PDF sale como [SIN COLOCAR].
• En el PDF cada ficha se imprime como una frase — *F2 — [SIN DESCRIBIR]: Factible con cartón hoy alto, Comunica la idea alto* —, así que se puede revisar sin abrir la hoja. El [SIN DESCRIBIR] es normal y no es un olvido del grupo: los nombres viven en la grilla F1-F5, no en el plano. Contrasten el plano con la respuesta a *¿cuál construyen primero?*: si dicen F4 y F4 está abajo a la izquierda, hay una incoherencia que vale la pena preguntar en voz alta.

Pasos 2 a 4 — qué esperar en la entrega

• Paso 2 · materiales. Es un marcado de un minuto. La opción Otro tiene su propio campo debajo: si está marcada y el campo está vacío, se perdió información que nadie va a recuperar después.
• Paso 3 · tres bloques abiertos, tres tras una pregunta. Después del tercer bloque la hoja pregunta *¿alcanzaron a prototipar más de tres?* y solo entonces abre los otros tres. Un PDF con tres bloques es el caso esperado, no un grupo que abandonó — los bloques que no se abrieron no aparecen en la entrega. Lo que sí hay que mirar son los bloques a medias: nombre sin foto, foto sin descripción.
• Fotografíen antes de desarmar. La pérdida más común de la sesión es el grupo que despieza el cartón para reutilizarlo y se queda sin evidencia de la funcionalidad anterior. Vale la pena recordarlo en voz alta a mitad de la sesión.
• El nivel de madurez es autodeclarado. Al revisar, contrástenlo con la foto: un funcional cuya foto es un dibujo plano es una conversación pendiente, no una nota menos.
• Paso 4 · la funcionalidad que falló se elige de una lista, así que el PDF dice a qué bloque se refiere la reflexión. "Ninguna falló" es la respuesta a mirar con sospecha: casi siempre significa que no llegaron a probar el prototipo con alguien de fuera del grupo, no que todo saliera bien.

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.