Test de usabilidad automático

Estamos ante un panorama donde el desarrollo de aplicaciones con tecnologías web está creciendo muy rápidamente y esto merece una atención especial. En concreto lo que respecta a la tradicional analítica web no parece salir de los modelos de aplicaciones como los e-commerce o redes sociales a la hora de ofrecer herramientas que permitan entender e interpretar ‘lo que está pasando’ desde una perspectiva de usuario. Plantearnos cómo podemos mejorar estas herramientas de analítica para entender cómo se comportan nuestros usuarios al mismo tiempo que capturamos datos globales sobre su experiencia y su percepción de usabilidad nos ayudará a tomar mejores decisiones de diseño.

En este artículo busco describir un modelo de automatización de los tests de usabilidad con usuarios como continuación del trabajo anterior ‘Measuring UX with your own tools’ con el que poder:

  1. Medir y analizar grandes cantidades de datos generados por los usuarios.
  2. Hacer del diseño un proceso experimental y cuantificable.

Partimos de que la Experiencia de Usuario abarca muchas más cosas que la interacción del usuario con el producto digital a través de su interfaz, pero que esta interacción condiciona su experiencia y es una parte fundamental de la misma. Dejando un lado la visión holísitica del término, la teoría de la actividad vendría a describir el framework en el que se basa este modelo de representación, análisis e interpretación, aunque no está limitado al mismo. Este trabajo también se inspira en la metodología HEART de Google como método para medir la UX a gran escala para aplicaciones web.

Read more

Consecuencias de un mal diseño

Es interesante ver que, a pesar de los múltiples esfuerzos de la industria del diseño (de moda, industrial, etc.) por hacernos valorar y apreciar la distinción que supone un buen diseño de uno malo o de la ausencia total del mismo, seguimos encontrándonos con productos mediocres. De éxito en algunos casos, pero mediocres en su conformidad y la ignorancia del impacto que esto tiene en el usuario final. Los hay mediocres a propósito (pero simplemente como estrategia) y los hay mediocres por el abuso de patrones oscuros (dark patterns) que utilizan para “persuadir” engañando a sus usuarios.

Si partimos de la hipótesis de que un producto estará bien diseñado si el público para el que está destinado será capaz de usarlo de forma efectiva (puede realizar una tarea), eficiente (en términos de esfuerzo mínimo requerido) y satisfactoria (grado de ‘felicidad’ de la experiencia), cumpliendo sus objetivos y necesidades; éste será percibido positivamente, haciéndolo deseable y quizá justificando una razonada y consciente voluntad de adquisición y aprovechamiento del mismo.

Un mal diseño no es algo excesivamente difícil de identificar. Un ejercicio que practico a menudo y que me ayuda a interiorizar ciertas ideas es repasar los principios heurísticos de usabilidad de Nielsen.

La ausencia de usabilidad genera una mala experiencia

Generalmente, para identificar si un producto es usable o no, podemos atender a dichos principios. Preguntas como “¿el feedback devuelto tras una acción permite al usuario entender lo que está pasando?” cuya respuesta esperada debería ser binaria, ‘Sí’ o ‘No’, me gusta plantearlas desde otra perspectiva: ¿cuál es la consecuencia probable de que el usuario no entienda lo que está pasando tras hacer la acción X? En mi opinión, aquí es donde la ausencia Usabilidad se convierte en una mala Experiencia de Usuario.

Nos encontraremos por tanto que el impacto que puede tener un producto poco usable genere en el usuario ideas del tipo:

  • No entiendo lo que está pasando
  • Nunca antes había visto esto
  • No tengo control sobre lo que hago
  • Me equivoco con frecuencia
  • No me siento cómodo
  • Es desagradable
  • No puedo solucionar un problema
  • Me frustro

Si bien el enfoque a la hora de diseñar no debe tratar sólo de evitar estas ‘malas experiencias’, sí podemos al menos establecer un criterio de calidad mínimo imprescindible a partir del cual podremos experimentar, arriesgar y provocar experiencias únicas, originales y significativas.

Tiene sentido definir un término como la Experiencia de Usuario

La Experiencia de Usuario (UX) es una disciplina holística, lo es todo, es el alfa y el omega, el principio y el fin, el caos y el orden y si le preguntas a un diseñador de UX te dirá que “cualquier cosa que hagas tú que no haya hecho él NO es UX”. Somos así.

UX es un término difícil de definir y, sin embargo, después de tantos años, me sigo encontrando con el mismo problema cuando tengo que explicarlo en algún taller o charla de introducción. Mejor o peor, esta es la forma en la que intento enfocar la definición del término: contando la historia sobre cómo llegué a valorar lo que significa ‘Experiencia de Usuario’.

Cómo llegué a entender el valor de la UX

En todo este tiempo de profesión creo que no llegué a entender bien la importancia de la UX hasta un día que, visitando el museo de Ciencia e Industria de Mánchester, muy recomendable por cierto, me encontré con una historia muy curiosa que me fascinó y está relacionada con la siguiente ilustración la cual representa un ‘día cualquiera’ en una fábrica algodonera.

 

IndustrialRevolutionManchester
Entre 1780 y 1820. La revolución de las máquinas

Ésta es una ilustración de cómo eran las máquinas entonces, el detalle de esta imagen está en esa niña pequeña. La razón por la que esa niña (al igual que otros niños de la época) trabajaba como un adulto era, entre otras cosas, porque las máquinas algodoneras estaban diseñadas de tal forma que obligaban para su funcionamiento que una persona, generalmente un niño, de no más de un metro de altura se moviera bajo el tejal para recoger el sobrante textil, evitar que la máquina se atrancara y mantener la cadencia de producción, incluso a riesgo de su propia salud física.

La verdad es que hasta que no vi estas imágenes no entendí el impacto tan grande y tan relevante que podía tener algo mal diseñado, mal ‘planteado’. Porque eso es lo que era, estas máquinas estaban simplemente pensadas para producir, para funcionar en un contexto mercantilista, pero no para que las manipulase un ser humano (adulto a ser posible) durante diez horas al día.

Todo esto sucede en el contexto de la Primera Revolución Industrial, época que incrustó en nuestra sociedad la creencia de que mediante la transformación tecnológica se perpetuaría la filosofía de la innovación, la modernidad y el progreso. ¿Os suena este pensamiento?

Mientras tanto el recién nacido mundo del cine comenzaba a reflejar cómo evolucionaría esta hasta la exageración proyectando distopías como la que veíamos en Metrópolis. Nada más lejos de la realidad ¿no?

Volviendo a la ciencia no ficción.

La ergonomía se ocupó entonces, y menos mal, de practicar un diseño que se adaptara a nuestras características físicas, psicológicas y ambientales. Personas, máquinas y contexto como principios fundamentales para el desarrollo de la tecnología.

Intencionada o no, las consecuencias de un buen diseño tendrían un enorme e irremediable impacto en nuestra sociedad como hemos visto. Tal y como vemos actualmente.

Seguimos con la historia y no tuvimos que esperar mucho para Revolución de la Computación. Personajes como Ada Lovelace o Alan Turing contribuyeron al surgimiento de una era histórica única, una era en la que las máquinas serían cada vez más inteligentes y sustituirán, quizá, el esfuerzo intelectual, de cálculo y procesamiento de información. La Informática como rama de estudios de todas estas ideas, nada que no sepáis.

eniac
Dos mujeres programando la ENIAC (1945-47) – US Army

Y desde este contexto, el equivalente histórico: la Interacción Persona-Ordenador, como área de conocimiento que estudia el diseño de estas ‘máquinas inteligentes’ para construirlas de acuerdo a las características de las personas que estaban destinados a usarlos.

Digamos que uno, quizá el primero, de los pasados de la Experiencia de Usuario reside desde el aspecto técnico, pero no es el único. César Astudillo lo cuenta muy bien en su artículo ‘¿Para quién luchamos?’. En el campo UX conviven ‘linajes distintos’. Como hemos visto los profesionales del diseño, pero también de las ciencias humanas, psicología, sociología, gente de negocio, de márketing y comunicación.

Pero ¿qué tenemos en común? Que todos desde nuestra forma de ejercer esta profesión vemos en la Experiencia de Usuario un espíritu de cambio. La UX surge como fenómeno transformador de la tecnología de trascendencia humanista.

La UX ya ha transformado el concepto de Usabilidad. No se limita por tanto únicamente a analizar la facilidad de uso (eficacia, eficiencia y satisfacción) de las personas que utilizan productos interactivos sino que alude también a un factor emocional del usuario. No se limita a calificar los productos de usables o útiles, sino que abarca las vivencias y las relaciones de las personas con dichos productos a lo largo del tiempo.

Como dice Nate Bolt, autor del libro Remote Research:

You don’t come up with an iPod just by making a Walkman really easy to use.

En este sentido el contexto emocional se suma al contexto de uso como factor determinante de la posible experiencia de usuario. En dicho contexto, se tienen en cuenta tanto sentimientos pre-asociados, como el actual estado de ánimo y emociones evocadas por el producto y afecta entre otras cosas a la capacidad de aprendizaje, atención, memorización, rendimiento y percepción de utilidad.

El término de UX según Donald Norman

En cualquier caso, si todo esto no ha terminado de convencerte mi sugerencia es leer y escuchar a los más grandes en este campo.

 

Interfaz de línea de comandos: ¿un paradigma poco popular?

Han pasado ya unas cuantas semanas desde que empecé en mi nuevo trabajo y tenía muchas ganas de hablar de unos cuántos temas que han ido surgiendo durante todo este tiempo.

Uno de los que más interés me está causando, debido a su estrecha relación con la Interacción Persona-Ordenador (HCI) es el de las Interfaces de Línea de Comandos (CLI) y lo usable (o no) de su diseño.

No es éste un tema habitual ya que, usualmente, todo lo que tiene que ver con la Usabilidad y Experiencia de Usuario se termina ligando inevitablemente a las Interfaces Gráficas de Usuario (GUI) ya sean web, móviles, de escritorio u otras superficies. Lo cierto es que, desde que la metáfora visual se utiliza como representación del modelo de comunicación entre personas y computadores, la necesidad de diseñar estas interfaces de una forma eficiente para su uso se convierte en una obligación.

¿Pero qué ocurre con las CLI? ¿Se les puede aplicar criterios cualitativos de usabilidad? Más allá de los estándares que ya existen ¿representa la línea de comandos un paradigma relegado a un modelo de uso en declive o poco popular?

Haciendo un poco de investigación me topé con algunos recursos interesantes que me sorprendieron.

El primero que recomiendo es este libro: Build Awesome Command-Line Applications in Ruby 2: Control Your Computer, Simplify Your Life

Claramente destinado a programadores de interfaces de comandos pero con un enfoque muy serio en cuanto al respeto hacia los estándares para desarrollar algo suficientemente familiar. En el libro se destacan varias ideas en su introducción y conclusión:

  • Las CLI están focalizadas a scripting.
  • Las CLI no suelen utilizarse para el trabajo final, sino como recurso.
  • Las CLI son un white canvas (con los problemas de usabilidad inherentes que eso conlleve).

Pero por el contrario

  • Las GUI son interfaces muy difíciles de automatizar.
  • Las GUI no son interfaces fácilmente portables.

Quiero referenciar también el post que encontré en Biko que, curiosamente, trata el aspecto gráfico o visual de las CLI para hablar sobre UX. Sin faltarle razón creo que es un tema en el que se puede profundizar hacia muchos más aspectos.

Otro interesantísimo recurso que encontré fue este artículo escrito por Florian Cramer y Kamen Nedev que me parece simplemente imprescindible: Poética de la línea de comandos donde ejemplifica la diferencia entre los dos paradigmas de una forma muy sencilla:

La interfaz de línea de comandos provee funciones, no aplicaciones; métodos, no soluciones, o: nada más que un montón de plug-ins para ser promiscuamente enchufados unos en otros. La aplicación puede construirse, y la solución puede ser inventanda, por los propios usuarios.

[…] O, también, el paradigma Lego de un juguete auto-definido frente al paradigma Playmobil de un juguete predefinido.

Finalmente, me gustaría incluir algunos ejemplos de interfaces que, si bien no son líneas de comandos clásicas orientadas a usuarios administradores de sistemas, sí hacen uso del lenguaje natural en formato textual para interaccionar con los usuarios.

Seguramente haya muchos más ejemplos, si conoces alguno te animo a que los compartas conmigo.

Una última reflexión que me surge es sobre la necesidad/oportunidad de evolucionar las CLI para que aprovechen mejor el factor de forma de algunos dispositivos móviles como Blackberry (que se niega a morir). A fin de cuentas aún hay millones de usuarios que se comunican y se entienden con mensajes de menos de 140 caracteres.

Google podría considerar otra interfaz más de comandos.

Cómo hablarle a los usuarios / Cómo no informar de los errores 

De qué hablamos cuando hablamos de informar a los usuarios, cuál es el mejor modo de hacerlo para saltar de la mera muestra de información a una comunicación más natural, más humana. Siguiendo los ejemplos de la foto, estas son mis reflexiones.

Título

No estás conectado vs VimeoError

Mientras el primero de ellos sintetiza un estado general del usuario de forma clara, el segundo se decanta por usar un código del sistema para resumir lo que ocurre. VimeoError nos hace pensar que algo ha podido incluso romperse, que algo hemos hecho mal, quizá el propio hecho de haber intentado usar la app. No estás conectado no dice claramente que sin conexión no hay contenido que ver.

Mensaje

La conexión Wifi y los datos móviles están desactivados. La página se podrá cargar cuando te conectes a una red. vs Could not connect to the Vimeo server. Please check your network settings.

Obviando que uno de ellos esté en inglés, aunque resulte más inaccesible para muchos usuarios, la gramática de ambos mensajes es diametralmente opuesta también. El primero se centra en explicarte qué significa No estás conectado y qué debes hacer para volver a estarlo sin más. El segundo insiste en describirse como un fallo de la app, de algo que escapa del control del usuario (el servidor) y que miremos la configuración de la red. No sabemos muy bien si también nosotros como usuarios hemos configurado mal nuestra red de repente y tendríamos que cambiar muchos parámetros, quizá baste con ‘encender la WiFi’, quién sabe…

Icono

Dinosaurio vs Alerta!

Sin duda, el primero de ellos no sólo intenta suavizar la gravedad del mensaje explicado la situación y la forma de salir de ella sin que cunda el pánico, sino que además busca simpatizar con un recurso gráfico que recuerda a la prehistoria, relacionando el hecho de la falta de conexión a Internet como algo de otra época. Esta línea de diseño emocional contrasta con la visualización de un icono de Alerta que enfatiza la gravedad de lo que ha pasado, aunque se contradiga incluso con el nivel de gravedad: ¿es una alerta o un error?

Control de acción

Más vs Cerrar

Una vez entendido o no el mensaje, la acción se ofrece como última escapatoria para el usuario. Más sugiere ampliar la información acerca de lo que ocurre, la confianza de que es posible hacer o saber algo más acerca de lo que sucede y por tanto yo, el usuario, podré saber cómo solucionarlo. Cerrar es simplemente una señal de que eso era todo y lo que pase después de cerrar es imprevisible.

Contenedor

Dentro del contenido vs Pop Up

El contexto también es importante y en el uso de móviles incluso más debido al espacio reducido para mostrar los contenidos. Usar ventanas modales ha sido una práctica común en aplicaciones de escritorio ya que ayudaba al usuario dentro de toda esa marabunta de ventanas a centrar su atención en el mensaje y tomar una decisión y una acción concreta. Usar un Pop-Up en un móvil en el que todo el contenido visible es ese mensaje (ya que no hay ni conexión ni se han cargado datos), además de ser innecesario me fuerza a considerar el mensaje como prioritario en mis atenciones, aunque lo primero que quiera hacer no sea interaccionar con él sino salir de allí como sea.

Conclusiones

Informar de los errores sin más no significa haber alcanzado un buen nivel de usabilidad en una aplicación, el modo en que esa información se dirige a los usuarios es clave para que éstos sepan qué está pasando y cómo pueden salir de ellos. En este contexto, el tono del mensaje debe acertar con la gravedad del mismo, entender que se dirige a un humano que no tiene que entender nada de sistemas, servidores o bases de datos, sino, a lo sumo, de su micromundo móvil que lleva en la mano.

El ejemplo de Google Chrome me parece fantástico para mostrar como un Diseño Emocional no significa hablarle a los usuarios de forma ‘jovial’ o personificada, sin sólo entender el contexto, empatizar con el humano que lo está usando y reforzar la confianza de que se puede prolongar un uso satisfactorio de la app a lo largo del tiempo.

Siento que Vimeo haya salido mal parado en esta comparación a pesar de sus muchas bondades sigue estando un poco oxidad.

Checkbox tri-estado

El pasado 6 de Mayo, el equipo de BalsamiqNext incluyó, por fin, el estado ‘indeterminado’ para el control de Checkbox.

El uso de este estado es muy marginal, pero sigue siendo sin embargo necesario cuando queremos mostrar checkboxes anidados, en concreto cuando el elemento padre contiene alguno de sus elementos hijos en estado ‘seleccionado’ y al menos uno en estado ‘normal’.

Sin embargo, esta representación tri-estado es considerada en ocasiones demasiado confusa para los usuarios, probablemente porque un estado indeterminado es de por sí ambiguo y poco específico ¿cuántos y qué elementos están realmente seleccionados?

Otra problemática es que este estado a veces no es activado por interacción directa del usuario sobre el control, sino por el estado de los elementos hijos, con lo cual, la representación visual puede despistar.

Incluso cuando es el usuario quién lo acciona de forma directa, continúa siendo difícil entender qué significa un estado intermedio entre seleccionado y no seleccionado.

No obstante, su uso sigue viéndose en ciertas aplicaciones, por ejemplo cuando debemos hacer selección múltiple sobre muchos elementos que además vienen agrupados para su mayor legibilidad y cuando la selección/deselección del elemento padre se usa para seleccionar/deseleccionar todos los elementos hijos de una vez.

En cualquier caso, no se trata de evitarlo sin más sino de reducir su uso sólo para las ocasiones en las que tenga de verdad sentido y a partir de ahora además podrás sketchearlo con la futura release de Balsamiq Mockups.

 

Si quieres saber más sobre el buen uso del Checkbox una buena referencia es la guía de Microsoft y el Nielsen’s Alertbox dedicado a este control.