Posgrado en Sistemas Computacionales Pruebas de usabilidad MC Luz María Moreno Aguilar Diciembre 2009

Plan Introducción Consideraciones Ciclo de vida de la prueba Actores Seleccionar a los experimentadores ¿qué medir?

Evaluación de la Usabilidad a)

Introducción Evaluación de usabilidad La principal actividad en el proceso de usabilidad es la evaluación La evaluación de la usabilidad puede ayudar a determinar el nivel actual del sistema y si el diseño elegido realmente funciona.

Introducción Los datos que se recaban mediante la observación del usuario frente a la aplicación, es información muy valiosa que ayudan en definitiva a detectar posibles mejoras del sistema.

Consideraciones Existen diferentes técnicas para evaluar un sistema, su uso depende de variables tales como: Costo Disponibilidad de tiempo Personal calificado para interpretar los datos, etc

Técnicas para medir la usabilidad Inspección formal de usabilidad. Un grupo de expertos realizan una especie de juicio de la interfaz, con uno de los participantes actuando como moderador, destacando las fortalezas y las debilidades de la aplicación.

Qué es una prueba de usabilidad? Una prueba de usabilidad es una medida empírica de la usabilidad de una herramienta, sitio o aplicación, tomada a partir de la observación sistemática de usuarios llevando a cabo tareas reales.

¿Por qué aplicar un prueba de usabilidad? Nos permitirá: Verificar la existencia de posibles problemas de usabilidad en el sitio. Encontrar posibles soluciones para los problemas encontrados. Establecer una medida concreta inicial contra la cual comparar a los competidores, futuros desarrollos de este mismo sitio o modificaciones al actual.

Tiempo y recursos necesario para la prueba Dependerá del tamaño del sistema y del grado de revisión de parámetros Recursos Un laboratorio completo de usabilidad es caro y complicado. Requiere mucho espacio, una habitación con un espejo de un solo sentido dividiéndola, equipo de grabación de audio y video, etc.

Ciclo de vida de la prueba Planificación: desarrollo del plan de la prueba, selección de participantes y preparación de los materiales. Prueba: Prueba piloto, ajustes y prueba definitivo. Conclusión: análisis de los datos, elaboración del informe y recomendaciones.

Planificación Desarrollo del plan Documentar los pasos a seguir, esto permite coordinar los esfuerzos de todos los participantes y definir claramente el rol de cada uno. Selección de participantes Es muy importante que los participantes sean lo más representativos posible ya que, normalmente, no hay posibilidad de trabajar con grandes muestras para hacer las pruebas. Preparación de materiales Preparar cuestionario pre y post prueba, la introducción para el Participante, las definiciones y escenarios para las Tareas, otros elementos necesarios vinculados con las tareas y los temas del interrogatorio post prueba.

Prueba Prueba piloto Probar el diseño de la prueba con un participante que puede tener menos requerimientos que los que utilizarán en la prueba definitiva. Puede ser una persona de la misma empresa u organización, que no participe directamente del proyecto del sitio. La prueba piloto sirve para verificar que todo funciona como corresponde y todos (Observadores, Facilitador y Participante) conocen sus roles y tareas y las cumplen a la perfección. Al finalizar se hace un pequeño análisis para determinar si es necesario hacer modificaciones al protocolo de la prueba. Para poder hacerlo con tranquilidad, es que la prueba piloto suele llevarse a cabo un día completo antes de comenzar con la prueba definitiva.

Prueba Prueba definitiva Se lleva a cabo la prueba con los participantes elegidos. Generalmente, se plantea un mínimo de 4 o 5 usuarios. Excepto casos muy particulares, no tiene mucho sentido hacer más de 8 o 10 usuarios, ya que el número de hallazgos por usuario disminuye significativamente y los usuarios son un recurso caro y difícil de encontrar. Para cada participante, se le da la bienvenida, se le explica lo que se va a hacer, se plantean ejecutan las tareas, se hace el interrogatorio post prueba. Se suele entregar alguna muestra de reconocimiento a los participantes, dependiendo de quiénes son y qué tan importantes son para la prueba.

Conclusión Análisis de datos Se reúnen los datos de los observadores, se analizan estadística y semánticamente, y se discuten sus posibles implicancias. En la discusión participan los observadores, el facilitador y –opcionalmente– otros integrantes del staff de desarrollo Informe y recomen- daciones Se elaborará un informe que contendrá los resultados y las recomendaciones para mejorar el sitio de acuerdo a lo observado. Este informe no sólo cumple con la formalidad de terminar la prueba, sino que es el respaldo para explicar a otras personas que no estuvieron involucradas los motivos de nuestras acciones y decisiones.

Plan de prueba Un plan de prueba debe ser escrito antes del comienzo de la prueba y debería abordar las siguientes cuestiones: El objetivo de la prueba: ¿Qué quieres lograr? ¿Dónde y cuándo se llevará a cabo la prueba? ¿Cuánto tiempo se espera que dure cada sesión de prueba? ¿Qué equipo de apoyo serán necesarios para la prueba? ¿Qué software tiene que estar preparado para la prueba? ¿En qué estado debería estar el sistema al inicio de la prueba? ¿Cómo debería ser la carga del sistema / red y los tiempos de respuesta? Si es posible, el sistema no debe ser extremadamente lento, pero tampoco exageradamente rápido, ya que se ejecuta en un sistema o red sin ningún otro usuario. Uno puede artificialmente a ralentizar el sistema para simular los tiempos de respuesta reales.

Plan de prueba continuación… ¿Quién servirá como experimentador para la prueba? ¿Quiénes van a ser los usuarios de prueba, y cómo conseguirlos? ¿Cuántos usuarios de la pruebas se necesitan? ¿Qué tareas de prueba se les pedirá a los usuarios que realicen? ¿Qué criterios se utilizan para determinar cuándo los usuarios han terminado de cada una de las tareas de prueba correctamente? ¿Qué ayudas de usuario (manuales, ayuda en línea, etc) se pondrá a disposición de los usuarios de prueba? ¿Hasta qué punto se permitirá al experimentador ayudar a los usuarios durante la prueba? ¿Qué datos se va a recoger, y cómo va a ser analizadas una vez que se ha recogido? ¿Cuál será el criterio que para determinar una interfaz exitosa?

Actores en una prueba de usabilidad En una prueba de usabilidad deberá haber por lo menos 3 actores: El participante o Usuario. El facilitador, monitor o experimentador. Los observadores o aplicadores. Los usuarios de la prueba deben ser tan representativos como sea posible de los usuarios que usarán el sistema

Seleccionando al experimentador Tener experiencia previa sin importar el método seleccionado No necesita saber como ha sido implementado el sistema, aunque puede recibir capacitación antes de la prueba Puede ser uno de los diseñadores

Aspectos éticos de una prueba Antes de la prueba: Tener todo listo antes de que el usuario llegue Destacar que es el sistema que se está probando, no el usuario. Reconocer que el software es nuevo y no probado, y puede tener problemas. Haga saber a los usuarios que pueden parar en cualquier momento. Explique cualquier grabación, registro de pulsaciones, o el seguimiento de otro tipo que se utiliza. Avisar al usuario de que los resultados se mantendrán en forma totalmente confidencial. Asegúrarse de haber contestado todas las preguntas del usuario antes de proceder.

Aspectos éticos de una prueba Durante la prueba: Tratar de dar al usuario una experiencia de éxito temprano. Distribuir las tareas de prueba de una en una. Mantener un ambiente tranquilo en la sala de ensayo, servir café y / o tener descansos. Evitar las interrupciones: Cerrar la puerta y colocar un cartel en ella. Deshabilitar el teléfono. Nunca indicar, de ninguna manera, que el usuario está cometiendo errores o es demasiado lento. Minimizar el número de observadores en la prueba. No permita que al jefe del usuario observar la prueba. Si es necesario, permitir al experimentador detener la prueba si se vuelve demasiado desagradable.

Aspectos éticos de una prueba Después de la prueba: Finalizar afirmando que el usuario ha ayudado a encontrar áreas de mejora. Nunca informe de resultados de tal manera que los usuarios individuales pueden ser identificados. Sólo mostrar cintas de video fuera del grupo de usabilidad con el permiso del usuario

¿Qué medir? Las mediciones cuantificables de usabilidad típicas incluyen: El tiempo que le toma a los usuarios completar una tarea específica. El número de tareas (o la proporción de una tarea mayor) de varios tipos que pueden ser completados en un plazo determinado. La relación entre las interacciones exitosas y los errores. El tiempo gastado en recuperación de errores. El número de errores de usuario. El número de acciones erróneas inmediatamente posterior. El número de comandos u otras características que fueron utilizados por el usuario (ya sea el número total de órdenes emitidas o el número de los diferentes comandos y funciones utilizadas).

¿qué medir? continuación… El número de comandos u otras características que nunca fueron utilizados por el usuario. El número de características de sistema el usuario puede recordar durante un interrogatorio después de la prueba. La frecuencia de uso de los manuales y / o el sistema de ayuda, y el tiempo de utilización de estos elementos del sistema. ¿ Con qué frecuencia el manual y / o ayuda del sistema resolvió el problema del usuario. La proporción de las declaraciones de usuario durante la prueba que fueron positivas en comparación con las críticas hacia el sistema. El número de veces que el usuario expresa su clara frustración (o clara alegría). La proporción de usuarios que dicen que ellos prefieren usar el sistema mejor que el de algún competidor determinado.

¿qué medir? continuación… El número de veces que el usuario tuvo que trabajar en torno a un problema irresoluble. La proporción de usuarios utilizando estrategias eficaces de trabajo en comparación con los usuarios que utilizan estrategias ineficientes (en caso de que haya múltiples maneras de realizar las tareas). La cantidad de "tiempo muerto" cuando el usuario no está interactuando con el sistema. El sistema puede estar dotado de instrumentos para distinguir entre dos tipos de tiempo muerto: los retrasos en el tiempo de respuesta, donde el usuario está esperando por el sistema, y retrasos en el tiempo de pensamiento, donde el sistema está esperando por el usuario. Estos dos tipos de tiempo muerto, obviamente debe ser abordados de diferentes maneras. El número de veces que el usuario se desvíe de centrarse en la tarea real.