Artículo 1.23. Introducción al diseño centrado en el usuario

Mari-Carmen Marcos

Mari-Carmen Marcos. 1.23. Introducción al diseño centrado en el usuario. En Cristòfol Rovira; Mari Carmen Marcos; Lluís Codina (dir.). Máster en Información Digital. Barcelona: UPF Barcelona School of Management.

Sumario

1. Conceptos relacionados con el Diseño Centrado en el Usuario

1.2. Interacción Persona-Ordenador (IPO, HCI), la disciplina paraguas que dio origen a todo esto

1.3. Usabilidad

1.4. Arquitectura de la información (AI)

1.5. Experiencia de usuario (UX)

2. El proceso del diseño centrado en el usuario (DCU)

2.1. Análisis de requisitos

2.2. Prototipado

2.3. Desarrollo

2.4. Publicación

2.5. Evaluación

3. Evaluación de interfaces desde el punto de vista del DCU

3.1. Técnicas de evaluación sin usuarios (evaluación por inspección). La evaluación heurística

3.1.1 Principios

3.1.2 Cómo realizar una evaluación heurística

3.1.3 Ventajas e inconvenientes de la evaluación heurística

3.2. Técnicas de evaluación con usuarios (evaluación por indagación). El test con usuarios

3.2.1 Planificación

3.2.2 Preparación de los materiales

3.2.3 El día del test

3.2.4 Análisis de los resultados

4. Bibliografía para comenzar a aprender

5. Propuesta para el debate

1. Conceptos relacionados con el Diseño Centrado en el Usuario

A lo largo del temario se van a tratar en profundidad conceptos, técnicas y herramientas del Diseño Centrado en el Usuario. Como introducción a esta unidad vamos a definir brevemente los conceptos básicos relativos a esta disciplina aunque algunos de estos conceptos ya hayan sido tratados y definidos en mayor profundidad en otras unidades didácticas. Por ejemplo, si ya ha estudiado la unidad 1.5 puede saltarse esta introducción. Los conceptos que vamos a recordar brevemente son: Human-Computer Interaction (HCI) o Interacción Persona-Ordenador (IPO), Arquitectura de la Información, Usabilidad y Experiencia de Usuario (UX).

1.2. Interacción Persona-Ordenador (IPO, HCI), la disciplina paraguas que dio origen a todo esto

Tal como se ha dicho en otras unidades didácticas, la Interacción Persona-Ordenador (IPO o HCI en inglés) es la disciplina que se ocupa de estudiar la manera en que las personas se comportan al utilizar sistemas tecnológicos. Su objetivo es adaptar los sistemas que hacen uso de las nuevas tecnologías a la forma que tienen las personas de utilizarlos. Aunque en su origen trataba sobre esta interacción con los ordenadores, hoy en día incorpora otras tecnologías como móviles, tablets, videojuegos, etc.

1.3. Usabilidad

La usabilidad es el concepto que más se escucha, un término que incluso podría decirse que se ha convertido en popular. La usabilidad viene definida por la norma ISO 9241-11 (Ergonomic requirements for office work with visual display terminals (VDTs) — Part 11: Guidance on usability ) como:

«The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use».

Ni los diccionarios de inglés ni los de español nos aclaran la diferencia entre «effectiveness» y «efficiency» o entre «efectividad», «eficiencia» y «eficacia», si bien por la práctica en la usabilidad podemos diferenciarlas con un matiz.

• Efectividad es la capacidad de lograr el efecto que se desea o se espera. Es decir, la capacidad de conseguir el objetivo marcado. Debería poder medirse en términos absolutos, “sí o “no”, pero según el caso admite matices.
• Eficiencia es la capacidad de lograr un objetivo con el mínimo gasto de recursos o con el menor esfuerzo posible.

1.4. Arquitectura de la información (AI)

La arquitectura de la información (AI) se ocupa entre otras cosas de «definir cuál va a ser el contenido del sitio, sus objetivos, herramientas, cómo se llamarán los botones y en qué posición éstos van a estar, cómo se va a relacionar el usuario con el sitio» (Velasco, http://mantruc.com/palabras/intro-ia/index.html). Algunos autores muy reconocidos en este campo han formalizado la definición de la disciplina, por ejemplo Wurman, o Rosenfeld y Morville.

1.5. Experiencia de usuario (UX)

Así como la usabilidad se preocupa de que las cosas funcionen bien, de forma intuitiva, con el menor esfuerzo cognitivo posible, la experiencia de usuario es un concepto más amplio que se focaliza en que el usuario disfrute, por lo tanto aporta más a la satisfacción, algo más subjetivo y que es complicado medir objetivamente.

2. El proceso del diseño centrado en el usuario (DCU)

Llamamos Diseño centrado en el usuario a aquellas prácticas del diseño de interfaces que tienen como eje central al target de ese producto. Normalmente se habla de DCU en un contexto de “pantallas”, concretamente de interfaces para ordenador, sobre todo cuando se trata del diseño de sitios web, y como tales, parten de la disciplina Interacción Persona-Ordenador. Entre sus criterios para lograr que realmente esas interfaces sean óptimas para su público, se tiene en cuenta la forma en que se trabaja la arquitectura de la información del sitio web y que se sigan las pautas que aseguran su usabilidad, y todo ello con el objetivo final de crear una buena experiencia en los usuarios.

El diseño centrado en el usuario (DCU) tiene un procedimiento de trabajo que como su nombre indica pone al usuario, receptor de la información, en un punto clave del diseño. Cuando se trabaja usando este planteamiento se pasa por cuatro etapas: análisis de los requisitos, prototipado, desarrollo y publicación, mientras que la evaluación está presente en cada una de las fases previas para asegurar que todo va a funcionar como está previsto (figura 1).

Figura 1. Proceso del diseño centrado en el usuario (DCU)

2.1. Análisis de requisitos

En la fase de análisis el diseñador estudia el contexto de trabajo: quién es el usuario al que se dirige el producto, en qué escenarios de uso debemos pensar, qué tareas deberá realizar el usuario, etc. En función de este análisis se deben plantear las funcionalidades del sistema.

2.2. Prototipado

La siguiente fase responde a la definición más concreta del diseño. En ella se estudia el modelo mental que los usuarios tienen del tipo de producto que se está diseñando. Es importante que el sistema responda a las expectativas de los usuarios, pues sólo así se evitarán frustraciones. Para lograr esta información es indispensable trabajar desde el principio con usuarios potenciales del sistema.

Dentro de esta etapa se construye una parte fundamental del diseño de sitios web: la arquitectura de contenidos. Consiste en definir el esquema en el que se distribuirán los contenidos en el sitio web, las jerarquías y las etiquetas que servirán para definir cada apartado. En esta etapa también se define el diseño de la interacción del sitio, de momento mediante prototipos no funcionales (wireframes), que una vez testados con los usuarios se trasladarán a un prototipo funcional.

Algunas de las técnicas que se utilizan en esta fase se podrán utilizar posteriormente para evaluar el sistema en su versión última antes de la distribución, así como en el seguimiento del producto para su mejora. Estas técnicas a las que nos referimos son el test de usabilidad (aplicado a los prototipos), el card-sorting (para conocer el modelo mental de los usuarios con respecto a la organización de la información y el vocabulario que utilizan) y la técnica de los personajes, que no recurre a usuarios reales sino imaginarios, pero que en parte la consideramos una técnica de evaluación con usuarios (similar a lo que sería el recorrido cognitivo).

2.3. Desarrollo

La tercera gran etapa es la de la construcción del sitio web, es la llamada etapa de producción. En esta fase entran los especialistas en lenguajes de marcado y en programación y los diseñadores gráficos. Un test de usabilidad en esta fase nos ayudará a determinar los aspectos que se pueden mejorar. Tras estas pruebas, y las correcciones que se deriven de ellas, el sistema estará listo para lanzarlo.

2.4. Publicación

La última etapa es la de distribución. En ella el producto está a disposición de los usuarios finales. Durante esta fase se deberán realizar algunos tests, análisis de logs, cuestionarios, etc. que sirvan como feedback y que permitan realizar las mejoras necesarias. En realidad no es una última etapa, pues el diseño centrado en el usuario es iterativo y si se aplica correctamente nunca se le pone punto final.

2.5. Evaluación

Se trata de una evaluación iterativa, que está presente en cada una de las etapas anteriores y que asegura que todo los pasos llevan a un buen diseño para los usuarios. Es un error pensar en la evaluación como la fase final de un producto porque en ese momento será mucho más difícil corregir los problemas que si se va realizando la evaluación a lo largo del proceso. En el apartado siguiente se trata con más detenimiento cómo evaluar interfaces.

3. Evaluación de interfaces desde el punto de vista del DCU

La evaluación es una fase necesaria en cualquier proceso. Permite comprobar si el resultado responde a los objetivos planteados. Por su propia naturaleza, la evaluación idealmente debe ser contemplada desde un inicio, cuando se planifica el producto o el proceso, y no dejarla para el final, ya que improvisar cómo evaluar dejará lagunas en los resultados.

Aplicada a usabilidad, es común clasificar la evaluación en dos grandes tipos: por inspección y por indagación. La primera, por inspección, se refiere a los métodos en los que una o varias personas expertas en usabilidad revisan el producto para detectar posibles problemas. La segunda, por indagación, incorpora técnicas de observación y los expertos en usabilidad observan a los usuarios realizando algunas tareas para detectar los problemas.

3.1. Técnicas de evaluación sin usuarios (evaluación por inspección). La evaluación heurística

La palabra “heurística” procede del griego (εὑρίσκειν) y literalmente significa hallar, inventar. Se aplica este término para referirse a técnicas de descubrimiento que lleven a la solución de un problema.

Como decíamos, una de las ramas donde se utilizan de forma más habitual estas técnicas es la de la evaluación de la usabilidad, donde es común para referirse a una forma de evaluación por inspección. Que sea por inspección significa que el evaluador, un experto en usabilidad, descubre problemas en un sistema o producto utilizando para ello una serie de herramientas: los principios heurísticos y concretamente los indicadores de calidad sobre el que se crean para poder detectar las carencias del producto.

En el campo de la usabilidad, los principios heurísticos describen propiedades de una interfaz y sirven de guía para detectar qué aspectos se cumplen y cuáles no.

3.1.1 Principios

Los principios heurísticos de la usabilidad están ampliamente reconocidos por la comunidad de Diseño Centrado en el Usuario. Posiblemente el primer autor, o al menos uno de los primeros, que recoge principios de evaluación heurística fue Ben Schneiderman (1986), si bien las bases tal y como las conocemos hoy en día las sentaron Molich y Nielsen (1990), y las popularizó Jacob Nielsen (1994) con el decálogo más conocido de la evaluación heurística:

http://www.useit.com/papers/heuristic/heuristic_list.html

http://www.nngroup.com/articles/ten-usability-heuristics/

Seguiremos las 10 reglas de Nielsen por ser las más extendidas en el ámbito profesional de la UX, y acompañaremos cada una de ejemplos que ayuden a concretar a qué se refieren.

Vamos a comenzar por una regla que numeraríamos como “cero” y que es previa a todas las demás ¿se puede acceder al sitio web? ¿se puede visualizar? No es en sí una heurística, pero sí una condición necesaria para poder aplicar todas las reglas que se presentarán a continuación… por lo tanto la incluimos como principio cero: ¿es posible acceder al sitio web? ¿ es posible verlo correctamente? ¿es accesible?

Una cláusula imprescindible y previa para poder plantear si un sistema es o no usable es que pueda ser usado. En el contexto de los sitios web, que sea usado implica que se pueda acceder a él. Se refiere a esto:

• Que se pueda abrir en ordenadores que usan diferentes sistemas operativos (distintas versiones de Windows, distintas versiones de sistemas operativos de Apple y de Linux).
• Que pueda abrirse desde cualquier navegador y en distintas versiones de ellos (Internet Explorer, Firefox, Safari, Chrome, Opera, etc.).
• Que se visualice correctamente en diferentes tamaños y tipos de monitores, así como en distintas resoluciones.
• Que se pueda ver en dispositivos distintos a los PCs: tablets, teléfonos móviles, etc.

En realidad, conseguir que el sitio web se visualice desde cualquier sistema operativo, navegador, resolución y dispositivo, depende de cómo se ha escrito el código fuente. La clave para hacerlo bien consiste en cumplir las recomendaciones del W3C.

Veamos cuáles son los 10 principios:

1. Visibility of system status. El sistema debe informar a los usuarios acerca de lo que está ocurriendo. Es habitual ver un mensaje del tipo “espere unos instantes, estamos buscando las mejores ofertas” que nos da ese tipo de feedback, o una barra de progresión que indica que un fichero se está descargando. A eso se refiere este principio.
2. Match between system and the real world. El sistema debe utilizar un lenguaje cercano al de los usuarios, con un vocabulario que el usuario entienda, y con iconos reconocibles. La idea es que el sistema no provoque frustración ni nos obligue a tener que aprender algo que no es necesario.
3. User control and freedom. Este principio indica que los usuarios deben poder deshacer y rehacer acciones realizadas. El sistema debe proveer al usuario de mecanismos de “escape” que les permitan cancelar la operación iniciada, retroceder o deshacer las acciones comenzadas.
4. Consistency and standards. Las personas seguimos ciertos patrones, unos aprendidos desde la niñez (ej. leemos de izquierda a derecha), otros aprendidos en el propio medio (ej. el logotipo está en la parte superior; al clicarlo se va a la página de inicio) y otros que aprendemos en la propia página web tras los primeros momentos navegando en ella (ej. los links son de color rojo; el menú está situado en la parte superior, debajo del banner).
5. Error prevention. Siendo claro en las explicaciones y ofreciendo la información necesaria se estará reduciendo el margen de confusión al usuario. Los casos más típicos de errores que podrían haberse previsto se dan en los formularios. Dos claves para que esto no ocurra: indicar qué campos son obligatorio y de qué manera deben ser rellenados.
6. Recognition rather than recall. Evitar al usuario tener que recordar dónde está cada opción, cada elemento, qué ha hecho hasta ese momento. Por ejemplo, en un proceso de compra en el que el usuario va añadiendo productos, debería estar siempre presente el carrito para que pueda ver qué ha ido comprando y cuánto va a costarle.
7. Flexibility and efficiency of use. Ya que los usuarios que pueden llegar a un sitio web pueden ser ya asiduos a la página, o bien ser su primera visitas, el sitio deberá estar preparado para ambos tipos de personas. Los aceleradores o atajos son útiles a los asiduos, por ejemplo les será cómodo poder usar la abreviatura “Bcn” para poner la ciudad de origen al comprar un vuelo, y el sistema le confirma que es “Barcelona, España”. En cambio alguien menos asiduo podría teclear “Barcelona” y que según escribe se le sugieran ciudades para autocompletar su palabra.
8. Aesthetic and minimalist design. Una página web sólo debe contener la información que realmente sea relevante o necesaria en cada momento. Cuando se ofrece al usuario una página cargada con mucha información, se reduce la visibilidad y es fácil desorientar al usuario. También debe cuidarse que haya un buen contraste de la letra con el fondo, un tamaño de letra legible, un ancho de columna cómodo, etc.
9. Help users recognize, diagnose, and recover from errors. En caso de que el sistema dé un mensaje de error, debe servir para explicar al usuario qué ha ocurrido y orientarle sobre cómo puede recuperarse de ese error.
10. Help and documentation. Si bien lo ideal es que el sitio web (o la aplicación) pueda ser usado sin ayuda, a veces es necesario proporcionar ciertas claves que ayuden, o al menos que den seguridad, al usuario.

A los principios de Nielsen se suman otros con algunas variaciones, como la propuesta de Tognazzini (2003) http://www.asktog.com/basics/firstPrinciples.html con estos principios:

1. Anticipation. Anticipación a las necesidades del usuario, mostrando al usuario toda la información y herramientas necesarias en cada momento.
2. Autonomy. Autonomía y control del usuario sobre el sitio web.
3. Color Blindness. Precaución en el uso del color . Transmitir información utilizando otros elementos complementarios al color para compensar la ceguera al color (daltonismo).
4. Consistency. Consistencia con las expectativas y aprendizaje previo de los usuarios.
5. Defaults. Uso de configuraciones y valores por defecto sólo en aquellos casos en qué tengan realmente sentido, permitiendo eliminarlas o cambiarlas con facilidad.
6. Efficiency of the User. Favorecer la eficiencia del usuario centrándose en su productividad.
7. Explorable Interfaces. Diseño de interfaces explorables que doten de libertad al usuario y que permitan reversibilidad sobre acciones realizadas.
8. Fitts’ Law. Ley de Fitts . Considerar que a menor distancia y mayor tamaño más facilidad del usuario para la interacción.
9. Human Interface Objects. Uso de estándares y objetos familiares en la interfaz.
10. Latency Reduction. Reducción del tiempo de latencia , optimizando el tiempo de espera de los usuarios.
11. Learnability. Minimizar el proceso y tiempo de aprendizaje necesario por parte del usuario.
12. Use of Metaphors. Uso adecuado de metáforas facilitando la comprensión del modelo conceptual presentado.
13. Protect Users’ Work. Protección del trabajo de los usuarios, asegurando que éstos no pierdan su trabajo como consecuencia de un error.
14. Readability. Favorecer la legibilidad mediante colores de texto contrastados y tamaños de fuente grandes.
15. Track State. Seguimiento del estado y de las acciones del usuario, permitiendo que éste realice operaciones frecuentes de manera más rápida.
16. Visible Navigation. Navegación visible, reduciéndola al máximo y presentándola de forma clara y natural.

Otros autores como Hassan-Montero y Martín-Fernández (2003) y Márquez-Correa (2003) concretan los principios heurísticos en indicadores más específicos que ayudan a aplicar este tipo de evaluación por evaluadores no expertos. Recomendamos su lectura para profundizar en el significado de los principios heurísticos.

3.1.2 Cómo realizar una evaluación heurística

Para realizar una evaluación heurística se debe contar con varios profesionales de UX familiarizados con la técnica. Nielsen recomienda que sean 3 personas (según sus cálculos, con 3 evaluadores se logran encontrar el 80% de los problemas de usabilidad). Cada evaluador debe realizar un entrenamiento previo para familiarizarse con la interfaz, para lo cual puede aplicar la técnica del “recorrido cognitivo” (cognitive walkthrough): revisa la web punto por punto, lo que le permite anotar las dificultades que tendría un usuario nuevo y medir la facilidad de aprendizaje (learnability).

A partir de ahí, cada evaluador va revisando de forma individual las distintas heurísticas para anotar problemas que encuentra en la web. En una tabla anota los problemas que observa, su frecuencia (si se dan constantemente o si son algo puntual) y la severidad (si impiden hacer la tarea serán graves, si molestan pero permiten continuar serán leves). Conviene guardar capturas de pantalla de los errores encontrados para después ilustrar el informe.

Para medir cada indicador, Nielsen propone una escala de 0 a 5 http://www.useit.com/papers/heuristic/severityrating.html

Una forma sencilla de puntuar consiste en usar una escala de 0-1-2 para la frecuencia y 1-2-3 para el impacto, de manera que se multiplica frecuencia por impacto y queda una puntuación de 0 a 6 para cada indicador.

Hecho este trabajo individual, los evaluadores ponen en común sus observaciones y llegan a un consenso. Juntos preparan un informe que recoge los problemas y las posibles soluciones.

3.1.3 Ventajas e inconvenientes de la evaluación heurística

Ahora que ya sabemos en qué consiste exactamente una evaluación heurística, podemos determinar cuándo aplicarla teniendo en cuenta que la técnica, como todas las técnicas, tiene una serie de ventajas y al mismo tiempo algunos inconvenientes. Entre las ventajas o puntos fuertes podemos destacar principalmente dos:

1. Es una técnica económica en tiempo y en dinero porque no trabaja con usuarios, con todo lo que conlleva: ni reclutar la muestra de usuarios ni preparar el protocolo de testeo, ni por tanto invertir el tiempo de testear con personas.
2. Es una técnica que puede aplicarse desde fases muy tempranas del desarrollo del producto, incluso con simples prototipos, de manera que se detectan los errores de usabilidad en un momento en que es mucho más fácil un rediseño.

Como inconvenientes o puntos débiles, al menos para tener en cuenta, se encuentran estos dos:

1. La aplicación correcta de una evaluación heurística requiere que los evaluadores tengan familiaridad con los principios heurísticos; de lo contrario pueden interpretarlos mal, detectar errores que no lo son o sobre todo no detectar los que hay.
2. Con esta técnica se identifican los problemas de la interfaz pero no los derivados de las expectativas del usuario o del contexto de uso, que si bien no necesariamente son problemas de usabilidad, si empobrecen la experiencia que tiene el usuario frente a producto que usa.

¿Qué más podemos hacer para evaluar un sitio web? Además de una evaluación heurística, que es una excelente forma de comenzar una evaluación, es importante complementar con otros métodos de evaluación que involucren a los usuarios.

3.2. Técnicas de evaluación con usuarios (evaluación por indagación). El test con usuarios

En un test de usuarios (user testing), los usuarios realizan una serie de tareas y el evaluador observa y anota lo que va ocurriendo. El test de usuario suele incluir cuestionarios y entrevistas. A los tests de usuarios se les pueden incorporar algunas formas de medición de aspectos biológicos, por ejemplo el seguimiento de la mirada (eye tracking), o los dispositivos EEG (Electroencephalography) para medir el esfuerzo cognitivo. En los últimos años se está aplicando la técnica de forma remota, de forma que los usuarios realizan los tests desde su propio ordenador en su casa, y un sistema graba la sesión para que después los evaluadores la revisen.

Como es una técnica un tanto compleja y que requiere una planificación detallada y una ejecución muy cuidada, vamos a explicar paso por paso todo lo que hay que tener en cuenta para plantear y llevar a cabo correctamente un test de usabilidad con usuarios.

3.2.1 Planificación

El planteamiento del test deberá quedar redactado con gran detalle en un informe para que todos los miembros del equipo lo tengan a mano en caso de dudas. Contendrá estos puntos que a continuación se explican con detenimiento.

1) Recabar información de usuarios. Es recomendable que antes de lanzarnos a hacer un test con usuarios se recabe información de forma rápida y automatizada, por ejemplo con un cuestionario breve online que podemos poner en Facebook, Google Docs, 5secondtest, etc. También se pueden hacer entrevistas a un grupo reducido de personas que nos resulten cercanas, para tener una primera impresión de los usuarios antes de continuar preparando el test. Con este feedback se podrán afinar los indicios y plantear un test más enfocado.

2) Escoger las técnicas de observación y seguimiento que se usarán en el test. Pueden ser desde simplemente observacionales hasta incorporar tecnología de seguimiento como mouse tracking y eye tracking. Si se requiere comparar dos interfaces para determinar cuál es más conveniente, será necesario plantear las métricas que se usarán para medirlo, y decidir si todos los participantes realizarán todas las tareas en todas las interfaces que se testean (lo que se llama un diseño experimental de tipo within-subjects), o si se dividirán para que unos hagan las tareas en una interfaz y otros en otra (diseño de tipo between-subjects). En la unidad dedicada a “Métricas de UX” se profundizará en estos dos tipos de diseño experimental.

3) Determinar el lugar de testeo. Se puede realizar el test en el entorno natural del usuario, por ejemplo en su oficina o en su casa, o bien en un laboratorio de UX más o menos equipado con dispositivos de grabación, o también se puede hacer un test en remoto utilizando tecnología que nos permita visualizar las acciones del usuario mientras las hace o posteriormente, si quedan grabadas en un servidor. Las opciones de compartir pantalla de programas como Skype facilitan este tipo de tests, si bien hay software específico para tests de usuarios en remoto, como Loop11 (con una versión reducida gratis) o UserZoom (de pago).

4) Asignación de roles y responsabilidades. Dentro del equipo de UX, una persona se ocupará de ser el moderador o conductor del test, acompañando al usuario durante las pruebas, mientras que otra u otras personas del equipo asumirán el rol de observador y anotarán las acciones del usuario y sus comentarios. Si sólo hay una persona en el equipo para realizar el test, grabar la sesión es lo más conveniente para poder repasarla y anotar lo que va ocurriendo. La mejor forma de anotar es disponer de una plantilla con espacios marcados para escribir en ellos lo que se quería observar, así se ahorra tiempo y en caso de que haya varias personas anotando a la vez, se asegura que siguen el mismo criterio.

5) Tareas. Las tareas son las acciones que se pide a los usuarios que realicen durante el test, por ejemplo “entra en la web de xxx y suscríbete al servicio de xxx”, o “compra un billete de tren para ir de xxx a xxx el día xx”. Se deben tener en cuenta varios aspectos:

• Cómo redactar las tareas. Es habitual que el usuario tienda a buscar la forma de realizar las tareas usando las palabras exactas de la redacción. Si pedimos al usuario que busque información de “créditos para compra de vivienda” es posible que se centre en esas palabras y no encuentre la información que hay sobre “hipotecas”. Las tareas deben estar inmersas en un “escenario”, es decir, un contexto que ayude a entender qué se le pide que haga, ya que en una situación real las personas hacemos acciones online con alguna finalidad, por ejemplo no compramos el billete de tren porque sí, lo hacemos porque queremos ir a algún lugar por algún motivo. Esta información debe dársele al usuario redactada de forma breve, que le ayude a entender pero que no le despiste. Una vez redactadas las tareas se puede comenzar a preparar el script (guión) que tendremos frente a nosotros durante las sesiones de testeo.
• Cuántas tareas proponer. Depende de distintos factores: la dificultad que entrañan, lo que se tarde en hacer cada una, si los usuarios van a ser remunerados o no, etc. No hay un número exacto de tareas, pero se recomienda que sea entre 3 y 5 tareas para que agotar al usuario. Un número menor no arroja suficientes datos, y un número mayor agota a los participantes y baja su rendimiento. También puede ocurrir que se tengan más tareas de las que un usuario vaya a realizar, de esa forma la muestra de tareas es mayor pero el número de usuarios que hace cada una desciende; puede interesar un diseño así si no la tarea en sí no influye y se quiere tener una muestra mayor de opciones.
• Cómo escoger las tareas. Las tareas serán aquellas que hayamos detectado que son importantes para los objetivos marcados para el test, y en las que las interfaces implicadas presenten potenciales problemas que ya se han intuido a través de encuestas, entrevistas, analítica web, et.. Entre las tareas es posible preparar algunas que consistan en hacer algo en productos de la competencia (benchmark) para saber cómo responden los usuarios a las interfaces de otros productos similares.
• En qué orden presentar las tareas. En caso de que una tarea requiera hacer otra previamente, el orden no podrá cambiarse. Si en cambio el orden no afecta, es preferible la aleatoriedad para evitar sesgos producidos por el cansancio (que afecta a las últimas tareas) o los nervios (que afectan a las primeras tareas). Igualmente se aconseja comenzar el test con una “tarea cero”, que es una tarea fácil que ayuda al usuario a introducirse en el test y tomar confianza.

6) Duración. La duración del test no debería superar una hora, incluyendo la presentación, las tareas, la entrevista y los cuestionarios. Las tareas en sí deberían poder ser hechas en máximo 30 minutos. Más tiempo resulta agotador y los usuarios no estarán tan atentos a las tareas. No debemos olvidar que están realizando tareas que no les interesan especialmente, pues se las hemos proporcionado nosotros, con lo cual su empeño no es tan alto como lo será cuando realicen tareas que les son de utilidad.

7) Datos para recoger. De toda la información que genera la interacción de una persona con una interfaz, hay unos datos de tipo cualitativo y otros de tipo cuantitativo. Los cualitativos nos ayudan a entender por qué los usuarios tienen cierto comportamiento, y los cuantitativos nos permitirán obtener métricas que serán de utilidad para medir el rendimiento (eficacia y eficiencia) y comparar con otras tareas, entre usuarios, entre dos interfaces, o una interfaz a lo largo del tiempo. En función de los objetivos del test, se recogerán y analizarán unos datos u otros, y en el caso de recoger datos cuantitativos se deberán tratar posteriormente con tests estadísticos apropiados (para más información, ver las unidades sobre Métricas de UX y Estadística para UX).

8) Selección de la muestra de participantes

• Cantidad. El número de participantes recomendado por Jakob Nielsen es de 4 o 5 personas (siempre y cuando tengan el mismo perfil, sean de un mismo target), porque con ese número ya se detectan un 80% de los problemas de usabilidad. Se ha cuestionado el número “mágico” de Nielsen alegando cuestiones puramente estadísticas; son especialmente relevantes los resultados de Sauro y Lewis (2012), que indican cómo calcular el número necesario de usuarios en base a dos datos. La tabla que mostramos a continuación pone algunos ejemplos de cuántos usuarios serían necesarios:

Tabla 1. Tamaño de muestra requerido en función del grado de descubrimiento de los problemas que se haya determinado

• Forma de reclutamiento. Es común que se haga a través de un anuncio, bien puesto por el propio equipo de UX, bien por una empresa de reclutamiento que puede contratarse. Este anuncio no puede revelar el objetivo ni decir para qué empresa se hará el test, sólo puede indicar la zona del lugar donde se hará y las fechas, el incentivo que se paga, y los datos que tiene que enviarnos toda aquella persona interesada.
• Screener. Se trata de un cuestionario breve para descartar/aceptar a las personas que voluntariamente hayan indicado que quieren participar en el test. Se suele hacer online. Si por ejemplo necesitamos a 4 personas menores de 20 años y a 4 mayores de 60 años, y tenemos más interesados de los que hacen falta, podemos determinar algún criterio para filtrar de entre las que han llegado.
• Gestión de no-show. Esto se refiere a qué pasa si alguna de las personas citadas al test no viene. Estaríamos perdiendo un tiempo para poder testear a otras. Unas empresas optan por tener a un usuario de reserva por si ocurre esto, y le pagan por las horas de espera que hace. Otras cuentan con usuarios cercanos (conocidos, familiares, compañeros) que pueden “tapar” ese agujero de tiempo en caso de que un usuario externo falle.

9) Calendario de tests. Cuando ya se tiene un panel de usuarios preparado hay que repartir las citas en los días de testeo. Es recomendable poner a los perfiles más complicados los primeros días, por si falla alguno tener tiempo para conseguir a alguien de ese perfil. En lo posible conviene evitar las citas los lunes por la mañana, ya que es el día que más personas olvidan su cita.

10) Incentivo. Cuánto pagar a los usuarios es un asunto que cada empresa o institución decide. Si es un perfil escaso se suele pagar más, lo mismo si las tareas son largas y difíciles. El pago puede hacerse en efectivo o con una tarjeta-regalo, o bien puede ser un regalo material (una camiseta, un pen-drive, una entrada para un evento, etc.).

3.2.2 Preparación de los materiales

Una vez que se ha terminado de planificar qué se va a testear, para qué y cómo, llega el momento de concretar todo lo anterior y preparar el test en sí. Habrá que tener en cuenta todo lo que se comenta a continuación. Según se vaya avanzando en la preparación del test se completará el script para que no quede nada en el aire.

• Revisión de software/hardware. No podemos arriesgarnos a que algo falle en el último momento, así que habrá que revisar que todo el equipo que se usará está funcionando en perfectas condiciones. Si se va a grabar con una webcam, se probará la webcam, si se va a seguir el ratón, se probará el software de mouse tracker. En ocasiones los software de observación, de grabación y de seguimiento requieren un determinado sistema operativo o navegador, por eso es importante probarlos bien antes de que lleguen los usuarios.

• Listado de usuarios con citas. Por banal que parezca, tener controlada la lista de usuarios, sus datos y los días y horas a los que se les cita es de gran importancia. Los usuarios pueden olvidar la cita, enviémosles un recordatorio por email el día anterior. Y el mismo día, un mensaje por SMS o whatsapp al móvil no está de más. Además, en caso de que la empresa cuente con una recepción, habrá que informar a las personas de la entrada para que les guíen hasta el laboratorio.

• Cuestionarios. Habitualmente se preparan 3 cuestionarios:
  • Previo, con preguntas sobre el perfil del usuario (edad, género, profesión, tipo de móvil que usa, tipo de ordenador que usa, tiempo de conexión a internet al día, etc.); si se hizo un screener para seleccionar la muestra, algunos de estos datos ya los tendremos y no necesitamos pedirlos de nuevo.
  • Post-tarea: se le pasa a continuación de cada tarea.
  • Final, para valorar la satisfacción. El más conocido es el cuestionario SUS (ver una explicación más amplia sobre este cuestionario en esta misma unidad más adelante).

• Entrevista final. Antes de que el usuario se vaya le haremos una entrevista para que nos diga su percepción sobre el sistema. Conviene tener una plantilla para hacerle preguntas y anotar sus respuestas, así llevamos la entrevista hacia lo que nos interesa.

• Tarjetas con las tareas. Es más cómodo para los usuarios si tienen las tareas escritas y en un formato cómodo. La tarjeta les permite tener a mano las tareas.

• Formularios de consentimiento. Como trabajamos con personas, es necesario que éstas firmen un consentimiento donde indican que realizan este test libremente y habiendo sido informadas de en qué consiste. Si se graba en vídeo debe indicarse qué uso se hará de él, y si se trabaja con menores deben firmarlo también sus padres o adultos a cargo de ellos.

• “Recibí”. Cuando el usuario recibe un incentivo debe confirmar que le ha sido entregado.

• Formulario de anotación para el observador. Prepararemos las hojas donde se anotarán las observaciones: tiempo que se tarda en hacer la tarea, si acaba o no, comentarios que hace, etc. Es mucho mejor tener estas plantillas que anotar de forma libre, pues con ellas se logra mayor coherencia en lo que se apunta y nos centremos en el objetivo.

• Check-list de todo lo que tiene que haber en la sala, para que no se nos olvide nada: bolígrafos, papel, agua, tarjetas de tareas, hojas de observación, script, etc.

• Preparación del laboratorio o de otro entorno donde se realice el test: iluminación, tipo de silla, enchufes, wifi, etc.

• Testeo del test. Antes de citar a los usuarios se debe hacer un recorrido completo por las tareas para asegurarse de que todo es coherente. A continuación se debe hacer una prueba piloto con un usuario cercano (un compañero puede servirnos), y finalmente una prueba piloto con un test real citando a un usuario real. Este piloto real nos permitirá detectar aspectos que se nos habían escapado, y mejoraremos el test antes de que vengan los demás usuarios.

3.2.3 El día del test

Llegados a este punto, comienza el test finalmente. Estos son los pasos que se realizan con cada uno de los usuarios citados que llegan al laboratorio:

• Recibimiento del usuario
  • Comenzamos con un saludo, presentándonos y presentando el test que haremos con una explicación breve y que no desvele los objetivos porque si los conoce, el usuario podría dejar de comportarse de forma natural. Es necesario e importante aclararle al usuario para qué está ahí, en qué va a colaborar y dejarle bien claro que se está evaluando una web y no a él, porque tienden a sentir que se les hace un examen o se les pone a prueba.
  • Firma del consentimiento informado.
  • Recordar que hay que apagar los móviles.
• Cuestionario inicial
• Realización del test
  • Pedirle que vaya comentando en voz alta lo que hace, como si pensara hablando (think aloud).
  • El moderador interviene sólo para guiar cuando haya que cambiar de tarea y para realizar el cuestionario post-tarea.
  • El observador está en la misma sala o bien en otra mirando tras el cristal (en salas de cristal-espejo se puede hacer).
• Encuesta final. Puede ser con preguntas abiertas y/o cerradas. Suele incluir un SUS
• Entrevista final

Ejemplos de distintos laboratorios en el momento en que los usuarios están realizando los tests. En todos los casos se ve cómo el moderador les acompaña.

3.2.4 Análisis de los resultados

Una vez terminadas las sesiones de testeo con los usuarios, llega el momento de obtener resultados. Para ello seguiremos estos pasos:

• Recoger inputs de todo el equipo. Ordenarlos por temas y por importancia
• Organizar los datos cuantitativos para aplicar fórmulas estadísticas: tiempo empleado para realizar cada tarea, número de errores cometidos, número de usuarios que han realizado correctamente una tarea etc. (ver la unidad sobre Estadística para UX)
• Analizar las respuestas de los cuestionarios
• Analizar los comentarios hechos por los usuario durante el test y durante la entrevista
• Triangulación de los datos: los cualitativos y los cuantitativos deben apuntar en la misma dirección. Usar varios métodos da rigurosidad a los resultados
• Ordenar resultados por alcance (de los problemas que se dan de forma puntual en algunos usuarios a los que ocurren de forma repetitiva) y severidad (de los más leves, que no afectan a la realización de las tareas, a los más graves, que impiden acabar las tareas). Crear una lista de problemas poniendo como prioritarios para resolver aquellos más graves que se dan de forma más repetitiva.

4. Bibliografía para comenzar a aprender

Desde la lectura de bibliografía especializada (libros y revistas) a blogs nada despreciables, el material para profundizar es amplio si se busca en inglés, y no tanto si buscamos textos en español. Algunas editoriales están traduciendo los libros más destacados de Jakob Nielsen, Donald Norman, Steve Krug, Lou Rosenfeld y Peter Morville, Alan Cooper, entre otros. Y poco a poco podemos encontrar libros en español, como el de Toni Granollers, Jesús Lorés y José Juan Cañas sobre diseño de sistemas interactivos, el de Adrián Coutín sobre arquitectura de la información, el libro digital publicado por AIPO o el de quien escribe ahora (Mari-Carmen Marcos) sobre IPO en sistemas de recuperación de información.

Además, las revistas de biblioteconomía y documentación publican puntualmente artículos sobre usabilidad, arquitectura de la información e interacción persona-ordenador. El profesional de la información, Item, BiD y la Revista española de documentación científica son ejemplos de revistas que en los últimos años han incorporado este tema.

Algunas lecturas que recomendamos para adentrarse en este tema son:

• Coutín Domínguez, Adrián. (2002). Arquitectura de información para sitios web . Madrid: Anaya Multimedia, 2002.
• Garret, Jessi James. (2003). The elements of user experience: user-centered design for the web . Indianapolis: New Riders Press.
• Granollers, Toni; Lorés, Jesús; Cañas, José Juan. (2005). Diseño de sistemas interactivos centrados en el usuario . Barcelona: UOC.
• Lorés, Jesús (ed.). Introducción a la interacción persona-ordenador.http://griho.udl.es/ipo/ipo/libroe.html
• Marcos, Mari-Carmen. (2004). Interfaces de recuperación de información: conceptos, metáforas y visualización . Gijón: Trea.
• Nielsen, Jacob. (1999). Designing Web Usability: The Practice of Simplicity. Indianapolis : New Riders Publishing.
• Norman, Donald. (2005) El diseño emocional: Por qué nos gustan (o no) los objetos cotidianos . Barcelona: Paidós.
• Rosenfeld, Lou; Morville, Peter. (2006). Information Architecture for the Wolrd Wide Web . 3ª ed. O’Reilli.

5. Propuesta para el debate

¿Le gustaría conocer el mercado laboral para consultores de usabilidad y UX? Hay lo siguiente:

• Revisar diversas ofertas de empleo relacionadas con usabilidad. Hacer la búsqueda en portales como Infojobs y UXplora
• Hacer una lista de las funciones que mencionan que realizará la persona contratada, no importa que estén repetidas (es mejor que lo estén)
• Crear una lista de palabras final de manera que se eviten los sinónimos (por ejemplo si tenemos prototipar y hacer prototipos, escoger una de las dos formas y usarla cada vez que tengamos ese concepto). Es posible que tengamos 10 veces “prototipar” y 5 veces “evaluar” en la lista creada
• Generar una nube de tags con Wordle (o similar) que contenga al menos 18 palabras, preferiblemente en un solo idioma, pero puede haber términos que se entienden mejor en inglés y no se traducen, ej. UX

Plantilla para la valoración de las intervenciones en el debate:

• ¿Las palabras de la nube de tags están directamente relacionadas con la usabilidad y el UX?
• ¿Hay al menos 18 palabras en la nube de tags?
• ¿Piensas que el resultado es lógico y que las palabras más grandes son también las que previsiblemente tienes que ser las más frecuentes en este tipo de demandas de empleo?
• Valorar la intervención con el desplegable del foro entre una y cinco estrellas (de menor a mayor calidad).

© Texto: autor/es del documento

© Presente edición: Máster en Información Digital. UPF Barcelona School of Management

Este obra está bajo una licencia Creative Commons

Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported