Reporte de Usuabilidad

Mientras observas una interfaz usando las

técnicas que vas a aprender en este
curso, vas a encontrar aspectos en la
interfaz que representan problemas para
los usuarios ( que querrás mejorar en la
siguiente versión) y aspectos que son muy
útiles para los usuarios.
 1. Identificador UAR
● Con el objetivo de que se archive el reporte,
este debe asignar una clave o ID.
● Este identificador se puede formar con números
y letras. Por ejemplo, si Carlos Pérez CP10 o
JT8.
● Seguido de este identificador puedes usar la
palabra "Problema", si el reporte describe un
problema de usabilidad de interfaz, o las
palabras "característica positiva", si describe un
aspecto de la interfaz que consideras debe
permanecer en la siguiente versión.
                   
2. Descripción Breve del aspecto
de Usuabilidad
● Esta descripción será el "nombre" de la
UAR .Asigna el nombre más corto que
puedas (de tres a cinco palabras).
Ejemplo :
UAR de la siguiente manera "etiqueta
Press-Me muy pequeña" (que señala el
problema) y no "etiqueta Press-Me debe
ser de 24 puntos" (que es una posible
solución y no el problema).
 3. La evidencia de un aspecto
(Lo persive el autor)
● Este es el material de soporte objetivo que
justifica el aspecto que identificaste y especifica
que merece un reporte.
● Esta sección debe contener la información
suficiente para que la persona que lea este UAR
comprenda.
● Para un reporte HE, por ejemplo, las evidencias
pueden consistir en una imagen que represente
desorden y la heurística que habla de diseño
estético y minimalista.
 3. La evidencia de un aspecto
● O puede consistir en una lista de
elementos de menú que no tienen un atajo
y la heurística que habla de incluir atajos.
● En un estudio de pensamiento en voz alta
la prueba consiste, por lo general de lo
que se ve en pantalla ( una impresión de
la pantalla o una descripción), las
acciones que realizó el usuario (teclado,
movimientos de mouse),
 4. La explicación de un Aspecto
(Objetiva)
● Esta es la interpretación de la evidencia. Es la
razón por la cual pasó lo que pasó.
● Se pueden incluir leyendas como: "la etiqueta
del botón XYZ, es un término de programación
estándar, pero el usuario, al parecer, no estaba
familiarizado con este término"
● Debes proveer suficiente contexto en esta
explicación para que la persona que lo lea
comprenda el problema—aún y cuando no
conozca el sistema y no lo domine al grado que
tu lo dominas.
5. La severidad del problema o el beneficio
de una característica positiva
● Aquí debes especificar, según tu razonamiento,
el grado de importancia que tiene este problema
para que se resuelva o para mantenerlo como
característica positiva.
● Aquí puedes incluir información referente a la
frecuencia con la cual se le presentará al
usuario, si acaso crees que aprenda el usuario
como funciona este problema, si crees que el
problema le afecta más a los usuarios nuevos,
no frecuentes o con experiencia, entre otros.
 6. Las posibles soluciones y los
costos potenciales
● Si el aspecto representa un problema es donde
se debe proponer una solución. No es necesario
contar con una solución al momento que
identificaste un problema—podrá darse el caso
en que después de analizar toda la interfaz,
muchos problemas estén relacionados y se
puedan solucionar todos haciendo algunos
cambios generales.
● Sin embargo, si propones alguna posible
solución, documenta cualquier costo potencial
de diseño.
 7. La relación que tiene con otros
aspectos de usabilidad
● Muchas veces los UARs están relacionados
entre sí.
● Aquí es donde se documenta con cual UAR está
relacionado cada uno y un breve enunciado que
indica la forma en que está relacionado.
● Ejemplo: Si el UAR #1 está relacionado con el
UAR #30, el UAR #30 debe indicar en esta
sección, la relación que tiene con UAR #1 y el
UAR #1 debe indicar la relación que tiene con la
UAR #30.