# UX Laws

> Use when auditing, reviewing or designing a UI (pantalla, módulo, formulario, tabla, dashboard, flujo, drawer, navegación) and the user asks for puntos débiles, simplicidad, facilidad de elección, optimización, fricción, carga cognitiva, or names a UX law (Hick, Fitts, Jakob, Miller, Doherty, Von Restorff, Tesler, Postel, Occam, Pareto, Gestalt, peak-end, Zeigarnik). Also for /ux-laws.

- Skill: `ricardooschutz/ux-laws` (Agent Skill, multi-file: 24 files)
- Install (CLI): `npx skillmds@latest add ricardooschutz/ux-laws`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ricardooschutz/ux-laws/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ricardooschutz (https://skillmd.com/u/ricardooschutz)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/ricardooschutz/ux-laws

---


# /ux-laws — afilador UX

Cada ley predice algo observable. Auditar es encontrar dónde la interfaz contradice una predicción, con evidencia. **Sin evidencia (archivo:línea, elemento, medición) no hay hallazgo.** "Podría confundir" no cuenta.

## Uso

```
/ux-laws auditar <ruta|módulo|url|captura>     # auditoría completa, 20 leyes
/ux-laws rapida <ruta>                          # solo checklist-auditoria.md (30 preguntas)
/ux-laws ley <nombre>                           # explicar una ley con ejemplos del proyecto actual
/ux-laws diseñar <qué vas a construir>          # leyes a aplicar ANTES de escribir código
```

## Flujo de auditoría

1. **Fijar la tarea principal.** ¿Qué viene a hacer el usuario a esta pantalla? Sin tarea no hay auditoría: la misma tabla es buena para "buscar un cliente" y mala para "cargar 30 pagos". Si hay datos de uso, el 20% de acciones que concentra el 80% del uso es la tarea (ver `leyes/20-pareto.md`).
2. **Leer todo el objeto.** Código completo del módulo (no muestrear), captura si hay, y si la app corre, un snapshot con Playwright. Anotar: cantidad de opciones por menú/select, tamaño y posición de targets, latencias visibles, cómo termina cada flujo.
3. **Pasar las 20 leyes.** Para cada archivo `leyes/NN-*.md` leer la sección **Preguntas de auditoría**. Solo cuando una pregunta da "sí" se abre el archivo entero (señales, correcciones, tensiones). No forzar hallazgos: una vista sana pasa 12 o 15 leyes limpias.
4. **Registrar cada hallazgo** con el formato de `plantilla-informe.md`: ley, evidencia, qué predice la ley que pasa, corrección, esfuerzo.
5. **Clasificar** por eje (simplicidad, elección, optimización) y severidad: `bloquea` (impide o corrompe la tarea principal), `fricción` (cuesta tiempo o errores en cada uso), `pulido` (mejora perceptible, no urgente).
6. **Priorizar** con Pareto: primero lo que toca la tarea principal, después lo recurrente, al final lo cosmético. Máximo 3 acciones en "hacer ya".
7. **Escribir el informe** con la plantilla. Un semáforo por eje, no un puntaje numérico (no hay base para un número).

## Mapa de leyes por eje

| Eje | Pregunta del eje | Leyes |
|---|---|---|
| **Simplicidad** | ¿Cuánto hay que procesar para entender la pantalla? | 05 Miller · 12 Prägnanz · 04 Proximidad · 13 Similitud · 14 Conexión uniforme · 17 Región común · 19 Occam · 15 Tesler · 03 Jakob |
| **Elección** | ¿Qué tan fácil es decidir qué hacer y encontrarlo? | 01 Hick · 07 Von Restorff · 09 Posición serial · 20 Pareto |
| **Optimización** | ¿Cuánto tiempo, esfuerzo y ansiedad cuesta completar la tarea? | 02 Fitts · 08 Distancia al objetivo · 06 Doherty · 18 Parkinson · 16 Postel · 10 Pico-final · 11 Zeigarnik |

## Las 20 leyes en una línea

| # | Ley | Predice | Archivo |
|---|---|---|---|
| 01 | Hick | El tiempo de decidir crece con el log de las opciones | `leyes/01-hick.md` |
| 02 | Fitts | Llegar a un target cuesta según distancia/tamaño | `leyes/02-fitts.md` |
| 03 | Jakob | El usuario espera que funcione como los otros sitios que usa | `leyes/03-jakob.md` |
| 04 | Proximidad | Lo que está cerca se lee como grupo | `leyes/04-proximidad.md` |
| 05 | Miller | La memoria de trabajo es corta; agrupar (chunking) la extiende | `leyes/05-miller.md` |
| 06 | Doherty | Bajo ~400 ms de respuesta, la productividad se dispara | `leyes/06-doherty.md` |
| 07 | Von Restorff | Lo distinto se recuerda; si todo destaca, nada destaca | `leyes/07-von-restorff.md` |
| 08 | Distancia al objetivo | Bordes, esquinas y acciones junto al objeto se alcanzan sin apuntar | `leyes/08-distancia-al-objetivo.md` |
| 09 | Posición serial | Se recuerda lo primero y lo último de una lista | `leyes/09-posicion-serial.md` |
| 10 | Pico-final | La experiencia se juzga por su pico y su final | `leyes/10-pico-final.md` |
| 11 | Zeigarnik | Lo incompleto se recuerda y empuja a terminar | `leyes/11-zeigarnik.md` |
| 12 | Prägnanz | Lo ambiguo se percibe en su forma más simple | `leyes/12-pragnanz.md` |
| 13 | Similitud | Lo que se ve igual se asume que hace lo mismo | `leyes/13-similitud.md` |
| 14 | Conexión uniforme | Lo conectado visualmente pesa más que lo cercano o lo parecido | `leyes/14-conexion-uniforme.md` |
| 15 | Tesler | La complejidad no desaparece: la absorbe el sistema o el usuario | `leyes/15-tesler.md` |
| 16 | Postel | Aceptar entradas variadas, emitir salidas estrictas | `leyes/16-postel.md` |
| 17 | Región común | Lo que comparte borde o fondo se lee como grupo | `leyes/17-region-comun.md` |
| 18 | Parkinson | La tarea se expande hasta llenar el tiempo/espacio disponible | `leyes/18-parkinson.md` |
| 19 | Occam | Entre equivalentes, la solución con menos supuestos | `leyes/19-occam.md` |
| 20 | Pareto | Un 20% de las funciones concentra el 80% del uso | `leyes/20-pareto.md` |

La lista original tenía Postel duplicada en el 17; se reemplazó por Región común para completar el set Gestalt. `leyes/extras.md` suma cinco de apoyo (estético-usabilidad, gradiente de meta, sobrecarga de elección, carga cognitiva, paradoja del usuario activo).

## Atribución correcta

Cada hallazgo se cuelga de la ley que **predice** el daño, no de la que suena parecida. Las confusiones más frecuentes:

| Hallazgo típico | NO es | Es |
|---|---|---|
| El mismo dato aparece 2-3 veces en la vista | Miller | 19 Occam (elementos de más) |
| Etiqueta "Opcional" en 12 de 13 campos | Miller | 07 Von Restorff (el énfasis dejó de distinguir) |
| Click en un ícono chico dispara la acción de la fila | Doherty | 02 Fitts (fallar el target tiene costo) |
| Escape o click fuera descarta lo editado sin aviso | Doherty | 10 Pico-final (final malo) |
| Menú de 12 ítems a la vista | Miller | 01 Hick, y solo si no están agrupados ni ordenados |
| Notas guardadas que "vuelven atrás" | Postel | 06 Doherty (feedback falso) o defecto funcional a reportar aparte |
| Botón "Guardar" fuera del viewport | Fitts | 08 Distancia al objetivo |
| Filtro activo sin marca visible | Prägnanz | 14 Conexión uniforme (control desconectado de su efecto) |
| Wizard sin indicador de paso | Miller | 11 Zeigarnik |
| Color rojo en acciones reversibles | Similitud | 07 Von Restorff (se gasta el énfasis) |

Un bug funcional (handler que falta, listener duplicado) se reporta como hallazgo bajo la ley cuya predicción rompe, con la nota "defecto funcional". No se inventa una ley para justificarlo.

## Modo diseñar: qué leyes cargar según lo que vas a construir

| Vas a construir | Leer primero |
|---|---|
| Tabla con filtros | 20 Pareto (columnas), 09 Posición serial (orden), 04/17 agrupación, 06 Doherty (carga), 02 Fitts (acciones por fila) |
| Formulario de carga | 15 Tesler (defaults), 16 Postel (inputs), 05 Miller (chunking), 04 Proximidad (label-input), 18 Parkinson (largo), 10 Pico-final (confirmación) |
| Dashboard / KPIs | 20 Pareto, 07 Von Restorff (un solo énfasis), 12 Prägnanz, 17 Región común, 01 Hick (cuántos widgets) |
| Navegación / sidebar | 01 Hick, 09 Posición serial, 03 Jakob, 13 Similitud, 20 Pareto |
| Flujo de varios pasos | 11 Zeigarnik (progreso), 10 Pico-final, 14 Conexión uniforme (steps), 18 Parkinson, 06 Doherty |
| Drawer / panel de detalle | 08 Distancia al objetivo (acciones junto al dato), 04 Proximidad, 05 Miller, 07 Von Restorff |
| Estados de error y vacío | 10 Pico-final, 16 Postel, 03 Jakob, 07 Von Restorff |

## Errores comunes al auditar

- **Marcar las 20 como violadas.** Eso es teatro de checklist. Si no hay evidencia, la ley pasa.
- **Citar "7±2" para menús.** Miller aplica a lo que hay que recordar, no a lo que está a la vista. Un menú de 12 ítems agrupados no viola nada (ver `leyes/05-miller.md`).
- **Recomendar sacar funciones sin datos de uso.** Pareto necesita medición o al menos el criterio del dueño. Sin eso, proponer progressive disclosure, no borrado.
- **Proponer un tooltip como fix.** Un tooltip mueve la complejidad al usuario (Tesler). Primero defaults, inferencia, autocompletar.
- **Destacar más cosas para "mejorar jerarquía".** Von Restorff funciona por escasez: una vista, un énfasis.
- **Confundir Postel con aceptar basura.** Tolerar formatos no es tolerar ambigüedad: `12/03` sin año se pregunta, no se adivina.
- **Auditar gusto visual o motion.** Paleta, tipografía y animaciones van con las skills `impeccable`, `design-taste-frontend` o `design-motion-principles`, no acá.

## Archivos

- `leyes/NN-*.md` — una ley por archivo: origen, fórmula, preguntas de auditoría, señales, correcciones, casos ERP, tensiones, fuentes.
- `checklist-auditoria.md` — 30 preguntas para el modo rápido, agrupadas por eje.
- `plantilla-informe.md` — formato de salida obligatorio del informe.