Leyes de UX, UI y UX Writing que todo dev debería conocer (la chuleta práctica)

Hay una conversación que se repite cada par de meses en cualquier equipo de software: el back-end dice que la interfaz da igual mientras el sistema funcione, el front pide presupuesto para un sistema de diseño, y el dueño de producto saca un screenshot de Notion preguntando “¿por qué no podemos hacerlo así?”. Todos tienen un pedazo de la razón. Y todos están operando sin un vocabulario común.

Ese vocabulario existe desde hace décadas y se llama leyes de UX. No son trucos de diseñador ni misticismo de Figma — son psicología cognitiva, percepción visual y teoría de la información condensadas en reglas operables, con experimentos reproducibles detrás. Jon Yablonski las recopiló en lawsofux.com (2018) y después en el libro Laws of UX: Using Psychology to Design Better Products & Services (O’Reilly, 2020). La referencia académica viene del Nielsen Norman Group, las investigaciones de los años 50-70 en psicología cognitiva, y los gestaltistas alemanes de principios del siglo XX.

Este post es la chuleta pragmática: veinte leyes que apliquen el lunes en la mañana, agrupadas por familia, con su fuente original, un ejemplo concreto del oficio y una explicación de por qué importan al construir software. Está pensado para devs, no para diseñadores — pero un diseñador lo puede usar para defender decisiones con argumento, no con opinión.

Al final viene una checklist para meter en code reviews y la lista de fuentes para profundizar. Bookmarkéalo. Vuelve cuando dudes.

I. Cognición y atención — la mente como recurso limitado

La premisa de todas estas leyes es simple: el cerebro tiene ancho de banda finito. Cada decisión, cada espera, cada elemento en pantalla consume parte de ese presupuesto. El trabajo del producto es no desperdiciarlo.

1. Ley de Hick (Hick-Hyman Law)

Qué dice: el tiempo que toma decidir crece logarítmicamente con el número de opciones disponibles. Más botones, más tiempo de decisión.

T = b · log₂(n + 1)

donde T = tiempo de reacción
       b = constante empírica (~150 ms para humanos)
       n = número de opciones equiprobables

Origen: William Edmund Hick (psicólogo británico, 1952) y Ray Hyman (Universidad de Oregon, 1953) lo derivaron en experimentos independientes con tableros de luces y botones. Es uno de los pocos resultados de psicología que ha aguantado siete décadas de replicación.

Por qué importa al dev: cada vez que metes un dropdown de 30 países sin búsqueda, una toolbar con 18 íconos sin tooltip, o un menú contextual con 12 opciones — estás pagando esta ley en milisegundos por usuario, multiplicado por todas las sesiones.

Cómo aplicarla:

• Si un dropdown tiene más de 7-8 opciones: agrega búsqueda.
• Si una toolbar tiene más de 5 botones: agrupa por contexto o esconde los menos usados detrás de un “Más”.
• En onboardings, una sola pregunta por pantalla siempre supera al formulario de 15 campos.

Trampa común: confundir “menos opciones” con “menos funcionalidad”. Hick no dice que recortes features — dice que escondas las opciones que no aplican al contexto actual. Progressive disclosure, no amputación.

2. Ley de Miller (Miller’s Number / The Magical Number Seven)

Qué dice: la memoria de trabajo humana puede sostener 7 ± 2 elementos simultáneamente. Por encima de 9, empezamos a olvidar.

Origen: George A. Miller, The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information, Psychological Review (1956). Estudios posteriores (Nelson Cowan, 2001) redujeron el número a 3-5 elementos, pero la regla operacional sigue siendo Miller.

Por qué importa: si tu sidebar tiene 14 secciones de primer nivel, no hay manera de que el usuario las mantenga en la cabeza. Vas a ver scrolling errático, búsquedas repetidas y abandono.

Cómo aplicarla:

• Navegación principal: máximo 7 ítems.
• Pasos en un wizard: máximo 5 (idealmente 3).
• Pestañas: si necesitas más de 5, repensar la estructura.
• Tablas: agrupar columnas relacionadas o permitir ocultar.

No-aplica: Miller habla de elementos simultáneos en memoria de trabajo, no del total de cosas que un usuario puede recorrer. Una tienda con 5000 productos no viola Miller si la navegación está bien jerarquizada — sólo viola Miller si esos 5000 están en el menú principal.

3. Carga cognitiva (Cognitive Load Theory)

Qué dice: cada elemento de interfaz, microinteracción y decisión consume carga cognitiva. Hay tres tipos: intrínseca (la dificultad del problema), extraneous (el ruido del diseño) y germane (el esfuerzo de aprender). El trabajo del producto es bajar la extraneous al mínimo.

Origen: John Sweller, University of New South Wales, 1988. Originalmente para diseño instruccional, después adaptado a UX.

Por qué importa: una interfaz “limpia” no es la que tiene menos elementos en pantalla — es la que tiene menos elementos que no aportan a la tarea actual. Mucho whitespace puede ser tan ruidoso como mucho contenido, si el whitespace no agrupa.

Cómo aplicarla:

• Cada componente debe responder “¿por qué está aquí?”. Si la respuesta es “por estética”, reevaluar.
• Evita pedir información que ya tienes (“¿cuál es su email?” cuando ya estás logueado).
• Ofrece defaults inteligentes en lugar de forzar elección.
• Los errores deben decir qué hacer, no sólo qué pasó.

4. Umbral de Doherty (Doherty Threshold)

Qué dice: cuando una computadora responde a una acción humana en menos de 400 ms, la productividad sube exponencialmente porque el usuario se mantiene en “flujo”. Por encima de eso, el cerebro empieza a hacer otra cosa y hay que pagar el costo de recontextualizar.

Origen: Walter J. Doherty y Arvind J. Thadani, The Economic Value of Rapid Response Time, IBM Systems Journal (1982). Investigación real con operadores de mainframes.

Por qué importa: cualquier acción que tarde más de 400 ms necesita feedback. Punto.

Cómo aplicarla:

• Si la operación tarda < 100 ms: nada (el cerebro lo percibe como instantáneo).
• 100-400 ms: feedback sutil (cambio de estado, microanimación).
• 400 ms - 2 s: spinner o skeleton screen.
• > 2 s: barra de progreso con porcentaje real, idealmente con texto de qué está pasando.
• > 10 s: asume que el usuario fue a hacer otra cosa. Notifica cuando termine.

Truco operacional: optimistic UI. Aplica el cambio en cliente, manda la petición en segundo plano, revierte si falla. El usuario percibe < 100 ms.

II. Percepción visual — las leyes Gestalt

Los gestaltistas alemanes (Max Wertheimer, Wolfgang Köhler, Kurt Koffka) probaron en los años 1920 algo que hoy damos por obvio: el ojo no ve píxeles, ve estructura. Agrupamos elementos en patrones antes de procesarlos individualmente. Estas leyes están en el corazón de cualquier sistema de diseño.

5. Ley de proximidad

Qué dice: los elementos cercanos se perciben como un grupo, incluso si son visualmente distintos. La distancia define las relaciones más que el color o el borde.

Por qué importa: si un label está más cerca del campo equivocado, el usuario lo va a asociar con ese campo. Si dos botones están pegados sin separación, el usuario asume que son acciones relacionadas.

Cómo aplicarla:

• Espaciado interno (dentro del grupo) menor que el espaciado externo (entre grupos). Esta es la regla más violada en formularios.
• Labels arriba del campo, no a la izquierda, salvo que haya razón fuerte.
• Botones de acciones primarias separados visualmente de las secundarias.

6. Ley de similitud

Qué dice: los elementos visualmente similares se perciben como pertenecientes al mismo grupo. Color, forma, tamaño, tipografía — todos son señales de “pertenencia”.

Por qué importa: si dos botones se ven idénticos pero hacen cosas distintas, el usuario va a tratarlos como equivalentes. Si dos cosas distintas (un link y un párrafo) se ven igual, el usuario no sabe que una es interactiva.

Cómo aplicarla:

• Mismo tipo de acción = mismo estilo visual (todos los botones de “eliminar” en rojo, todos los “guardar” en cempasúchil).
• Los links deben verse como links (subrayado, color distintivo, o ambos).
• El texto interactivo debe diferenciarse del texto descriptivo, incluso si el bordes están eliminados.

7. Ley de la región común (Common Region)

Qué dice: los elementos dentro de un contenedor visual (caja, borde, fondo distinto) se perciben como agrupados, incluso cuando están más lejos que elementos fuera del contenedor.

Por qué importa: una card con borde sutil agrupa mejor que tres columnas separadas por whitespace, porque el borde es señal explícita de pertenencia.

Cómo aplicarla:

• Usa cards/contenedores cuando el agrupamiento es importante para la comprensión.
• Evita cards anidadas — el cerebro se confunde con la jerarquía.
• Si vas a usar borders, que sean consistentes (siempre --line, nunca grises arbitrarios).

8. Ley de la conexión uniforme

Qué dice: los elementos conectados visualmente (por líneas, flechas, fondos compartidos) se perciben más relacionados que los simplemente cercanos. La conexión explícita vence a la proximidad.

Por qué importa: en diagramas, dashboards y pipelines, una línea fina entre dos nodos comunica relación con más fuerza que ponerlos uno al lado del otro.

Cómo aplicarla:

• Diagramas de flujo (como este Mermaid): las flechas sí cuentan.
• Tablas: las líneas guía entre filas ayudan a leer en zigzag.
• Timelines: una línea vertical que conecta los hitos vale más que tres tarjetas separadas.

III. Interacción y motor — el cuerpo en la ecuación

9. Ley de Fitts

Qué dice: el tiempo para mover el puntero a un target es proporcional al log de la distancia, e inversamente proporcional al ancho del target. Targets grandes y cercanos = clicks rápidos. Targets pequeños y lejanos = errores.

T = a + b · log₂(D/W + 1)

donde T = tiempo de movimiento
       D = distancia al target
       W = ancho del target en la dirección del movimiento
       a, b = constantes del sistema motor

Origen: Paul Fitts, The Information Capacity of the Human Motor System in Controlling the Amplitude of Movement, Journal of Experimental Psychology (1954). Es una de las leyes más probadas de la interacción humano-computadora.

Por qué importa al dev: un botón de 12px de alto en un formulario que se llena diez veces al día representa horas perdidas al año, multiplicado por todos los usuarios.

Cómo aplicarla:

• Botones primarios: mínimo 44×44 px (recomendación Apple) o 48×48 dp (Android). En desktop, mínimo 32px de alto.
• Acciones destructivas (eliminar) lejos de acciones frecuentes (guardar). No querés que un slip de mouse borre algo importante.
• Los bordes de pantalla son “infinitamente grandes” porque el cursor no se sale. Aprovechá esquinas y bordes para acciones importantes (menú macOS arriba, dock en el borde).
• Menús contextuales: la opción más probable arriba (más cerca del cursor que aparece).

10. Ley de Steering

Qué dice: navegar por un pasillo estrecho (como un menú anidado en cascada) es lineal en la distancia, no logarítmico. Es decir, mucho más costoso que un click directo.

Origen: Johnny Accot y Shumin Zhai, Beyond Fitts’ law: models for trajectory-based HCI tasks, CHI 1997.

Por qué importa: menús anidados a tres o cuatro niveles son brutales. El usuario tiene que mantener la trayectoria perfecta o el menú colapsa.

Cómo aplicarla:

• Evita menús cascada profundos. Reemplazá por mega-menús (todo visible) o command palettes (⌘K + búsqueda).
• Si tenés que usar cascada, agregá un delay de 300-500 ms al cierre para tolerar la imprecisión.

IV. Memoria y emoción — qué recuerda el usuario

11. Regla del pico y final (Peak-End Rule)

Qué dice: la gente no recuerda experiencias por su promedio — las recuerda por el momento de pico emocional (positivo o negativo) y por cómo terminaron. Daniel Kahneman lo demostró con experimentos de dolor donde los pacientes preferían procedimientos más largos si terminaban mejor.

Origen: Daniel Kahneman, Barbara Fredrickson y otros, When More Pain Is Preferred to Less: Adding a Better End, Psychological Science (1993).

Por qué importa: una app puede tener performance excelente todo el día y el usuario recordarla como “lenta” si el primer login se sintió pesado, o si el último error fue grave.

Cómo aplicarla:

• Onboarding fuerte: el primer minuto define el recuerdo de la primera semana.
• Estados vacíos cuidados, no genéricos. Es momento de hacer brillar a la marca.
• Mensajes de éxito que celebran (sin caer en cursilería) — el usuario acaba de hacer algo bien, decíselo.
• Cierres de flujo memorables: confirmaciones que sienten finitas, no genéricas (“Listo, su pedido va en camino” > “Pedido procesado exitosamente”).

12. Efecto de posición serial (Serial Position Effect)

Qué dice: recordamos mejor los primeros y los últimos elementos de una lista. Los del medio se pierden. Es la combinación del primacy effect (lo primero impacta) y el recency effect (lo último está fresco).

Origen: Hermann Ebbinghaus (1885), refinado por Murdock (1962) y Glanzer & Cunitz (1966).

Por qué importa: en una navegación de 10 ítems, el segundo, tercero y cuarto desde el final pasarán desapercibidos.

Cómo aplicarla:

• Pon las acciones más importantes al inicio o al final de listas y menús.
• En un wizard de 5 pasos, el contenido del paso 3 debe ser el más simple (porque se va a recordar peor).
• En tablas largas, fijar las columnas críticas a la izquierda (primera).

13. Efecto Zeigarnik

Qué dice: recordamos mejor las tareas inconclusas que las terminadas. La psicóloga Bluma Zeigarnik lo observó en meseros que recordaban perfectamente las órdenes pendientes pero olvidaban las ya servidas.

Origen: Bluma Zeigarnik, Universidad de Berlín, 1927. La cita original: Über das Behalten von erledigten und unerledigten Handlungen.

Por qué importa: el cerebro empuja al usuario a terminar lo empezado. Si un flujo está mal diseñado y la gente abandona a mitad, vas a perder la conversión — pero también vas a quedarte en su cabeza generando frustración.

Cómo aplicarla:

• Barras de progreso explícitas en formularios largos (“3 de 5”).
• “Guardar borrador automáticamente” — cuando el usuario regresa, no hay penalización por haber pausado.
• Estados de tareas pendientes destacados (“Tienes 2 facturas sin pagar”). Es manipulación leve pero efectiva — usar con criterio ético.

14. Efecto estética-usabilidad (Aesthetic-Usability Effect)

Qué dice: los usuarios perciben las interfaces estéticamente agradables como más fáciles de usar — incluso cuando objetivamente no lo son. Una interfaz bonita compra paciencia frente a fallos menores.

Origen: Masaaki Kurosu y Kaori Kashimura, Apparent Usability vs. Inherent Usability, Hitachi Design Center, CHI ‘95.

Por qué importa: el diseño no es decoración — es inversión en tolerancia al error. Pero también es una trampa: una interfaz bonita puede esconder problemas de usabilidad reales que sólo se manifiestan en sesiones de prueba.

Cómo aplicarla:

• Invertí en diseño visual, pero siempre validá con usuarios reales — la estética no sustituye usability testing.
• Cuidado con confundir “se ve bien en Figma” con “funciona bien en producción”.

V. Filosofía de diseño — los principios estructurales

15. Ley de Jakob (Jakob’s Law)

Qué dice: “Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know.” Es decir: no innoves en lo conocido.

Origen: Jakob Nielsen, cofundador de Nielsen Norman Group, 2000. Es probablemente la ley más citada en UX en los últimos 25 años.

Por qué importa al dev: cada vez que reimplementás un componente que ya existe en navegadores (un select, un date picker, una scrollbar) estás violando Jakob’s Law y le estás cobrando al usuario aprender tu versión. A veces vale la pena, casi siempre no.

Cómo aplicarla:

• El logo arriba a la izquierda, la búsqueda arriba a la derecha. Sí, suena básico — por eso funciona.
• Los carritos de e-commerce funcionan como Amazon. Aceptalo.
• Si vas a romper una convención, asegurate de que la mejora justifique el costo de aprendizaje (y validá con datos).

16. Ley de Tesler (Law of Conservation of Complexity)

Qué dice: toda aplicación tiene una cantidad inherente de complejidad que no puede ser eliminada. Sólo puede moverse. Si la sacás del usuario, alguien (el sistema, el dev, el diseñador) tiene que tragársela.

Origen: Larry Tesler (Xerox PARC, después Apple y Amazon), años 80. El mismo Tesler que inventó el cut/copy/paste.

Por qué importa: cada vez que un PM pide “que sea más simple para el usuario”, está pidiendo que alguien más cargue con esa complejidad. Generalmente es el equipo de ingeniería. Hay que ser consciente del trade.

Cómo aplicarla:

• Defaults inteligentes (la complejidad la come la lógica detrás).
• Auto-detect (formato de fecha, locale, moneda).
• Si la complejidad debe ser visible al usuario, mostrala con claridad — no la escondas a la mala.

17. Ley de Postel (Robustness Principle)

Qué dice: “Be conservative in what you do, be liberal in what you accept from others.” Originalmente para protocolos de red, pero aplica entero a UX y a APIs.

Origen: Jon Postel, RFC 760, DoD Standard Internet Protocol (1980). El mismo Postel que estuvo detrás de TCP/IP y la IANA.

Por qué importa: los formularios que rechazan “+52 (444) 123-4567” porque no es “5244412345” están violando Postel. Aceptá lo que el humano escribió de forma natural, normalizalo internamente.

Cómo aplicarla:

• Inputs de teléfono: aceptá guiones, paréntesis, espacios. Normalizá del lado servidor.
• Búsquedas: tolerá typos, mayúsculas/minúsculas, acentos.
• Fechas: aceptá múltiples formatos, mostrá uno solo.
• En APIs: aceptá tanto userName como user_name si tu cliente puede venir de varios stacks.

18. Navaja de Ockham (Occam’s Razor)

Qué dice: “Entia non sunt multiplicanda praeter necessitatem” — no multipliques entidades sin necesidad. La solución más simple que resuelve el problema suele ser la correcta.

Origen: William of Ockham, fraile franciscano y filósofo inglés, siglo XIV. La razor original es filosófica; su aplicación en diseño la popularizó el movimiento de diseño industrial alemán y después el lean UX.

Por qué importa: las interfaces tienden a engordar con el tiempo. Cada feature pide su botón, su modal, su tooltip. Sin un principio de poda activa, el producto se vuelve inusable.

Cómo aplicarla:

• Por cada feature nueva: ¿qué se va a quitar?
• Por cada componente: ¿la versión más simple resuelve el 80% de los casos?
• Si dudás entre dos diseños, probá el más simple primero. Es más barato evolucionar de simple a complejo que al revés.

VI. Comportamiento y motivación

19. Efecto del gradiente meta (Goal-Gradient Effect)

Qué dice: la motivación crece a medida que la persona se acerca al objetivo. Funcionalmente, la gente pone más esfuerzo en los últimos pasos que en los primeros.

Origen: Clark L. Hull, The Goal-Gradient Hypothesis Applied to Some “Field-Force” Problems in the Behavior of Young Children, Psychological Review (1938). Replicado en consumidores por Ran Kivetz et al. (Columbia, 2006) con tarjetas de fidelidad.

Por qué importa: una barra de progreso que muestra “casi terminás” mantiene al usuario empujando hasta el final. Sin esa señal, abandona.

Cómo aplicarla:

• Onboardings con steppers visibles.
• Perfiles “X% completos” — el 70% pasa al 80% más rápido que el 20% al 30%.
• En e-commerce: “Sólo $200 más para envío gratis” funciona porque mueve el goal-gradient.

20. Principio de Pareto (regla 80/20)

Qué dice: el 80% de los efectos viene del 20% de las causas. En producto: el 80% del uso viene del 20% de las features. El 80% de los reportes de bugs vienen del 20% de los flujos.

Origen: Vilfredo Pareto, economista italiano, 1896. Observó que el 80% de la tierra italiana pertenecía al 20% de la gente. Joseph M. Juran generalizó la regla a calidad y gestión, años 50.

Por qué importa: dedicarle tiempo equivalente a todas las features es siempre la decisión equivocada. El 20% que se usa todos los días merece 80% del cuidado de polish, performance y diseño.

Cómo aplicarla:

• Instrumentá uso real (analytics honestos). Identificá el 20% top.
• Polish desproporcionado al 20%. El otro 80% que funcione, sin más.
• Cuando recortes scope, recortá del 80% que casi nadie usa, no del core.

21. Efecto Von Restorff (Isolation Effect)

Qué dice: el elemento que rompe la uniformidad se recuerda mejor que los demás. Un botón de color distinto en una lista de botones grises se vuelve el ancla visual de toda la pantalla.

Origen: Hedwig von Restorff, psiquiatra alemana, Über die Wirkung von Bereichsbildungen im Spurenfeld, Psychologische Forschung (1933).

Por qué importa: la acción primaria de cada pantalla debe ser la única que use el color de énfasis. Si hay tres botones cempasúchil, ninguno es el primario.

Cómo aplicarla:

• Una acción primaria por pantalla, una secundaria, el resto ghost o link.
• En analítica: el número que importa va en un tamaño/color que rompe la grilla.
• En navegación, el estado activo debe romper la uniformidad de los inactivos (no apenas diferenciarse).

VII. UX Writing — las cinco reglas que el dev debe respetar

UX Writing no es marketing, es microcopia que pasa por código. Los devs escribimos UX writing todos los días sin darnos cuenta: cada string en un botón, cada mensaje de error, cada placeholder.

1. Claridad antes que ingenio. Un mensaje de error que dice “Algo salió mal” es inútil. Uno que dice “Tu sesión expiró por inactividad — vuelve a ingresar” es accionable. El usuario está frustrado, no necesita una broma.

2. Voz activa, sujeto al frente. “Tu reporte fue enviado” → “Enviamos tu reporte”. El sistema actúa, no el reporte. El usuario percibe agencia, no algo pasando solo.

3. Front-load del valor. Los primeros 2-3 palabras de cada texto cargan el sentido. Mal: “Para poder continuar, necesitamos que verifiques tu correo.” Bien: “Verifica tu correo para continuar.”

4. Microcopy contextual, no genérica. Estados vacíos que sólo dicen “No hay datos” desperdician una oportunidad. “Aún no hay pedidos — cuando tus clientes hagan su primera compra, aparecerán aquí.” funciona infinitamente mejor.

5. Consistencia léxica. Si en un lugar decís “Eliminar” y en otro “Borrar” para la misma acción, el usuario duda. Mantené un glosario de términos del producto y respetá los exactos en todos los strings — esto es trabajo de dev, no del diseñador.

VIII. Accesibilidad — el mínimo no negociable

WCAG 2.2 (Web Content Accessibility Guidelines, W3C) define tres niveles: A (mínimo), AA (estándar) y AAA (ideal). El objetivo realista es AA. Es ley en muchos países (México, Ley General de Inclusión, 2011; Estados Unidos, ADA + Section 508; Unión Europea, EAA 2025).

Lo no negociable:

• Contraste 4.5:1 para texto normal, 3:1 para texto grande (≥18px o 14px bold). Usá Contrast Checker de WebAIM o las DevTools.
• Navegación por teclado completa. Si no podés hacer toda la app con Tab + Enter + flechas, no es accesible. Foco visible siempre. Nunca outline: none sin reemplazo.
• HTML semántico. <button> para botones, <a> para links, <h1>-<h6> para jerarquía. No <div onclick> por flojera.
• Alt text en imágenes. Vacío alt="" para decorativas, descriptivo para informativas. Las captchas y los gráficos sin alt son discriminatorios.
• Labels en formularios. Cada input necesita un <label for> o aria-label. Placeholders no sustituyen labels.
• Mensajes de error asociados (aria-describedby). Un error en rojo no le sirve a un usuario daltónico o con lector de pantalla.
• Respetá prefers-reduced-motion. Si el usuario lo pide, las animaciones se apagan.

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

La accesibilidad no es feature, es higiene de oficio. Y casi siempre mejora la UX de todos, no sólo de personas con discapacidad — la subtitulación ayuda en transporte público, los targets grandes ayudan en móvil, los contrastes altos ayudan al sol del mediodía.

IX. Checklist pragmática — para usar en code review

Cuando estés revisando una PR de UI, corré esta lista:

• Hick — ¿hay un dropdown con más de 8 opciones sin búsqueda?
• Miller — ¿el menú principal tiene más de 7 ítems?
• Doherty — ¿toda acción > 400 ms tiene feedback visible?
• Carga cognitiva — ¿hay elementos en pantalla que no aportan a la tarea actual?
• Proximidad — ¿los grupos tienen separación interna < externa?
• Similitud — ¿cosas que hacen lo mismo se ven igual?
• Fitts — ¿los targets clave tienen mínimo 44×44 px en móvil?
• Peak-End — ¿el último paso del flujo termina con sensación de completitud?
• Jakob — ¿reimplementaste un control que ya existe nativo? ¿Vale la pena?
• Tesler — la complejidad que escondiste al usuario, ¿dónde quedó?
• Postel — ¿los inputs aceptan formatos naturales (espacios, guiones, mayúsculas)?
• Ockham — ¿probaste la versión más simple antes de la compleja?
• Von Restorff — ¿hay una sola acción primaria por pantalla?
• Writing — ¿los strings son claros, en voz activa, con valor al frente?
• A11y — ¿contraste 4.5:1, navegación por teclado, semántica HTML, alt text?

Si quince checkmarks parecen demasiado, escogé tres que aplican a esta PR. Es mejor mirar tres con cuidado que listar quince sin pensarlas.

X. Fuentes para profundizar

Libros:

• Laws of UX — Jon Yablonski (O’Reilly, 2020). El más cercano a “manual de referencia”. Si te llevás un solo libro, este.
• Don’t Make Me Think — Steve Krug. La introducción más clara y honesta a usabilidad. 200 páginas, se lee en un fin de semana.
• The Design of Everyday Things — Don Norman. El clásico de affordances, signifiers y modelos mentales.
• About Face — Alan Cooper. Mucho más denso, pero el más completo sobre diseño de interacción.
• Designing for the Mind — Victor Yocco. Psicología aplicada con menos jerga.

Recursos online:

• lawsofux.com — Jon Yablonski. La versión web con referencias.
• Nielsen Norman Group — el grupo de Jakob Nielsen y Don Norman. Investigación seria, gratis.
• WCAG 2.2 Quick Reference — guía oficial de accesibilidad.
• a11yproject.com — accesibilidad pragmática, sin academia.

Papers originales (si te gusta ir a la fuente):

• Hick, W. E. (1952). On the rate of gain of information.
• Miller, G. A. (1956). The Magical Number Seven, Plus or Minus Two.
• Fitts, P. M. (1954). The information capacity of the human motor system.
• Sweller, J. (1988). Cognitive load during problem solving.
• Doherty, W. J. & Thadani, A. J. (1982). The Economic Value of Rapid Response Time.

---

Estas veinte leyes no son las únicas — pero son las que más valor por hora de estudio dan para alguien que escribe código y toma decisiones de interfaz. El resto se construye sobre ellas.

Lo importante no es memorizarlas. Es internalizar la forma de pensar: cada decisión de UI tiene un costo cognitivo, una psicología detrás y una mejor manera de resolverla que la primera que se te ocurra. Las leyes son atajos para no tener que redescubrirlas.

Bookmarkéa este post. Vuelve cuando dudes.