¿Qué os parece volver a uno de los temas más clásicos del diseño UX: las 10 heurísticas de Nielsen? No para listarlos de forma académica (eso ya está muy bien cubierto en otros sitios) sino para ilustrarlos con ejemplos de interfaces que usamos a diario: Figma, Gmail, Notion y Spotify.
Porque una cosa es saber que «la visibilidad del estado del sistema» es un principio importante, y otra muy distinta es reconocerlo (o echar de menos su ausencia) mientras trabajas. Ese es el objetivo de este artículo.
(1) Visibilidad del estado del sistema
El sistema siempre debería informar al usuario de lo que está pasando, en tiempo razonable y de forma comprensible.
El ejemplo más interesante aquí es el guardado automático. Figma, Notion y Gmail guardan los cambios sin que el usuario tenga que hacer nada. Y esto ha generado un cambio de paradigma interesante: ya no necesitamos confirmar que el sistema funciona bien → asumimos que sí, y el sistema solo nos avisa cuando algo va mal, con un snackbar o un mensaje discreto.
Es una vuelta de tuerca a la heurística original: en lugar de informar constantemente del estado, se informa solo cuando el estado es problemático. El resultado es una interacción más fluida y menos ansiosa. Nos liberamos de tener que controlar el flujo de trabajo («¿Quieres guardar tus cambios antes de salir?») y podemos centrarnos en lo que estamos haciendo.
(2) Coincidencia entre el sistema y el mundo real
El sistema debería hablar el idioma del usuario, no el idioma técnico del desarrollo.
Figma lo hace bien con los nombres de sus herramientas: mano para moverse, lapiz para dibujar, marco para agrupar. Son metáforas del mundo físico que cualquier diseñador entiende sin leer un manual.
Gmail lo aplica también con términos como «bandeja de entrada», «borradores» o «papelera» → conceptos directamente tomados del mundo de la correspondencia física. El usuario no tiene que aprender vocabulario nuevo porque ya lo conoce.
Cuando esta heurística falla, los usuarios se sienten perdidos en un sistema que habla un idioma que no es el suyo.
(3) Control y libertad del usuario
Los usuarios cometen errores. El sistema debe ofrecer salidas claras: deshacer, rehacer, cancelar.
Figma es un ejemplo muy sólido aquí. El Ctrl+Z funciona con mucha profundidad → puedes deshacer decenas de acciones sin perder el hilo. Y si necesitas ir más atrás, el historial de versiones guarda automáticamente el estado del archivo a lo largo del tiempo, permitiendo volver a cualquier punto sin haber hecho nada especial para guardarlo.
Gmail también aplica esto bien con el «Deshacer envío»: si activas esta opción en la configuración, tienes unos segundos después de pulsar enviar para arrepentirte. Es una salida de emergencia pequeña pero muy agradecida cuando has enviado un correo antes de tiempo.
Cuando esta heurística falla, el usuario siente que está trabajando sin red. Y eso genera tensión, indecisión y errores mayores por miedo a cometer errores menores.
(4) Consistencia y estándares
Los usuarios no deberían tener que preguntarse si dos cosas distintas significan lo mismo.
Notion es un buen ejemplo de consistencia interna: el mismo gesto (/) sirve para insertar cualquier tipo de bloque en toda la aplicación. No importa si estás en una página, una base de datos o un documento. La lógica es siempre la misma.
Cuando la consistencia falla, el usuario pierde la confianza en el sistema porque no puede predecir qué va a pasar. Y un sistema impredecible es un sistema que cansa.
(5) Prevención de errores
Mejor que un buen mensaje de error es un diseño que evite que el error ocurra.
Figma lo hace bien con las restricciones de componentes: si un componente tiene propiedades bloqueadas, no puedes editarlas por accidente desde una instancia. El sistema te impide el error antes de que lo cometas.
Gmail también aplica esto con la detección de adjuntos: si escribes «adjunto» en el cuerpo del correo y luego intentas enviarlo sin adjuntar nada, te avisa antes de que pulses enviar. No te deja cometer el error sin avisarte.
Son decisiones de diseño pequeñas con un impacto enorme en la experiencia del usuario.
(6) Reconocimiento en lugar de recuerdo
El usuario no debería tener que recordar información de una parte de la interfaz para usarla en otra. Todo lo necesario debería estar visible o fácilmente accesible.
Figma lo aplica muy bien en la búsqueda de componentes: cuando buscas un componente en la biblioteca, ves un preview visual antes de insertarlo. No tienes que recordar cómo se llamaba el componente exacto ni cómo lucía → lo reconoces visualmente.
Gmail también funciona así con el autocompletado de destinatarios: empieza a escribir un nombre y el sistema sugiere contactos con foto y nombre completo. Reconoces a la persona sin tener que recordar su dirección exacta de correo.
(7) Flexibilidad y eficiencia de uso
El sistema debería ser accesible para usuarios nuevos y eficiente para usuarios avanzados. Los atajos existen para los que los necesitan, sin estorbar a los que no.
Figma es un ejemplo brillante aquí: tiene shortcuts para prácticamente todo, y además los muestra de forma contextual junto a cada opción del menú. El usuario avanzado trabaja casi sin tocar el ratón, mientras que el usuario nuevo puede hacer lo mismo desde los menús sin sentirse limitado.
Spotify, sin embargo, rompe esta heurística en móvil con la posición del botón «+ Crear». Está colocado al final de la barra de navegación, en el extremo derecho, justo donde el pulgar llega primero. Para muchos de los usuarios que escuchan música y no crean listas cada día, ese botón es un obstáculo que se interpone entre ellos y «Tu biblioteca», que debería ser la acción más accesible. La eficiencia se ve comprometida por una decisión de prioridad que no refleja cómo usa la mayoría la aplicación.
(8) Diseño estético y minimalista
Cada elemento que no aporta información relevante compite por la atención del usuario. Menos es más, siempre que ese menos sea suficiente.
Figma en su interfaz principal es un buen ejemplo: el canvas es limpio, los paneles laterales son colapsables y los iconos de herramientas son minimalistas. No hay ruido visual compitiendo con el trabajo.
Notion también lo aplica bien: el editor empieza vacío, sin barras de herramientas visibles. Las opciones de formato aparecen solo cuando las necesitas, al seleccionar texto. El diseño no interrumpe el pensamiento.
(9) Ayudar a reconocer, diagnosticar y recuperarse de errores
Los mensajes de error deberían estar en lenguaje humano, explicar qué ha pasado y sugerir cómo solucionarlo. Sin códigos de error, sin jerga técnica.
Gmail tiene aquí un caso interesante que rompe esta heurística de forma sutil. En la app móvil, deslizar un correo hacia la izquierda lo archiva. Hasta ahí bien. Pero si luego quieres encontrar ese correo archivado → para restaurarlo, por ejemplo → no hay ninguna carpeta «Archivados» visible en el menú lateral. Hay «Papelera», hay «Spam», pero los archivados desaparecen de la vista sin dejar rastro claro de dónde han ido.
El usuario que archivó por error un correo importante tiene que investigar para encontrarlo. No hay ningún mensaje que diga «este correo ha sido archivado → puedes encontrarlo aquí». El sistema no ayuda a recuperarse del error porque ni siquiera comunica claramente que ha ocurrido uno.
(10) Ayuda y documentación
Lo ideal es que el usuario no necesite documentación. Pero cuando la necesita, debería ser fácil de encontrar, específica para la tarea y orientada a la acción.
Figma tiene una documentación excelente, pero lo que más me parece útil es cómo integra la ayuda contextual dentro de la propia herramienta: tooltips que aparecen al pasar el cursor sobre cualquier elemento, con el nombre de la herramienta y su atajo de teclado. La documentación está donde la necesitas, no en una pestaña separada que tienes que ir a buscar.
Notion también integra guías y plantillas directamente en el onboarding, sin que el usuario tenga que salir de la aplicación para aprender a usarla.
No son reglas, son preguntas
Las heurísticas de Nielsen no son una lista de cosas que tienes que cumplir para que tu diseño sea correcto. Son preguntas que vale la pena hacerse mientras diseñas.
¿Sabe el usuario qué está pasando? ¿Puede volver atrás si se equivoca? ¿El sistema habla su idioma o el nuestro? ¿Estamos poniendo demasiadas cosas donde solo debería haber pocas?
Si ya conocías estas heurísticas de nombre pero nunca las habías visto aplicadas a herramientas concretas, ahora tienes un punto de partida. La próxima vez que algo te moleste en una interfaz, intenta ponerle nombre. Casi siempre hay una heurística detrás.