Si hay que ponerle un cartel, está mal diseñado

Hoy es el Día Mundial de la Usabilidad. Se celebra el segundo jueves de noviembre desde 2005, y la idea había salido un año antes, en 2004, de una conversación entre dos miembros de la junta de la asociación de profesionales de experiencia de usuario: hacía falta un día para recordarle al mundo una idea sencilla.

Que las cosas funcionen no es lo mismo que las cosas se puedan usar.

Y para explicar la diferencia, quiero contarte lo de las puertas.

El tirador dice «tira»; el folio, «empuje». Ilustración generada con IA para este artículo: no es ninguna puerta real.

La puerta Norman

Vas a un edificio de oficinas. La puerta tiene una barra vertical, bonita, cromada. Tu mano la agarra y tira. La puerta no cede. Miras. Hay un cartel que pone EMPUJE.

Empujas. Entras. Y durante medio segundo te sientes ligeramente tonto.

No eres tonto. Es una puerta Norman, y se llama así por Don Norman, autor de La psicología de los objetos cotidianos, que la usó como ejemplo perfecto de mal diseño.

El argumento es demoledor: un tirador invita a tirar. Una placa plana invita a empujar. Si tienes que ponerle un cartel a una puerta para explicar cómo se abre, no has puesto un cartel: has certificado por escrito que la puerta está mal diseñada.

Cada cartel de instrucciones es la lápida de una decisión de diseño.

Y ahora piensa en cuántos carteles hay en tu software. El tooltip que explica qué hace un botón. El texto de ayuda que te dice en qué formato va la fecha. El manual de uso interno de una pantalla de alta. Cada vez que alguien de soporte tiene que explicar por teléfono dónde hay que hacer clic.

Todo eso son pegatinas de EMPUJE.

Ojo, no toda ayuda lo es. Explicar qué pasa si borras una cuenta, o qué es un concepto fiscal, es contexto: eso no lo arregla ningún diseño. La pegatina es otra cosa: es la instrucción que necesita una acción básica, de las que deberían entenderse solas. Abrir una puerta. Guardar un formulario. Encontrar el botón de pagar.

El coste, que es lo que interesa aquí

Este blog no va de diseño, va de negocio con tecnología dentro. Así que vamos al grano: la mala usabilidad no es un problema estético, es una partida de gastos que no aparece en ninguna cuenta.

Está repartida en sitios donde nadie la busca:

• En soporte. Cada llamada de «no encuentro dónde se hace» es una función que existe y que el usuario no ve. Pagas dos veces: la desarrollaste y ahora pagas por explicarla.
• En formación. Si cada persona nueva necesita tres días para manejar la herramienta interna, ese es el coste real de la herramienta. Multiplícalo por la rotación.
• En errores. Un formulario confuso no genera menos datos: genera datos malos. Y los datos malos son más caros que los datos que faltan, porque no sabes que están mal.
• En abandono. La gente no se queja de un proceso de compra malo. Se va. Y se va en silencio, sin dejar ni un ticket ni una reseña. Es el coste más grande y el más difícil de explicar: el embudo te dice en qué paso se va la gente, pero no por qué.
• En horas de la plantilla. Un proceso interno que se hace 200 veces al día y pierde diez segundos cada vez son más de cien horas al año. Nadie lo mide porque cada instancia individual es «solo un momentito».

Esto último es lo que más me llama la atención. Las empresas auditan el gasto en licencias hasta el último euro y nunca auditan el tiempo que su gente pierde peleándose con esas licencias.

Las cinco de siempre

Después de veinte años, hay cinco cosas que veo repetidas en prácticamente todos los proyectos que reviso. Algunas se arreglan en una tarde; otras piden revisar el flujo o cómo funciona el sistema por dentro.

1. Mensajes de error que no dicen qué hacer. «Se ha producido un error inesperado.» Un error tiene que decir qué ha pasado, por qué —cuando se sabe— y qué puede hacer el usuario ahora. «No hemos podido guardar porque el archivo pesa más de 5 MB. Prueba con una imagen más ligera» es un mensaje útil. «Error 500» es un encogimiento de hombros con tipografía.

2. Formularios que castigan. Validación solo al final, todo el formulario borrado tras el fallo, el campo de teléfono que rechaza los espacios que tú mismo has escrito, el DNI que quiere la letra en mayúscula sin decirlo. Regla: si el ordenador puede arreglarlo, que lo arregle el ordenador. Quitar los espacios de un número de tarjeta es una línea de código, no una tarea del usuario.

3. Falta de estado. El botón que pulsas y no pasa nada visible, así que lo pulsas otra vez, y acabas con dos pedidos. El botón tiene que reaccionar en el momento, y si la espera se nota, decir que está trabajando. Y el servidor, por su parte, no debería aceptar el mismo pedido dos veces: el estado visual evita el segundo clic, pero no el segundo envío.

4. Acciones destructivas sin red. Borrar sin poder deshacer. Y su hermano peor: el diálogo de «¿estás seguro?», que la gente acepta sin leer después de la tercera vez. Deshacer es mejor que confirmar. Casi siempre.

5. Copiar el organigrama en el menú. El menú que refleja los departamentos de la empresa en vez de las tareas del usuario. A nadie le importa qué área gestiona qué: la gente busca «cambiar mi dirección», no «Área de Gestión de Datos Maestros».

Cómo se prueba esto sin presupuesto

La investigación de usuarios tiene fama de cara y lenta. La versión pobre funciona sorprendentemente bien:

Coge a cinco personas que se parezcan a quienes van a usar el producto. Cinco. Es la cifra que popularizó Jakob Nielsen: con cinco suelen salir ya los problemas gordos, y a partir de ahí cada persona nueva te enseña sobre todo lo que ya habías visto. Si tus usuarios son de perfiles muy distintos —clientes y personal interno, por ejemplo—, cinco de cada.

Dales una tarea concreta —«compra este producto», «date de alta», «cambia tu contraseña»— y luego haz lo más difícil que existe:

Cállate.

No expliques. No ayudes. No digas «tienes que darle ahí». Cada vez que sientas el impulso de intervenir, apunta el minuto: acabas de encontrar un fallo de usabilidad. Ese impulso es la métrica.

Media hora por persona. Arreglas lo que has visto y repites con otras cinco. Tres rondas pequeñas enseñan más que una grande, y bastante más que seis meses de reuniones sobre el rediseño.

Lo que ha cambiado, y no para bien

Dos apuntes de 2026 que me tienen algo cascarrabias.

Uno: la accesibilidad no es lo mismo que la usabilidad, pero es su prueba de esfuerzo. Lo que funciona con un lector de pantalla y solo con teclado suele funcionar mejor para todo el mundo. Los subtítulos los usa medio mundo en el metro. Las rampas las agradece cualquiera con un carrito. En mayo hay un día entero dedicado a esto y le dedicaré su artículo, pero quede dicho hoy: si tu web no se puede navegar con el tabulador, no tienes solo un problema de accesibilidad, tienes un problema de usabilidad. Y si vendes online a consumidores o eres una administración, probablemente también un problema legal.

Dos: la interfaz de conversación no arregla la usabilidad mala, la esconde. Poner un chat con IA encima de un sistema que nadie entiende es, otra vez, la pegatina de EMPUJE. Más grande, más cara y más elocuente, pero pegatina. Si tus usuarios necesitan preguntarle a un asistente dónde está el botón, el problema es el botón.

Feliz día

Así que hoy, si quieres celebrarlo de verdad, no leas un libro de diseño. Haz esto:

1. Abre tu producto en una ventana de incógnito.
2. Intenta hacer la tarea principal como si fuera la primera vez.
3. Apunta dónde dudas, dónde te equivocas y cuánto tardas. Los clics, también.
4. Y busca las pegatinas de EMPUJE que has ido pegando durante años sin darte cuenta.

Están todas ahí. Y cada una fue, en su día, la solución rápida a un problema que nadie quiso arreglar bien.

Que no cunda el pánico: las tenemos todos.