ricardooschutz /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
- 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). - 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.
- Pasar las 20 leyes. Para cada archivo
leyes/NN-*.mdleer 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. - Registrar cada hallazgo con el formato de
plantilla-informe.md: ley, evidencia, qué predice la ley que pasa, corrección, esfuerzo. - 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). - 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".
- 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/03sin año se pregunta, no se adivina. - Auditar gusto visual o motion. Paleta, tipografía y animaciones van con las skills
impeccable,design-taste-frontendodesign-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.