Malentendidos comunes

13.1 Malentendidos comunes

Hay muchos malentendidos sobre las pruebas de usabilidad:

• No es necesario contar con un sistema funcional. Incluso una versión en papel y lápiz de las pantallas puede revelar la mayoría de los problemas.
• No es una demostración del sistema en la que un desarrollador o una persona de marketing muestre cómo realizar varias tareas con el sistema. Los usuarios y los clientes pueden estar muy entusiasmados con el sistema, pero ser completamente incapaces de usar por su cuenta.
• No es una prueba en la que un colega es el usuario de la prueba. Lo más probable es que él sepa tanto sobre las computadoras que no encontrará ciertos tipos de problemas. Y él puede saber tan poco sobre el área de aplicación que se encuentra con problemas que los usuarios reales no. Es esencial encontrar usuarios de prueba que correspondan al público objetivo del producto final.
• La prueba no tiene que realizarse en un laboratorio de usabilidad especial con video, registro electrónico y paredes de vidrio semitransparentes. Un escritorio con un PC, un facilitador, un guardián del registro y preferiblemente un desarrollador motivado es suficiente en la mayoría de los casos. Cuando pruebe con maquetas de papel, puede incluso prescindir de la PC.

Propósito de las pruebas de usabilidad

¿Cuál es el propósito de las pruebas de usabilidad? ¿Por qué hacemos la prueba? La figura 13.1 muestra algunas posibles respuestas.

Pruebas de usabilidad durante el desarrollo. Veamos primero los propósitos durante el desarrollo del sistema.

El propósito no es encontrar bugs en el sistema. Los desarrolladores tienen formas más rentables de hacerlo. Por supuesto, puede ocurrir que encontremos errores durante una prueba de usabilidad. Por ejemplo, la versión inicial del sistema que usamos para las pruebas de usabilidad podría fallar de vez en cuando, o la maqueta no tiene todos los cuadros de mensaje necesarios. Anotamos estos problemas para ayudar a los desarrolladores a corregirlos, pero Este no es el propósito de la prueba de usabilidad.

El propósito principal no es probar que el sistema es fácil de usar. Los desarrolladores sin experiencia de usabilidad creen que su sistema es fácil de usar, y quieren demostrarlo justo antes de la entrega. Encuentran un número asustadizo de problemas, pero no son capaces de corregirlos en esta etapa. Sin embargo, si hemos hecho pruebas de usabilidad temprano durante el diseño, es una buena idea hacer un cheque también al final, para detectar problemas que se han colado después del diseño.

A primera vista, el objetivo principal es encontrar problemas de usabilidad, pero es sólo una parte de por qué realmente hacemos la prueba: Queremos corregir los problemas. Si no planeamos cambios también, no habrá mejoras en el producto final y las pruebas serán una pérdida de tiempo. Esta es la razón por la cual es tan importante realizar pruebas de usabilidad temprano durante el diseño, preferiblemente antes de que algo haya sido programado.

Un efecto secundario importante de las pruebas tempranas de usabilidad es que los desarrolladores experimentan los usuarios, sus conocimientos y actitudes de dominio y sus conocimientos y actitudes de TI.

Esto puede mejorar fuertemente la intuición que los desarrolladores usan cuando diseñan la interfaz.

Pruebas de usabilidad en otros casos. Pruebas de usabilidad se puede utilizar en otros casos también. Por ejemplo, podemos querer medir la utilidad de un producto que queremos comprar. O medir la usabilidad de un sistema antiguo que planeamos mejorar.

13.2 Planificación de la prueba

La Figura 13.2 muestra las cosas importantes a considerar cuando se planifica una prueba de usabilidad. Puede utilizar la figura como plantilla cuando planifique sus propias pruebas de usabilidad. En la figura hemos rellenado la plantilla correspondiente a un test de usabilidad de un sistema hotelero que desarrollamos.

¿Cuántos usuarios?

¿Cuántos usuarios de prueba necesitamos? Algunos expertos de HCI afirman que necesitamos al menos 10 usuarios para obtener significancia estadística, de lo contrario la prueba no sirve de nada. Por desgracia, esto se utiliza a menudo como un argumento para ni siquiera intentar, ya que los compañeros desarrolladores pueden ver claramente que 10 usuarios requieren una gran cantidad de trabajo.

La experiencia demuestra que al comienzo del desarrollo, deberíamos probar con un solo usuario! Encontramos tantos problemas serios con un solo usuario que sería tonto probar con otro usuario antes de que se hayan corregido los peores problemas. No todos los problemas son problemas de usabilidad. Algunos de ellos son problemas en el montaje experimental, por ejemplo, que el prototipo de configuración y las tareas de prueba no coinciden.

En la siguiente ronda de pruebas, podemos utilizar 2-4 usuarios. Da una gran cantidad de datos de observación para realizar un seguimiento. Por supuesto, podemos perder algunos problemas que relativamente pocos usuarios encuentran, y por casualidad ninguno de nuestros usuarios de prueba. Desde un punto de vista práctico, este es el tipo de riesgos que tenemos que correr en la mayoría de los proyectos. En la práctica, no podemos hacer felices a todo el mundo. (Ver sección 13.4 para una discusión detallada.)

Cuando ayudo a los desarrolladores a realizar pruebas de usabilidad por primera vez, suele suceder lo siguiente: El primer usuario llega a la prueba y pronto se encuentra con muchos problemas graves. Los desarrolladores se miran el uno al otro, pensando: qué idiota - no puede ser un usuario típico. Entonces el próximo usuario llega y pronto se tropieza con los mismos problemas. Ahora los desarrolladores se ponen incómodos - tal vez hay algunos problemas con la interfaz de usuario. Y cuando el tercer usuario encuentra los problemas, los desarrolladores están convencidos. En la mayoría de los casos esto logra el propósito principal - los desarrolladores se motivan para mejorar la interfaz de usuario.

Así, con los desarrolladores que no están familiarizados con las pruebas de usabilidad, tres usuarios parecen una buena opción para la primera prueba. Para los desarrolladores experimentados, un usuario para la primera prueba es la opción correcta.

¿Qué usuarios?

Es importante saber qué tipo de usuarios de prueba necesitamos. Su conocimiento debe corresponder a los usuarios que esperamos en la práctica. No necesitamos cuidar tanto a los usuarios ideales que entienden rápidamente y conocen muchos sistemas de TI ya, pero deben buscar aquellos en el extremo más débil del grupo de usuarios.

...