Usabilidad en los peajes I – Re-diseñando los rótulos

A pesar de que en Internet se pueden encontrar opiniones y análisis sobre cualquier tema imaginable, me ha sorprendido un poco no haber encontrado ninguna referencia sobre la usabilidad de los peajes, ni siquiera en inglés. Ya sé que no es un tema tan interesante como para hablar de él largo y tendido, pero cuanto menos es curioso. ¿O quizás es que yo soy el el único del mundo que necesita un pequeño esfuerzo mental para entender los rótulos y la caótica iconografía que los acompaña? ¿Seré yo el único al que no le gusta nada la interfaz de las máquinas de cobro? O quizás sea sólo desviación profesional…

Lo bueno de esto es que nadie ha hablado sobre esto antes y por tanto soy el primero que entre a explorar este territorio virgen. Con esta idea en mente y dado que tengo un esguince que me tiene impedido y no tengo nada más que hacer, voy a hacer una pequeña serie de artículos con propuestas sencillas y económicas de mejorar la usabilidad de los peajes.

En esta primera parte me centraré en exclusiva en el rotulado, que lógicamente incide en mucho en la usabilidad percibida de un sistema. En otro post intentaré escribir una pequeña crítica sobre la usabilidad de las máquinas de cobro de los peajes, que ese es un tema que merece también su propio post.

El primer problema de los peajes es la rotulación. Cuando nos aproximamos con el coche, nos encontramos con carteles de este tipo, al menos en Cataluña: MANUAL y AUTOMÁTICO.

Usabilidad en los peajes

Como todo buen profesional de la usabilidad sabe, el rotulado debe ser auto-explicativo por un lado y por el otro no llevar a confusión. Sin embargo, tanto las vías señalizadas como “MANUAL” como las de “AUTOMÁTICO” son todas manuales, no automáticas. Pagues con billetes y monedas o con tarjeta, ambos modos de pago son completamente manuales y no tienen nada de automático, en tanto en cuanto requieren que pares, que bajes la ventanilla, que pagues y que una vez se efectúe el pago se suba la barrera. No es pago automático porque no es que la máquina cobre por sí misma, quee s la definición de una máquina de pago automático. Esto viola uno de los principios más elementales de la usabilidad: la correcta rotulación a nivel semántico.

Adicionalmente, “AUTOMÁTICO” puede inducir a error a los usuarios del Teletac, que sí es un sistema de pago realmente automático en tanto en cuanto no requiere ninguna acción del conductor aparte de bajar un poco la velocidad. Un usuario del Teletac con toda la razón del mundo podría pensar que los carriles de “AUTOMÁTICO” son sus carriles, y que los de “MANUAL” son para los que no tienen de un sistema de pago automático porque manualmente, ya sea con billetes y monedas o con tarjeta.

En realidad, lo que distingue unos carriles de los otros no es otra cosa que el modo de pago. A diferencia de un supermercado en el que tanto los que pagan con billetes y monedas como los que pagan con tarjeta pasan por los mismos carriles o cajas, en los peajes se distingue a unos y otros, porque el dispositivo de cobro es diferente. Por tanto el rotulado debería expresar esto sin ambiguedades y los carteles sobre las vías deberían ser “AL CONTADO” y “TARJETA”. De este modo, se comunicaría fielmente e inequivocamente que se distingue a los conductores por cómo van a pagar.

En realidad, ésta tampoco sería buena opción, ya que en los carriles señalizados como “AL CONTADO” siempre hay un operario, y a éste se le puede pagar también con tarjeta. Por tanto, los rótulos deberían ser “AL CONTADO O TARJETA” y “TARJETA”. Lo mejor, por supuesto, es acompañar estos dos rótulos de iconos sencillos que apoyen y confirmen el mensaje para no dejar lugar a dudas. Con un sencillo icono de monedas y billetes, y otro sencillo icono de tarjeta es suficiente para acabar de comunicar que se distingue los carriles por cómo se puede pagar en ellos. Además, estos icono son necesarios para los extranjeros si el rótulo no está traducido, como es el caso aquí.

Por tanto, si antes tenían este aspecto:

Usabilidad en los peajes

Ahora tendremos éste otro:

Usabilidad en los peajes

Hemos eliminado los conceptos de “AUTOMÁTICO” y “MANUAL” porque, como hemos visto, son incorrectos y se prestan a confundir. Por otro lado, al integrar arriba los iconos de pago al contado y de pago con targeta, podemos eliminar los otros rótulos fluorescentes que están más abajo y que sólo añaden ruido visual. Las redundancias, en el caso de un sistema en el que hay pocos segundos para escoger, son negativas. También aprovechamos para quitar el rótulo verde con el icono de tarjetas que hay debajo del rótulo también verde para vehículos pesados, porque ahora es también redundante. Con lo cual la cosa nos queda así:

Usabilidad en los peajes

Pero aún hay muchas cosas que mejorar. Como bien sabe cualquier diseñador, los códigos cromáticos se suelen hacer servir para con diferentes intenciones. Pero lo que está claro es que los códigos cromáticos, si se utilizan, deben utilizarse siempre y bien. De otro modo, no sólo pierden su sentido, sino que confunden en vez de ayudar. En la imagen anterior a ésta última, hay un código cromático que identifica a los mensajes dirigidos a los vehículos pesados, el verde. El verde agrupa a 3 rótulos dirigidos a este tipo de vehículos.

Pero cualquier diseñador algo avezado en psicología humana sabrá que mucha gente, ante estos cuatro rótulos, deducirá con toda lógica que si el fondo verde se utiliza para significar “Vehículos pesados”, entonces por fuerza los fondos azul y blanco de los otros rótulos deben querer significar otros dos tipos de vehículos. Este tipo de razonamiento no es sólo completamente lógico, sino que además es también consecuencia del aprendizaje de las señales de tráfico, que son probablemente el mejor ejemplo de una señalética excelente que se basa, precisamente, en este tipo de códigos cromáticos. En el caso de las señales de tráfico, los fondos se combinan con la forma, con el borde y con iconos para expresar diferentes conceptos combinados. La gente ha aprendido a leer este tipo de códigos al estudiar para el carnet de conducir y los aplica también frente a la rotulación de los peajes.

En este peaje, parece que se ha utilizado el azul y el blanco con la intención de querer distinguir mejor un carril para pago con tarjeta y otro para pago al contado (y con tarjeta), pero es un error. En el código que estamos diseñando, los tipos de pago se comunican a través del icono y sólo a través del icono. Hacerlo de dos modos distintos, con color y con icono, como bien se sabe en usabilidad, es redundante y genera confusiones. “Dínoslo de una manera correcta, y de sólo una manera”, sería la frase.

En cambio, el color de fondo, lo estamos utilizando para identificar tipos de vehículos distintos. Verde para vehículos pesados, y por tanto el blanco o el azul, pero nunca ambos, para vehículos ligeros. En este caso prefiero utilizar el blanco, con lo cual la foto nos quedaría así:

Usabilidad en los peajes

Parece que queda más claro las dos famílias que hay, la blanca para vehículos ligeros y la verde para vehículos pesados. Pero aún queda un pequeño detalle. Dado que la redundancia es negativa como norma general en usabilidad y como norma particular cuando sólo se tienen unos cuantos segundos para tomar una decisión, como cuando uno se aproxima a un peaje, aún queda un pequeño detalle: eliminar el cartel verde con el dibujo del camión.

Finalmente, si lleváramos al extremo los principios del buen diseño y de la usabilidad, corregiríamos una asociación visual que es traicionera: el verde que identifica vehículos pesados es muy parecido al que hay en las balizas de los refugios entre carril y carril. Por supuesto, en este caso sería difícil que alguien entendiera que los vehículos pesados, identificados en verde, deben pasar por los carriles “señalizados” con balizas verdes, pero vamos a pasarnos de rosca e intentar resolver algo que no porque no nunca tendrá mayores consecuencias deja ser un error. Por tanto, cambiaremos el color verde de las balizas por uno que no se relacione en nada con los rótulos, ya que no tienen nada que ver. Hay que romper esta asociación cromática utilizando otro color.

Podríamos pintar las balizas de cualquier color excepto el blanco o el verde (ya que se asociarían con los rótulos), pero para ir a por nota, no escogeremos un color al azar, sinó que ayudaremos a distanciar más las balizas respecto de los rótulos asociando las balizas a las cabinas pintando las balizas de color azul. De este modo, ordenaremos el paisaje visual uniendo las balizas a las cabinas, comunicando por tanto que las balizas no tienen ningún significado, sino que forman parte de la estructura del peaje.

Operando estos dos cambios la cosa queda de la siguiente manera:

Usabilidad en peajes

OK, ahora queda más claro. Lo que hemos hecho ha sido rediseñar la rotulación de este peaje, de modo que esté más ordenada, más clara, tenga menos ruido visual,  y exija menos esfuerzo para ser comprendida. Para poder comparar este resultado con lo que teníamos al principio del rediseño, recupero la imagen original:

Usabilidad en los peajes

En el caso de un peaje, una buena rotulación no es una cuestión baladí, y de hecho puede tener un impacto notable. Por un lado puede ahorrar un gran número de errores como los que todos hemos visto muchas veces de coches que tiran marcha atrás porque se han equivocado de carril, y por el otro lado puede reducir el número de maniobras de último momento que algunos conductores  hacen cuando por fin localizan el carril por el que tienen que ir. En algunos casos, este tipo de maniobras provocan accidentes.

Hasta aquí el rotulado. En el próximo capítulo, cuando pueda, me centraré en las máquinas de cobro con tarjeta de los peajes.

Cómo medir la usabilidad de una web

La usabilidad es la capacidad de algo de ser usado. En el campo específico del diseño web, la usabilidad se refiere a la facilidad o dificultad con la que los usuarios de un website navegan, interactuan, encuentran información y, en general, realizan las acciones que quieren realizar en él.

Como la usabilidad es por naturaleza algo subjetivo y dificilmente medible, hay que recurrir a técnicas que, aunque aproximadas, son al menos más objetivas, para poder evaluar la usabilidad de un sitio o sistema web.

Una de estas técnicas es la medición de varias propiedades relacionadas con la facilidad de uso. Estas propiedades que hay que medir son las siguientes:

  • Satisfacción – Mediante un cuestionario anónimo
  • Eficiencia – Midiendo el tiempo que se tarda para realizar una(s) tarea(s) determinada(s)
  • Aprendabilidad – Midiendo el tiempo que se tarda en alcanzar un cierto nivel de conocimiento
  • Errores – Contando el número de errores que ocurren mientras se usa la web para completar una tarea determinada
  • Memorabilidad – Contando el número de respuestas correctas en un test de memoria del funcionamiento de la web

Algunas de estas propiedades son un poco subjetivas, como por ejemplo la satisfacción, pero aún así se puede evaluar especificando unos niveles-objetivo. Por otro lado, la eficiencia, la aprendabilidad, el cómputo de errores y la memorabilidad son propiedades más fáciles de medir matemáticamente.

Con esta técnica planteada, podemos estar seguros de que mediremos la usabilidad de un website de un modo bastante certero. De todos modos, hay otras variantes en este tipo de mediciones relativas a la usabilidad, como por ejemplo aquella en la que se miden sólo 3 factores: la eficacia (el usuario logra lo que quiere), la eficiencia (lo logra rápidamente y sin obstáculos) y la satisfacción (después de completar la tarea).

Con la técnica de las 5 propiedades, debemos asignar diferentes niveles -objetivo requeridos de usabilidad para cada propiedad que evaluamos. Por ejemplo, si la satisfacción la medimos en una escala de 1 a 5, en la que una satisfacción óptima es 5, podemos fijarnos como meta llegar al nivel 4, que ya es suficientemente difícil de conseguir, y podemos establecer que no daremos por buena una web cuya satisfacción en el uso esté por debajo de 3. Lo mismo con las otras propiedades.

A priori, otros atributos, como el número de errores, son más fáciles de evaluar, porque consiste en contar las veces que un usuario se equivoca al querer realizar una tarea. Pero ojo, no nos llevemos a engaño: identificar y comprender por qué suceden los errores requiere tanto experticia como experiencia.

Habitualmente, los requisitos de usabilidad que se quieren para un website se definen después de que se han establecido los requisitos técnicos, sin que ello suponga ningún problema. Pero si los requisitos de usabilidad se definen demasiado tarde en un proyecto web, entonces implementarlos puede ser terriblemente caro. Por tanto, idealmente los requisitos deben establecerse después del diseño y antes de la programación.

De todos modos, no está de más tampoco ir comprobando que la web cumple con los requisitos de usabilidad establecidos a medida que la vamos construyendo, es decir, en diferentes estadios del ciclo de desarrollo del proyecto. Ello nos ayudará a ir evaluando la usabilidad del sitio para que, cuando tengamos que realizar una medición de usuabilidad, logremos una buena calificación.

Por qué hay tan mala usabilidad en el open-source

¿Por qué las aplicaciones open-source suelen tener tan mala usabilidad? He aquí algunas de mis razones:

– Hay pocos incentivos para que haya una buena usabilidad. Los fabricantes de productos comerciales tienen que ganar dinero para pagar los sueldos de los desarrolladores, y eso significa que se deben esforzar en que sus productos sean usables, para maximizar ventas. En el open-source no existe esta obligación.

– Muchas aplicaciones open-source se entregan “as it is”; no suele haber un sistema de soporte técnico que colapse ninguna centralita si el producto tiene una mala usabilidad. En cambio, en el software comercial se intenta evitar al máximo las llamadas al soporte técnico y ello significa que se cuida la facilidad de uso. En el open-source los problemas de usabilidad en una aplicación no suelen tener ningún impacto en sus desarrolladores.

– Por su propia naturaleza, las personas involucradas en el open-source suelen estar centradas en el código. Cualquier otro aspecto es secundario. Ello incluye el diseño o la usabilidad, que son aspectos que quedan relegados. El resultado son aplicaciones con interfaces bastante caóticas, sin orden, jerarquía o estructura visual.

– Cualquier producto open-source necesita diseño, pero en cambio suele haber pocos diseñadores en el software libre. Tal como está pensado el open-source, no es lugar para un diseñador. Por ejemplo, mientras que un desarrollador puede identificar un bug y contribuir un patch para solucionarlo, un diseñador que encuentre un fallo de diseño o de usabilidad no puede más que indicarlo, y esperar que alguien de mala gana lo intente arreglar.

– Al no haber muchos diseñadores, muchas decisiones de diseño y usabilidad se deciden sin el criterio necesario. Al igual que los mejores intérpretes de música suelen ser pésimos compositores, los mejores programadores suelen ser pésimos diseñadores. La ausencia de criterio propicia decisones erróneas y, en consecuencia, en el desarrollo de aplicaciones con las que trabajar no suele ser muy ergonómico. En segundo lugar, al no haber diseñadores las decisiones se toman a modo de compromiso entre las sensibilidades de todos los programadores, lo que resulta en una interfaz sin unidad, integridad y consistencia.

– Los bugs son objetivos, los fallos de diseño o usabilidad son en su mayoría subjetivos. Cuesta mucho más aceptar un error de diseño que un error de funcionamiento, porque aquél es mucho menos obvio. También cuesta mucho más que el grupo de desarrolladores se ponga de acuerdo sobre si algo es un fallo de diseño o esa una “feature” especial. Al ser los errores de diseño o usabilidad más subjetivos, es más dificil llegar a su identificación.

– Se programa antes de diseñar. El software suele ser mucho más usable si se diseña antes de programar, pero los entusiastas voluntarios de muchos proyectos open-source tienen tantas ganas de escribir código que prefieren saltarse los wireframes, los prototipos y los mockups. Sin embargo, estos elementos inciden directamente en el flujo de trabajo y uso de la aplicación, por lo que afecta al modelo de datos, a los algoritmos, al orden en que las acciones se realizan, etc. Programar antes de diseñar es cómo construir una casa sin planos.

– Al ser programadores, los desarrolladores suelen ser también power users. En consecuencia, las aplicaciones están pensadas para usuarios avanzados como ellos, para los que los problemas de usabilidad de una aplicación pueden ser superados sin mayores esfuerzos, pero eso no ocurre con los usuarios normales. Ejemplo de esta mentalidad de power-user es la ausencia casi total de asistentes o de prompts que guíen la navegación, elementos que en cambio suelen ser habituales en los programas comerciales.

– Los programadores open-source, al ser voluntarios, trabajan en aquellos proyectos que les interesan. Eso suele resultar en una falta de capacidad de abstracción. Al estar tan metidos en ese proyecto, a los desarrolladores les falta distancia y visión global, y la empatía necesaria para ponerse en el lugar de los usuarios. Los árboles no suelen dejarles ver el bosque.

– Por su propio carácter libre, el open-source facilita el intercambio de código y la reintegración de componentes, por lo que a menudo muchos módulos de diferentes orígenes se integran en una única aplicación. Ello suele resultar en inconsistencias en el diseño, en el manejo, o incluso en el léxico empleado de las aplicaciones de software libre, perjudicando por tanto la usabilidad.

– Todos los programadores voluntarios quieren que su pieza de software o la funcionalidad que han desarrollado aparezca en la aplicación, y cuánto más aparezca, mejor. Para aplacar ese deseo y asegurar la continuidad del voluntario, esa funcionalidad suele meterse donde quepa y de la mejor manera, pero a menudo sólo estorba y añade caos a la aplicación, tanto a nivel de diseño como de uso. Del mismo modo, quitar componentes de la aplicación para poder mejorar la ergonomía de la aplicación suele poner furioso al desarrollador que los hizo, con lo que a veces continúan aunque sean un estorbo o rompan completamente el uso lógico de la aplicación.

– Las aplicaciones open-source suelen competir unas con otras por el nivel de features que tienen, no por su diseño o por su facilidad de uso, mucho menos por obtener una cualificación mayor en la capacidad que tienen de ser usadas por los usuarios. Ello significa que la featuritis suele primar por encima de la experiencia de usuario. La simplicidad se ve como una carencia de features, no como una virtud.

– Los programadores no suelen distinguirse por su sensibilidad estética, por lo que muchas aplicaciones tienen un aspecto visual que ellos dan por bueno pero que a menudo horrorizan a cualquier usuario normal y corriente. Que las aplicaciones aparezcan bien es tan o más importante que el que funcionen bien. Un diseño pobre no sólo decepciona estéticamente al usuario, sino que perjudica sobremanera su usabilidad.

– Detalles como informar al usuario del progreso de una acción con una barra de progreso, explicar lo que  ocurrirá al presionar un botón determinado, rotular correctamente los botones y las secciones, redactar con propiedad la mensajería del sistema o la ayuda, ilustrar la interacción del usuario con el sistema con estados como hover o focus no suelen ser muy excitantes para los programadores, por lo que suelen faltar en las aplicaciones realizadas por voluntarios. Sin embargo, tienen un efecto crítico sobre la experiencia de uso de la aplicación.

Open source no es lo mismo que software gratis (freeware), ni que software libre. Estas razones no pueden aplicarse a todas las aplicaciones open-source (por ejemplo, hay aplicaciones open-source de pago con muy buena usabilidad), sino a muchas aplicaciones que aparte de ser open-source son también gratuitas.

Diseño y Usabilidad en Suunto

Suunto

La reconocida marca finlandesa de instrumentos electrónicos de precisión Suunto tiene una graciosa y curiosa manera de explicar la historia del equipo de diseño y usabilidad de Suunto en su web:

Design & Usability

If you put together a group of professional designers, one psychologist and a cognitive scientist with various sports backgrounds including orienteering, free diving, surfing, sailing, triathlon, swimming, cycling, snowboarding and boxing you end up with the Suunto design group. I do not think there is (or even could be) a more versatile team at Suunto than the design group.

The design group was formed when two designers working at Suunto R&D hammered through the importance of the team in so many meetings, that nobody in the company could deny it anymore. Now the group holds an important role inside Suunto, bringing together the R&D, marketing, sales and production departments. And most importantly by taking care of the “look and feel” design of all Suunto products.

The group is full of creative guys. This is probably not the easiest team to work with though, being a little bit on the artistic side.

For the wrists of our loyal users, we at Suunto are constantly exchanging ideas and suggestions. This in fact brings up the point of usability, the inherent design principle of the whole group. Every single design decision is and will be, in one way or another, based on usability and our end users needs. All in all, the design group’s core competence is an ability to combine design, usability and concept research into the package of a small wrist top computer.

La parte dedicada al departamento de Ingeniería y I+D de Suunto tampoco tiene desperdicio; unas notas:

“They call me a sports nerd – but that´s ok… I work at Suunto R&D with a bunch of other similar minded YUP´s, Young Useful Propeller heads… Besides being a technology freak – which I am proud of – I also have a softer side: I understand that aesthetics is important in product design”

Definitivamente, me gusta la marca Suunto, son simpáticos y me caen bien, y además comparto sus valores referidos a la importancia del diseño y la usabilidad. Me han causado una muy buena impresión. Cuando me tenga que comprar un reloj será Suunto. ¡Eso sí que es una web comercial!