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.

Diseñando una navegación

Hace unas semanas participé en un proyecto de diseño de una intranet. Se tuvo que plantear, entre otras cosas, un sistema de navegación para moverse cómodamente entre varios elementos de un mismo nivel de la estructura de información. La particularidad era que el número de elementos variaba en función del usuario de la intranet que hubiera accedido.

¿Qué hacer en este escenario? ¿Qué debemos pedir al cliente?

Una aproximación totalmente absurda sería pensar sólo en el caso mejor: pediríamos al cliente cuál es el número mínimo de elementos (sólo uno, de hecho) y diseñaríamos ignorando el resto de casos. No creo que sea necesario justificar el porqué esto es una estupidez (aunque la realidad sea que uno a veces se encuentra diseños planteados así).

Otra opción que puede parecer más razonable es solicitar al cliente cuál es el caso peor, el número máximo de elementos que la navegación debe “aguantar”, y diseñar algo acorde a ello. En el proyecto que nos ocupa ese máximo era el medio millar. Esta alternativa es mejor que la anterior, pero sigue siendo una aproximación estúpida: el caso peor puede darse en muy pocas circunstancias y aunque debe ser considerado no podemos focalizar toda la interfaz a satisfacerlo ignorando el resto.

Una tercera opción es solicitar al cliente dos números: el caso peor y el promedio (media aritmética). Así podríamos intentar diseñar una interfaz focalizada en lo más habitual y hacer las variaciones necesarias para soportar el caso peor. El problema es que este argumento tiene un fallo importante: un promedio no necesariamente será un caso habitual. De hecho en el proyecto el promedio era de 5 elementos, pero esto sólo representaba un 2% del total de usuarios

La cuarta opción es mi recomendación: pedir toda la información que sea posible. Siempre. Queremos el detalle de cuántos elementos tendrá cada uno de los usuarios. ¿Y qué hacemos con todos estos datos? Pues para empezar representarlos visualmente:

Gráfico de barras de 1 a 500. El 1 es significativamente mayor que el resto.

La representación visual nos da una idea clara de la distribución de los usuarios por número de elementos. Vemos que lo más habitual, con diferencia, es tener un único elemento y que la larga cola es larga pero fina.

Esto nos puede llevar a plantear un diseño de una navegación con las siguientes variaciones:

  • Para la gran mayoría de casos (un 70% concretamente) no necesitamos navegación alguna. Simplemente debemos mostrar el elemento.
  • Para algunos otros casos (un 20%) podemos proporcionar una navegación sencilla de un máximo de 10 elementos.
  • Para el resto (un 10%) proporcionaremos una navegación especial, pero sin rompernos demasiado la cabeza: un sistema de búsqueda y los elementos consultados recientemente fue suficiente para el proyecto.

Para este análisis estamos suponiendo que todos los usuarios tienen la misma importancia. A veces puede no ser así.

BitLocker, FileVault y VeraCrypt

Cada vez es menos habitual transportar información en dispositivos físicos. Lo normal es compartirla por Internet, ya sea subiéndola a un servicio de hospedaje de archivos o bien mandándola directamente por correo electrónico. Pero hay veces que tenemos varias gigas de material y utilizar este tipo de servicios no es práctico, por lo que recurrimos a otros sistemas de almacenamiento de datos, como un disco externo, que deberemos transportar físicamente.

Incluso tomando las precauciones adecuadas puede suceder que nos olvidemos, perdamos o nos roben el dispositivo de almacenamiento. Probablemente a nadie le interese un pepino nada de nuestros proyectos, pero si el material es delicado no está de más poner algún tipo de barrera para que esta situación no se nos vaya de las manos.

La buena noticia es que los sistemas operativos más utilizados ya llevan mecanismos para hacer esta función: en el caso de Windows es BitLocker y en Mac es FileVault. Ambos permiten convertir nuestro disco, o parte de él, en un almacenamiento cifrado que al ser conectado a nuestro equipo desbloquearemos mediante una contraseña u otros métodos criptográficos. A partir de ese momento podremos utilizarlo de forma convencional, realizándose el cifrado y descifrado sobre la marcha.

El principal problema de estos sistemas es que son exclusivos de cada sistema operativo. BitLocker sólo funciona en Windows (integrado a partir de Windows 7 y con una aplicación llamada BitLocker To Go Reader disponible para Windows Vista y XP) y FileVault sólo en Mac.

Si no usáis el mismo sistema operativo que vuestro cliente podéis probar la alternativa libre VeraCrypt, un sucesor del más conocido TrueCrypt, actualmente abandonado, que está disponible para Windows, OSX y GNU/Linux. Aunque usar VeraCrypt tiene un inconveniente importante: tendréis que ser administradores del equipo de vuestro cliente para poder instalarlo (o para simplemente ejecutarlo si lo lleváis en vuestro disco), lo que en muchos casos como supondréis no es algo viable.

Si no sabéis qué equipo tendrá vuestro cliente y queréis la tranquilidad de llevar los datos cifrados, mi consejo es utilizar un disco con tres particiones: una cifrada con BitLocker, otra con FileVault y otra sin cifrar por si las moscas (donde podéis incluir VeraCrypt u otra aplicación de cifrado de archivos).

Todos estos sistemas, especialmente FileVault y BitLocker (que son privativos, de código cerrado), son susceptibles de tener agujeros de seguridad, pero siempre serán un buen disuasivo para aquél que encuentre un disco al lado de la taza del café que nos acabamos de tomar.