Un proyecto completo desde la primera semana; cuatro versiones de diseño, cada una con su porqué.
Hoy, con Claude Code o Antigravity, una visualización interactiva y sonora se construye en una tarde: la parte "difícil" ya no es mérito. Por eso esta entrega no premia llegar al resultado, sino iterarlo: partir de una idea completa y mejorarla durante semanas — discutiendo, criticando, descartando y justificando — hasta que el diseño esté a la altura del mensaje. Deberán documentar al menos cuatro versiones y el porqué racional de cada evolución.
Un resultado sobrio con un proceso de diseño claro y bien argumentado vale más que un resultado espectacular con un proceso mal documentado o reconstruido a última hora.
Una visualización de información interactiva y con sonificación, publicada en la web, que comunique de manera efectiva un mensaje a partir de un conjunto de datos elegido libremente por el grupo.
Partan completos desde el día uno. La V1 ya debe ser una visualización interactiva y sonora funcionando — construirla es rápido con los agentes de IA del curso. El trabajo de las semanas siguientes no es agregar piezas cada vez más difíciles: es iterar el diseño de esa idea completa hasta que comunique de verdad. Ese proceso es lo que esta entrega documenta.
El proyecto se documenta como una secuencia de al menos cuatro versiones, repartidas en las semanas de trabajo — el ritmo natural es una versión por semana. Cada versión es un estado completo, funcional y razonable del proyecto: algo que se puede usar, mostrar y discutir. Lo que cambia entre una versión y la siguiente no es la cantidad de tecnología: es la calidad del diseño.
Una iteración puede tocar cualquier frente — afinar el mensaje, rehacer la forma visual, repensar la interacción, rediseñar la sonificación, 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, la crítica interna del grupo a la luz de los principios del curso — y se justifica.
La primera versión ya lo tiene todo: mensaje, datos, forma visual, interacción y sonificación funcionando. No importa que esté cruda — importa que sea discutible: es el material de la primera crítica seria.
Qué no estaba funcionando — del mensaje, de la forma, de la interacción, del sonido — y cómo lo mejoraron. Aquí se nota el efecto de la R1, la primera revisión con el equipo docente.
El diseño se afina: jerarquías, percepción, los detalles de la interacción, el rol exacto del sonido. Las decisiones se vuelven más finas y las justificaciones, más precisas — alimentadas por la R2, la revisión entre pares, y/o la evaluación con usuarios.
El cierre, tras la R3 — la última revisión con el equipo docente: los últimos ajustes justificados y el balance del recorrido — qué mejoró desde V1, y qué decidieron no cambiar y por qué. Es la versión que mejor comunica el mensaje, no la que más cosas tiene.
Cuatro es el mínimo: si su proceso real tuvo más versiones o un cambio de rumbo 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 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 la V1 funcionando, 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 proyecto ajeno. El feedback que dan también se evalúa (sección 4). |
| Entre V3 y V4 | R3 — equipo docente | Se revisa cómo evolucionó el proyecto 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 10).
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 — mirar con ojos críticos el proyecto 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, fecha aproximada y commit o tag de GitHub correspondiente. Obligatorio: las versiones deben ser verificables en el historial del repositorio. |
| Evidencia visual y sonora | Cada versión con su propia evidencia: captura(s) de pantalla y un video corto (o GIF con enlace al video) donde se vea la interacción y se escuche la sonificación de esa versión. La evolución del diseño tiene que poder verse y oírse, 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 al menos una de estas fuentes: principios del curso (percepción, Gestalt, jerarquía, ink-ratio, mantra de Shneiderman, principios de sonificación), lo discutido en las revisiones (con el equipo docente o entre pares), feedback de usuarios (thinking aloud) o evidencia de los datos. Máximo 12 líneas. Es la parte con más peso en la nota. |
| Qué se descartó | Alternativas que consideraron o probaron y no siguieron, y por qué. Descartar con criterio también es diseñar. 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 la técnica de pensar en voz alta (thinking aloud), en el momento del proceso donde más les sirva — idealmente entre V2 y V3, o entre V3 y V4. Se recomiendan dos rondas: una a mitad de camino y una hacia el final. Es la técnica de evaluación más barata y más poderosa que existe: una persona explora la visualización diciendo todo lo que pasa por su cabeza, y ustedes escuchan lo que la viz comunica de verdad — no lo que creían haber diseñado.
Cada ronda sigue esta hoja del observador, y su registro completo va en el documento:
Efecto en el proceso: indiquen explícitamente en qué transición de versión (por ejemplo, V3 → V4) se incorporó — o se decidió no incorporar, y por qué — lo aprendido.
/v1, /v2… en Pages) para que el equipo docente pueda recorrer la evolución.| Criterio | Peso | Qué se mira |
|---|---|---|
| Proceso iterativo documentado | 25 % | Al menos cuatro versiones completas y verificables (commits/tags), cada una con su propia evidencia visual y sonora, y con evolución de diseño significativa entre una y otra. |
| Rationale de la evolución | 25 % | Calidad y honestidad de las justificaciones: ancladas en principios del curso, discusiones, feedback o evidencia de los datos; 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. |
| Implementación final | 15 % | La visualización interactiva y sonora funciona en GitHub Pages, es coherente con el mensaje y aplica los principios vistos en el curso. |
| Evaluación con usuarios | 10 % | La hoja del observador seguida y completa — bitácora con citas literales, heurísticas, preguntas de cierre —, hallazgos concretos (también sobre el sonido) 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 3).
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) · evidencia (capturas + video corto con interacció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 7, por ronda): quién fue el pensador y cuándo (máx. 2 líneas) · la bitácora (tiempo · cita literal · acción) · qué dijo del sonido · 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 10.
Envíen el PDF exclusivamente mediante este formulario: Entrega 1 — Proyecto Visualización de Información IIC2026. Entregas por otros medios descuentan puntaje de la nota final.