Una experiencia físico-digital completa desde el inicio, iterada en cuatro versiones justificadas.
Prototipar en físico es iterar todavía más rápido: el cartón se corta, se pega y se descarta sin culpa — y la capa digital, con los agentes de IA, se arma en una tarde. Por eso tampoco aquí se premia llegar al prototipo: se premia iterarlo. Documenten al menos cuatro versiones de la experiencia y el porqué racional de cada evolución.
Un prototipo sobrio con un proceso claro y bien argumentado vale más que uno vistoso cuyo camino no se puede reconstruir.
Partiendo del tema trabajado en la Entrega 1, una visualización de información con un aspecto de fisicalización: una representación física de algún aspecto de los datos y/o una interacción física/tangible con los datos.
Partan de la idea completa. Desde la V1 deben poder contar toda la experiencia: qué aspecto de los datos se fisicaliza, cómo se interactúa, qué suena y dónde entra la capa digital. En lo físico, eso sí, la V1 puede apoyarse en maquetas y simulaciones (cartón, Mago de Oz) mientras llegan materiales y sensores; desde ahí, cada versión se acerca a la experiencia real. Las iteraciones que cuentan son las de diseño — "ahora sí funciona el sensor" no es una evolución de diseño.
Como en la Entrega 1: al menos cuatro versiones repartidas en las semanas de trabajo — el ritmo natural es una por semana — con evolución de diseño significativa y justificada entre una y otra. Cada versión es un estado completo y discutible de la experiencia; en lo físico, además, cada maqueta es naturalmente una versión.
Una iteración puede tocar cualquier frente: la forma física y su escala, los materiales, el mapeo datos → objeto, la interacción tangible, el rol del sonido en el espacio — o varios a la vez. Lo único que no puede pasar es el cambio inexplicado: cada evolución nace de una discusión — las revisiones con el equipo docente, la revisión entre pares, la evaluación con usuarios, las restricciones de materiales — y se justifica.
Toda la experiencia contada de una vez: qué se fisicaliza y por qué, cómo se interactúa, qué suena, dónde entra la capa digital. Maquetas de cartón y simulación Mago de Oz perfectamente válidas — lo importante es que la idea sea completa y discutible: es el material de la primera crítica seria.
Qué no estaba funcionando — de la forma física, de la interacción tangible, del sonido — y cómo lo mejoraron. Aquí se nota el efecto de la R1, la primera revisión con el equipo docente, y el prototipo acercándose a la tecnología real.
El diseño se afina con la experiencia ya operativa: legibilidad del objeto, escala y distancia, la respuesta del sensor, el sonido en contexto. Decisiones más finas, justificaciones más precisas — alimentadas por la R2, la revisión entre pares, y/o la evaluación con usuarios. Las restricciones técnicas y de materiales son rationale legítimo: documéntenlas.
El cierre, tras la R3 — la última revisión con el equipo docente: la experiencia completa y operativa — física, digital y sonora a la vez, coherente con el mensaje — más el balance del recorrido: qué mejoró desde V1, y qué decidieron no cambiar y por qué.
Cuatro es el mínimo: si hubo más versiones o un golpe de timón a mitad de camino, documéntenlo — un proceso honesto con desvíos vale más que uno lineal maquillado.
No van a iterar solos: el proceso tiene tres instancias de discusión, intercaladas con las versiones. Son sesiones de trabajo, no interrogaciones: se mira — y se toca — la versión vigente, se discute qué funciona y qué no, y se sale con decisiones. Las fechas se anunciarán en clase.
| Momento | Instancia | Qué pasa |
|---|---|---|
| Entre V1 y V2 | R1 — equipo docente | Profesor y/o ayudantes miran (y tocan) la V1 — aunque sea maqueta o simulación — y de la discusión salen las decisiones que alimentan la V2. |
| Entre V2 y V3 | R2 — entre pares | En clase, presencial y supervisada por un ayudante: cada grupo presenta su V2, recibe feedback estructurado de otro grupo — y da el suyo sobre el prototipo ajeno. El feedback que dan también se evalúa (sección 5). |
| Entre V3 y V4 | R3 — equipo docente | Se revisa cómo evolucionó la experiencia y se afinan las últimas decisiones antes de la versión final. |
El proceso completo se lee entonces como una sola historia: V1 → R1 → V2 → R2 → V3 → R3 → V4 — y así mismo, intercalado, se cuenta en el documento de entrega (ver la plantilla, sección 11).
En el documento de entrega, cada revisión es una sección propia entre las versiones: fecha, qué se discutió (síntesis breve) y qué decisiones tomaron a partir de ahí — qué adoptaron, qué descartaron y por qué — y cómo se ve eso en la versión siguiente (máximo 10 líneas por revisión).
En la R2 — la revisión entre pares — no solo reciben feedback: también lo dan. Y darlo bien se evalúa — manipular y criticar el prototipo de otro grupo es una de las mejores formas de afinar el propio.
En el documento de entrega, dediquen una sección aparte al proyecto que les tocó evaluar:
El ayudante que supervisa la sesión toma nota del feedback que cada grupo da: su calidad — especificidad, anclaje en los principios, tono constructivo — es parte de la nota (ver pauta de evaluación).
Por cada una de las versiones, el documento de entrega debe incluir:
| Campo | Qué se espera |
|---|---|
| Identificación | Número de versión y fecha aproximada. Para el código, el commit o tag de GitHub correspondiente. El historial del repositorio respalda la parte digital del proceso. |
| Evidencia | Cada versión con su propia evidencia: fotos del estado físico y, en cuanto hay interacción que mostrar, un video corto con la manipulación y el sonido de esa versión. En lo físico la foto es el equivalente del commit: obligatoria en todas las versiones. La evolución tiene que poder verse, versión por versión. |
| Qué cambió | Lista concreta de los cambios respecto a la versión anterior (en V1: las decisiones iniciales). Máximo 8 líneas. |
| Por qué cambió — el rationale | La justificación razonada de cada cambio, anclada en: principios del curso (fisicalización, niveles de fidelidad del prototipado, sonificación, percepción), lo discutido en las revisiones (con el equipo docente o entre pares), feedback de usuarios, evidencia de los datos o restricciones técnicas y de materiales documentadas. Máximo 12 líneas. Es la parte con más peso en la nota. |
| Qué se descartó | Alternativas de materiales, mecanismos o representaciones que probaron y abandonaron, y por qué. Máximo 5 líneas. |
Además del registro de versiones, el documento incluye una sola vez:
Al menos una ronda de evaluación con pensar en voz alta (thinking aloud), con personas interactuando físicamente con el prototipo — idealmente entre V3 y V4, cuando ya hay algo tangible que probar. En lo físico surgen cosas que en pantalla no existen: el alcance de las manos, la fragilidad, el orden en que se lee el objeto, el miedo a tocarlo.
Cada ronda sigue esta hoja del observador, adaptada al objeto físico, y su registro completo va en el documento:
Efecto en el proceso: indiquen explícitamente en qué transición de versión se incorporó — o se decidió no incorporar, y por qué — lo aprendido.
| Criterio | Peso | Qué se mira |
|---|---|---|
| Proceso iterativo documentado | 25 % | Al menos cuatro versiones reales del prototipo, cada una con su propia evidencia fotográfica/audiovisual, y con evolución de diseño significativa entre una y otra. |
| Rationale de la evolución | 25 % | Calidad y honestidad de las justificaciones: principios del curso, discusiones, feedback, evidencia o restricciones documentadas; incluye lo que se descartó y por qué. |
| Revisiones (R1 · R2 · R3) | 15 % | Llegaron preparados a las tres instancias, y lo discutido — registrado en los apuntes de los ayudantes — fue ponderado con razones en las versiones siguientes: adoptado o descartado, siempre con argumentos. |
| Feedback al otro grupo | 10 % | Calidad del feedback dado en la R2 — específico, anclado en los principios, constructivo — según los apuntes del ayudante supervisor y la sección correspondiente del documento. |
| Prototipo final físico-digital | 15 % | La combinación físico-digital funciona, la sonificación está integrada con sentido, y el conjunto comunica el mensaje con coherencia. |
| Evaluación con usuarios | 10 % | La hoja del observador seguida con el objeto físico — bitácora con citas y acciones, heurísticas, preguntas de cierre —, hallazgos concretos (manos y sonido incluidos) y efecto visible (y explícito) en el proceso. |
Esta pauta produce la nota grupal de la entrega. Sobre ella se aplica el modificador individual que sale del diálogo en las revisiones R1 y R3 (ver sección 4).
Esta es la estructura exacta del documento que deben entregar — cópienla y complétenla. El corazón del documento cuenta el proceso en orden cronológico, versiones y revisiones intercaladas, para que la historia de la iteración se lea de corrido. Pueden agregar subsecciones si les sirve, pero ninguna de estas partes puede faltar.
Campos de cada versión (V1–V4): identificación (fecha + commit/tag del código) · evidencia (fotos y, cuando hay interacción, video corto con manipulación y sonido) · qué cambió (máx. 8 líneas) · por qué cambió, el rationale (máx. 12 líneas) · qué se descartó (máx. 5 líneas).
Campos de cada revisión (R1–R3): fecha · síntesis de lo discutido (breve) · decisiones tomadas: qué adoptaron, qué descartaron y por qué (máx. 10 líneas).
Campos de la hoja del observador (sección 8, por ronda): quién fue el pensador y cuándo (máx. 2 líneas) · la bitácora (tiempo · cita literal · acción física) · qué dijo del sonido al manipular · heurísticas que fallaron · las tres respuestas de cierre: atasco, hipótesis equivocada, cambio concreto · efecto en el proceso (en qué transición de versión se refleja — o por qué no).
Se entrega un único PDF. Cómo lo produzcan es asunto del grupo — Word, Google Docs, LaTeX, Markdown exportado, lo que prefieran — pero lo que se envía es un PDF, legible y con la estructura de la plantilla de la sección 11.
Envíen el PDF exclusivamente mediante este formulario: Entrega 2 — Proyecto Visualización de Información IIC2026. Entregas por otros medios descuentan puntaje de la nota final.