De la colina a la montaña

Hace unos años, cuando empecé a trabajar en consultoría de usabilidad, era difícil convencer al neófito de la utilidad de las evaluaciones empíricas, es decir, todas aquellas técnicas de testing basadas en la experimentación y la observación, como el test tradicional de usabilidad o el “moderno” test A/B.

Hoy en día, probablemente gracias a (o por culpa de) la popularización de enfoques lean y sus famosos MVP (mal entendidos), empezamos a observar lo contrario: algunos equipos de diseño han integrado tanto estas técnicas de evaluación que toman más protagonismo que la propia generación o construcción de soluciones. Son entornos donde se dedica muy poco esfuerzo a la investigación generativa (entrevistas con usuarios, etnografía, etc.) y se intenta sacar algo lo más rápido posible para luego optimizar mediante tests.

Este enfoque creo que tiene varios problemas, entre ellos el que describía Alan Cooper recientemente:

Yo lo veo así: observad el siguiente dibujo e imaginad que se trata de un espacio de soluciones a un problema, siendo la altura la representación de la calidad de cada alternativa (entendida como consideréis: eficiencia, conversión, utilidad, usabilidad, etc.)

Una representación tridimensional muestra dos picos parecidos a montañas, uno más bajo a la izquierda y otro más alto a la derecha.

 

 

 

 

 

Si nuestro objetivo es llegar a lo más alto, nos interesa subir a la “montaña” de la derecha (óptimo global de la cordillera); pero si escogemos un punto de partida mediocre en la zona izquierda y nos limitamos a ascender ciegamente mediante pequeñas mejoras dirigidas por tests, lo único que conseguimos es subir poco a poco una colina (nuestro óptimo local actual).

El salto de la colina a la montaña no procederá nunca de la evaluación empírica por si sola. Se requiere lo que en genética se llamaría una mutación, un salto más grande y peligroso, cuyo riesgo podemos reducir (¡sorpresa!) mediante la tan denostada y poco “científica” investigación generativa.

Desactivando minas con perritos

Tenéis ante vosotros un campo de minas que queréis cruzar.

Os acompañan varios perritos.

Descartando por el momento la opción de ir delante (que me fastidiaría la metáfora) parece que una solución es dejar corretear los cánidos libremente por el campo para que vayan, a su manera, desactivando las minas.

Fivi, un yorkshire
Fotografía utilizada con autorización expresa de su autor, licenciada originalmente bajo CC BY-NC-ND 2.0.

Sin embargo, si dejamos sueltos todos los perritos a la vez existe el riesgo obvio de que una mina explote volando a más de uno. Los perritos extra habrán sido sacrificados en vano.

Otra solución más “inteligente” es lanzar los perritos de uno en uno: un perrito, una mina.

Esta metáfora me ha servido en varios cursos para dos cosas: ganarme algunas miradas de odio e ilustrar gráficamente los enfoques de test de usabilidad iterativos basados en sesiones con pocos participantes y cambios rápidos.

Me explico: en un test de usabilidad evaluativo (el objetivo del cuál es detectar problemas) de nada sirve lanzar multitud de participantes contra una interfaz para que choquen una y otra vez con las mismas dificultades. Es un sacrificio de recursos, tiempo y participantes.

Existe un enfoque mejor: reducir el número de participantes, testear, hacer cambios y repetir. Estos cambios permiten retirar las dificultades detectadas (explosión controlada de las minas) para poder hacer una nueva ronda de testing y determinar nuevas oportunidades de mejora.

Es más barato y eficiente.

Si os interesa el enfoque leed el artículo “Using the RITE method to improve products; a definition and a case study” o el libro “Rocket Surgery Made Easy: The Do-it-yourself Guide to Finding and Fixing Usability Problems” de Steve Krug.

Ningún animal sufrió daños durante la preparación y redacción de esta entrada. Mucho menos Fivi, que la ilustra con candor.

 

Ver el vestido de otro color

Hace casi un mes que medio mundo se volvió loco con un vestido que algunos veían blanco y dorado (al parecer la mayoría) y otros azul y negro.

Se trata obviamente de un efecto óptico (con un impacto importante de elementos contextuales a la propia observación), pero con una peculiaridad que a mí me parece especialmente interesante: para mucha gente es imposible cambiar su forma de ver los colores del vestido.

Dejad que lleve este tema al terreno de la usabilidad.

A veces en un test de usabilidad un participante tiene dificultades continuamente. Al parecer no entiende nada, todo son barreras para él. Y tú, como investigador, debes intentar averiguar dónde está el problema.

En esas ocasiones los árboles no te dejan ver el bosque: mientras observas al participante prestas atención a literales, estructura, componentes visuales… pero ninguno de estos elementos por sí solo puede ser capaz de generar tanta confusión.

Donald Norman hace unos años nos contaba esto:

The design model is the conceptualization that the designer has in mind. The user’s model is what the user develops to explain the operation of the system. Ideally, the user’s model and the design model are equivalent. However the user and designer communicate only through the system itself: its physical appearance, its operation, the way it responds, and the manuals and instructions that accompany it. Thus the system image is critical: the designer must ensure that everything about the product is consistent with and exemplifies the operation of the proper conceptual model.

Un usuario al aterrizar en un sistema acostumbra a tener ya un modelo parcialmente construido de cómo va a funcionar que puede no coincidir con el del diseñador. En estos casos, si la interfaz no proyecta una imagen del sistema claramente contradictoria con su prejuicio, entrará en juego su sesgo de confirmación, que le ayudará a incorporar todo lo que vea a su modelo mental.

El usuario acaba operando la interfaz con un modelo totalmente distinto al de diseño. Y claro, no entiende nada.

Como facilitador de un test debes ser capaz de hacer tres cosas ante esta situación.

Primero debes conseguir darte cuenta de lo que está sucediendo. Comprender que el problema es profundo y nada superficial.

Segundo debes averiguar con qué modelo mental trabaja el participante. Entender cómo él cree que funciona el sistema. Para ello es prácticamente indispensable utilizar el protocolo think aloud.

Y finalmente está lo más complicado: debes cambiar tu modelo mental por el del usuario y observar con sus ojos la interfaz. Debes ver el vestido de otro color.

La señora

La señora, de unos 65 años, se nota que casi nunca ha utilizado un ratón. Lo desplaza lentamente y me pregunta a qué botón debe darle para pulsar. Mis prejuicios entran en juego y asumo que no es usuaria habitual de Internet. “Lo uso”, me dice, “pero en casa tengo un tablet”. Añade, sin que venga a cuento, “me encanta el Candy Crush”.

La señora quizás no es representativa de su perfil demográfico. Puede que se trate de un outlier, una observación atípica, un chiste del azar que quiere joder nuestra estadística; pero nos recuerda algo importante que usualmente olvidamos: usuario es “el que usa”, no “el que es”. En el fondo no nos importa el usuario en sí. Me refiero a si tiene 80 años o 20. Si es moreno o rubio. Si es de Barcelona o Madrid. No queremos saber quién es, sólo averiguar cómo se comporta, qué necesidades tiene y qué objetivos persigue.

Al finalizar la sesión de test, la señora me comenta que tiene un hijo que mide unos dos metros, como yo. Acto seguido me pregunta si juego a baloncesto.

La señora parte de una correlación entre características físicas y aficiones, pero no asume nada, no lo usa como atajo al conocimiento, pregunta y confirma para no caer en un mero estereotipo.

Problemas anecdóticos

Un test de usabilidad evaluativo es una técnica cualitativa con la que intentamos descubrir problemas observando participantes realizando tareas. Lo más habitual es que el facilitador de un test determine también la causa del problema en el momento en que es observado, por lo que la existencia del problema nunca se debería probar, o justificar, con la observación, sino con las causas que lo produjeron.

Pese a esto, es habitual preguntarse hasta qué punto la observación es relevante o puede acreditar la existencia del problema por sí sola, sin justificación causal. Así pues, ¿observar un participante teniendo un problema es significativo? Significativo, estadísticamente hablando, expresa que el resultado del test no se puede atribuir al azar o que, mejor dicho, la probabilidad de que sea atribuible al azar es muy pequeña.

Podemos preguntarnos lo mismo de otro modo: ¿qué probabilidad hay que el problema observado le pueda suceder a otra persona? Para un sitio web dirigido a una población de 10 o 20 millones de usuarios, por ejemplo, sería una gran casualidad que hubiéramos dado con la única persona que va a tener dificultades. Nuestra intuición, pues, nos dice que el problema le va a suceder a más gente, pero ¿a cuánta?

Pongamos que hacemos un test de un sitio web de comercio electrónico con únicamente 3 participantes y sólo uno de ellos tiene problemas para comprar. Con una muestra tan pequeña y con una sola observación, podríamos categorizar el problema de anecdótico y no atrevernos ni siquiera a exponerlo.

Vamos a suponer, arbitrariamente y con poco criterio, que para nosotros un problema anecdótico es aquél que afecta a menos de 1 de cada 1000 usuarios. ¿Qué probabilidad existe de que observemos un problema una única ocasión con tres participantes si en la realidad se da 1 de cada 1000 veces?

Una forma de calcular esto es utilizando probabilidad binomial, ya que cada participante es un “experimento” independiente en el que podemos observar, o no, el problema. La fórmula para calcular esta probabilidad es:

{P(k;n,p)=\binom{n}{k}p^k(1-p)^{n-k}}

donde k es el número de observaciones (una), n el número de experimentos (tres) y p la probabilidad del problema (0,001).

Calculando obtenemos que existe una probabilidad del 0,3% de obtener este resultado en el test. Dicho de otro modo: sólo obtendríamos este resultado (“1 observación en 3 participantes”) 3 de cada 1000 veces que hiciéramos el test. En el resto de casos obtendríamos otro número de observaciones para el problema (0, 2 o 3).

Visto esto, podemos afirmar que es “raro” que nos encontremos ante esta situación. ¿Existirá otra más probable? Quizás el problema es más habitual de lo que creemos. En nuestra muestra lo hemos observado 1 de cada 3 veces… ¿qué probabilidad hay que hayamos obtenido este resultado si la proporción de usuarios “real” afectados por el problema fuera la misma que la observada en nuestra muestra? Pues bastante. Si hacemos el cálculo el resultado es de un 44%.

Debemos tener claro que ambos casos son posibles: puede que la frecuencia del problema sea pequeña, de sólo un 0,1%, y que haya dado la casualidad que hayamos obtenido este resultado del test. O puede que la frecuencia sea mayor y que no hayamos tenido tanta casualidad al obtener este resultado. Sea como sea, con estos números podemos afirmar que es más probable que el problema detectado no sea anecdótico que no que lo sea.

Seguimos, eso sí, sin saber la probabilidad real del problema, pero podemos calcular una aproximación: una horquilla entre dos números donde, con gran seguridad, se encuentre la frecuencia que buscamos. Esto es lo que se llama intervalo de confianza y si lo calculamos usando el método de Clopper-Pearson obtenemos que es muy probable (un 95% de probabilidad) que la frecuencia del problema observado esté entre el 0,8% y el 90,5%. El intervalo es muy amplio, pero nos da gran seguridad de que no estamos ante algo anecdótico.

Si os interesa profundizar en cuestiones estadísticas y usabilidad os recomiendo leer a Jeff Sauro, quien en 2010 ya trató este mismo tema haciendo también un análisis de probabilidad binomial.