Metodologías de UX: Walkthrough o Recorrido Cognitivo

Te explicamos qué es un Walkthrough o Recorrido Cognitivo, cuándo usarlo y más. También te enseñamos a hacerlo por tu cuenta: desde la dinámica de preparación hasta su ejecución y análisis.

Tomàs Modroño

Published in

Blog de Interactius UX

10 min readMar 14, 2017

¿Qué és un Walkthrough?

Un Walkthrough o Cognitive Walkthrough (Recorrido Cognitivo) es un método de inspección de la usabilidad de un sistema interactivo que se centra en evaluar la facilidad de aprendizaje de un diseño.

Su objetivo es ver cómo piensa y se comporta un usuario cuando utiliza por primera vez una interfaz. Está constatado que si se da a elegir a los usuarios, estos prefieren aprender a base de la exploración y la observación, más que leer un manual o seguir unas instrucciones.

Esta técnica, se testea sobre un prototipo inicial de baja fidelidad de una aplicación y la suelen llevar a cabo evaluadores expertos. Los cuales se encargan de hacer un recorrido (‘walk’) a través de una serie de tareas típicas que soporta el sistema.

La principal ventaja del recorrido cognitivo es la habilidad de generar resultados muy rápidamente y a un coste muy bajo, especialmente si se compara con otra técnicas de testeo de la usabilidad, como la ‘Evaluación heurística’.

¿Cuándo se debe usar?

Los Walkthroughs se acostumbran a usar en fases tempranas de un proyecto de implementación de un sistema interactivo. Y suelen realizarse durante la fase de definición y diseño para obtener insights rápidos antes de invertir recursos en la fase de desarrollo.

Evidentemente, se podrían realizar Recorridos Cognitivos en fases posteriores al desarrollo, pero entonces se estaría desaprovechando el potencial que brindan otras técnicas más efectivas, como los tests con usuarios sobre el propio sistema digital ya desarrollado.

Ventajas y desventajas

Ventajas

Se trata de una técnica muy barata y asequible ya que, al llevarse a cabo con prototipos de papel de baja fidelidad, se necesitan pocos recursos.
La preparación y ejecución del test es muy rápida.
En los Walkthroughs grupales, como las personas evaluadas trabajan individualmente y en silencio, se obtiene feedback de muchos usuarios a la vez.

Desventajas

Las interacciones o animaciones no se pueden simular sobre papel.
Por ejemplo, no se pueden captar:
Acciones del cursor encima de elementos como botones o formularios (hover, click o focus).
Movimientos de elementos como acordeones, pestañas, menús y desplegables.
Cualquier vídeo, animación o movimiento de elementos que sean importantes para captar la atención.
Todo esto, hace que el usuario no pueda tener una interacción 100% real con la aplicación y, por lo tanto, se sienta limitado.
De todas formas, se pueden mejorar estos detalles usando recortes de elementos concretos, que superponiéndose a las hojas del prototipo principal, ofrecen ‘mini-simulaciones’ de cambios de estado. (Ver “Vídeo de Ejemplo 02” de la sección de ‘Ejemplos’.)
Al prohibir al evaluador pasar página para explorar qué pantallas o acciones siguen, éste se puede sentir restringido, afectando así en su proceso de aprendizaje de la herramienta.

Tipos de Walkthrough

El Cognitive Walkthrough fué inicialmente desarrollado a principios de los 90 por Wharton, C., Rieman, J., Lewis, C., and Polson, P. Años más tarde, se popularizó al aparecer en un capítulo del libro ‘Usability Inspection Methods’ de Jakob Nielsen. El estudio, que más adelante ampliaremos, consistía en preguntar una serie de cuatro preguntas para cada paso de las tareas a evaluar. Pero en el año 2000, Spencer, R., redujo las preguntas a dos para hacer el método más efectivo dentro de un contexto real de desarrollo de software.

Con este pequeño apunte histórico se quiere remarcar que, desde la implantación de esta técnica hasta ahora, han aparecido diferentes variantes y maneras de ejecutarla.

Las variables que marcan los distintos tipos de Walkthough son: quién evalúa las tareas y qué metodología se usa.

A continuación, se hace una pequeña clasificación según estos factores:

Quién evalúa:

1. Walkthrough con expertos
Según los postulados de la técnica original, el Recorrido Cognitivo consiste en analizar una aplicación mediante la inspección de varios evaluadores expertos. Mediante los conocimientos y principios, como por ejemplo los Principios heurísticos de Nielsen utilizados en las Evaluaciones heurísticas, se aporta el grado de neutralidad y concreción que un usuario no podría aportar.

2. Walkthrough con usuarios
Esta variante recoge los principios del recorrido cognitivo tradicional, sumándole las mejoras de involucrar usuarios reales:

Ayudar a corroborar o a completar dudas y errores que puedan surgir en una evaluación de expertos. Dado que, a menudo, el evaluador no es capaz de detectar los errores correctamente debido a su inexperiencia y desconocimiento de la herramienta.
Fomentar el diseño participativo y la formación de equipos multidisciplinares tan importantes en la disciplina de la Interacción Persona-Ordenador.

El mayor inconveniente de involucrar usuarios es el tiempo que se invierte en reclutarlos y estar por ellos. No obstante, vistos los resultados en sesiones reales, es una inversión que vale la pena hacer.

3. Walkthrough plural
Método desarrollado inicialmente en los laboratorios IBM, y realizado con los tres tipos principales de actores implicados en el producto: usuarios representativos, desarrolladores y expertos en usabilidad. Se caracteriza por la responsabilidad que toman todos los participantes en asumir el papel de los usuarios reales y también porque suele terminarse con un debate en común entre todos los stakeholders.

Qué metodología se usa:

‘Metodología tradicional’
Los pasos a seguir para llevar a cabo un Walkthrough convencional serían:

Confección de un prototipo de baja fidelidad (sobre el cual se practicará la sesión de inspección).
Reclutamiento de los evaluadores que, como hemos visto en el método clásico, serían expertos.
Definición de las tareas core soportadas por el sistema sobre las cuales se realizará el recorrido.
El llamado ‘happy path’: por cada tarea, añadir por escrito una lista con las acciones que se necesitan para completarla satisfactoriamente.
Por ejempo, el happy-path para una supuesta tarea de ‘Enviar un correo electrónico’ sería:

Abre el navegador.
Accede a tu gestor de correo on-line.
Presiona sobre el botón ‘Correo nuevo’.
Añade el asunto del correo.
Añade los destinatarios.
Añade el cuerpo del correo.
Presiona el botón de ‘Enviar’.

5. Para cada una de las tareas, el evaluador tiene que recorrer las acciones sobre el prototipo, opinando sobre el sistema y respondiendo a las siguientes cuatro preguntas:

¿El usuario intentará lograr el efecto correcto?
¿Percibirán los usuarios que está disponible la acción correcta?
¿Los usuarios asociarán la acción correcta con el resultado que espera lograr?
Si se realiza la acción correcta, ¿Los usuarios verán que se está avanzando hacia el resultado deseado?

6. Documentar los resultados.
Se deben anotar todos los comentarios de los usuarios y el sistema. Y a partir de su análisis, elaborar un informe de oportunidades de mejora de la aplicación.

‘Metodología sobre papel’
Esta variante de Walkthrough se realiza sobre un prototipo de papel de baja fidelidad y también se basa en recorrer cada una de las tareas preparadas. La única variante es que, para cada tarea, no se formulan las cuatro preguntas sino que se anotan por escrito las acciones y las dudas que tiene el usuario. En Interactius, es la metodología con la que estamos más acostumbrados a trabajar, ya que creemos que es más ágil que el método tradicional. Además la aplicamos implicando a usuarios finales y adaptándonos así a resultados más realistas y concretos.
A continuación, se explica paso por paso la dinámica de preparación, ejecución y análisis de un Walkthrough tipo bajo la ‘metodología sobre papel’.

Dinámica de preparación, ejecución y análisis

Preparación

Reclutar el conjunto de usuarios que realizarán el recorrido. Deben de ser usuarios reales que no estén muy familiarizados o que no hayan usado nunca el sistema.
El número de participantes suficientes para llevarlo a cabo son entre 6 y 10.
Determinar qué tareas soportadas por el sistema se quieren evaluar. Siempre se debe intentar que sean funcionalidades principales y no secundarias. Dependiendo de la aplicación, habrán más o menos tareas. Sin embargo, por cuestiones de tiempo, no es recomendable testear más de cinco. También se debe tener en cuenta si la aplicación tiene distintos perfiles de usuario, ya que deberán diferenciarse las tareas.
Para cada tarea, preparar un dosier compuesto por un conjunto de wireframes sobre papel que simulen un escenario, dónde se muestre visualmente, página a página, el avance de la consecución de la tarea de manera correlativa.
Apuntes importantes:

Usa páginas de papel DIN-A3.
Para cada dosier-tarea, añade una portada con el enunciado de la tarea objetivo. A menudo se deben añadir premisas para entender mejor la tarea (Ej. ‘ Se da por hecho que ya eres usuario del sistema y ya te has autenticado’).
En cada pàgina debe adjuntarse una pequeña ficha-formulario a rellenar por parte del usuario, con la siguiente información:

Número de participante.
Número de pantalla.
Enunciado o título de la tarea.
La pregunta: “¿Qué harías o seleccionarías?”
La pregunta: “¿Hay algo que te resulte confuso o que no se entienda?”
Un campo de “Observaciones”.

Para aportar veracidad al test, lo ideal es que los datos y elementos que aparecen en cada pantalla simulen al máximo el funcionamiento real del sistema. Por lo tanto, se evitarán recursos como por ejemplo el “Lorem ipsum” o cifras inventadas.
El diseño de cada Wireframe debe ser simple y de baja fidelidad, para evitar que el usuario se distraiga en cuestiones de diseño. También usa fuentes grandes y una buena calidad de impresión.

4. Imprimir tantos libros de tareas como usuarios asistan a la sesión de Walkthrough. La siguiente captura, muestra un ejemplo de una de las hojas de un dosier de una tarea de un Walkthrough.
Nótese las distintas partes anteriormente comentadas:

Wireframe de la aplicación. Muestra una acción, dentro de la concatenación de acciones de toda la tarea.
Formulario de paginación.
Formulario cuestionando las acciones y decisiones tomadas por el usuario.

**Ejemplo de una de las hojas de un dosier de una tarea de un *Walkthrough*.**

Ejecución

Presentar la sesión de Walkthrough a los participantes. Explicando el funcionamiento de ésta y aclarando cualquier duda.
Como en cualquier test con usuarios se debe dejar claro que el objetivo de la sesión no es evaluarlos a ellos, sino a la interfaz del sistema en cuestión.
Entregar a cada usuario el libro de dosieres de tareas.
Ejecutar el ejercicio de manera individual, en silencio y escribiendo sus comentarios.
Normalmente en este tipos de métodos se suele usar la técnica del Thinking Aloud para grabar rápidamente los comentarios de voz de los evaluadores. Sin embargo, creemos que el hecho de obligar a escribir las reflexiones obliga al usuario a concentrarse y poner mucho foco en el recorrido.
Los usuarios deben recorrer las tareas pantalla a pantalla indicando qué acciones realizaría y qué cree que sucedería, siguiendo estas dos normas importantes:

Nunca se puede voltear la siguiente hoja hasta no haber completado la hoja en curso.
Una vez se ha dado la vuelta a la hoja, independientemente de lo que encuentre, tiene que volver a informar qué acciones realizaría y que cree que pasaría. Teniendo en cuenta que no se puede volver a hojas anteriores para corregir comentarios supuestamente erróneos.

5. Durante la sesión, los usuarios pueden hacer preguntas de todo tipo a los facilitadores.

6. Una vez todos los participantes han terminado de rellenar sus tareas y se han recogido todos los dosieres, se puede realizar una breve sesión de Focus group para intercambiar opiniones y puntos de vista.

walkthrough_sesion — **Simulación de una sesión de *Walkthrough* con usuarios reales. Fotografía propiedad de** **Dr. Andreas Holzinger**

Análisis

Es tarea de los consultores UX volcar toda la información recogida en la sesión y organizarla por tareas y perfiles de usuario (si fuera el caso).
Analizar todos los errores, puntos de dolor, dudas y comentarios que han anotado cada uno de los usuarios.
A partir del análisis, redactar un informe detallado con una serie de hallazgos de errores de usabilidad de la aplicación. Para cada hallazgo hacer una ficha donde conste:

Descripción del problema de usabilidad detectado.
Propuesta de mejora del problema.
Pantallazo ilustrativo de la aplicación.
Lugar de la aplicación dónde ocurre.
Indicador numérico de la severidad del error.
Suele hacerse sobre una escala del 1 al 5 y sirve para ordenar los hallazgos: de los más problemàtios a los que menos

**Ejemplo de ficha de un hallazgo de un informe de análisis de un *Walkthrough*.**

4. Hacer una valoración y aplicar las soluciones a los problemas anteriores sobre el prototipo del producto.
Como se ha comentado anteriormente, dependiendo de la fase en la que se realice la sesión de Walkthrough, el proceso de actualización será más o menos costoso.

Ejemplos

Finalmente, para ilustrar mejor el desarrollo de una sesión de Walkthrough, se adjuntan una serie de videos de ejemplos de casos reales con usuarios.

En este caso el usuario utiliza la metodología clásica, dónde para cada acción de una tarea, se formulan las cuatro preguntas antes comentadas.

2. Por otro lado, este ejemplo muestra una sesión de Recorrido Cognitivo de una aplicación móvil sobre papel.
La particularidad de está variación es que dependiendo de las acciones que haga o elija el usuario, se van superponiendo diferentes elementos sobre la pantalla mediante recortes de papel. Esta técnica es mucho más abierta y menos restrictiva que la de fijar un ‘happy path’ de acciones de una tarea tipo.