“Mejora la UI/UX” es uno de los peores prompts que puedes darle a un agente. No define para quién, qué tarea debe mejorar ni cómo distinguir una solución usable de una pantalla simplemente más decorada.
El resultado suele ser reconocible: más gradientes, más cards, más animaciones y la misma duda de siempre:
¿Qué tengo que hacer aquí?
Una forma mucho más útil de dirigir una revisión es trabajar con diez principios explícitos:
- Semantic UX Writing
- Visual Affordance
- Visual Hierarchy
- Cognitive Load Reduction
- Systemic Consistency
- Immediate Feedback
- Discoverability
- Contextual Interaction Design
- Invisible Complexity
- Operational Clarity
La lista es una síntesis práctica, no un decálogo académico publicado como conjunto. Su valor está en que reúne ideas que sí tienen fundamentos sólidos: los signifiers de Don Norman, las heurísticas de Jakob Nielsen, la carga cognitiva de John Sweller, el diseño de contenido de GOV.UK, los estados de Material Design y los criterios verificables de WCAG.
Esta guía convierte esa síntesis en un contrato operativo: qué observar, qué pedirle a un agente, qué aceptar y cómo comprobar que el cambio mejoró la tarea.
Lo que el marco resuelve —y lo que todavía le falta
Los diez principios cubren cuatro preguntas que una interfaz debe responder:
Es una cobertura muy buena de comprensión, atención y estado. Pero usarla como único criterio deja cuatro huecos:
- Accesibilidad. Algo puede parecer claro y seguir siendo invisible para teclado o lector de pantalla.
- Prevención y recuperación de errores. El feedback posterior no sustituye undo, confirmaciones proporcionales ni conservación de datos.
- Control del usuario. Ocultar complejidad no autoriza a esconder consecuencias o ejecutar decisiones irreversibles.
- Evidencia. Una interfaz no mejora porque el agente diga que ahora es “más intuitiva”; hay que recorrer la tarea.
No añadiremos otros cuatro puntos al decálogo. Los trataremos como gates transversales: los diez principios deben pasar por ellos.
Affordance: el término que usamos mal
En diseño digital decimos que un botón tiene affordance cuando “parece presionable”. Técnicamente estamos mezclando dos conceptos.
- Una affordance es la relación entre un actor y las acciones que un entorno permite.
- Un signifier es la señal perceptible que comunica dónde y cómo actuar.
Una superficie táctil permite tocar casi cualquier píxel. Esa es la affordance. El borde, color, etiqueta, sombra, cursor y cambio de estado que revelan “esto es un botón” son signifiers.
Don Norman corrigió esta confusión de forma explícita: para las interfaces virtuales, los signifiers suelen importar más que la affordance real porque permiten descubrirla. Su ensayo Signifiers, not affordances explica que las personas buscan pistas para construir un modelo de lo que ocurre y de las acciones disponibles.
Mantendremos “Visual Affordance” porque es el término que los equipos reconocen, pero el criterio correcto será:
¿La acción existe, la persona puede descubrirla y sus signifiers comunican cómo usarla?
Los diez principios convertidos en criterios verificables
Una frase aspiracional no basta. Cada principio necesita una pregunta, una práctica y una forma de comprobarlo.
1. Semantic UX Writing: las palabras son parte del control
El copy no acompaña a la interfaz. Es interfaz.
Enviar, Continuar o Aceptar pueden ser correctos sólo si el contexto elimina toda ambigüedad. En cuanto hay dos interpretaciones posibles, el botón debe nombrar el resultado:
| Débil | Específico |
|---|---|
| Enviar | Enviar cotización |
| Aceptar | Aceptar invitación |
| Continuar | Revisar pedido |
| Error 422 | El archivo no incluye la columna «correo» |
| No hay datos | Aún no hay pedidos. Crea el primero para comenzar. |
La guía oficial de GOV.UK para escribir interfaces recomienda usar el lenguaje de las personas, poner las palabras importantes al inicio y corregir la interfaz cuando necesita demasiadas instrucciones.
Pregunta de revisión: ¿el texto comunica objeto, acción, estado y consecuencia sin jerga interna?
Criterio de aceptación: cada CTA puede entenderse fuera de la maqueta y cada error explica qué ocurrió y qué puede hacer la persona.
No uses un icono para evitar una palabra cuando el icono requiere tooltip. El tooltip puede complementar; no debe rescatar una acción indescifrable.
2. Visual Affordance: haz visible la posibilidad de actuar
Los elementos interactivos necesitan señales suficientes:
- forma y contraste respecto al contenido;
- cursor y área táctil;
- etiqueta o icono reconocido;
- estados
hover,focus,active,selectedydisabled; - relación espacial con el objeto que modifican;
- respuesta al activarse.
Un texto gris que parece párrafo pero abre un modal tiene mala affordance percibida. Una card completa que es clicable pero sólo revela el click al pasar el mouse falla en touch. Un icono de tres puntos sin nombre accesible existe visualmente, pero no para un lector de pantalla.
WCAG 2.2 exige que nombre, rol y valor puedan ser determinados por software; también incorpora un target mínimo de 24×24 CSS px en nivel AA, con excepciones específicas. El tamaño, sin embargo, sólo vuelve tocable al control: no lo vuelve comprensible.
Pregunta de revisión: ¿una persona puede distinguir qué es interactivo y anticipar el tipo de acción?
Criterio de aceptación: el control funciona con mouse, touch y teclado; tiene nombre accesible y sus estados no dependen únicamente del color.
3. Visual Hierarchy: el orden visual es una instrucción silenciosa
La jerarquía determina qué procesa primero el ojo. No se resuelve agrandando el título; se construye con:
- orden en el DOM y en la composición;
- escala tipográfica;
- contraste;
- proximidad y separación;
- alineación;
- densidad;
- énfasis reservado para lo importante.
Si el CTA, tres badges, un banner, seis métricas y una ilustración usan el mismo contraste, la pantalla no tiene seis prioridades: no tiene ninguna.
Haz la prueba de cinco segundos:
- muestra la pantalla;
- ocúltala;
- pregunta qué página era, qué dato importaba y cuál era la acción principal.
No es un estudio completo, pero detecta una jerarquía rota con rapidez.
Pregunta de revisión: ¿la atención llega primero al objetivo y después a la evidencia necesaria para decidir?
Criterio de aceptación: título, estado y acción primaria se identifican sin leer cada bloque.
4. Cognitive Load Reduction: elimina trabajo mental, no capacidad
La investigación de John Sweller partió de una limitación: el procesamiento cognitivo disponible es finito. Su paper de 1988, Cognitive Load During Problem Solving, estudió cómo ciertas demandas de resolución consumen capacidad que ya no queda disponible para aprender.
En UI la traducción debe hacerse con cautela: no significa que exista un número mágico de botones. Significa que una tarea empeora cuando obliga a:
- recordar información entre pantallas;
- traducir términos del sistema al lenguaje propio;
- comparar demasiadas opciones simultáneas;
- repetir datos ya proporcionados;
- filtrar contenido irrelevante;
- deducir por qué una acción no está disponible.
Nielsen lo formula como reconocimiento antes que recuerdo. Muestra opciones, historial y ayuda donde se necesitan. La divulgación progresiva puede reducir ruido, siempre que lo frecuente permanezca visible y el acceso a lo avanzado sea descubrible.
Pregunta de revisión: ¿qué debe recordar, deducir o decidir la persona que el sistema podría resolver?
Criterio de aceptación: los datos relevantes permanecen visibles, existen defaults seguros y la información secundaria no compite con la tarea.
Minimalismo no es esconder todo. Nielsen Norman Group advierte que interfaces demasiado “zen” pueden aumentar cambios de atención y costo de interacción.
5. Systemic Consistency: la coherencia libera memoria
Hay dos consistencias:
- Interna: el producto usa el mismo componente, término y comportamiento para la misma intención.
- Externa: respeta convenciones de la plataforma y del dominio.
Si “cliente”, “cuenta” y “organización” nombran la misma entidad, el usuario debe mantener un diccionario mental. Si un botón cempasúchil guarda en una pantalla y elimina en otra, el sistema enseña una regla falsa.
La consistencia no obliga a que todo se vea idéntico. Un componente debe variar cuando cambia su función o riesgo. La guía de Nielsen lo resume así: las personas no deberían preguntarse si palabras o acciones distintas significan lo mismo.
Pregunta de revisión: ¿el sistema reutiliza patrones por intención o sólo por parecido visual?
Criterio de aceptación: existe un término por concepto y una variante documentada por tipo de acción, estado y riesgo.
6. Immediate Feedback: toda acción abre una deuda de información
Cuando alguien actúa, el sistema debe cerrar tres incertidumbres:
- ¿recibió mi acción?
- ¿está trabajando?
- ¿cuál fue el resultado?
Material Design trata hover, focus, pressed, dragged, disabled y otros como estados de interacción, no como decoración opcional. Nielsen vincula la visibilidad del estado con control y confianza.
No todo feedback necesita un toast:
| Evento | Feedback apropiado |
|---|---|
| Toggle local | Cambio inmediato de posición y nombre/estado accesible |
| Guardado corto | Estado inline: Guardando → Guardado |
| Proceso largo | Progreso real, tarea en curso y posibilidad de continuar |
| Alta exitosa | Confirmación con resultado y siguiente acción |
| Error recuperable | Mensaje junto al origen, dato conservado y corrección |
| Acción asíncrona | Estado persistente consultable; no un toast que desaparece |
Para lectores de pantalla, WCAG 2.2 incluye el criterio Status Messages: ciertos cambios de estado deben poder anunciarse sin mover el foco.
Pregunta de revisión: ¿el feedback responde a la incertidumbre real o sólo muestra animación?
Criterio de aceptación: toda acción relevante comunica recepción, proceso y resultado por medios visuales y accesibles.
7. Discoverability: una función invisible no existe para quien la necesita
Una interfaz puede ser eficiente después de aprenderla y pésima al primer uso.
Fallos frecuentes:
- acciones disponibles sólo al hacer hover;
- swipe sin alternativa visible;
- drag-and-drop sin botón equivalente;
- atajos sin un camino normal;
- iconos ambiguos sin etiqueta;
- búsqueda escondida dentro de otro menú;
- selección por click en toda una fila sin indicación.
Discoverability no significa exponer todas las funciones. Significa que las importantes tienen una entrada visible y las avanzadas dejan un rastro claro. La divulgación progresiva funciona cuando el control “Opciones avanzadas” establece una expectativa concreta; falla cuando “Más” es un cajón impredecible.
Pregunta de revisión: ¿cómo descubre esta acción alguien que nunca vio el producto?
Criterio de aceptación: la tarea principal y sus alternativas no requieren memoria, ensayo ciego ni instrucciones externas.
8. Contextual Interaction Design: muestra lo pertinente sin volver inestable la UI
El contexto puede ser:
- etapa del flujo;
- rol y permisos;
- objeto seleccionado;
- estado del sistema;
- frecuencia de uso;
- dispositivo;
- riesgo.
Un editor puede mostrar herramientas de imagen cuando hay una imagen seleccionada. Un dashboard puede priorizar facturas vencidas para cobranza. Eso reduce ruido.
Pero hay una frontera: si una acción desaparece o cambia de lugar sin explicación, la reducción de carga crea una nueva carga. Para funciones frecuentes, suele ser mejor mantener la posición y reflejar el estado —incluido explicar por qué no está disponible— que teletransportar el control.
Pregunta de revisión: ¿el contexto mejora relevancia sin romper predictibilidad?
Criterio de aceptación: lo frecuente mantiene una ubicación estable; lo contextual aparece junto al objeto o momento que lo activa.
9. Invisible Complexity: el sistema trabaja para la persona
La complejidad no desaparece: cambia de lugar.
Buenos ejemplos:
- detectar formato de fecha sin pedirlo;
- completar datos conocidos;
- guardar borradores;
- elegir un default seguro;
- agrupar configuración avanzada;
- reintentar fallos transitorios;
- traducir códigos técnicos a acciones humanas.
Malos ejemplos:
- ocultar una comisión hasta el último paso;
- decidir automáticamente algo irreversible;
- esconder permisos concedidos;
- reemplazar toda configuración por una “caja mágica” imposible de corregir;
- eliminar detalles que una persona experta necesita auditar.
El objetivo no es hacer invisible el sistema. Es volver invisible la mecánica innecesaria y transparente la consecuencia importante.
Pregunta de revisión: ¿qué complejidad puede absorber el producto y cuál debe permanecer bajo control humano?
Criterio de aceptación: los defaults son reversibles, las consecuencias son visibles y el detalle técnico está disponible bajo demanda.
10. Operational Clarity: estado actual, siguiente acción y resultado
Este principio cierra a los otros nueve. En cualquier momento, una persona debería poder responder:
- ¿dónde estoy?
- ¿qué estado tiene mi trabajo?
- ¿qué acción principal está disponible?
- ¿qué ocurrirá si la ejecuto?
- ¿qué debo hacer después?
- ¿puedo volver, cancelar o recuperar?
Una barra de progreso que sólo dice 67% puede carecer de claridad operacional. Importando 670 de 1,000 clientes · puedes cerrar esta ventana explica estado, avance y libertad.
Un mensaje Guardado puede ser insuficiente. Borrador guardado · publica cuando esté listo aporta resultado y siguiente paso.
Pregunta de revisión: ¿la interfaz mantiene orientación antes, durante y después de la acción?
Criterio de aceptación: cada estado importante tiene nombre, consecuencia, salida y siguiente paso cuando aplica.
Los cuatro gates que ningún rediseño puede saltarse
Gate 1: accesibilidad
WCAG 2.2 organiza accesibilidad bajo cuatro principios: perceptible, operable, comprensible y robusto. Para una revisión de UI, empieza por:
- HTML semántico;
- teclado y orden de foco;
- foco visible y no oculto;
- labels y nombres accesibles;
- contraste de texto y controles;
- reflow y zoom;
- target size;
- mensajes de estado;
- alternativa a drag, gesto y color.
Accesibilidad no es un “modo especial”. Es la prueba de que los signifiers no dependen de una sola forma de percibir o actuar.
Gate 2: prevención y recuperación
El Design System de GOV.UK pide que un error explique qué salió mal y cómo corregirlo. Añade:
- validar cerca del campo y conservar datos;
- prevenir condiciones peligrosas;
- usar confirmación según riesgo, no para todo;
- ofrecer undo cuando sea posible;
- separar errores del usuario de fallos del servicio.
Algo salió mal no es feedback: es la confesión de que el producto no sabe ayudar.
Gate 3: control del usuario
La automatización debe informar antes de generar consecuencias y permitir salida cuando exista una alternativa razonable. Cancelar, regresar, editar y deshacer no son detalles secundarios: construyen confianza.
Gate 4: evidencia
La auditoría produce hipótesis. La verificación produce evidencia.
Como mínimo:
- recorre la tarea crítica en navegador;
- prueba móvil y escritorio;
- navega con teclado;
- fuerza
loading,empty,error,successy permisos; - comprueba copy y nombres accesibles;
- registra qué no pudo validarse.
Después usa tests con personas, analítica de abandono, errores y tiempo de tarea para comprobar los supuestos de mayor impacto.
Gate condicional: Calibrated Agency
Si la interfaz incorpora IA o automatización, aparece un problema adicional: el sistema puede interpretar, planear y actuar más allá del click explícito.
En ese caso también debes:
- distinguir si la IA informa, recomienda, prepara o ejecuta;
- comunicar capacidades, límites e incertidumbre relevante;
- mostrar target, diff y consecuencias antes de acciones sensibles;
- permitir corrección, cancelación y recuperación;
- usar permisos mínimos y fronteras técnicas;
- conservar un activity log verificable;
- diseñar la Agent‑Computer Interface de sus herramientas.
Desarrollamos este gate en Agentic UX: cómo diseñar interfaces para agentes de IA sin perder el control, con niveles de autonomía, commit boundaries, patrones de permisos, ACI y evals.
Ejemplo trabajado: importar clientes
Imagina este flujo:
[ Arrastra archivo aquí ]
[ Procesar ]Al presionar Procesar aparece un spinner. Dos minutos después:
Error 422Visualmente es limpio. Operacionalmente es opaco.
Auditoría
| Severidad | Evidencia | Principio | Impacto |
|---|---|---|---|
| S1 | No dice formatos o columnas admitidas | UX Writing / Discoverability | Ensayo y error |
| S1 | Drag es la única entrada visible | Affordance / Accesibilidad | Bloquea teclado y móvil |
| S1 | Error 422 no permite corregir | Feedback / Claridad | Pérdida de tarea |
| S2 | Procesar no describe resultado | UX Writing | Consecuencia ambigua |
| S2 | Spinner sin progreso ni salida | Operational Clarity | Incertidumbre y repetición |
Resultado propuesto
Importar clientes
Archivo CSV de hasta 20 MB. Descarga una plantilla.
[ Seleccionar archivo CSV ] o arrástralo aquí
clientes-julio.csv · 1,000 filas
[ Revisar e importar 1,000 clientes ]
Importando 670 de 1,000 clientes
Puedes cerrar esta ventana. Te avisaremos al terminar.
Importación terminada
982 clientes creados · 18 filas necesitan corrección
[ Descargar filas con error ] [ Ver clientes ]No sólo agregamos texto. Hicimos visible el contrato, añadimos una alternativa al drag, nombramos la consecuencia, comunicamos progreso y convertimos un error técnico en recuperación.
Cómo usar estos principios con un agente de código
Un prompt útil necesita contexto y un contrato de salida. Antes de pegar los diez principios, especifica:
Producto: panel de cobranza
Usuario: analista que procesa 100-300 cuentas al día
Tarea crítica: detectar vencidos y registrar una promesa de pago
Contexto: desktop, uso repetido, alta presión, teclado frecuente
Restricciones: conservar componentes y tokens existentes
Modo: auditar primero; implementar sólo S0/S1Después obliga al agente a separar observación de preferencia:
Para cada hallazgo entrega:
- evidencia visible o reproducible;
- principio afectado;
- impacto en la tarea;
- severidad S0-S3;
- cambio mínimo;
- criterio verificable de aceptación.Y define una secuencia:
- inspeccionar;
- recorrer la tarea;
- auditar;
- priorizar;
- implementar sólo lo autorizado;
- volver a recorrer;
- reportar evidencia y pendientes.
Sin esa secuencia, el agente tiende a editar mientras descubre, y termina justificando el rediseño que ya hizo.
Prompt completo listo para reutilizar
Publicamos el Prompt operativo para revisar UI/UX y affordance. Incluye:
- modo
AUDITARoIMPLEMENTAR; - variables de usuario, tarea, contexto y restricciones;
- definiciones operativas de los diez principios;
- gates de accesibilidad, errores, control y evidencia;
- matriz de estados;
- severidades S0–S3;
- formato obligatorio de hallazgos;
- Definition of Done;
- una versión breve para componentes pequeños.
La instrucción más importante es ésta:
No rediseñes por estética. Prefiere el cambio más pequeño que mejore la comprensión y mantenga el sistema consistente.
Scorecard para comparar antes y después
Usa la escala como herramienta de conversación, no como “ciencia” ni para comparar productos distintos:
0: ausente o bloquea la tarea;1: débil, ambiguo o inconsistente;2: adecuado con fricción menor;3: claro, consistente y verificado.
| Principio | 0–3 | Evidencia |
|---|---|---|
| Semantic UX Writing | ||
| Visual Affordance | ||
| Visual Hierarchy | ||
| Cognitive Load | ||
| Systemic Consistency | ||
| Immediate Feedback | ||
| Discoverability | ||
| Contextual Interaction | ||
| Invisible Complexity | ||
| Operational Clarity |
No promedies un bloqueo. Si el flujo es inaccesible, pierde datos o ejecuta una acción destructiva sin control, falla aunque el total sea 27/30.
Checklist para code review
- El CTA nombra una acción y un resultado concretos.
- Links, botones, inputs y filas interactivas se distinguen del contenido.
- La acción primaria domina sin competir con múltiples acentos.
- La persona reconoce datos y opciones sin recordarlos entre pantallas.
- Un concepto conserva el mismo término y componente.
- Existen estados
focus,loading,success,empty,errorydisabledcuando aplican. - Las funciones críticas no dependen sólo de hover, gesture, drag o atajo.
- Las acciones contextuales aparecen cerca de su objeto sin moverse de forma impredecible.
- Los defaults reducen trabajo y pueden corregirse.
- Estado actual, siguiente paso y salida son visibles.
- La tarea funciona con teclado y no comunica sólo por color.
- Los errores conservan datos y explican cómo recuperarse.
- El cambio fue recorrido en móvil y escritorio.
- La PR aporta evidencia, no sólo adjetivos.
Para profundizar en las leyes psicológicas detrás de varias decisiones, consulta nuestra guía de referencia de leyes de UX para developers. Para validar una interfaz con observación humana, la síntesis de No me hagas pensar explica un método ligero y recurrente.
Preguntas frecuentes
¿Visual affordance y discoverability son lo mismo?
No. La affordance describe la posibilidad de actuar y sus signifiers inmediatos; discoverability cubre si la función puede encontrarse dentro del producto. Un botón puede parecer perfectamente clicable y estar escondido en un lugar imposible de descubrir.
¿Más microcopy siempre mejora claridad?
No. El texto compensa una interfaz sólo hasta cierto punto. Si necesitas un párrafo para explicar un control, cambia el control. El copy debe resolver intención o incertidumbre real.
¿Debo mostrar siempre los botones deshabilitados?
Depende. Mantenerlos visibles puede enseñar la siguiente acción y preservar estabilidad, pero hay que explicar qué requisito falta. Si la acción jamás aplica al rol o contexto actual, ocultarla puede ser más claro.
¿Una UI minimalista reduce carga cognitiva?
Sólo si elimina información irrelevante sin esconder señales necesarias. Menos elementos puede producir más memoria, navegación y ensayo.
¿Puede una IA validar que la UX mejoró?
Puede inspeccionar consistencia, semántica, estados, accesibilidad automatizable y recorridos reproducibles. No puede inventar la comprensión de usuarios reales. Los cambios de mayor riesgo deben observarse con personas y métricas.
¿Este marco sustituye WCAG o una prueba de usabilidad?
No. Es un protocolo de revisión. WCAG aporta criterios técnicos de accesibilidad y las pruebas con personas revelan modelos mentales, contexto y problemas que una heurística no predice.
Fuentes y fundamentos
- Signifiers, not affordances — Don Norman
- The Design of Everyday Things, Revised Edition — Don Norman
- 10 Usability Heuristics — Nielsen Norman Group
- Progressive Disclosure — Nielsen Norman Group
- Cognitive Load During Problem Solving — John Sweller
- Writing for user interfaces — GOV.UK
- Error messages — GOV.UK Design System
- States — Material Design 3
- Web Content Accessibility Guidelines 2.2 — W3C
Una buena interfaz no obliga a admirar el diseño. Permite actuar con certeza. Si el usuario entiende qué significa, qué puede hacer, qué está ocurriendo y qué sigue, el diseño ya está haciendo su trabajo.