markhougaard/ux-laws

Leyes de UX — índice y protocolo

Este archivo selecciona el modo, elige cuáles de las 30 leyes aplican y define cómo se usan juntas y cómo informar. Cada ley reside en su propio archivo bajo references/, nombrado como en las tablas siguientes (fitts-law → references/fitts-law.md). Abre solo los que selecciones.

Si el usuario nombra una ley ("revisa este formulario contra la Ley de Postel"), abre solo esa referencia y úsala en el modo que pidió. Las revisiones siguen la sección 5 aquí.

0. Archivos y entorno

Este skill funciona en cualquier agente que pueda leer archivos. No depende de herramientas particulares.

• Las rutas en cada archivo de este skill, incluidas las referencias, son relativas al directorio que contiene este SKILL.md. references/fitts-law.md siempre significa <directorio del skill>/references/fitts-law.md, incluso cuando aparece dentro de otro archivo de referencia.
• Si no puedes abrir los archivos de referencia (por ejemplo, este texto fue pegado en un prompt sin su carpeta), dímelo y pide los archivos de ley que necesites. No ejecutes comprobaciones desde la memoria: los IDs de comprobación, las severidades y los tipos de evidencia están definidos solo en esos archivos.
• La evidencia depende de lo que puedas inspeccionar. Si no puedes ver imágenes, las capturas de pantalla y los mocks no cuentan como evidencia static para ti; revisa cualquier texto o código que tengas y menciónalo en la línea de alcance. Si no puedes ejecutar el artefacto, interactive y runtime están fuera de alcance a menos que el usuario proporcione grabaciones o mediciones.

1. Elegir el modo

Modo	Cuándo usarlo	Qué produces
Asesorar	Solo existe un objetivo, un brief, un enunciado del problema, un elemento de la hoja de ruta o un concepto temprano.	Un breve informe de dirección: las leyes que más importan aquí, los riesgos que predicen, las preguntas que el equipo debe responder y las decisiones a tomar ahora.
Construir	Un diseño o implementación está en progreso y necesita una referencia.	Orientación específica para el componente o pantalla en cuestión, extraída del Modo 2 de las leyes relevantes, con valores concretos cuando existan.
Revisar	Un diseño terminado, prototipo, conjunto de capturas de pantalla, URL o diff de código está a punto de ser commiteado.	Un informe estricto de hallazgos con severidades, evidencia, correcciones y un veredicto.

Si la solicitud no lo dice, infiérelo de la entrada: un objetivo → Asesorar; trabajo en progreso → Construir; un artefacto terminado → Revisar. Si aún no está claro, haz una pregunta.

2. Seleccionar las leyes

No abras las 30 para cada tarea. Selecciona por situación, luego añade aquellas cuyos disparadores coincidan con lo que ves.

Base para cualquier revisión de UI (siempre ejecutar): fitts-law, jakobs-law, cognitive-load, law-of-proximity, law-of-similarity, selective-attention, cognitive-bias. Añade doherty-threshold siempre que el artefacto sea interactivo.

Por situación:

Situación	Abrir
Formularios, entrada de datos, registro	postels-law, working-memory, chunking, law-of-proximity, parkinsons-law, goal-gradient-effect
Navegación, menús, arquitectura de información	hicks-law, serial-position-effect, mental-model, jakobs-law, chunking, pareto-principle
Paneles, herramientas densas en datos y para expertos	cognitive-load, chunking, law-of-common-region, law-of-pragnanz, flow, pareto-principle
Visualización de datos y diagramas	law-of-pragnanz, law-of-uniform-connectedness, law-of-similarity, von-restorff-effect
Incorporación, primera ejecución, ayuda	paradox-of-the-active-user, goal-gradient-effect, zeigarnik-effect, cognitive-load, mental-model
Precios, planes, catálogos, pago	choice-overload, hicks-law, cognitive-bias, von-restorff-effect, serial-position-effect, peak-end-rule
Notificaciones, alertas, estado	selective-attention, von-restorff-effect, flow, zeigarnik-effect
Móvil y táctil	fitts-law, law-of-proximity, serial-position-effect, doherty-threshold
Rendimiento, carga, trabajo asíncrono	doherty-threshold, goal-gradient-effect, peak-end-rule, flow
Rediseños y migraciones	jakobs-law, mental-model, serial-position-effect, aesthetic-usability-effect
Automatización, IA y funciones inteligentes	teslers-law, mental-model, cognitive-bias, doherty-threshold
Alcance, priorización, hoja de ruta	pareto-principle, occams-razor, teslers-law, hicks-law
Trabajo de diseño visual y sistema de diseño	aesthetic-usability-effect, law-of-similarity, law-of-proximity, law-of-common-region, law-of-pragnanz, von-restorff-effect
Errores, fallos y finales	peak-end-rule, postels-law, selective-attention, mental-model

Sigue las Leyes relacionadas de cada ley abierta solo cuando un hallazgo o pregunta realmente toque esa ley.

3. Protocolo de asesoramiento

1. Reformula el objetivo, los usuarios y el contexto en dos o tres líneas. Si se desconocen los usuarios o el contexto, dilo — ese es el primer riesgo.
2. Selecciona 3–6 leyes de la tabla. Más de seis diluye el consejo.
3. Para cada una, da el uno o dos riesgos que predice para este proyecto y la pregunta que el equipo debe responder. Usa el Modo 1 de la ley como fuente, pero hazlo específico.
4. Enumera las decisiones a tomar ahora (presupuestos, valores predeterminados, convenciones, reglas de énfasis, medición) y quién debería poseerlas.
5. Señala las tensiones entre leyes que requerirán una elección deliberada (ver sección 6).

Mantenlo aproximadamente en una página. El objetivo es guiar, no prediseñar.

4. Protocolo de construcción

1. Identifica el componente, pantalla o flujo en el que se está trabajando.
2. Abre las leyes correspondientes y usa sus listas del Modo 2 como referencia, citando valores concretos (tamaños de objetivo, tiempos, relaciones de contraste, criterios WCAG).
3. Cuando la guía entre en conflicto, dilo y recomienda una resolución para este caso.
4. No ejecutes la revisión completa durante la construcción; menciona un problema de nivel de Revisión solo si es probable que sea un Bloqueante.

5. Protocolo de revisión (estricto)

Las revisiones existen para detener problemas antes del commit. Reglas de rigor:

• Evidencia o no pasó. Una comprobación pasa solo con evidencia positiva en el artefacto. Nunca asumas un estado, tamaño, tiempo o comportamiento que no puedas ver.
• No verificable significa NO VERIFICADO, no pasa. Nombra lo que necesitarías (un estado de error, una medición, datos reales, un dispositivo, el código).
• El alcance se declara, nunca se implica. Un veredicto cubre solo la evidencia que se te ha dado. Las comprobaciones que necesitan un tipo de evidencia que no recibiste se enumeran como fuera de alcance, para que una revisión de captura de pantalla no se lea como una aprobación completa.
• No suavices. Sin relleno de elogios, sin "en general se ve genial", sin reducir la severidad debido a plazos o esfuerzo ya invertido.
• Sé específico. Cada hallazgo nombra la ubicación (pantalla, componente, elemento o archivo:línea), lo que observaste y una corrección concreta.
• Un problema, un hallazgo. Si varias leyes señalan el mismo problema, repórtalo una vez, enumera todos los IDs de comprobación y usa la severidad más alta.
• Informa las leyes limpias explícitamente. Enumera qué leyes se aplicaron sin hallazgos, para que la cobertura sea visible.

Pasos:

1. Inventaria lo que se te ha dado (pantallas, estados, puntos de interrupción, código) y lo que falta, y establece el alcance de la evidencia: cuáles de los tipos de evidencia siguientes tienes.
2. Selecciona la base más las leyes situacionales.
3. Ejecuta cada comprobación en la tabla del Modo 3 de cada ley seleccionada. Clasifica cada comprobación en una de:
   • verificado — pasó o produjo un hallazgo;
   • no verificado — su tipo de evidencia está en alcance, pero falta el estado, elemento o medición que necesita (por ejemplo, alcance static, pero no hay pantalla de estado de error);
   • fuera de alcance — ninguno de sus tipos de evidencia está en alcance;
   • no aplicable — el artefacto no tiene nada sobre lo que trata la comprobación (por ejemplo, FIT-1 en una herramienta de escritorio solo con ratón). Da la razón en pocas palabras.
4. Fusiona duplicados, asigna severidad, escribe correcciones.
5. Da el veredicto, con su alcance.

Tipos de evidencia

Cada comprobación del Modo 3 tiene una columna Evidencia que nombra los tipos de entrada que pueden resolverla. Cuando enumera más de uno, cualquiera de ellos es suficiente.

Tipo	Qué es	Entradas típicas
static	Lo que se puede ver en imágenes fijas de las pantallas y estados relevantes.	Capturas de pantalla, mocks estáticos, archivos de diseño con medidas, tableros de flujo
interactive	Lo que solo se muestra cuando operas la cosa: teclado, foco, transiciones, tiempo tal como se experimenta, qué sucede después de una acción.	Un prototipo interactivo, una compilación en ejecución, una URL, una grabación de pantalla
code	Lo que está en el código fuente o marcado: semántica, ARIA, autocomplete, áreas de impacto, tokens y comportamiento que el código fuente fija sin ambigüedad (qué hace un manejador en caso de error, si la entrada se conserva, adónde va el foco).	Un diff, código fuente del componente, DOM renderizado
runtime	Mediciones en hardware, redes y datos realistas.	Trazas de rendimiento, números RUM o de laboratorio
context	Hechos fuera del artefacto: datos de uso, investigación, registros de decisiones, reglas de negocio.	Analíticas, hallazgos de investigación, un PRD o ADR, una declaración del equipo

Cuenta un tipo de evidencia como en alcance solo si realmente lo tienes. Que te digan que el código existe no pone code en alcance.

Severidad

Severidad	Significado
Bloqueante	Impide o engaña en una tarea central; arriesga pérdida de datos, daño financiero, de seguridad o protección; falla un criterio WCAG 2.2 AA; o es un patrón engañoso. Debe corregirse antes del commit.
Mayor	Fricción significativa, diseño propenso a errores o inconsistencia clara con convenciones o el sistema de diseño. Corregir antes del commit, o registrar aceptación explícita por un propietario nombrado con un seguimiento.
Menor	Pulido y consistencia. Corregir cuando se toque el área la próxima vez.

Veredicto

Aplica la primera regla que coincida:

1. Cualquier Bloqueante → No commitear.
2. Cualquier comprobación Bloqueante en alcance está NO VERIFICADA → Bloqueado pendiente de evidencia. Nombra el estado o medición faltante, que el equipo podría haber proporcionado con la evidencia que ya dieron.
3. Cualquier Mayor → Commitear solo con cada Mayor corregido o aceptado por un propietario nombrado.
4. Solo Menor o ninguna → Aprobado.

Cada veredicto lleva su alcance, por ejemplo Aprobado (alcance static). Si alguna comprobación Bloqueante está fuera de alcance, enumérala en la línea del veredicto con el tipo de evidencia que necesita, por ejemplo fuera de alcance: JAK-1 (interactive), SA-2 (interactive), DOH-1 (interactive). Un veredicto puede ser sin calificar (solo "Aprobado") solo cuando ninguna comprobación Bloqueante de las leyes seleccionadas está fuera de alcance o no verificada. Las comprobaciones fuera de alcance nunca cambian el veredicto. Le dicen al equipo qué sigue sin revisar y si necesita una segunda pasada con más evidencia antes del lanzamiento.

Plantilla de informe

## Revisión de leyes de UX — <nombre del artefacto>

Revisado: <qué se revisó: pantallas, estados, puntos de interrupción, archivos>
Alcance de la evidencia: <static | interactive | code | runtime | context — los realmente proporcionados>
No proporcionado: <estados o evidencia faltantes>
Leyes aplicadas: <códigos>
Veredicto: <No commitear | Bloqueado pendiente de evidencia | Commitear con Mayores aceptados | Aprobado> (<alcance>)
         fuera de alcance: <IDs de comprobación Bloqueantes con el tipo de evidencia que necesita cada una, o "ninguno">

### Bloqueantes
- [BLOQUEANTE] FIT-1, JAK-1 · <ubicación> — <observación> → <corrección>

### Mayores
- [MAYOR] CL-2 · <ubicación> — <observación> → <corrección>

### Menores
- [MENOR] SIM-6 · <ubicación> — <observación> → <corrección>

### No verificado (en alcance, evidencia faltante)
- POS-2 · <qué no se pudo comprobar> — necesita <el estado o medición específicos>

### Fuera de alcance
- interactive: JAK-1, SA-2, DOH-1, …
- code: CH-3, PKL-3, …

### No aplicable
- FIT-1 — <razón>

### Aplicado sin hallazgos
<códigos>

6. Tensiones comunes

Tensión	Resolución predeterminada
Hick / Occam (menos opciones) vs Pareto cola larga y necesidades de expertos	Mantén las funciones críticas pero raras encontrables mediante divulgación progresiva; nunca las elimines solo por uso.
Occam (eliminar) vs Tesler (complejidad irreducible)	Elimina la complejidad incidental; mueve la complejidad inherente al sistema, con visibilidad y deshacer.
Jakob (convención) vs diferenciación	Innova en el problema, no en los controles principales. Las desviaciones necesitan un beneficio declarado y probado.
Von Restorff (énfasis) vs Similaridad (consistencia)	Un elemento enfatizado por vista; todo lo demás consistente.
Fitts (objetivos grandes y convenientes) vs activación accidental	Separa las acciones destructivas; añade deshacer o confirmación para las consecuentes.
Flujo (sin interrupciones) vs confirmaciones de seguridad	Interrumpe solo para acciones consecuentes e irreversibles.
Carga cognitiva (mostrar menos) vs Memoria de trabajo (mostrar contexto)	Muestra el contexto necesario para el paso actual; oculta el resto.
Postel (aceptar liberalmente) vs corrección	Liberal en formato, estricto en significado; confirma valores ambiguos y consecuentes.
Goal-Gradient, Zeigarnik, Posición Serial, Von Restorff como palancas vs interés del usuario	Úsalos solo hacia resultados que el usuario desea; ver cognitive-bias.

7. Todas las leyes

Percepción y atención

Ley	Código	Úsalo para
aesthetic-usability-effect	AUE	pulido visual, primeras impresiones, expresión de marca, interpretación de pruebas de usabilidad y la brecha entre cómo se ve un producto y cómo funciona
law-of-common-region	CR	tarjetas, paneles, secciones, bordes, rellenos de fondo, filas de tabla, grupos de formularios y cualquier contenedor usado para señalar que los elementos pertenecen juntos
law-of-proximity	PRX	espaciado, densidad de diseño, asociación etiqueta-campo, agrupación de controles y contenido, y escalas de espaciado
law-of-pragnanz	PRG	iconos, ilustraciones, visualizaciones de datos, siluetas de diseño, logotipos y cualquier elemento visual que deba entenderse de un vistazo
selective-attention	SA	notificaciones, alertas, cambios de estado, banners, sugerencias de incorporación, mensajes del sistema y colocación de información que los usuarios no deben perderse
law-of-similarity	SIM	consistencia visual, estilos de enlaces y botones, variantes de componentes, colores de estado, familias de iconos y uso del sistema de diseño

…

Cognición y memoria

Ley	Código	Úsalo para
cognitive-load	CL	paneles, formularios, flujos de varios pasos, tutoriales, configuraciones complejas y cualquier pantalla que contenga más de 7 elementos de información distintos
working-memory	WM	formularios, procesos de varios pasos, resultados de búsqueda, tablas de comparación, interfaces de transacción y contextos que el usuario debe retener entre pantallas
chunking	CH	formularios largos, entradas de datos, navegación con muchos elementos, números de tarjetas de crédito y contraseñas, instrucciones procedurales y pasos de asistente
mental-model	MM	patrones de navegación, terminología de funciones, flujos de trabajo de tareas, migraciones de sistemas heredados, integraciones de terceros y funciones de IA/automatización
flow	FL	herramientas de productividad, creación de contenido, desarrollo, análisis de datos, juegos y cualquier flujo de trabajo en el que el usuario permanezca más de 10 minutos
paradox-of-the-active-user	PAU	incorporación, ayuda contextual, tutoriales, características avanzadas, atajos de teclado y descubrimiento de funciones para usuarios ocupados
zeigarnik-effect	ZE	indicadores de progreso, listas de verificación, borradores, incorporación por pasos, procesos que se reanudan, recompensas pendientes y cualquier flujo que se pueda dejar incompleto

Toma de decisiones y sesgos

Ley	Código	Úsalo para
hicks-law	HK	menús, barras de herramientas, catálogos, páginas de planes de precios, cualquier pantalla con 5 o más opciones distinguibles y puntos de decisión
cognitive-bias	CB	comparaciones de precios, listas de funciones, señales de escasez, pruebas sociales, valores predeterminados, enmarcado de opciones y cualquier pantalla que influya en la elección
choice-overload	CO	niveles de planes, comparaciones de productos, personalización, ajustes de filtros y cualquier pantalla con más de 6 opciones simultáneas
von-restorff-effect	VR	llamadas a la acción, mensajes de estado, diferencias entre planes, elementos destacados de contenido, señales de error y todo lo que necesita destacar
peak-end-rule	PER	incorporación, pago, incorporación de clientes, informes de errores, final de sesión, cancelaciones y cualquier flujo que tenga un pico definido y un final
serial-position-effect	SPE	navegación, listas, filas de tabla, flujos de varios pasos, carruseles, bandejas de notificaciones, lista de reproducción y cualquier secuencia lineal de elementos
goal-gradient-effect	GGE	incorporación, indicadores de progreso, listas de verificación, programas de fidelización, puntos de referencia, límites de cuenta gratuita y cualquier flujo hacia un objetivo

Interacción

Ley	Código	Úsalo para
fitts-law	FIT	botones, enlaces, objetivos táctiles, menús desplegables, controles de arrastrar y soltar, diseño de teclado, disposición de barras de herramientas y cualquier elemento que requiera un movimiento del cursor o del dedo
jakobs-law	JK	patrones de navegación, iconografía, diseño de formularios, gestos, terminología y cualquier convención de UI que los usuarios traen de otros sitios
postels-law	POS	formatos de entrada, validación de formularios, manejo de errores, importación de datos, procesamiento de lenguaje natural en formularios, normalización de entradas
doherty-threshold	DOH	estados de carga, progreso de acciones, tiempo de respuesta, animaciones, feedback después de una acción y cualquier interacción donde la latencia sea perceptible
teslers-law	TSL	configuraciones complejas, definición de reglas de automatización, generación de informes, preferencias de usuario, API y cualquier función con complejidad irreducible
law-of-uniform-connectedness	UC	tablas, diagramas de flujo, diagramas de red, paneles de datos, gráficos de líneas y cualquier UI donde se muestren visualmente conexiones

Corrección, pulido y refinamiento

Ley	Código	Úsalo para
parkinsons-law	PKL	tareas cronometradas, límites de sesión, estados de carga, temporizadores, cuentas regresivas y cualquier UI que muestre tiempo o progreso
pareto-principle	PTO	análisis de uso de funciones, esfuerzo de refactorización, pruebas, optimización de rendimiento, determinación del alcance del lanzamiento y cualquier decisión sobre qué construir o arreglar primero
occams-razor	OCR	páginas de destino, onboarding, opciones de planes, configuración, salida de IA y cualquier decisión de simplificación
law-of-similarity	SIM	(ya listado arriba)
aesthetic-usability-effect	AUE	(ya listado arriba)

8. Leyes agrupadas para problemas comunes

Problema	Leyes principales a aplicar
La interfaz se siente abarrotada o abrumadora	cognitive-load, working-memory, law-of-proximity, hicks-law, choice-overload
Los usuarios cometen errores al ingresar datos	postels-law, working-memory, cognitive-load, chunking
La navegación es confusa	jakobs-law, hicks-law, serial-position-effect, mental-model, chunking
La incorporación no retiene usuarios	paradox-of-the-active-user, goal-gradient-effect, zeigarnik-effect, cognitive-load
Los usuarios se sienten lentos o frustrados	doherty-threshold, peak-end-rule, flow, cognitive-bias
Los cambios de diseño encuentran resistencia	jakobs-law, aesthetic-usability-effect, mental-model, serial-position-effect
El equipo no sabe qué priorizar	pareto-principle, occams-razor, teslers-law, fitts-law (para alcance)