Categoría: Usabilidad e interfaces

Llego a una puerta, agarro la barra vertical y estiro. No se abre. Estiro de nuevo. Sigue sin abrirse. Veo entonces un cartel indicando “Empujar” y una cierta sensación de estupidez me invade.

No creo que esta situación os resulte muy extraña. La tecnología nos hace sentir estúpidos cuando no sabemos utilizarla. Nos sucede con los ordenadores, los grifos del baño y constantemente con todo tipo de puertas. En The Psychology of Everyday Things, Donald Norman introduce este tipo de situaciones y las ejemplifica justamente hablando de puertas. Son las llamadas «Norman Doors», puertas cuyo diseño nos indica que se deben abrir de una forma, pero realmente se abren al revés.

La revista Vox hizo recientemente un divertido vídeo con Norman sobre este tema:

Los que nos dedicamos a la usabilidad no solo intentamos que la tecnología, especialmente la digital, sea más fácil de comprender, aprender y utilizar; también pretendemos «evangelizar» para que cuando no sepamos utilizar algo no nos sintamos tan estúpidos, ya que en general la culpa no es nuestra, sino del diseño. ¿Pero lo estemos haciendo bien?

En el encuentro anual de profesionales de experiencia de usuario UXSpain, Asier Arranz hizo una interesante demostración en vivo de realidad virtual con unas Microsoft HoloLens. Durante la demostración intentó hacer una llamada vía Skype al centro de control del auditorio, pero a la primera no funcionó y tuvo que reiniciar Windows 10. “Esto nunca cambiará”, bromeó. Al segundo intento sí arrancó la videoconferencia y la sala estalló en un aplauso.

¿Por qué aplaudimos?

No me malinterpretéis, no le quito mérito a la charla ni al trabajo de Asier, y tengo presente que se trataba de un modelo especial, no comercializado y para desarrolladores; pero el aplauso me parece muy ilustrativo de las bajas expectativas que tenemos, me incluyo, con la tecnología digital.

Mi sensación es que ya no atribuimos tanto los problemas a nuestra torpeza, pero sustituimos la culpabilidad con simple condescendencia. Hemos llegado a un punto en que aceptamos que los programas se queden sin memoria y se bloqueen; que perdamos documentos de vez en cuando; que nuestro router deje de funcionar y tengamos que reiniciarlo (llegando al extremo de personas que compran sin ruborizarse este tipo de dispositivos); o que la mitad de llamadas que hacemos por Skype no conecten a la primera.

Nos sentimos tan identificados con el chiste de “esto nunca cambiará” al reiniciar Windows 10 que reímos implicados.

450 personas que nos dedicamos a la experiencia de usuario aplaudimos cuando algo, simplemente, se limita a funcionar como estaba previsto.

Da que pensar sobre dónde estamos realmente en la jerarquía de necesidades de Stephen P. Anderson.

 

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.

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.

Apreciado Responsable de Mensajes de Error:

He visto un mensaje tuyo y de aquí que te escriba esta misiva.

Quiero que sepas que la gente, la normal, no tú ni yo, cuando lee la palabra “puerto” piensa en un “lugar en la costa o en las orillas de un río que por sus características sirve para que las embarcaciones realicen operaciones de carga y descarga, embarque y desembarco, etc.”

Esto explicaría que mi padre no te entienda si le dices que “el puerto no está conectado” cuando intenta imprimir la declaración de la Renta.

Que hayas decidido usar la palabra “puerto” me hace pensar que quizás tengas un perfil técnico. Tranquilo, yo también, te entiendo: te veo intentando cumplir un deadline absurdo y con la responsabilidad delegada implícitamente de escribir los mensajes de error que tus compañeros «de UX» no se han molestado ni en pensar. Sí, esos mismos que pasan más tiempo preocupándose sobre qué buzzword poner en sus biografías de Twitter que en hacer su trabajo; yo también conozco algunos.

Pero vamos a intentar mejorar este mensaje de error en concreto. Y no, no me digas nada más empezar que el mensaje sólo puede indicar el síntoma y no la causa del problema.

¿No es justamente “el puerto no está conectado” una causa probable del síntoma “no llega señal al puerto”? No creo que puedas saber, técnicamente, si el problema es que el dispositivo no responde o es que está físicamente desconectado; pero bien que asumes esto segundo. Y no, no lo critico, entiendo que intentas hacer un mensaje explicativo y útil. Conozco personas que habrían escrito “Error 0x0554” y se habrían ido a casa orgullosas de un trabajo bien hecho.

Hagamos algo. Cambia simplemente la palabra “puerto” por “cable”. Sí, ok, hay puertos software y máquinas virtuales. ¿Crees que es el caso de muchos de tus usuarios? Y sí, existen conexiones inalámbricas, pero podemos mostrar otro mensaje para estos casos ¿no?

Ya te estoy robando demasiado tiempo, lo sé. Admito que no es trivial. No es simplemente escupir cuatro palabras en el fichero de localización de strings de la aplicación.

Pero mira, hagamos una cosa, ni tu ni yo, mantén el mensaje original, tal cual, pon de hecho lo que te dé la gana, haz de esa ventana modal tu lienzo de expresión personal, pero añadamos una línea debajo: “Comprueba que la impresora no esté apagada o el cable desconectado”.

Gracias.

Es más o menos conocido que al diseñar para pantallas táctiles debemos cuidar las dimensiones de los elementos interactivos. Deben superar cierto tamaño para que puedan ser pulsados minimizando el número de errores.

Pekka Parhi, entre otros, investigó empíricamente mediante tests de usabilidad esta cuestión y determinó unos tamaños mínimos aconsejables que teóricamente toda persona que diseñe para interfaces táctiles debería conocer.

Lo que no es tan conocido es porqué sucede esto.

La explicación habitual es que “tenemos los dedos gordos”. Según esta teoría, si alguien intenta pulsar repetidamente en un mismo objetivo visual, el punto de contacto entre el dedo y la pantalla será siempre distinto, con una distancia grande entre pulsaciones. Como si disparáramos a una pared con un arma automática sin estabilizar y viéramos los agujeros de bala muy dispersos pese a estar apuntando siempre en el mismo sitio.

Sin embargo, empíricamente se puede observar que esto no es cierto. Si se pulsa repetidamente en un mismo sitio las pulsaciones se concentran en un área mucho más pequeña de lo que la teoría del dedo gordo nos podría hacer pensar. Es decir, sí somos precisos, entendiendo precisión como el hecho de que pulsamos siempre en el mismo sitio. El problema, en todo caso, es que el sitio en el que realmente pulsamos y el que percibimos o creemos estar pulsando pueden ser distintos. Volviendo a la metáfora del arma, es como si realmente los agujeros no estuvieran dispersos entre sí, pero sí puede ser que nunca toquemos al blanco.

Esto es observable en cualquier test de usabilidad: vemos participantes que no tienen ningún problema en pulsar en zonas mucho más pequeñas de lo recomendado, mientras que otros son incapaces de hacerlo aunque pulsen repetidamente. Y no, unos no tienen los dedos más gordos que los demás. Simplemente su pulsación tiene un offset o desvío fijo: visualmente creen estar pulsando en un sitio, pero pulsan siempre algo más abajo o más arriba.

Christian Holz y Patrick Baudisch han propuesto el “Generalized Perceived Input Point Model” que explica estas observaciones con diversas variables, entre ellas el ángulo de contacto y el modelo mental de cada usuario, es decir, cómo entiende cada persona el hecho de “tocar”.

Los autores del modelo comentan que el problema, pues, es un caso de hardware no adaptándose al modelo mental del usuario y no tanto de una limitación inherente de nuestros mecanismos físicos para tocar.