EVALUACIN DE USABILIDAD DE PENSAMIENTO EN VOZ ALTASDD4

Mtro. Armando Cruz Cruz

TEMAS BSICOS DE LA EVALUACIN DE USABILIDAD DE

PENSAMIENTO EN VOZ ALTA3.1

QU ES UNA EVALUACIN DE USABILIDAD DE PENSAMIENTO EN

VOZ ALTA? Es una tcnica emprica utilizada para evaluar la

usabilidad de un prototipo de interfaz cualquiera.

Se describe como el mtodo de ingeniera de usabilidad ms valioso.

Para llevar a cabo la evaluacin se requiere que, mientras un usuario desempea una tarea en tu sistema, comente en voz alta lo que est pensando. Mientras, tu observas silenciosamente para aprender lo que el usuario piensa de la tarea y los problemas que tiene al usar el sistema.

Se conforma de dos tcnicas, el anlisis del protocolo de pensamiento en voz y el anlisis de incidentes crticos.

ANLISIS DEL PROTOCOLO DE PENSAMIENTO EN VOZ

ALTA

El mtodo consta de dos partes

la recopilacin de datos del pensamiento en voz alta (protocolos)

la construccin y anlisis de un modelo (generalmente la simulacin de un sistema).

La primera parte del mtodo, la recopilacin de datos del pensamiento en voz alta, ha sido de extrema utilidad para evaluar la usabilidad de los sistemas computacionales.

ANLISIS DEL PROTOCOLO DE PENSAMIENTO EN VOZ

ALTA

Existen tres tipos de expresiones del pensamiento

hablar en voz alta (tipo 1)

pensar en voz alta (tipo 2)

los procesos intermedios (tipo 3).

PROTOCOLO TIPO 1

2 + 4 = ?

PROTOCOLO TIPO2

EJEMPLO: ARMAR UN ROMPECABEZAS

PROTOCOLO TIPO 3

Consiste en pedirle a alguien que se exprese verbalmente pero con una peticin adicional para agregar mas procesamiento a la informacin.

Ejemplificando:

le puedes pedir a algunos automovilistas que te especifiquen los peligros que perciben, relacionados con la construccin, mientras recorren alguna ruta particular. Lo anterior requiere que filtren la informacin para NO incluir los peligros asociados con escuelas y parques y precipicios o cada de piedras.

Este tipo no es recomendable para el diseo de interfaces de usuario

ANLISIS DE INCIDENTES CRTICOS

Los estudios de usabilidad en el diseo UI ha modificado el procedimiento, quedando de la siguiente manera:

Usando un prototipo del sistema computacional a ser evaluado, un usuario expresa sus pensamientos en voz alta mientras desempea una tarea en un ambiente de laboratorio. Generalmente la sesin se filma o se usa un software para captar las acciones y la voz.

El analista (no el usuario que desempe la tarea) observa la sesin grabada del protocolo de pensamiento en voz alta y hace un reporte de los incidentes crticos usando el formato UAR.

El analista categoriza e interpreta las observaciones.

El analista hace el resumen de la informacin y sus interpretaciones.

DEFINICION DE INCIDENTE CRITICO

"Se define como incidente cualquier actividad humana observable que sea suficientemente completa para permitir inferencias y predicciones sobre la persona desempeando la funcin"

"Para que un incidente sea crtico, el incidente debe ocurrir en una situacin donde el propsito o la intencin del acto sea claro para el observador y donde sus consecuencias sean suficientemente definitivas y evidentes".

" Dichos incidentes son comportamientos extremos, ya sean extremadamente efectivos o inefectivos con respecto al objetivo de la actividad

ESTUDIO DE USABILIDAD

Por lo tanto, el procedimiento para hacer un estudio de usabilidad combina los mejores protocolos del pensamiento en voz alta y la tcnica de incidentes crticos.

Se documentan los pensamientos de los usuarios lo que les llama la atencin, la informacin que no ven, los conocimientos previos que utilizan para hacer la tarea, lo que los desconcierta y lo que es muy claro para ellos.

Tambin provee una forma para registrar datos importantes en los UAR de incidentes crticos y resume los resultados en un reporte final.

TICA EN LOS ESTUDIOS EMPRICOS

Evaluar la Interfaz, No al Participante

Participacin Voluntaria

Mantener el Anonimato

Consentimiento

Leyes

EVALUAR LA INTERFAZ, NO AL PARTICIPANTE

El usuario no es igual que yo

Esto significa que tu, como diseador de sistemas, nunca podrs pensar igual que un usuario porque conoces muy bien el sistema y no puedes impedir que todo ese conocimiento te ayude a usar el sistema.

Se debe contar con personas que cuenten con una aptitud computacional similar a la de los usuarios potenciales del sistema.

USUARIOS CORRECTOS falta de atencin te debe hacer cuestionar las causas

de su distraccin.

Sus errores te hacen cuestionar si las guas del sistema provocan los errores

No leern todas las instrucciones y/o los mensajes de error, ya que tampoco los leen los usuarios reales.

los cambios de estado de nimo y su salud te permite evaluar la manera en que las personas usan el sistema con todas las distracciones de sus vidas.

Cualquier cosa que los participantes hagan, siempre cuestiona si no hay algo del sistema que provoca al usuario hacia cierta direccin, en lugar de culpar al participante de no saber lo suficiente o de no poner atencin o no leer

PARTICIPACIN VOLUNTARIA

La participacin en la evaluacin siempre debe ser voluntaria.

es muy importante crear un ambiente en el cual el participante se sienta con la libertad de terminar cuando lo desee.

Es tico ofrecer una recompensa por terminar la evaluacin.

Es responsabilidad tuya captar las diversas maneras que puede usar el participante para expresar sus deseos de terminar la evaluacin.

MANTENER EL ANONIMATO

Generalmente, en lugar del nombre del participante se usa un cdigo (por ejemplo, usuario1, P3, etc).

En un lugar separado de los datos del estudio debes almacenar una forma de consentimiento que cuente con los datos del participante.

Cuando menciones los datos obtenidos de la evaluacin, siempre usa el cdigo del participante y no el nombre

CONSENTIMIENTO El concepto del consentimiento informado es

fundamental para todo tipo de evaluacin con participantes humanos. En las evaluaciones de usabilidad, ests obligado ticamente a especificarle al participante:

el tema del experimento

los procedimientos que se utilizaran

la compensacin que recibir

lo que pueden hacer si tienen alguna objecin relacionado con algo de la evaluacin

y debido a que la participacin es voluntaria, tienen la libertad de detenerse y terminar en cualquier momento.

LEYES Existen leyes que regulan las evaluaciones empricas con

humanos tanto en los Estados Unidos como en otros pases del mundo.

Si la evaluacin se est llevando a cabo en otro pas, es responsabilidad tuya determinar las leyes relevantes y la manera de aplicarlas.

Sin embargo, las obligaciones ticas de la participacin voluntaria, la anonimidad y el consentimiento informado que provienen de la actitud de que se est evaluando la interfaz y no al participante, transcienden la ley y se deben mantener aunque el trabajo sea exento de los reglamentos gubernamentales.

CMO CONDUCIR UNA EVALUACIN DE USABILIDAD EN

VOZ ALTA3.2

PASOS PARA CONDUCIR UNA EVALUACIN DE USABILIDAD EN VOZ

ALTA1. Define la estructura de la evaluacin,

2. Selecciona los aspectos a observar,

3. Prepara el examen de usabilidad de pensamiento en voz alta,

4. Introduce a los participantes al procedimiento de observacin,

5. Conduce la observacin,

6. Analizando la observacin,

7. Busca las posibles modificaciones en el diseo, y

8. Escribe la documentacin.

DEFINICIN DE LA ESTRUCTURA DE LA

EVALUACIN El equipo de desarrollo debe definir el propsito del

sistema y la observacin de la usabilidad. A continuacin se enumeran las preguntas que el equipo de desarrollo debe contestar. :

Cul es el problema que el sistema intenta resolver?

Qu tipo de trabajo apoya?

Las respuestas a estas preguntas te ayudar a seleccionar el tipo de evaluacin.

PREGUNTAS Cul es el nivel de ayuda que recibirn los usuarios - en

cuanto a entrenamiento para utilizar el sistema, documentacin, ayuda en-linea, u otros recursos?

La respuesta te ayudar a desarrollar el material y las tareas. Tambin te ayudar el contar con una situacinrealista.

Qu tipos de uso deseamos evaluar con los exmenes de usabilidad? Primer contacto con el sistema, sin uso de manuales? Usuarios con experiencia en cierta tarea pero que usan este sistema particular por primera vez? Uso exploratorio sin presiones de tiempo o uso orientado a un objetivo con lmite de tiempo? Otros aspectos?

La respuesta a estas preguntas ayudarn a especificar las tareas, los participantes y la definicin de lo que se considera un problema en el sistema.

PREGUNTAS Cuales son las metas de uso del sistema?

Que el 90% de los usuarios puedan lograr una tarea sencilla en 3 minutos o menos sin entrenamiento previo?

Que el 50% de los usuarios entrenados para el uso del sistema desempeen cada tarea con menos de un error recuperable?

Las respuestas a estas preguntas te ayudar a elegir las tareas y a definir el criterio para la identificacin de los problemas y las caractersticas positivas del sistema.

SELECCIN DE LOS ASPECTOS A OBSERVAR

El Contenido de las Tareas

La Necesidad de Entrenamiento para Realizar las Tareas

El Tiempo Requerido Para Realizar las Tareas

La Integracin de Varias Tareas Pequeas

EL CONTENIDO DE LAS TAREAS la evaluacin debe incluir las tareas que se llevan a

cabo con ms frecuencia.

As tambin, debes incluir tareas de todas las reas del sistema, para que se evalen todas sus partes.

Asegrate de incluir tareas que eliminan y/o modifican datos, no solo tareas que agregan datos nuevos. Es recomendable incluir tareas de recuperacin de errores.

Tambin debes incluir tareas que representen casos aislados pero importantes

LA NECESIDAD DE ENTRENAMIENTO PARA

REALIZAR LAS TAREAS

Si el conjunto de tareas seleccionadas para la evaluacin requieren de algn tipo de entrenamiento, dicho entrenamiento debe formar parte del conjunto de tareas.

Esto te permite la evaluacin del material de entrenamiento, ya sea un manual, una pagina de web, una conferencia o un tutorial en lnea.

EL TIEMPO REQUERIDO PARA REALIZAR LAS TAREAS

no se les puede pedir a los usuarios que trabajen por ms de dos horas diarias.

La evaluacin debe estar diseada para llevarse a cabo en sesiones de dos horas con un receso despus de cada hora. Esto incluye el entrenamiento.

Si el entrenamiento se realiza un da y la tarea se hace al da siguiente, es necesario dar un repaso al principio del segundo da.

LA INTEGRACIN DE VARIAS TAREAS PEQUEAS

Es importante que la evaluacin sea lo suficientemente larga para incluir diversas caractersticas del sistema. (Insertar, Modificar, Eliminar, etc).

Tambin puedes incluir tareas que evalan la integracin del sistema con otros sistemas que utilizan. Cmo pueden agregar esos resultados a un email? A una pagina de web? Cmo puede alguien enviar informacin para tu sistema a travs de un email?

PREPARACIN PREVIA A LA OBSERVACIN

Antes de realizar las sesiones de pensamiento en voz alta, debemos previamente preparar el ambiente y ciertos documentos, entre ellos los siguientes:

Crear un Ambiente Real para la Recopilacin de Datos

Redactar la Tarea a Realizar

Realizar un Ejercicio de Prctica de la Sesin

Reclutar Usuarios

INTRODUCCIN DEL PROCEDIMIENTO A LOS

PARTICIPANTES Durante el primer encuentro con el participante que

va a realizar la observacin, debes darle la suficiente informacin como para que l se sienta cmodo llevando a cabo la prueba de pensamiento en voz alta y tu obtengas la mejor calidad de datos. Para esto, :

debers explicarle el propsito del estudio,

como pensar en voz alta y dedicar tiempo para practicar la tcnica y

explicar las reglas de la observacin.

DESCRIBE EL PROPSITO DEL ESTUDIO EN TRMINOS

GENERALES Introduccin personal (nombre y ttulo).

Introduccin de la organizacin para la que trabajas y su propsito

Menciona el objetivo del estudio

Declara que lo estas evaluando es el sistema computacional, no estas evaluando al usuario.

Asegrales que su participacin es voluntaria y que pueden interrumpir la evaluacin en cualquier momento.

Otrgale al participante la forma de consentimiento, dales tiempo para leerla y pdele su firma

En caso de que vayas a llevar a cabo la evaluacin en un saln equipado, mustrale al participante el equipo, explcale lo que hace cada componente y mustrale como usar los que tiene que usar el.

Mustrale al participante la manera en que vas a grabar su voz y sus acciones.

LLEVA A CABO UN ENTRENAMIENTO CON EL

USUARIO SOBRE COMO "PENSAR EN VOZ ALTA

A los participantes se les deber entrenar sobre cmo pensar en voz alta mientras trabajan. Al principio parecer un poco absurdo, as que te recomendamos que practiquen haciendo cosas diferentes a las que quieres observar en el sistema

EXPLICA LAS REGLAS DE LA OBSERVACIN

Cuando el participante se sienta cmodo pensamiento en voz alta, ests casi listo para seguir a la fase de observacin de la evaluacin de usabilidad. Justo antes de esta fase, explica las siguientes "reglas" de la observacin.

No podrs contestar preguntas durante la observacin.

De todas formas, deben hacerte preguntas. Tu compromiso consiste en anotarlas y contestarlas al final de la observacin.

Si el participante guarda silencio por ms de 10 segundos, le pedirs que contine hablando.

Despus de explicar estas reglas, pregntale al participante si tiene alguna pregunta sobre el procedimiento de pensar en voz alta o de cualquier otra cosa hasta el momento.

CONDUCCIN DE LA OBSERVACIN

Presenta la Fase de Observacin

Da Inicio a la Observacin

Concluye la Observacin

PRESENTA LA FASE DE OBSERVACIN

Empieza describiendo el sistema que vas a evaluar. Explcale al participante todas las caractersticas del sistema que consideras que conocern ya los usuarios reales.

Contina explicndole a los participantes las tareas que quieres que hagan (verbalmente y en papel).

Ahora pregntale al participante si tiene alguna duda sobre el propsito del estudio, los procedimientos, el producto o la tarea.

DA INICIO A LA OBSERVACIN

Siempre debes de estar al tanto del progreso del usuario mientras trabaja. Si deja de hablar por 5 o 10 segundos, di "Por favor siga hablando". No elabores mas a esta simple frase. No digas "Que ests pensando?" o "Por favor explica lo que haces" porque cualquier frase ms del simple " Por favor contina hablando

Si el usuario empieza a explicar sus procedimientos en vez de solo decir lo que est pensando al trabajar, no lo dejes continuar y di "Por favor no trate de explicarme lo que hace. Acte como si estuviera solo, hablando consigo mismo mientras soluciona el problema."

CONCLUYE LA OBSERVACIN

responde las preguntas que apuntaste en caso de que el usuario tenga an la duda

Responde a lo que puedas o ponlo en contacto con alguien quien le pueda contestar.

Pregntale al usuario su opinin respecto al producto que acaba de usar. Pregntale si tiene sugerencias sobre lo que puede hacer la compaa para mejorar el producto.

Agradcele al participante su ayuda. Recurdale que su participacin te ayudar a identificar problemas con el sistema para que tu compaa los pueda arreglar.

ANALIZANDO LA OBSERVACIN Establecer los Criterios para los Incidentes Crticos

Criterio que puede usarse para identificar problemas

Criterio que puede usarse para identificar caractersticas positivas

El usuario tarda ms de tres minutos en terminar una tarea (entonces el que hace el experimento le explica que hacer).

El usuario te dice que una caracterstica tiene un efecto positivo o que es fcil de usar.

El usuario verbaliza una meta, realiza varios intentos y despus se da por vencido.

El usuario muestra una expresin de agrado.

El usuario verbaliza una tarea, y tiene que llevar a cabo ms de tres actividades para encontrar la solucin.

Algn analisis previo(por ejemplo una evaluacin heurstica) alerta la presencia de un problema de usabilidad, pero el usuario no tiene problemas con ese aspecto del sistema.

El usuario no puede hacer la tarea. Lo que hizo el usuario es diferente a lo que se pidi.

El usuario mostr una reaccin de angustia.

El usuario te dice que algo tiene un efecto negativo or que hay un problema.

El usuario hace una sugerencia para el diseo.

OBSERVAR EL COMPORTAMIENTO

GRABADO Y ESCRIBIR EL UAR Al ver el comportamiento del video y escuchar los datos

que indican que un aspecto de la interfaz cumple con cierto criterio, desarrolla con un nuevo UAR como hiciste con los UAR HE.

Asgnale un nombre a cada identificador UAR y define si es un problema o una caracterstica positiva.

Asgnale un nombre corto.

Cuando termines de escribir el UAR, revisa los dems UAR para encontrar las relaciones existentes.

EVIDENCIA PARA EL ASPECTO

La evidencia para un incidente crtico en una evaluacin de pensamiento en voz alta incluye el comportamiento del participante:

lo que el usuario dijo e hizo (palabras escritas, hizo click en un boton, etc.)

lo que el usuario pudo haber visto, lo que apareca en la pantalla cuando sucedi el incidente. (Ntese que aunque algo apareci en la pantalla NO significa que el usuario lo vi.)

la "evidencia" incluye "solamente lo que se puede ver" y NO la interpretacin de lo que pas

EVIDENCIA PARA EL ASPECTO

Generalmente, la evidencia iniciar con el enunciado del objetivo del usuario.

Es mucho ms fcil saber si la interfaz le ayud o no al usuario si hay evidencia que indica lo que el usuario trataba de hacer.

Muchas veces sabes lo que el usuario quiere hacer cuando dice frases como las siguientes "Quisiera encontrar..." o "Ahora, vamos a ver si..." o "Ahora tengo que..."

A veces, el enunciado del objetivo ocurre antes de que suceda el incidente crtico pero lo vas a incluir en la seccin de evidencia aunque no est seguida del incidente porque sirve como contexto para la actividad. Este contexto es necesario para poder entender lo que sucede.

EVIDENCIA PARA EL ASPECTO

debes mencionar qu impacto tienen estas acciones en el usuario.

Dicho impacto aparece como screen shots o descripciones de lo que sucedi en la pantalla y con el sistema. A veces las acciones del usuario tienen efectos secundarios que no se pueden observar en la pantalla. En este caso, incluye una descripcin, como parte de la evidencia.

EXPLICACIN DEL ASPECTO la explicacin representa la hiptesis sobre lo que el usuario

vi, interpret, entendi, o adivin mientras estaba realizando las tareas y se encuentran en el espacio de evidencia.

Esta explicacin viene del comportamiento observado que incluyes en el espacio de evidencia, del entendimiento del conocimiento que ya tena el usuario, y del entendimiento que t tienes sobre el funcionamiento del sistema.

Esta explicacin determinar las soluciones posibles para los problemas que encuentres.

En ocasiones, una evidencia contar con ms de una explicacin. En estos casos, escribe todas estas explicaciones en el espacio de explicacin

A veces es necesario contar con ms participantes y llevar a cabo tareas ms cortas y ms directas, para poder tener evidencia que ayude a distinguir entre stas explicaciones, y as no necesitars hacer mas investigaciones.

SEVERIDAD DEL PROBLEMA O BENEFICIO DE LAS CARACTERSTICAS

POSITIVAS la severidad puede estar relacionada con el criterio

utilizado para identificar un incidente como crtico.

Es ms severo que el usuario se haya dado por vencido y no terminara la tarea que si hubiera demostrado angustia pero hubiera seguido trabajando.

SOLUCIN POSIBLE, INCLUYENDO LOS POSIBLES COSTOS (TRADE-

OFFS) Por lo general, la solucin a un problema de usabilidad llega al

tratar de ayudar directamente al usuario a lograr sus objetivos.

Pregntate a t mismo si el sistema le permite al usuario cumplir sus objetivos y si no es as, por que no? Si es un objetivo razonable, cmo puedes modificar el sistema para que se pueda usar para eso? Si no es un objetivo razonable, qu parte del sistema fue el que gui al usuario a formar dicho objetivo?

A veces el usuario soluciona su propio problema. Anota estas sugerencias y considralas, tal como consideraras cualquier sugerencia de un miembro del equipo de desarrollo. Pero no les des importancia solo porque las hizo un usuario.

RESUMEN DEL REPORTE Si encuentras uno o varios patrones de problemas del

sistema que indican que se necesita un rediseo, se recomienda que te concentres en explicar esos cambios de concepto que son clave y justifcalos con ejemplos basndote en tu informacin.

Si encuentras muchos problemas pequeos, es mejor presentar una lista con los problemas segn su orden de importancia.

El ranking debe contemplar la severidad que piensas que tiene el problema y la cantidad de esfuerzo que piensas que se necesitar para resolver el problema.

La lista debe ordenarse segn la severidad de los problemas, empezando por los problemas ms severos.

NIVELES DE SEVERIDAD

Este aspecto de usabilidad TIENE QUE ser corregido antes de mandar el producto a los usuarios, de no ser as, los clientes no lo van a poder usar.

Este problema de usabilidad DEBE corregirseaunque se tenga que incurrir a algunos recursos para corregirlo.

Se RECOMIENDA corregir estos problemas de usabilidad antes de presentar el producto al mercado - pero solo si se requiere un esfuerzo mnimo para lograrlo (si no es muy costoso corregir la falla).

TRABAJO EN CLASEMultiple Choice Quiz 8 (10 minutos)

Ejercicio 7 (90 minutos)

Practical Quiz 3 (45 minutos)