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.

Dos ideas sobre diseñadores y científicos

Diseñadores trabajando sobre la IA de un website

Dos ideas:

El diseño es esencialmente prescriptivo mientras que la ciencia es predominantemente descriptiva. Los diseñadores no se encargan de cuestiones como qué es, cómo y por qué, sino con lo que podría ser o lo que debería ser. Mientras que los científicos pueden ayudarnos a entender el presente y predecir el futuro, los diseñadores prescriben y crean ese futuro.

Los diseñadores, a diferencia de los científicos, parece que no tienen derecho a equivocarse. Mientras que a menudo se acepta que una teoría científica que ha sido deprecada puede haber contribuido al avance de la ciencia, raramente a los diseñadores se les reconoce una contribución de este tipo.

(inspirado por How Designers Think)

El espacio en blanco y la visibilidad relativa

Espacio en blanco

Un tema recurrente en las relaciones entre diseñadores y clientes y que ya ha sido comentado, entre otros sitios aquí y aquí, es el empleo del espacio en blanco. En este post intento explorar un poco más la cuestión, pero además aportar también una manera fácil y objetiva de explicar al cliente la importancia del espacio en blanco y su papel en cualquier diseño, y así intentar evitar atiborrar cada píxel del diseño que realizamos.

El uso (y el no uso) del espacio en blanco (que por cierto, no tiene por qué ser blanco) es uno de los motivos típicos de discusión entre diseñadores y clientes. Para los diseñadores, es un espacio necesario para mantener el equilibrio y el orden del diseño. Para los clientes, es un espacio vacío y desaprovechado que podría aprovechar para introducir nuevos elementos.

En la mayoría de los casos, a grandes rasgos son los diseñadores los que tienen razón, aunque ello está exento de mérito teniendo en cuenta que se trata de una cuestión técnica de diseño. Es un hecho que el uso inteligente del espacio en blanco es un elemento esencial del buen diseño. El espacio en blanco es como la respiración en poesía, algo necesario.

Pero el problema es otro. No es tanto que el cliente quiera rellenar cualquier espacio en blanco que encuentre, como que nosotros, los diseñadores, no somos capaces de justificar su uso, y por tanto no acabamos de convencer al cliente sobre por qué debería dejarl ese espacio en blanco. Solemos defender el uso de espacio en blanco aduciendo que “queda mejor” o que “queda más bonito”. Con estas justificaciones, es normal que no se logre convencer a ningún cliente. Sin embargo, bien argumentado y explicado, es incluso posible obrar el milagro de que el cliente acabe apoyando el uso del espacio en blanco. Sí, es posible.

Cuando defendemos el uso del espacio en blanco alegando que “queda bien” o que “así respira más”, nos estamos equivocando. Son argumentos muy débiles. Debemos justificarlo de otra manera: deberíamos defender su uso explicando que cada elemento nuevo que se añade al diseño le resta importancia a los demás elementos. Eso sí lo entiende un cliente. En otras palabras, cuanto más elementos añadas, menos importancia obtienen todos y más diluido (y menos impactante) será el resultado. El diseño pierde efectividad entre el ruido que se genera. Eso sí lo entiende un cliente. El diseño de impacto necesita el uso prolijo del espacio en blanco para que el mensaje principal aparezca en soledad, esté libre de distracciones, sea único y por tanto atraiga magnéticamente toda la atención. El espacio en blanco, más que espacio desaprovechado, es la luz que ilumina un elemento del diseño. Cuanto más espacio en blanco tenga a su alrededor, más visibilidad obtendrá. Eso sí lo entiende un cliente.

He hecho mención al término “visibilidad”. En cualquier diseño, rápidamente se puede comprobar que cuantos más elementos se añaden a un tapiz, más probable es que los elementos más importantes se pierdan entre la multitud. Eso va en detrimento de lo que suelen querer muchos clientes: atención e impacto. En cambio, con la utilización de espacio en blanco, la supuesta oportunidad perdida de no aprovecharlo se compensa con la obtención de una mayor atención a los elementos restantes, que obtienen una visibilidad aún mayor. Eso es lo que se llama técnicamente “visibilidad relativa”.

Hay una manera muy clara de explicar el concepto de visibilidad relativa, y este concepto nos puede ayudar mucho a explicar a nuestros clientes la necesidad del espacio en blanco de un modo convincente. Hay un hecho incontestable y es que la atención de la audiencia es limitada, y que por tanto no por añadir más elementos a un diseño se obtiene más atención por parte del lector. Digamos por ejemplo que un lector dispone de 10 puntos de atención sobre un anuncio. Si en el anuncio sólo hay un mensaje, ese mensaje obtiene 10 puntos de atención. Si hay dos mensajes expresados gráficamente en igualdad, cada uno de ellos obtiene 5 puntos de atención. Si hay un slogan, una foto, un texto y un logo, el reparto de la atención del lector se hará acorde con la importancia visual que el diseñador haya asignado a cada elemento. En un caso típico, el slogan se llevaría 3 puntos, la foto 4 puntos, el copy 1 y el logo 2 puntos.

Por tanto, dado que la atención es limitada, utilizar espacio en blanco en un diseño no es desaprovechar territorio, sino dar más puntos de atención al resto de elementos, concentrar la atención en otros elementos. Es una manera de dar importancia a algo y de guiar el ojo del usuario hacia lo que queremos destacar.

El sistema de puntos de atención no sólo nos permite explicar muy bien el rol que juega el espacio en blanco en un diseño, sino que también es muy práctico para poder definir conjuntamente con el cliente la importancia que tienen varios elementos dentro de una composición. Asignándoles puntos hasta llegar al tope de 10 puntos (algo así como el “saldod e atención” del lector), el cliente puede priorizar los elementos de un modo más objetivo y comprensible para nosotros, y nosotros repartir consecuentemente la atención del lector a los diferentes elementos según la importancia que les ha sido atribuida. Por supuesto, ello lo conseguiremos otorgando más o menos relevancia visual a los elemento mediante colores, distribuciones, contrastes, gruesos, formas, tipografías… y sí, también con espacios en blanco.