Los principios de usabilidad de Nielsen

Jakob Nielsen ya no es tan popular como hace unos años, pero me atrevería a afirmar que el conjunto de principios heurísticos de usabilidad más conocido sigue siendo el suyo:

  • Visibility of system status
  • Match between system and the real world
  • User control and freedom
  • Consistency and standards
  • Error prevention
  • Recognition rather than recall
  • Flexibility and efficiency of use
  • Aesthetic and minimalist design
  • Help users recognize, diagnose, and recover from errors
  • Help and documentation

Estos principios pretenden explicar problemas de usabilidad que podemos encontrar en una interfaz; pero la cuestión de la que quiero hablar es: ¿cuántos problemas explican? ¿la mayoría?

Para responder esta pregunta es práctico conocer de dónde provienen estos heurísticos.

En el año 1990 Rolf Molich y Jakob Nielsen publicaron el artículo “Improving a human-computer dialogue” en el que describían los resultados de un estudio sobre evaluación de interfaces. En el estudio montaron un concurso, con premio y todo, que anunciaron en la revista Computerworld. Consistía en encontrar problemas de usabilidad en una interfaz diseñada con algo de mala baba por los propios autores.

Interfaz monocroma en modo texto del concurso de evaluación de usabilidad.
«The telephone index system» Seductora, ¿verdad?

Molich y Nielsen determinaron su propia lista de problemas y los compararon con los que mandaban los participantes.

El tema que nos atañe es que para inventariar los problemas que ellos detectaron se sacaron de la manga nueve principios de usabilidad “inspirados” en las “Apple Human Interface Guidelines” de 1987. Eran estos:

  • Simple and Natural Dialogue
  • Speak the User’s Language
  • Minimize the User’s Memory Load
  • Be consistent
  • Provide Feedback
  • Provide Clearly Marked Exits
  • Provide Shorcuts
  • Provide Good Error Messages
  • Error Prevention

Años más tarde, en “Usability Engineering”, un libro publicado por Nielsen, se adaptaban ligeramente los nombres de algunos principios y aparecería uno nuevo:

  • (Provide) Help and documentation

El propio Nielsen decía en el libro:

“These principles can be used to explain a large proportion of the problems one observes in user interface designs”

Ya tenemos una primera aproximación a la respuesta de nuestra pregunta: “a large proportion”; pero sigamos investigando.

Nielsen en el 94 escribió «Enhancing the explanatory power of usability heuristics» donde sintetizaba un nuevo conjunto de principios de usabilidad. Se basó en su experiencia profesional y el análisis de varios conjuntos de heurísticos de distintas compañías (como Sun, Apple y Xerox) y otros especialistas.

Planteó inicialmente una lista de siete principios heurísticos que os resultaran familiares:

  • Visibility of system status
  • Match between system and the real world
  • User control and freedom
  • Consistency and standards
  • Error prevention
  • Recognition rather than recall
  • Flexibility and efficiency of use

¿Os habéis preguntado alguna vez por qué este orden y no otro?

Nielsen los “probó” con unos 250 problemas que tenía inventariados. Cada principio explicaba una cierta cantidad de dichos problemas y se limitó a ordenarlos de forma descendiente según la proporción. Es decir: existían más problemas categorizados como “Visibility of system status” que “Consistency and standards”.

A los siete principios añadió dos, menos frecuentes en general, pero importantes para poder explicar problemas “serios”:

  • Aesthetic and minimal design
  • Helping users recognize, diagnose and recover from errors

Lo divertido del asunto son las frecuencias concretas indicadas en el artículo. El primer principio solo explica un 6% de los problemas; la lista entera de nueve no llega ni al 35%.

Vamos, que más de la mitad de los problemas que podemos encontrar/cometer en una interfaz quedan fuera de los diez famosos principios heurísticos de usabilidad de Nielsen.

Con esto no pretendo decir que los ignoréis. Alumnos míos saben que dedico una apasionante sesión de 4 horas a explicarlos. Considero que deben ser aprendidos e interiorizados, que son una gran herramienta para evaluar y diseñar; pero deben ser tomados como lo que son: solo un punto de partida.

Publicado por

Dani Armengol

Consultor independiente de arquitectura de información