Malentendidos comunes

...

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:

- 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.

- 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.

- 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.

- 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.

Algunos especialistas de HCI dicen que los desarrolladores no deben estar presentes durante la prueba. Los desarrolladores pueden observar lo que está sucediendo a través de una pantalla de televisión remota o desde una sala de observación vecina, separada por cristal. El argumento es que los desarrolladores no pueden abstenerse de interferir con los usuarios, dándoles ayuda y asesoramiento - o comentando sobre lo que hacen.

Mi propia experiencia es que muchos desarrolladores son realmente buenos en el equipo de prueba tan pronto como se les da la idea de lo que se trata. Pronto pueden ejecutar pruebas de usabilidad por su cuenta. Tengo sólo unas pocas veces observado desarrolladores interferir de manera inapropiada, por ejemplo, en total frustración gritando al usuario desde la parte posterior de la habitación mirar en la parte inferior de la pantalla (mensajes de error apareció allí, pero el usuario no había notado). Un buen facilitador puede manejar esto de una manera que bromea y el revelador no lo hará otra vez.

Tareas de prueba

Tenemos que planificar las tareas que el usuario debe intentar. No es suficiente mencionar las tareas, tenemos que planificar los datos específicos a utilizar. En la figura 13.2 hemos indicado al huésped específico para reservar. Necesitamos su nombre, dirección, cuando llega, etc., por ejemplo, en forma de carta o fax.

Muchos desarrolladores tienen cierta dificultad en señalar las tareas de prueba de una buena manera. Tienden a dar al usuario una receta para llevar a cabo la tarea, en lugar de darles un problema para resolver. Volvemos a esto en la sección 13.5.

Encontrar los problemas importantes depende crucialmente de las tareas que incluimos en la prueba. Debe ser obvio que no podemos encontrar problemas que se producen al realizar la tarea X si no probamos la tarea X. Por otro lado, una sesión de prueba con un solo usuario no puede durar más de 1-2 horas. Las pruebas más largas son agotadoras tanto para el usuario como para el equipo de pruebas. Esto pone un límite al número de tareas que podemos probar.

Afortunadamente, el efecto acelerador nos ayuda. Cuando las pantallas centrales son correctas - para que los usuarios entiendan - los desarrolladores son más capaces de hacer las pantallas restantes también. Además, cuando los usuarios entienden las pantallas centrales del sistema, les resulta más fácil entender el resto. Por esta razón, inicie las pruebas con las tareas que utilizan sólo las pantallas centrales. (La Sección 2.4.3 explica más sobre el efecto acelerador.)

Presentación