Experiencias interactivas · Guía práctica
Operar, ensayar y recibir una experiencia interactiva
Una experiencia necesita una salida clara cuando el público cambia, un dato se pierde o alguien necesita asistencia. La operación se diseña junto con el contenido.
Participar sin depender de un único gesto
Ofrecé una forma equivalente de elegir o responder cuando alguien no puede saltar, levantar una mano, mantenerse de pie o usar su teléfono. Puede ser un pulsador alcanzable, selección en pantalla o asistencia del anfitrión. La alternativa debe conservar el sentido de la actividad.
- Mostrar instrucciones claras y confirmación visual; no comunicar el turno sólo con color o sonido.
- Preparar subtítulos revisados y sincronizados, incluidos sonidos necesarios para comprender el contenido. Prever descripción de información visual relevante.
- Evitar que la única salida exija repetir el gesto que falló. Dar tiempo para decidir, poder pausar y ajustar estímulos según el diseño.
Ensayo propuesto: participar sentado, sin voz y sin smartphone; completar la tarea con el control alternativo y pedir asistencia. Revisar alcance, legibilidad y escucha desde las posiciones previstas. Las referencias WAI orientan el diseño; evaluar la experiencia completa con sus usuarios y especialistas antes de declarar cumplimiento de una norma.
Una persona, un grupo y una fila necesitan reglas distintas
Definí qué inicia la sesión y cuándo vuelve a estar disponible: presencia, confirmación, tiempo acordado o cierre del anfitrión. Separá zona activa de espera para que el movimiento de la fila no cambie la imagen de quien participa.
- Asignar prioridad cuando ingresan varias personas: turno, zona o acción compartida. Mostrar quién puede actuar y cómo se suma un acompañante.
- Acordar duración objetivo, aviso de cierre y reinicio. Un temporizador operativo no debe echar sin explicación a quien necesita asistencia.
- Dimensionar atención con llegada estimada, duración y capacidad de acompañamiento. No confundir sesiones por hora con aforo permitido.
Ensayo propuesto: entrada adelantada del próximo participante, abandono, acompañante y sesión sin acción. Verificar que se borran selecciones de la sesión anterior y no se atribuyen al siguiente visitante. El operador puede pausar nuevas entradas y guiar la salida. Coordiná la circulación con el recinto y la producción, y acordá cómo se habilitan las nuevas sesiones desde el control previsto.
Usar el dato mínimo para la respuesta
Para activar una onda puede alcanzar una presencia o posición efímera. Antes de incorporar cámara, voz o nube, dibujá qué datos entran, dónde se procesan, qué sale del dispositivo y qué se conserva. Un resultado numérico no garantiza por sí solo anonimato.
- Priorizar estados de zona sobre identificación cuando la intención no necesita identidad. Evaluar pulsador o selección manual sin cámara.
- Si una cámara es necesaria, definir campo y procesamiento; no convertir la grabación en un subproducto automático. Para voz, confirmar si el servicio transmite o retiene audio.
- Separar recursos de intérpretes autorizados y entradas del público. Usar personajes ficticios o activos con derechos y permiso de uso; informar cuando la representación es sintética.
Revisión propuesta: mapa de datos, servicios, retención, accesos y responsable por tramo; probar alternativa sin captura identificable. Acordar información y permisos necesarios con los responsables del evento y sus asesores. El alcance técnico no modifica por sí mismo avisos legales ni acredita cumplimiento de privacidad.
Estados claros y mando del operador
- Activo
- Dato vencido → espera
- Operador → local
- Preview → habilitación
Para el público, espera, escucha, respuesta y pausa deben verse distintos. Para el operador, también importan fuente válida, edad del dato, contenido seleccionado y modo activo. Un indicador “conectado” no basta para saber si el personaje está respondiendo bien.
- Definir prioridad del mando manual frente a sensores y solicitudes remotas; evitar dos controladores que se sobrescriben.
- Acordar cue de espera, contenido local y modo asistido con el sistema de control previsto. Exigir confirmación de estado cuando la interfaz lo permita.
- Al volver de una falla, descartar acciones vencidas y revisar preview antes de habilitar la respuesta pública.
Ejemplo propuesto: activo → dato vencido → espera; desde cualquier estado, operador → local; recuperación → preview → habilitación acordada. El reinicio no debe mostrar información de una sesión anterior.
Ensayo propuesto: fallo de entrada durante respuesta, dos órdenes contradictorias y recuperación. Registrar orden solicitada y estado observado por separado. Esta lógica se aplica a imagen/audio no críticos; no es un controlador de maquinaria ni de seguridad.
Varias jornadas: volver a un estado conocido
Prepará una secuencia de apertura documentada por responsable: confirmar versión de contenido/proyecto, servicios necesarios, entradas, calibración y salida antes de invitar público. La operación real sigue los procedimientos de equipos y recinto.
- Antes de abrir: comparar marcas físicas, probar zona y control asistido, escuchar voz y revisar subtítulos, reinicio de sesión y pieza local.
- Durante: registrar degradación de detección, cambios de luz, periféricos desgastados y tiempos de recuperación. Reservar pausas de revisión sin público activo.
- Al cerrar: detener participación, conservar proyecto aprobado y registro de incidencias; aplicar la retención de datos acordada y el cierre técnico del sistema.
Ensayo propuesto: reinicio completo autorizado fuera de programa y vuelta a la misma configuración, sin depender de la memoria de un único operador. Comprobar qué ajustes se conservan y cuáles deben restaurarse. Probar respaldo y sustitución antes del evento, sin instalar actualizaciones durante programa por rutina.
Un cambio de sensor, posición, contenido, firmware o versión puede invalidar parte de la prueba anterior. Registrar el cambio y repetir sólo las comprobaciones afectadas. El mantenimiento de superficie y periféricos se hace con métodos aprobados para el sistema.
Ensayo con condiciones representativas del evento
La prueba debe usar personaje, contenido, luz, sonido, vestuario y zona previstos. Una demostración silenciosa con una persona frente al sensor no comprueba una activación con fila, música y cambios de iluminación.
- Matriz de condiciones: luz prevista y cambios, ruido, una/varias personas, alturas, ropa, oclusión, sesión prolongada y reinicio. Acordar qué variaciones importan para el guion.
- Por prueba: versión, condición, estímulo, resultado esperado, resultado observado, método, tolerancia, responsable y evidencia autorizada. Un campo sin observar se marca pendiente.
- Variar una condición a la vez cuando se busca causa; después repetir el recorrido completo bajo carga representativa. Registrar también la alternativa asistida.
Ejemplo de criterio para ensayar: “Cuando dos personas se cruzan, el sistema mantiene la selección de la sesión activa o pasa a espera, según la regla acordada”. Durante el ensayo, anotá qué ocurrió y comparalo con ese criterio.
Las pruebas de pérdida de datos, enlace y recuperación se preparan fuera de programa con fuentes de prueba. La habilitación física corresponde al montaje real y sus responsables. Si cambia una condición relevante, identificar qué aceptación necesita revisarse antes de abrir.
Entrega y aceptación: alcance, archivos y pruebas
La entrega debe permitir que el responsable entienda qué recibe y cómo operar el alcance aprobado. Separá archivos editables, recursos de reproducción, documentación e interfaces. Una carpeta de videos sola no describe un sistema interactivo.
- Inventario: proyecto/build, recursos, versiones, formatos, dispositivos/interfaces, licencias y derechos aplicables. Identificar qué se transfiere y qué depende de terceros.
- Operación: mapa de señales y coordenadas, guion de estados, controles, apertura/cierre, respaldo y contactos responsables acordados.
- Pruebas: matriz con esperado/observado, condiciones, método, fecha y evidencia autorizada. Separar revisión documental, simulación y ensayo físico.
- Aceptación: registrar desviaciones, restricciones de uso, acciones pendientes, responsable y criterio para cerrar cada una. Completá la aceptación después de comprobar esos criterios con el sistema real.
Revisión propuesta: otra persona abre la documentación, identifica la versión aprobada, sigue un reinicio fuera de programa y demuestra modo asistido y respaldo bajo supervisión. Confirmar que los recursos pueden recuperarse desde las copias acordadas y que las dependencias están identificadas.
La habilitación del sistema requiere revisar montaje y condiciones de uso con sus responsables. La recepción se acuerda para el sistema real y las condiciones ensayadas. Cambios posteriores de hardware, versión, luz o recorrido pueden exigir comprobaciones adicionales.
Preguntas para preparar la configuración
¿Una demostración con datos ficticios equivale a un ensayo del evento?
Permite revisar estados o reglas dentro de esa simulación. El evento necesita probar detección, luz, audio, conexión, superficie y operación con condiciones representativas. El registro debe separar lo esperado de lo observado.
¿Qué debería quedar documentado al recibir el sistema?
Versiones y recursos, mapa de señales y coordenadas, controles, respaldo, licencias y responsabilidades. Sumá resultados de pruebas, restricciones de uso y acciones pendientes con su criterio de cierre.
Fuentes y alcance
- W3C WAI — Motion Actuation — Criterios para ofrecer controles alternativos a los movimientos del dispositivo.
- W3C WAI — Captions/Subtitles — Texto sincronizado de voz y sonidos necesarios para comprender el contenido.
- W3C — Privacy Principles, Statement 2025-05-15 — Principios de diseño y minimización para revisar la ruta de información.