Categoría: Investigación de diseño

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, 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.

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:

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.

Actualización: Originalmente este artículo estaba publicado sin ánimo de lucro en otro sitio; pero parece que lo han sustituido por una especie de publirreportaje, por lo que lo republico aquí en su integridad.

Oficina nueva. Paredes aún sin pintar. Sala de reuniones improvisada y cuatro personas ilusionadas sentadas alrededor de una mesa de camping. Pues sí, una start-up. A la primera de cambio se menciona “El Usuario” en la reunión. ¿Pulsará aquí o allá? ¿Irá por este camino o aquél otro? Cada uno dice la suya. Uno recuerda ciertas leyendas antiguas sobre este extraño ser. Otra saca a relucir los datos que le facilitó un amigo que lo vio un día entre la niebla. El tercero pone encima la mesa sus prejuicios y experiencias personales. Y el cuarto se inventa algo para no quedar en silencio. La reunión se alarga, discutiendo amargamente sin llegar a ninguna conclusión, y finalmente el tiempo se agota y la decisión final se acaba delegando al viento, sentenciándola con esa lapidaria expresión… “le damos una pensada”.

Esto, aunque nos pese, es la viva imagen de muchas start-ups digitales.

Hace años era peor. Hace años la gente no creía en los usuarios. Parecía como si nadie hubiera visto ninguno. Uno hablaba, por ejemplo, del por qué el sitio web no vendía, pero en ningún momento se tenía en mente a ese señor en su casa manejando a duras penas el ratón. Con el tiempo la cosa cambió: las empresas fueron evangelizadas y empezaron a venerar a este ser misterioso, el dador de dinero, mencionándolo continuamente en cualquier conversación.

Pero a veces la fe no es suficiente: hay quien imagina “El Usuario” como un extraño monstruo de tres cabezas, que vive en el fondo del mar y sale los días de luna llena a visitar sitios web y descargar aplicaciones para móviles. Si fuera así entonces sería comprensible tener estas discusiones a puerta cerrada; como en una obra cualquiera de fantasía donde el consejo del pueblo discute sobre la posible llegada de un dragón. ¿Qué doncella ofreceremos para saciar al dragón este año? ¿Ésta o aquella? Mejor le damos una pensada.

La realidad es otra: “El Usuario” no vive escondido bajo el mar. No sale sólo las noches de luna llena. No muerde, ni contagia la rabia. Realmente “El Usuario” viaja en el mismo autobús que nosotros. Se toma el café en nuestro bar de confianza. Y quizá incluso trabaja en la oficina de enfrente. Entonces ¿por qué no le hacemos una visita?

Esto nos va a permitir comprender sus deseos, necesidades y limitaciones, requisito indispensable para alcanzar nuestros objetivos de negocio. Hablar con ella o él y observar mientras utiliza nuestro producto (o el de la competencia) nos puede ayudar a detectar problemas en fases tempranas de definición, solucionándolos cuando aún es económico hacerlo, así como determinar funcionalidades o ideas que pueden no tener sentido en el producto final, ahorrándonos también los costes asociados a su desarrollo.

Es buen momento para recordar que si algo no ha cambiado en muchos años en el mundo del software es que el 80% del mantenimiento de un producto corresponde a requisitos de usuario no satisfechos o no previstos (Martin & McClure, 1993). No es tontería: esto repercute en más de un 60% del coste total del proyecto (Roger Pressman, 1992).

Pero no es sólo una cuestión de costes, conocer a los usuarios y sus tareas va a contribuir a:

• Mejorar el aprendizaje del producto
• Definir procesos más rápidos y eficientes
• Reducir la probabilidad que se comentan errores en la interacción
• Mejorar la satisfacción subjetiva
• Y conseguir productos más atractivos y que transmitan mayor confianza

Todo esto, a veces, muy pocas veces, se puede conseguir a puerta cerrada, pero la única forma de asegurarnos que vamos por el buen camino y evitar discusiones sobre el sexo de los ángeles es usar alguna de las múltiples técnicas que existen para recabar información sobre los usuarios: encuestas, cuestionarios, entrevistas, grupos de discusión, tests de usabilidad con la competencia, análisis etnográficos y un largo etcétera; muchas de ellas perfectamente descritas y documentadas en libros como el muy recomendable y práctico “Understanding your Users” de Catherine Courage y Kathy Baxter.

Y un consejo final: tened siempre algún tipo de contador en vuestra sala de reuniones; si “El Usuario” es mencionado más de 10 veces en un minuto… id a visitarlo.