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.

Podemos especificar el perfil de usuario en dos dimensiones: Los conocimientos de dominio del usuario (sus conocimientos profesionales en el área de aplicación) y los conocimientos de TI del usuario. (Ver más sobre los perfiles de usuario en la sección 5.4.) En el caso del sistema hotelero, ¿podemos asumir que nuestros usuarios del hotel tienen experiencia en recepción? O, ¿también debemos atender a los asistentes temporales en el servicio nocturno? ¿Podemos suponer que conocen la TI en el nivel de procesamiento de texto? ¿O que han intentado otro sistema de recepción antes?

A veces necesitamos la ayuda de otras personas para encontrar usuarios de prueba. Estas personas deben saber la respuesta a estas preguntas con el fin de seleccionar los usuarios adecuados. La sección 13.3 explica más sobre cómo encontrar usuarios de prueba.

¿Dónde probar?

¿Dónde debemos hacer la prueba? Existen varias posibilidades:

1. En nuestra propia sala de reuniones. Esto está bien porque tenemos fácil acceso al prototipo y otros equipos, y podemos evitar interrupciones. El problema es que el usuario viaje a nuestro lugar. Además, el ambiente de prueba puede no reflejar las condiciones reales de trabajo.
2. En el sitio del usuario. Esto estaría normalmente en el lugar de trabajo del usuario. La ventaja es que el usuario no necesita viajar y el medio ambiente es el correcto. La desventaja es que tenemos más problemas para configurar el prototipo y no podemos controlar las interrupciones. Además, el usuario puede sentirse incómodo porque sus colegas pueden observarlo durante la prueba.
3. En un lugar público. Esto es útil para sistemas públicos, tales como sistemas de bibliotecas y sistemas de información de viajes. El medio ambiente es el verdadero, e incluso podemos tener la suerte de encontrar a nuestros usuarios de prueba en el acto. La desventaja es el problema de configurar el prototipo y otros equipos en este lugar.
4. En un laboratorio de usabilidad. Podemos tener uno en nuestra propia compañía o podemos alquilar uno de otra compañía. Como explicamos a continuación en la recolección de datos esto es mucho más engorroso y sólo vale la pena el esfuerzo para los sistemas en los que tenemos un prototipo funcional y queremos estudiar las acciones rápidas de los usuarios.

Roles en el equipo de prueba

El equipo de prueba está formado por diseñadores y / o especialistas en HCI. El equipo debe manejar tres roles:

•  El facilitador que tiene el contacto principal con el usuario de la prueba, le da las tareas de prueba, le pide que piense en voz alta, le pregunte lo que está buscando, etc. El facilitador también es el líder de la prueba.
• El ordenador'. A menos que usemos un prototipo completamente funcional, necesitamos una persona que simule lo que hace la computadora, cambia pantallas, escribe las respuestas de la computadora, etc. Algunas personas lo llaman El Mago de Oz. Esta persona suele ser un diseñador, ya que sabe mejor lo que el ordenador debe hacer.
•  El administrador del registro escribe lo que sucede, donde el usuario encuentra problemas, lo que el usuario cree sobre el sistema, etc. El usuario del registro puede interferir cautelosamente con el usuario, por ejemplo para aclarar un problema o retener al usuario mientras el registro El guardián escribe sus notas. Sin embargo, el guardián del registro debe respetar el papel principal del facilitador durante la prueba, de lo contrario puede terminar en un lío.

Podemos asignar una persona a cada uno de estos roles, pero a menudo dejamos que dos personas los compartan. Como ejemplo, una persona puede ser facilitadora y computadora al mismo tiempo; La otra persona es el encargado del registro. A veces he jugado todos los papeles solos, pero eso es duro, particularmente con pruebas largas. Pronto me da la sensación de que extraño demasiados problemas o de que la "computadora" haga lo malo.

...