Diseñando lo que ocurre
Una gramática de eventos para interfaces de usuario
Manuscrito completo revisado


## Introducción

## La pregunta que aparece al construir interfaces
Este libro nace de una práctica, no de una pretensión.
Durante años, trabajando en front-end, me encontré una y otra vez con preguntas que las herramientas habituales no terminaban de responder del todo.
No eran preguntas espectaculares. Eran preguntas pequeñas, de esas que aparecen mientras se construye una interfaz real:
¿Por qué un botón debe responder antes de confirmar?
¿Por qué guardar no se siente igual que completar?
¿Por qué una espera necesita parecer viva?
¿Por qué una advertencia corregible no debería sentirse como una amenaza?
¿Por qué una pérdida ya producida no debería expresarse igual que un peligro todavía evitable?
¿Por qué un modal a veces cambia el contexto y otras veces solo muestra contenido?
¿Por qué el color ha cargado con tanta semántica?
¿Por qué motion, sonido, forma, presencia, háptica y accesibilidad suelen tratarse como capas separadas si el usuario las vive juntas?
No soy psicólogo. No soy neurocientífico. No pretendo dar lecciones en esos campos.
Soy un programador que, al construir interfaces, empezó a sospechar que faltaba un lenguaje para describir algo que ocurría todos los días delante de nosotros.
Las guías de diseño explicaban componentes. Los frameworks ofrecían patrones. Los sistemas de diseño ordenaban tokens. La accesibilidad establecía criterios necesarios. La psicología ofrecía fundamentos sobre percepción, atención, acción, evaluación y continuidad.
Pero entre todo eso seguía apareciendo una zona difícil de nombrar: qué ocurre cuando la interfaz responde, espera, avisa, confirma, pierde, aparece, cambia de contexto o sostiene un proceso.
Este libro intenta trabajar en esa zona.
No viene a sustituir la teoría de interfaces existente. No viene a redefinir desde cero el diseño de interacción. No viene a invadir campos que ya tienen desarrollos sólidos.
Viene a completar una pregunta concreta desde otra perspectiva:
¿Podemos pensar la interfaz como una gramática de eventos?
La web será el campo principal de ejemplos, porque ahí trabajo y porque ahí la fragmentación se ve con mucha claridad: DOM, CSS, JavaScript, estados, eventos técnicos, tokens, componentes, motion, accesibilidad, sonido y comportamiento aparecen como capas separadas.
Pero el usuario no vive capas. Vive eventos.
Percibe que algo respondió. Que algo sigue ocurriendo. Que algo se guardó. Que algo reclama atención. Que algo puede perderse. Que algo ya se perdió. Que algo apareció. Que el contexto cambió. Que algo quedó completado. Que el sistema puede actuar por él.
Este libro propone una forma de nombrar esos eventos.
No como verdad final. No como dogma. No como framework cerrado. Sino como una herramienta para pensar mejor una parte de la interfaz que ya estaba funcionando, aunque muchas veces no tuviera nombre.
La hipótesis es sencilla:
La interfaz no solo tiene componentes, estados y efectos.
Tiene eventos.
Y esos eventos necesitan una gramática.


## Alcance de la propuesta
Esta gramática no pretende agotar todos los eventos posibles de cualquier interfaz ni sustituir las teorías existentes de HCI, accesibilidad o diseño de interacción.
Propone un vocabulario operativo para describir eventos recurrentes en interfaces digitales, especialmente útil en producto digital, sistemas de diseño y desarrollo front-end.
En dominios especializados —trading, medicina, CAD, simulación, sistemas críticos— pueden aparecer eventos propios que requieran extensiones, subfamilias o reglas específicas. La gramática no se cierra ante ellos: ofrece criterios para decidir cuándo una diferencia merece entrar en el sistema y cuándo debe tratarse como verbo, fase, intent, canal de expresión o composición.
Este libro debe leerse como una propuesta práctica con fundamentos teóricos, no como una ley universal de la percepción ni como una especificación técnica cerrada.

## Nota terminológica
El libro usa algunos términos ingleses porque también están pensados para funcionar en documentación técnica, diseño de sistemas y código. Las familias semánticas se nombran como contact, commit, signal, handle, emerge, shift, sustain y delegate. En el texto narrativo se explican en español; en tablas, notación y ejemplos técnicos se mantiene la etiqueta inglesa.
La palabra intent se usa como etiqueta del sistema. No significa “intención del usuario”. Significa la valoración que declara un evento cuando debe percibirse como neutro, confirmatorio, resolutivo, corregible, amenazante o perdido.
El término motion se usa como canal de expresión. No equivale simplemente a animación técnica. La animación es la implementación; motion es el movimiento tal como participa en la lectura del evento.
Este libro usa semántica en sentido operativo: el significado que un evento adquiere para el usuario dentro de una interfaz. No pretende construir una semántica formal en sentido lógico.

## Dónde se sitúa esta propuesta
Esta gramática no nace en el vacío. Dialoga con tradiciones que han pensado la interacción, la acción, la percepción, la semiótica y la accesibilidad desde otros ángulos.
La Semiotic Engineering entiende la interacción humano-computador como comunicación entre quienes diseñan el sistema y quienes lo usan. Esta propuesta comparte esa preocupación por el significado, pero trabaja en una escala más concreta: el evento que la interfaz hace perceptible.
La Activity Theory entiende la tecnología como mediación de la actividad humana. Este libro no sustituye ese marco, pero toma de él la idea de que una interfaz no puede analizarse solo como objeto visible: debe entenderse por las acciones que habilita y transforma.
El Ecological Interface Design trabaja la interfaz como soporte para actuar en sistemas complejos. Esta gramática comparte la preocupación por hacer visibles relaciones operativas, aunque se centra en producto digital, sistemas de diseño y eventos de interfaz.
WAI-ARIA ya proporciona una semántica técnica para accesibilidad web mediante roles, estados y propiedades. Esta propuesta no reemplaza ARIA; intenta complementar esa semántica técnica con una gramática de eventos perceptibles para diseño e implementación.
Los sistemas de design tokens y componentes han permitido estandarizar color, espaciado, tipografía, elevación, estados y variantes. Esta gramática no sustituye esos sistemas. Propone una capa anterior: declarar qué evento ocurre antes de decidir qué token, componente o canal de expresión lo materializa.
La contribución del libro no es inventar la interacción desde cero. Es ofrecer un lenguaje operativo para que diseñadores, programadores y equipos de producto puedan hablar con precisión de lo que ocurre en una interfaz.


## CAPÍTULO 1
Qué entendemos por interfaz
Hacia una definición operativa de la interfaz
La palabra interfaz parece clara hasta que uno intenta definirla con precisión.
En el trabajo cotidiano solemos usarla sin demasiadas dudas. Decimos que una interfaz tiene botones, menús, formularios, diálogos, listas, pestañas, estados de carga, mensajes de error y acciones disponibles. Decimos que una interfaz es clara, confusa, pesada, fluida, accesible, elegante o difícil de usar.
La palabra sirve para muchas cosas. Quizá por eso también oculta algunas.
Durante mucho tiempo, la definición más práctica ha sido suficiente: una interfaz es el punto de contacto entre una persona y un sistema. Es la superficie mediante la cual el sistema se vuelve visible, interpretable y manipulable.
Esa definición ha sido útil. Todavía lo es. Gracias a ella hemos aprendido a construir pantallas legibles, jerarquías visuales, patrones de navegación, controles reutilizables y guías de estilo.
El problema no es que esa definición sea falsa. El problema es que empieza a quedarse corta.
Porque cuando una persona usa una interfaz, no se relaciona únicamente con una superficie. También percibe respuestas, cambios, interrupciones, confirmaciones, esperas, apariciones, pérdidas, errores, desplazamientos, manipulaciones y consecuencias.
Una interfaz no es solo aquello que está ahí. Es también aquello que ocurre.
Si la interfaz se entiende solo como superficie, el componente tiende a convertirse en la unidad principal de análisis. Pero si la interfaz se entiende también como lugar donde ocurren transformaciones, aparece otra pregunta:
¿Qué clase de evento está percibiendo el usuario?

## 1. La interfaz como superficie
La concepción clásica de interfaz nace de una necesidad concreta: hacer que un sistema pueda ser usado. Un sistema informático, por sí mismo, no se ofrece directamente a la percepción humana. Sus operaciones internas no son visibles. Sus estados no se presentan espontáneamente como posibilidades comprensibles.
La interfaz aparece para mediar esa distancia. Convierte estructuras internas en formas perceptibles. Traduce posibilidades abstractas en controles. Presenta estados. Organiza caminos de acción.
Desde este punto de vista, la interfaz es una superficie de traducción. No una superficie en el sentido pobre de «lo visual», sino en el sentido de una zona de contacto: el lugar donde dos realidades distintas se encuentran.
Esta tradición ha producido herramientas indispensables: jerarquía visual, contraste, espaciado, agrupación, estados de componente, affordances, patrones de navegación, consistencia, accesibilidad, sistemas de diseño y componentes reutilizables.
Nada de eso queda invalidado por la propuesta de este libro. Una teoría del evento necesita apoyarse en esa base.
Principio
La gramática del evento no sustituye a la gramática visual; la prolonga.
Pero la superficie, por sí sola, no basta. Porque la experiencia de uso no está hecha solo de elementos dispuestos en el espacio. Está hecha de elementos que cambian, responden, aparecen, desaparecen, se desplazan, se fijan, se bloquean o se transforman.
La interfaz no es una imagen. Es una situación que evoluciona.

## 2. El límite de la superficie
Pensemos en algo sencillo: un usuario pulsa un botón para guardar cambios. Desde la implementación pueden ocurrir muchas cosas: se dispara un evento click, el botón entra en estado active, aparece un spinner, se envía una petición, se deshabilita el control, llega una respuesta, se muestra una confirmación, cambia un estado interno, quizá aparece un toast.
Técnicamente son muchas operaciones. Para el usuario, sin embargo, hay una secuencia más compacta: he actuado; el sistema me ha sentido; algo está ocurriendo; el resultado ha quedado confirmado.
Figura 1.1
La experiencia no se organiza según nuestras capas de implementación. Se organiza según unidades de sentido operativo.
Lo mismo sucede con un diálogo modal. Desde la superficie, es una capa que aparece sobre otra. Pero desde la experiencia, puede significar cosas muy distintas: una confirmación ligera, una interrupción crítica, un cambio temporal de foco, una elección irreversible.
La interfaz no solo representa estados; también organiza transformaciones.

## 3. Del objeto al cambio
El diseño de interfaces ha desarrollado una cultura poderosa alrededor del objeto. Definimos botones, inputs, selects, cards, dialogs, menus, tooltips, accordions, tabs. Cada componente tiene una anatomía, unas variantes, unos estados y unas reglas de uso.
Ese enfoque ha sido enormemente productivo. Pero el objeto no siempre es la unidad que el usuario necesita comprender. Un botón no es significativo solo por ser botón. Lo es por lo que permite hacer y por lo que ocurre cuando se actúa sobre él.
Por eso, para una teoría semántica de la interfaz, el centro debe desplazarse: del componente al evento, de la forma al cambio, del estado aislado a la transformación, de la propiedad visual al significado perceptivo.
Distinción clave
Un componente es una entidad de diseño. Un evento es una unidad de experiencia.
A partir de ahí aparece una segunda idea: una interfaz no es solo una superficie visible, sino la dimensión perceptible de un contexto operativo. Cuando usamos una interfaz, no estamos mirando figuras flotando en una pantalla. Estamos dentro de una situación de acción. Queremos hacer algo, corregir algo, elegir algo, esperar algo, confirmar algo. Hay objetivos, estados, restricciones, riesgos, expectativas y consecuencias. La interfaz es la forma sensible que adopta todo ese contexto.

## 4. Qué llamamos contexto operativo
Un contexto operativo es la situación de uso en la que una acción tiene sentido. No es solo la pantalla. No es solo el estado interno. Es el conjunto dinámico de condiciones que hacen que una acción signifique algo.
Figura 1.2
Cuando un usuario pulsa «Eliminar», el contexto operativo no se reduce al botón rojo. Incluye qué se elimina, si hay deshacer, si la acción es irreversible, si el elemento tiene valor, si forma parte de una estructura más grande, si el usuario espera confirmación y si la pérdida debe comunicarse como amenaza, riesgo o hecho consumado.
El contexto operativo no es una capa más del sistema. Es aquello de lo que la interfaz es manifestación perceptible.

## 5. La interfaz como dimensión perceptible
Si el contexto operativo es la situación de acción, la interfaz es aquello que permite percibirlo. No todo el contexto se vuelve sensible de la misma manera. Algunas partes se expresan mediante texto. Otras mediante posición. Otras mediante color. Otras mediante movimiento. Otras mediante sonido. Otras mediante ausencia, bloqueo, espera o silencio.
La interfaz no necesita contestar siempre con palabras. Parte de su trabajo consiste en distribuir respuestas entre señales perceptivas: posición, contraste, ritmo, continuidad, jerarquía espacial, tono, presencia, desaparición. Un campo que tiembla prepara la atención. Un botón que se comprime preserva la sensación de contacto. Un panel que aparece desde un origen hace visible una relación. Un objeto que se eleva al ser arrastrado hace sensible el cambio de régimen.
Por eso conviene hablar de dimensión perceptible. La interfaz es la zona donde el sistema se vuelve perceptivamente disponible para un cuerpo humano: visible, audible, táctil, temporalmente inteligible y accionable.

## 6. La interfaz no es solo visual
Uno de los supuestos más persistentes en el diseño de interfaces es que la interfaz es fundamentalmente visual. Este supuesto tiene razones históricas claras: la pantalla ha sido el medio dominante, las herramientas de diseño trabajan sobre superficies visuales, la web misma nació como documento visible.
Pero incluso dentro de lo visual, conviene distinguir canales que suelen mezclarse. Un cambio de color no comunica lo mismo que un desplazamiento. Una sombra no comunica lo mismo que un borde. Una aparición no comunica lo mismo que una vibración de alerta.
Figura 1.3
La interfaz no es visual más algunos extras. Es perceptiva. Y esa percepción se distribuye entre canales distintos, cada uno con mecanismos propios, reglas propias y condiciones propias de eficacia. El hecho de que algunos canales no estén disponibles en ciertos entornos no los vuelve teóricamente irrelevantes.
La pregunta de fondo es siempre la misma: ¿qué necesita percibir el usuario para entender lo que ocurre?

## 7. Estados, eventos y consecuencias
Un estado describe una condición relativamente estable: seleccionado, desactivado, cargando, inválido. Un evento describe una transformación: seleccionar, desactivar, empezar a cargar, fallar.
La diferencia importa porque el usuario necesita entender ambas cosas. Necesita saber que algo está seleccionado, pero también necesita percibir que la selección acaba de ocurrir. Necesita saber que algo está cargando, pero también necesita percibir cuándo empezó y si sigue vivo.
Tabla 1 — Los cuatro planos de análisis de la interfaz
Una interfaz centrada solo en estados puede mostrar correctamente el resultado final, pero dejar pobremente articulado el cambio que llevó hasta él. Por eso este libro insistirá en que una interfaz no debería limitarse a mostrar estados finales. Debe hacer legibles las transformaciones relevantes.

## 8. Qué cuenta como evento
No cualquier cambio perceptible merece el mismo rango. Para hablar de evento en sentido fuerte hacen falta tres condiciones.
Primero, debe haber una modificación perceptible. Algo debe cambiar en el campo de experiencia del usuario.
Segundo, esa modificación debe tener relevancia operativa. Debe afectar a la acción, la atención o la interpretación del estado.
Tercero, debe poder inscribirse en una clase reconocible. Una teoría necesita identificar diferencias recurrentes.
Definición
Un evento es una modificación perceptible del contexto operativo que tiene significado para la acción, la atención o la interpretación del estado.
Esta definición excluye tanto la pura lógica interna como la ornamentación sin función. Un callback técnico no es necesariamente un evento. Una animación decorativa tampoco. Pero cuando una modificación perceptible ayuda al usuario a entender qué está ocurriendo, empieza a tener estatuto de evento significativo.

## 9. Un botón no es un evento
Tomemos un botón simple: «Guardar». Desde el punto de vista del componente tiene un label, un tamaño, una variante, estados hover, active, disabled. Pero desde el punto de vista del evento, el mismo botón puede participar en secuencias distintas.
Figura 1.4
En todos los casos el componente puede ser «un botón de guardar». Pero los eventos no son los mismos. Una teoría centrada solo en componentes tiende a ocultar esa diferencia. Una teoría centrada en eventos la vuelve explícita.

## 10. Abrir no siempre significa lo mismo
Un tooltip aparece. Un dropdown aparece. Un modal aparece. Una página nueva aparece. Una notificación aparece. Un error aparece. Superficialmente podríamos decir: todos son eventos de aparición. Pero esa descripción es demasiado gruesa.
Figura 1.5
Un tooltip revela información auxiliar sin cambiar el marco principal. Un modal reorganiza el foco operativo y subordina lo demás. Una notificación introduce un mensaje iniciado por el sistema. «Algo aparece» no basta. La pregunta relevante es: ¿qué tipo de aparición es esta dentro del contexto operativo?

## 11. Por qué esta redefinición importa al programar
Un click no es una semántica. Un change no es una semántica. Un submit no es una semántica. Un drag no es una semántica. Son disparadores técnicos. Pueden dar lugar a eventos muy distintos.
Un click puede ser contacto, consolidación, navegación, apertura, amenaza, pérdida o confirmación. Un submit puede ser inicio de proceso, culminación, fallo, riesgo o resolución. Un drag puede ser manipulación, desplazamiento, reordenación o descarte.
Cuando no tenemos vocabulario para estas diferencias, las resolvemos de forma local. Una teoría semántica permite que antes de discutir «qué transición ponemos aquí», podamos preguntar: ¿qué evento estamos haciendo perceptible? Y antes de discutir «qué color usamos»: ¿este evento es evaluable o solo estructura el campo?

## 12. Resumen operativo
No estamos diciendo que la interfaz clásica esté equivocada. No estamos diciendo que todo deba animarse, sonar o vibrar. No estamos diciendo que los componentes dejen de importar. No estamos diciendo que todo cambio sea semántico. No estamos diciendo que la ciencia pueda dictar cada duración o cada frecuencia.
Lo que sí estamos diciendo es más sencillo:
La interfaz no se comprende del todo si solo se analiza como superficie de componentes. También debe analizarse como sistema perceptivo de eventos.

## 13. Síntesis
Esta idea se desarrollará con más precisión en el capítulo de fundamentos psicoperceptivos. Allí veremos que la interfaz no solo se organiza visualmente; también se apoya en percepción de campo, affordances, atención, evaluación, movimiento, sonido, multisensorialidad y experiencia corporal.
Por ahora basta con fijar una tesis:
DISTINCIÓN
La interfaz no es visual más algunos extras. Es perceptiva.

## Síntesis
La interfaz es la dimensión perceptible de un contexto operativo.
Tabla 2 — El desplazamiento conceptual que propone este libro
El usuario no necesita percibir solo que algo existe, sino qué tipo de cambio ha ocurrido y qué implica. Desde aquí, el siguiente paso será desarrollar la noción de evento con más detalle.
Porque si la interfaz es la dimensión perceptible de un contexto operativo, entonces su unidad básica de cambio no puede ser únicamente el elemento visible.
Tiene que ser el cambio significativo.
Tiene que ser el evento.
La redefinición de interfaz como dimensión perceptible de un contexto operativo prepara el desplazamiento central del libro: del componente al evento. El componente sigue siendo necesario, pero ya no basta como unidad principal de significado. Cuando la interfaz cambia, responde, espera, interrumpe, confirma o pierde algo, el usuario no interpreta solo objetos: interpreta eventos.
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="2412"/><w:gridCol w:w="2412"/><w:gridCol w:w="2412"/><w:gridCol w:w="2412"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>PLANO
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>PREGUNTA
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>EJEMPLO
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>FORMA TÍPICA
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Componente
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>¿Qué es esto?
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>botón, modal, toast
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Elemento del DOM
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Estado
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>¿En qué condición está?
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>seleccionado, abierto, cargando
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Clase CSS, propiedad
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Evento
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>¿Qué cambio acaba de ocurrir?
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>seleccionar, abrir, iniciar carga
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Transición, señal perceptiva
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Consecuencia
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>¿Qué implica ahora?
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>quedó fijado, hay que esperar
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Interpretación del usuario
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>ANTES
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>DESPUÉS
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Interfaz como superficie
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Interfaz como dimensión perceptible
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Componente como centro
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Evento como unidad de significado
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Estado final
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Transformación significativa
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Efecto local
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Gramática del cambio
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Implementación fragmentada
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Experiencia unificada

## CAPÍTULO 2
Por qué preguntamos ahora
Sedimentación, dependencia del camino y carga paradigmática
El capítulo anterior propuso una redefinición de la interfaz: no solo como superficie visible de componentes, sino como dimensión perceptible de un contexto operativo. Esa redefinición abre una pregunta incómoda.
Si la interfaz es algo más que una superficie, si el usuario no percibe solo botones, menús, colores o estados, sino también respuestas, esperas, confirmaciones, interrupciones, pérdidas, apariciones y cambios de contexto, ¿por qué durante tanto tiempo hemos diseñado y programado como si esas dimensiones pertenecieran a capas separadas?
La respuesta fácil sería decir que el diseño de interfaces arrastra una deuda histórica. Pero lo que ha ocurrido no es exactamente deuda técnica. Muchas categorías no se adoptaron como soluciones provisionales, sino como supuestos tan naturales que ni siquiera parecían necesitar examen.
Este capítulo sostiene que el diseño de interfaces arrastra tres mecanismos entrelazados: sedimentación cultural (capas de convenciones heredadas que se acumulan sin revisión profunda), dependencia del camino (decisiones iniciales que se vuelven difíciles de abandonar porque el ecosistema se organiza alrededor de ellas) y carga paradigmática (supuestos invisibles que determinan qué preguntas parecen naturales y cuáles ni siquiera aparecen).
Figura 2.1

## 1. Por qué «deuda técnica» no basta
La deuda técnica implica normalmente tres cosas: una decisión consciente, un intercambio temporal y una posibilidad futura de corrección. Alguien sabe que está tomando un atajo, acepta el coste posterior y deja abierta la posibilidad de pagarlo.
Muchas convenciones del diseño de interfaces no nacieron así. Cuando se adoptaron categorías como success, warning, danger o info, no parece que la industria estuviera diciendo «esto es provisional hasta que desarrollemos una teoría afectiva más sólida». La convención era familiar, comprensible y útil. Parecía natural.
Lo mismo sucede con el sonido. La web nació en un contexto donde el audio era técnicamente difícil, socialmente problemático y muchas veces mal usado. La desconfianza tenía razones legítimas, pero no equivalía a una teoría perceptiva del canal auditivo.
Principio
Una deuda técnica se contrae sabiendo que se contrae. Un supuesto no examinado opera precisamente porque no se percibe como supuesto.
Figura 2.2

## 2. Sedimentación cultural
Las convenciones no se han contraído como deudas. Se han sedimentado como capas. Cada generación de herramientas, medios y prácticas ha depositado una capa sobre la anterior. La interfaz digital heredó convenciones del papel, del diseño editorial, de la señalización industrial, de los sistemas operativos de escritorio, de la web documental, de los frameworks CSS, de los sistemas de diseño corporativos y de las librerías de componentes.
Ninguna de esas capas es absurda. Cada una resolvió problemas reales en su momento. El problema aparece cuando olvidamos que eran respuestas situadas. Lo que nació como solución local puede convertirse, con el tiempo, en una categoría general no examinada.
Esa sedimentación no es mala en sí misma. Sería imposible diseñar sin herencia. Pero hay un límite. Algunas convenciones siguen funcionando porque capturan intuiciones perceptivas sólidas. Otras siguen simplemente porque el ecosistema se organizó alrededor de ellas. Y otras funcionaron en un medio anterior pero ya no bastan para un medio donde la interfaz es temporal, dinámica, multicanal y adaptativa.
Figura 2.3

## 3. Dependencia del camino
La sedimentación explica cómo se acumulan las convenciones. Pero no explica del todo por qué persisten cuando aparecen alternativas mejores. Ahí entra la dependencia del camino: una decisión inicial, tomada por razones concretas y a veces contingentes, puede condicionar todas las decisiones posteriores.
El ejemplo clásico es QWERTY. La distribución de teclado se estabilizó en un contexto tecnológico muy distinto del actual. Cuando aparecieron alternativas, ya no bastaba con demostrar que podían ser mejores. Había que vencer el coste de cambiar todo el ecosistema.
El diseño de interfaces tiene sus propios QWERTYs. La estructura success / warning / danger / info se difundió porque era útil, simple y fácil de implementar. Pero su permanencia actual no se debe necesariamente a que sea la mejor taxonomía afectiva posible. Se debe también a que frameworks, documentación, temas, equipos y hábitos se han organizado alrededor de ella.
Una convención puede persistir no porque sea óptima, sino porque el coste de abandonar el camino que abrió se ha vuelto demasiado alto.
Tabla 1 — Algunos «QWERTYs» del diseño de interfaces
Figura 2.4

## 4. Carga paradigmática
La sedimentación explica cómo se acumulan las capas. La dependencia del camino explica por qué persisten. Pero todavía queda un mecanismo más profundo: por qué ciertas preguntas ni siquiera aparecen.
Un paradigma no es solo un conjunto de prácticas. Es un marco que define qué preguntas parecen naturales, qué problemas merecen atención y qué soluciones resultan visibles. Si la interfaz se concibe fundamentalmente como superficie visual de componentes, entonces es natural preguntar por layout, color, estilo, estados y componentes. Es menos natural preguntar por evento, temporalidad, canales de expresión, coordinación multicanal o semántica de la pérdida.
Formulados explícitamente, los supuestos del paradigma dominante pueden discutirse: que la interfaz es fundamentalmente visual, que el componente es la unidad principal, que el sonido y la háptica son añadidos, que el motion es suavizado o decoración, que los intents heredados son categorías naturales, que la accesibilidad se añade después. Pero mientras no se formulan, operan como normalidad.
¿Qué evento necesita percibir el usuario y por qué canales debe hacerse legible?
Figura 2.5

## 5. Por qué ahora
Lo que ha cambiado es la convergencia de varias condiciones. Las interfaces son más dinámicas, los canales disponibles se han multiplicado, la accesibilidad ha dejado de ser un añadido, la IA cambia la naturaleza de la interfaz, y los sistemas de diseño han madurado lo suficiente como para mostrar la capa que falta.
La semántica del evento se vuelve más importante cuanto menos visible es la causalidad interna del sistema. Cuando una interfaz sugiere, anticipa, completa, genera, advierte, modifica estados o toma iniciativas, el usuario necesita entender qué tipo de evento está ocurriendo.
Figura 2.6

## 6. Qué preguntas permite formular este libro
El objetivo no es declarar obsoletas las convenciones existentes. Muchas funcionan porque capturan regularidades perceptivas reales. El problema es no poder distinguir cuáles siguen siendo fundamento y cuáles son solo sedimento.
Este libro intenta abrir un espacio donde esas preguntas puedan formularse: ¿por qué una interfaz necesita distinguir contacto de consolidación? ¿Por qué una advertencia corregible no debería sentirse igual que una amenaza urgente? ¿Por qué abrir un panel no es lo mismo que cambiar de contexto? ¿Por qué la accesibilidad debería pensarse como redistribución semántica entre canales?
Tabla 2 — Qué abre este capítulo
Figura 2.7

## 7. Síntesis
La noción de deuda técnica no basta para explicar la situación. Lo que encontramos es una mezcla de sedimentación cultural, dependencia del camino y carga paradigmática. La sedimentación explica cómo las convenciones se acumulan por capas. La dependencia del camino explica por qué persisten. La carga paradigmática explica por qué ciertas preguntas no aparecen dentro del marco dominante.
Este libro no propone rechazar esa herencia. Propone hacerla examinable. Y para examinarla necesitamos desplazar la pregunta.
¿Qué evento necesita percibir el usuario?
Si la interfaz es la dimensión perceptible de un contexto operativo, entonces su unidad básica de cambio no puede ser únicamente el componente.
Tiene que ser el cambio significativo.
Tiene que ser el evento.
Lo que ha cambiado no es que hayamos descubierto de pronto la percepción humana. La psicología de la percepción, la teoría de affordances, la atención, los modelos de evaluación afectiva, la multisensorialidad y los esquemas corporales llevan décadas ofreciendo herramientas para pensar mejor la interacción.
Lo que ha cambiado es la necesidad de reunir esos marcos en una teoría de interfaz.
Por eso el siguiente capítulo hará una pausa antes de entrar en evento, gramática e interacción semántica. Presentará los fundamentos psicoperceptivos que sostendrán el resto del libro. No para convertir el diseño en psicología aplicada mecánicamente, sino para evitar que la teoría semántica de la interfaz parezca una colección de intuiciones personales.
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="2412"/><w:gridCol w:w="2412"/><w:gridCol w:w="2412"/><w:gridCol w:w="2412"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>CONVENCIÓN
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>RAZÓN INICIAL
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>COSTE DE CAMBIARLA
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>PREGUNTA QUE ABRE
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>success/danger/info
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Categorías simples
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>APIs, temas, hábitos
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>¿Qué regiones afectivas necesita la interfaz?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Motion como adorno
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Interfaz nació estática
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Herramientas centradas en componentes
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>¿Qué significado temporal tiene cada evento?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Sonido como accesorio
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Abuso histórico, autoplay
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Desconfianza cultural
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>¿Cuándo el sonido comunica mejor?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Visual como saco único
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Tradición gráfica
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Disciplinas organizadas así
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>¿Qué canales se esconden dentro?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Accesibilidad como corrección
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Diseño primero, adaptar después
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Procesos separados
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>¿Cómo se redistribuye el significado?
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>SUPUESTO HEREDADO
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>PREGUNTA QUE AHORA PODEMOS FORMULAR
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>La interfaz es visual
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Qué canales de expresión participan realmente?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>El componente es la unidad central
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Qué eventos atraviesan los componentes?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Motion es decoración
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Qué significado temporal comunica el movimiento?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Sonido es accesorio
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Qué eventos necesitan canal auditivo?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Intent es color
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Qué evaluación afectiva comunica el evento?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Accesibilidad es adaptación posterior
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Cómo migra el significado entre canales?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Las convenciones son estándares
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Qué parte es fundamento y qué parte es sedimento?

## CAPÍTULO 3
Fundamentos psicoperceptivos de la interfaz
De qué está hecha la percepción interactiva
Si este libro sostiene que la interfaz debe entenderse como sistema perceptivo de eventos, no puede apoyarse solo en vocabulario de diseño, convenciones de framework o intuiciones de implementación. Necesita preguntarse cómo perciben las personas: cómo organizan un campo visual, cómo detectan cambios, cómo orientan la atención, cómo atribuyen causalidad, cómo evalúan una situación, cómo integran señales de varios canales y cómo convierten una acción en experiencia significativa.
Una interfaz no se comprende solo como imagen, ni solo como estructura, ni solo como código. Se comprende como un campo perceptivo en el que un usuario atiende, actúa, evalúa, predice, recuerda e integra señales distribuidas entre varios canales.
Figura 3.1

## 1. Por qué necesitamos fundamentos perceptivos
El diseño de interfaces ha construido una tradición práctica muy sólida. Sabemos organizar jerarquías visuales, usar contraste, agrupar elementos, diseñar componentes y sistemas. Pero si la interfaz hace perceptibles eventos, necesitamos explicar cómo un usuario percibe que algo ha ocurrido, que su acción fue registrada, que un estado quedó fijado, que una operación sigue viva, que una alerta reclama atención o que una pérdida ya se produjo.
Principio
Si la interfaz es perceptiva, su teoría no puede depender solo de convenciones visuales. Debe apoyarse en cómo las personas perciben, atienden, actúan y evalúan cambios.

## 2. Organización perceptiva: Gestalt, agrupación y figura/fondo
Un usuario no percibe una interfaz como suma neutra de elementos. La percibe como un campo organizado: unas cosas pertenecen juntas, otras quedan separadas; unas actúan como figura, otras como fondo. La revisión de Wagemans y colaboradores sobre un siglo de psicología Gestalt resume fenómenos como agrupación, organización figura/fondo, continuidad y cierre como principios centrales de la percepción visual.
Esto prepara una distinción esencial: hay eventos que son figura y eventos que son fondo. Un error dentro de un modal puede ser figura evaluable. La apertura del modal puede ser fondo estructural. Si no distinguimos ambas cosas, terminamos coloreando el contenedor en lugar del mensaje.
Figura 3.2

## 3. Affordances y acción situada
Una interfaz no es solo algo que el usuario observa. Es un campo de posibilidades. Gibson formuló la noción de affordance para nombrar lo que el entorno ofrece al organismo en términos de acción posible. Un botón ofrece ser pulsado. Un slider ofrece ser arrastrado. Un modal comunica que ciertas acciones quedan suspendidas y otras adquieren prioridad.
Tabla 1 — Affordances y eventos

## 4. Atención, saliencia y carga cognitiva
Una interfaz siempre compite por recursos limitados. Cada señal, cada movimiento, cada sonido y cada color saturado tiene un coste. Posner estudió la orientación de la atención como un proceso que asigna recursos de procesamiento a una parte del campo perceptivo, incluso antes de que haya movimiento ocular explícito.
No todo evento debe reclamar atención. Un signal.alert sí puede justificar interrupción. Un emerge.reveal quizá solo debe hacer aparecer contenido. Un sustain.progress debe mantener conciencia de proceso sin competir con la tarea principal.
Figura 3.3

## 5. Valoración del evento: evaluación del evento
Algunos cambios no solo se perciben. Se evalúan: ¿esto es bueno o malo para mí?, ¿favorece mi meta?, ¿bloquea mi acción?, ¿puedo corregirlo?, ¿requiere respuesta inmediata? Scherer describe el proceso emocional como una secuencia de evaluaciones en términos de relevancia, implicaciones, capacidad de afrontamiento y significado normativo.
El valoración del evento permite formular una distinción que después será central: no todos los eventos son evaluables. Algunos son mensaje (fallo, advertencia, confirmación, pérdida). Otros son marco (apertura, expansión, navegación, sostenimiento). El intent tiene sentido cuando hay algo que evaluar.
Principio
El intent no nace del color. Nace de la evaluación de un evento respecto a metas, riesgo, control y consecuencia.

## 6. Valencia y activación: el espacio afectivo
Si un evento es evaluable, necesitamos describir de qué tipo de evaluación se trata. El modelo circumplejo de Russell propone dos ejes: valencia (positivo/negativo) y activación (baja/alta activación). Esto permite distinguir regiones que el semáforo heredado (success/warning/danger/info) mezcla.
No es lo mismo threat (negativo, alta activación) que loss (negativo, baja activación). No es lo mismo affirm (positivo leve) que fulfill (positivo, activación media-alta). Esta distinción permite formular los intents no como colores, sino como regiones evaluativas del evento.
Figura 3.4

## 7. Movimiento, causalidad y continuidad
En diseño de interfaces solemos hablar de «animación» como recurso visual añadido. Pero para esta teoría conviene distinguir animación de motion. La animación es la implementación. Motion es la percepción de que algo se mueve, se comprime, aparece, se desplaza o cambia de régimen en el tiempo.
Michotte mostró que ciertos patrones simples de movimiento producen una impresión directa de causación: si una respuesta ocurre cerca de la acción del usuario y con forma temporal adecuada, puede percibirse como consecuencia de esa acción. Si llega tarde o con forma incongruente, se percibe como evento separado.
Figura 3.5

## 8. Sonido, multisensorialidad e integración de canales
El sonido tiene propiedades que otros canales no tienen: puede percibirse sin mirar la pantalla, puede comunicar urgencia rápidamente, puede marcar cierre, confirmación o pérdida, y puede funcionar como canal de respaldo cuando motion o visión están reducidos. Spence revisa cómo ciertas correspondencias crossmodales — pitch con tamaño, brillo con peso, movimiento ascendente con resolución — aparecen de forma consistente.
Principio
El problema histórico no ha sido el sonido en la interfaz. Ha sido el sonido sin gramática: arbitrario, desproporcionado o desacoplado del evento.
El usuario no percibe motion, sonido, color y háptica como departamentos aislados. Wallace y colaboradores muestran que la capacidad del cerebro para ligar estímulos de distintas modalidades depende de su estructura temporal. Si el sonido llega demasiado tarde respecto al movimiento, el usuario percibe dos eventos, no uno. Una interacción semántica multicanal necesita congruencia temporal, de intensidad, de dirección y afectiva.
Figura 3.6

## 9. Esquemas sensoriomotores y cognición corporeizada
Muchas categorías que usamos para pensar interfaces proceden de patrones corporales básicos: contacto, presión, contenedor, camino, entrada, salida, peso, resistencia, pérdida, agarre, encaje, proceso. No las usamos solo como metáforas decorativas. Funcionan porque la interfaz digital se apoya en esquemas que el usuario ya conoce por su experiencia corporal.
Algunos esquemas son agentivos e implican acción y evaluación: contacto, elección, logro, pérdida, manipulación. Otros son estructurales y organizan el campo: contenedor, camino, proceso, entrada/salida. Esta diferencia prepara la distinción entre eventos valenciales y transicionales.
Figura 3.7

## 10. Accesibilidad como prueba de arquitectura perceptiva
Si una interfaz distribuye significado entre varios canales, debe preguntarse qué ocurre cuando uno se reduce. Si el color no basta, debe haber forma, texto o posición. Si se reduce motion, la causalidad debe apoyarse en otros recursos. Si el sonido está desactivado, una alerta debe seguir siendo perceptible.
Principio
La accesibilidad no solo adapta la interfaz. Revela si el significado estaba bien distribuido entre canales.

## 11. Cómo usará este libro estos fundamentos
Tabla 2 — Mapa de fundamentos y función en el libro

## 12. El espacio evaluativo: valencia y activación
El espacio evaluativo: valencia y activación
Hasta ahora hemos descrito cómo el usuario percibe, atiende y actúa. Falta una dimensión esencial: cómo evalúa lo que ocurre.
Cuando un evento sucede, el usuario no solo lo reconoce. También lo interpreta: ¿esto es bueno o malo para mí? ¿requiere acción inmediata? ¿puedo ignorarlo? ¿ya ocurrió o aún puedo evitarlo? ¿se resolvió algo que estaba pendiente?
Una forma útil de organizar estas evaluaciones es el espacio propuesto por James A. Russell, que describe los estados afectivos mediante dos dimensiones: valencia (positivo / negativo) y activación (baja / alta).
Este modelo no pretende capturar toda la complejidad emocional. Pero resulta suficiente para distinguir diferencias que una interfaz necesita comunicar de forma consistente.
Por ejemplo: no es lo mismo algo negativo urgente que algo negativo ya ocurrido; no es lo mismo una confirmación leve que una culminación; no es lo mismo informar que advertir; no es lo mismo pedir atención que registrar una pérdida.
Estas diferencias no son estilísticas. Son operativas.
Este libro utilizará ese espacio como base para definir los intents, no como una teoría psicológica completa, sino como una estructura mínima para organizar la evaluación del evento.

## Síntesis
La interfaz se percibe como campo organizado: por eso necesitamos Gestalt y figura/fondo. Se usa como campo de acción: por eso necesitamos affordances. Compite por atención limitada: por eso necesitamos saliencia y carga cognitiva. Comunica resultados, riesgos y pérdidas: por eso necesitamos valoración del evento. Modula tono afectivo: por eso necesitamos valencia y activación. Cambia en el tiempo: por eso necesitamos motion. Puede sonar, vibrar, moverse y cambiar de presencia a la vez: por eso necesitamos multisensorialidad. Se apoya en experiencia corporal: por eso necesitamos esquemas. Y debe seguir siendo legible cuando un canal falta: por eso la accesibilidad es constitutiva, no añadida.
Estos fundamentos no pretenden probar una taxonomía definitiva ni dictar cada valor concreto de duración, frecuencia o intensidad. La ciencia no sustituye al diseño. Lo disciplina. Le impide confundir color con intent, motion con decoración, sonido con accesorio y evento técnico con significado experiencial.
Una teoría semántica de la interfaz debe apoyarse en cómo los seres humanos perciben cambios, actúan sobre posibilidades, atienden señales, evalúan consecuencias e integran canales.
El siguiente capítulo podrá volver ahora al concepto central del libro: el evento como unidad básica de cambio. Ya no partiremos solo de una intuición práctica. Tendremos un mapa de fundamentos que explica por qué el evento, y no solo el componente, puede convertirse en la unidad central de una teoría perceptiva de la interfaz.
Estos fundamentos no dictan una taxonomía cerrada. No prueban que solo existan ocho familias ni seis intents. Lo que hacen es otra cosa: ofrecen criterios para que las categorías del libro no parezcan arbitrarias.
A partir de aquí, cuando hablemos de evento, gramática, interacción semántica, familias, intent y canales, no estaremos hablando de nombres inventados desde el diseño. Estaremos nombrando formas recurrentes de percibir, actuar, atender, evaluar e integrar cambios.
DISTINCIÓN
Este libro no inventa categorías perceptivas. Les da nombre dentro de la interfaz.
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="2412"/><w:gridCol w:w="2412"/><w:gridCol w:w="2412"/><w:gridCol w:w="2412"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>AFFORDANCE
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>QUÉ OFRECE
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>EVENTO
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>LECTURA
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Presionar
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Actuar sobre algo
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>contact
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>El sistema ha sentido mi acción
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Elegir
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Fijar una opción
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>commit.select
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Esto queda elegido
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Manipular
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Mover directamente
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>handle
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Estoy controlando este objeto
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Atender
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Mirar o responder
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>signal
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Esto requiere mi atención
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Entrar/salir
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Cambiar disponibilidad
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>emerge / shift
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Algo apareció / cambió el marco
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Esperar
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Sostener proceso
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>sustain
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Esto sigue ocurriendo
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>FUNDAMENTO
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>QUÉ EXPLICA
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>QUÉ APORTA A LA TEORÍA
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Gestalt
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Agrupación, figura/fondo
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Diferencia entre marco y mensaje
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Affordances
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Percepción de acción posible
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Contexto operativo, contacto, manipulación
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Atención
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Saliencia, orientación, carga
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Signal, proporción, interrupción
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Valoración del evento
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Evaluación respecto a metas
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Semánticas valenciales/transicionales
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Valencia/activación
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Estructura afectiva básica
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Sistema de intents
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Motion
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Causalidad, continuidad, energía
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Temporalidad y física del evento
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Sonido
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Urgencia, valencia, cierre
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Microeventos auditivos
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Multisensorialidad
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Integración temporal de señales
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Evento multicanal unificado
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Esquemas corporales
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Contacto, camino, contenedor, pérdida
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Familias semánticas
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Accesibilidad
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Reducción o sustitución de canales
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Migración semántica

## CAPÍTULO 4
El evento como unidad básica de cambio
Esta definición se apoya en los fundamentos anteriores. Desde la organización perceptiva, un evento modifica el campo: algo aparece, cambia de figura, se subordina. Desde las affordances, un evento modifica lo que el usuario puede hacer. Desde la atención, un evento puede orientar, reclamar o liberar foco. Desde el valoración del evento, un evento puede volverse evaluable: favorable, riesgoso, urgente, perdido o resuelto. Desde la multisensorialidad, un evento puede distribuirse entre varios canales y aun así percibirse como una sola unidad.
Por eso un evento no equivale a un click, a un callback ni a un cambio interno de estado. Un evento existe cuando una modificación perceptible altera la relación operativa entre usuario y sistema.
Qué cuenta como cambio significativo en una interfaz
El capítulo anterior propuso una redefinición inicial: la interfaz no es solo una superficie de componentes, sino la dimensión perceptible de un contexto operativo. Desde ahí aparecía una consecuencia inevitable: si la interfaz no solo muestra cosas, sino que también hace ocurrir transformaciones, entonces la unidad básica de cambio no puede buscarse únicamente en el componente. Tiene que buscarse en el cambio. Tiene que buscarse en el evento.
Su objetivo no es todavía cerrar la taxonomía de familias semánticas. Tampoco entrar en canales de expresión, intents o valores concretos. Aquí necesitamos algo más básico: entender qué es un evento, qué lo diferencia de una acción técnica, de un estado, de una variación visual, de un efecto y de una consecuencia.
¿Cuándo algo que cambia en una interfaz merece ser tratado como evento significativo?

## 1. El cambio no basta
En una interfaz pasan muchas cosas. Un botón cambia de color al pasar el cursor. Un icono modifica su opacidad. Una lista se reordena. Un menú aparece. Un campo muestra un error. Un spinner empieza a girar. Un toast entra desde la esquina. Una tarjeta desaparece. Un sonido breve acompaña una confirmación. Una vibración responde al contacto. Una vista sustituye a otra.
Podríamos llamar «evento» a todo eso. Pero esa definición sería demasiado amplia. No todo cambio perceptible es un evento en sentido fuerte. Algunos cambios son ornamentales. Otros son puramente mecánicos. Otros son variaciones locales sin relevancia para la acción del usuario.
La pregunta no es simplemente: ¿algo ha cambiado? La pregunta es: ¿ese cambio modifica lo que el usuario entiende que está ocurriendo?
Principio
Un evento no es cualquier cambio perceptible. Es un cambio perceptible con relevancia operativa.

## 2. Variación, efecto y evento
Una variación es un cambio perceptible de bajo compromiso semántico. Un botón que cambia su sombra al hover puede indicar interactividad, pero si no altera el estado ni comunica una acción registrada, no es todavía un evento pleno.
Un efecto es una realización perceptiva concreta: una animación, un sonido, una vibración, un cambio cromático, un fade, un bounce, un shake. El efecto pertenece al plano de los medios.
Un evento pertenece al plano del significado operativo. No se define por la forma que toma, sino por la transformación que vuelve legible.
Un shake puede ser un efecto. Pero «el sistema reclama atención por una discrepancia» es un evento. Un bounce puede ser un efecto. Pero «esta decisión ha quedado fijada» es un evento.
Figura 4.1

## 3. El evento no está en el código
Un click solo dice que ocurrió una activación de entrada. No dice qué significa esa activación para el usuario. El mismo click puede abrir un menú, confirmar una eliminación, seleccionar una opción, iniciar una carga, enviar un formulario, cerrar un diálogo o navegar a otro destino. Desde el código, todos empiezan igual. Desde la experiencia, no tienen nada que ver.
Tabla 1 — Tres planos del evento
Distinción
Un evento técnico ocurre en el sistema. Un evento ocurre para el usuario.

## 4. El evento como transformación del contexto operativo
Un evento es una modificación perceptible del contexto operativo que tiene significado para la acción, la atención o la interpretación del estado.
Esta definición contiene tres condiciones. La primera: una modificación perceptible. Algo debe cambiar en el campo de experiencia. La segunda: relevancia operativa. El cambio debe afectar a lo que el usuario puede hacer, debe atender o necesita interpretar. La tercera: debe pertenecer a una clase reconocible — contacto, consolidación, señal, manipulación, aparición, cambio de contexto, sostenimiento.
Figura 4.2
Un botón que se comprime al ser pulsado comunica contacto. Un switch que cambia de estado comunica consolidación. Un modal que se abre comunica cambio de contexto. Un spinner que aparece comunica sostenimiento. Un elemento que desaparece comunica pérdida o retirada. En todos estos casos, lo importante no es que algo cambie en pantalla. Lo importante es que el cambio reorganiza la relación entre usuario y sistema.

## 5. Acción, evento y consecuencia
La acción es lo que hace el usuario o el sistema. El evento es la transformación perceptible que esa acción produce. La consecuencia es lo que cambia después en el contexto operativo.
Figura 4.3
Acción, evento y consecuencia no siempre coinciden en el tiempo. A veces la acción y el evento están muy próximos. A veces la acción inicia un proceso. A veces la consecuencia llega después. A veces el sistema produce un evento sin acción inmediata del usuario: una notificación, una alerta, una sesión expirada.

## 6. Estado y evento: dos formas de sentido
Un estado describe una condición relativamente estable: seleccionado, abierto, cargando, inválido. Un evento describe una transformación: seleccionar, abrir, empezar a cargar, fallar. Los estados orientan. Los eventos explican cómo se llegó a esa orientación. El usuario necesita ambos.
Tabla 2 — Estado, evento y consecuencia
Una interfaz centrada solo en estados puede mostrar el resultado final, pero dejar pobremente articulado el cambio que llevó hasta él. Una interfaz centrada solo en eventos puede volverse efímera. La teoría necesita ambos planos.

## 7. El evento tiene forma temporal
Un evento no es solo una etiqueta. Tiene forma en el tiempo. Algunos son casi puntuales. Otros tienen fase de entrada y salida. Otros son sostenidos. Otros tienen estructura interna compleja.
Figura 4.4
Un contacto se siente como ataque. Una consolidación se siente como asentamiento. Una señal se siente como irrupción. Una aparición se siente como entrada de presencia. Un cambio de contexto se siente como cruce de umbral. Un sostenimiento se siente como continuidad. Una manipulación se siente como trayectoria.
La temporalidad no es decoración. Es parte de la semántica.

## 8. El evento tiene granularidad
Los eventos pueden observarse a distintas escalas. A escala pequeña, un botón responde al contacto. A escala media, una operación se inicia. A escala de flujo, un usuario completa un proceso. La teoría necesita permitir todos los niveles, pero sin mezclarlos.
Conviene distinguir entre microeventos (cambios inmediatos), eventos compuestos (varias fases), secuencias semánticas (encadenamientos de familias distintas) y resultados de la acción (estabilización del nuevo contexto).
Principio
No todos los eventos tienen el mismo tamaño. Algunos son microeventos; otros son secuencias completas de transformación.

## 9. El evento tiene origen
Un evento puede estar iniciado por el usuario o por el sistema. Cuando el usuario inicia, la interfaz debe preservar la relación causal entre acción y respuesta. Cuando el sistema inicia, la cuestión principal es atención: el usuario necesita saber por qué algo aparece o por qué se interrumpe el flujo.
Tabla 3 — Origen del evento

## 10. El evento tiene dirección
Algunos eventos son reversibles. Otros no. Algunos abren posibilidades. Otros las cierran. Abrir no significa lo mismo que cerrar. Seleccionar no significa lo mismo que deseleccionar. Eliminar no significa lo mismo que ocultar.
Muchas implementaciones tratan estas parejas como simples reversos animados. Pero perceptivamente eso es insuficiente. Entrar y salir no son la misma narración en sentido contrario.
Figura 4.5

## 11. El evento tiene valencia o estructura
Algunos eventos son evaluables. Comunican algo que puede leerse como bueno, malo, urgente, grave, reparable o perdido. Una confirmación puede ser positiva. Una alerta puede ser amenazante. Un fallo puede exigir corrección.
Otros eventos son estructurales. No comunican por sí mismos una evaluación, sino una reorganización del campo perceptivo: algo aparece, se expande, cambia de plano, desplaza el foco, sostiene una operación.
Hay eventos que son mensaje. Hay eventos que son marco.
Tabla 4 — Eventos evaluables y eventos estructurales

## 12. El evento puede ser simple o compuesto
Muchos eventos reales no pertenecen a una sola familia de forma pura. Son composiciones. Un modal de confirmación destructiva combina cambio de contexto y señal de amenaza. Un drag hacia una papelera combina manipulación y pérdida. Un guardado largo combina contacto, sostenimiento y consolidación.
Figura 4.6
Un evento compuesto debe poder descomponerse en eventos simples sin perder la unidad de experiencia.

## 13. El evento tiene huella
Un evento no termina siempre cuando acaba su animación. A veces deja un estado. A veces deja una marca visual. A veces deja una obligación. A veces deja una pérdida. A veces deja una posibilidad nueva.
Conviene distinguir entre duración expresiva (el tiempo durante el cual el evento se vuelve perceptible), estado resultante (la condición que queda después), resultado de la acción (lo que cambia en el campo de acción) y huella semántica (el modo en que el evento sigue importando después de ocurrir).
Principio
La duración de un evento no equivale a su importancia. Lo decisivo es la consecuencia que deja en el contexto operativo.

## 14. El evento puede fallar
Un evento falla cuando la transformación que intenta comunicar no llega al usuario con la claridad adecuada. Puede fallar por latencia, por indiferenciación, por exceso, por ambigüedad, por canal único, por incongruencia multicanal o por falsa valencia.
Estos fallos muestran que la semántica no es un lujo. Es una forma de evitar ambigüedad, exceso y pérdida de continuidad. Una interfaz puede funcionar técnicamente y fallar semánticamente: ejecutar la acción correcta y aun así dejar al usuario con la pregunta «¿qué acaba de pasar exactamente?»

## 15. Del evento a la interacción semántica
El evento es la transformación significativa. La interacción semántica es la forma recurrente de hacerla legible. El evento de que el sistema ha registrado una acción se hace legible mediante la familia de contacto. El evento de que una decisión ha quedado fijada se hace legible mediante la familia de consolidación. El evento de que el sistema reclama atención se hace legible mediante la familia de señal.
Figura 4.7

## 16. Resumen operativo
No estamos diciendo que cada microcambio deba convertirse en categoría. No estamos diciendo que toda animación sea un evento. No estamos diciendo que la interfaz deba explicar explícitamente cada transformación. No estamos diciendo que el usuario deba aprender una taxonomía consciente.
Cuando una transformación afecta a la acción, la atención o la interpretación del estado, la interfaz debería tener una forma consistente de hacerla perceptible. Eso es todo.
Una gramática del evento no obliga a expresarlo todo con más fuerza. Al contrario, ayuda a decidir qué merece expresión y qué debe permanecer silencioso.

## 17. Síntesis
El evento es la unidad básica de cambio significativo en una interfaz. No coincide con el componente, ni con el estado, ni con el evento técnico, ni con el efecto.
Tabla de síntesis del capítulo
El capítulo anterior redefinió la interfaz. Este capítulo ha definido el evento. El siguiente paso será explicar por qué esos eventos necesitan una gramática: un sistema estable de diferencias que permita reconocerlos, componerlos y expresarlos sin depender de decisiones locales aisladas.
La pregunta ya no será solo: ¿qué evento ha ocurrido? Sino: ¿cómo puede una interfaz hacer que esa clase de evento sea reconocible cada vez que ocurre?
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>PLANO
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>QUÉ REGISTRA
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>EJEMPLO
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Evento técnico
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Una ocurrencia del sistema o dispositivo
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>click, submit, change, dragstart
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Evento
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Una transformación significativa para el usuario
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Contacto, consolidación, señal, aparición
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Interacción semántica
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Una forma recurrente de hacer legible esa transformación
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>contact, commit, signal, handle, emerge
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="2412"/><w:gridCol w:w="2412"/><w:gridCol w:w="2412"/><w:gridCol w:w="2412"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>PLANO
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>PREGUNTA
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>EJEMPLO
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>RIESGO SI FALTA
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Estado
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>¿En qué condición está?
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>El switch está encendido
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>No sabe cómo actuar ahora
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Evento
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>¿Qué cambio ocurrió?
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>El switch acaba de activarse
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>No sabe si su acción tuvo efecto
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Consecuencia
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>¿Qué implica?
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>La preferencia ya se aplicó
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>No entiende el alcance del cambio
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="2412"/><w:gridCol w:w="2412"/><w:gridCol w:w="2412"/><w:gridCol w:w="2412"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>ORIGEN
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>PREGUNTA DEL USUARIO
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>EJEMPLO
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>RIESGO
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Usuario
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>¿Mi acción tuvo efecto?
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Pulsar, arrastrar, seleccionar
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Pérdida de agencia
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Sistema
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>¿Por qué ocurre esto ahora?
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Notificación, alerta, sesión expirada
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Interrupción o sorpresa
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Mixto
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>¿Qué parte depende de mí?
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Guardar con validación, subir archivo
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Ambigüedad causal
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="2412"/><w:gridCol w:w="2412"/><w:gridCol w:w="2412"/><w:gridCol w:w="2412"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>TIPO
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>QUÉ HACE
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>EJEMPLO
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>¿ACEPTA INTENT?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Evaluable
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Comunica resultado, riesgo, pérdida o logro
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Confirmación, alerta, error, eliminación
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Sí
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Estructural
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Organiza presencia, foco, marco o continuidad
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Abrir, expandir, navegar, sostener
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Normalmente no
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Compuesto
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Combina marco y mensaje
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Modal de error, wizard con validación
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>En el mensaje, no en el marco
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>IDEA
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>SÍNTESIS
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>El cambio no basta
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Solo hay evento cuando el cambio importa operativamente
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>El efecto no basta
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Una animación o sonido no son semánticos por sí mismos
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>El código no basta
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Un evento técnico no define el significado experiencial
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>El estado no basta
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>El usuario necesita comprender la transformación
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>La duración no basta
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>La importancia depende de la consecuencia
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>La semántica organiza
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Una interacción semántica hace legible una clase de evento

## CAPÍTULO 5
Por qué una gramática del evento
De la intuición a la estructura
El capítulo anterior nos dejó en un punto delicado. Ya no estamos hablando solo de componentes. Tampoco solo de estados. Hemos empezado a llamar evento a una modificación perceptible del contexto operativo que tiene significado para la acción, la atención o la interpretación del estado.
Esa definición cambia el problema. Si la interfaz no solo muestra cosas, sino que hace perceptibles transformaciones, entonces no basta con preguntarse qué elementos hay en pantalla. Hay que preguntarse qué tipos de cambio ocurren, cómo se distinguen, cómo se repiten y cómo el usuario aprende a reconocerlos.
Si cada una de esas transformaciones se resuelve de forma local, la interfaz puede seguir funcionando, pero su lenguaje queda fragmentado. Cada componente decide cómo responder. Cada pantalla decide cómo animar. Cada equipo decide cuándo usar color, sonido, vibración o silencio. El usuario, entonces, no aprende una estructura común: interpreta caso por caso.
¿Puede una interfaz tener una gramática de sus eventos?

## 1. Por qué la palabra gramática
La palabra «gramática» no se usa aquí por adorno. Tampoco pretende trasladar de forma literal la gramática de una lengua natural al diseño de interfaces. Se usa porque necesitamos nombrar algo que las palabras «estilo», «patrón», «efecto», «animación» o «taxonomía» no terminan de cubrir.
Una taxonomía clasifica. Una guía de estilo normaliza la forma. Un patrón resuelve un problema recurrente. Un efecto materializa una respuesta perceptiva concreta. Una gramática, en cambio, define un sistema de diferencias y relaciones que permite producir significado reconocible. No se limita a decir qué unidades existen. También define cómo se distinguen, cómo se combinan, cuándo una forma cambia de sentido, qué variaciones son aceptables y qué combinaciones producen ruido o ambigüedad.
Tabla 1 — Por qué gramática y no otro concepto

## 2. Qué define una gramática del evento
La interfaz ya tiene gramáticas parciales. Tiene una gramática visual: jerarquía, contraste, alineación, proximidad. Tiene una gramática de componentes: botones, campos, menús. Tiene una gramática de estados: hover, focus, active, disabled. Pero todavía no suele tener una gramática explícita del evento: una forma sistemática de distinguir entre tocar, fijar, advertir, emerger, cambiar de marco, manipular, sostener, completar o perder.
Definición
Una gramática del evento es el sistema de diferencias, relaciones y reglas de composición mediante el cual una interfaz hace reconocibles las clases significativas de cambio que ocurren dentro de un contexto operativo.
Esta definición contiene piezas: diferencias (no todo cambio significa lo mismo), relaciones (los eventos se encadenan y componen), reglas de composición (contacto → sostenimiento → consolidación es una secuencia, no una acumulación de efectos), y reconocimiento (la gramática existe para el usuario, no para el sistema).
No llamamos gramática a esta capa porque queramos hacer una metáfora elegante. La llamamos gramática porque necesitamos algo más que una lista de eventos: necesitamos un sistema que defina diferencias, relaciones, combinaciones, modulaciones y límites de expresión. La palabra gramática aparece, entonces, porque el problema ya no es solo identificar eventos, sino articularlos. Una interfaz necesita distinguirlos, repetirlos con estabilidad, combinarlos en secuencias, modularlos cuando son evaluables, distribuirlos entre canales de expresión y reducirlos cuando la accesibilidad o el contexto lo exigen. Esa red de distinciones y reglas es lo que este libro llama gramática del evento.
Figura 5.1

## 3. Responder no es suficiente
El usuario pulsa: algo cambia. Envía: aparece un spinner. Falla: el campo se marca en rojo. Desde el punto de vista técnico, hay respuesta. Pero desde el punto de vista perceptivo: ¿qué clase de respuesta es esa?
Si todo se resuelve con respuestas locales, la interfaz puede funcionar pero no construir lenguaje. El usuario aprende por contexto, pero ese aprendizaje procede de su esfuerzo por reconstruir lo que el sistema no diferencia.
Principio
Una interfaz no necesita responder más. Necesita responder con diferencias que tengan significado.
Figura 5.2

## 4. El problema de los efectos aislados
Un efecto aislado responde a una pregunta local: ¿cómo hacemos que esto se note? Una gramática responde a otra: ¿qué clase de transformación necesita hacerse perceptible aquí? Si empezamos por el efecto, la interfaz se llena de soluciones agradables pero no coherentes. Si empezamos por el evento, el efecto se convierte en realización de una diferencia previa.
Distinción clave
Un efecto pregunta: ¿cómo se ve o se siente esto? Una gramática pregunta: ¿qué diferencia debe reconocer el usuario?

## 5. Tres fallos de una interfaz sin gramática
Indiferenciación: eventos distintos se sienten iguales. Todo resultado positivo es success, todo problema es danger, toda espera es spinner. La interfaz tiene vocabulario, pero es demasiado pequeño para las diferencias que necesita expresar.
Arbitrariedad: el mismo tipo de evento se expresa de formas distintas según el lugar. Una selección rebota en una pantalla, cambia solo de color en otra. La gramática permite variación sin perder identidad.
Capricho: estímulos sin necesidad semántica. Una animación porque «da vida», un sonido porque «queda premium». Cada estímulo que no aporta significado añade ruido. Una gramática no solo dice cómo expresar; también ayuda a decidir cuándo callar.
Figura 5.3

## 6. Gramática y economía cognitiva
Cada vez que la interfaz cambia, el usuario responde a preguntas: ¿qué cambió? ¿lo causé yo? ¿sigue ocurriendo? ¿terminó? ¿es bueno o malo? ¿debo actuar? La gramática no elimina trabajo cognitivo. Lo distribuye mejor.
Tabla 2 — Qué reduce una gramática del evento

## 7. De la consistencia visual a la consistencia semántica
La consistencia visual responde a: ¿esto pertenece al mismo sistema formal? La consistencia semántica responde a otra: ¿esto pertenece a la misma clase de evento? Un sistema puede ser visualmente consistente y semánticamente pobre: paleta impecable, componentes bien construidos, pero eventos indiferenciados.
Figura 5.4

## 8. Los niveles de la gramática
Cinco niveles que no deben mezclarse: la familia (qué clase de evento), el verbo (qué ocurre concretamente), la fase (en qué momento temporal), el intent (cómo se evalúa si es evaluable) y la realización (cómo se expresa por canales concretos).
Si mezclamos familia y efecto, acabamos diciendo «este evento es un bounce». Si mezclamos intent y color, «esto es rojo». Si mezclamos evento técnico y semántica, «esto es un click». Separar niveles permite pensar mejor.
Figura 5.5

## 9. Composición y proporción
Los eventos reales rara vez aparecen aislados. Un guardado largo contiene contacto, sostenimiento y consolidación. Una eliminación contiene contacto, señal de amenaza, cambio de contexto y pérdida. Sin gramática, son acumulación de efectos. Con gramática, cada parte tiene función.
Además, no todas las diferencias merecen la misma intensidad. Si cada guardado automático se celebra como culminación, la recompensa se desgasta. Si cada validación fallida se trata como amenaza, la interfaz fatiga.
Principio
La intensidad de una señal debe ser proporcional a la consecuencia perceptiva del evento.
Tabla 3 — Proporción semántica

## 10. La gramática debe ser multicanal
Si todo depende del color, falla ante daltonismo. Si todo depende del motion, falla ante reducción de movimiento. La gramática debe distribuir significado de forma que el evento tenga identidad que sobreviva a la reducción de un canal.
La accesibilidad no solo elimina canales; obliga a redistribuir significado.
Figura 5.6

## 11. La gramática debe admitir silencio
No todo contacto necesita sonido. No toda selección necesita celebración. No toda espera necesita animación constante. Un efecto agradable una vez puede volverse insoportable al repetirse cien veces al día.
Principio
Una gramática perceptiva no consiste en expresar siempre más, sino en saber cuándo una señal debe permanecer mínima o incluso silenciosa.

## 12. Gramática no significa rigidez
Una gramática no elimina estilo. Lo hace más responsable. Un sistema financiero, una herramienta creativa y un editor de código no deberían sonar igual. Pero si pertenecen a la misma familia de evento, deberían conservar relación reconocible con esa familia. La gramática no fija una única forma. Fija una relación entre significado y expresión.

## 13. Gramática y aprendizaje implícito
El usuario no debe aprender la gramática explícitamente. Funciona por familiaridad, por recurrencia, por diferencia sensible. El aprendizaje implícito requiere suficiente regularidad para reconocer y suficiente elasticidad para adaptarse.
Tabla 4 — Condiciones del aprendizaje implícito

## 14. La gramática como herramienta para programadores
Programar interfaces implica tomar decisiones sin nombre claro. ¿Este click confirma contacto o fija estado? ¿Este open revela contenido o cambia de marco? ¿Este drag manipula, reordena o elimina? Sin gramática, se resuelve con lógica local. Con gramática, se separan los niveles.
Figura 5.7

## 15. Lo que una gramática debe responder
Tabla 5 — Preguntas mínimas de una gramática del evento

## 16. Resumen operativo
No estamos diciendo que todas las interfaces necesiten una gramática explícita con nombres técnicos. No estamos diciendo que cada evento deba disparar motion, sonido o háptica. No estamos diciendo que la gramática deba ser idéntica en todos los productos.
Si una interfaz produce transformaciones significativas de forma recurrente, necesita una manera consistente de hacerlas perceptibles.

## 17. Síntesis
Una interfaz madura no solo necesita componentes consistentes. Necesita eventos consistentes.
Tabla de síntesis del capítulo
El siguiente paso será definir con más precisión la unidad que articula esa consistencia: la interacción semántica como configuración perceptiva recurrente que hace legible una clase de evento dentro de un contexto operativo.
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>CONCEPTO
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>QUÉ HACE
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>POR QUÉ NO BASTA
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Efecto
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Materializa una respuesta perceptiva
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Puede existir sin significado estable
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Patrón
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Resuelve un problema recurrente de interacción
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Suele estar ligado a casos concretos
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Guía de estilo
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Normaliza la forma visual
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>No siempre explica el significado del cambio
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Taxonomía
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Clasifica tipos de evento
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>No define composición, modulación ni canal
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Gramática
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Define diferencias, relaciones y reglas de combinación
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Es el nivel necesario para articular eventos como lenguaje
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>SIN GRAMÁTICA
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>CON GRAMÁTICA
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>El usuario interpreta cada cambio por contexto
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>El usuario reconoce familias de cambio
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Los efectos son soluciones locales
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Los efectos expresan eventos identificables
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>El color carga con demasiada semántica
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>La semántica se distribuye entre canales
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>La accesibilidad elimina señales sin reemplazo
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>La carga semántica puede migrar entre canales
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>EVENTO
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>CONSECUENCIA
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>INTENSIDAD RECOMENDABLE
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Contacto común
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Baja, inmediata
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Mínima y breve
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Autoguardado
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Positiva leve
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Confirmación suave
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Operación larga completada
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Positiva con tensión previa
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Resolución más expresiva
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Eliminación irreversible
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Alta consecuencia
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Señal grave, no necesariamente ruidosa
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Amenaza activa
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Urgencia alta
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Máxima claridad
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>CONDICIÓN
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>QUÉ APORTA
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Recurrencia
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>El patrón aparece suficientes veces
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Diferenciación
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>No se confunde con otros eventos
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Estabilidad
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Conserva núcleo semántico
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Proporción
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>La intensidad coincide con la importancia
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Multicanalidad
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Puede sobrevivir a cambios de canal
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Sobriedad
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>No fatiga por repetición
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>PREGUNTA
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>RESPUESTA QUE BUSCA
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Qué clase de evento es?
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Familia semántica
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Qué ocurrió concretamente?
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Verbo o variante
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿En qué momento está?
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Fase temporal
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Es evaluable?
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Posibilidad de intent
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Qué canales participan?
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Realización multicanal
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Qué intensidad merece?
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Proporción
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Qué pasa si un canal falta?
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Migración semántica
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Con qué otros eventos se compone?
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Secuencia o composición
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>DISTINCIÓN
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>POR QUÉ IMPORTA
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Efecto y evento
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>El efecto es medio; el evento es significado
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Estado y transformación
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>El usuario necesita saber qué cambió
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Marco y mensaje
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>No todo evento acepta intent
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Canal y significado
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Ningún canal agota la semántica
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Intensidad y consecuencia
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>No todo merece la misma energía
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Silencio y ausencia
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>No expresar también puede ser decisión semántica

## CAPÍTULO 6
Qué es una interacción semántica
La forma perceptiva recurrente de un evento
Los capítulos anteriores han preparado el terreno. Primero redefinimos la interfaz como dimensión perceptible de un contexto operativo. Después introdujimos el evento como unidad básica de cambio significativo. Explicamos por qué las convenciones heredadas no han formulado antes estas preguntas. Y desarrollamos por qué esos eventos necesitan una gramática.
Ahora aparece la pregunta central de este capítulo:
Una interacción semántica es una configuración perceptiva recurrente mediante la cual una interfaz hace legible una clase de evento dentro de un contexto operativo.

## 1. Por qué necesitamos otro término
Un componente nombra una unidad estructural. Un estado nombra una condición estable. Un evento técnico nombra una ocurrencia del sistema. Un efecto nombra una realización perceptiva. Un patrón nombra una solución recurrente. Un intent nombra el tono evaluativo. Pero entre todo eso falta una capa: la unidad que puede decir esto es una clase de evento que la interfaz necesita hacer reconocible.
La interacción semántica nombra la capa donde componentes, estados, efectos y colores se organizan alrededor de un significado operativo.
Tabla 1 — Por qué no basta con los términos existentes
Figura 6.1

## 2. Definición de interacción semántica
La definición contiene cinco partes: configuración perceptiva (puede incluir movimiento, color, sonido, presencia, háptica), recurrente (debe poder reaparecer en distintos componentes y situaciones), hace legible (su función es reducir ambigüedad), una clase de evento (contacto, consolidación, señal, manipulación, aparición, cambio de contexto, sostenimiento) y dentro de un contexto operativo (el significado no existe en abstracto).
Definición
Interacción semántica: configuración perceptiva recurrente que hace reconocible una clase de evento dentro de un contexto operativo.

## 3. No es una interacción concreta
El mismo gesto puede pertenecer a semánticas distintas. Un click puede ser contacto, confirmación, navegación, advertencia, pérdida, apertura, cierre o selección. La interacción concreta es la superficie gestual. La interacción semántica es la lectura significativa de lo que ocurre.
Tabla 2 — Un mismo gesto, múltiples semánticas posibles

## 4. No es una animación
Un bounce puede expresar selección, culminación, encaje o celebración. Un fade puede expresar aparición, retirada, pérdida o simple suavizado. La animación es ambigua hasta que se integra en una gramática. El orden correcto no es: tenemos un bounce → ¿qué significa? Sino: necesitamos expresar consolidación → ¿qué configuración perceptiva la hace legible?
Distinción clave
La animación pertenece al plano de la realización. La interacción semántica pertenece al plano del significado operativo.
Figura 6.2

## 5. No es un componente
La semántica de contacto puede aparecer en un botón, un icon button, una tarjeta clicable, un slider thumb o un control de reproducción. La consolidación puede aparecer en un switch, un checkbox, un chip, un filtro. La señal puede aparecer en un toast, un banner, un badge, un error inline. Si una categoría depende de un componente concreto, todavía no es una interacción semántica en sentido fuerte.
Figura 6.3

## 6. No es un patrón de diseño
Un modal de confirmación destructiva puede contener cambio de contexto, señal de amenaza, consolidación y pérdida. Un toast puede contener señal con intent de riesgo, confirmación o pérdida. El patrón organiza una solución de interfaz. La semántica organiza el significado perceptivo de los eventos que ocurren dentro.
Figura 6.4

## 7. No es un intent
La semántica responde a ¿qué clase de evento ocurre? El intent responde a ¿cómo debe evaluarse afectivamente? No es lo mismo commit + fulfill, signal + fulfill y contact + affirm. En todos hay valencia positiva, pero no el mismo evento. El intent colorea o modula la semántica. No la sustituye.
Tabla 3 — Semántica e intent no son lo mismo

## 8. La interacción semántica como unidad de articulación
Articula tres planos: el evento que ocurre, el significado operativo que ese evento tiene, y la forma perceptiva que permite reconocerlo. Si nos quedamos demasiado arriba, solo tenemos conceptos abstractos. Si bajamos demasiado pronto, solo tenemos recursos. La interacción semántica conecta ambas capas.
Figura 6.5

## 9. Toda interacción semántica responde a una pregunta perceptiva
Una semántica merece existir cuando responde a una pregunta que aparece una y otra vez en la interacción. No porque sea bonita ni porque encaje en un framework, sino porque el usuario necesita resolver esa diferencia para actuar con claridad.
Tabla 4 — Preguntas perceptivas y familias semánticas

## 10. Tiene una firma, no una receta
Una receta fija valores: duración 180ms, scale 0.97, frecuencia 2600 Hz. Una firma semántica dice algo más abstracto: breve, inmediata, proporcional, causalmente ligada a la acción, con baja persistencia. La receta puede cambiar. La firma debe permanecer.
Distinción clave
Una receta fija valores. Una firma conserva identidad bajo variación.

## 11. Puede realizarse por varios canales
Si el usuario reduce motion, la semántica no debería desaparecer. Si el sonido está desactivado, la información no debería perderse. La interacción semántica es lo que permite esa migración: sabemos qué significado debía transportarse, así que podemos redistribuirlo.
Figura 6.6

## 12. Tiene estructura temporal
Tabla 5 — Formas temporales de las semánticas

## 13. Puede componerse con otras semánticas
Un guardado largo: contacto → sostenimiento → consolidación. Una eliminación: contacto → señal de amenaza → cambio de contexto → pérdida. Un drag a papelera: manipulación → señal de destino → pérdida. La gramática permite asignar cada función a su lugar.
Figura 6.7

## 14. Tiene fronteras
Tabla 6 — Fronteras semánticas importantes

## 15. Requiere estabilidad y elasticidad
La estabilidad está en el núcleo: qué pregunta responde, qué tipo de evento hace legible, qué forma temporal tiene. La elasticidad está en la realización: duración, intensidad, estilo, tema, plataforma, accesibilidad.
Principio
La identidad de una interacción semántica no está en repetir siempre la misma forma, sino en conservar la misma función perceptiva bajo variaciones controladas.

## 16. Puede ser mínima
A veces será casi invisible. A veces una latencia ajustada. A veces una microcompresión. A veces un silencio deliberado. Cuanto más frecuente es un evento, más sobria debe ser su expresión.
Principio
Semántico no significa intenso. Significa proporcional, reconocible y necesario.

## 17. Cómo saber si algo merece ser interacción semántica
Tabla 7 — Condiciones mínimas de una interacción semántica
Una interacción semántica no se declara; se justifica.

## 18. Ejemplo: selección
El usuario marca una opción. Desde la implementación: click, state.selected = true, class="selected". Desde la experiencia: una decisión del usuario queda fijada. La selección no es mero contacto. Comunica «esto queda elegido». Si usamos la misma respuesta que para un botón cualquiera, el usuario siente que tocó pero no necesariamente que eligió.

## 19. Ejemplo: notificación
Un toast aparece, un badge cambia, un banner se muestra. La semántica no es «toast» — toast es un patrón. La semántica es señal: el sistema inicia comunicación y reclama cierto grado de atención. El intent modula: neutra si informa, riesgo si advierte, amenaza si exige reacción, pérdida si registra algo consumado.

## 20. Ejemplo: manipulación
Arrastrar un elemento no es solo pulsar y mover. Es una experiencia continua con fases: pick, carry, drop. En el pick, el objeto cambia de régimen. En el carry, conserva continuidad con el gesto. En el drop, el resultado se evalúa. La evaluación se concentra en el drop. El carry debe permanecer neutro.
Figura 6.8

## 21. Lo que una interacción semántica debe especificar
Tabla 8 — Ficha mínima de una interacción semántica

## 22. Resumen operativo
Cuando una clase de evento aparece de forma recurrente y afecta a la acción, la atención o la interpretación del estado, la interfaz necesita una forma consistente de hacerla reconocible. A esa forma consistente la llamamos interacción semántica.

## 23. Síntesis
Tabla 9 — Qué responde cada capa
Una interfaz no solo necesita componentes reutilizables. Necesita formas recurrentes de hacer legibles sus eventos.
El siguiente capítulo desarrollará los criterios para decidir cuándo una diferencia merece convertirse en interacción semántica. Porque no todo cambio necesita nombre propio. Pero los cambios que organizan la experiencia sí.
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>TÉRMINO
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>QUÉ NOMBRA
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>POR QUÉ NO BASTA
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Componente
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Una unidad estructural
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>No dice qué evento ocurre
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Estado
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Una condición estable
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>No explica la transformación
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Evento técnico
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Una ocurrencia del sistema
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>No contiene significado experiencial
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Efecto
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Una realización perceptiva
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Puede existir sin semántica
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Patrón
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Una solución recurrente
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Puede contener varias semánticas
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Intent
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Tono evaluativo
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>No define la clase de evento
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Interacción semántica
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Forma recurrente de hacer legible un evento
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Articula significado y percepción
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>INTERACCIÓN CONCRETA
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>PUEDE SIGNIFICAR
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>SEMÁNTICA POSIBLE
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Pulsar botón
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>El sistema registró mi gesto
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Contacto
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Pulsar botón
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>La acción quedó confirmada
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Consolidación
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Pulsar botón
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Se abre una superficie
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Aparición
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Pulsar botón
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Entro en otro flujo
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Cambio de contexto
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Pulsar botón
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Pierdo un recurso
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Pérdida / commit
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Arrastrar elemento
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Lo estoy moviendo
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Manipulación
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>PREGUNTA
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>PERTENECE A
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>EJEMPLO
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>¿Qué clase de evento ocurre?
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Semántica
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Contacto, señal, consolidación, aparición
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>¿Qué ocurrió concretamente?
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Verbo
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Guardar, eliminar, abrir, seleccionar
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>¿En qué fase está?
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Fase
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Enter, exit, start, progress, drop
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>¿Cómo se evalúa?
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Intent
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Neutral, affirm, fulfill, risk, threat, loss
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>¿Cómo se expresa?
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Canales
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Motion, sonido, color, presencia, háptica
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>PREGUNTA PERCEPTIVA
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>FAMILIA SEMÁNTICA
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿El sistema ha sentido mi acción?
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Contacto / contact
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Esto ha quedado fijado?
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Consolidación / commit
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Algo reclama mi atención?
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Señal / signal
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Estoy controlando este objeto?
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Manipulación / handle
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Algo ha aparecido o desaparecido?
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Aparición / emerge
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Ha cambiado el contexto?
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Cambio de contexto / shift
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Esto sigue ocurriendo?
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Sostenimiento / sustain
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>SEMÁNTICA
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>FORMA TEMPORAL
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>LECTURA
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Contacto
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Puntual
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>«me ha sentido»
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Consolidación
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Breve + resolutiva
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>«esto quedó fijado»
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Señal
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Entrada + posible persistencia
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>«atiende esto»
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Aparición
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Entrada / salida
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>«algo entra o sale del campo»
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Cambio de contexto
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Cruce de umbral
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>«ahora estás en otro régimen»
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Manipulación
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Pick / carry / drop
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>«lo agarro, lo muevo, lo coloco»
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Sostenimiento
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Inicio / continuidad / fin
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>«sigue ocurriendo»
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>NO CONFUNDIR
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>DIFERENCIA
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Contacto / consolidación
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Registrar gesto no es fijar estado
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Aparición / señal
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Aparecer no es reclamar atención
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Aparición / cambio de contexto
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Entrar en campo no es cambiar régimen
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Sostenimiento / culminación
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Seguir ocurriendo no es haber terminado
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Ocultación / pérdida
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Retirar de la vista no es destruir
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Intent / semántica
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>El tono evaluativo no define el tipo de evento
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>CONDICIÓN
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>PREGUNTA
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Recurrencia
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Aparece en muchos contextos?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Relevancia operativa
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Afecta a acción, atención o estado?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Diferenciabilidad
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Se distingue de otras semánticas?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Estabilidad
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Puede aprenderse?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Multicanalidad
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Puede expresarse por más de un canal?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Economía cognitiva
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Ayuda a comprender mejor?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Proporción
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Su intensidad corresponde a su consecuencia?
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>CAMPO
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>PREGUNTA
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Qué comunica
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Qué tipo de evento vuelve legible?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Pregunta perceptiva
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Qué necesita resolver el usuario?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Fronteras
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Con qué no debe confundirse?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Temporalidad
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Cómo ocupa el tiempo?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Origen
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Responde al usuario o parte del sistema?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Intent
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Es evaluable o estructural?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Canales
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Por dónde se expresa mejor?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Accesibilidad
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Cómo migra si un canal falta?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Proporción
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Cuánta energía merece?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Errores
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Cómo suele fallar?
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>CONCEPTO
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>QUÉ RESPONDE
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Componente
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Qué elemento participa?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Evento técnico
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Qué ocurrió en el sistema?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Evento
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Qué transformación percibe el usuario?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Interacción semántica
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Cómo se hace reconocible esa clase de transformación?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Intent
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Cómo se evalúa afectivamente, si procede?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Realización
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Por qué canales se expresa?

## CAPÍTULO 7
Criterios para identificar una interacción semántica
Cuándo una diferencia merece convertirse en lenguaje
Si una interacción semántica es una forma recurrente de hacer legible una clase de evento, necesitamos decidir qué diferencias merecen convertirse en semánticas y cuáles no. Si distinguimos demasiado poco, la interfaz se empobrece. Si distinguimos demasiado, la gramática se vuelve opaca.
Figura 7.1

## 1. El riesgo de declarar semánticas por intuición
Una semántica no se justifica porque podamos nombrarla. Se justifica porque nombra una diferencia que el usuario necesita reconocer de forma recurrente para actuar con claridad.
Principio
Una interacción semántica no existe porque tenga nombre. Existe cuando nombra una diferencia que el usuario necesita percibir.

## 2. Criterio 1: relevancia operativa
Una diferencia merece convertirse en semántica si afecta a la acción, a la atención o a la interpretación del estado. Una semántica no debería nacer de una variación estética, sino de una diferencia operativa.

## 3. Criterio 2: recurrencia estructural
Una interacción semántica debe corresponder a una clase de evento que reaparece en distintos lugares, componentes o situaciones. Si solo ocurre en un caso específico, puede resolverse como comportamiento local.
Figura 7.2

## 4. Criterio 3: diferenciabilidad perceptiva
No basta con que internamente sepamos que dos eventos son distintos. El usuario debe poder percibir esa diferencia. Contacto no debería sentirse igual que consolidación. Aparición no debería sentirse igual que señal. Cambio de contexto no debería sentirse igual que expansión.
Principio
Una diferencia que no puede percibirse todavía no funciona como diferencia semántica.
Figura 7.3

## 5. Criterio 4: estabilidad de significado
Una semántica debe conservar su significado a través de distintas realizaciones. Si solo existe cuando usamos una animación concreta, no es todavía una semántica fuerte. Es un efecto. La semántica de contacto puede expresarse con microcompresión visual en web, pulso háptico en móvil, sonido breve sin motion o cambio de foco visible. La realización cambia; el significado permanece.

## 6. Criterio 5: elasticidad de realización
Una interfaz bancaria, una aplicación médica, una herramienta creativa y un editor de código no deberían expresar igual sus eventos. Pero si pertenecen a la misma familia de evento, deberían conservar relación reconocible con esa familia.
Figura 7.4

## 7. Criterio 6: economía cognitiva
Una interacción semántica debe reducir carga interpretativa. Si una categoría nueva obliga a pensar más, recordar más o diferenciar matices irrelevantes, probablemente no merece existir. La pregunta: ¿esta semántica ayuda al usuario a interpretar mejor el evento o solo satisface nuestra necesidad interna de clasificar?

## 8. Criterio 7: transversalidad
Si una supuesta semántica solo existe dentro de un componente concreto, quizá no estamos ante una semántica sino ante un patrón local. La transversalidad es lo que convierte una respuesta en lenguaje del sistema.
Figura 7.5

## 9. Criterio 8: compatibilidad multicanal
Una semántica no debería depender exclusivamente de un único canal. Si se reduce motion, parte del significado puede migrar a color, forma, texto o sonido. Si el color no es fiable, la forma, el texto, la posición o el icono deben sostener la diferencia.
Principio
Una semántica no debería vivir en un canal. Debería poder viajar entre canales sin perder su función.

## 10. Criterio 9: capacidad de composición
Las interacciones semánticas no aparecen siempre aisladas. Una categoría merece entrar en la gramática si puede componerse con otras sin generar ambigüedad. Esto exige fronteras claras.
Figura 7.6

## 11. Criterio 10: proporción expresiva
Si todo suena, nada importa. Si todo vibra, la háptica se vuelve ruido. Si todo rebota, la confirmación pierde valor. La proporción expresiva pregunta: ¿cuánta energía perceptiva merece este evento?
Tabla 1 — Proporción expresiva

## 12. Criterio 11: asimetría significativa
Abrir no significa lo mismo que cerrar. Seleccionar no significa lo mismo que deseleccionar. Eliminar no significa lo mismo que restaurar. La asimetría es especialmente clara en semánticas como handle, donde pick, carry y drop no son fases equivalentes.
Principio
Una salida no es siempre una entrada invertida. Puede tener otro significado, otra energía y otra consecuencia.

## 13. Criterio 12: sobriedad y silencio
No todo contacto necesita sonido. No toda confirmación necesita celebración. No toda espera necesita animación constante. Un sonido agradable una vez puede volverse insoportable cincuenta veces al día.
Figura 7.7

## 14. Criterio 13: posibilidad de validación
Si una semántica está bien definida, deberíamos poder comprobar si ayuda. Si retrasamos el contacto, debería disminuir la sensación de agencia. Si usamos la misma firma para contacto y consolidación, deberían aumentar las dudas sobre si el estado quedó fijado. La validación convierte la semántica en hipótesis de diseño, no en opinión estética.

## 15. Criterio 14: compatibilidad con accesibilidad
Si la semántica desaparece al quitar un canal, era demasiado frágil. Un error no puede depender solo del rojo. Una alerta no puede depender solo del sonido. Una manipulación no puede depender solo de sombra si el contraste es pobre.
Principio
La accesibilidad no solo adapta la interfaz. Revela si la semántica estaba bien distribuida.

## 16. Matriz de decisión
Tabla 2 — Matriz para aceptar una interacción semántica

## 17. Tres ejemplos
Selection: sí merece semántica, como commit.select. Fija estado persistente, tiene recurrencia alta, se diferencia de contacto, acepta intent.
Hover: no como semántica propia. Estado de disponibilidad con relevancia operativa limitada, salvo que revele evento.
Manipulation: sí, como handle. Evento continuo irreducible con estructura pick/carry/drop, alta transversalidad y multicanalidad.
Figura 7.8

## 18. Resumen operativo
Una diferencia debe convertirse en interacción semántica solo cuando ayuda de forma recurrente, perceptible y proporcional a comprender un evento operativo.

## 19. Síntesis
Tabla 3 — Síntesis de criterios
Una interacción semántica no se acepta porque sea posible. Se acepta porque es necesaria.
El siguiente capítulo dará el paso que estos criterios preparan: ¿qué familias de evento sobreviven a estos criterios y merecen formar parte de la gramática fundamental de la interfaz?
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="2412"/><w:gridCol w:w="2412"/><w:gridCol w:w="2412"/><w:gridCol w:w="2412"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>EVENTO
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>CONSECUENCIA
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>FRECUENCIA
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>INTENSIDAD
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Contacto cotidiano
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Baja
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Alta
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Mínima
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Autoguardado
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Baja positiva
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Alta
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Confirmación suave
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Operación completada
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Media-alta
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Baja
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Resolución perceptible
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Amenaza activa
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Alta
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Baja
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Interrupción justificada
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Pérdida consumada
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Alta, ya ocurrida
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Baja
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Gravedad sin alarma
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>CRITERIO
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>PREGUNTA
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>SI LA RESPUESTA ES NO…
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Relevancia
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>¿Afecta a acción, atención o estado?
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Es variación local
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Recurrencia
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>¿Aparece en distintos contextos?
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Es caso específico
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Diferenciabilidad
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>¿Se distingue perceptivamente?
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Se fusiona con otra
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Estabilidad
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>¿Mantiene significado bajo variación?
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Es receta o efecto
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Elasticidad
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>¿Puede adaptarse a plataformas?
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Es demasiado rígida
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Economía
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>¿Reduce ambigüedad?
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Añade ruido taxonómico
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Transversalidad
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>¿Atraviesa componentes?
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Es patrón local
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Multicanalidad
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>¿Puede migrar entre canales?
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Es frágil
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Composición
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>¿Se combina sin confusión?
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Necesita mejores fronteras
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Proporción
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>¿Intensidad corresponde al evento?
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Puede fatigar o trivializar
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Sobriedad
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>¿Sabe cuándo callar?
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Puede sobreestimular
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Validación
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>¿Produce predicciones observables?
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Es opinión difícil de evaluar
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Accesibilidad
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>¿Sobrevive a reducción de canal?
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>No está completa
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>CRITERIO
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>FUNCIÓN
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Relevancia operativa
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Asegura que la diferencia importa
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Recurrencia
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Evita categorías demasiado locales
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Diferenciabilidad
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Garantiza que pueda percibirse
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Estabilidad
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Permite aprendizaje
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Elasticidad
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Permite adaptación
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Economía cognitiva
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Evita ruido taxonómico
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Transversalidad
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Separa semántica de componente
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Multicanalidad
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Evita fragilidad de canal único
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Composición
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Permite secuencias complejas
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Proporción
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Calibra intensidad
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Sobriedad
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Permite callar
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Validación
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Convierte la semántica en hipótesis comprobable
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Accesibilidad
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Asegura distribución robusta del significado

## CAPÍTULO 8
De las clases de evento a las familias semánticas
Cómo reducir sin empobrecer
Los capítulos anteriores han construido ya las piezas necesarias. Este capítulo aplica los criterios del capítulo anterior. La pregunta ya no es qué es una interacción semántica, sino: ¿qué familias de evento sobreviven cuando aplicamos esos criterios?
La respuesta que propone este libro es una reducción desde un campo exploratorio amplio hacia ocho familias fundamentales: contact, commit, signal, handle, emerge, shift, sustain, delegate. Esta reducción no busca empobrecer el sistema. Busca conservar las diferencias esenciales sin convertir cada matiz en categoría raíz.
Estas familias no son categorías de diseño. Son categorías perceptivas.
Cada una se apoya en una forma distinta de organizar la experiencia: contact se apoya en agencia y causalidad inmediata; commit en cierre cognitivo y memoria de estado; signal en atención y saliencia; handle en acción corporal y manipulación; emerge en figura/fondo y presencia; shift en cambio de contexto cognitivo; sustain en continuidad temporal y reducción de incertidumbre.
PRINCIPIO
Las familias no salen de componentes. Salen de preguntas perceptivas recurrentes.
Figura 8.1

## 1. De una lista exploratoria a una gramática manejable
En los primeros borradores aparecía una lista amplia de trece semánticas. Esa lista cumplió una función necesaria: abrir el campo y mostrar que la interfaz contiene tipos de cambio muy distintos. Pero una lista exploratoria no es todavía una gramática madura. La reducción debe hacerse separando niveles: no todo debe ser familia. Algunas diferencias pertenecen al verbo, a la fase, al intent o a la realización.
Tabla 1 — Niveles de la gramática
Figura 8.2

## 2. Las ocho preguntas fundamentales
Aplicando los criterios aparece una estructura compacta de siete preguntas perceptivas. No son preguntas que el usuario formule verbalmente. Son preguntas operativas que la interfaz debe responder.
Las familias semánticas no forman una jerarquía moral. Distinguen funciones perceptivas.
Figura 8.3

## 3. Las ocho familias fundamentales
3.1. contact
Comunica que una acción directa del usuario ha sido registrada. ¿El sistema ha sentido mi acción? No comunica todavía resultado ni estado persistente. Comunica acoplamiento acción-respuesta. Aquí se reubica la antigua semántica feedback. Ejemplos: contact.press, contact.release, contact.activate.
3.2. commit
Comunica que algo ha quedado fijado, resuelto o establecido. ¿Esto ha quedado fijado? Aquí entran selección, confirmación, guardado, cancelación, fallo, eliminación, restauración, culminación o pérdida consumada. Es una de las familias más claramente evaluables.
3.3. signal
Comunica que el sistema inicia una señal para orientar la atención. ¿Algo reclama mi atención? No todas las señales son alertas. También hay anuncios, recordatorios, hints, badges y énfasis. Acepta intent plenamente.
3.4. handle
Comunica manipulación directa de un objeto. ¿Estoy controlando directamente este objeto? Tiene estructura temporal propia: pick → carry → drop. El carry es estructural y neutro. La evaluación aparece sobre todo en el drop.
3.5. emerge
Comunica aparición, retirada o disponibilidad en el campo perceptivo. ¿Algo ha entrado o salido del campo? Normalmente no acepta intent. Una aparición no es buena o mala por aparecer. Lo evaluable puede estar dentro de lo que aparece.
3.6. shift
Comunica cambio de contexto. ¿Sigo en el mismo marco o ha cambiado el régimen? Cambiar de vista, de modo, avanzar en un wizard o entrar en edición reorganiza el marco desde el que se interpreta la interfaz. Normalmente no acepta intent.
3.7. sustain
Comunica continuidad operativa. ¿Esto sigue ocurriendo? No comunica resultado. Comunica que una operación sigue viva. Si un proceso se vuelve problemático, lo más limpio es componer sustain.progress con signal.warn + risk, en lugar de convertir todo el proceso en evento evaluativo.
Tabla 2 — Las ocho familias fundamentales

## 4. Lo que se pierde y lo que se conserva
La reducción no elimina las semánticas exploratorias. Las reubica.
Tabla 3 — Reubicación de las semánticas exploratorias

## 5. Tres casos difíciles
5.1. El caso context
Cuando algo aparece sin cambiar profundamente el régimen operativo, estamos cerca de emerge. Cuando reorganiza el foco, bloquea el fondo o impone un nuevo régimen, estamos en shift. Un tooltip es emerge. Un modal bloqueante es shift. La pregunta: ¿solo aparece algo o cambia el régimen de operación?
Figura 8.4
5.2. El caso signal
Las tres semánticas previas (notification, attention, emphasis) comparten una función profunda: el sistema intenta modificar la atención del usuario. Lo que cambia es la intensidad, el tono, la persistencia y el intent. La familia es la misma: signal. La variación ocurre por verbo, prioridad e intent.
5.3. El caso commit
Commit no significa «guardar». Significa que algo queda fijado en el contexto operativo. Aquí conviene anticipar una distinción importante: threat comunica que algo está en peligro o exige reacción inmediata. loss comunica que algo ya se perdió. No son el mismo estado afectivo. Una amenaza todavía convoca acción. Una pérdida consumada registra consecuencia. Tratar una pérdida como amenaza comunica urgencia donde ya no hay nada que evitar.
Figura 8.5

## 6. Familias e intents
Las familias dicen qué tipo de evento ocurre. Los intents dicen cómo se evalúa afectivamente, cuando el evento es evaluable. La lista de intents:
Tabla 4 — Los seis intents
No todas las familias aceptan intent. Emerge, shift y sustain normalmente no. Contact puede aceptar modulación leve. Commit y signal lo aceptan plenamente. Handle lo acepta sobre todo en drop.
El intent modula eventos evaluables, no eventos cuya función es estructurar el campo perceptivo.

## 7. Ejemplo narrativo: eliminar una tarea
Imaginemos una aplicación de gestión de proyectos. El usuario ve una tarea con archivos adjuntos y comentarios. Abre el menú de acciones y pulsa «Eliminar».
1. contact.press — el sistema registra el gesto. Todavía no se ha eliminado nada.
2. signal.warn + threat — el sistema advierte. El usuario aún puede evitar la consecuencia. Corresponde threat, no loss.
3. shift.enter-mode — aparece un modal de confirmación. El modal reorganiza el contexto. El intent no pertenece al modal como contenedor, sino al mensaje evaluable dentro de él.
4. commit.delete + loss — el usuario confirma. La tarea deja de existir. Aquí entra loss: no debe sonar ni moverse como threat. Necesita registrar consecuencia, no preparar reacción.
5. sustain.progress — si hay sincronización remota. El sostenimiento no es negativo por sí mismo.
6. emerge.present — aparece una barra de undo. La aparición no es la pérdida. La pérdida ya ocurrió en el paso 4.
7. signal.announce + neutral — el sistema informa del resultado y ofrece deshacer.
Figura 8.6

## 8. Por qué no seis
Podría parecer tentador agrupar shift dentro de emerge. Pero cambiar de contexto no es lo mismo que hacer aparecer algo. Un tooltip aparece pero no cambia el marco. Un cambio de vista puede no «aparecer» como capa pero desplaza al usuario a otro régimen. Si eliminamos shift, la teoría pierde capacidad para nombrar una de las experiencias más frecuentes en interfaces complejas: cruzar un umbral operativo.

## 9. Por qué no doce
Algunas de las semánticas iniciales son mejor entendidas como verbos, variantes, fases o intents. Como muestra la tabla de reubicación, cada semántica exploratoria encuentra sitio como verbo, fase o composición dentro de las ocho familias. Si conservamos todas como raíz, la gramática se vuelve más pesada y menos aprendible. La teoría no pierde precisión al reducirlas; gana organización.

## 10. Síntesis
La taxonomía no pretende agotar todas las interfaces posibles ni fijar una verdad natural inmutable. Es una hipótesis teórica compacta: suficientemente pequeña para aprenderse, suficientemente rica para distinguir los cambios que una interfaz necesita hacer legibles.
Tabla 5 — Síntesis de las ocho familias
Una familia semántica no es una etiqueta para un efecto. Es una respuesta estable a una pregunta perceptiva recurrente.
El siguiente capítulo desarrollará la distinción que atraviesa todo el sistema: por qué algunas familias y eventos aceptan intent y otras no. Porque no todos los cambios son mensaje. Algunos son marco.
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>NIVEL
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>PREGUNTA
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>EJEMPLO
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Familia
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>¿Qué clase perceptiva de evento es?
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>contact, commit, signal
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Verbo
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>¿Qué ocurrió concretamente?
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>select, delete, notify, expand
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Fase
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>¿En qué momento temporal está?
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>enter, exit, pick, carry, drop
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Intent
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>¿Cómo se evalúa, si procede?
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>neutral, affirm, fulfill, risk, threat, loss
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Realización
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>¿Por qué canales se expresa?
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>motion, sonido, color, presencia, háptica
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="1930"/><w:gridCol w:w="1930"/><w:gridCol w:w="1930"/><w:gridCol w:w="1930"/><w:gridCol w:w="1930"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>FAMILIA
<w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>PREGUNTA
<w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>QUÉ COMUNICA
<w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>TEMPORALIDAD
<w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>INTENT
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:t>contact
<w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:t>¿me ha sentido?
<w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:t>Registro de acción
<w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:t>Puntual
<w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:t>Leve
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:t>commit
<w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:t>¿quedó fijado?
<w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:t>Estado o consecuencia
<w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:t>Resolutiva
<w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:t>Sí
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:t>signal
<w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:t>¿debo atender?
<w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:t>Mensaje del sistema
<w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:t>Entrada + persist.
<w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:t>Sí
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:t>handle
<w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:t>¿lo controlo?
<w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:t>Manipulación directa
<w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:t>pick/carry/drop
<w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:t>En drop
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:t>emerge
<w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:t>¿apareció?
<w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:t>Presencia/disponibilidad
<w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:t>enter/exit
<w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:t>Normalmente no
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:t>shift
<w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:t>¿cambió el marco?
<w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:t>Cambio de régimen
<w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:t>leave/arrive
<w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:t>Normalmente no
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:t>sustain
<w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:t>¿sigue?
<w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:t>Continuidad de proceso
<w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:t>start/progress/end
<w:tcPr><w:tcW w:type="dxa" w:w="1930"/></w:tcPr><w:p><w:r><w:t>Normalmente no
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>SEMÁNTICA EXPLORATORIA
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>REUBICACIÓN EN FAMILIAS
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>feedback
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>contact
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>selection
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>commit.select
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>completion
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>commit.complete + fulfill
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>destruction
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>commit.delete + loss
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>notification
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>signal.notify
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>attention
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>signal.alert / signal.warn
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>emphasis
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>signal.emphasize
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>revelation
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>emerge.reveal
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>expansion
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>emerge.expand
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>context
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>shift si cambia marco; emerge si solo aparece superficie
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>navigation
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>shift.navigate
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>persistence
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>sustain
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>manipulation
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>handle.pick / carry / drop
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>INTENT
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>FUNCIÓN
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>neutral
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Operación sin juicio afectivo específico
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>affirm
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Confirmación positiva leve
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>fulfill
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Resolución positiva de una tensión u objetivo
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>risk
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Problema corregible, sin urgencia extrema
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>threat
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Amenaza activa, requiere atención o acción inmediata
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>loss
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Pérdida consumada, algo ya dejó de estar disponible
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>FAMILIA
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>PREGUNTA CENTRAL
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>contact
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿El sistema ha sentido mi acción?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>commit
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Esto ha quedado fijado o resuelto?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>signal
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Algo reclama mi atención?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>handle
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Estoy controlando directamente este objeto?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>emerge
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Algo ha entrado o salido del campo?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>shift
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Ha cambiado el contexto?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>sustain
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Esto sigue ocurriendo?

## CAPÍTULO 9
Semánticas valenciales y transicionales
Qué eventos son mensaje y qué eventos son marco
El Capítulo 3 presentó varios fundamentos que ahora convergen en una distinción central.
Desde el valoración del evento, algunos eventos se evalúan respecto a metas, control, urgencia y consecuencia. Desde la Gestalt, algunos eventos funcionan como figura y otros como fondo. Desde las affordances, los eventos operativos pueden portar valencia, mientras los estructurales organizan posibilidades. Desde la atención, una señal puede reclamar procesamiento, pero una transición puede solo orientar.
Todas esas distinciones apuntan a una misma idea:
PRINCIPIO
Hay eventos que son mensaje. Hay eventos que son marco.
Los primeros pueden portar intent. Los segundos normalmente no.
El error no es usar intent. El error es aplicarlo al evento equivocado. Un modal puede contener una amenaza, pero el modal no es la amenaza. Un spinner puede preceder a un fallo, pero el spinner no es el fallo.
PRINCIPIO
El intent modula la figura evaluable, no el fondo estructural.
Principio
El error no es usar intent. El error es aplicarlo al evento equivocado. El intent modula la figura evaluable, no el fondo estructural.

## 2. Qué significa que un evento sea evaluable
Un evento es evaluable cuando puede juzgarse en relación con las metas, expectativas o riesgos del usuario. Puede ser bueno o malo, leve o grave, puede exigir acción inmediata o permitir revisión, puede resolver una tensión o abrir un problema.
Un evento transicional o estructural no porta, por sí mismo, un juicio afectivo. Su función es reorganizar el campo perceptivo, revelar disponibilidad, mantener continuidad o cambiar el contexto. Dice algo apareció, has cambiado de marco o el proceso sigue vivo — pero no dice todavía bueno, malo, grave, logrado o perdido.
Tabla 1 — Evento evaluable y evento estructural

## 3. Neutralidad no es ausencia de intent
neutral no debería convertirse en una manera de decir «no hemos pensado si este evento acepta intent». Un signal.announce + neutral sí tiene sentido: el sistema comunica algo sin valencia fuerte. Pero un emerge.open no necesita intent neutro para funcionar. Su función no es evaluar, sino organizar presencia.
Distinción
neutral es un intent de baja valencia. La ausencia de intent es otra cosa: indica que el evento no pertenece al plano evaluativo.

## 4. Recordatorio: los seis intents
Tabla 2 — Los seis intents (recordatorio — el Capítulo 9 los desarrollará en detalle)
Figura 9.2

## 5. Fundamento: valoración del evento
La teoría del valoración del evento explica por qué algunos eventos aceptan intent y otros no. El valoración del evento es el proceso por el cual un estímulo se evalúa en relación con metas, control, consecuencias y urgencia. Un error de validación dispara preguntas de valoración del evento: ¿bloquea mi objetivo? ¿puedo corregirlo? ¿es urgente? Pero la apertura de un panel o el cambio de vista no disparan el mismo tipo de evaluación.
Figura 9.3

## 6. Fundamento: figura y fondo
La percepción organiza el campo en figura y fondo. Algunos eventos son figura: el error, la advertencia, la confirmación, la pérdida. Otros son fondo estructural: el modal, el panel, la expansión, la navegación, la espera. La valencia no está en el modal como estructura. Está en el mensaje que el modal contiene.
Figura 9.4

## 7. Fundamento: esquemas sensoriomotores
Algunos esquemas son agentivos: contacto, elección, señal, logro, pérdida, manipulación/drop. Otros son estructurales: contenedor, camino, proceso, entrada/salida, plano, carry. Los esquemas agentivos tienden a admitir evaluación porque implican logro, fallo, contacto, elección, pérdida o control. Los estructurales organizan el espacio de experiencia.
Figura 9.5

## 8. Confirmaciones desde affordances, atención y afecto
Desde las affordances, los eventos operativos e informativos tienden a ser evaluables porque afectan a lo que el usuario puede hacer o debe interpretar. Las affordances estructurales organizan el campo sin portar juicio por sí mismas.
Desde la atención, signal.alert puede reclamar evaluación porque introduce una figura que el usuario debe atender. emerge, shift y sustain muchas veces redirigen o acompañan la atención sin convertir ese cambio en mensaje afectivo.
Desde el modelo valencia-activación, los intents tienen sentido cuando un evento puede ubicarse en una región evaluativa. Una expansión no es positiva por expandirse. Una navegación no es exitosa por cambiar de vista. Una espera no es amenaza por durar.
La convergencia es clara: el intent pertenece al evento que porta juicio, no al evento que organiza el espacio donde ese juicio aparece.

## 9. Mapa de familias según evaluabilidad
Tabla 3 — Familias semánticas y relación con intent

## 10. Reglas de composición
Regla 1 — El intent va en el evento evaluable. Incorrecto: emerge.open + risk. Correcto: emerge.open → signal.warn + risk.
Regla 2 — El marco puede contener mensaje, pero no absorberlo. Incorrecto: shift.enter-mode + threat. Correcto: shift.enter-mode → signal.alert + threat.
Regla 3 — El proceso no es el resultado. Incorrecto: sustain.progress + fulfill. Correcto: sustain.progress → commit.complete + fulfill.
Regla 4 — La amenaza no es la pérdida. Incorrecto: commit.deleted + threat. Correcto: commit.delete + loss. Y si antes hay advertencia: signal.warn + threat → commit.delete + loss.
Regla 5 — En manipulación, el carry no debe cargar el juicio. Incorrecto: handle.carry + threat. Correcto: handle.carry → signal.warn + threat (si zona destructiva) → commit.delete + loss (si se suelta ahí).
Figura 9.6

## 11. Antipatrones comunes
Tabla 4 — Antipatrones y correcciones

## 12. Ejemplo: archivo no guardado al cerrar
El usuario edita un documento y pulsa cerrar. La interfaz detecta cambios sin guardar.
1. contact.press — el sistema confirma que recibió el gesto.
2. signal.warn + risk — el sistema detecta cambios sin guardar. Todavía no hay pérdida; hay riesgo corregible.
3. shift.enter-mode — aparece un diálogo que bloquea la salida. El modal reorganiza el marco. El intent no pertenece al modal.
Si el usuario elige guardar: commit.save + affirm. Si descarta: commit.discard + loss. Si cancela: commit.cancel + neutral.
4. shift.exit-mode — el modal se cierra. La salida del modal no es éxito ni pérdida. Libera el marco.
Figura 9.7

## 13. Consecuencias para diseño e implementación
Reduce sobreactuación: si solo los eventos evaluables reciben intent, la interfaz reserva la energía afectiva para donde realmente la necesita.
Mejora la composición: cada parte de una operación compuesta tiene su función asignada.
Mejora la accesibilidad: si sabemos qué evento porta el significado evaluable, podemos redistribuirlo mejor cuando un canal se reduce.
Evita falsas emociones: una interfaz no debería comunicar amenaza cuando hay pérdida, ni celebración cuando solo hay confirmación suave.

## 14. Síntesis
Este capítulo ha introducido una distinción central: no todos los eventos aceptan intent porque no todos los eventos son evaluables. Esta distinción no convierte los eventos estructurales en secundarios ni prohíbe que una transición tenga atmósfera. Solo establece que el intent debe vivir donde hay evaluación operativa, no donde solo hay organización del campo.
Tabla 5 — Síntesis: evaluabilidad por familia
El intent no es una propiedad del componente, ni del contenedor, ni de la transición. Es una modulación evaluativa del evento que porta juicio.
El siguiente capítulo desarrollará en detalle el sistema de intents: por qué success / warning / danger / info no basta, por qué loss debe separarse de threat, por qué affirm no es lo mismo que fulfill, y por qué info quizá no es un intent sino una función de señal.
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="2412"/><w:gridCol w:w="2412"/><w:gridCol w:w="2412"/><w:gridCol w:w="2412"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>TIPO
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>QUÉ HACE
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>EJEMPLOS
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>INTENT
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Evaluable
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Porta juicio sobre el evento
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Confirmar, fallar, advertir, perder
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Sí
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Estructural
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Organiza el campo perceptivo
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Abrir, expandir, navegar, sostener
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Normal. no
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Compuesto
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Contiene marco y mensaje
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Modal de error, wizard con validación
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>En el mensaje
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>INTENT
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>FUNCIÓN MÍNIMA
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>neutral
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Evaluación sin tono fuerte
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>affirm
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Confirmación positiva leve
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>fulfill
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Resolución positiva
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>risk
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Problema corregible
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>threat
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Amenaza activa
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>loss
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Pérdida consumada
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="2412"/><w:gridCol w:w="2412"/><w:gridCol w:w="2412"/><w:gridCol w:w="2412"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>FAMILIA
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>NATURALEZA
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>RELACIÓN CON INTENT
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>EJEMPLO
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>contact
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Agentiva inmediata
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Modulación leve o anticipatoria
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>contact.press + threat si acción grave
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>commit
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Evaluable
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Acepta intent plenamente
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>commit.complete + fulfill
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>signal
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Informativa/atencional
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Acepta intent plenamente
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>signal.warn + risk
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>handle
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Mixta
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Intent sobre todo en drop
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>handle.drop + risk o commit.loss
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>emerge
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Estructural
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Normalmente no
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>emerge.open
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>shift
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Estructural
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Normalmente no
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>shift.navigate
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>sustain
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Estructural/temporal
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Normalmente no
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>sustain.progress
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>ANTIPATRÓN
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>QUÉ CONFUNDE
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>CORRECCIÓN
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Modal rojo
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Marco con mensaje
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>shift + signal.threat
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Spinner de error
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Proceso con resultado
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>sustain + commit.fail
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Success de navegación
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Cambio de contexto con logro
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>shift + commit.fulfill si procede
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Danger para pérdida
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Amenaza con pérdida
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>commit.delete + loss
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Alerta para toda aparición
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Aparición con señal
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>emerge + signal solo si hay mensaje
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>FAMILIA
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>EVALUABILIDAD
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>REGLA PRÁCTICA
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>contact
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Leve o anticipatoria
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Puede anticipar peso pero no porta resultado
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>commit
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Alta
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Es el lugar natural del intent
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>signal
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Alta
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Comunica el tono del mensaje
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>handle
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Mixta; sobre todo en drop
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>El carry no carga juicio; el drop sí
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>emerge
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Estructural
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>El intent va en lo que emerge, no en la aparición
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>shift
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Estructural
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>El intent va en el evento dentro del nuevo marco
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>sustain
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Estructural
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Si falla, componer con signal o commit

## CAPÍTULO 10
Intent: más allá del semáforo
Por qué success, warning, danger e info no bastan
El capítulo anterior estableció una regla fundamental:
PRINCIPIO
El intent vive en el evento evaluable, no en el contenedor estructural.
Un modal no es peligroso por abrirse. Una carga no es negativa por durar. Una navegación no es exitosa por cambiar de pantalla. El intent debe aplicarse allí donde el evento porta juicio.
Ahora aparece otra pregunta:
PRINCIPIO
¿Qué intents merece tener una interfaz?
1. El intent como problema no examinado
Existe en el diseño de interfaces una convención tan extendida que ha dejado de parecer convención.
Cuando algo ha ido mal, usamos rojo. Cuando algo requiere precaución, usamos amarillo. Cuando algo ha ido bien, usamos verde. Cuando algo es informativo, usamos azul.
A ese conjunto lo llamamos danger, warning, success, info. Pero la estructura permanece.
Lo notable no es que usemos esa convención. Lo notable es que casi nunca preguntamos de dónde viene, qué cubre, qué omite y qué mezcla.
¿Por qué success debe cubrir tanto una operación importante completada como un autoguardado menor?
¿Por qué danger debe cubrir tanto una amenaza activa como una pérdida ya consumada?
¿Por qué warning mezcla un riesgo corregible y a veces una amenaza seria?
¿Por qué info aparece junto a los intents si muchas veces no comunica valencia, sino solo saliencia atencional?
La pregunta del capítulo es:
PRINCIPIO
¿Qué ocurre cuando dejamos de tratar el intent como color y empezamos a tratarlo como evaluación perceptiva del evento?
2. La herencia del semáforo
La taxonomía heredada no nació en las interfaces digitales. Antes de que existieran botones verdes de success o alertas rojas de danger, esos colores ya cargaban con una historia de señalización industrial, ferroviaria y vial.
El rojo, el amarillo y el verde pertenecían a entornos donde una señal debía reconocerse rápido, a distancia y con consecuencias físicas claras. Eran instrucciones operativas. Esa estructura era adecuada para señalización porque resolvía un problema urgente: decisiones rápidas con bajo coste interpretativo.
Pero no era una teoría afectiva completa. No pretendía distinguir amenaza activa de pérdida consumada, ni confirmación suave de culminación significativa.
Cuando las interfaces gráficas empezaron a necesitar comunicar estados, heredaron esa estructura porque ya era comprensible. El diseño digital no inventó esa asociación. La recibió. El problema no fue heredar. El problema fue olvidar que se estaba heredando.
Con el tiempo, la asociación cromática dejó de parecer convención histórica y empezó a parecer estructura natural. El rojo pasó a llamarse danger. El verde, success. El amarillo, warning. Y el azul terminó ocupando el cajón residual: info.
Ahí ocurrió la mutación decisiva:
PRINCIPIO
Una convención cromática empezó a funcionar como si fuera una taxonomía semántica.
3. De la carretera a la pantalla
La web estabilizó esa mutación. Frameworks como Bootstrap ofrecieron clases contextuales simples: success, warning, danger, info. Aquella decisión era razonable y barata cognitivamente. Pero al entrar en CSS, tokens, componentes y guías, dejó de parecer un atajo. Se convirtió en vocabulario.
El núcleo siguió siendo: positivo, precaución, negativo grave, informativo, neutral.
Ese núcleo parecía suficiente mientras el intent solo modificaba color. Pero en una interfaz perceptiva multicanal, el intent puede modular motion, sonido, duración, ritmo, intensidad, persistencia, profundidad, forma, háptica y silencio.
En ese momento, la convención heredada muestra sus límites. Porque una cosa es elegir un color. Otra muy distinta es decidir cómo debe moverse, sonar, durar, aparecer, persistir o sentirse un evento.
4. Qué codifica realmente la convención heredada
Si examinamos success, warning, danger e info, vemos que no forman una taxonomía afectiva completa. Forman una taxonomía cromática útil. Eso no las vuelve inútiles. Las vuelve insuficientes.
Danger mezcla amenaza activa, fallo grave y pérdida consumada. Success mezcla confirmación suave, resolución positiva y culminación. Warning no distingue riesgo corregible de amenaza próxima. Info muchas veces no expresa evaluación afectiva, sino saliencia atencional.
PRINCIPIO
La convención heredada codifica colores útiles. La teoría del intent debe codificar regiones evaluativas del evento.
Por eso necesitamos separar: threat ≠ loss, affirm ≠ fulfill, info ≠ intent.
5. Qué debería ser un intent
Un intent es la modulación evaluativa de un evento.
Primero, pertenece al evento, no al componente. Segundo, pertenece al plano evaluativo, no a cualquier cambio. Tercero, debe poder modular varios canales. Cuarto, debe expresar una región afectiva funcional, no una etiqueta genérica.
6. El espacio afectivo
El sistema de intents se apoya en el espacio valencia/activación descrito por James A. Russell. No como teoría completa de la emoción, sino como base operativa.
La valencia distingue lo positivo de lo negativo. La activación distingue baja y alta movilización atencional.
No es lo mismo threat que loss. Ambos son negativos, pero uno tiene alta activación y convoca acción; el otro registra consecuencia consumada con activación más baja. Tampoco es lo mismo affirm que fulfill. Ambos son positivos, pero uno confirma suavemente; el otro resuelve una tensión.
7. Las seis regiones evaluativas
PRINCIPIO
Los intents no son colores ni estilos. Son regiones evaluativas del evento que pueden expresarse mediante distintos canales de expresión.
8. Lo que la convención heredada pierde
Threat convoca acción. Loss registra consecuencia. Affirm confirma normalidad. Fulfill resuelve tensión. Info no responde a cómo se evalúa el evento, sino a si debe ser notado.
9. Cómo modula el intent
El intent no se expresa solo en color. Puede hacerse perceptible mediante duración, energía de motion, timbre sonoro, persistencia, profundidad, forma, háptica o silencio.
10. Neutralidad no es ausencia de intent
Neutral ocupa una región de baja activación sin carga evaluativa fuerte. Pero no todo evento sin carga evaluativa necesita recibir neutral. Algunos eventos simplemente no pertenecen al plano evaluativo: emerge.open, shift.navigate o sustain.progress pueden no necesitar intent.
11. Familia e intent
La familia dice qué tipo de evento está ocurriendo. El intent dice en qué región evaluativa cae ese evento. Los canales dicen cómo se vuelve perceptible esa evaluación.
12. Antipatrones
13. Ejemplo narrativo
Autoguardado: commit.save + affirm. Región: valencia positiva, baja activación.
Envío completado: commit.submit + fulfill. Región: valencia positiva, activación media-alta.
Eliminación previa: signal.warn + threat. Región: valencia negativa, alta activación, antes de la consecuencia.
Eliminación consumada: commit.delete + loss. Región: valencia negativa, menor activación, después de la consecuencia.
14. Principios
El intent pertenece al evento, no al componente.
El intent modula el plano evaluable, no el estructural.
El intent se deriva de la evaluación del evento en el espacio valencia/activación, no del color con que se represente.
15. Síntesis
Con este capítulo, el sistema de intents deja de ser una variación cromática y pasa a funcionar como capa evaluativa del evento. A partir de ahora, color, motion, sonido, forma, presencia, háptica y tiempo no definirán el intent: lo expresarán.
Figura 10.1
Figura 10.2
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>INTENT
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>REGIÓN EVALUATIVA
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>LECTURA
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>neutral
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>baja activación, sin valencia fuerte
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>el evento no requiere evaluación afectiva significativa
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>affirm
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>valencia positiva, baja activación
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>confirma sin alterar significativamente el foco
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>fulfill
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>valencia positiva, activación media-alta
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>marca resolución de tensión o culminación
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>risk
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>valencia negativa, activación media
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>problema corregible que requiere atención
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>threat
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>valencia negativa, alta activación
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>exige atención urgente y posible acción inmediata
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>loss
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>valencia negativa, menor activación y posterioridad
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>registra consecuencia ya consumada
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>CONVENCIÓN
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>QUÉ MEZCLA
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>SEPARACIÓN PROPUESTA
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>danger / error
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>amenaza, fallo, pérdida
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>threat, risk, loss
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>warning
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>riesgo corregible, amenaza
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>risk, a veces threat
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>success
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>confirmación, resolución, logro
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>affirm, fulfill
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>info
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>saliencia, mensaje neutro
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>signal.announce + neutral
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>ANTIPATRÓN
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>QUÉ OCULTA
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>derivar intent de color
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>oculta el espacio valencia/activación
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>usar danger para pérdida
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>oculta la diferencia temporal antes/después
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>usar success para todo
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>oculta la diferencia entre baja y mayor activación positiva
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>usar info como intent
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>oculta la diferencia entre saliencia y evaluación

## CAPÍTULO 11
LOS CANALES DE EXPRESIÓN DEL EVENTO
Por dónde se vuelve sensible un evento
Hasta aquí hemos hablado de eventos.
Hemos definido la interfaz como la dimensión perceptible de un contexto operativo. Hemos explicado que el usuario no percibe solo componentes, sino transformaciones: algo responde, algo se fija, algo aparece, algo reclama atención, algo se pierde, algo continúa, algo cambia de marco. Hemos llamado evento a esa modificación perceptible del contexto operativo que tiene significado para la acción, la atención o la interpretación del estado.
Pero un evento no se percibe en abstracto.
Para que exista en la experiencia del usuario, debe tomar cuerpo en algún canal. Debe durar, moverse, aparecer, sonar, cambiar de color, ocupar un plano, modificar una forma, dejar una marca, producir contacto o retirarse.
A esa materia sensible la llamaremos canales de expresión de la interfaz.
Un canal de expresión no es una propiedad técnica. No es opacity, transform, box-shadow, background-color, AudioContext o vibration API. Esas son herramientas. El canal es lo que el usuario percibe a través de ellas: presencia, movimiento, profundidad, forma, color, sonido, contacto, tiempo, continuidad, urgencia, peso, pérdida, confirmación.
El desarrollador escribe transform: scale(.97). Pero el usuario no percibe “un transform”. Percibe que el botón cede brevemente a su acción.
El desarrollador escribe box-shadow. Pero el usuario no percibe “un box-shadow”. Percibe elevación, plano, separación o prioridad.
El desarrollador dispara un sonido breve. Pero el usuario no percibe “un wav” o “un oscillator”. Percibe confirmación, aviso, cierre, amenaza o recompensa.
El problema de muchas interfaces no es que carezcan de efectos. Es que esos efectos no están organizados como canales de significado.
El mapa completo: del evento a la lectura perceptiva
Figura 11.1
Antes de entrar canal por canal conviene situar la arquitectura completa del sistema.
La teoría que este libro propone no empieza en los canales. No empieza en el color, ni en motion, ni en sonido, ni en una vibración. Empieza en el evento.
Un evento ocurre dentro de un contexto operativo. Ese evento pertenece a una familia semántica. Puede concretarse mediante un verbo o una fase. Si es evaluable, puede recibir un intent. Y solo entonces se materializa mediante canales de expresión.
La secuencia completa es:
evento
→ familia semántica
→ verbo / fase
→ evaluación si procede
→ intent
→ canales de expresión
→ lectura unificada
Ejemplo:
commit.complete + fulfill
→ motion resolutivo
→ sonido breve ascendente
→ color positivo
→ marca persistente
→ lectura: objetivo cumplido
Otro ejemplo:
signal.warn + risk
→ forma de callout
→ color de advertencia moderada
→ icono
→ texto persistente
→ lectura: revisa esto
Y otro:
contact.press
→ baja latencia
→ estado pressed
→ micro motion opcional
→ háptica opcional
→ lectura: el sistema ha sentido mi acción
Esta secuencia evita un error frecuente: empezar por el efecto.
Si empezamos por el efecto, preguntamos:
PRINCIPIO
¿qué animación queda bien aquí?
Si empezamos por el canal, preguntamos:
PRINCIPIO
¿qué sonido usamos?
Si empezamos por el color, preguntamos:
PRINCIPIO
¿esto va en rojo, verde o amarillo?
Pero la pregunta correcta es anterior:
PRINCIPIO
¿qué evento necesita percibir el usuario?
Solo después podemos decidir por qué canales conviene expresarlo.
Crear una cadena vertical o horizontal:
EVENTO
↓
FAMILIA SEMÁNTICA
↓
VERBO / FASE
↓
EVALUACIÓN SI PROCEDE
↓
INTENT
↓
CANALES DE EXPRESIÓN
↓
LECTURA UNIFICADA
Añadir ejemplo lateral:
signal.alert + threat
→ presencia fuerte
→ color saliente
→ forma clara
→ sonido opcional
→ texto persistente
→ lectura: atiende ahora
PRINCIPIO
Los canales no se coordinan entre sí en abstracto. Se coordinan alrededor de un evento.
Principio añadido
PRINCIPIO
No se diseña un canal primero. Se identifica el evento y después se decide qué canales lo vuelven perceptible.
1. Por qué hablar de canales
----------------------------
Durante mucho tiempo hemos tratado la interfaz como si tuviera una división simple:
visual
auditivo
háptico
Y dentro de “visual” hemos metido casi todo: color, forma, layout, sombra, movimiento, aparición, profundidad, iconografía, estado, foco, contraste.
Pero esa agrupación es demasiado gruesa.
Un cambio de color no comunica lo mismo que un desplazamiento. Una sombra no comunica lo mismo que un borde. Una aparición no comunica lo mismo que un temblor. Un icono no comunica lo mismo que una deformación. Una transición lenta no comunica lo mismo que una respuesta instantánea.
Todo puede entrar por la vista, pero no todo pertenece al mismo canal de expresión.
El tiempo comunica inmediatez, espera, continuidad, persistencia o resolución.
Motion comunica causalidad, trayectoria, energía, masa y cambio.
La presencia comunica aparición, retirada, disponibilidad o desaparición.
La profundidad comunica plano, jerarquía, elevación, subordinación o régimen operativo.
La forma comunica límite, affordance, contorno, agrupación, iconografía y estabilidad.
El color comunica saliencia, estado, valencia y refuerzo, pero no debería cargar solo con todo el significado.
El sonido comunica urgencia, cierre, confirmación, alarma, pérdida o recompensa con una velocidad que el canal visual no siempre alcanza.
La háptica comunica contacto, impacto, resistencia, fricción y encaje, aunque su disponibilidad dependa mucho del dispositivo y, en la web, siga siendo limitada.
2. Fundamento psicoperceptivo: por qué no basta con decir “visual”
------------------------------------------------------------------
La separación entre canales no nace de una ocurrencia terminológica. Nace de una observación básica: la percepción humana no procesa todas las señales de una interfaz como si fueran una sola materia uniforme.
Incluso dentro de lo que solemos llamar visual, hay dimensiones perceptivas distintas. El color no comunica lo mismo que la forma. La forma no comunica lo mismo que la profundidad. La profundidad no comunica lo mismo que el movimiento. La presencia no comunica lo mismo que la posición. Todas pueden llegar por la vista, pero no cumplen la misma función cognitiva.
La psicología Gestalt mostró que la percepción organiza el campo visual según principios como proximidad, semejanza, continuidad, cierre, región común, figura/fondo y destino común. Esto ayuda a explicar por qué una interfaz no se percibe como una lista de elementos, sino como un campo organizado de relaciones.
La teoría de affordances añade otra dimensión: no percibimos solo propiedades visibles, sino posibilidades de acción. Un botón no es solo una forma rectangular; es algo que ofrece ser presionado. Un objeto elevado no es solo un objeto con sombra; puede sugerir manipulación. Un campo con borde activo no es solo un contorno; indica disponibilidad de entrada.
La atención introduce un tercer plano. Algunas señales orientan, otras interrumpen, otras sostienen y otras fatigan. Por eso no basta con decir que algo “se ve”: hay que preguntar qué demanda atencional genera.
La integración multisensorial añade todavía otra capa. Cuando motion, sonido, háptica y color ocurren de manera temporal y semánticamente congruente, el usuario puede percibirlos como un único evento. Cuando se desacoplan, los percibe como señales separadas o incluso contradictorias.
Por eso este libro distingue canales de expresión. No porque cada canal tenga fronteras absolutas, sino porque cada uno tiende a transportar tipos distintos de significado.
3. Propiedad técnica y canal de expresión
--------------------------------------
Una misma propiedad técnica puede participar en varios canales.
Opacity puede comunicar aparición, retirada, debilitamiento, indisponibilidad o subordinación del fondo.
Scale puede comunicar contacto, profundidad, énfasis, celebración o manipulación.
Box-shadow puede comunicar profundidad, elevación, foco, manipulación o cambio de plano.
Color puede comunicar estado, categoría, saliencia, valencia o marca.
Sonido puede comunicar contacto, alerta, cierre, pérdida o logro.
Vibración puede comunicar contacto, impacto, encaje, rechazo o amenaza corporal.
Por eso no basta con definir tokens técnicos. Hace falta una capa semántica que pregunte:
PRINCIPIO
¿qué dimensión del evento comunica esta propiedad?
4. El evento como composición perceptiva
----------------------------------------
Una interacción semántica no se expresa necesariamente por un solo canal.
Un contact.press puede combinar tiempo breve, micro motion, estado visual y quizá háptica.
Un commit.complete + fulfill puede combinar motion resolutivo, sonido ascendente, color positivo y marca persistente.
Un signal.warn + risk puede combinar color moderado, forma de callout, icono, texto y persistencia.
Un handle.pick puede combinar profundidad, sombra, motion de elevación, forma de agarre y háptica opcional.
Un sustain.progress puede combinar tiempo, presencia persistente, barra, texto de estado y motion suave.
Lo importante es que el usuario no perciba esos canales como piezas separadas, sino como una lectura coherente del evento.
La gramática no pregunta primero:
PRINCIPIO
¿qué animación ponemos?
Pregunta:
PRINCIPIO
¿qué evento debe hacerse perceptible y qué canales lo expresan mejor?
5. La web como campo principal de ejemplos
------------------------------------------
Este libro toma la web como campo principal de observación.
No porque la teoría se limite a la web, sino porque en la web la fragmentación de los canales se vuelve especialmente visible. El desarrollador trabaja con DOM, CSS, JavaScript, estados, clases, media queries, eventos técnicos, tokens, componentes, Web Audio API y accesibilidad. Cada capa tiene su propia lógica.
Y, sin embargo, el usuario no experimenta esas capas por separado.
La web también muestra muy bien las asimetrías entre canales:
- color, forma, presencia y motion están muy disponibles;
- sonido existe, pero está condicionado por políticas del navegador, permisos, contexto de uso y cultura del silencio;
- háptica existe de manera limitada e inconsistente;
- profundidad es simulada, pero perceptivamente poderosa;
- tiempo y latencia dependen de rendimiento, red, dispositivo y sincronización del render.
La web será nuestro laboratorio principal. No será el límite de la teoría.
6. Síntesis
-----------
Un evento necesita hacerse sensible.
Los canales de expresión no son efectos decorativos ni propiedades técnicas aisladas. Son vías por las que el usuario percibe que algo responde, aparece, se fija, reclama atención, se pierde, continúa o cambia de marco.
La tesis del capítulo puede formularse así:
PRINCIPIO
El evento es la unidad de significado. Los canales son la materia sensible que lo hace perceptible.

## CAPÍTULO 12
TIEMPO, LATENCIA Y SINCRONÍA
El canal que atraviesa todos los canales
Antes de que algo se mueva, suene, vibre o cambie de color, ocurre en el tiempo.
El tiempo no es una propiedad secundaria de la interfaz. Es el canal que organiza la relación entre acción, espera, continuidad, consecuencia y memoria.
Una interfaz puede sentirse inmediata, fluida, lenta, rota, viva, bloqueada o concluida según su temporalidad. La misma respuesta, con el mismo color y el mismo componente, cambia de significado si llega demasiado tarde o demasiado pronto.
En una teoría del evento, el tiempo no es solo duración de animación.
Es una forma de significado.
1. La interfaz como experiencia temporal
---------------------------------------
Solemos pensar la interfaz como espacio: una pantalla, una disposición, un layout, una jerarquía. Pero la interacción no ocurre solo en el espacio. Ocurre en secuencias.
El usuario actúa. El sistema responde. Algo empieza. Algo continúa. Algo se detiene. Algo termina. Algo queda.
Cada momento tiene significado.
Una respuesta inmediata comunica contacto. Una espera sin señal comunica duda. Una espera con señal comunica proceso. Una culminación comunica cierre. Una señal persistente comunica relevancia. Una desaparición demasiado rápida puede parecer error o pérdida. Una notificación demasiado larga puede convertirse en ruido.
El tiempo convierte un cambio en evento.
2. Fundamento psicoperceptivo: tiempo, agencia y espera
-------------------------------------------------------
El tiempo es uno de los canales más estudiados en interacción humano-computador, aunque a menudo se trate solo como rendimiento técnico.
En HCI clásica se han propuesto umbrales temporales aproximados que siguen siendo útiles como orientación: una respuesta casi inmediata tiende a sentirse como parte del gesto; una demora breve puede mantenerse dentro del flujo de pensamiento; una espera más larga exige feedback explícito para no convertirse en incertidumbre.
Estos umbrales no son leyes absolutas, pero ayudan a entender algo fundamental: el tiempo modifica la interpretación del evento.
Cuando la respuesta llega muy cerca de la acción, el usuario puede atribuirla a su propio gesto. Esa atribución sostiene la sensación de agencia. En una interfaz, el contacto no se comunica solo con un cambio visual, sino con un cambio suficientemente próximo a la acción.
Por eso contact.press depende tanto de la latencia. Si el sistema responde tarde, el evento deja de sentirse como contacto y empieza a sentirse como una reacción posterior del sistema.
La espera activa otro mecanismo. Cuando el usuario actúa y el resultado no llega, necesita saber si el sistema sigue trabajando. La ausencia de señal durante una espera puede interpretarse como bloqueo, fallo o pérdida de control. De ahí la función de sustain: no comunicar resultado, sino continuidad.
La sincronía multisensorial también depende del tiempo. Si un movimiento, un sonido y una vibración pertenecen al mismo evento, deben estar suficientemente coordinados para que el usuario los perciba como una unidad. Si llegan desfasados, pueden sentirse como eventos separados.
El tiempo, por tanto, no es solo duración. Es la condición que permite percibir causalidad, continuidad, espera, resolución y unidad multicanal.
3. Latencia
-----------
Latencia es el intervalo entre la acción del usuario y la respuesta perceptible del sistema.
No es solo una métrica técnica. Es una condición de agencia.
Cuando el usuario pulsa un botón, arrastra un objeto, escribe una tecla o activa un control, necesita que el sistema responda lo bastante rápido como para que esa respuesta se atribuya a su acción.
Si la respuesta llega dentro de una ventana breve, el usuario siente:
PRINCIPIO
lo he hecho yo.
Si llega demasiado tarde, empieza a sentir:
PRINCIPIO
el sistema ha hecho algo después.
Esa diferencia es semántica.
4. Duración
-----------
Duración no es lo mismo que latencia.
La latencia pregunta: ¿cuándo empieza la respuesta?
La duración pregunta: ¿cuánto dura la expresión del evento?
Un evento demasiado corto puede no ser percibido.
Un evento demasiado largo puede sentirse pesado, teatral o intrusivo.
La duración debe corresponder a la función semántica del evento.
Contact debe ser breve. Sustain puede ser prolongado. Signal puede necesitar persistencia. Commit necesita resolución. Emerge necesita entrada y salida. Handle necesita continuidad durante el gesto.
5. Espera
---------
La espera es una de las situaciones temporales más delicadas.
Cuando el usuario actúa y el sistema no puede dar un resultado inmediato, aparece una pregunta:
PRINCIPIO
¿esto sigue vivo o se ha roto?
Ahí nace sustain.
Sustain no comunica éxito ni error. Comunica continuidad operativa.
Un spinner, una barra de progreso, un skeleton, un texto “guardando…” o una actualización periódica no son elementos decorativos. Son formas de decir:
PRINCIPIO
el sistema sigue trabajando.
6. Persistencia y huella
------------------------
No todo evento termina cuando termina su animación.
Una selección queda marcada. Una alerta permanece hasta ser atendida. Un resultado deja estado. Una pérdida deja ausencia o undo. Un proceso deja progreso.
Conviene distinguir duración expresiva, persistencia, huella y caducidad.
La persistencia es especialmente importante para accesibilidad. Una señal efímera puede no ser percibida por todos los usuarios. Si la información es importante, debe dejar alguna huella.
7. Secuencia
------------
El significado temporal depende también del orden.
No es lo mismo:
signal.warn + threat
commit.delete + loss
que:
commit.delete + loss
signal.warn + threat
En el primer caso, la interfaz advierte antes de la pérdida. En el segundo, advierte después de que ya no hay nada que evitar.
El orden cambia el sentido.
8. Tiempo e intent
------------------
El intent también modula el tiempo.
Affirm suele ser breve, suave, de baja activación. Fulfill puede durar algo más porque marca resolución de una tensión. Risk necesita persistir lo suficiente para que el usuario lo procese. Threat debe entrar rápido y con alta saliencia. Loss puede ser breve, grave y dejar huella.
La posición de un intent en el espacio valencia/activación tiene consecuencias temporales. Un threat, por su alta activación, debe entrar rápido y con suficiente saliencia. Un loss, aunque negativo, no necesita la misma urgencia, porque registra una consecuencia ya consumada.
9. Accesibilidad temporal
-------------------------
El tiempo también es accesibilidad.
No todos los usuarios procesan los cambios a la misma velocidad. No todos ven una señal efímera. No todos pueden actuar antes de un timeout. No todos interpretan una animación rápida.
La accesibilidad temporal incluye duración suficiente de mensajes importantes, control sobre pausas y timeouts, evitar desapariciones críticas, no depender de instantes efímeros y mantener estados importantes después del evento.
Principio:
PRINCIPIO
Si un evento importante solo existe durante un instante, muchos usuarios no lo recibirán.
10. Síntesis
------------
El tiempo atraviesa todos los canales.
Define si una respuesta se siente causada por la acción del usuario o como evento separado. Define si una espera parece proceso o bloqueo. Define si una señal se percibe o se pierde. Define si una culminación cierra una tensión o pasa desapercibida.
La tesis:
PRINCIPIO
El tiempo no acompaña al evento. El tiempo forma parte de su significado.

## CAPÍTULO 13
MOTION: LA FÍSICA PERCIBIDA DEL EVENTO
Movimiento, causalidad, continuidad y energía
Animación es la técnica.
Motion es la percepción del cambio en movimiento.
Una animación puede ser una transición CSS, un transform, un keyframe, un spring, un fade, un slide, un scale, un spinner o una interpolación entre estados. Pero motion, en este libro, no es la propiedad técnica que cambia. Es lo que el usuario percibe cuando algo se desplaza, se comprime, se eleva, se asienta, se resiste, tiembla, colapsa o entra en el campo.
Motion comunica causalidad, continuidad, energía, masa, dirección y régimen.
1. Fundamento psicoperceptivo: movimiento, causalidad y continuidad
-------------------------------------------------------------------
Motion se apoya en mecanismos básicos de percepción del movimiento.
Uno de los fundamentos más relevantes para interfaces es la percepción de causalidad. Los estudios clásicos de Michotte mostraron que ciertas secuencias simples de movimiento se perciben directamente como relaciones causales: un objeto se mueve hacia otro, lo toca, y el segundo empieza a moverse. El observador no percibe simplemente dos desplazamientos sucesivos, sino una relación de causa.
En interfaz ocurre algo parecido, aunque a otra escala. Cuando el usuario pulsa un botón y el botón se comprime inmediatamente, la respuesta se interpreta como consecuencia del gesto. Si la respuesta llega tarde o con una forma no relacionada, esa atribución se debilita.
Motion también sostiene la continuidad de objeto. Cuando un elemento cambia de posición, se expande o se desplaza hacia otro lugar, el movimiento permite al usuario percibir que sigue siendo el mismo objeto en otra condición. Sin movimiento, el cambio puede sentirse como desaparición de una cosa y aparición de otra.
Otro fundamento importante es la predicción sensorimotora. Cuando algo empieza a moverse, el usuario genera expectativas sobre su trayectoria, velocidad y destino. Si el movimiento se corta, salta o contradice la física implícita que sugiere, aparece una sensación de extrañeza.
Finalmente, el movimiento comunica energía y masa mediante claves temporales: velocidad, aceleración, desaceleración, rebote, rigidez, fricción, overshoot o colapso. La interfaz no tiene peso real, pero motion puede producir una lectura de peso, ligereza, resistencia o pérdida de energía.
Estos fundamentos no dictan una curva universal. Pero sí justifican la tesis central:
DISTINCIÓN
Motion no es decoración; es una forma de comunicar cómo ocurre un cambio.
2. Causalidad
-------------
La primera función de motion es preservar causalidad.
Cuando el usuario pulsa un botón y el botón se comprime de inmediato, la interfaz comunica:
PRINCIPIO
mi acción produjo una respuesta.
Esa relación es la base de contact.
3. Continuidad
--------------
Motion permite que el usuario perciba que algo sigue siendo lo mismo a través del cambio.
Una tarjeta que se desplaza hasta otra posición sigue siendo la misma tarjeta. Un panel que se expande desde su encabezado sigue perteneciendo a ese origen. Un indicador activo que se desliza de una pestaña a otra conserva continuidad de navegación. Un objeto arrastrado mantiene identidad durante el gesto.
Sin continuidad, el usuario debe reconstruir el cambio con memoria y razonamiento.
4. Energía, masa y activación
-----------------------------
Motion comunica energía.
Un movimiento rápido y seco puede comunicar urgencia. Un movimiento suave puede comunicar calma. Un rebote puede comunicar elasticidad o celebración. Un colapso puede comunicar pérdida de energía. Un shake puede comunicar discrepancia o alerta. Un asentamiento puede comunicar cierre.
La energía del movimiento puede reforzar la activación del evento. Un threat, situado en una región de alta activación negativa, puede admitir entradas más rápidas, tensas o salientes. Un risk necesita una tensión más moderada. Un affirm debe ser suave y breve. Un fulfill puede tener más resolución. Un loss puede usar descenso, contracción o retirada grave, no la energía urgente de una amenaza activa.
5. Dirección
------------
Motion comunica de dónde viene algo y hacia dónde va.
Un dropdown que emerge desde su trigger se entiende como dependiente de ese control. Un modal que aparece centrado comunica un marco dominante. Un panel que entra desde un borde comunica procedencia lateral. Una tarjeta que colapsa hacia una zona de descarte comunica retirada o pérdida.
La dirección no es decorativa. Es orientación.
6. Motion y familias
--------------------
Contact usa motion para causalidad inmediata.
Commit usa motion para asentamiento y cierre.
Signal usa motion para llamar atención.
Handle usa motion para control continuo.
Emerge usa motion para aparición y retirada.
Shift usa motion para cambio de contexto.
Sustain usa motion para continuidad.
7. Motion y accesibilidad
-------------------------
Motion es poderoso, pero delicado.
Puede ayudar a entender causalidad y continuidad. También puede producir mareo, distracción, fatiga o malestar vestibular.
Reducir motion no debe significar eliminar semántica. Si motion transportaba contacto, debe migrar a estado visual, sonido opcional o háptica. Si transportaba continuidad, debe migrar a texto o estado. Si transportaba cambio de contexto, debe migrar a foco, título, estructura y landmarks.
Principio:
PRINCIPIO
Reducir motion no significa eliminar el tiempo ni el significado. Significa expresarlos sin movimiento problemático.
8. Síntesis
-----------
Motion es la física percibida del evento.
No pregunta “cómo animar esto”.
Pregunta “qué clase de cambio necesita percibir el usuario”.

## CAPÍTULO 14
Presencia y profundidad
Lo que está, lo que aparece y lo que ocupa un plano
A veces lo decisivo no es que algo se mueva.
A veces lo decisivo es que algo aparece.
Un tooltip entra en el campo.
Un dropdown se abre bajo un botón.
Un panel lateral se despliega.
Un modal se impone sobre la página.
Una tarjeta desaparece de una lista.
Una barra de undo aparece después de eliminar.
Un objeto arrastrado se eleva sobre el layout.
En todos esos casos, la interfaz no solo muestra o esconde elementos. Reorganiza la presencia y la profundidad del campo perceptivo.
La presencia responde:
PRINCIPIO
¿esto está aquí, aparece, permanece o se retira?
La profundidad responde:
PRINCIPIO
¿en qué plano ocurre y qué prioridad tiene?
Ambos canales son esenciales para entender emerge, shift, handle, signal y commit.delete + loss.
1. Presencia no es existencia técnica
Un elemento puede existir técnicamente y no estar presente para el usuario.
Puede estar en el DOM, pero oculto.
Puede estar fuera del viewport.
Puede estar colapsado.
Puede estar subordinado.
Puede estar inaccesible por foco.
Puede existir como estado interno, pero no como experiencia.
Y al revés: algo puede ser técnicamente transitorio y tener una presencia perceptiva muy fuerte, como un modal, una alerta o un toast.
Por eso, en este libro, presencia no significa existencia técnica.
Significa existencia perceptiva.
La pregunta no es:
¿está renderizado?
sino:
¿forma parte del campo perceptivo del usuario?
2. Fundamento psicoperceptivo: figura/fondo, plano y claves de profundidad
Presencia y profundidad se apoyan en la forma en que la percepción organiza el campo visual.
La psicología Gestalt mostró que no percibimos elementos aislados, sino relaciones: agrupación, continuidad, figura/fondo, cierre, proximidad, semejanza y destino común. Esto es fundamental para entender por qué un modal, un tooltip o un dropdown no son solo rectángulos que aparecen en pantalla. Cada uno reorganiza el campo de una manera distinta.
La distinción figura/fondo es especialmente importante. Cuando un modal aparece sobre una página, el contenido anterior no desaparece necesariamente, pero pasa a funcionar como fondo subordinado. El modal se convierte en figura operativa.
La profundidad se construye mediante claves perceptivas como oclusión, sombra, escala relativa, desenfoque, superposición y tratamiento del fondo. La pantalla es plana, pero esas claves permiten leer relaciones como:
esto está delante
esto queda detrás
esto flota
esto depende de aquello
esto domina el marco actual
Por eso shift.enter-mode no se comunica solo porque aparece un modal, sino porque cambia la relación de planos. En handle.pick, la profundidad comunica otro cambio: el objeto pasa del layout al régimen de manipulación. En emerge, la presencia permite leer aparición o retirada. En loss, la ausencia misma puede comunicar que algo dejó de estar disponible.
3. Emerge, shift y signal: tres formas de aparecer
No todo lo que aparece pertenece a la misma familia.
Un tooltip aparece.
Un dropdown aparece.
Un modal aparece.
Un toast aparece.
Un error inline aparece.
Pero no son el mismo evento.
TOOLTIP
emerge.present
Aparece información auxiliar.
No cambia el marco.
No reclama atención urgente.
Debe estar anclado al elemento que explica.
DROPDOWN
emerge.open
Aparecen opciones locales.
La superficie depende de un trigger.
El fondo sigue activo.
No hay cambio de régimen operativo completo.
MODAL
shift.enter-mode
Aparece una superficie, sí, pero su función principal no es aparecer.
Su función es cambiar el contexto: subordina el fondo, captura foco y exige una acción dentro de un nuevo régimen.
TOAST
signal.notify + neutral
Aparece un mensaje iniciado por el sistema.
La presencia sirve a la señal.
ERROR INLINE
signal.warn + risk
Aparece junto a un campo, pero su función no es solo presencia. Reclama atención sobre un problema corregible.
La pregunta clave es:
PRINCIPIO
¿algo apareció o el sistema está reclamando atención? ¿algo apareció o cambió el contexto?
Figura 14.1
4. Profundidad no significa importancia
Un error frecuente es asumir que todo lo que está “más arriba” es más importante.
No necesariamente.
Un dropdown puede flotar sin ser importante.
Un tooltip puede estar por encima sin ser urgente.
Un objeto arrastrado puede elevarse porque está bajo control, no porque sea crítico.
Un modal puede estar delante porque cambia el marco, no porque su contenido sea necesariamente peligroso.
La profundidad comunica plano, relación y régimen operativo. La importancia afectiva depende del evento evaluable.
Por eso:
shift.enter-mode
signal.warn + threat
es más preciso que:
shift.enter-mode + threat
El modal cambia el plano.
La advertencia porta la amenaza.
Caja de principio
DISTINCIÓN
Más profundidad no significa más peligro. Significa otro plano operativo.
5. Desaparecer no significa perder
La desaparición visual es ambigua.
Una tarjeta puede desaparecer porque:
- se cerró;
- se ocultó;
- se filtró;
- se colapsó;
- se descartó;
- se eliminó;
- se perdió.
Si la interfaz no distingue esas diferencias, el usuario debe adivinarlas.
emerge.close
significa:
PRINCIPIO
se cerró una superficie.
emerge.hide
significa:
DISTINCIÓN
sigue existiendo, pero no está visible.
emerge.collapse
significa:
PRINCIPIO
el contenido volvió a estar contenido.
commit.delete + loss
significa:
PRINCIPIO
dejó de estar disponible.
La presencia debe hacer legible si algo se retira de la vista o si realmente deja de existir operativamente.
Figura 14.2
Cuatro tarjetas con la misma silueta que se retira:
Cerrar
emerge.close
“se retiró la superficie”
Ocultar
emerge.hide
“sigue existiendo”
Colapsar
emerge.collapse
“vuelve al contenedor”
Eliminar
commit.delete + loss
“dejó de estar disponible”
PRINCIPIO
La desaparición visual es ambigua. La semántica debe distinguir retirada, ocultación, colapso y pérdida.
6. Ejemplo narrativo: tarjeta eliminada con undo
Un usuario elimina una tarjeta de una lista.
Una solución pobre:
la tarjeta hace fade out
Problema: el usuario puede no saber si se ocultó, se filtró, se movió o se eliminó.
Una solución semántica:
signal.warn + threat
commit.delete + loss
emerge.present undo
signal.announce + neutral
Primero, si la acción es destructiva, puede haber una advertencia.
Después, al confirmar, la tarjeta se retira como consecuencia:
commit.delete + loss
Pero la interfaz no debería limitarse a hacerla desaparecer. Debe dejar huella:
emerge.present undo
La barra de undo no es la pérdida. La pérdida ya ocurrió en el commit. La barra emerge como posibilidad temporal de reparación.
Canales:
- presencia: la tarjeta deja de estar;
- motion: retirada o colapso;
- forma: barra de undo;
- texto: “Tarjeta eliminada”;
- tiempo: undo persistente lo suficiente;
- color: refuerzo sobrio;
- accesibilidad: anuncio si procede.
Lectura:
PRINCIPIO
esto se eliminó, pero todavía puedes deshacerlo.
7. Ejemplo narrativo: command palette
Una command palette aparece sobre la interfaz.
Podría parecer un caso de emerge, porque “aparece algo”. Pero semánticamente es más fuerte.
La command palette cambia el régimen operativo:
- captura foco;
- convierte el teclado en canal principal;
- permite ejecutar acciones globales;
- subordina el fondo;
- introduce un modo temporal.
Por tanto:
shift.enter-mode
No:
emerge.open
Aunque la superficie aparezca, su función principal no es presencia local. Es cambio de contexto.
Canales:
- profundidad: superficie dominante;
- presencia: entrada clara;
- foco: input activo;
- forma: shell reconocible;
- motion: entrada rápida;
- accesibilidad: gestión de foco, escape, retorno.
Lectura:
PRINCIPIO
ahora estás operando sobre el sistema entero desde otro modo.
8. Accesibilidad de presencia y profundidad
Presencia y profundidad pueden ser claras visualmente y opacas para otros modos de interacción.
Un modal visualmente evidente puede fallar si no gestiona foco.
Un fondo oscurecido puede parecer subordinado, pero seguir activo para teclado.
Un toast puede aparecer visualmente, pero no ser anunciado.
Un dropdown puede flotar, pero no estar relacionado con su trigger.
Un cambio de vista puede ser visible, pero no mover foco ni actualizar título.
La accesibilidad exige coherencia entre:
plano visual
foco
árbol accesible
orden de lectura
estado operativo
Si algo emerge visualmente, también debe emerger operativamente.
Si un fondo queda subordinado visualmente, también debe quedar subordinado en la interacción.
9. Antipatrones
10. Síntesis
Presencia y profundidad comunican existencia perceptiva, plano y régimen.
Presencia pregunta:
PRINCIPIO
¿esto está, aparece, permanece o se retira?
Profundidad pregunta:
PRINCIPIO
¿en qué plano ocurre y qué prioridad tiene?
La tesis del capítulo:
PRINCIPIO
La interfaz no solo muestra elementos. Hace entrar, salir, elevarse, subordinarse y desaparecer partes del contexto operativo.
Reglas centrales:
Aparecer no es advertir.
Aparecer no es cambiar de marco.
Flotar no significa ser importante.
Desaparecer no significa perder.
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>SUPERFICIE
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>FAMILIA DOMINANTE
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>LECTURA
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Tooltip
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>`emerge.present`
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>aparece ayuda auxiliar
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Dropdown
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>`emerge.open`
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>aparecen opciones locales
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Modal
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>`shift.enter-mode`
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>cambia el contexto
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Toast
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>`signal.notify`
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>el sistema comunica algo
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Error inline
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>`signal.warn + risk`
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>hay un problema corregible
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>ANTIPATÓN
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>QUÉ FALLA
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>CORRECCIÓN
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Dropdown como modal
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>profundidad excesiva
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>mantener anclaje local
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Modal como popover
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>marco insuficiente
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>subordinar fondo y foco
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Todo lo que aparece parece alerta
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>exceso de saliencia
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>separar `emerge` de `signal`
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Desaparición ambigua
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>no se sabe si se ocultó o perdió
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>distinguir `hide` / `delete + loss`
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Fondo visualmente bloqueado pero activo
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>incoherencia
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>gestionar foco e interacción
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Toast efímero importante
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>pérdida de información
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>persistencia / historial

## CAPÍTULO 15
Forma: límite, affordance e iconografía
Lo que se reconoce antes de colorearse, moverse o sonar
Antes de que una interfaz use color, motion, sonido o háptica, ya está diciendo algo mediante la forma.
Un botón parece pulsable antes de estar coloreado.
Un campo parece editable antes de mostrar validación.
Un icono sugiere una acción antes de recibir un tooltip.
Un borde separa una región antes de que haya profundidad.
Una tarjeta agrupa contenido antes de que se eleve.
Un contorno de foco indica disponibilidad antes de cualquier sonido.
La forma es uno de los canales más discretos de la interfaz, pero también uno de los más persistentes.
No aparece solo cuando ocurre un evento. Está ahí continuamente, estructurando lo que puede tocarse, leerse, separarse, agruparse o reconocerse.
La forma responde a preguntas como:
¿esto es accionable?
¿esto está separado?
¿esto pertenece a este grupo?
¿esto es editable?
¿esto está activo?
¿esto está enfocado?
¿esto representa una acción conocida?
1. Fundamento psicoperceptivo: Gestalt, contorno y affordance
La forma se apoya en dos familias de fundamentos: organización perceptiva y percepción de acción posible.
Desde la organización perceptiva, la Gestalt mostró que el sistema perceptivo tiende a agrupar y separar elementos según proximidad, semejanza, continuidad, cierre, región común y figura/fondo. Un borde puede convertir varios elementos en una región común. Una forma repetida puede indicar pertenencia. Una discontinuidad puede marcar separación. Un contorno cerrado puede hacer que algo se perciba como unidad.
Desde la teoría de affordances, especialmente en Gibson, la forma también sugiere posibilidades de acción. Una superficie con relieve, borde, tamaño táctil y posición estable puede sugerir presión. Un asa visible puede sugerir arrastre. Un campo rectangular con cursor puede sugerir escritura. Un chevron puede sugerir expansión. Un icono de papelera puede sugerir eliminación.
La iconografía añade una capa más: condensa acciones o estados en siluetas aprendidas. Pero los iconos no son universales. Funcionan cuando el sistema cultural, el contexto y la redundancia los sostienen.
Por eso una X puede ser cerrar, cancelar, borrar o eliminar. Un check puede ser seleccionar, confirmar o completar. Un triángulo puede ser play, expansión o advertencia. Un punto rojo puede indicar nuevo, grabando, error o alerta.
La forma no es solo lo que algo parece. Es parte de lo que el sistema ofrece hacer.
2. Forma como límite
Una de las funciones principales de la forma es establecer límite.
Un límite permite saber:
esto es una unidad
esto pertenece aquí
esto no pertenece allí
esto puede manipularse como objeto
esto es una región de acción
Sin límites, la interfaz se vuelve ambigua.
Un bloque de contenido sin borde, sombra, fondo o separación puede no parecer una tarjeta.
Un grupo de botones sin región común puede parecer una lista de acciones inconexas.
Un área de drop sin contorno puede no parecer destino.
Un campo sin forma puede no parecer editable.
Una alerta sin contenedor puede confundirse con texto ordinario.
El límite puede expresarse con borde, fondo, espacio, radio, sombra, contorno, región común o alineación.
No siempre hace falta una línea. A veces el espacio basta. A veces el fondo basta. Pero cuando la estructura lo requiere, debe haber una señal de pertenencia y separación.
3. Forma como affordance
Una forma puede invitar o bloquear acción.
Un botón bien formado no necesita explicar demasiado que puede pulsarse.
Un slider bien formado no necesita decir que puede arrastrarse.
Un input bien formado no necesita tutorial para indicar escritura.
Un chip bien formado sugiere selección, filtro o etiqueta.
Un handle visible sugiere que algo puede moverse.
La forma participa en las familias semánticas antes de que el evento ocurra.
FORMA EN `CONTACT`
Un control debe parecer activable antes de recibir contacto.
button
icon button
toolbar item
card clickable
Si su forma no sugiere acción, el usuario primero debe adivinar que puede actuar.
FORMA EN `COMMIT`
Una opción seleccionable debe distinguirse de texto ordinario.
checkbox
radio
switch
chip
toggle
La forma ayuda a decir:
PRINCIPIO
esto puede quedar elegido.
FORMA EN `SIGNAL`
Una señal necesita forma reconocible para no confundirse con contenido ordinario.
banner
badge
callout
inline error
toast
La forma marca que eso debe leerse como comunicación del sistema.
FORMA EN `HANDLE`
La manipulación necesita affordances explícitas:
drag handle
grip dots
drop zone
resize corner
Si no hay forma que sugiera agarre, la manipulación depende de descubrimiento accidental.
FORMA EN `EMERGE`
Un trigger debe sugerir que puede abrir algo:
chevron
caret
plus
disclosure shape
La forma anticipa el evento de aparición.
FORMA EN `SUSTAIN`
Un proceso necesita una forma que represente continuidad:
bar
circle
skeleton
track
timeline
La forma hace visible el tipo de espera.
Figura 15.1
Crear una matriz visual:
contact → botón / superficie
commit → check / toggle / selected pill
signal → callout / badge / alert
handle → grip / drop zone
emerge → chevron / disclosure
shift → modal shell / stepper
sustain → progress bar / skeleton
PRINCIPIO
La forma puede anticipar, sostener o fijar la lectura semántica de un evento.
4. Forma y estado
La forma también comunica estado.
No solo mediante color. Muchas veces el estado debe poder reconocerse por forma, contorno, icono, densidad, posición o marca.
Ejemplos:
seleccionado
enfocado
desactivado
expandido
colapsado
inválido
editable
arrastrable
bloqueado
Si el estado solo cambia de color, la semántica es frágil.
Una opción seleccionada puede necesitar check, borde, fondo, marca persistente o cambio de peso.
Un campo inválido puede necesitar icono, mensaje, borde y relación espacial.
Un accordion expandido puede necesitar cambio de chevron, contorno y relación con el contenido desplegado.
La forma permite que el estado sobreviva cuando el color no basta o cuando motion se reduce.
5. Forma e intent
La forma no es intent, pero puede reforzarlo.
Un risk puede usar forma de advertencia moderada: icono, callout, borde, contenedor local.
Un threat puede usar forma más contundente: bloque dominante, icono claro, agrupación crítica.
Un loss puede usar formas de ausencia o registro: espacio vacío, estado tachado, undo, recurso retirado.
Un affirm puede usar forma pequeña y estable: check discreto, marca de guardado, estado aplicado.
Un fulfill puede usar forma más resolutiva: check grande, pantalla de completado, progreso al 100%.
Esto es importante porque los intents no deben depender solo del color.
6. Ejemplo narrativo: campo inválido
Un usuario deja vacío un campo obligatorio.
Evento:
signal.warn + risk
Una solución pobre:
border-color: red;
El color cambia, pero el evento depende casi por completo del color.
Una solución semántica:
- borde o contorno;
- icono de advertencia;
- mensaje vinculado;
- forma de callout local;
- relación espacial clara;
- persistencia hasta corrección;
- aria-describedby;
- no solo rojo.
La forma ayuda a responder:
¿dónde está el problema?
¿qué campo afecta?
¿es corregible?
¿qué debo hacer?
El error no debería sentirse como amenaza global si solo es un riesgo local corregible.
7. Ejemplo narrativo: selección de filtro
Un usuario selecciona un filtro en una lista de chips.
Evento:
commit.select + affirm
Si solo cambia el color del chip, puede entenderse, pero depende demasiado del canal cromático.
La forma puede reforzar el estado:
- check interno;
- borde más definido;
- fondo persistente;
- cambio de peso;
- botón de remove;
- posición dentro de un grupo activo.
La pregunta perceptiva es:
PRINCIPIO
¿esto quedó elegido?
La forma debe dejar huella.
Un contacto se siente y desaparece. Una selección debe permanecer.
8. Ejemplo narrativo: área de drop
Un usuario arrastra un archivo a una zona de subida.
Antes de que el archivo entre, la zona debe sugerir que acepta drop.
Eso es forma como affordance.
Recursos posibles:
- contorno discontinuo;
- icono de upload;
- texto breve;
- tamaño suficiente;
- fondo suave;
- cambio de forma al hover;
- estado válido / inválido.
Secuencia:
handle.carry
signal/affordance de destino
handle.drop
commit.upload + affirm/fulfill
Si la zona no tiene forma suficiente, el usuario no sabe dónde soltar.
Si solo se colorea al pasar por encima, quizá llega tarde.
La forma debe anticipar la posibilidad de acción.
9. Accesibilidad de la forma
La forma es crucial para accesibilidad.
Si todo depende de color, la forma debe sostener el significado.
Si una animación se reduce, la forma puede dejar estado persistente.
Si el sonido no está disponible, la forma puede reforzar señal.
Si el usuario usa teclado, el foco debe tener forma clara.
Problemas frecuentes:
- foco invisible;
- iconos sin texto;
- áreas clicables sin forma clara;
- contornos demasiado sutiles;
- targets demasiado pequeños;
- drop zones no accesibles por teclado;
- botones que parecen texto;
- texto que parece botón.
La accesibilidad de la forma no es solo contraste. Es reconocimiento de función.
10. Síntesis
La forma es el canal del límite, la affordance y el reconocimiento estructural.
Comunica:
dónde empieza y termina algo
qué pertenece junto
qué puede hacerse
qué estado tiene
qué acción representa
La tesis:
PRINCIPIO
La forma no dice solo cómo se ve algo. Dice qué es, dónde termina y qué permite hacer.

## CAPÍTULO 16
COLOR: REFUERZO SEMÁNTICO Y VALENCIA
El canal que más hemos confundido con la semántica
El color es uno de los canales más poderosos de la interfaz.
También es uno de los más peligrosos.
Durante décadas, buena parte de la semántica visual se ha delegado en el color: rojo para error, amarillo para advertencia, verde para éxito, azul para información.
Pero el color no es la semántica.
Es un canal que puede reforzarla.
1. Fundamento psicoperceptivo: saliencia, contraste y codificación
------------------------------------------------------------------
El color se apoya en varios mecanismos perceptivos.
El primero es la saliencia. Un color que contrasta con su entorno puede llamar la atención antes de que el usuario lea el contenido.
El segundo es el contraste. El color no se percibe de forma aislada, sino en relación con fondo, luminancia, saturación y contexto.
El tercero es la codificación aprendida. Rojo como peligro, verde como positivo, amarillo como precaución y azul como información funcionan porque los usuarios los han visto muchas veces, no porque formen por sí solos una teoría completa del afecto.
El cuarto es la variabilidad perceptiva. No todos los usuarios distinguen los mismos colores, ni en las mismas condiciones.
Por eso el color es fuerte, pero incompleto.
2. Color e intent
-----------------
El color no define el intent. El intent proviene de la evaluación del evento en el espacio valencia/activación; el color es solo uno de los canales que puede reforzarlo.
Rojo, amarillo, verde o azul no son la semántica. Son recursos expresivos que pueden ayudar a comunicar amenaza, riesgo, confirmación, resolución, pérdida o neutralidad.
La diferencia entre threat y loss no nace de dos tonos de rojo. Nace de una diferencia evaluativa: en threat todavía hay algo que evitar; en loss la consecuencia ya ocurrió.
La diferencia entre affirm y fulfill no nace de dos verdes. Nace de una diferencia entre confirmación suave y resolución positiva. El color puede reforzar esa diferencia, pero no debe sustituirla.
3. La herencia del semáforo
---------------------------
El capítulo 10 desarrolló la crítica al semáforo. Aquí solo aplicamos su consecuencia al canal color.
La convención heredada funciona como atajo cromático, pero no como teoría semántica completa.
Danger mezcla threat y loss. Success mezcla affirm y fulfill. Info mezcla saliencia con evaluación.
El color debe quedar subordinado al evento, no al revés.
4. Accesibilidad cromática
--------------------------
El color no debe ser el único medio para comunicar información crítica.
Error solo en rojo. Link solo por color. Selección solo por fondo verde. Gráfica solo por colores. Validación solo por verde/rojo.
Todo eso es frágil.
El color debe trabajar con forma, icono, texto, posición, patrón, estado persistente y contraste suficiente.
5. Síntesis
-----------
El color orienta atención, refuerza estado, modula valencia y construye identidad visual.
Pero cuando trabaja solo, la semántica queda expuesta.
PRINCIPIO
El color expresa el intent. No lo define.

## CAPÍTULO 17
Sonido: urgencia, valencia y microeventos auditivos
Cuando la interfaz también se oye
La web ha tratado el sonido con desconfianza durante mucho tiempo.
No sin razón.
Durante años, el sonido en interfaces web estuvo asociado a malas prácticas: música automática, anuncios intrusivos, notificaciones insistentes, páginas que sonaban sin permiso, efectos gratuitos y experiencias imposibles de usar en oficinas, bibliotecas, transporte público o espacios compartidos.
La consecuencia cultural fue clara:
PRINCIPIO
mejor que la interfaz no suene.
Esa reacción era comprensible. Pero también produjo una simplificación peligrosa: confundir el mal uso del sonido con la inutilidad del sonido.
El problema histórico no ha sido el sonido en sí.
Ha sido el sonido sin gramática.
Un sonido arbitrario molesta.
Un sonido demasiado largo invade.
Un sonido inesperado sobresalta.
Un sonido repetido fatiga.
Un sonido sin relación clara con el evento parece decoración o ruido.
Pero un sonido breve, proporcionado, sincronizado con el evento y opcional para el usuario puede comunicar cosas que otros canales comunican peor.
1. Fundamento psicoperceptivo: correspondencias, roughness e integración audiovisual
El sonido se apoya en varios fenómenos perceptivos relevantes para la interfaz.
El primero son las correspondencias crossmodales. Charles Spence ha revisado un amplio cuerpo de investigaciones que muestra que las personas tienden a asociar ciertos rasgos auditivos con rasgos visuales o espaciales: pitch alto con objetos más pequeños, brillantes o elevados; pitch bajo con objetos más grandes, oscuros o pesados.
Estas correspondencias no deben leerse como reglas universales cerradas, pero sí como orientaciones útiles para diseñar congruencia entre canales.
Para interfaz, esto significa que el sonido puede reforzar cualidades que también comunica motion o profundidad:
tono más agudo → ligereza, pequeñez, puntualidad
tono más grave → peso, gravedad, cierre
ascenso tonal → apertura, logro, resolución
descenso tonal → cierre, caída, pérdida
timbre limpio → claridad, confirmación, baja tensión
timbre áspero → urgencia, alarma, tensión
El segundo fundamento es la roughness o aspereza acústica. Ciertos timbres ásperos o modulados tienden a aumentar la saliencia y la sensación de alarma. Esto no significa que toda alerta de interfaz deba sonar como alarma. Significa lo contrario: la aspereza acústica tiene tanta carga atencional que debe reservarse para eventos donde esa carga esté justificada.
El tercer fundamento es la integración audiovisual. Cuando un sonido ocurre en sincronía con un movimiento, una aparición o una vibración, el usuario puede percibirlos como un único evento. Si el sonido llega tarde, demasiado pronto o con una cualidad incongruente, se separa de la experiencia y se convierte en ruido añadido.
El cuarto fundamento conecta con el sistema de intents. Las variaciones en pitch, timbre, ataque y duración pueden modular la activación y la valencia percibida del evento. Un fulfill puede admitir un sonido más ascendente o resolutivo. Un risk puede usar un sonido contenido y seco. Un threat puede justificar mayor saliencia. Un loss puede usar descenso, gravedad o decaimiento, no alarma sostenida.
Un sonido no es “amenazante” por una frecuencia aislada. Lo es por la relación entre pitch, timbre, ataque, duración, contexto, volumen, repetición y evento.
2. Qué comunica el sonido
El sonido puede comunicar:
- contacto;
- cierre;
- urgencia;
- valencia;
- presencia fuera de foco;
- materialidad;
- pérdida;
- resolución.
Su fuerza está en que no exige que el usuario mire el lugar donde ocurre el evento.
Una señal visual puede pasar desapercibida si el usuario mira otra zona. Un sonido breve puede alcanzar al usuario aunque su atención visual esté en otro lugar.
Eso no significa que deba usarse para todo.
Significa que, cuando un evento necesita atravesar el campo atencional, el sonido puede ser un canal muy eficaz.
3. Sonido y familias semánticas
CONTACT
contact.press
Un microclick breve puede reforzar que el sistema recibió la acción.
Pero no todos los contactos deben sonar. En interfaces de alta frecuencia, sonorizar cada press se vuelve insoportable.
El sonido de contact debe ser breve, limpio, opcional y fácil de desactivar.
COMMIT
commit.save + affirm
commit.complete + fulfill
commit.delete + loss
El sonido puede marcar cierre o resultado.
affirm puede ser casi imperceptible.
fulfill puede ser más resolutivo.
loss puede ser más grave o descendente.
SIGNAL
signal.notify + neutral
signal.warn + risk
signal.alert + threat
El sonido es especialmente potente en signal, porque puede alcanzar al usuario fuera del foco visual.
Pero también es donde más riesgo hay de invadir.
Una notificación informativa no debería sonar como alarma. Una amenaza crítica sí puede justificar un sonido más saliente.
HANDLE
El sonido puede reforzar pick y drop, no tanto carry.
handle.pick
handle.drop
El carry suele ser silencioso porque es una fase de control continuo. Sonorizar el arrastre completo fatiga.
EMERGE
Normalmente no necesita sonido.
Un tooltip, dropdown o popover no debería sonar salvo que contenga una señal evaluable.
SHIFT
El cambio de contexto puede tener sonido en casos específicos, pero normalmente profundidad, foco y motion bastan.
SUSTAIN
El sonido sostenido es peligroso.
Un proceso en curso no debería emitir un loop audible salvo en contextos muy particulares. El sonido puede marcar inicio o fin, pero rara vez debe acompañar toda la espera.
4. Sonido e intent
El sonido puede modular intent con mucha precisión.
neutral → silencio o sonido mínimo
affirm → breve, limpio, suave
fulfill → ascendente, resolutivo
risk → seco, moderado, contenido
threat → saliente, áspero, ataque claro
loss → grave, descendente, seco
La diferencia entre threat y loss es crucial.
Un sonido de amenaza prepara para actuar.
Un sonido de pérdida registra que algo ya ocurrió.
No deben sonar igual.
5. Ejemplo narrativo: autoguardado
Un editor guarda cambios automáticamente.
Evento:
commit.save + affirm
¿Debe sonar?
Depende.
Si el autoguardado ocurre cada pocos segundos, probablemente no. Sería fatigante.
Si ocurre al final de una edición importante, puede haber una confirmación discreta.
Una solución semántica:
- texto “guardado”;
- marca visual breve;
- color positivo discreto;
- sin sonido por defecto;
- sonido opcional si el usuario lo activa.
El intent es affirm, no fulfill.
No hay tensión fuerte que celebrar. Solo normalidad confirmada.
6. Ejemplo narrativo: subida completada
Un usuario sube un archivo grande.
Secuencia:
contact.press
sustain.progress
commit.complete + fulfill
Aquí el sonido puede tener sentido.
Durante sustain, silencio.
Al completar, un sonido breve y resolutivo puede marcar cierre.
El sonido no comunica que el proceso estaba vivo. Eso lo hacía el progreso visual.
El sonido comunica:
PRINCIPIO
ya terminó.
Esto es especialmente útil si el usuario dejó de mirar la barra de progreso.
7. Ejemplo narrativo: alerta crítica
Una sesión está a punto de expirar.
Evento:
signal.alert + threat
Aquí el sonido puede ser apropiado porque:
- el usuario puede no estar mirando;
- hay urgencia;
- todavía puede actuar;
- el evento exige atención.
Pero debe tener límites:
- no sonar indefinidamente;
- no ser exageradamente estridente;
- permitir silencio;
- tener equivalente visual persistente;
- no repetirse sin control.
La alerta sonora debería decir:
PRINCIPIO
atiende ahora.
No:
PRINCIPIO
entra en pánico.
8. Ejemplo narrativo: eliminación
El usuario elimina una tarjeta.
Antes de confirmar:
signal.warn + threat
Puede haber sonido si el evento es grave y requiere atención.
Después de confirmar:
commit.delete + loss
Si hay sonido, debería ser distinto.
threat puede tener más ataque y saliencia.
loss puede ser más seco, grave, descendente o apagado.
El sonido de pérdida no debe sonar como alarma activa, porque ya no hay nada que evitar. Debe registrar consecuencia.
Caja de principio
PRINCIPIO
El sonido de amenaza prepara para actuar. El sonido de pérdida registra que algo ya ocurrió.
9. Sonido y web
En la web, el sonido necesita una doble justificación:
1. perceptiva;
2. social.
Técnicamente puede producirse audio con Web Audio API. Pero hay restricciones reales:
- políticas de autoplay;
- necesidad de gesto del usuario;
- variación entre navegadores;
- dispositivos silenciados;
- entornos compartidos;
- rechazo cultural al audio web.
Por eso en web el sonido debe ser:
- desactivable;
- bajo control del usuario;
- no crítico como única vía;
- breve;
- vinculado a eventos claros;
- probablemente iniciado tras interacción;
- respetuoso con contexto.
10. Accesibilidad sonora
El sonido nunca debe ser el único canal de información crítica.
Usuarios sordos o con hipoacusia pueden no percibirlo.
Usuarios con sonido desactivado no lo recibirán.
Usuarios en entornos ruidosos pueden perderlo.
Usuarios con sensibilidad auditiva pueden rechazarlo.
Por tanto:
- una alerta sonora debe tener equivalente visual;
- una confirmación sonora debe tener estado visible;
- una pérdida sonora debe dejar huella;
- una notificación sonora debe tener texto;
- el usuario debe poder reducir o desactivar sonido.
11. Antipatrones
12. Síntesis
El sonido es uno de los canales más peligrosos y más potentes.
Comunica contacto, cierre, urgencia, valencia, pérdida, materialidad y eventos fuera del foco visual.
Su regla central:
PRINCIPIO
Si un sonido no ayuda a reconocer qué ocurrió, cuándo ocurrió o cómo debe evaluarse, probablemente sobra.
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>ANTIPATÓN
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>PROBLEMA
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>CORRECCIÓN
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>sonido decorativo
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>ruido
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>vincular a evento
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>sonido largo
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>invasión
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>microsonidos
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>alerta solo sonora
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>inaccesibilidad
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>respaldo visual
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>mismo sonido para todo
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>indiferenciación
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>familias + intents
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>alarma menor
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>fatiga
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>separar `risk` / `threat`
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>loop de carga
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>molestia
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>silencio durante sustain
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>sin control
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>rechazo
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>preferencias

## CAPÍTULO 18
Háptica y vibración
Contacto, impacto, resistencia y encaje
La interfaz no solo puede verse u oírse.
También puede sentirse.
Al menos en algunos dispositivos.
Un teléfono puede responder con un pulso breve al tocar una tecla.
Un reloj puede vibrar para avisar de una notificación.
Un mando puede transmitir impacto, fricción o tensión.
Un trackpad puede simular un click que no existe físicamente.
Un sistema móvil puede usar háptica para reforzar selección, error, encaje o alerta.
La háptica es el canal de expresión que comunica mediante sensación corporal: vibración, presión, resistencia, impacto, textura, pulso o ritmo táctil.
En la web, este canal todavía es limitado. Pero esa limitación técnica no elimina el canal como dimensión teórica.
La teoría debe distinguir:
la háptica como canal de expresión
la háptica como capacidad disponible en una plataforma concreta
1. Fundamento psicoperceptivo: tacto, cuerpo y acción
La háptica se apoya en un hecho básico: la interacción con el mundo no es solo visual. Tocamos, presionamos, agarramos, soltamos, sentimos resistencia, textura, peso, impacto y vibración.
La percepción táctil y propioceptiva participa en cómo entendemos la acción. Cuando una interfaz simula contacto, no está inventando una categoría nueva. Está apoyándose en una experiencia corporal primaria: tocar algo y recibir una respuesta.
Por eso un pequeño pulso puede reforzar contact.press: el usuario no solo ve que el sistema respondió; lo siente.
La háptica también conecta con esquemas sensoriomotores de la cognición corporeizada. Esquemas como CONTACTO, IMPACTO, RESISTENCIA, ENCAJE o PÉRDIDA tienen una base corporal que puede trasladarse, de forma limitada, a la interfaz.
La investigación sobre tactons ha mostrado que los parámetros hápticos pueden codificar información mediante duración, ritmo, intensidad, localización o frecuencia. Esto permite pensar la háptica como canal semántico, no solo como buzz genérico.
Un pulso breve no comunica lo mismo que una vibración larga.
Un doble pulso no comunica lo mismo que un pulso único.
Un pulso fuerte no comunica lo mismo que uno suave.
Un patrón rítmico no comunica lo mismo que un impacto seco.
La háptica se integra con motion y sonido. Cuando el usuario suelta un objeto y ve que encaja, un pulso háptico sincronizado puede reforzar la sensación de drop. Si el pulso llega tarde, se separa del evento. Si es demasiado fuerte, comunica gravedad donde quizá solo había encaje leve.
2. Qué comunica la háptica
La háptica puede comunicar:
- contacto;
- impacto;
- encaje;
- rechazo;
- resistencia;
- alerta corporal;
- pérdida;
- ritmo.
Mientras motion puede simular la física visual de un evento, la háptica puede reforzar su dimensión corporal.
Un botón que se comprime comunica contacto visual.
Un pulso háptico breve comunica contacto táctil.
Un objeto que se asienta comunica encaje visual.
Un pequeño pulso al soltar comunica encaje corporal.
Una alerta visual comunica urgencia.
Una vibración fuerte o repetida comunica urgencia corporal.
3. Háptica y familias semánticas
CONTACT
contact.press
Es la familia háptica más básica.
Un pulso breve comunica:
PRINCIPIO
el sistema ha sentido mi acción.
Pero no todos los contactos deben vibrar. En interfaces de alta frecuencia, la háptica puede cansar rápidamente.
COMMIT
commit.select + affirm
commit.complete + fulfill
commit.fail + risk
commit.delete + loss
La háptica puede reforzar selección, cierre, rechazo o pérdida.
Un pulso suave puede marcar selección.
Un pulso más definido puede marcar final de operación.
Un patrón de rechazo puede marcar fallo.
Una vibración seca puede marcar pérdida.
SIGNAL
signal.alert + threat
La háptica puede reclamar atención corporal.
Pero debe reservarse para señales importantes. Una vibración por cada notificación menor convierte el cuerpo del usuario en superficie de ruido.
HANDLE
handle.pick
handle.drop
La háptica puede reforzar agarre, encaje, rechazo o destino.
El carry normalmente debería permanecer sin vibración continua, salvo simulaciones especializadas de fricción.
EMERGE
Normalmente no necesita háptica.
Un tooltip, dropdown o popover no debería vibrar al aparecer.
SHIFT
Puede usar háptica en cambios de modo muy significativos, pero con moderación.
SUSTAIN
La háptica sostenida es muy delicada. En general, no debería usarse para procesos continuos.
4. Háptica e intent
La háptica puede modular intent, aunque con menos sutileza que color, motion o sonido en muchas plataformas.
neutral → ausente o mínima
affirm → pulso suave
fulfill → pulso más definido / doble suave
risk → pulso contenido
threat → vibración fuerte o doble
loss → pulso seco / pesado
La diferencia entre threat y loss vuelve a ser importante.
Una amenaza prepara acción.
Una pérdida registra consecuencia.
La háptica de amenaza puede ser más activadora. La de pérdida puede ser más seca y conclusiva.
5. La web y sus límites hápticos
En la web, la háptica sigue siendo un canal débil.
La Vibration API permite patrones básicos de vibración en algunos dispositivos, pero no ofrece control fino sobre textura, intensidad, localización o calidad del motor. Además, su soporte y comportamiento varían entre navegadores y plataformas. Muchos contextos de escritorio no tienen háptica disponible.
Esto significa que en web no podemos asumir la háptica como canal principal.
La teoría puede incluirla, pero la implementación web debe tratarla como:
- opcional;
- degradable;
- nunca única;
- dependiente de dispositivo;
- sujeta a permisos o políticas;
- controlable por el usuario.
La pobreza háptica de la web no invalida la teoría. Solo impone una regla:
PRINCIPIO
En web, la háptica debe ser enriquecimiento, no soporte semántico obligatorio.
6. Ejemplo narrativo: teclado móvil
Un teclado móvil puede usar háptica para reforzar cada tecla.
Evento:
contact.press
La háptica comunica contacto.
Pero el evento es de frecuencia altísima. El usuario puede pulsar cientos de teclas en pocos minutos.
Por eso:
- pulso muy breve;
- intensidad baja;
- desactivable;
- sin variación dramática;
- sin intent fuerte.
Un teclado que vibra demasiado convierte el contacto en fatiga.
Aquí la semántica correcta es casi invisible:
PRINCIPIO
estoy tocando, el sistema responde, puedo seguir.
7. Ejemplo narrativo: selección de chip
El usuario selecciona un filtro.
Evento:
commit.select + affirm
Una háptica suave puede reforzar que la selección quedó aplicada, especialmente en móvil.
Pero no debe sentirse como logro importante.
affirm, no fulfill.
Expresión posible:
- pulso único suave;
- marca visual persistente;
- color positivo leve;
- sin sonido por defecto.
La háptica aquí refuerza estado, no celebra.
8. Ejemplo narrativo: drag-and-drop táctil
En una interfaz táctil, el usuario arrastra una tarjeta.
Secuencia:
handle.pick
handle.carry
handle.drop
PICK
Un pulso breve puede comunicar agarre.
Lectura:
PRINCIPIO
lo has cogido.
CARRY
Normalmente silencio háptico.
El usuario necesita control, no ruido táctil continuo.
DROP VÁLIDO
Pulso de encaje.
Lectura:
PRINCIPIO
encajó aquí.
DROP INVÁLIDO
Pulso de rechazo.
Lectura:
PRINCIPIO
no puede ir aquí.
DROP DESTRUCTIVO
Composición:
handle.drop
commit.delete + loss
La háptica puede comunicar consecuencia, pero con cuidado: no debe parecer amenaza si la pérdida ya ocurrió.
9. Ejemplo narrativo: alerta en wearable
En un reloj, la háptica puede ser el canal principal de una señal.
Evento:
signal.alert + threat
Aquí la vibración tiene sentido porque:
- la pantalla es pequeña;
- el usuario puede no estar mirando;
- el dispositivo está en contacto con el cuerpo;
- la señal puede requerir atención inmediata.
Pero incluso aquí debe haber control:
- patrón reconocible;
- duración limitada;
- posibilidad de silenciar;
- prioridad bien definida;
- no usar el mismo patrón para todo.
La háptica de wearable puede ser muy efectiva, pero precisamente por eso debe ser sobria.
10. Accesibilidad háptica
La háptica puede ayudar a algunas personas y molestar a otras.
Puede servir como canal alternativo cuando el sonido está desactivado.
Puede reforzar contacto.
Puede ayudar en wearables o contextos donde la visión está ocupada.
Pero también puede ser problemática:
- sensibilidad táctil;
- vibración molesta o dolorosa;
- fatiga por repetición;
- dispositivos con vibración demasiado brusca;
- falta de control de intensidad;
- patrones indistinguibles;
- interferencia con ayudas de accesibilidad.
Por eso la háptica debe ser:
- desactivable;
- proporcional;
- infrecuente cuando es intensa;
- nunca única para información crítica;
- ajustable si la plataforma lo permite;
- coherente con el evento.
La accesibilidad háptica no consiste en añadir vibración para “mejorar accesibilidad”. A veces la vibración reduce accesibilidad.
11. Antipatrones
12. Síntesis
La háptica es el canal corporal de la interfaz.
Comunica contacto, impacto, encaje, rechazo, resistencia, alerta y pérdida mediante sensación táctil.
Su fuerza está en que hace sentir el evento en el cuerpo.
Su riesgo está precisamente ahí: puede invadir, fatigar o excluir si se usa mal.
La tesis:
DISTINCIÓN
La háptica no es vibración añadida. Es la posibilidad de hacer corporalmente perceptible un evento.
Regla práctica:
PRINCIPIO
Diseñar la semántica para que pueda vivir sin háptica, y enriquecerla con háptica cuando la plataforma y el usuario lo permitan.
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>ANTIPATRÓN
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>PROBLEMA
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>CORRECCIÓN
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>vibrar por todo
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>fatiga corporal
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>reservar para eventos relevantes
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>mismo buzz para todo
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>indiferenciación
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>variar duración, ritmo, intensidad
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>háptica crítica sin respaldo
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>inaccesibilidad
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>canales alternativos
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>háptica desincronizada
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>ruido
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>sincronía con press/drop/señal
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>intensa y frecuente
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>rechazo
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>reducir intensidad
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>asumir háptica rica en web
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>inconsistencia
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>tratar como opcional

## CAPÍTULO 19
ACCESIBILIDAD PERCEPTIVA Y REDUCCIÓN DE CANALES
Cuando no todos perciben el mismo evento
Una teoría multicanal tiene una obligación inmediata: no puede asumir que todos los usuarios perciben los mismos canales, con la misma intensidad, en las mismas condiciones y con la misma tolerancia.
La accesibilidad no debería aparecer al final como cumplimiento. En este libro ocupa un lugar más profundo:
PRINCIPIO
La accesibilidad es la prueba de estrés de una semántica perceptiva.
1. Fundamento psicoperceptivo: variabilidad perceptiva y redistribución del significado
--------------------------------------------------------------------------------------
La accesibilidad perceptiva se apoya en una idea simple: no todos los usuarios disponen de los mismos canales en las mismas condiciones.
La visión puede estar reducida. El color puede no discriminarse. El sonido puede estar desactivado. El movimiento puede producir malestar. La háptica puede no existir. La atención puede estar fragmentada. El tiempo de procesamiento puede variar.
Esto significa que una semántica perceptiva no puede depender de una única vía sensorial.
Los fundamentos del Capítulo 3 ayudan a entender por qué:
- la Gestalt explica que la organización visual puede fallar si figura, fondo o agrupación no son claras;
- las affordances explican que una acción puede no percibirse como disponible si su forma no la sugiere;
- la atención explica que una señal puede no alcanzar el foco si no tiene suficiente saliencia;
- el valoración del evento explica que una evaluación puede perderse si el evento no comunica riesgo, pérdida o resolución;
- el espacio valencia/activación explica que el intent puede perderse si solo vive en color;
- la multisensorialidad explica que un evento puede sobrevivir si su significado migra entre canales;
- la cognición corporeizada explica que algunos usuarios pueden necesitar otras vías para percibir contacto, encaje o resistencia.
La pregunta central no es solo:
PRINCIPIO
¿puede el usuario acceder al componente?
Sino:
PRINCIPIO
¿puede comprender qué evento ocurrió y qué implica?
2. Canal único y fragilidad
---------------------------
Si el significado crítico vive en un solo canal, la semántica es vulnerable.
Error solo rojo. Contacto solo motion. Alerta solo sonido. Pérdida solo desaparición. Progreso solo spinner. Selección solo color.
Todos son frágiles.
3. Migración semántica
----------------------
Cuando un canal se reduce, no basta con quitarlo. Hay que preguntar:
PRINCIPIO
¿qué significado transportaba ese canal?
Si motion transportaba causalidad, debe migrar a estado, texto, sonido o háptica. Si color transportaba valencia, debe migrar a forma, icono, texto o posición. Si sonido transportaba urgencia, debe migrar a presencia, persistencia o live region. Si háptica transportaba encaje, debe migrar a motion, forma o sonido.
4. Accesibilidad y familias
---------------------------
Contact debe sobrevivir sin motion. Commit debe dejar huella. Signal no puede depender solo de color o sonido. Handle necesita alternativas a drag. Emerge debe sincronizar presencia visual y operativa. Shift debe gestionar foco y orientación. Sustain necesita texto, estado y control.
5. Síntesis
-----------
La accesibilidad perceptiva no es una excepción al sistema. Es la prueba de que familias, intents y canales no dependen de una condición ideal de percepción.
Una interacción semántica es robusta cuando conserva su significado bajo condiciones variables.

## CAPÍTULO 20
COORDINACIÓN MULTICANAL
Cuando varios canales dicen un solo evento
Una interfaz semántica no consiste en activar muchos canales.
Consiste en que, cuando varios canales participan, digan lo mismo.
O mejor:
PRINCIPIO
que participen en la misma lectura del evento.
1. Fundamento psicoperceptivo: integración multisensorial y congruencia
-----------------------------------------------------------------------
La coordinación multicanal se apoya en un principio general de la percepción: el sistema perceptivo tiende a integrar señales de distintas modalidades cuando parecen pertenecer al mismo evento.
Esa integración depende de varios factores:
- proximidad temporal;
- correspondencia espacial;
- congruencia semántica;
- intensidad compatible;
- relación causal plausible;
- expectativas previas;
- coherencia afectiva.
Si un movimiento, un sonido y una vibración ocurren en el momento adecuado y parecen corresponder al mismo tipo de evento, el usuario puede percibirlos como una unidad.
Si llegan desfasados, con intensidades contradictorias o con significados afectivos distintos, se separan.
La idea de integración temporal explica por qué un sonido de contacto que llega tarde se percibe como añadido, no como parte del press. La correspondencia crossmodal explica por qué un objeto que se mueve como algo pesado pero suena como algo ligero produce conflicto. La teoría de valencia/activación explica por qué los canales deben modular el mismo intent.
2. La secuencia completa del sistema
------------------------------------
La coordinación no empieza en los canales. Empieza en el evento.
La secuencia completa es:
evento
→ familia semántica
→ verbo / fase
→ evaluación si procede
→ intent
→ canales coordinados
Si se rompe esta secuencia, aparecen errores:
- canales sin evento;
- intent sin familia;
- color sin evaluación;
- sonido sin necesidad;
- motion sin semántica;
- accesibilidad como parche posterior.
3. Congruencia
--------------
La coordinación exige congruencia temporal, semántica, afectiva, de intensidad y accesible.
4. Redundancia significativa
----------------------------
La redundancia no es repetir por repetir.
Es hacer que el significado sobreviva cuando un canal falla.
5. Sobrecarga
-------------
La alternativa a la fragilidad no es saturación.
Una interfaz puede activar demasiados canales: cada click vibra, cada confirmación suena, cada cambio rebota, cada error interrumpe, cada success celebra.
El resultado no es claridad. Es fatiga.
6. Síntesis
-----------
La Parte II ha separado los canales para poder entenderlos.
Pero el usuario no vive esos canales separados.
La interfaz debe volver a unirlos.
La tesis:
DISTINCIÓN
Una interacción semántica multicanal no es una colección de efectos. Es una composición perceptiva orientada a un único evento.
CIERRE DE LA PARTE II
Con este capítulo se cierra la Parte II.
Hemos separado los canales para poder entenderlos:
- tiempo;
- motion;
- presencia;
- profundidad;
- forma;
- color;
- sonido;
- háptica;
- accesibilidad;
- coordinación multicanal.
Pero el usuario no vive esos canales como capas separadas. Los vive como un único evento, o como ruido si la coordinación falla.
La tesis de esta parte puede formularse así:
PRINCIPIO
El evento es la unidad de significado. Los canales son la materia sensible. La coordinación convierte esa materia en experiencia perceptiva unificada.
La siguiente parte volverá al eje semántico del sistema: las familias del evento. Allí veremos cómo contact, commit, signal, handle, emerge, shift, sustain, delegate y delegate no son categorías abstractas, sino formas recurrentes de organizar acción, consecuencia, atención, manipulación, presencia, marco y continuidad.
FIN DE LA PARTE II REESCRITA

## Capítulo 21
Las familias semánticas del evento
Qué nombran, de dónde vienen y cómo se usan
Hasta aquí, el libro ha construido una serie de piezas:
- la interfaz como dimensión perceptible de un contexto operativo;
- el evento como unidad básica de cambio;
- una gramática del evento;
- las interacciones semánticas;
- criterios para identificar diferencias relevantes;
- la distinción entre eventos valenciales y transicionales;
- un sistema de intents;
- y una teoría de canales de expresión.
A partir de este punto, el libro cambia de plano.
Deja de construir la teoría general y empieza a recorrer, una por una, las familias que organizan la semántica del evento.
Pero antes de entrar en cada familia, conviene responder tres preguntas:
Principio
¿Qué es exactamente una familia semántica? ¿De dónde sale este conjunto concreto? ¿Cómo debe leerse dentro del sistema?
1. Qué es una familia semántica
Una familia semántica no es un componente.
No es un botón, ni un modal, ni un toast, ni un dropdown, ni un loader.
Tampoco es un efecto.
No es un fade, ni un slide, ni un bounce, ni un sonido, ni una vibración.
Una familia semántica es:
Principio
una clase de evento perceptivamente recurrente que responde a una misma pregunta del usuario.
Por ejemplo:
contact → ¿el sistema ha sentido mi acción?
commit → ¿algo quedó fijado o tuvo consecuencia?
signal → ¿algo reclama mi atención?
handle → ¿estoy manipulando directamente algo?
emerge → ¿algo entró o salió del campo?
shift → ¿cambió el contexto?
sustain → ¿esto sigue ocurriendo?
Estas preguntas no son arbitrarias. Surgen de cómo el usuario organiza la experiencia interactiva: acción, respuesta, proceso, atención, presencia, manipulación, consecuencia.
Una familia no describe cómo se implementa algo.
Describe qué tipo de evento está ocurriendo.
2. De dónde salen las ocho familias
Las familias no aparecen por enumeración arbitraria.
El sistema partió de un conjunto más amplio de semánticas exploratorias: feedback, selection, revelation, context, expansion, navigation, notification, attention, emphasis, completion, destruction, persistence y manipulation.
Ese conjunto era útil para descubrir diferencias. Pero era demasiado granular como sistema canónico.
Al aplicar criterios de relevancia operativa, diferenciabilidad perceptiva, recurrencia, capacidad de composición, economía cognitiva y compatibilidad multicanal, el conjunto se redujo a ocho familias:
contact
commit
signal
handle
emerge
shift
sustain
No son las únicas posibles en un sentido absoluto, pero forman un conjunto mínimo y suficiente para describir la mayoría de eventos sin redundancia excesiva.
Cada familia cubre una región distinta del espacio de interacción:
- acción → contact
- consecuencia → commit
- atención → signal
- manipulación → handle
- presencia → emerge
- marco → shift
- proceso → sustain
3. Fundamento psicoperceptivo de las familias
Las familias no son categorías de diseño. Son categorías perceptivas.
Cada una nombra una estructura recurrente de la experiencia:
Esto es importante.
Si las familias se presentan solo como “eventos de UI”, pueden parecer inventadas. Pero no lo son. Son nombres operativos para estructuras que el usuario ya experimenta en la interacción.
El libro no inventa esas estructuras. Las hace explícitas.
4. Qué no son las familias
No son componentes
Un modal no es una familia.
Puede participar en:
shift.enter-mode
signal.alert + threat
Un dropdown no es una familia.
Puede ser:
emerge.open
Un botón no es contact. Un botón puede participar en contact.press, pero también en commit, signal o shift según el evento.
No son efectos
Un fade no es emerge.
Un slide no es shift.
Un bounce no es fulfill.
Un shake no es threat.
Los efectos son realizaciones posibles en canales. La familia es el evento.
No son estados
“Loading”, “error”, “success” no son familias.
Son mezclas de familia, verbo e intent:
loading → sustain.progress
error → commit.fail + risk
success → commit.complete + fulfill
5. La estructura completa del sistema
Una familia no actúa sola.
Forma parte de una estructura mayor:
familia.verbo + intent
Ejemplos:
contact.press + neutral
commit.save + affirm
commit.complete + fulfill
signal.warn + risk
signal.alert + threat
commit.delete + loss
handle.drop + risk
La familia nombra el tipo de evento.
El verbo concreta la acción.
El intent modula la evaluación.
Y todo eso se expresa mediante canales:
tiempo
motion
presencia
profundidad
forma
color
sonido
háptica
6. Familias y evaluabilidad
No todas las familias aceptan intent de la misma manera.
Esta no es una prohibición rígida, pero sí una regla de claridad:
Principio
el intent vive donde hay evaluación del evento, no donde solo hay organización del campo.
7. Cómo leer los capítulos de familias
Cada familia se desarrollará desde ocho planos:
1. qué pregunta responde;
2. qué eventos incluye;
3. cuál es su fundamento psicoperceptivo;
4. qué canales la expresan mejor;
5. cómo se relaciona con intent;
6. ejemplos prácticos;
7. riesgos y antipatrones;
8. consideraciones de accesibilidad.
No se trata de describir componentes, sino patrones de evento.
8. Ejemplo transversal
Tomemos una acción simple: eliminar un elemento.
contact.press
signal.warn + threat
commit.delete + loss
Tres familias distintas:
- contact → acción registrada;
- signal → advertencia;
- commit → consecuencia.
Tres preguntas distintas:
¿he pulsado?
¿puedo evitarlo?
¿qué ocurrió?
Si todo se tratara como un solo estado danger, se perderían esas distinciones.
9. Síntesis
Las familias semánticas son el eje de la gramática del evento.
No describen componentes, ni estilos, ni efectos, ni estados. Describen clases de evento perceptivamente recurrentes.
La tesis del capítulo:
Principio
La interfaz no se organiza solo en componentes. Se organiza en familias de eventos que responden a preguntas perceptivas recurrentes.
Fig. 1 — Las familias son respuestas a preguntas perceptivas recurrentes.
Fig. 2 — La familia define qué ocurre. El intent cómo se evalúa. Los canales lo hacen perceptible.
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Familia
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Fundamento perceptivo dominante
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>`contact`
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>agencia, causalidad inmediata, esquema táctil
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>`commit`
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>cierre, consecuencia, memoria de estado
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>`signal`
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>atención, saliencia, orientación
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>`handle`
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>control motor, manipulación, continuidad sensorimotora
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>`emerge`
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>figura/fondo, presencia, aparición perceptiva
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>`shift`
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>cambio de contexto, orientación, modelo mental
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>`sustain`
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>continuidad temporal, espera, reducción de incertidumbre
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Familia
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Relación con intent
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>`contact`
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>leve, anticipatoria
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>`commit`
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>plena
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>`signal`
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>plena
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>`handle`
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>sobre todo en `drop`
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>`emerge`
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>normalmente no
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>`shift`
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>normalmente no
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>`sustain`
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>normalmente no
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Familia
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Pregunta
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>`contact`
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿el sistema ha sentido mi acción?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>`commit`
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿algo quedó fijado o tuvo consecuencia?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>`signal`
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿algo reclama mi atención?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>`handle`
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿estoy manipulando algo directamente?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>`emerge`
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿algo entró o salió del campo?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>`shift`
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿cambió el contexto?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>`sustain`
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿esto sigue ocurriendo?

## Capítulo 22
Contact
La respuesta mínima del sistema a la acción del usuario
Antes de que una interfaz confirme, advierta, complete, falle o pierda algo, ocurre un momento previo.
El usuario actúa.
Pulsa. Toca. Hace click. Arrastra. Escribe. Activa.
Y entonces aparece una pregunta inmediata:
Principio
¿El sistema ha sentido mi acción?
Ese momento es contact.
1. Qué es `contact`
Contact es la familia semántica de la recepción de la acción.
No comunica resultado. No comunica éxito. No comunica error. No comunica estado final.
Comunica algo más básico:
Principio
la acción del usuario ha entrado en el sistema.
Ejemplos:
contact.press
contact.tap
contact.activate
contact.focus
contact.trigger
Un botón que se hunde ligeramente. Una tecla virtual que responde al toque. Un switch que muestra estado pressed. Un item que empieza a estar bajo el dedo.
Todo eso pertenece a contact.
2. Qué no es `contact`
contact no es commit.
contact.press ≠ commit.save
El sistema puede haber recibido la acción sin haber producido todavía resultado.
contact no es signal.
contact.press ≠ signal.warn
No reclama atención ni advierte. Solo registra acción.
contact no es handle.
contact.press ≠ handle.pick
Puede iniciar una manipulación, pero no es la manipulación.
contact no es intent.
contact.press + neutral
puede ser suficiente.
contact es anterior a la evaluación.
3. Fundamento psicoperceptivo: agencia, causalidad inmediata y esquema táctil
contact se apoya en la percepción de agencia: la tendencia del usuario a atribuir un cambio al propio gesto cuando la respuesta ocurre con suficiente proximidad temporal y formal.
Cuando el sistema responde inmediatamente al gesto, el usuario percibe:
yo hice esto → el sistema respondió
Si la respuesta se retrasa:
yo hice esto → … → algo ocurrió
la relación causal se debilita.
Este fundamento conecta con la percepción de causalidad dinámica: ciertos cambios próximos en el tiempo y coherentes en su forma tienden a organizarse como relación causa-efecto. En interfaz, la microrespuesta de un control preserva esa lectura causal.
También se apoya en esquemas sensorimotores básicos. Tocar algo y recibir una respuesta es una experiencia corporal primaria: presión, resistencia, rebote, click, vibración. La interfaz digital toma prestada esa estructura para hacer que una acción abstracta se sienta registrada.
Por eso contact no es decoración. Es la semántica mínima de agencia.
4. La pregunta perceptiva
contact responde a:
Principio
¿el sistema ha sentido mi acción?
Si la respuesta es clara, el usuario continúa.
Si no, aparecen comportamientos compensatorios:
- doble click;
- repetición del toque;
- espera insegura;
- frustración;
- abandono de la operación.
Muchos problemas de UX no son errores funcionales. Son fallos de contact.
5. Contact y latencia
El canal crítico de contact es el tiempo.
Un contacto correcto:
input → feedback inmediato
Un contacto fallido:
input → silencio → feedback
Esto no es un problema estético. Es un problema semántico.
Principio
Un contacto bonito pero tardío es peor que un contacto simple pero inmediato.
6. Canales de `contact`
contact suele apoyarse en pocos canales.
El color puede acompañar, pero no debe ser el canal principal. El contacto se siente sobre todo por tiempo, microcambio y relación causal.
7. Contact y verbos
contact no es un único gesto.
press
tap
activate
focus
trigger
Ejemplos:
contact.press
contact.focus
contact.trigger
Cada uno mantiene la misma lógica:
Principio
acción registrada, no resultado.
8. Contact frente a Commit
Ejemplo clave:
contact.press
commit.save + affirm
contact dice:
Principio
he pulsado.
commit dice:
Principio
se guardó.
Error típico:
contact.press + fulfill
Esto hace que el sistema diga “ya terminó” cuando solo ha empezado.
Principio
Contact inicia. Commit resuelve.
9. Contact frente a Signal
contact.press
signal.warn + risk
Contact:
Principio
he actuado.
Signal:
Principio
atiende esto.
No deben mezclarse. Un contacto no debería reclamar atención si todavía no hay nada que evaluar.
10. Contact en componentes web
Botón
contact.press
microcompresión, estado pressed, retorno rápido.
Input
contact.focus
cursor visible, contorno, foco.
Toggle
contact.press
commit.toggle + affirm
el press registra; el toggle fija.
Link
contact.press
shift.navigate
la presión no es la navegación.
Drag
contact.press
handle.pick
el contacto inicia el agarre, pero no lo agota.
11. Contact e intent
Normalmente:
contact + neutral
o incluso sin intent explícito.
En acciones graves, la interfaz puede anticipar el peso mediante forma, color o señal previa, pero el intent fuerte no debería vivir en el contacto, sino en la señal o consecuencia posterior.
Ejemplo:
contact.press
signal.warn + threat
commit.delete + loss
12. Contact y accesibilidad
contact debe sobrevivir sin motion, sonido o háptica.
Si el usuario duda si ha actuado, el problema no es solo de rendimiento. Es de semántica de contacto.
13. Antipatrones
14. Síntesis
contact es la familia de la agencia mínima.
No evalúa. No resuelve. No advierte.
Responde a una única pregunta:
Principio
¿el sistema ha sentido mi acción?
Su regla práctica:
Principio
Cuanto más frecuente es una acción, más inmediato y más discreto debe ser su contacto.
Fig. 1 — La percepción de agencia depende de la proximidad entre acción y respuesta.
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Latencia
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Lectura
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>muy baja
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>contacto
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>media
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>respuesta
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>alta
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>duda / desconexión
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Canal
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Función
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Tiempo
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>respuesta inmediata
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Motion
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>microrespuesta
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Forma
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>estado pressed / foco
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Sonido
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>click breve opcional
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Háptica
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>pulso breve opcional
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Color
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>secundario
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Canal ausente
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Sustituto
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Motion
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>estado pressed, foco visible
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Sonido
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>estado visual
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Háptica
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>tiempo + forma
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Visión
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>anuncio o feedback auditivo si procede
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Antipatrón
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Problema
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Contacto tardío
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>rompe agencia
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Contacto exagerado
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>teatraliza acciones menores
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Contacto como éxito
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>promete resultado antes de tiempo
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Sin feedback
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>incertidumbre
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Solo color
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>feedback débil o inaccesible
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Sonido en todo
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>fatiga

## Capítulo 23
Commit
Cuando algo queda fijado, seleccionado, completado o perdido
Si contact responde a:
Principio
¿el sistema ha sentido mi acción?
commit responde a una pregunta distinta y decisiva:
Principio
¿qué ha pasado como consecuencia de esa acción?
Aquí es donde la interfaz deja de registrar gestos y empieza a producir realidad operativa.
Algo queda seleccionado. Algo se guarda. Algo se envía. Algo se completa. Algo falla. Algo se descarta. Algo se elimina. Algo se pierde.
Ese momento —cuando el sistema fija un estado o produce una consecuencia— es commit.
1. Qué es `commit`
Commit es la familia semántica de la fijación de estado o consecuencia.
No es el inicio. No es el proceso. No es la advertencia.
Es el momento en que el sistema dice:
Principio
esto ya ocurrió.
Ejemplos:
commit.select
commit.save
commit.submit
commit.complete
commit.fail
commit.delete
commit.restore
commit.cancel
commit.expire
commit.discard
Todos comparten una propiedad:
Distinción
después de este evento, el sistema ya no es exactamente el mismo que antes.
2. Qué no es `commit`
commit no es contact.
contact.press ≠ commit.save
El sistema puede haber recibido la acción sin haber producido todavía el resultado.
commit no es sustain.
sustain.progress ≠ commit.complete
El proceso puede seguir en curso.
commit no es signal.
signal.warn ≠ commit.fail
Una advertencia no es un resultado.
commit no es shift.
shift.navigate ≠ commit.submit
Cambiar de pantalla no equivale a completar una operación.
3. Fundamento psicoperceptivo: cierre, consecuencia y memoria de estado
commit se apoya en una necesidad fundamental de la acción: saber cuándo una operación produjo consecuencia.
El usuario no solo necesita actuar. Necesita saber qué quedó después de actuar.
Esta familia se sostiene sobre tres dimensiones psicoperceptivas:
3.1. Cierre cognitivo
Una acción abierta genera incertidumbre. El usuario necesita percibir cuándo puede dejar de vigilarla. commit cierra la secuencia.
acción → resultado
Sin cierre, la acción queda suspendida.
3.2. Resultado de la acción
El usuario necesita saber si algo cambió en el sistema: una opción quedó marcada, un documento fue guardado, un archivo se eliminó, una operación falló.
3.3. Memoria de estado
Un buen commit deja huella. No desaparece como un contacto. Puede quedar como estado seleccionado, mensaje, ausencia, historial, undo, marca de completado o error persistente.
Por eso commit no solo ocurre. Se recuerda.
4. La pregunta perceptiva
commit responde:
Principio
¿qué ha quedado fijado?
O:
¿se guardó?
¿se eligió?
¿se envió?
¿se completó?
¿falló?
¿se perdió?
5. Verbos de `commit`
commit tiene verbos que definen el tipo de consecuencia:
select
toggle
save
submit
complete
fail
delete
restore
cancel
reset
expire
discard
Ejemplos:
commit.select + affirm
commit.complete + fulfill
commit.fail + risk
commit.delete + loss
6. Tipos de commit
6.1. Fijación de estado
commit.select
commit.toggle
commit.save
Lectura:
Principio
algo queda aplicado o guardado.
6.2. Resolución de proceso
commit.complete
commit.submit
commit.fail
Lectura:
Principio
un proceso terminó.
6.3. Consecuencia irreversible o crítica
commit.delete
commit.discard
commit.expire
Lectura:
Principio
algo deja de estar disponible.
7. Canales de `commit`
A diferencia de contact, commit suele requerir huella.
8. Commit e intent
commit es una de las familias donde el intent vive con más fuerza.
`affirm`
commit.save + affirm
Lectura:
Principio
todo va bien.
`fulfill`
commit.complete + fulfill
Lectura:
Principio
objetivo logrado.
`risk`
commit.fail + risk
Lectura:
Principio
algo no se completó, revisa.
`loss`
commit.delete + loss
Lectura:
Principio
esto ya se perdió.
El intent no cambia el evento. Cambia cómo se evalúa su consecuencia.
9. Commit vs Contact
contact.press
commit.save + affirm
Error común:
contact.press + fulfill
Problema:
Principio
se celebra antes de saber el resultado.
10. Commit vs Sustain
sustain.progress → commit.complete
sustain mantiene.
commit cierra.
Confundirlos produce incertidumbre.
11. Ejemplos prácticos
Guardar
contact.press
sustain.progress
commit.save + affirm
Enviar
contact.press
sustain.progress
commit.submit + fulfill
Error
contact.press
commit.fail + risk
Eliminación
signal.warn + threat
commit.delete + loss
Toggle
contact.press
commit.toggle + affirm
12. Accesibilidad
commit debe ser visible, persistente y comprensible.
Debe sobrevivir sin color, sonido o motion.
Si el usuario no sabe qué ocurrió después de actuar, el commit falló.
13. Antipatrones
14. Síntesis
commit es la familia donde la interfaz produce consecuencias.
Comunica:
La tesis:
Distinción
El significado de la interfaz no está en el click. Está en lo que queda después.
Regla principal:
Principio
Todo evento importante debe dejar una huella perceptible de su consecuencia.
Fig. 1 — Después de commit, el sistema ya no es el mismo que antes.
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Tipo
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Ejemplo
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Lectura
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Estado
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>`commit.select`
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>esto queda elegido
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Proceso
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>`commit.complete`
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>esto terminó
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Consecuencia
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>`commit.delete`
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>esto ya no está
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Canal
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Función
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Forma
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>estado persistente
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Presencia
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>aparición o retirada
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Motion
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>asentamiento o cierre
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Color
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>refuerzo de estado o valencia
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Sonido
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>cierre opcional
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Háptica
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>impacto o encaje opcional
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Tiempo
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>marca el momento de resolución
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Canal ausente
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Sustituto
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Color
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>forma + texto
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Motion
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>estado persistente
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Sonido
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>mensaje visible
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Háptica
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>estado + motion
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Antipatrón
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Problema
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Sin commit visible
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>incertidumbre
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Commit efímero
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>no deja huella
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Todo es success
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>trivializa resultados
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Todo es danger
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>mezcla pérdida y amenaza
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Celebración constante
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>fatiga
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Sin diferencia entre affirm y fulfill
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>pérdida de matiz
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Resultado solo en color
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>inaccesible
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Dimensión
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Pregunta
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Estado
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿qué quedó aplicado?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Resultado
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿qué ocurrió?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Cierre
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿puedo continuar?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Consecuencia
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿qué cambió en el sistema?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Evaluación
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿cómo debo interpretarlo?

## Capítulo 24
Signal
Cuando el sistema reclama atención
Si contact responde a:
Principio
¿el sistema ha sentido mi acción?
y commit responde a:
Principio
¿qué ha pasado como consecuencia?
signal responde a una pregunta distinta:
Principio
¿debo atender esto?
Aquí el flujo se invierte.
No es el usuario quien actúa primero. Es el sistema quien orienta, interrumpe o reclama la atención.
Una advertencia antes de eliminar. Un error en un campo. Un badge que indica algo nuevo. Una notificación. Un mensaje informativo. Un aviso de expiración de sesión. Una validación. Una señal de progreso que requiere atención.
Todo eso pertenece a signal.
1. Qué es `signal`
Signal es la familia semántica de la orientación y reclamación de atención.
No ejecuta una acción. No fija un resultado. No cambia el marco por sí sola.
Hace algo más básico:
Principio
dirige la percepción del usuario hacia algo relevante.
Ejemplos:
signal.announce
signal.notify
signal.warn
signal.alert
signal.inform
signal.emphasize
signal.remind
2. Qué no es `signal`
signal no es commit.
signal.warn ≠ commit.fail
Una advertencia no es un resultado. Un resultado puede necesitar señal, pero no son lo mismo.
signal no es contact.
No es respuesta a acción. Puede aparecer sin gesto directo.
signal no es emerge.
emerge.open ≠ signal
Algo puede aparecer sin reclamar atención.
signal no es shift.
Un modal no es la señal. El mensaje dentro puede serlo.
3. Fundamento psicoperceptivo: atención, saliencia y carga cognitiva
signal se apoya en la orientación atencional.
La percepción no procesa todo por igual. El sistema atencional decide qué entra en foco, qué queda en fondo, qué se pospone y qué interrumpe.
Una señal puede:
- orientar la atención;
- informar;
- advertir;
- interrumpir;
- mantener algo en vigilancia;
- fatigar.
El concepto clave es saliencia: la capacidad de un estímulo para destacar del fondo y reclamar procesamiento.
Pero la saliencia tiene coste.
Demasiada saliencia produce ruido. Poca saliencia produce invisibilidad.
Por eso signal no es simplemente “mostrar algo”. Es regular cuánta atención se pide.
Esta familia se apoya en mecanismos de orientación atencional y en la distinción entre estímulos que simplemente aparecen y estímulos que exigen procesamiento.
4. La pregunta perceptiva
signal responde:
Principio
¿debo notar esto?
Y, en casos de mayor urgencia:
Principio
¿debo actuar ahora?
5. Tipos de señal
5.1. `signal.announce`
signal.announce + neutral
Comunica:
Principio
esto existe, sin urgencia.
5.2. `signal.notify`
signal.notify + neutral / affirm
Comunica:
Principio
algo ocurrió, pero no requiere acción inmediata.
5.3. `signal.warn`
signal.warn + risk
Comunica:
Principio
revisa esto.
5.4. `signal.alert`
signal.alert + threat
Comunica:
Principio
atiende ahora.
6. Canales de `signal`
signal es una familia multicanal fuerte.
El texto es especialmente importante. Es el canal que puede explicar con precisión qué ocurre y qué debe hacer el usuario.
7. Signal e intent
La relación con intent es central.
signal + intent
- signal.announce + neutral → sin carga afectiva fuerte.
- signal.notify + affirm → confirmación ligera.
- signal.warn + risk → problema corregible.
- signal.alert + threat → urgencia.
loss es menos común en signal, porque la pérdida suele vivir en commit. Pero una señal puede anunciar una pérdida ya ocurrida:
signal.announce + loss
si lo que el sistema hace es comunicar una consecuencia previa.
8. Signal vs Emerge
emerge.open
signal.warn + risk
- emerge → aparece algo.
- signal → eso que aparece importa.
Error común:
emerge.open + danger
Se está cargando el contenedor, no el evento evaluable.
9. Signal vs Commit
signal.warn + risk
commit.fail + risk
- signal puede ocurrir antes o durante.
- commit ocurre como resultado.
Ejemplo:
signal.warn + risk
Principio
revisa este campo.
commit.fail + risk
Principio
la operación no se completó.
10. Ejemplos prácticos
Error de formulario
signal.warn + risk
- forma: inline;
- color: moderado;
- texto: claro;
- persistente hasta corrección.
Notificación informativa
signal.notify + neutral
- presencia leve;
- no interrumpe.
Alerta crítica
signal.alert + threat
- presencia fuerte;
- posible sonido;
- persistente hasta acción.
Información contextual
signal.announce + neutral
No es intent info. Es señal neutra.
11. Accesibilidad
signal es la familia más crítica en accesibilidad.
Debe:
- no depender solo de color;
- tener texto claro;
- ser persistente si importa;
- usar live region si procede;
- no ser solo sonora;
- no desaparecer demasiado rápido;
- no interrumpir sin necesidad.
12. Antipatrones
13. Síntesis
signal es la familia de la atención.
No actúa. No fija. No transforma el sistema directamente.
Hace algo más básico:
Principio
dirige la percepción del usuario.
Comunica:
La tesis:
Principio
Una interfaz no solo responde a acciones. También guía la atención.
Fig. 1 — Signal no es solo mostrar algo. Es regular cuánta atención se pide.
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Tipo
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Intent
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Lectura
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>announce
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>neutral
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>existe
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>notify
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>neutral / affirm
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>ocurrió algo
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>warn
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>risk
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>revisa
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>alert
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>threat
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>actúa ahora
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Canal
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Función
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Presencia
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>aparición visible
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Forma
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>separar de contenido
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Color
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>valencia y saliencia
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Texto
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>significado explícito
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Tiempo
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>persistencia
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Motion
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>entrada / énfasis
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Sonido
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>opcional, fuera de foco
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Háptica
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>opcional, alertas
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Problema
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Solución
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>solo color
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>añadir texto/icono
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>solo sonido
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>añadir visual
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>efímero
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>persistencia
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>fuera de foco
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>live region
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>exceso de alerta
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>graduar
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Antipatrón
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Problema
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Todo es alert
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>fatiga
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Info como intent
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>confusión
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Warning para todo
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>pierde significado
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Señales efímeras
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>no se procesan
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Exceso de motion
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>ruido
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Modal para todo
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>interrupción
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Dimensión
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Pregunta
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Atención
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿debo mirar esto?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Urgencia
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿debo actuar ahora?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Saliencia
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿qué destaca?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Contexto
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿qué significa esto?

## Capítulo 25
Handle
Cuando el usuario manipula directamente un objeto
Hasta ahora hemos visto familias donde la interacción suele ser discreta: contact registra una acción, commit fija una consecuencia y signal reclama atención.
Pero hay un tipo de interacción donde el evento no cabe en un instante.
El usuario no solo pulsa. No solo confirma. No solo observa.
El usuario manipula.
Arrastra. Reordena. Redimensiona. Desliza. Mueve. Agarra. Suelta.
Aquí aparece otra pregunta:
Principio
¿estoy controlando directamente este objeto?
Esa pregunta define handle.
1. Qué es `handle`
Handle es la familia semántica de la manipulación directa.
No es una acción puntual. No es un resultado. No es una señal.
Es una relación continua entre el usuario y un objeto.
Ejemplos:
handle.pick
handle.carry
handle.drop
handle.drag
handle.resize
handle.rotate
handle.reorder
A diferencia de otras familias, handle no es un instante. Es una secuencia sostenida en el tiempo.
2. Qué no es `handle`
handle no es contact.
contact.press ≠ handle.pick
contact inicia. handle continúa.
handle no es commit.
handle.drop ≠ commit.delete
Soltar no es necesariamente el resultado. El resultado ocurre después o en composición.
handle no es sustain.
sustain.progress ≠ handle.carry
Un proceso automático no es control directo.
handle no es shift.
Mover un objeto no es cambiar de vista.
3. Fundamento psicoperceptivo: control directo, esquema corporal y continuidad
handle se apoya en la percepción de control directo sobre un objeto.
Cuando el usuario arrastra algo, espera que ese objeto:
- responda inmediatamente;
- siga su gesto;
- conserve identidad;
- tenga comportamiento coherente;
- se asiente, encaje o se rechace al soltar.
Esto conecta con esquemas sensoriomotores básicos: agarrar, trasladar, soltar.
El usuario no piensa en eventos discretos. Piensa:
Principio
estoy moviendo esto.
La interfaz debe sostener esa ilusión. Si el objeto se retrasa, el control se rompe. Si se mueve de forma extraña, el usuario pierde confianza. Si no se sabe qué se está manipulando, hay ambigüedad.
handle es una de las familias más corporales del sistema porque convierte la interfaz en espacio de acción continua.
4. Las fases de `handle`
handle tiene tres fases fundamentales.
4.1. Pick
handle.pick
Pregunta:
Principio
¿he agarrado esto?
Canales:
- profundidad;
- motion;
- forma;
- háptica opcional.
Lectura:
Principio
esto está bajo mi control.
4.2. Carry
handle.carry
Pregunta:
Principio
¿sigue bajo mi control?
Canales:
- motion continuo;
- latencia mínima;
- coherencia espacial.
Lectura:
Principio
estoy moviendo esto.
4.3. Drop
handle.drop
Pregunta:
Principio
¿qué ocurrió al soltar?
Aquí handle se conecta con otras familias:
handle.drop
commit.reorder + affirm
commit.delete + loss
signal.warn + risk
Lectura:
Principio
esto se colocó / esto no encaja / esto se perdió.
5. Canales de `handle`
handle es una de las familias más exigentes en canales.
Motion y profundidad son centrales. El objeto debe sentirse separado del layout mientras está en control directo.
6. Handle y evaluación
handle tiene una relación especial con intent.
El carry normalmente no debe cargar intent. Durante el carry el usuario planifica y controla. La evaluación aparece sobre todo en el drop.
Ejemplo:
handle.pick
handle.carry
handle.drop + risk
si el destino es inválido.
O:
handle.pick
handle.carry
commit.delete + loss
si el drop produce eliminación.
Esto evita inyectar evaluación en una fase que aún no tiene resultado.
7. Ejemplos prácticos
Drag & drop
contact.press
handle.pick
handle.carry
handle.drop
commit.move + affirm
Reordenar lista
handle.pick
handle.carry
handle.drop
commit.reorder + affirm
Resize
handle.resize
commit.resize + affirm
Slider
handle.drag
commit.set + affirm
8. Accesibilidad
handle es la familia más difícil de hacer accesible porque suele depender de gesto continuo, precisión motora y control espacial.
Soluciones:
- alternativa por teclado;
- botones subir/bajar;
- selección + acción;
- zonas explícitas;
- feedback textual;
- estado del objeto;
- cancelación clara;
- no depender solo de drag-and-drop.
Principio
La accesibilidad no exige el mismo gesto. Exige el mismo resultado operativo.
9. Antipatrones
10. Síntesis
handle es la familia de la manipulación directa.
Comunica:
La tesis:
Principio
Handle convierte la interfaz en espacio de acción continua.
Su regla principal:
Principio
El objeto debe sentirse bajo control en todo momento.
Fig. 1 — Handle no es un evento puntual. Es una secuencia sostenida.
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Fase
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Evento
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Lectura
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Pick
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>`handle.pick`
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>agarro
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Carry
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>`handle.carry`
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>controlo
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Drop
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>`handle.drop`
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>suelto / evalúo
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Canal
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Función
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Tiempo
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>latencia mínima
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Motion
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>continuidad
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Profundidad
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>régimen de manipulación
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Forma
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>objeto activo / asa
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Color
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>destino válido/inválido
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Sonido
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>opcional en pick/drop
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Háptica
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>opcional en pick/drop
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Antipatrón
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Problema
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Lag en drag
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>pierde control
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Sin elevación
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>no se entiende pick
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Objeto rígido
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>no sigue gesto
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Drop ambiguo
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>no se sabe resultado
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Sin alternativa
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>inaccesible
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Feedback continuo
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>fatiga
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Intent durante carry
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>ruido evaluativo
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Dimensión
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Pregunta
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Control
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿esto está bajo mi acción?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Continuidad
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿sigue siendo el mismo objeto?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Movimiento
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿lo estoy moviendo?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Resultado
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿qué ocurre al soltar?

## Capítulo 26
Emerge
Cuando algo entra o sale del campo perceptivo
Hasta ahora hemos visto familias en las que el sistema responde, fija consecuencias, reclama atención o permite manipular objetos.
Pero hay otra clase de evento más silenciosa y estructural.
Algo aparece. Algo se revela. Algo se despliega. Algo se oculta. Algo se retira. Algo entra en el campo perceptivo. Algo deja de estar presente.
Fig. 1 — Emerge hace que algo pase a ocupar una figura reconocible en el campo.
Ese evento no siempre comunica éxito, error, riesgo o pérdida. Muchas veces solo reorganiza la presencia.
La pregunta de emerge es:
Principio
¿algo ha entrado o salido del campo perceptivo?
1. Qué es `emerge`
Emerge es la familia semántica de la aparición y retirada perceptiva.
No nombra el contenido que aparece. No nombra su evaluación. No nombra necesariamente una decisión del usuario.
Nombra el hecho de que algo pasa a estar presente o deja de estarlo.
Ejemplos:
emerge.present
emerge.dismiss
emerge.open
emerge.close
emerge.expand
emerge.collapse
emerge.reveal
emerge.hide
emerge no dice todavía:
esto es bueno
esto es malo
esto es urgente
esto se perdió
Dice:
Principio
esto entra en el campo esto sale del campo
2. Qué no es `emerge`
emerge no es signal.
emerge.open ≠ signal.warn
Algo puede aparecer sin reclamar atención urgente.
Si lo que aparece contiene una advertencia, entonces tenemos composición:
emerge.open
signal.warn + risk
emerge organiza presencia. signal reclama atención.
emerge no es shift.
emerge.open ≠ shift.enter-mode
Un elemento puede aparecer sin cambiar el contexto.
emerge no es commit.
emerge.dismiss ≠ commit.delete + loss
Cerrar un panel no es perder un recurso.
3. Fundamento psicoperceptivo: figura/fondo, presencia y organización del campo
emerge se apoya en la organización perceptiva del campo.
La percepción no recibe la pantalla como una lista plana de elementos. Organiza lo que aparece como figura, fondo, región, objeto, superficie, contorno, relación y prioridad.
En esa organización, la aparición de una nueva figura modifica el campo perceptivo.
Un tooltip que aparece junto a un término no solo añade un rectángulo: convierte una información auxiliar en figura local.
Un dropdown que se abre no solo añade opciones: revela una región dependiente de un control.
Un accordion que se expande no solo aumenta la altura de una sección: convierte contenido oculto en parte del campo procesable.
emerge suele ser transicional: reorganiza la presencia para que algo pueda verse, leerse, elegirse o evaluarse.
4. La pregunta perceptiva
emerge responde:
Principio
¿qué acaba de entrar o salir del campo?
Y también:
¿de dónde viene?
¿a qué pertenece?
¿puedo interactuar con ello?
¿es temporal o persistente?
¿se ha ocultado o se ha perdido?
5. Verbos de `emerge`
6. Tipos de `emerge`
Aparición anclada
emerge.open
Dropdown, tooltip, popover.
Lectura:
Principio
esto viene de aquí.
Expansión interna
emerge.expand
Accordion, details, sección desplegable.
Lectura:
Principio
esto estaba contenido aquí.
Retirada reversible
emerge.dismiss
emerge.close
emerge.hide
Lectura:
Principio
se fue de la vista, pero no se perdió.
Aparición auxiliar
emerge.present
Ejemplo:
commit.delete + loss
emerge.present undo
7. Canales de `emerge`
emerge debe ser legible, no necesariamente saliente.
8. Emerge e intent
emerge normalmente no acepta intent.
Su función principal es estructural: introduce presencia. Lo evaluable será lo que aparece dentro o lo que ocurre después.
Incorrecto:
emerge.open + threat
Más preciso:
emerge.open
signal.warn + threat
La amenaza está en la advertencia, no en el hecho de abrir.
9. Emerge vs Signal
Tooltip:
emerge.present
Alerta inline:
signal.warn + risk
Composición:
emerge.present
signal.warn + risk
Lectura:
Principio
algo aparece y ese algo contiene una advertencia.
10. Emerge vs Shift
Dropdown:
emerge.open
Modal:
shift.enter-mode
El primero introduce presencia local. El segundo cambia régimen operativo.
11. Emerge vs Commit/Delete
emerge.dismiss
significa:
Principio
se retiró de la vista.
commit.delete + loss
significa:
Principio
dejó de estar disponible.
No es lo mismo ocultar que perder.
Fig. 2 — La semántica debe distinguir retirada, ocultación, colapso y pérdida.
12. Ejemplos prácticos
Dropdown
contact.press
emerge.open
commit.select + affirm
emerge.close
Tooltip
contact.focus
emerge.present
emerge.dismiss
Accordion
contact.press
emerge.expand
emerge.collapse
Eliminación con undo
signal.warn + threat
commit.delete + loss
emerge.present undo
13. Accesibilidad
emerge tiene riesgos importantes.
Principio
Si algo emerge visualmente, también debe emerger operativamente.
14. Antipatrones
15. Síntesis
emerge es la familia de la presencia.
Comunica:
Tesis:
Principio
Emerge no dice qué significa lo que aparece. Dice que algo ha pasado a estar presente.
Regla:
Principio
La aparición debe ser proporcional al régimen que introduce.
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Verbo
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Lectura
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>`present`
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>algo se muestra
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>`dismiss`
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>algo se retira de la atención
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>`open`
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>una superficie o región se abre
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>`close`
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>una superficie o región se cierra
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>`expand`
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>una región crece y revela contenido
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>`collapse`
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>una región se contrae
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>`reveal`
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>algo oculto se hace visible
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>`hide`
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>algo sigue existiendo pero deja de verse
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Canal
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Función
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Presencia
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>hacer visible o retirar
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Motion
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>mostrar origen, entrada, salida
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Profundidad
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>indicar plano flotante o dependencia
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Forma
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>definir superficie o región
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Tiempo
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>duración de aparición y retirada
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Color
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>secundario
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Sonido
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>normalmente no
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Háptica
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>normalmente no
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Riesgo
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Soporte necesario
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>contenido aparece pero no se anuncia
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>estado abierto/cerrado
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>tooltip inaccesible
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>alternativa textual / descripción
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>dropdown sin teclado
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>navegación y escape
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>accordion visual solamente
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>`aria-expanded`, relación trigger-panel
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>popover flotante
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>foco y cierre claro
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>contenido oculto aún accesible
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>coherencia DOM/árbol accesible
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Antipatrón
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Qué falla
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Corrección
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Todo lo que aparece parece alerta
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>exceso de saliencia
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>separar `emerge` de `signal`
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Dropdown como modal
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>profundidad excesiva
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>mantener anclaje local
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Tooltip inaccesible
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>información perdida
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>descripción accesible
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Cerrar como eliminar
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>confusión de consecuencia
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>separar `dismiss` y `delete + loss`
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Fade sin origen
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>dependencia ambigua
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>motion anclado
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Contenido oculto pero accesible
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>incoherencia operativa
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>sincronizar DOM/ARIA/visibilidad
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Dimensión
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Pregunta
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Aparición
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿qué acaba de entrar en el campo?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Retirada
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿qué acaba de salir?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Origen
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿de dónde viene?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Dependencia
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿a qué pertenece?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Reversibilidad
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿se ocultó o se perdió?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Campo
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿cómo se reorganiza lo visible?

## Capítulo 27
Shift
Cuando cambia el contexto
Hasta ahora hemos visto eventos que ocurren dentro de un mismo contexto: el sistema responde, algo queda fijado, algo reclama atención, el usuario manipula, algo aparece o desaparece.
Pero hay un tipo de evento distinto.
No cambia solo un elemento. No aparece solo una superficie. No se completa solo una acción.
Cambia el lugar desde el que todo lo demás se interpreta.
El usuario pasa a otro estado del sistema.
Ese evento es shift.
1. Qué es `shift`
Shift es la familia semántica del cambio de contexto.
No describe un contenido. No describe una señal. No describe una acción puntual.
Describe algo más profundo:
Principio
el contexto en el que el usuario actúa ha cambiado.
Ejemplos:
shift.enter-mode
shift.exit-mode
shift.navigate
shift.step
shift.route
shift.context
shift.return
Abrir un modal. Entrar en edición. Ir a otra pantalla. Avanzar en un flujo. Cambiar de vista. Activar un modo especial.
2. Qué no es `shift`
shift no es emerge.
emerge.open ≠ shift.enter-mode
Un dropdown aparece. Un modal cambia el contexto.
shift no es commit.
shift.navigate ≠ commit.submit
Ir a otra pantalla no implica que la operación haya terminado.
shift no es signal.
Un cambio de vista no es una advertencia.
shift no es handle.
Manipular un objeto no es cambiar el marco.
3. Fundamento psicoperceptivo: cambio de contexto, orientación y modelo mental
shift se apoya en un fenómeno clave: el usuario opera siempre dentro de un modelo mental activo.
Fig. 1 — El cambio no es solo visual. Es semántico.
Cuando ese modelo cambia, la percepción cambia con él.
Ejemplos:
- editar vs visualizar;
- navegar vs confirmar;
- formulario vs resultado;
- lista vs detalle;
- búsqueda vs navegación;
- selección simple vs modo bulk.
Estos no son cambios visuales únicamente. Son cambios en:
qué puedo hacer
qué significa cada acción
qué es relevante
qué está permitido
qué queda subordinado
cómo vuelvo
El usuario necesita reorientarse.
Si el sistema no comunica el cambio de contexto, aparece desorientación:
¿dónde estoy?
¿qué ha cambiado?
¿puedo volver?
¿qué puedo hacer ahora?
shift no es opcional. Es necesario para mantener coherencia cognitiva.
4. La pregunta perceptiva
shift responde:
Principio
¿sigo en el mismo contexto o estoy en otro?
Y también:
¿puedo hacer lo mismo aquí?
¿cómo vuelvo?
¿qué cambió?
qué es ahora lo importante?
5. Tipos de `shift`
Navegación
shift.navigate
Lista → detalle. Página A → página B.
Lectura:
Principio
estoy en otro lugar.
Cambio de modo
shift.enter-mode
shift.exit-mode
Visualizar → editar. Normal → selección múltiple.
Lectura:
Principio
estoy en otro régimen.
Flujo paso a paso
shift.step
Paso 1 → paso 2 → paso 3.
Lectura:
Principio
avanzo en un proceso.
Cambio de contexto local
shift.context
Filtro activo, modo bulk, vista agrupada.
Lectura:
Principio
el significado del campo cambió.
6. Canales de `shift`
shift es altamente multicanal.
El foco es especialmente importante.
Principio
Si cambia el contexto, debe cambiar el foco.
7. Shift y familias relacionadas
Con `emerge`
emerge.open
shift.enter-mode
Diferencia:
- emerge → aparece algo;
- shift → cambia el sistema de acción.
Con `commit`
commit.submit + fulfill
shift.navigate
Una operación puede terminar y después llevar a otra vista.
Con `signal`
shift.enter-mode
signal.warn + threat
Un modal puede cambiar el marco y contener una advertencia.
8. Shift vs Emerge
Dropdown:
emerge.open
Modal:
shift.enter-mode
9. Ejemplos prácticos
Navegación
contact.press
shift.navigate
Modal
contact.press
shift.enter-mode
signal.warn + threat
Wizard
shift.step
Modo edición
shift.enter-mode
handle.edit
commit.save + affirm
shift.exit-mode
10. Accesibilidad
shift es crítico en accesibilidad.
Debe:
- mover foco;
- anunciar cambio;
- actualizar título;
- definir landmarks;
- permitir volver;
- evitar desorientación;
- bloquear correctamente lo que ya no es operativo.
Principio
Si el usuario no sabe dónde está, el shift falló.
11. Antipatrones
12. Síntesis
shift es la familia del cambio de contexto.
Comunica:
Tesis:
Principio
Shift redefine el espacio de acción del usuario.
Regla:
Principio
Todo cambio de contexto debe ser explícito y orientado.
Fig. 2 — Ambas superficies aparecen, pero solo una cambia el contexto.
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Canal
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Función
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Profundidad
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>nuevo plano
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Presencia
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>aparición del nuevo contexto
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Motion
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>transición orientadora
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Tiempo
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>duración suficiente
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Forma
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>estructura del nuevo estado
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Foco
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>punto de entrada
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Color
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>apoyo de modo
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Sonido
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>ocasional
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Propiedad
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Dropdown
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Modal
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Cambia contexto
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>no
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>sí
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Bloquea fondo
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>no
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>sí
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Requiere decisión
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>normalmente no
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>a menudo sí
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Foco cambia
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>local
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>dominante
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Problema
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Efecto
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>foco no cambia
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>confusión
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>título no cambia
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>desorientación
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>fondo activo
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>incoherencia
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>navegación invisible
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>pérdida
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>modo sin anuncio
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>acciones mal interpretadas
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Antipatrón
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Problema
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Todo es modal
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>exceso de cambio
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Cambio sin foco
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>desorientación
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Animación sin orientación
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>ruido
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Navegación sin contexto
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>pérdida
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Modal sin bloqueo
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>incoherencia
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Shift invisible
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>confusión
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Modo sin salida clara
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>ansiedad
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Dimensión
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Pregunta
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Contexto
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿dónde estoy?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Acción
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿qué puedo hacer?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Continuidad
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿de dónde vengo?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Orientación
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿cómo vuelvo?

## Capítulo 28
Sustain
Cuando algo sigue ocurriendo sin haber terminado
Hay eventos que no se resuelven en un instante.
El usuario pulsa guardar, pero el guardado tarda. Envía un archivo, pero la subida avanza lentamente. Abre una vista, pero los datos aún no llegan. Inicia una búsqueda, pero el sistema sigue procesando. Sincroniza un documento, pero todavía no hay resultado.
En todos esos casos, el evento principal no es todavía éxito, error, pérdida ni confirmación. Tampoco es simplemente contacto.
Algo está ocurriendo, pero aún no ha terminado.
Esa es la región de sustain.
La pregunta perceptiva de sustain es:
Principio
¿esto sigue ocurriendo?
O, dicho desde la experiencia del usuario:
Principio
¿el sistema sigue vivo o se ha quedado bloqueado?
1. Qué es `sustain`
Sustain es la familia semántica de la continuidad operativa.
Comunica que una operación, estado o proceso sigue activo aunque todavía no haya producido una consecuencia final.
Ejemplos:
sustain.start
sustain.progress
sustain.loading
sustain.waiting
sustain.syncing
sustain.streaming
sustain.processing
sustain.pending
sustain.end
Un spinner puede ser sustain. Una barra de progreso puede ser sustain. Un skeleton puede ser sustain. Un texto “guardando…” puede ser sustain. Un indicador de sincronización puede ser sustain.
Pero sustain no es el spinner. No es la barra. No es el skeleton. No es el texto.
Es la clase de evento que esos recursos intentan hacer perceptible:
Principio
una operación continúa sin haber llegado aún a su resultado.
2. Qué no es `sustain`
Sustain no es contact.
contact.press ≠ sustain.progress
contact confirma que el sistema recibió la acción. sustain confirma que la operación iniciada sigue viva.
Sustain no es commit.
sustain.progress ≠ commit.complete
Un proceso en curso no es culminación.
Sustain no es signal.
sustain.progress ≠ signal.warn
Un proceso no es alerta por el hecho de durar.
Sustain no es emerge.
emerge.present ≠ sustain.progress
Puede aparecer un indicador, pero la aparición no es el proceso.
3. Fundamento psicoperceptivo: continuidad temporal, incertidumbre y confianza
Sustain se apoya en una necesidad básica de la interacción:
Principio
cuando no hay resultado inmediato, el usuario necesita saber si el sistema sigue funcionando.
La ausencia de respuesta prolongada no se percibe como neutral. Se percibe como ambigua.
El usuario empieza a preguntarse:
¿se ha bloqueado?
¿lo he hecho mal?
¿debo esperar?
¿debo repetir?
¿perderé lo que estaba haciendo?
sustain reduce esa incertidumbre.
Trabaja con tres dimensiones:
1. Continuidad temporal
El usuario necesita percibir que el proceso no se ha detenido.
2. Predicción
Si hay progreso medible, el usuario puede anticipar el final.
3. Confianza operativa
Una señal proporcional permite sostener la confianza sin vigilancia constante.
Fig. 1 — Sin señal parece fallo; con demasiada señal parece amenaza.
Por eso sustain no es un detalle visual. Es una forma de mantener abierta una operación en la mente del usuario.
4. La pregunta perceptiva
Sustain responde:
Principio
¿esto sigue ocurriendo?
Y también:
¿está vivo?
¿está bloqueado?
¿avanza?
¿cuánto falta?
¿puedo hacer otra cosa?
¿puedo cancelar?
¿debo esperar?
5. Tipos de `sustain`
6. Canales de `sustain`
El texto es muchas veces el canal más honesto de sustain.
Un spinner sin texto dice:
Principio
algo pasa.
Un texto dice:
Principio
esto es lo que pasa.
7. Sustain e intent
Sustain normalmente no acepta intent por sí mismo.
Un proceso en curso no es positivo o negativo por estar en curso.
Puede volverse problemático, pero entonces se compone:
sustain.progress
signal.warn + risk
Puede terminar bien:
sustain.progress
commit.complete + fulfill
Puede fallar:
sustain.progress
commit.fail + risk
El intent aparece en la señal o en el resultado, no en la continuidad misma.
8. Sustain vs Commit
contact.press
sustain.progress
commit.save + affirm
Sustain mantiene abierta la operación. Commit la cierra.
Si el sistema muestra “guardado” mientras todavía está guardando, rompe la confianza. Si mantiene “guardando…” después de haber guardado, también.
9. Sustain vs Signal
Sustain acompaña.
Signal reclama atención.
Si un proceso tarda más de lo esperado:
sustain.processing
signal.warn + risk
Si falla:
commit.fail + risk
No todo proceso lento debe convertirse en alerta. Pero todo proceso que se aleja de las expectativas debe comunicarlo.
10. Ejemplos prácticos
Guardado remoto
contact.press
sustain.progress
commit.save + affirm
Subida de archivo
contact.press
sustain.progress
commit.complete + fulfill
Búsqueda
contact.submit
sustain.processing
emerge.present results
IA generando respuesta
contact.submit
sustain.streaming
commit.complete + affirm / fulfill
Sincronización offline
sustain.syncing
commit.save + affirm
o si falla:
sustain.syncing
commit.fail + risk
11. Accesibilidad
sustain debe ser accesible porque la espera genera incertidumbre.
La accesibilidad de sustain consiste en hacer soportable la espera.
12. Antipatrones
13. Síntesis
Sustain es la familia de la continuidad operativa.
No responde a:
¿se recibió mi acción?
Eso era contact.
No responde a:
¿ya terminó?
Eso será commit.
Responde a:
¿esto sigue ocurriendo?
Su función es mantener la confianza durante el intervalo entre acción y resultado.
Tesis:
Principio
Sustain mantiene abierta una operación sin convertirla todavía en resultado.
Regla principal:
Principio
Todo proceso que no termina de inmediato debe indicar que sigue vivo, sin parecer alarma ni celebración.

## Cierre de los capítulos 20–28
Con estos capítulos queda consolidado el bloque de coordinación y familias semánticas.
La teoría ya no se limita a nombrar siete palabras. Cada familia queda vinculada a:
- una pregunta perceptiva;
- un fundamento psicoperceptivo;
- una relación con intent;
- unos canales dominantes;
- ejemplos concretos;
- criterios de accesibilidad;
- antipatrones.
Esta revisión corrige el problema anterior: las semánticas ya no aparecen como fichas técnicas, sino como estructuras perceptivas del evento.
Fig. 2 — Sustain mantiene abierta la operación. Commit la cierra.
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="2412"/><w:gridCol w:w="2412"/><w:gridCol w:w="2412"/><w:gridCol w:w="2412"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Tipo
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Qué comunica
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Ejemplo
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Riesgo
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>`loading`
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>carga indeterminada
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>skeleton, spinner
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>bloqueo aparente
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>`progress`
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>avance medible
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>barra, porcentaje
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>progreso falso
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>`syncing`
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>alineación de estado
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>guardando en nube
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>confundir con commit
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>`processing`
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>cálculo interno
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>búsqueda, IA, exportación
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>opacidad
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>`streaming`
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>flujo continuo
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>respuesta en vivo
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>no distinguir final
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>`waiting`
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>dependencia externa
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>esperando servidor
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>frustración
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Canal
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Función
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Tiempo
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>sostener continuidad
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Presencia
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>mantener visible el estado
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Forma
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>representar proceso
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Motion
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>indicar actividad o avance
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Texto
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>explicar qué ocurre
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Color
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>bajo, como estado auxiliar
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Sonido
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>normalmente evitar
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Háptica
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>normalmente evitar
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Problema
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Riesgo
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Corrección
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>solo spinner
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>ambiguo
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>texto de estado
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>motion continuo
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>malestar
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>reduced motion
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>sin progreso
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>ansiedad
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>barra o explicación
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>sin cancelación
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>bloqueo
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>control del usuario
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>sin final claro
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>duda
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>commit visible
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>anuncios excesivos
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>ruido
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>live regions dosificadas
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>skeleton largo
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>sensación de vacío
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>mensaje o alternativa
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Antipatrón
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Qué falla
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Corrección
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>spinner eterno
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>ansiedad
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>progreso, texto, control
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>spinner sin texto
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>ambigüedad
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>estado explícito
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>progreso falso
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>desconfianza
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>progreso real o indeterminado
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>sustain como alarma
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>sobreactuación
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>neutralidad + signal si procede
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>resultado sin cierre
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>duda
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>commit claro
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>espera invisible
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>fallo percibido
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>indicador de continuidad
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>loop sonoro
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>fatiga
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>silencio
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Dimensión
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Pregunta
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Continuidad
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿sigue vivo?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Progreso
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿avanza?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Tiempo
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿debo esperar?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Estado
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿qué está haciendo?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Control
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿puedo cancelar o seguir?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Cierre
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿cuándo pasó a commit?

## CAPÍTULO 29

## Delegate

## Cuando el sistema actúa por el usuario
Las familias anteriores describen buena parte de las interfaces reactivas: el usuario actúa, el sistema responde, algo aparece, algo se sostiene, algo reclama atención, algo cambia de contexto o algo produce un resultado.
Pero muchas interfaces actuales introducen una pregunta adicional. El sistema ya no solo responde. Puede sugerir, planificar, generar, aplicar cambios, pedir revisión, esperar autorización o devolver el control.
En esos casos el usuario necesita saber algo muy concreto:
¿quién actúa ahora?
Esa pregunta no pertenece del todo a contact, commit, signal, handle, emerge, shift o sustain. Por eso esta gramática incorpora delegate.

## 1. Qué es delegate
Delegate es la familia de los eventos donde cambia quién lleva la iniciativa o quién ejecuta parte de la acción.
No es una familia de IA. Una IA puede producir eventos delegate, pero no todo evento delegate requiere IA. Una macro, un flujo automatizado, una regla programada, una aprobación delegada o un sistema de workflow también pueden producir delegate.
La pregunta de delegate es:
¿el usuario actúa directamente, el sistema actúa por él, o ambos comparten la acción?

## 2. Verbos principales
Los verbos de delegate describen momentos distintos del reparto de control:
delegate.offer      → el sistema ofrece encargarse de algo
delegate.plan       → el sistema propone un plan o curso de acción
delegate.authorize  → el usuario concede permiso o alcance
delegate.act        → el sistema actúa por el usuario
delegate.review     → el sistema espera revisión antes de aplicar
delegate.escalate   → el sistema pide intervención humana
delegate.return     → el control vuelve al usuario

## 3. Qué no es delegate
Delegate no es sustain. Sustain comunica que algo sigue ocurriendo. Delegate comunica quién actúa o bajo qué autorización.
Delegate no es signal. Signal reclama atención. Delegate puede pedir revisión, pero la reclamación de atención pertenece a signal.
Delegate no es commit. Commit comunica resultado. Delegate puede terminar en commit, pero no es el resultado.
Delegate no es shift. Shift cambia el contexto. Delegate cambia el reparto de acción dentro de ese contexto.

## 4. Delegate e intent
Delegate no tiene intent por defecto. Que el sistema actúe por el usuario no significa automáticamente que algo sea positivo, negativo, urgente o perdido.
El intent aparece cuando la acción delegada produce una señal, un resultado, un riesgo, una amenaza o una pérdida.
Ejemplos:
delegate.act
→ sustain.processing
→ commit.apply + affirm

delegate.review
→ signal.warn + risk

delegate.act
→ commit.fail + risk

delegate.act
→ commit.delete + loss

## 5. Casos no basados en IA
Un sistema de aprobación puede delegar una acción en otro usuario o rol.
Una regla automática puede archivar mensajes bajo condiciones definidas.
Una macro puede aplicar una secuencia de cambios en una herramienta profesional.
Un workflow puede ejecutar pasos cuando una tarea cambia de estado.
En todos esos casos lo importante no es la inteligencia del sistema. Lo importante es que la acción ya no está completamente en manos del usuario en ese instante.

## 6. Riesgos de diseño
Delegate es una familia delicada porque afecta control y responsabilidad. Si se expresa mal, el usuario puede no saber si el sistema solo sugiere, si ya está actuando, si espera autorización o si el resultado ya se aplicó.
Los errores más comunes son:
mostrar un loader genérico cuando el sistema está actuando por el usuario;
no explicar el alcance de la acción;
no ofrecer salida o cancelación;
no diferenciar sugerencia, plan, autorización y ejecución;
no dejar claro cuándo el control vuelve al usuario.

## 7. Resumen operativo
Qué es: delegate nombra los eventos donde cambia quién lleva la iniciativa o quién ejecuta parte de la acción.
Qué no es: no es IA, no es proceso, no es señal y no es resultado.
Para qué sirve: sirve para que el usuario entienda si actúa él, el sistema o ambos, y bajo qué autorización.
Regla de uso: usa delegate cuando el problema principal sea quién actúa, no simplemente qué se muestra o qué resultado se produjo.

## Síntesis
Delegate completa el sistema de familias al cubrir una región cada vez más importante: el reparto de acción entre usuario y sistema.
No aparece porque la IA esté de moda. Aparece porque muchas interfaces ya no solo esperan órdenes; también sugieren, planifican, ejecutan, escalan o devuelven control.
La gramática necesita hacer visible ese reparto.


## CAPÍTULO 30
Composición de eventos semánticos
Secuencias, reglas y solapamientos
Hasta ahora hemos separado.
Hemos separado familias semánticas:
contact
commit
signal
handle
emerge
shift
sustain
Hemos separado intents:
neutral
affirm
fulfill
risk
threat
loss
Hemos separado canales:
tiempo
motion
presencia
profundidad
forma
color
sonido
háptica
Esa separación era necesaria. Sin ella, todo se mezcla: un click parece éxito, un modal parece amenaza, un spinner parece error, una desaparición parece pérdida, una advertencia parece resultado.
Pero una interfaz real no ocurre por piezas aisladas.
El usuario no vive una familia semántica cada vez. Vive flujos. Pulsa. Espera. Recibe una señal. Corrige. Confirma. El sistema procesa. Algo queda fijado. Algo se pierde. Algo aparece como reparación. Algo cambia de marco.
Una interacción real suele ser una composición temporal de eventos semánticos.
La pregunta de este capítulo es:
PREGUNTA DEL CAPÍTULO
¿Cómo se combinan las familias semánticas sin que la interfaz pierda claridad?
Figura 29.1
1. Por qué necesitamos composición
Una familia semántica aislada explica un tipo de evento. Pero una operación de interfaz casi nunca es un solo evento.
Guardar no es solo commit.save. Eliminar no es solo commit.delete. Arrastrar no es solo handle.carry. Enviar un formulario no es solo submit. Abrir un modal no es solo shift.enter-mode. Cargar una vista no es solo sustain.loading.
Cada operación contiene fases. Por ejemplo, guardar un documento remoto puede componerse así:
contact.press → sustain.progress → commit.save + affirm
La pulsación fue recibida. El sistema trabajó. El resultado quedó guardado.
Si omitimos contact, el usuario duda si actuó. Si omitimos sustain, la espera parece bloqueo. Si omitimos commit, no hay cierre.
La operación no se entiende por un único efecto. Se entiende por la relación entre eventos.
DISTINCIÓN
Una interacción real no es una familia aislada. Es una composición temporal de eventos.
2. Secuencias básicas
Hay composiciones muy frecuentes.
2.1. ACCIÓN INMEDIATA CON RESULTADO SIMPLE
contact.press → commit.toggle + affirm
El usuario activa un switch. Lectura: me ha sentido → el estado quedó aplicado. No hace falta sustain si la operación es inmediata.
2.2. ACCIÓN CON PROCESO INTERMEDIO
contact.press → sustain.progress → commit.save + affirm
El usuario guarda cambios en servidor. Lectura: me ha sentido → sigue trabajando → quedó guardado.
2.3. ACCIÓN CON CULMINACIÓN
contact.press → sustain.progress → commit.complete + fulfill
El usuario exporta un vídeo, sube un archivo o completa un flujo importante. Lectura: me ha sentido → sigue procesando → objetivo cumplido. Aquí fulfill tiene más sentido que affirm, porque se resuelve una tensión o meta.
2.4. ACCIÓN DESTRUCTIVA CON ADVERTENCIA
contact.press → signal.warn + threat → commit.delete + loss
El usuario elimina un proyecto. Lectura: me ha sentido → puedo evitar una consecuencia grave → algo dejó de estar disponible. La amenaza vive antes de la pérdida. La pérdida vive después de la consecuencia.
2.5. ELIMINACIÓN CON REPARACIÓN
signal.warn + threat → commit.delete + loss → emerge.present undo
El usuario confirma eliminar una tarjeta y aparece una barra de deshacer. Lectura: puedes evitarlo → ya se perdió → puedes repararlo temporalmente. El undo no borra la pérdida. La recontextualiza como parcialmente reversible.
2.6. MANIPULACIÓN DIRECTA
contact.press → handle.pick → handle.carry → handle.drop → commit.reorder + affirm
El usuario reordena una lista. Lectura: me ha sentido → lo agarro → lo controlo → lo suelto → quedó reordenado.
3. Las reglas no son dogmas
Las reglas de composición no deberían parecer mandamientos arbitrarios.
No decimos que contact va antes de commit porque sí. Decimos que si el usuario actúa, necesita primero percibir que su acción fue recibida antes de poder interpretar el resultado.
No decimos que threat debe ir antes de loss porque lo dice la taxonomía. Decimos que una amenaza convoca acción antes de la consecuencia; una pérdida registra consecuencia después.
No decimos que sustain debe terminar en commit. Decimos que un proceso abierto necesita algún tipo de cierre, resultado, cancelación, fallo o persistencia explicada.
Cada regla debe derivarse de una necesidad perceptiva.
4. Reglas de composición
REGLA 1 — CONTACT PRECEDE AL RESULTADO CUANDO HAY ACCIÓN DIRECTA
Si el usuario actúa directamente, la interfaz debe comunicar recepción antes de comunicar consecuencia.
contact.press → commit.save + affirm
Fundamento: agencia, causalidad acción-respuesta, reducción de duda.
Error: commit.save + affirm sin contacto perceptible. El usuario puede no saber si la acción fue registrada o si el estado cambió por otra razón.
REGLA 2 — SUSTAIN PRECEDE AL COMMIT CUANDO HAY ESPERA
Si la operación no termina de inmediato, debe sostenerse antes de resolverse.
contact.press → sustain.progress → commit.complete + fulfill
Fundamento: continuidad temporal, reducción de incertidumbre, mantenimiento de confianza.
Error: contact.press → silencio → commit.complete + fulfill. La operación puede funcionar técnicamente, pero la espera se percibe como bloqueo.
REGLA 3 — THREAT PRECEDE A LOSS
Threat vive antes o durante una posible consecuencia. Loss vive después.
signal.warn + threat → commit.delete + loss
Fundamento: temporalidad de la evaluación, espacio valencia/activación, diferencia entre prevenir y registrar.
Error: commit.delete + threat. Después de la eliminación, ya no hay nada que evitar. La amenaza se vuelve disonante.
REGLA 4 — EMERGE NO DEBE ABSORBER EL INTENT DEL CONTENIDO
Una superficie puede aparecer sin ser evaluable.
emerge.open → signal.warn + risk
Fundamento: figura/fondo, evento estructural vs evento evaluable, marco ≠ mensaje.
Error: emerge.open + risk. La apertura no es el riesgo. El riesgo está en el mensaje que aparece.
REGLA 5 — SHIFT DEBE ORIENTAR EL CAMBIO DE CONTEXTO
Cuando cambia el contexto, el usuario necesita orientación. shift.enter-mode debe acompañarse de foco, título, profundidad, estructura y salida clara.
Fundamento: cambio de modelo operativo, orientación espacial/cognitiva, gestión de foco.
Error: un modal aparece visualmente, pero el foco permanece detrás.
REGLA 6 — HANDLE CONCENTRA EVALUACIÓN EN EL DROP
Durante handle.carry, el usuario está controlando. La evaluación aparece sobre todo al soltar.
handle.pick → handle.carry → handle.drop + risk
Fundamento: control motor continuo, separación entre manipulación y resultado, economía atencional.
Error: hacer que todo el carry parezca amenaza porque el usuario pasa cerca de una zona destructiva. Mejor: handle.carry + signal.warn + threat solo cuando la zona destructiva se vuelve destino probable.
REGLA 7 — TODO PROCESO ABIERTO NECESITA SALIDA
Un sustain no puede quedar suspendido indefinidamente sin cambio de estado. Posibles salidas: commit.complete + fulfill, commit.save + affirm, commit.fail + risk, signal.warn + risk, commit.cancel + neutral.
Fundamento: cierre cognitivo, confianza, memoria de estado.
Error: spinner eterno.
5. Ejemplo largo: subida con fallo parcial y recuperación
Veamos una composición más compleja.
El usuario sube un archivo grande para enviarlo a revisión. Durante la subida, la conexión falla parcialmente. El sistema conserva parte del progreso, muestra una advertencia y permite reintentar. El usuario reintenta y la subida termina correctamente.
5.1. ACCIÓN INICIAL
contact.press — el usuario pulsa "Subir". Canales: respuesta inmediata, estado pressed, micro motion opcional.
5.2. SUBIDA EN CURSO
sustain.upload — el sistema empieza a subir. Canales: barra de progreso, texto "Subiendo archivo…", presencia persistente, baja saliencia.
5.3. ADVERTENCIA CORREGIBLE
signal.warn + risk — la conexión se interrumpe parcialmente. No es threat si no hay urgencia inmediata. No es loss si no se perdió definitivamente. Canales: callout, color moderado de advertencia, texto descriptivo, presencia persistente.
5.4. REINTENTO AUTOMÁTICO O DISPONIBLE
sustain.retrying — el sistema intenta continuar. Canales: indicador de reintento, texto "Reintentando…", baja saliencia.
5.5. RESULTADO PARCIAL
commit.partial + risk — parte de la operación no se completó. Este commit no es fulfill ni loss completo. Es un resultado problemático, corregible. Canales: estado de progreso parcial, mensaje descriptivo, color de advertencia.
5.6. APARICIÓN DE RECUPERACIÓN
emerge.present recovery — aparece una opción de reintentar o continuar. La aparición no es el riesgo. La opción emergente ofrece reparación. Canales: botón de reintentar, presencia clara.
5.7. REINTENTO DEL USUARIO
contact.press → sustain.progress — el usuario pulsa "Reintentar". El sistema vuelve a trabajar. Canales: barra de progreso restaurada, texto "Subiendo…".
5.8. CIERRE POSITIVO
commit.complete + fulfill — la subida termina. Aquí fulfill tiene sentido porque había tensión, espera y recuperación. Canales: motion resolutivo, marca de completado, color positivo, sonido breve opcional.
6. Eventos simultáneos y solapados
Hasta ahora hemos hablado de secuencias lineales. Pero una interfaz real también tiene simultaneidad.
Un proceso puede seguir en curso mientras aparece una advertencia:
sustain.progress + signal.warn + risk
Un usuario puede estar arrastrando mientras se aproxima a una zona destructiva:
handle.carry + signal.warn + threat
Un modal puede cambiar el marco mientras dentro aparece una señal:
shift.enter-mode + signal.alert + threat
Un sistema puede estar sincronizando mientras muestra un estado parcial:
sustain.syncing + commit.partial + risk
Una notificación puede llegar mientras el usuario está manipulando un objeto:
handle.carry + signal.notify + neutral
La composición no siempre es una cadena. A veces es una superposición.
7. Regla de dominancia atencional
Cuando dos eventos se solapan, uno debe dominar la atención y el otro debe mantenerse como contexto.
La jerarquía de dominancia sigue tres criterios:
El evento evaluable domina sobre el estructural. Un signal.warn + risk que aparece durante un sustain.progress debe convertirse en figura. El proceso queda como contexto.
El evento con mayor activación domina sobre el de menor activación. Un signal.alert + threat domina sobre un signal.notify + neutral. La amenaza reclama atención; la notificación espera.
El evento más reciente domina sobre el anterior cuando ambos son del mismo nivel. Si durante un sustain.progress aparece un commit.partial + risk, el resultado parcial toma prioridad sobre el indicador de proceso.
Ejemplo:
sustain.progress + signal.warn + risk
El proceso sigue, pero la advertencia debe ser figura. Lectura correcta: el sistema sigue trabajando, pero hay algo que revisar. No: el proceso falló completamente.
Otro ejemplo:
handle.carry + signal.warn + threat
El usuario sigue manipulando, pero la zona destructiva reclama atención. Lectura correcta: sigues controlando el objeto, pero si lo sueltas ahí habrá consecuencia.
Otro ejemplo:
handle.carry + signal.notify + neutral
El usuario está arrastrando y llega una notificación del sistema. Handle domina porque el usuario está en control motor activo. La notificación no debe interrumpir ni reclamar foco. Debe esperar o aparecer sin competir con la manipulación.
8. Jerarquía dentro de una composición
Una composición necesita jerarquía. No todos los eventos deben expresarse con la misma intensidad.
En una operación larga:
contact.press → sustain.progress → commit.complete + fulfill
Contact debe ser inmediato y discreto. Sustain debe sostener sin fatigar. Commit debe cerrar con claridad. Si los tres tienen la misma energía, la secuencia se vuelve plana.
En una operación destructiva:
signal.warn + threat → commit.delete + loss → emerge.present undo
Threat debe destacar antes. Loss debe registrar después. Undo debe permanecer como reparación, sin parecer otra amenaza.
La jerarquía se establece mediante tres principios:
El evento evaluable recibe más intensidad que el estructural. Commit.complete + fulfill merece más energía perceptiva que el sustain que lo precedió. Signal.warn + threat merece más saliencia que el emerge.open que lo contiene.
El evento con mayor activación recibe más intensidad que el de menor activación. Un threat necesita más saliencia que un affirm. Un fulfill necesita más resolución que un neutral. Un loss necesita más gravedad que un risk.
El evento de cierre recibe más presencia que los intermedios. En contact → sustain → commit, el commit es el cierre. Debe ser el momento perceptivo más claro de la secuencia. El sustain acompaña. El contact inicia.
Cuando todos los eventos compiten por la misma atención, la composición se convierte en ruido. Cuando están bien graduados, la secuencia se lee como una historia perceptiva coherente.
9. Antipatrones de composición
9.1. COMMIT ANTICIPADO
La interfaz muestra éxito antes de terminar.
contact.press → commit.complete + fulfill → sustain.progress
Problema: promete resultado antes de que exista. Corrección: contact.press → sustain.progress → commit.complete + fulfill.
9.2. THREAT DESPUÉS DE LOSS
commit.delete + loss → signal.alert + threat
Problema: comunica urgencia cuando ya no hay prevención posible. Corrección: signal.warn + threat → commit.delete + loss.
9.3. EMERGE COMO ALERT
Un dropdown aparece con la energía de una alerta.
Problema: aparición local se confunde con señal urgente. Corrección: emerge.open sin intent, salvo que contenga un signal.
9.4. SUSTAIN SIN SALIDA
Un spinner queda indefinido.
Problema: proceso sin cierre. Corrección: sustain.progress → commit.complete / commit.fail / signal.warn / cancel.
9.5. HANDLE EVALUADO TODO EL TIEMPO
Todo el arrastre está teñido de amenaza.
Problema: el usuario pierde sensación de control. Corrección: mantener carry neutro y señalizar solo destinos o drop.
9.6. NOTIFICACIÓN QUE INTERRUMPE MANIPULACIÓN
Una notificación reclama foco mientras el usuario arrastra.
Problema: rompe el control motor activo. Corrección: la notificación espera o aparece sin competir con handle.
10. Síntesis
La composición convierte familias aisladas en interacción real.
Una interfaz no debe preguntarse solo: ¿qué evento es este?
También debe preguntarse: ¿qué ocurrió antes? ¿qué viene después? ¿qué evento domina la atención? ¿qué evento queda como contexto? ¿qué resultado cierra la secuencia? ¿qué huella queda?
DISTINCIÓN
Una interacción real no es una familia aislada. Es una composición temporal de eventos semánticos.
PRINCIPIO
Toda composición debe preservar la pregunta perceptiva de cada evento sin hacerlos competir innecesariamente.
La composición es donde la gramática deja de ser vocabulario y empieza a comportarse como lenguaje.
Figura 29.2
Figura 29.3
Figura 29.4
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>OPERACIÓN
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>SECUENCIA SEMÁNTICA
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>LECTURA
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Activar switch
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>contact.press → commit.toggle + affirm
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>acción recibida, estado aplicado
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Guardar remoto
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>contact.press → sustain.progress → commit.save + affirm
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>acción, proceso, cierre
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Completar flujo
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>contact.press → sustain.progress → commit.complete + fulfill
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>acción, espera, objetivo cumplido
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Eliminar
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>contact.press → signal.warn + threat → commit.delete + loss
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>acción, advertencia, pérdida
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Deshacer eliminación
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>commit.delete + loss → emerge.present undo
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>pérdida con reparación temporal
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Reordenar
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>contact.press → handle → commit.reorder + affirm
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>agarre, control, resultado
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>REGLA
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>FUNDAMENTO
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>contact precede a resultado
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>agencia y causalidad
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>sustain precede a commit si hay espera
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>continuidad temporal
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>threat precede a loss
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>antes/después de consecuencia
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>emerge no absorbe intent
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>figura/fondo; marco ≠ mensaje
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>shift debe orientar
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>cambio de modelo operativo
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>handle.drop concentra evaluación
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>control continuo vs resultado
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>sustain necesita salida
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>cierre cognitivo
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="2412"/><w:gridCol w:w="2412"/><w:gridCol w:w="2412"/><w:gridCol w:w="2412"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>MOMENTO
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>FAMILIA
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>INTENT
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>LECTURA
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Pulsar subir
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>contact.press
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>—
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>el sistema me ha sentido
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Subiendo
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>sustain.upload
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>—
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>sigue trabajando
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Problema de red
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>signal.warn
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>risk
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>hay algo corregible
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Reintento
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>sustain.retrying
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>—
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>intenta recuperarse
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Resultado parcial
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>commit.partial
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>risk
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>algo quedó incompleto
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Opción de recuperación
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>emerge.present recovery
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>—
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>aparece una reparación
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Reintentar
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>contact.press
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>—
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>recibió mi acción
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Subida completada
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>commit.complete
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>fulfill
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>objetivo cumplido
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>CRITERIO
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>REGLA
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Evaluabilidad
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>lo evaluable domina sobre lo estructural
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Activación
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>lo más activado domina sobre lo menos activado
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Recencia
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>si el nivel es similar, domina lo más reciente
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>COMPOSICIÓN
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>EVENTO DE CONTEXTO
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>EVENTO DOMINANTE
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>sustain.progress + signal.warn
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>proceso en curso
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>advertencia
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>handle.carry + signal.threat
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>manipulación
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>zona peligrosa
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>shift.enter-mode + signal.alert
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>nuevo marco
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>alerta interna
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>sustain.syncing + commit.partial
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>sincronización
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>resultado parcial
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>emerge.present + signal.notify
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>aparición
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>mensaje del sistema
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>handle.carry + signal.notify
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>manipulación activa
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>handle domina, notificación espera

## CAPÍTULO 31
Matrices semánticas
Familias, intents y canales
El capítulo anterior mostró que una interacción real no suele ser una familia aislada. Una operación de interfaz encadena eventos: contacto, proceso, señal, consecuencia, aparición, cambio de contexto o manipulación. La gramática se vuelve útil cuando permite leer esas secuencias sin confundirlas.
Pero para diseñar, revisar o documentar una interfaz hace falta otro paso.
No basta con saber que existe contact, commit, signal, handle, emerge, shift, sustain, delegate y delegate. Tampoco basta con saber que existen neutral, affirm, fulfill, risk, threat y loss.
Hay que saber qué canales expresan mejor cada familia y cómo cambia esa expresión cuando aparece un intent.
Este capítulo introduce dos herramientas: la matriz de familias × canales y la matriz de intents × canales. No son tablas cerradas ni recetas universales. Son mapas de decisión.
PREGUNTA DEL CAPÍTULO
¿Qué canal debe dominar cada evento y qué función cumple en él?
1. Para qué sirve una matriz semántica
Una matriz semántica convierte la teoría en una herramienta de trabajo. Permite pasar de frases generales como "este evento necesita feedback" a preguntas más precisas: ¿es contact o commit? ¿hay proceso intermedio? ¿hay intent evaluativo? ¿el canal dominante debe ser tiempo, motion, forma, presencia o sonido? ¿qué ocurre si el usuario reduce motion? ¿qué queda después del evento?
Por ejemplo, un botón "Guardar" no debería resolverse diciendo "añade una animación de success." Sino: contact.press → sustain.progress si hay espera → commit.save + affirm. Y entonces la matriz ayuda a decidir: contact.press necesita tiempo y micro motion; sustain.progress necesita presencia, texto y progreso; commit.save + affirm necesita marca discreta, quizá color suave, quizá sonido opcional.
La matriz obliga a separar lo que muchas veces se decide junto.
PRINCIPIO
Una matriz semántica no dice qué efecto usar. Dice qué función debe cumplir cada canal dentro del evento.
2. Cómo leer las matrices
Las matrices de este capítulo no usan solo valores como "alto", "medio" o "bajo". Esa forma puede ser útil, pero es insuficiente. Decir que motion es "alto" en contact no explica qué hace motion ahí. Es mejor decir: motion en contact → causalidad inmediata. Decir que color es "alto" en signal tampoco basta. Es mejor decir: color en signal → saliencia y valencia.
Por eso las celdas de estas matrices describen función, no solo intensidad. La pregunta para cada celda es: ¿qué aporta este canal a esta familia o intent?
3. Matriz de familias y canales
La primera matriz cruza las ocho familias semánticas con los canales de expresión principales. No pretende decir que todos los eventos de una familia usen siempre los mismos canales. Pretende mostrar qué canales suelen dominar y qué función suelen cumplir.
4. Lectura por familia
4.1. CONTACT
Contact depende principalmente del tiempo. Si la respuesta llega tarde, pierde su función aunque el motion sea bonito. El canal dominante es la latencia: el usuario debe percibir que el sistema ha sentido su acción. Motion puede ayudar mediante microcompresión o respuesta breve. Forma puede reforzar con un estado pressed. Sonido y háptica son opcionales.
Función dominante: tiempo + motion → agencia inmediata.
Riesgo: convertir cada contacto en espectáculo, sonido o vibración.
4.2. COMMIT
Commit necesita dejar huella. No basta con que algo cambie por un instante. El usuario debe percibir que algo quedó fijado, resuelto, eliminado, cancelado o restaurado. Motion puede comunicar asentamiento o retirada. Forma y presencia sostienen el estado. Color puede reforzar intent. Sonido o háptica pueden marcar cierre en eventos relevantes.
Función dominante: forma + presencia + motion → consecuencia perceptible.
Riesgo: commit efímero sin huella, o sobrecelebración de acciones rutinarias.
4.3. SIGNAL
Signal necesita entrar en la atención. Sus canales fuertes son presencia, forma, color y texto. El sonido puede ser útil cuando la señal debe alcanzar al usuario fuera del foco visual. Motion puede introducir o enfatizar, pero debe dosificarse.
Función dominante: presencia + forma + texto + color → atención orientada.
Riesgo: depender solo de color o convertir todo en alerta.
4.4. HANDLE
Handle requiere baja latencia, continuidad y profundidad. Motion es central porque sostiene el control. Profundidad indica que el objeto salió del flujo normal. Forma define objeto, grip y zonas destino. Color puede indicar válido/inválido, pero no debe dominar el carry.
Función dominante: motion + profundidad + forma → control directo.
Riesgo: perder agencia por lag, destino ambiguo o falta de alternativa accesible.
4.5. EMERGE
Emerge necesita hacer legible la entrada o salida de algo en el campo perceptivo. Presencia y motion son centrales. Profundidad ayuda si la superficie flota. Forma define el tipo de superficie. Color, sonido y háptica suelen ser secundarios.
Función dominante: presencia + motion + forma → aparición reconocible.
Riesgo: que una aparición local se sienta como alerta o como cambio de contexto.
4.6. SHIFT
Shift necesita orientar un cambio de contexto. Sus canales principales son profundidad, presencia, foco, estructura y motion. Color puede reforzar modo activo. Sonido y háptica son raros.
Función dominante: profundidad + foco + estructura → cambio de contexto.
Riesgo: que el usuario no sepa dónde está, qué cambió o cómo volver.
4.7. SUSTAIN
Sustain necesita sostener continuidad sin fatigar. El canal principal es el tiempo. Presencia mantiene visible el estado. Forma representa proceso. Motion puede indicar actividad pero debe ser de baja demanda. Sonido y háptica deben evitarse.
Función dominante: tiempo + presencia + forma → proceso vivo.
Riesgo: spinner eterno, espera silenciosa o sustain que parece alarma.
5. Matriz de intents y canales
La segunda matriz cruza los intents con los canales. Aquí la pregunta cambia. Ya no preguntamos qué familia es, sino cómo debe evaluarse afectivamente este evento. Los intents no definen el evento. Lo modulan. Por eso esta matriz no se usa sola. Siempre debe leerse junto a una familia.
6. Lectura por intent
neutral — ausencia de juicio afectivo fuerte, no ausencia de estructura. Puede necesitar forma y texto, pero no carga intensa de color, sonido o motion. Riesgo: hacer invisible lo que necesita ser notado.
affirm — confirma suavemente, baja activación positiva. Marca ligera, color discreto, asentamiento breve. No es "objetivo logrado," es "todo va bien." Riesgo: celebrar lo rutinario.
fulfill — resolución positiva, mayor activación que affirm porque cierra una tensión. Motion resolutivo, color positivo visible, sonido ascendente opcional. Riesgo: trivializar el logro o convertirlo en espectáculo.
risk — problema corregible, región negativa moderada. Callout local, color de advertencia, icono, texto, persistencia hasta corrección. Dice "revisa esto," no "actúa ahora." Riesgo: expresarlo como amenaza.
threat — amenaza activa, alta activación negativa. Presencia dominante, alta saliencia, forma crítica, sonido opcional. Dice "atiende ahora." Riesgo: usarlo para todo y destruir su fuerza.
loss — pérdida consumada, comparte valencia negativa con threat pero con menor activación y distinta temporalidad. Retirada, ausencia, huella, undo, color grave. Dice "esto ya se perdió," no alarma sostenida. Riesgo: hacerlo sonar como amenaza cuando ya no hay prevención posible.
Figura 30.1
7. Cómo usar las matrices juntas
Las dos matrices deben cruzarse. No basta con elegir familia. No basta con elegir intent. La lectura final surge de la combinación.
Ejemplo: commit.save + affirm. Familia commit pide huella, cierre, estado persistente. Intent affirm pide baja activación, confirmación suave, poca saliencia. Resultado: marca discreta de guardado, color positivo bajo, sin sonido por defecto, motion mínimo.
Otro ejemplo: signal.alert + threat. Familia signal pide atención, presencia, texto, forma clara. Intent threat pide alta activación, urgencia, acción inmediata. Resultado: presencia dominante, forma crítica, texto claro, color saliente, sonido opcional, persistencia hasta acción.
Figura 30.2
Otro ejemplo: commit.delete + loss. Familia commit pide consecuencia, huella, cierre. Intent loss pide gravedad, baja activación relativa, ausencia significativa. Resultado: retirada del objeto, mensaje de pérdida, undo si existe, color grave/desaturado, sin alarma sostenida.
8. Celdas prohibidas o raras
No todas las combinaciones tienen el mismo sentido.
emerge.open + threat — normalmente incorrecta. La amenaza está en el contenido o señal, no en la apertura. Mejor: emerge.open → signal.warn + threat.
sustain.progress + fulfill — normalmente incorrecta. El proceso no es el resultado. Mejor: sustain.progress → commit.complete + fulfill.
handle.carry + loss — normalmente incorrecta. La pérdida se produce en el resultado, no en el carry. Mejor: handle.drop → commit.delete + loss.
contact.press + fulfill — normalmente incorrecta. El contacto no es culminación. Mejor: contact.press → sustain.progress → commit.complete + fulfill.
9. Matrices y accesibilidad
Las matrices también sirven para revisar accesibilidad. Si un evento depende de un solo canal, la matriz lo revela.
signal.warn + risk — si solo se expresa con color amarillo, falta forma, texto, persistencia, icono, relación con el campo.
commit.select + affirm — si solo se expresa con color verde, falta check, borde, estado persistente, forma seleccionada.
sustain.progress — si solo se expresa con spinner, falta texto, estado, quizá progreso real, anuncio controlado.
La matriz obliga a preguntar: ¿qué canal domina? ¿qué canal respalda? ¿qué canal falla? ¿qué canal sobra?
10. Antipatrones de matriz
10.1. USAR TODOS LOS CANALES PORQUE LA MATRIZ LOS MENCIONA
La matriz no obliga a activar todo. Muestra posibilidades y funciones. La matriz también sirve para quitar: si un commit.save + affirm ya tiene marca visual persistente y color positivo, añadir sonido, háptica y motion resolutivo probablemente sobra. La pregunta no es solo "¿qué canal puedo añadir?" sino también "¿qué canal puedo omitir sin perder la lectura?"
10.2. INTERPRETAR LA MATRIZ COMO RECETA FIJA
Cada contexto modifica la decisión. Una app médica, una herramienta creativa y un dashboard financiero no deberían modular igual.
10.3. CONFUNDIR CANAL DOMINANTE CON CANAL ÚNICO
Dominante no significa exclusivo.
10.4. USAR INTENT SIN FAMILIA
risk no dice qué ocurrió. Necesitamos: signal.warn + risk, commit.fail + risk o handle.drop + risk.
10.5. USAR FAMILIA SIN CANAL SUFICIENTE
commit.delete + loss sin huella, sin texto ni ausencia significativa, puede no entenderse.
11. Síntesis
Las matrices semánticas convierten la teoría en herramienta.
La matriz de familias responde: ¿qué tipo de evento es y qué canales suelen hacerlo legible?
La matriz de intents responde: ¿cómo debe evaluarse el evento y qué modulación perceptiva necesita?
Usadas juntas, permiten pasar de una decisión vaga como "pon feedback de success" a una decisión semántica: commit.save + affirm → huella discreta → color positivo leve → sin sonido por defecto → persistencia breve.
PRINCIPIO
Una matriz semántica no prescribe efectos. Organiza funciones perceptivas.
PRINCIPIO
No preguntes primero qué canal usar. Pregunta qué evento debe percibirse y qué función debe cumplir cada canal.
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="1206"/><w:gridCol w:w="1206"/><w:gridCol w:w="1206"/><w:gridCol w:w="1206"/><w:gridCol w:w="1206"/><w:gridCol w:w="1206"/><w:gridCol w:w="1206"/><w:gridCol w:w="1206"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>FAMILIA
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>TIEMPO
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>MOTION
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>PRESENCIA / PROFUNDIDAD
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>FORMA
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>COLOR
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>SONIDO
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>HÁPTICA
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>contact
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>causalidad inmediata
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>microrespuesta al gesto
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>casi nula
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>estado pressed / foco
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>secundario
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>click opcional
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>pulso breve
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>commit
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>momento de cierre
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>asentamiento / retirada
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>huella o consecuencia
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>marca persistente
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>refuerzo evaluativo
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>cierre opcional
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>impacto / encaje
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>signal
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>persistencia suficiente
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>entrada o énfasis
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>figura atencional
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>callout / badge / alerta
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>saliencia y valencia
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>fuera de foco
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>alerta corporal
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>handle
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>baja latencia
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>seguimiento continuo
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>elevación / plano activo
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>grip / zona destino
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>válido / inválido
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>pick/drop opcional
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>pick/drop
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>emerge
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>entrada y salida
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>origen / retirada
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>presencia local
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>superficie / contenedor
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>apoyo menor
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>normalmente no
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>normalmente no
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>shift
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>transición orientadora
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>cruce de marco
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>plano dominante / fondo
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>estructura del nuevo contexto
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>modo o estado
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>raro
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>raro
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>sustain
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>continuidad
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>actividad o progreso
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>estado persistente
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>barra / skeleton / indicador
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>bajo
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>evitar loop
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>evitar
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="1206"/><w:gridCol w:w="1206"/><w:gridCol w:w="1206"/><w:gridCol w:w="1206"/><w:gridCol w:w="1206"/><w:gridCol w:w="1206"/><w:gridCol w:w="1206"/><w:gridCol w:w="1206"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>INTENT
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>TIEMPO
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>MOTION
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>PRESENCIA
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>FORMA
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>COLOR
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>SONIDO
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>HÁPTICA
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>neutral
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>funcional
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>mínimo
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>baja
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>estructura clara
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>sin carga
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>normalmente no
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>normalmente no
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>affirm
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>breve
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>asentamiento suave
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>baja / discreta
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>marca ligera
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>positivo discreto
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>breve opcional
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>pulso suave
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>fulfill
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>cierre más marcado
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>resolución visible
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>media
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>final claro
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>positivo claro
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>ascendente breve
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>pulso definido
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>risk
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>persistente
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>tensión moderada
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>local y estable
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>callout / borde / icono
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>advertencia moderada
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>seco contenido
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>pulso contenido
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>threat
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>entrada rápida
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>saliente / tenso
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>dominante
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>bloque crítico
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>alta saliencia
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>urgente opcional
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>vibración fuerte
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>loss
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>breve + huella
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>retirada / descenso
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>ausencia visible
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>undo / registro / tachado
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>grave / desaturado
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>seco / grave
<w:tcPr><w:tcW w:type="dxa" w:w="1206"/></w:tcPr><w:p><w:r><w:t>pulso seco
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>COMBINACIÓN
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>PROBLEMA
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>ALTERNATIVA
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>emerge.open + threat
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>evalúa el marco, no el contenido
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>emerge.open → signal.warn + threat
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>sustain.progress + fulfill
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>confunde proceso y resultado
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>sustain.progress → commit.complete + fulfill
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>contact.press + loss
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>confunde recepción y consecuencia
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>contact.press → commit.delete + loss
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>handle.carry + loss
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>evalúa antes del drop
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>handle.drop → commit.delete + loss
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>shift.enter-mode + risk
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>evalúa el cambio de contexto
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>shift.enter-mode → signal.warn + risk

## CAPÍTULO 32
Rangos psicoperceptivos orientativos
Duración, intensidad, persistencia y fatiga
El capítulo anterior convirtió las familias, intents y canales en matrices de decisión.
Pero una matriz todavía deja abierta una pregunta práctica:
PREGUNTA DEL CAPÍTULO
¿Cuánto debe durar, persistir o intensificarse cada evento para conservar su lectura?
Cuánto debe durar un contact.press. Cuánta presencia necesita un signal.warn + risk. Cuánta intensidad puede tener un signal.alert + threat. Cuánto tiempo debe permanecer un undo. Cuánto motion empieza a fatigar. Cuándo un sustain.progress deja de tranquilizar y empieza a desesperar. Cuándo un sonido breve ayuda y cuándo invade.
Esta pregunta es peligrosa. Si damos valores demasiado concretos, caemos en falsa precisión. Si no damos ninguno, dejamos al lector igual que antes.
Por eso este capítulo no propone leyes. Propone rangos psicoperceptivos orientativos. Un rango no dice "usa siempre 120 ms." Dice algo más útil: esta clase de evento suele necesitar una temporalidad breve para preservar su función perceptiva. O: esta señal debe persistir mientras el usuario pueda actuar sobre ella. O: esta intensidad debe mantenerse baja porque el evento ocurre con mucha frecuencia.
Los rangos son regiones de diseño, no números sagrados.
1. Por qué hablar de rangos
La semántica perceptiva no solo depende de qué canal usamos. También depende de cuánto lo usamos.
Un motion correcto puede fallar por exceso de duración. Un color adecuado puede fallar por exceso de saturación. Una señal necesaria puede fallar por desaparecer demasiado pronto. Un sonido útil puede fallar por repetirse demasiado. Un loader puede fallar por durar sin explicar nada. Una vibración puede fallar por ser demasiado intensa o demasiado frecuente.
El canal no trabaja solo por presencia o ausencia. Trabaja por intensidad, duración, ritmo, persistencia, frecuencia y contexto.
DISTINCIÓN
Un rango psicoperceptivo no es una ley. Es una zona en la que un evento conserva mejor su lectura.
2. Fundamento: umbrales, atención y fatiga
Los rangos se apoyan en tres ideas ya desarrolladas en la Parte II.
2.1. VENTANAS DE PERCEPCIÓN
El Capítulo 12 explicó que el tiempo modifica la lectura del evento. Una respuesta muy próxima a la acción se percibe como contacto. Una respuesta más tardía se percibe como reacción. Una espera prolongada exige señal explícita. Por eso contact necesita vivir cerca del gesto.
2.2. ACTIVACIÓN ATENCIONAL
Los intents tienen distinta activación. Affirm es positivo y bajo en activación. Fulfill es positivo y más resolutivo. Risk es negativo moderado. Threat es negativo de alta activación. Loss es negativo, pero no necesariamente urgente. Por eso no todos deben tener la misma intensidad, duración o persistencia.
2.3. FATIGA SENSORIAL
Un canal puede funcionar bien una vez y volverse insoportable por repetición. Un sonido de confirmación puede ser agradable una vez y molesto cincuenta veces. Una microvibración puede reforzar contacto en un gesto aislado y fatigar en un teclado. Un motion de éxito puede resultar expresivo una vez y ridículo si ocurre cada minuto. La frecuencia modifica el rango aceptable.
Figura 31.1
3. Rangos temporales orientativos
No hay valores universales, pero sí regiones útiles.
Lo importante no es memorizar la tabla. Es entender la lógica. Un contact demasiado largo deja de ser contacto. Un signal.warn + risk demasiado breve no permite corregir. Un sustain.progress sin continuidad parece bloqueo. Un loss sin huella puede parecer simple desaparición.
4. Contact: el rango de la agencia
Contact es la familia más sensible al tiempo. Su pregunta es: ¿el sistema ha sentido mi acción? Para responder, debe ocurrir dentro de la ventana de atribución causal descrita en el Capítulo 12. No necesita durar mucho. Necesita empezar pronto.
Un buen contact.press puede ser casi instantáneo y muy breve: estado pressed, microcompresión, cambio de foco, pulso háptico leve, click opcional. Su función no es expresar belleza. Es preservar agencia.
Si el sistema no puede ejecutar la operación inmediatamente, debe al menos responder al contacto y después sostener el proceso: contact.press → sustain.progress → commit.save + affirm.
Antipatrón: silencio → commit.save + affirm. El sistema puede haber funcionado, pero el usuario no percibe agencia.
5. Commit: el rango del cierre
Commit necesita una señal de cierre. No debe ser tan breve que pase desapercibida. No debe ser tan larga que teatralice el resultado. La duración depende del intent.
commit.save + affirm — confirmación suave, breve, discreta, baja activación. Lectura: guardado, puedes seguir.
commit.complete + fulfill — resolución positiva, puede tener más duración, más motion o más presencia. Lectura: objetivo cumplido.
commit.delete + loss — consecuencia consumada, cierre breve pero huella suficiente. Lectura: esto ya no está disponible.
La clave: commit no siempre necesita más intensidad. Necesita claridad de consecuencia.
6. Signal: el rango de la atención
Signal trabaja con atención, y la atención tiene coste. Una señal demasiado débil se pierde. Una señal demasiado fuerte fatiga. Una señal demasiado breve no se procesa. Una señal demasiado persistente se convierte en ruido.
Un risk necesita tiempo para que el usuario lo procese y corrija. Un threat necesita entrar rápido y permanecer mientras la acción sea necesaria. Pero una amenaza no debería gritar indefinidamente.
7. Handle: el rango del control
Handle tiene requisitos de rango muy específicos porque es la única familia de control motor continuo.
Durante handle.carry, la latencia debe ser mínima y constante. Cualquier retraso rompe la sensación de control directo. El usuario no interpreta un lag como "el sistema procesa" — lo interpreta como "no estoy controlando esto."
En handle.pick, el rango es breve: un cambio de estado inmediato (elevación, sombra, háptica) que diga "lo tienes." En handle.drop, el rango depende del resultado: si es commit.reorder + affirm, marca breve; si es commit.delete + loss, huella y gravedad.
La regla de handle: el carry debe ser silencioso y fluido. La evaluación se concentra en pick y drop.
Antipatrón: motion durante todo el carry que compite con el control del usuario. O lag variable que hace que el objeto "salte."
8. Sustain: el rango de la espera
Sustain existe porque hay tiempo sin resultado. Su rango no se mide como un evento breve, sino como una continuidad.
Un spinner breve puede funcionar. Un spinner largo se vuelve pregunta. Un spinner eterno se vuelve acusación.
La regla: cuanto más dura una espera, más información debe ofrecer.
9. Emerge y shift: rangos de entrada y orientación
Emerge — una aparición local debe ser lo bastante clara para que el usuario entienda qué apareció, de dónde viene y a qué pertenece. Pero no debe tener el peso de un cambio de contexto. Un tooltip, dropdown o popover necesita entrada breve y ligera. Si dura demasiado o tiene demasiada profundidad, puede parecer shift.
Shift — un cambio de contexto necesita más orientación. Abrir un modal, entrar en edición, cambiar de vista o activar una command palette implica otra relación operativa. La transición debe ser suficiente para orientar, pero no tan larga que interrumpa.
10. Sonido y háptica: rangos de intrusión
Sonido y háptica entran en el cuerpo o en el entorno del usuario. Por eso sus rangos deben ser más conservadores.
Eventos frecuentes: sonido/háptica mínimos o ausentes. Eventos raros y relevantes: sonido/háptica posibles. Eventos críticos: sonido/háptica opcionales, nunca únicos. Sustain: evitar sonido/háptica continuos. Contact frecuente: evitar refuerzo fuerte. Threat: entrada saliente, no bucle agresivo.
Figura 31.2
11. Saturación y frecuencia
La intensidad aceptable depende de la frecuencia. Un evento que ocurre una vez al día puede permitirse más presencia. Un evento que ocurre cien veces por hora debe ser casi invisible.
PRINCIPIO
La gramática debe tener memoria de frecuencia. No todo evento puede pedir atención como si fuera único.
12. Rangos y accesibilidad
Los rangos también deben adaptarse a accesibilidad. Un usuario puede necesitar más tiempo para leer una señal. Otro puede necesitar menos motion. Otro puede tener sonido desactivado. Otro puede fatigarse con vibración.
Por eso los rangos no pueden ser fijos. Deben poder ajustarse mediante reduced motion, controles de sonido, duración suficiente de mensajes, persistencia de estados importantes, opción de cerrar manualmente, evitar timeouts injustificados y alternativas a señales efímeras.
Una señal importante no debería desaparecer antes de que el usuario haya tenido oportunidad razonable de procesarla.
13. Tabla síntesis de rangos
14. Antipatrones de rango
14.1. MICROFEEDBACK LENTO
Un contact que empieza tarde. Problema: se pierde agencia.
14.2. CONFIRMACIÓN EXCESIVA
Un affirm que se celebra como fulfill. Problema: todo parece logro.
14.3. WARNING FUGAZ
Un risk que desaparece antes de corregir. Problema: el usuario no puede actuar.
14.4. THREAT INFINITO
Una alerta de sesión que suena en loop, vibra el dispositivo y parpadea sin control. El usuario no puede silenciarla sin atender. Si está en una reunión, en transporte público o usando auriculares, la interfaz se convierte en agresión. El problema no es la amenaza — la sesión sí puede expirar. El problema es que la intensidad no tiene techo ni control. La entrada puede ser saliente, pero la persistencia debe ser sobria: presencia visual firme, texto claro, sonido breve si procede, y después silencio mientras la alerta siga visible.
14.5. LOSS SIN HUELLA
Algo se elimina y desaparece sin rastro. Problema: se confunde pérdida con ocultación.
14.6. SPINNER ETERNO
Proceso sin explicación ni salida. Problema: se rompe confianza.
14.7. HANDLE CON LAG VARIABLE
Un objeto arrastrado que a veces sigue el gesto y a veces salta. Problema: el usuario pierde sensación de control directo.
15. Síntesis
Los rangos psicoperceptivos no son valores universales. Son regiones de diseño. Sirven para mantener la función del evento: contact → agencia, commit → cierre, signal → atención, handle → control, emerge → presencia, shift → orientación, sustain → continuidad.
PRINCIPIO
Un evento no solo necesita el canal correcto. Necesita la cantidad correcta de canal.
PRINCIPIO
La intensidad debe corresponder a consecuencia, urgencia, frecuencia, reversibilidad y accesibilidad.
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>EVENTO
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>REGIÓN TEMPORAL ORIENTATIVA
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>FUNDAMENTO
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>contact.press
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>dentro de la ventana de atribución causal
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>agencia acción-respuesta
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>commit.save + affirm
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>breve, sin interrumpir flujo
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>confirmación suave
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>commit.complete + fulfill
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>breve-media, más resolutivo
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>cierre de tensión
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>emerge.tooltip
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>breve-media
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>aparición auxiliar
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>emerge.dropdown
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>breve
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>opciones locales
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>shift.enter-mode
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>media, con orientación
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>cambio de contexto
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>signal.warn + risk
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>persistente hasta corrección
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>permitir acción correctiva
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>signal.alert + threat
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>entrada rápida + persistencia hasta acción
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>urgencia
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>commit.delete + loss
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>breve + huella
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>consecuencia consumada
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>sustain.progress
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>mientras dure el proceso
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>continuidad
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>handle.carry
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>baja latencia continua
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>control directo
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>SIGNAL
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>PERSISTENCIA
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>INTENSIDAD
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>signal.announce + neutral
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>breve o contextual
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>baja
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>signal.notify + neutral
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>breve-media
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>baja-media
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>signal.warn + risk
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>hasta corrección/cierre
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>media
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>signal.alert + threat
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>hasta acción
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>alta, pero no infinita
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>DURACIÓN PERCIBIDA
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>NECESIDAD
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>muy breve
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>quizá no mostrar nada o feedback mínimo
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>breve
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>indicador simple
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>media
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>texto de estado
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>larga
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>progreso, explicación o control
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>indefinida
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>alternativa, cancelación o cambio de estado
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>EVENTO
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>FRECUENCIA PROBABLE
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>INTENSIDAD RECOMENDABLE
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>contact.press
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>muy alta
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>mínima
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>commit.save + affirm
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>alta
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>discreta
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>sustain.progress
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>media
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>baja saliencia
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>signal.notify + neutral
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>media
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>controlada
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>signal.warn + risk
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>media-baja
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>clara
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>commit.complete + fulfill
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>baja-media
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>resolutiva
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>signal.alert + threat
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>baja
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>alta, pero breve
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>commit.delete + loss
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>baja
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>grave, con huella
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>FAMILIA / INTENT
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>RANGO ORIENTATIVO
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>EVITAR
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>contact
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>inmediato, muy breve
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>retraso o teatralización
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>commit + affirm
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>breve y discreto
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>celebración
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>commit + fulfill
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>breve-media, resolutivo
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>trivialidad o espectáculo
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>signal + risk
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>persistente hasta corrección
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>desaparición rápida
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>signal + threat
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>entrada rápida + persistencia sobria
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>alarma sostenida
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>commit + loss
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>breve + huella
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>desaparición sin registro
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>handle
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>latencia mínima continua
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>lag o evaluación durante carry
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>emerge
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>entrada/salida ligera
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>peso de modal
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>shift
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>transición orientadora
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>cambio invisible
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>sustain
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>mientras dure proceso
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>spinner eterno sin información

## CAPÍTULO 33
Accesibilidad aplicada
Migración semántica en flujos reales
La accesibilidad ya apareció varias veces en este libro. Apareció en la Parte I como prueba de que una semántica no debe depender de un único canal. Apareció en la Parte II como reducción de canales. Apareció en las familias semánticas como exigencia concreta.
Pero hasta ahora la accesibilidad ha sido tratada sobre todo por partes. Este capítulo la aplica a flujos completos.
Un usuario con reduced motion no pierde "una animación"; puede perder causalidad, continuidad, cambio de contexto o cierre. Un usuario que no distingue color no pierde "rojo o verde"; puede perder riesgo, amenaza, confirmación o pérdida. Un usuario sin sonido no pierde "un aviso"; puede perder una señal fuera de foco. Un usuario que navega con teclado no pierde "drag"; puede perder la posibilidad de manipular. Un usuario que usa lector de pantalla no pierde "layout"; puede perder presencia, marco, orden y consecuencia.
PREGUNTA DEL CAPÍTULO
¿La semántica del evento sobrevive en condiciones perceptivas distintas?
Figura 32.1
1. Accesibilidad aplicada no es traducción literal
Cuando un canal se reduce, la solución no consiste en copiar el mismo estímulo por otro canal. La pregunta es anterior: ¿qué significado transportaba ese canal?
Si el motion transportaba contacto, el reemplazo debe conservar contacto. Si transportaba continuidad, debe conservar continuidad. Si el color transportaba riesgo, el reemplazo debe conservar riesgo corregible. Si el sonido transportaba amenaza, el reemplazo debe conservar urgencia.
Esto es migración semántica.
PRINCIPIO
La accesibilidad aplicada no conserva necesariamente los mismos estímulos. Conserva la misma lectura semántica.
2. Caso 1: error de formulario
Evento base: signal.warn + risk. El usuario intenta enviar un formulario y un campo obligatorio está vacío. La lectura semántica esperada es: hay un problema corregible aquí. No: todo ha fallado. No: hay una amenaza crítica.
2.1. VERSIÓN FRÁGIL
input border: red. Problemas: depende solo de color, no explica qué ocurre, no comunica corrección, puede no ser detectado por usuarios con baja visión o daltonismo, puede no estar vinculado al campo, puede no ser anunciado tras submit.
2.2. VERSIÓN ACCESIBLE SEMÁNTICAMENTE
2.3. MIGRACIONES
Sin color: el campo sigue comunicando error mediante icono, mensaje, borde, posición y relación con el campo.
Sin color Y sin visión parcial: el mensaje debe estar vinculado al campo mediante aria-describedby. El usuario debe poder oír: "El campo correo electrónico es obligatorio."
Sin motion: no pasa nada si el error no tiembla. El mensaje persistente sostiene la semántica.
Con varios errores: conviene añadir resumen ("Hay 3 errores en el formulario") y permitir saltar a cada campo.
3. Caso 2: operación larga con reduced motion
Secuencia base: contact.press → sustain.progress → commit.complete + fulfill. El usuario sube un archivo grande.
3.1. QUÉ SE PERDERÍA SI SOLO QUITAMOS MOTION
Si eliminamos todas las animaciones sin más: el contacto puede sentirse menos inmediato, el progreso puede parecer estático, el cierre puede perder resolución, el usuario puede no distinguir entre proceso activo y resultado final. Reducir motion no debe amputar la estructura temporal.
3.2. VERSIÓN ACCESIBLE SEMÁNTICAMENTE
Contact: estado pressed claro, cambio inmediato de forma, foco visible, quizá sonido o háptica opcional.
Sustain: barra de progreso sin motion excesivo, texto "Subiendo archivo…", porcentaje si existe, estado persistente, actualización discreta.
Commit: mensaje visible, marca de completado, estado persistente, sonido opcional, color positivo claro pero no único.
La lectura se conserva: me ha sentido → sigue trabajando → objetivo cumplido. Aunque el movimiento se reduzca.
DISTINCIÓN
Reduced motion no significa interfaz sin tiempo. Significa tiempo expresado por canales menos problemáticos.
4. Caso 3: eliminación con undo
Secuencia base: signal.warn + threat → commit.delete + loss → emerge.present undo.
4.1. VERSIÓN FRÁGIL
Botón rojo, tarjeta desaparece, toast breve "Eliminado", undo aparece durante dos segundos, sin anuncio accesible, foco queda en lugar ambiguo. Problemas: amenaza y pérdida se comunican con el mismo color, la desaparición puede parecer ocultación, el undo puede no percibirse, usuarios de teclado o lector pueden perder contexto.
4.2. VERSIÓN ACCESIBLE SEMÁNTICAMENTE
Antes (signal.warn + threat): texto claro, forma de advertencia, presencia suficiente, foco en decisión, color como refuerzo. Lectura: puedes evitar una consecuencia.
Después (commit.delete + loss): retirada de la tarea, mensaje de consecuencia, actualización de lista, huella temporal, no alarma sostenida. Lectura: esto ya se eliminó.
Reparación (emerge.present undo): barra o mensaje persistente, botón de deshacer claro, tiempo suficiente, foco no perdido, anuncio si procede. Lectura: puedes reparar temporalmente.
5. Caso 4: drag-and-drop accesible
Secuencia base: handle.pick → handle.carry → handle.drop → commit.reorder + affirm.
5.1. VERSIÓN FRÁGIL
Solo funciona con ratón o touch. No hay alternativa de teclado. No se anuncia la posición. No hay forma clara de cancelar. La semántica de manipulación depende completamente de un gesto físico y visual.
5.2. QUÉ DEBE CONSERVARSE
La accesibilidad no exige que todos hagan el mismo gesto. Exige que todos puedan realizar y comprender el mismo evento operativo. El evento no es "arrastrar con ratón." El evento es: mover un objeto de una posición a otra.
5.3. VERSIÓN ACCESIBLE SEMÁNTICAMENTE
Opciones: activar modo "mover" con teclado, seleccionar elemento, botones "subir"/"bajar", elegir destino, anunciar posición actual, anunciar resultado, permitir cancelar, marcar destino válido, conservar foco.
Lo importante es que la semántica se conserva: he elegido este objeto → lo estoy moviendo → quedó en otra posición.
PRINCIPIO
La accesibilidad no exige el mismo gesto. Exige el mismo evento operativo comprensible.
6. Caso 5: señal crítica sin sonido ni color
Evento base: signal.alert + threat. La sesión expirará en 30 segundos si el usuario no actúa.
6.1. SIN SONIDO
La amenaza debe migrar a: presencia dominante, texto claro, cuenta atrás si procede, color de alta saliencia, forma crítica, foco si bloquea acción, persistencia hasta respuesta.
6.2. SIN COLOR
Debe sobrevivir mediante forma, texto, icono, posición, persistencia, quizá motion contenido.
6.3. SIN SONIDO Y SIN COLOR
Este es el caso extremo donde la migración se pone a prueba. La amenaza debe sobrevivir solo con forma, texto, posición, tamaño y persistencia. Un bloque de texto grande, bien posicionado, con icono reconocible, foco capturado y cuenta atrás textual puede comunicar urgencia sin depender de color ni sonido. Si la semántica sobrevive aquí, la arquitectura multicanal funciona.
6.4. CON LECTOR DE PANTALLA
Debe anunciarse con prioridad adecuada, pero sin crear ruido continuo. La semántica no es "hacer ruido." Es permitir acción antes de la consecuencia.
7. Principios de accesibilidad aplicada
Principio 1 — Conservar significado, no estímulo. Si un canal se reduce, pregunta qué significado transportaba.
Principio 2 — Diferenciar evento y gesto. El gesto puede cambiar. El evento debe mantenerse. Drag físico puede convertirse en mover con teclado.
Principio 3 — No depender de color para intent. Risk, threat, loss, affirm y fulfill deben sobrevivir sin color.
Principio 4 — No depender de motion para causalidad. Si el movimiento se reduce, la agencia debe migrar a estado, foco, texto, sonido o háptica opcional.
Principio 5 — No depender de sonido para urgencia. Una amenaza debe tener presencia visual/textual suficiente.
Principio 6 — No hacer efímero lo importante. Señales críticas y resultados relevantes deben dejar huella.
Principio 7 — Adaptar intensidad. Accesibilidad también significa reducir fatiga sensorial.
8. Ficha de migración semántica
Para revisar un flujo:
Flujo: eliminar tarea con undo. Evento principal: commit.delete + loss. Familias: signal, commit, emerge. Intents: threat, loss, neutral. Canales dominantes: presencia, forma, texto, color. Sin color: se mantiene con texto, forma, icono. Reduced motion: retirada menos animada, huella persistente. Sin sonido: no afecta. Teclado: foco en confirmación y luego undo. Lector: anuncio de eliminación y acción disponible. Significado en riesgo: pérdida + reparación temporal. Migración: mensaje persistente + undo + actualización de lista.
Figura 32.2
9. Antipatrones de accesibilidad aplicada
9.1. ADAPTAR EL COMPONENTE, NO EL EVENTO
El componente cumple WCAG, pero el flujo completo no se entiende. El usuario puede activar cada control pero no comprende la secuencia semántica.
9.2. QUITAR MOTION SIN SUSTITUIR SIGNIFICADO
Se elimina mareo, pero también causalidad y continuidad. El usuario deja de percibir qué causó qué.
9.3. SILENCIAR SIN RESPALDO
Se apaga sonido, pero la alerta fuera de foco se pierde. El usuario no tiene otra forma de saber que algo reclama atención.
9.4. ALTO CONTRASTE SIN ESTRUCTURA
Se mejora visibilidad, pero la jerarquía de eventos sigue confusa. Se ve mejor, pero no se entiende mejor.
9.5. TECLADO SIN SEMÁNTICA
Se puede llegar al control, pero no entender el estado, resultado o consecuencia del evento.
9.6. LECTOR DE PANTALLA SIN SECUENCIA
Se anuncian piezas aisladas, pero no el flujo. El usuario oye elementos pero no comprende la operación.
10. Síntesis
La accesibilidad aplicada es donde la teoría multicanal demuestra si funciona.
No basta con que un canal tenga alternativa. No basta con que un componente cumpla una regla. No basta con que haya etiquetas.
PRINCIPIO
Una adaptación accesible no conserva necesariamente los mismos estímulos. Conserva la misma lectura semántica.
PRINCIPIO
Cuando un canal falla, migra el significado, no el adorno.
Figura 32.3
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>CANAL
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>FUNCIÓN
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Color
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>refuerzo de advertencia moderada
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Forma
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>borde, callout o contorno local
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Icono
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>reconocimiento rápido
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Texto
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>explicación del problema
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Presencia
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>persistencia hasta corrección
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Foco
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>llevar al primer error si bloquea envío
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Relación accesible
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>mensaje vinculado al campo
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Tiempo
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>no desaparecer automáticamente
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="2412"/><w:gridCol w:w="2412"/><w:gridCol w:w="2412"/><w:gridCol w:w="2412"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>MOMENTO
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>EVENTO
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>RIESGO
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>SOPORTE NECESARIO
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Antes
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>signal.warn + threat
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>no percibir gravedad
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>texto, foco, forma, color
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Después
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>commit.delete + loss
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>confundir con ocultación
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>mensaje, huella, actualización
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>Reparación
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>emerge.present undo
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>no llegar a deshacer
<w:tcPr><w:tcW w:type="dxa" w:w="2412"/></w:tcPr><w:p><w:r><w:t>persistencia, botón claro, foco/anuncio

## CAPÍTULO 34
Antipatrones globales
Cuando la gramática se rompe
Una teoría no se entiende del todo hasta que muestra sus errores.
Hasta ahora hemos definido eventos, familias, intents, canales, composición, matrices, rangos y accesibilidad aplicada. Pero en una interfaz real, los problemas no siempre aparecen como fallos aislados. Muchas veces aparecen como rupturas de gramática.
No es solo que una animación sea demasiado larga. No es solo que un color tenga poco contraste. No es solo que un sonido moleste. El problema más profundo suele ser otro: el sistema comunica una clase de evento distinta de la que realmente está ocurriendo.
PREGUNTA DEL CAPÍTULO
¿Qué ocurre cuando la interfaz dice una cosa y el evento significa otra?
1. Todo es success
Qué se hace mal: toda operación positiva se comunica igual. Un autoguardado, un toggle, una preferencia cambiada, un formulario enviado, una subida terminada — todo recibe el mismo verde, el mismo check, la misma animación. commit.save + affirm y commit.complete + fulfill quedan aplastados bajo una sola categoría: success.
Por qué parece correcto: porque ambos casos son positivos. El sistema hizo algo bien. La convención heredada del semáforo refuerza esta simplificación.
Qué fundamento viola: la distinción entre valencia y activación. Affirm confirma normalidad. Fulfill resuelve una tensión. El autoguardado no debería sentirse como culminación.
Corrección: separar confirmación suave (marca discreta, baja saliencia, sin sonido) de resolución positiva (motion resolutivo, cierre visible, color positivo más claro).
PRINCIPIO
Si todo es success, nada se siente realmente logrado.
2. Todo es danger
Qué se hace mal: todo evento negativo fuerte se comunica igual. Una advertencia, un recurso eliminado, un fallo de validación, una conexión perdida, una acción irreversible — todo se comunica con rojo, alerta y tono grave.
Por qué parece correcto: porque todos tienen valencia negativa. La convención permite agruparlo todo bajo danger.
Qué fundamento viola: la diferencia temporal y afectiva entre risk (problema corregible), threat (amenaza activa) y loss (pérdida consumada). Una amenaza convoca acción. Una pérdida registra consecuencia. Un riesgo pide corrección. Si una pérdida se comunica como amenaza, el sistema genera urgencia donde ya no hay prevención posible.
Corrección: separar los tres casos. signal.warn + risk para "revisa esto." signal.alert + threat para "actúa ahora." commit.delete + loss para "esto ya se perdió."
PRINCIPIO
No todo lo negativo debe gritar. A veces debe corregirse. A veces debe evitarse. A veces solo debe registrarse.
3. Info como cajón de sastre
Qué se hace mal: todo lo que no es success, warning o danger se llama info. Un dato contextual, un mensaje neutro, una notificación, un consejo, una ayuda, una confirmación leve — todo cae en info.
Por qué parece correcto: porque info parece una categoría segura. No es positivo ni negativo.
Qué fundamento viola: la separación entre saliencia atencional y evaluación afectiva. Info no responde a "¿cómo se evalúa esto?" sino a "¿debo notarlo?" Eso pertenece mejor a signal.
Corrección: sustituir info como intent por composiciones de señal neutra. signal.announce + neutral para información contextual. signal.notify + neutral para notificación sin carga evaluativa.
DISTINCIÓN
Info no es una emoción del evento. Es una función de atención.
4. Todo lo que aparece es alerta
Qué se hace mal: cualquier cosa que aparece se diseña como si reclamara atención fuerte. Un tooltip entra con demasiada saliencia. Un dropdown parece una alerta. Una ayuda contextual usa color de warning.
Por qué parece correcto: porque si algo aparece, el equipo quiere que el usuario lo vea. Entonces se aumenta contraste, motion, sombra o color.
Qué fundamento viola: la diferencia entre emerge y signal. Emerge introduce presencia. Signal reclama atención. No toda aparición es una señal.
Corrección: emerge.open para dropdown. emerge.present para tooltip. signal.warn + risk solo si lo que aparece comunica problema corregible. signal.alert + threat solo si exige atención inmediata.
DISTINCIÓN
Aparecer no es advertir. Entrar en el campo no es reclamarlo entero.
5. Modal rojo
Qué se hace mal: un modal contiene una advertencia y todo el modal se vuelve peligroso. Fondo rojo, borde rojo, botones rojos, toda la superficie absorbe el intent.
Por qué parece correcto: porque el contenido del modal es grave. Parece razonable que el modal completo se diseñe como danger.
Qué fundamento viola: la distinción entre marco y mensaje. El modal es shift.enter-mode — cambia el contexto. La advertencia dentro del modal es signal.warn + threat. El modal no es la amenaza. El mensaje porta la amenaza.
Corrección: componer shift.enter-mode + signal.warn + threat. El modal comunica cambio de contexto mediante profundidad y foco. La advertencia comunica amenaza mediante forma, texto, color e icono.
PRINCIPIO
El intent debe vivir en la figura evaluable, no en el contenedor estructural.
6. Spinner de error
Qué se hace mal: un proceso en curso se comunica con color, motion o tono de error. Un spinner rojo. Un loader tenso. Una espera con alarma.
Por qué parece correcto: porque esperar genera ansiedad. El equipo quiere avisar de que algo importante está ocurriendo.
Qué fundamento viola: la diferencia entre sustain y signal/commit. sustain.progress comunica "esto sigue ocurriendo," no "esto falló" ni "esto es peligroso."
Corrección: mantener sustain neutro. Si aparece un problema durante el proceso: sustain.progress + signal.warn + risk. Si falla: commit.fail + risk.
DISTINCIÓN
Una espera no es un error por durar. Es un proceso que necesita continuidad.
7. Commit anticipado
Qué se hace mal: la interfaz comunica resultado antes de que exista. Un botón muestra success al pulsar. Un formulario dice "enviado" antes de recibir respuesta.
Por qué parece correcto: porque el sistema quiere dar feedback rápido y sentirse optimista.
Qué fundamento viola: la diferencia entre contact, sustain y commit. Contact dice "he recibido tu acción." Sustain dice "sigo trabajando." Commit dice "ya terminó." Si se usa commit en el momento de contact, la interfaz promete una consecuencia que aún no existe.
Corrección: contact.press → sustain.progress → commit.complete + fulfill.
PRINCIPIO
No celebres lo que todavía no ha ocurrido.
8. Pérdida sin huella
Qué se hace mal: algo desaparece y no queda rastro. Una tarjeta se elimina con fade out. Un archivo desaparece de una lista. No hay mensaje, undo, registro ni estado.
Por qué parece correcto: porque visualmente la desaparición parece suficiente. El objeto ya no está. La interfaz se limpió.
Qué fundamento viola: la diferencia entre desaparición y pérdida. emerge.hide no es commit.delete + loss. Una pérdida no solo retira presencia — cambia disponibilidad operativa.
Corrección: commit.delete + loss con huella: retirada, mensaje, undo si existe, actualización de estado.
DISTINCIÓN
Una pérdida importante no debe desaparecer como si solo se hubiera ocultado.
9. Drag sin alternativa
Qué se hace mal: la única forma de manipular un objeto es arrastrar con ratón o touch.
Por qué parece correcto: porque visualmente el drag-and-drop es intuitivo para muchos usuarios.
Qué fundamento viola: la accesibilidad operativa de handle. Handle no significa "arrastrar con ratón." Significa "controlar directamente un objeto."
Corrección: ofrecer alternativas: botones subir/bajar, seleccionar y elegir destino, mover con teclado, anuncio de posición, cancelación clara.
PRINCIPIO
La interfaz puede cambiar el gesto. No debe perder el evento.
10. Sonido decorativo
Qué se hace mal: la interfaz suena sin necesidad semántica. Cada click suena. Cada notificación suena igual. Cada éxito tiene chime. Los procesos tienen loop sonoro.
Por qué parece correcto: porque el sonido parece añadir riqueza o personalidad.
Qué fundamento viola: la relación entre canal y evento. El sonido no debe existir porque "queda bien." Debe reforzar una dimensión que el evento necesita.
Corrección: sonido solo si responde a función clara: contacto, cierre, urgencia, pérdida, fuera de foco.
PRINCIPIO
Si un sonido no ayuda a reconocer qué ocurrió, cuándo ocurrió o cómo debe evaluarse, probablemente sobra.
11. Todo vibra
Qué se hace mal: la interfaz usa háptica para todo. Cada toque, selección, error, scroll y notificación vibra.
Por qué parece correcto: porque la háptica parece reforzar contacto.
Qué fundamento viola: la proporcionalidad corporal. La háptica ocurre en el cuerpo del usuario. Puede ayudar pero también invadir y fatigar.
Corrección: reservar háptica para contacto relevante, pick/drop, encaje, alerta importante, pérdida significativa. Debe ser opcional, proporcional y nunca única.
DISTINCIÓN
La háptica no es más feedback. Es contacto corporal con el evento.
12. Color como semántica
Qué se hace mal: el color define el significado completo del evento. Rojo = error. Verde = success. Amarillo = warning. Azul = info.
Por qué parece correcto: porque es la convención heredada. Fácil, familiar, rápida.
Qué fundamento viola: el principio central del sistema de intents. El intent no nace del color. Nace de la evaluación del evento en el espacio valencia/activación.
Corrección: partir de evento → evaluación → intent → canales. No de color → significado.
PRINCIPIO
El color expresa la semántica. No la funda.
13. Señales efímeras
Qué se hace mal: mensajes importantes aparecen y desaparecen demasiado rápido. Un error, una pérdida, una advertencia, un undo — el usuario no alcanza a leer, actuar o recuperar.
Por qué parece correcto: porque el diseño busca no interrumpir. Los mensajes efímeros parecen ligeros y poco invasivos.
Qué fundamento viola: accesibilidad temporal y persistencia semántica. Si un evento exige acción, corrección o reconocimiento, debe persistir lo suficiente.
Corrección: affirm breve. Risk hasta corrección. Threat hasta acción. Loss con huella. Undo con duración suficiente y accesible.
DISTINCIÓN
Lo importante no debe existir solo durante un instante.
14. Shift invisible
Qué se hace mal: el contexto cambia pero el usuario no recibe orientación. Una nueva vista aparece sin foco. Un modal abre pero el lector sigue en el fondo. Un modo de edición se activa sin señal.
Por qué parece correcto: porque visualmente el cambio parece claro para quien lo diseña.
Qué fundamento viola: la función de shift. El usuario necesita saber dónde está, qué puede hacer, cómo vuelve, qué cambió.
Corrección: todo shift debe cuidar foco, título, profundidad, landmarks, navegación de retorno, estado de modo.
PRINCIPIO
Si el usuario no sabe dónde está, el shift falló.
15. Tabla resumen
16. Síntesis
Los antipatrones globales muestran que la gramática puede romperse de muchas formas. No basta con que un componente funcione. No basta con que una animación sea fluida. No basta con que un color sea reconocible. La pregunta es: ¿el sistema comunica el evento correcto, con la intensidad correcta, por los canales correctos, en el momento correcto?
DISTINCIÓN
Un antipatrón semántico no es solo una mala práctica visual. Es una contradicción entre el evento que ocurre y el evento que la interfaz hace percibir.
PRINCIPIO
Cuando una interfaz se siente rara, muchas veces no falla el efecto. Falla la gramática.
Figura 33.1
Figura 33.2
Figura 33.3
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>ANTIPATRÓN
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>QUÉ CONFUNDE
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>CORRECCIÓN
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Todo es success
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>affirm con fulfill
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>separar confirmación y culminación
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Todo es danger
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>risk, threat, loss
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>separar riesgo, amenaza y pérdida
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Info como cajón
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>saliencia con intent
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>signal + neutral
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Todo aparece como alert
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>emerge con signal
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>separar presencia y atención
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Modal rojo
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>marco con mensaje
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>shift + signal.threat
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Spinner de error
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>proceso con fallo
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>sustain + señal si procede
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Commit anticipado
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>contacto con resultado
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>contact → sustain → commit
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Pérdida sin huella
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>ocultación con pérdida
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>commit.loss + huella
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Drag sin alternativa
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>gesto con evento
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>alternativa operativa
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Sonido decorativo
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>canal con adorno
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>sonido solo si comunica evento
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Todo vibra
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>feedback con invasión
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>háptica proporcional
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Color como semántica
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>canal con intent
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>intent antes que color
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Señales efímeras
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>ligereza con pérdida
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>persistencia proporcional
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>Shift invisible
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>cambio sin orientación
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>foco y estructura

## CAPÍTULO 35
Validación de una semántica perceptiva
Cómo saber si el sistema comunica lo que cree comunicar
Una teoría de la interfaz no debería sostenerse solo porque suene coherente. Si este libro propone una gramática perceptiva del evento, debe poder hacerse una pregunta incómoda:
PREGUNTA DEL CAPÍTULO
¿Cómo sabemos si el usuario percibe el evento que creemos estar comunicando?
Porque una interfaz puede estar muy bien construida desde el punto de vista técnico y aun así fracasar semánticamente. El botón funciona. La animación corre a 60 fps. El color cumple contraste. Pero el usuario puede no entender qué ocurrió, si el sistema recibió su acción, si algo sigue procesando, si algo ya terminó, si debe corregir, si algo se perdió.
Figura 34.1
1. Qué significa validar una semántica
Validar una semántica perceptiva significa comprobar si existe correspondencia entre tres cosas: el evento que el sistema quería comunicar, las señales perceptivas utilizadas y la lectura real del usuario.
Si el sistema quería comunicar signal.warn + risk pero el usuario lee signal.alert + threat, la semántica falló. Si quería comunicar commit.delete + loss pero el usuario lee emerge.hide, la semántica falló. Si quería comunicar sustain.progress pero el usuario lee "sistema bloqueado", la semántica falló.
PRINCIPIO
Una semántica no se valida preguntando si el efecto gusta. Se valida preguntando qué evento ha entendido el usuario.
2. Qué no es validación semántica
No es solo usabilidad general — un usuario puede completar una tarea sin entender los eventos intermedios. No es test de preferencia — preguntar si gusta una animación no valida si comunica contact o commit. No es solo accesibilidad técnica — roles correctos no garantizan lectura correcta. No es solo QA funcional — que el estado cambie no significa que el usuario lo perciba.
3. Qué se valida
4. Protocolo 1 — Test de lectura inmediata
Mostrar una interacción y preguntar inmediatamente: ¿qué acaba de ocurrir?
Ejemplo contact: evento diseñado contact.press. Respuestas esperadas: "he pulsado", "el botón respondió." Respuestas problemáticas: "se ha guardado", "no sé si ha pasado algo."
Ejemplo sustain: evento diseñado sustain.progress. Respuestas esperadas: "está cargando", "sigue trabajando." Respuestas problemáticas: "ha fallado", "se bloqueó."
Ejemplo loss: evento diseñado commit.delete + loss. Respuestas esperadas: "se eliminó", "ya no está." Respuestas problemáticas: "se ocultó", "se cerró", "no sé dónde fue."
PRINCIPIO
Si el usuario no puede decir qué ocurrió, la interfaz no comunicó un evento. Comunicó un cambio.
Figura 34.2
5. Protocolo 2 — Test de diferenciabilidad
Comparar dos eventos y preguntar: ¿qué diferencia percibes?
Ejemplo contact vs commit: evento A contact.press, evento B commit.save + affirm. Respuesta esperada: "en el primero solo responde, en el segundo se guardó." Respuesta problemática: "parecen lo mismo."
Ejemplo risk vs threat: evento A signal.warn + risk, evento B signal.alert + threat. Pregunta: ¿cuál requiere actuar antes? Respuesta esperada: "la segunda." Respuesta problemática: "parecen igual de graves."
Figura 34.3
6. Protocolo 3 — Test de intent
Validar si el usuario percibe correctamente la evaluación del evento. No se pregunta "¿esto es risk?" Se pregunta con lenguaje natural.
7. Protocolo 4 — Test de reducción de canal
Probar el mismo evento reduciendo un canal: sin color, con reduced motion, sin sonido, solo teclado, lector de pantalla. La pregunta no es "¿se sigue viendo parecido?" sino "¿se sigue entendiendo el mismo evento?"
8. Protocolo 5 — Test de secuencia
Mostrar una operación completa y preguntar: ¿qué pasó primero, después y al final? Si el usuario percibe solo "hubo error y luego success", la composición perdió matiz.
9. Protocolo 6 — Test de fatiga
Un evento puede funcionar una vez y fallar por repetición. Preguntas: ¿seguiría siendo tolerable después de 20 veces? ¿se vuelve molesto? ¿pierde significado? Un microclick puede ser útil una vez pero fatigar en cada tecla. Un guardado con animación puede ser agradable una vez pero absurdo en cada autoguardado.
10. La ficha completa de validación semántica
Nombre del flujo:
Evento o secuencia evaluada:
Familia esperada:
Intent esperado:
Canales usados:
Canal dominante:
Lectura esperada:
Lectura real:
Diferencia detectada:
¿Se distingue de eventos cercanos?
¿Sobrevive sin color?
¿Sobrevive con reduced motion?
¿Sobrevive sin sonido?
¿Sobrevive con teclado?
¿Produce fatiga por repetición?
Corrección propuesta:
11. Cómo interpretar los resultados
La validación busca patrones. Si un usuario se confunde, puede ser ruido. Si varios confunden lo mismo, hay problema.
12. Validación sin laboratorio
No hace falta laboratorio formal. Un equipo puede hacer validación semántica con prototipo interactivo, 5-8 usuarios, grabación de pantalla, preguntas inmediatas, comparación entre variantes, prueba con reduced motion, revisión con teclado, revisión sin color.
PRINCIPIO
La validación semántica no pregunta si el usuario puede usar la interfaz. Pregunta si puede leer lo que la interfaz está diciendo.
13. Antipatrones de validación
Preguntar si gusta — gusto no equivale a lectura. Validar solo resultado final — el usuario puede completar la tarea sin entender los eventos intermedios. Probar solo versión completa — si no pruebas reducción de canales, no sabes si la semántica es robusta. Confundir rapidez con claridad — una interacción rápida puede ser ambigua. Preguntar con términos del sistema — no preguntes "¿percibiste risk?" sino "¿esto parecía corregible o urgente?" Ignorar fatiga — una microinteracción agradable puede ser insoportable en repetición.
14. Síntesis
La validación semántica convierte la teoría en herramienta comprobable.
DISTINCIÓN
Una semántica perceptiva no debe defenderse solo porque suene coherente. Debe poder ponerse a prueba.
PRINCIPIO
Si el usuario interpreta otro evento distinto del que el sistema quería comunicar, la semántica falló aunque la interfaz funcione.
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>NIVEL
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>PREGUNTA
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Familia
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿qué tipo de evento percibió?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Verbo
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿qué cree que ocurrió concretamente?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Intent
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿cómo evalúa el evento?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Canal
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿qué señales usó para entenderlo?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Secuencia
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿entendió el orden de los eventos?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Accesibilidad
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿se conserva la lectura si se reduce un canal?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Fatiga
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿la señal sigue siendo proporcional en repetición?
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>INTENT
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>PREGUNTA DE VALIDACIÓN
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>neutral
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿esto parece informativo sin carga fuerte?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>affirm
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿esto confirma que todo va bien sin interrumpir?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>fulfill
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿esto parece objetivo cumplido?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>risk
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿esto parece corregible?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>threat
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿esto exige actuar ahora?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>loss
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿esto ya ocurrió y dejó consecuencia?
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>RESPUESTA DEL USUARIO
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>DIAGNÓSTICO PROBABLE
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>CORRECCIÓN
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>"No sé qué pasó"
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>evento poco legible
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>reforzar presencia / texto / huella
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>"Se guardó" ante contact
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>commit anticipado
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>separar contact de commit
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>"Parece peligroso" ante risk
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>exceso de activación
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>reducir saliencia
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>"Parece oculto" ante loss
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>falta huella
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>mensaje / undo / registro
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>"Parece modal" ante dropdown
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>profundidad excesiva
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>reducir shift, reforzar emerge
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>"Se bloqueó" ante sustain
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>continuidad insuficiente
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>texto / progreso
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>"Molesta tras repetir"
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>fatiga sensorial
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>reducir intensidad / frecuencia

## CAPÍTULO 36
De la teoría al sistema
Nombres, documentación, tokens y diseño operativo
Una teoría de interfaz no se vuelve útil solo porque esté bien formulada. Se vuelve útil cuando puede entrar en el trabajo diario de un equipo. Cuando ayuda a nombrar eventos. Cuando permite documentar decisiones. Cuando ordena tokens. Cuando mejora revisiones de diseño. Cuando evita discusiones vagas.
PREGUNTA DEL CAPÍTULO
¿Cómo puede una teoría así entrar en un sistema de diseño sin convertirse en un framework rígido?
1. La gramática no es un framework
Este libro no propone que todos los equipos adopten los mismos nombres internos, los mismos tokens ni la misma arquitectura. La gramática cumple otra función: obliga a distinguir funciones que la implementación no debería mezclar.
Un equipo puede llamar a algo danger. Otro puede llamarlo destructive. Otro puede usar critical. Lo importante no es el nombre exacto. Lo importante es que el sistema distinga: risk ≠ threat ≠ loss, affirm ≠ fulfill, emerge ≠ shift, contact ≠ commit.
PRINCIPIO
La gramática no obliga a una implementación concreta. Obliga a no confundir funciones perceptivas distintas.
2. Por qué llevar la gramática al sistema
Si la gramática se queda solo en el libro, sirve para pensar. Pero si entra en el sistema, también sirve para coordinar. En muchos equipos, las decisiones sobre interfaz se reparten: diseño visual define color, frontend implementa estado, UX define copy, accesibilidad revisa foco, producto define prioridad, motion se añade al final, sonido ni se considera.
La gramática permite alinear esas decisiones alrededor de un evento. Por ejemplo, signal.warn + risk implica: copy que explica un problema corregible, color que refuerza advertencia sin amenaza, forma que localiza el problema, motion contenido, accesibilidad que persiste y vincula al campo.
Figura 35.1
3. Tres niveles de adopción
3.1. NIVEL CONCEPTUAL
El equipo usa la gramática como lenguaje de revisión. Preguntas típicas: ¿esto es contact o commit? ¿esto es risk o threat? ¿esta desaparición es hide o loss? No requiere cambiar código ni tokens. Solo requiere cambiar cómo se conversa.
3.2. NIVEL DOCUMENTAL
El sistema de diseño documenta eventos semánticos. Cada evento tiene pregunta perceptiva, canales recomendados, errores comunes, accesibilidad y ejemplos. Aquí la gramática se vuelve documentación.
3.3. NIVEL OPERATIVO
La gramática entra en tokens, componentes, eventos declarativos o herramientas. Este nivel es más potente pero también más peligroso. Si se implementa sin criterio, puede convertirse en rigidez.
4. Naming: nombrar eventos, no efectos
Muchos sistemas nombran por apariencia (red-alert, green-success, slide-in, shake-error) o por componente (ButtonDanger, SuccessToast, ErrorModal). Ese naming mezcla planos.
Una gramática semántica intenta nombrar por evento: contact.press, commit.save + affirm, signal.warn + risk, commit.delete + loss.
5. Tokens semánticos
Los tokens suelen organizarse por propiedades: color.red.500, duration.200, shadow.lg. Eso es necesario pero no suficiente. Una gramática semántica no sustituye esos tokens. Los organiza en un nivel superior. Pero hay que pensar en firmas perceptivas, no en tokens de intent que parezcan tokens de color.
Figura 35.2
6. Firma perceptiva
Una firma perceptiva es el conjunto de decisiones de canal asociadas a un evento. Por ejemplo, commit.save + affirm: tiempo breve, motion asentamiento mínimo, forma marca persistente, color positivo discreto, sonido no por defecto. La firma perceptiva evita que cada canal se decida por separado.
7. Fichas de evento semántico
Una documentación de sistema podría incluir fichas como esta:
Ficha: commit.delete + loss. Pregunta: ¿qué dejó de estar disponible? Canales dominantes: presencia, forma, texto. Canales de apoyo: color, motion, sonido opcional. Firma perceptiva: retirada del objeto, mensaje de consecuencia, huella o registro, undo si existe. Accesibilidad: no depender solo de desaparición visual, anunciar pérdida si procede, mantener undo el tiempo suficiente. No usar: alarma sostenida de threat, solo color rojo, fade out sin huella. Antipatrones cercanos: todo es danger, pérdida sin huella, threat después de loss.
Ficha: signal.warn + risk. Pregunta: ¿qué requiere revisión? Canales dominantes: forma, texto, presencia. Firma: callout local, mensaje claro, persistencia hasta corrección, color moderado. Accesibilidad: mensaje vinculado al campo, no depender solo de color, no desaparecer automáticamente. No usar: alarma de threat, modal si no cambia el marco, shake agresivo.
Ficha: commit.complete + fulfill. Pregunta: ¿qué objetivo quedó cumplido? Canales dominantes: motion, presencia, forma. Firma: cierre resolutivo, marca de completado, color positivo visible, sonido breve opcional. No usar: success genérico para todo, celebración excesiva, desaparición sin estado final.
Figura 35.3
8. Documentar decisiones, no solo componentes
Un design system suele documentar componentes: Button, Modal, Toast, Tooltip, Spinner. Pero un botón puede participar en contact.press, commit.delete + loss, signal.warn + threat, shift.navigate. Un modal puede participar en shift.enter-mode, signal.alert + threat, commit.cancel + neutral. La documentación debería incluir una capa de eventos, no solo de componentes.
9. Tokens de canal y tokens de evento
Tokens de canal definen propiedades perceptivas básicas: color.red.600, motion.duration.short. Tokens de evento agrupan decisiones por semántica: event.signal.warn.risk podría mapear a color intent.risk.color, shape callout.warning, duration persistent.untilResolved. El token de evento no reemplaza los tokens de canal. Los coordina.
10. Cuidado: tokens no son verdad
Si el sistema convierte la gramática en tokens demasiado rígidos, puede matar la adaptación contextual. Un signal.warn + risk en un campo de formulario no es igual que en una operación financiera. La gramática orienta. No sustituye al juicio.
DISTINCIÓN
Un token semántico no debe congelar la experiencia. Debe impedir que se confundan funciones distintas.
11. Cómo usarlo en revisión de diseño
En lugar de decir "el modal se siente raro" podemos preguntar: ¿es realmente shift o solo emerge? ¿el intent vive en el mensaje o en el contenedor? ¿el commit deja huella? ¿el signal persiste lo suficiente? ¿la semántica sobrevive sin motion?
Figura 35.4
12. De la gramática al sistema sin dogmatismo
El peligro de toda gramática es convertirse en policía. Este libro no propone eso. La pregunta no es "¿hemos aplicado la taxonomía de forma perfecta?" sino "¿hemos evitado confundir eventos perceptivamente distintos?"
13. Síntesis
Convertir la teoría en sistema no significa construir un framework universal. Significa introducir una capa de lenguaje donde antes solo había componentes, estilos y efectos.
DISTINCIÓN
La gramática no obliga a una implementación concreta. Obliga a distinguir funciones que la implementación no debería mezclar.
PRINCIPIO
Nombra eventos antes de nombrar efectos.
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/><w:gridCol w:w="3216"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>NAMING HABITUAL
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>PROBLEMA
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>NAMING SEMÁNTICO
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>redAlert
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>color como significado
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>signal.alert + threat
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>successToast
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>componente + color
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>commit.save + affirm
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>dangerButton
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>intent en componente
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>commit.delete + loss
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>loadingSpinner
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>canal como evento
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>sustain.progress
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>shakeError
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>efecto como semántica
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>signal.warn + risk
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>modalDanger
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>contenedor como amenaza
<w:tcPr><w:tcW w:type="dxa" w:w="3216"/></w:tcPr><w:p><w:r><w:t>shift.enter-mode + signal.warn + threat
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>PREGUNTA
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>DETECTA
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Qué evento ocurre?
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>ambigüedad de familia
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Hay intent?
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>evaluación ausente o excesiva
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Dónde vive el intent?
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>contenedor coloreado
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Qué canal domina?
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>sobrecarga o fragilidad
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Qué queda como huella?
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>commit débil
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Qué pasa sin color?
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>dependencia cromática
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Qué pasa con reduced motion?
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>pérdida de causalidad
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿El evento es frecuente?
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>fatiga sensorial
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿Hay cierre?
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>sustain infinito
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>NIVEL
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>USO
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Conceptual
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>conversaciones y revisión
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Documental
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>guías, fichas, ejemplos
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>Operativo
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>tokens, eventos, componentes

## CAPÍTULO 37
Cierre
Hacia una interfaz con gramática perceptiva propia
Este libro empezó con una incomodidad. No con una certeza.
La incomodidad de trabajar durante años construyendo interfaces y sentir que muchas decisiones importantes quedaban repartidas en capas separadas: componentes, estados, estilos, animaciones, sonidos, accesibilidad, validaciones, loaders, modales, notificaciones, tokens, eventos técnicos.
El usuario no percibe "un componente." No percibe "un token." No percibe "un transition-duration." Percibe otra cosa: algo respondió, algo empezó, algo sigue ocurriendo, algo se guardó, algo reclama atención, algo puede perderse, algo ya se perdió, algo apareció, algo cambió de marco, algo quedó completado.
La pregunta inicial era sencilla, pero difícil de formular:
PREGUNTA DEL CAPÍTULO
¿Por qué no tenemos un lenguaje más claro para hablar de lo que ocurre cuando una interfaz responde?
1. Lo que este libro ha intentado hacer
Este libro no ha intentado fundar una teoría definitiva de la interfaz. Ha intentado algo más concreto: nombrar la capa de eventos perceptivos que ya existe entre el sistema y el usuario.
Para nombrarla, el libro ha propuesto una gramática: evento → familia semántica → verbo/fase → evaluación → intent → canales de expresión → lectura unificada.
2. La interfaz como contexto operativo perceptible
La primera decisión fue dejar de entender la interfaz solo como superficie. Una interfaz es la dimensión perceptible de un contexto operativo. El componente sigue importando, pero deja de ser la unidad central del significado. Lo que importa no es solo qué objeto hay en la interfaz. Importa qué evento hace perceptible.
3. El evento como unidad básica de cambio
La segunda decisión fue tomar el evento como unidad básica. No el evento técnico del navegador. No el callback. No el estado interno. Sino el cambio perceptible que modifica la relación del usuario con el sistema.
4. Las familias semánticas
Para ordenar esos eventos, el libro propuso ocho familias como siete preguntas perceptivas recurrentes:
5. El intent más allá del color
Después vino la pregunta evaluativa. Durante años hemos tratado success, warning, danger e info como si fueran una taxonomía suficiente. Pero gran parte de esa estructura procede de una herencia cromática. El libro propuso separar el intent del color. Un intent es una región evaluativa del evento: neutral, affirm, fulfill, risk, threat, loss. Un autoguardado no es una culminación. Un riesgo corregible no es una amenaza activa. Una amenaza no es una pérdida consumada. El color puede reforzar todo eso. Pero no debe definirlo.
6. Los canales como materia sensible
Un evento no existe en abstracto. Debe materializarse por canales: tiempo, motion, presencia, profundidad, forma, color, sonido, háptica. Pero ningún canal debería cargar solo con todo el significado. Una semántica robusta puede migrar. La accesibilidad no es posterior a la semántica. Es la prueba.
7. Composición, matrices y validación
La última parte intentó convertir la teoría en herramienta. Composiciones, matrices, rangos, fichas de migración, antipatrones y protocolos de validación. No como burocracia, sino como formas de hacer una pregunta simple: ¿la interfaz comunica el evento que cree comunicar?
8. Lo que este libro viene a completar
Este libro no nace contra la teoría de interfaces existente. No intenta corregir desde fuera todo lo que el diseño de interacción, la usabilidad, la accesibilidad, la arquitectura de información, los sistemas de diseño, la ergonomía, la psicología de la percepción o la investigación HCI ya han construido.
Existen teorías, métodos y guías muy desarrolladas para pensar la interfaz: cómo organizar información, cómo diseñar flujos, cómo construir componentes, cómo hacer sistemas consistentes, cómo asegurar accesibilidad, cómo evaluar usabilidad, cómo jerarquizar contenido, cómo trabajar con affordances, cómo diseñar navegación, cómo reducir carga cognitiva.
Este libro no pretende sustituir nada de eso. Su intención es más limitada y más concreta.
Durante años de trabajo en front-end, algunas preguntas seguían apareciendo sin encontrar un lenguaje suficientemente preciso: ¿qué diferencia hay entre que el sistema reciba una acción y que confirme un resultado? ¿por qué una espera necesita sentirse viva? ¿cuándo una aparición es solo presencia y cuándo se convierte en señal? ¿por qué una amenaza no debería expresarse igual que una pérdida? ¿por qué el color ha cargado con demasiada semántica? ¿cómo migra el significado si el usuario reduce motion, no oye sonido o no distingue color?
Estas preguntas no niegan la teoría existente. Nacen en una zona que muchas veces queda entre varias disciplinas: entre componente y experiencia, entre estado técnico y percepción, entre efecto visual y significado, entre accesibilidad y semántica, entre motion y evento, entre color e intent.
Este libro intenta trabajar precisamente ahí. No redefine la interfaz desde cero. Propone una capa complementaria: una gramática perceptiva del evento.
DISTINCIÓN
Este libro no viene a reemplazar la teoría de interfaces. Viene a completarla desde la pregunta por el significado perceptivo del evento.
9. Lo que sí propone
Propone que la interfaz tiene una capa semántica que merece ser nombrada. Propone que entre el sistema técnico y la experiencia del usuario hay eventos perceptivos que pueden organizarse. Propone que el intent no debería vivir en el color, sino en la evaluación del evento. Propone que los canales deben coordinarse alrededor de una lectura única. Propone que la accesibilidad es una prueba de si el significado estaba bien distribuido. Y propone que el trabajo de interfaz necesita un lenguaje más preciso para hablar de lo que ocurre.
10. Volver al programador front-end
Al final, este libro vuelve al lugar del que salió. A un programador front-end enfrentado a decisiones aparentemente pequeñas: ¿este botón solo responde o confirma? ¿este loader tranquiliza o parece bloqueo? ¿esta alerta es riesgo o amenaza? ¿esta eliminación avisa o ya registra pérdida? ¿este modal es marco o mensaje? ¿qué cree el usuario que acaba de ocurrir?
Ninguna de esas preguntas es menor. Este libro ha intentado ofrecer un vocabulario para pensarlas con más claridad. No para eliminar la intuición. Sino para darle estructura.
11. Una teoría provisional
Toda gramática de interfaz debe ser provisional. Las plataformas cambiarán. Los dispositivos cambiarán. La IA modificará muchas interacciones. La háptica será más rica. Las interfaces espaciales traerán otros problemas. La accesibilidad seguirá ampliando el campo.
Por eso esta teoría no debe cerrarse sobre sí misma. Quizá algunas familias cambien. Quizá aparezcan nuevas. Quizá algunos intents se dividan. Quizá otros equipos encuentren mejores nombres. Eso no debilita el proyecto. Lo mantiene vivo.
Una gramática no existe para impedir que el lenguaje evolucione. Existe para hacer posible una conversación más precisa.
12. Cierre
Si este libro tiene algún valor, no está en haber resuelto definitivamente la interfaz. Está en haber intentado formular con claridad una pregunta que aparece una y otra vez en la práctica:
PRINCIPIO
¿Cuándo un cambio en la interfaz deja de ser efecto y se convierte en significado?
Las teorías existentes nos ayudan a pensar muchas cosas: estructura, usabilidad, accesibilidad, affordances, atención, percepción, diseño visual, navegación, consistencia, componentes y sistemas. Este libro ha intentado añadir una pieza más a esa conversación: el evento como unidad semántica perceptible.
Este libro empezó con fragmentación. Componentes por un lado. Estados por otro. Motion por otro. Color por otro. Sonido por otro. Accesibilidad por otro.
Y termina con una propuesta de unión: evento, familia, intent, canales, accesibilidad, validación. No como sistema cerrado. Sino como lenguaje compartido.
PRINCIPIO
La interfaz no solo debe funcionar. Debe hacer perceptible lo que ocurre.
PRINCIPIO
Este libro no intenta cerrar la teoría de la interfaz. Intenta ofrecer un lenguaje para una capa que ya estaba operando sin nombre.
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="4824"/><w:gridCol w:w="4824"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>FAMILIA
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>PREGUNTA
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>contact
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿el sistema ha sentido mi acción?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>commit
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿algo quedó fijado o tuvo consecuencia?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>signal
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿algo reclama mi atención?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>handle
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿estoy manipulando directamente un objeto?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>emerge
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿algo entró o salió del campo perceptivo?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>shift
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿cambió el contexto?
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>sustain
<w:tcPr><w:tcW w:type="dxa" w:w="4824"/></w:tcPr><w:p><w:r><w:t>¿esto sigue ocurriendo?


## APÉNDICE A

## Capa semántica declarativa
Esta gramática no debe implementarse como un sistema de variantes visuales. No se trata de reemplazar <Button variant="danger"> por otra variante con otro nombre.
La gramática del evento propone una capa declarativa por encima de componentes, tokens y patrones. Esa capa declara qué evento ocurre, a qué familia pertenece, si porta intent y qué canales de expresión deberían participar.
La secuencia conceptual es:
evento
→ familia
→ verbo / fase
→ intent si procede
→ firma de expresión
→ componente / patrón / tokens
En una implementación real, esta capa puede representarse como un DSL, un JSON, un mapa de morfos, una convención de documentación o una herramienta interna de sistema de diseño.
Ejemplo conceptual:
{
  "event": "deleteConfirmationOpen",
  "family": "emerge",
  "verb": "open",
  "intent": "threat",
  "expression": {
    "channels": ["presence", "depth", "shape", "color"],
    "persistence": "until-decision",
    "intensity": "high",
    "a11y": {
      "focus": "contained",
      "announcement": "assertive"
    }
  }
}
La regla técnica más importante es que el intent no se hereda de forma implícita. Se declara en el evento que lo porta. Si un diálogo tiene intent="threat", el morfo debe decidir qué evento declara ese intent: emerge.open, shift, signal.alert o commit.delete.
El runtime no debe adivinar. La semántica debe estar declarada.


## APÉNDICE B

## Firmas de expresión y matriz mínima
Una firma de expresión es la configuración concreta de canales, intensidad, duración, persistencia y huella con la que un evento se hace reconocible en un sistema concreto.
La familia y el intent dicen qué evento ocurre y cómo debe valorarse. La firma de expresión dice cómo se materializa esa lectura.
<w:tblPr><w:tblStyle w:val="TableGrid"/><w:tblW w:type="auto" w:w="0"/><w:tblLook w:firstColumn="1" w:firstRow="1" w:lastColumn="0" w:lastRow="0" w:noHBand="0" w:noVBand="1" w:val="04A0"/></w:tblPr><w:tblGrid><w:gridCol w:w="1608"/><w:gridCol w:w="1608"/><w:gridCol w:w="1608"/><w:gridCol w:w="1608"/><w:gridCol w:w="1608"/><w:gridCol w:w="1608"/></w:tblGrid><w:tr><w:trPr><w:tblHeader w:val="true"/></w:trPr><w:tc><w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Evento
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Canales principales
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Canales secundarios
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Intensidad
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Huella
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:rPr><w:b/></w:rPr><w:t>Accesibilidad
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>contact.press
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>tiempo, forma
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>motion, háptica
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>mínima
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>no
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>foco visible
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>commit.save + affirm
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>presencia, tiempo
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>color suave
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>baja
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>breve
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>texto si procede
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>commit.complete + fulfill
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>presencia, motion, forma
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>sonido opcional
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>media
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>sí
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>estado persistente
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>signal.warn + risk
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>forma, texto, presencia
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>color
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>media
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>hasta corrección
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>relación con campo
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>signal.alert + threat
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>presencia, profundidad, forma
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>sonido opcional
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>alta
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>hasta decisión
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>anuncio urgente
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>commit.delete + loss
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>presencia, forma, tiempo
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>color, motion
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>alta
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>sí
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>deshacer / mensaje persistente
<w:tc><w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>delegate.act
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>presencia, texto, sustain
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>motion
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>media
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>hasta retorno
<w:tcPr><w:tcW w:type="dxa" w:w="1608"/></w:tcPr><w:p><w:r><w:t>cancelar / revisar


## APÉNDICE C

## Tres casos de estudio

## Caso 1 — Formulario con error corregible
Un usuario envía un formulario y un campo obligatorio está vacío. La interfaz no debería tratar este caso como amenaza. Todavía hay margen de acción.
Secuencia:
contact.press
→ signal.warn + risk
→ focus.field
→ commit.block + risk
Firma de expresión: mensaje junto al campo, forma clara, color moderado, persistencia hasta corrección y foco orientado si el envío queda bloqueado.

## Caso 2 — Eliminación con confirmación y deshacer
Un usuario intenta eliminar un elemento. Antes de confirmar, la interfaz introduce una situación de amenaza. Después de confirmar, comunica pérdida y mantiene una huella si existe deshacer.
Secuencia:
contact.press
→ emerge.open + threat
→ signal.alert + threat
→ commit.delete + loss
→ emerge.present-undo
Firma de expresión: diálogo claro, foco contenido, acciones diferenciadas, mensaje persistente tras la eliminación y opción de recuperación mientras sea válida.

## Caso 3 — Sistema que propone y aplica cambios
Un sistema propone modificar varios campos, espera revisión y aplica cambios tras autorización. El problema principal no es solo el resultado, sino quién actúa y cuándo.
Secuencia:
delegate.plan
→ signal.warn + risk
→ delegate.review
→ delegate.authorize
→ delegate.act
→ sustain.processing
→ commit.apply + affirm
Firma de expresión: explicación del alcance, estado visible del sistema, posibilidad de cancelar, revisión explícita y confirmación de resultado aplicado.


## Glosario
Contexto operativo: Conjunto de información del sistema, estados visibles, restricciones y operaciones disponibles que determinan qué puede hacer el usuario, qué significa cada acción y qué resultado puede producir.
Interfaz: Medio por el que una persona percibe, interpreta y actúa sobre un contexto operativo.
Evento: Cambio perceptible del contexto operativo que afecta a lo que el usuario puede hacer, debe atender o necesita interpretar.
Evento técnico: Ocurrencia registrada por el sistema, como click, submit, change o dragstart.
Unidad básica de cambio: Función del evento dentro de la gramática: no el fragmento más pequeño, sino la unidad desde la que se analiza qué cambió para el usuario.
Gramática del evento: Sistema de diferencias, relaciones y reglas de composición que permite hacer reconocibles clases significativas de cambio.
Familia semántica: Clase recurrente de evento que responde a una pregunta estable del usuario.
Interacción semántica: Forma recurrente con la que una interfaz hace reconocible una familia de evento.
Firma de expresión: Configuración concreta de canales, intensidad, duración, persistencia y huella con la que se expresa un evento.
Intent: Valoración que declara un evento cuando debe percibirse como neutro, confirmatorio, resolutivo, corregible, amenazante o perdido.
Canales de expresión: Vías por las que un evento se hace perceptible: tiempo, motion, presencia, profundidad, forma, color, sonido y háptica.
Contact: Familia que comunica que el sistema ha sentido una acción.
Commit: Familia que comunica que un resultado se ha aplicado, fallado, completado o perdido.
Signal: Familia que reclama atención.
Handle: Familia de manipulación directa.
Emerge: Familia de aparición, retirada o disponibilidad.
Shift: Familia de cambio de contexto.
Sustain: Familia de continuidad o proceso en curso.
Delegate: Familia donde cambia quién actúa, quién tiene la iniciativa o quién ejecuta parte de la acción.
Neutral: Intent de baja carga: algo debe notarse sin tono fuerte.
Affirm: Confirmación positiva suave.
Fulfill: Cierre positivo de una tensión u objetivo cumplido.
Risk: Problema corregible.
Threat: Amenaza activa que todavía puede evitarse.
Loss: Pérdida ya producida o disponibilidad perdida.
Huella: Modo en que un evento sigue importando después de su expresión visible.
Migración de significado: Traslado de una lectura a otros canales cuando un canal se reduce, falla o no está disponible.


## Índice analítico
acción delegada: delegate; capítulos 8, 29, 36; apéndice C
accesibilidad: capítulos 3, 19, 33; apéndice B
canales de expresión: parte II; capítulos 11-20
commit: capítulos 8, 23
contact: capítulos 8, 22
contexto operativo: capítulos 1, 4
delegate: capítulos 8, 29, 36; apéndice C
evento: capítulos 1, 4, 5
firma de expresión: apéndice B; capítulo 36
handle: capítulos 8, 25
intent: capítulos 9, 10
loss: capítulo 10
migración de significado: capítulos 19, 33
risk: capítulo 10
shift: capítulos 8, 27
signal: capítulos 8, 24
sustain: capítulos 8, 28
threat: capítulo 10
unidad básica de cambio: capítulo 4


## Referencias bibliográficas
Amershi, S., Weld, D., Vorvoreanu, M., et al. (2019). Guidelines for Human-AI Interaction. Proceedings of CHI 2019.
Brewster, S. & Brown, L. M. (2004). Tactons: Structured Tactile Messages for Non-Visual Information Display.
de Souza, C. S. (2005). The Semiotic Engineering of Human-Computer Interaction. MIT Press.
Gibson, J. J. (1979). The Ecological Approach to Visual Perception. Houghton Mifflin.
Hutchins, E., Hollan, J. & Norman, D. (1985). Direct Manipulation Interfaces. Human-Computer Interaction.
Kaptelinin, V. & Nardi, B. (2006). Acting with Technology: Activity Theory and Interaction Design. MIT Press.
Merleau-Ponty, M. (1945). Phenomenology of Perception.
Michotte, A. (1946). The Perception of Causality.
Nielsen, J. (1993). Usability Engineering. Morgan Kaufmann.
Norman, D. A. (2013). The Design of Everyday Things. Basic Books.
Rasmussen, J. & Vicente, K. J. (1989). Coping with human errors through system design: implications for ecological interface design.
Russell, J. A. (1980). A Circumplex Model of Affect. Journal of Personality and Social Psychology.
Scherer, K. R. (2005). What are emotions? And how can they be measured? Social Science Information.
Shneiderman, B. (1983). Direct Manipulation: A Step Beyond Programming Languages. IEEE Computer.
Spence, C. (2011). Crossmodal correspondences: A tutorial review. Attention, Perception, & Psychophysics.
Suchman, L. (1987). Plans and Situated Actions. Cambridge University Press.
Vicente, K. J. (2002). Ecological Interface Design: Progress and Challenges. Human Factors.
W3C. Web Content Accessibility Guidelines (WCAG) 2.2.
W3C. WAI-ARIA Authoring Practices Guide.
W3C Design Tokens Community Group. Design Tokens Format Module.
Wagemans, J., Elder, J. H., Kubovy, M., et al. (2012). A century of Gestalt psychology in visual perception. Psychological Bulletin.
