El testeo en papel ha resultado ser una técnica sencilla, barata y ágil para explorar los límites de los prototipos que diseñamos. Diferentes artículos en la web nos asoman bondades de esta técnica, dando consejos e ideas para hacerlo como es debido. El Nielsen Norman Group incluso tiene un DVD explicativo muy recomendado (por $68).

Hace unos días Chema y yo decidimos hacerlo en idealista.com. Tras una fase de prototipado bastante larga decidimos que, antes de testearlo en digital, sobre una maqueta, podíamos hacerlo en papel. En la primera prueba ya adivinamos ciertas mejoras que vinieron bien para dejar más cerrado el wireframe, pero aún así, encontramos algunas dificultades que colocan a esta técnica en un nivel de eficacia un poco relativo. Las enumero a continuación:

• Scrolling: implica hacerse de un recorte del browser y mostrar sólo el contenido que entra en la resolución deseada, cuando el usuario pincha sobre la barra de scroll toca mover la página manualmente. La verdad es que resulta raro, porque tienes que afinar mucho para que la hoja no se atasque y saber dónde tienes la línea de flotación. La otra opción (la que nosotros probamos) consiste en mostrar la página al completo, con todo su contenido, el problema es que el usuario lo ve todo desde el principio, falseando un poco la realidad. En cualquiera de los dos casos, resulta una interacción poco natural.
• Efectos mouse over: tuvimos que descartarlo definitivamente. Nos hubiera gustado comprobar la reacción de usuarios ante un drop-down o determinadas tooltips al hacer mouse over en determinados escenarios, pero teniendo en cuenta que el cursor es un la punta de un lápiz, resulta imposible andar con el desplegable detrás del “cursor” del usuario y calcular cuándo hay que mostrarlo. Descartado.
• Estado de los elementos de interacción: drop-downs, radio-buttons, checks, etc. son difíciles de mantener. Cada vez que el usuario pincha sobre uno de ellos tienes que mostrar el elemento seleccionado. La simple selección de tres o cuatro elementos resulta un proceso lento en este tipo de testeo.
• Páginas no comtempladas: cuando el usuario se sale del flujo de pantallas previsto lo único que puedes hacer es mostrarle “página en contrucción” o algo parecido. Resulta muy difícil contemplar todo lo que el usuario puede hacer. Sólo puedes ceñirte a un grupo de páginas.

Conclusiones:

Resulta una técnica bastante interesante para identificar problemas que van más relacionados con el concepto que quieres desarrollar, pero hacer prototipos de alta fidelidad y luego testearlo sobre papel se hace lento, difícil y tedioso.

El cursor es la punta de un lápiz. Es algo poco natural y a los usuarios les resulta difícil interiorizar que la punta representa el cursor. Es necesario explicarlo despacio y bien.

Feedback de la interfaz: cerrar todo lo que el sistema puede hacer es difícil. Si encima defines a alta fidelidad multiplicas el tiempo de preparación por cinco.

El tiempo: al final es el problema más importante. Se tarda tiempo en preparar los escenarios y tiempo en intercambiar las hojas conforme el usuario navega. Cualquier pequeño detalle, desde la selección de un check hasta la paginación prolonga tu sesión al doble.

Mi recomendación, desde la experiencia vivida, es aconsejar esta ténica en las primerísimas etapas de concepción. Más tarde, en fases donde tu proyecto está más cerrado, evitaría aplicar testeo sobre papel. Su preparación es lenta y merece más la pena emplear el tiempo en el desarrollo de una maqueta dinámica.

Nota: la foto pertenece al NNGroup.