2. Analizando la observación
• debes analizar la información para encontrar las características
positivas que quieres mantener en las versiones futuras de tu
sistema, los problemas del sistema que quieres corregir, y las
soluciones posibles a esos problemas. Para hacer esto, debes
establecer criterios para saber cuales comportamientos indican
incidentes críticos que se refieren a usabilidad, estudiar todos estos
incidentes en los comportamientos que fueron grabados, y luego
describirlos en los reportes de aspectos de usabilidad (UAR)
correspondientes.
3. Establecer los criterios para los
incidentes críticos
• Es importante que analices cuidadosamente los resultados y
determines cuales son los comportamientos que deben
considerarse como incidentes críticos para el sistema que estás
diseñando. Debes hacerte la siguiente pregunta: "¿Qué aspecto
representa un problema para este sistema?" Nota que la
pregunta es diferente a: "¿Cuales son los problemas?", es una
pregunta más general "¿Cuáles son las causas del problema?" Al
mismo tiempo, debes determinar cuáles son los
comportamientos que indican que existe un aspecto tan bien
diseñado que debe mantenerse igual en la siguiente versión.
• Recuerda que en el análisis de incidentes críticos
definimos los incidentes críticos como
"comportamientos extremos, muy efectivos o nada
efectivos para lograr los fines de la actividad“. Como
no todas las acciones del usuario son "críticas", no es
necesario evaluar cada acción para ver si hay algo que
corregir o que mantener en la siguiente versión del
software.
• El criterio para evaluar si hay
acciones críticas será distinto
según las situaciones de diseño.
4. • El usuario verbaliza una meta, • El usuario tarda más de tres minutos en
realiza varios intentos y terminar una tarea (entonces el que hace
después se da por vencido el experimento le explica que hacer).
• El usuario verbaliza una tarea, y tiene
que llevar a cabo más de tres
actividades para encontrar la
solución.
• El usuario no puede hacer la
tarea. Lo que hizo el usuario es
diferente a lo que se pidió.
• El usuario mostró una
reacción de angustia.
• El usuario hace una
• El usuario te dice que algo sugerencia para el diseño.
tiene un efecto negativo or
que hay un problema.
5. • El usuario te dice que una
• El usuario muestra una característica tiene un efecto
expresión de agrado. positivo o que es fácil de usar.
• Algún analisis previo(por ejemplo una
evaluación heurística) alerta la presencia de
un problema de usabilidad, pero el usuario
no tiene problemas con ese aspecto del
sistema.
6. Observar el comportamiento grabado
y escribir UAR
• Al ver el comportamiento del
video y escuchar los datos que • Cuando termines de escribir el
indican que un aspecto de la UAR, revisa los demás UAR
interfaz cumple con cierto para encontrar las relaciones
criterio, desarrolla con un existentes.
nuevo UAR como hiciste con
los UAR HE. Asígnale un
nombre a cada identificador
UAR y define si es un
problema o una característica
positiva.
7. Evidencia para el aspecto
• Incluyen lo que el usuario dijo e
hizo.
• También debes incluir lo que el
usuario pudo haber visto, lo que
aparecía en la pantalla cuando
sucedió el incidente.
• Recuerda de incluir un apuntador
en esa parte de la grabación para
que puedas volver a ver esta
parte cuando sea necesario.
8. Explicación del aspecto
• representa la hipótesis sobre lo que el usuario vió, interpretó, entendió, o
adivinó mientras estaba realizando las tareas y se encuentran en el espacio
de evidencia. Esta explicación viene del comportamiento observado que
incluyes en el espacio de evidencia, del entendimiento del conocimiento que
ya tenía el usuario, y del entendimiento que tú tienes sobre el
funcionamiento del sistema. La evidencia debe ser consistente con la
evidencia y con el funcionamiento del sistema. Esta explicación determinará
las soluciones posibles para los problemas que encuentres.
9. Severidad del Problema o Beneficio
de las Características Positivas
• puede estar relacionada con el criterio utilizado para identificar un incidente como
crítico. Es más severo que el usuario se haya dado por vencido y no terminara la
tarea que si hubiera demostrado angustia pero hubiera seguido trabajando. Así
como no hay criterio estándar para identificar incidentes críticos porque las
situaciones que se consideran críticas varían entre un diseño y otro, lo que se
considera severo también varía según el diseño. Tendrás que establecer criterios
para medir la severidad dependiendo de la situación de diseño.
10. Solución Posible, Incluyendo los
Posibles Costos
• A veces el usuario soluciona su propio problema.
• Anota estas sugerencias y considéralas, tal como considerarías
cualquier sugerencia de un miembro del equipo de desarrollo.
• los usuarios suelen no saber cuales características servirían en
el largo plazo.
• Las sugerencias que resultan de la evaluación de usabilidad
pueden surgir por una dificultad local y tal vez no cuenten con
el conocimiento suficiente del sistema completo como para
que sean realmente útiles.
