Evaluacin Heurstica

Mara Paula Gonzlez, Jess Lors, Afra Pascual

Objetivos 2
1. Introduccin 2
2. Definicin de Evaluacin Heurstica 3
3. El concepto de Principio Heurstico 4
4. Pasos de una Evaluacin Heurstica 26
5. Conclusiones 35
Referencias 35
Objetivos
Este captulo tiene como objetivo:
Introducir a la metodologa de la Evaluacin Heurstica
Presentar el concepto de Principio Heurstico desde una amplia base
bibliogrfica
Describir los pasos de una Evaluacin Heurstica
Brindar un ejemplo prctico de una Evaluacin Heurstica

1. Introduccin
Este Captulo presenta un mtodo de evaluacin de la usabilidad por inspeccin
denominado Evaluacin Heurstica. La Evaluacin Heurstica consiste en verificar la
calidad de una serie de principios llamados Principios Heursticos o simplemente
"heursticas previamente establecidos. Es llevada a cabo por evaluadores expertos
en usabilidad que actan imitando las reacciones que tendra un usuario promedio
al interactuar con el sistema que se este evaluando. A continuacin, la Seccin 2
presenta a la Evaluacin Heurstica definindose el concepto de heurstica y
describindose las principales caractersticas, el objetivo y la potencialidad de esta
metodologa. Se presentan las principales ventajas y desventajas de esta
metodologa y se muestran contradicciones encontradas en diversos autores en
cuanto a su eficiencia y su efectividad. Seguidamente, la Seccin 3 detalla el
concepto de Principio Heurstico y presenta distintas corrientes metodolgicas que
plantean fundamentos tericos alternativos y complementarios para su definicin. A
continuacin, la Seccin 4 describe los diferentes pasos incluidos en una Evaluacin
Heurstica: su Planificacin, su Puesta en Marcha y por ltimo, el Anlisis de los
resultados obtenidos tras la inspeccin.

En relacin a la Planificacin de una Evaluacin Heurstica, en la Seccin 4.1 se
discute el tipo de perfil y la cantidad de evaluadores ptimos segn distintas
corrientes bibliogrficas estudiadas. Tambin se describe el proceso de traduccin
que permite transformar a los Principios Heursticos generales presentados en la
Seccin 2 en preguntas heursticas adecuadas para la evaluacin de la interfaz de
un sistema interactivo particular. Se plantea la importancia de establecer tambin
la escala de valores que se utilizar para la posterior ponderacin de cada pregunta
heurstica considerando a esta seleccin desde el punto de vista de la llamada
Usabilidad Transcultural. Al final de la Seccin 4.1 se detalla que tipo de
documentacin debera obtenerse al concluir esta etapa de la Evaluacin Heurstica
enfatizndose las ventajas de contar con plataformas de software que acten como
gestores de todo el proceso posterior. A modo de ejemplo, el software UsabAIPO-
GestorHeurstica es presentado y descrito. Con respecto a la Puesta en Marcha de
una Evaluacin Heurstica, la Seccin 4.2 analiza los pasos sugeridos por los
creadores de la metodologa. Se enfatiza la importancia de minimizar la influencia
de factores externos en el proceso de inspeccin y se detalla que tipo de
actividades sern seguidas por cada uno de los evaluadores involucrados. En
cuanto al Anlisis de resultados de la Evaluacin Heurstica, la Seccin 4.3 describe
el procesamiento cuantitativo y cualitativo al que pueden someterse los datos
obtenidos. En este sentido se entiende a ambos tipos de procesamiento como
complementarios y no excluyentes. Finalmente, la Seccin 5 presenta las
conclusiones de este Captulo.

2. Definicin de Evaluacin Heurstica

La palabra heurstica procede etimolgicamente de la palabra griega "euriskein
que procede de "eureka, un vocablo que significa hallar o encontrar. Este vocablo
fue exclamado por Arqumedes en un famoso episodio sin bases histricas. El
diccionario de la Real Academia Espaola define a la palabra "heurstica como:
Tcnica de la indagacin y del descubrimiento.
Busca o investigacin de documentos o fuentes histricas.
En algunas ciencias, manera de buscar la solucin de un problema
mediante mtodos no rigurosos, como por tanteo, reglas empricas, etc.

Partiendo de la definicin anterior, la Interaccin Persona Ordenador (IPO) presenta
a la Evaluacin Heurstica (EH) como un mtodo de evaluacin de la usabilidad por
inspeccin que debe ser llevado a cabo por evaluadores expertos a partir de unos
principios (denominados "heursticos) previamente establecidos. Por ser una
tcnica de evaluacin de la usabilidad, la EH tiene como objetivo el medir la calidad
de la interfaz de cualquier sistema interactivo en relacin a su facilidad para ser
aprendido y usado por un determinado grupo de usuarios en un determinado
contexto de uso [ISO98, UNET06].

La metodologa de la EH fue presentada inicialmente por Nielsen y Molich [MOL90].
Esta metodologa consiste en analizar la conformidad de la interfaz con unos
principios reconocidos de usabilidad (la "heurstica) mediante la inspeccin de
varios evaluadores. Los autores [MOL90] solo plantearon que los evaluadores
deberan poseer algn conocimiento sobre los principios de la usabilidad. Ms tarde,
autores como [JEF91] postularon que la EH sera ms efectiva cuando los
evaluadores fueran expertos en usabilidad. Cabe destacar que estos evaluadores
intentan ponderar a la interfaz que esta siendo evaluada en funcin de lo que creen
que ser la percepcin de usuarios de distintos perfiles. Es por ello que frente a
otros mtodos que enfatizan la realizacin de tareas (como es el caso del mtodo
del Recorrido Cognitivo [WRLP94, GPL04]), la EH inspecciona problemas
potenciales, ya que el evaluador predice los errores que el usuario real podr tener
cuando interaccione con la interfaz del sistema que se esta evaluando.

Una caracterstica fundamental de la EH es su bajo coste, aunque el mismo puede
variar dependiendo del nmero de evaluadores que se incluya en el proceso. Varios

autores sostienen que la EH es barata, intuitiva y que esto motiva a la gente a
utilizarla [MOL90, MUL98, LAI04]. De hecho, la EH no requiere una larga
planificacin para realizarse y puede usarse en las etapas iniciales del proceso de
desarrollo de sistemas, siempre que se disponga de un prototipo a evaluar. Segn
[NIE94], el mtodo de la EH detecta aproximadamente un 42 % de los problemas
graves de diseo y un 32 % de los problemas menores, dependiendo del nmero
de evaluadores que revisen el sitio. Sin embargo, segn nuestra opinin, este tipo
de afirmaciones no pueden sostenerse en la actualidad, ya que la Ingeniera de la
Usabilidad ha avanzado considerablemente en la ltima dcada, por lo que el
contexto actual es mucho mas favorable que el que poda observase en el ao 1994
(ms conocimiento sobre la metodologa de la EH, ms madurez y experiencia en la
evaluacin de la usabilidad, nuevos modelos de desarrollo de sistemas propios de la
Ingeniera de la Usabilidad, evaluadores ms capacitados, ms fuentes
bibliogrficas, mayor madurez cientfica y metodolgica en la disciplina de la IPO).

En realidad, la potencialidad de la EH para detectar problemas de usabilidad en un
determinado sistema interactivo depende en gran medida de las heursticas que se
hayan definido para efectuar la inspeccin de la interfaz de dicho sistema
interactivo [DR99]. A continuacin se presenta en ms detalle el concepto de
heurstica detallndose brevemente distintas corrientes metodolgicas que plantean
fundamentos tericos alternativos y complementarios para su definicin.

2.1. Ventajas y Desventajas de la
Evaluacin Heurstica

La EH ha sido presentada por J. Nielsen como un mtodo de la denominada
Ingeniera de la Usabilidad de Descuento (Discount Usability Engineering) en
[Nie99]. En este trabajo Nielsen defiende que la EH es menos costosa que otros
mtodos para la evaluacin de la usabilidad ya que requiere, relativamente, pocos
recursos y disminuye el costo asociado a la produccin de software. En general, las
principales ventajas y desventajas de la EH son las siguientes (informacin basada
en material encontrado en la web "Usability Body of Knowedge, consultada en julio
del 2006 en http://www.usabilitybok.org/methods/p275):

Ventajas de la Evaluacin Heurstica:
Es econmica en comparacin con otros mtodos de evaluacin de la
usabilidad [NIE90]
Es intuitiva y es fcil motivar a los evaluadores potenciales a que la
utilicen[NIE90]
No requiere planificacin por adelantado [NIE90].
Los evaluadores no necesitan ser expertos en usabilidad. Por ejemplo, en
[NIE90] y [NIE92] se presentan EH realizadas por profesionales de las
Ciencias de la Computacin como programadores y estudiantes de
Informtica.
Puede ser utilizada en etapas tempranas del proceso de desarrollo de
sistemas, siempre que se cuente con un prototipo a evaluar [NIE90].
Tiempo de procesamiento menor que los teste de laboratorio [KR97].
Cabe destacar que esta ltima ventaja puede disminuir su importancia
debido a los avances y mejoras en las metodologas de evaluacin de la
usabilidad con testeos de laboratorio que se han producido desde el ao
1997 a la fecha.

Desventajas de la Evaluacin Heurstica:
Segn la descripcin original de la metodologa propuesta en [NIE90], los
evaluadores deben conocer los principios de la usabilidad. Pero ms
tarde, J. Nielsen prob que los evaluadores expertos en usabilidad
detectaba mayor cantidad de problemas de usabilidad que los no
expertos, y que los evaluadores "doblemente expertos (expertos en
usabilidad que adems poseen experticia en el contexto de uso al cual
pertenece el sistema que se desea evaluar) detectan an mayor cantidad
de problemas de usabilidad [NIE92]. Esto supone una desventaja por la
alta capacitacin requerida para los evaluadores si se desea optimizar la
deteccin de problemas de usabilidad con la metodologa de la EH.
Es recomendable que la EH sea realizada por mas de un evaluador
porque una sola persona no detectar la totalidad de los problemas de
usabilidad del sistema que se esta evaluando [NIE90]
La EH puede no identificar tantos atributos relacionados con la usabilidad
como otras metodologas, por ejemplo las metodologas por testeo
[NIE89]. Sin embargo, en nuestra opinin esta desventaja tambin esta
presente en otras metodologas y puede minimizarse si se estructura a
los pasos de la EH tal como se muestra en la Seccin 4.
La EH puede identificar mayor cantidad de problemas de usabilidad
menores y menor cantidad de problemas de usabilidad mayores que la
mitologa del Thinking-Aloud [JD92].
La EH puede resultar difcil de ejecutar si la interfaz que se evala es
muy compleja. En este tipo de interfaces un grupo pequeo de
evaluadores no puede detectar la mayora de los problemas de usabilidad
de alta importancia [SC99]
La EH no siempre sugiere de manera fcil o clara soluciones para las
caractersticas que son identificadas. Adems, debe tenerse en cuenta el
sesgo asociado a la subjetividad de los diferentes evaluadores [NIE90]
En una EH tradicional los evaluadores solo emulan el comportamiento de
los usuarios son usuarios reales [KR97]
La EH puede tender a reportar falsas alarmas (problemas que son
detectados en la aplicacin pero que no corresponden en realidad a
problemas de usabilidad) [JEF94]

A pesar de que las principales ventajas y desventajas de la EH han sido
ampliamente discutidas por autores, se observa un cierta falta de consenso en
varios de los trabajos consultados. A continuacin presentaremos cuatro ejemplos
que se muestran en la web "Usability Body of Knowedge (consultada en julio del
2006 en http://www.usabilitybok.org/methods/p275). Un primer ejemplo que
ilustra tras contradicciones relacionadas con las ventajas y desventajas de la EH se
presenta en [JMWU91]. En este trabajo los autores comparan la efectividad de
diferentes mtodos de evaluacin incluyendo a la EH. Primeramente, estos autores
postulan que la EH identifica ms problemas de usabilidad que otras metodologas
incluidas en su estudio (como los Test de Usabilidad, las Guas de Revisin o los
Recorridos Cognitivos) si los resultados de cada uno de los evaluadores (a los
cuales considera solo como personas con experiencia en usabilidad en
contraposicin con la metodologa original presentada en [NIE90]) son comparados
y compilados en un solo informe de usabilidad (tal como se propone en la Seccin

4.3 del presente Captulo). Sin embargo, ms adelante los autores sostienen que
aunque la EH detecte mas problemas de usabilidad que los Test de Usabilidad, la
severidad de los problemas detectados con la EH es menor que la severidad de
aquellos detectados con los Test de Usabilidad.

Un segundo ejemplo puede observase en [DKA92]. En este caso, los autores
muestran que los evaluadores expertos identifican ms problemas de usabilidad
que los evaluadores no expertos, y que los evaluadores "doblemente expertos
[NIE92] an detectan ms problemas de usabilidad que los expertos. Sin embargo,
mas adelante explican que incluir evaluadores "doblemente expertos es demasiado
costoso por lo que recomiendan la inclusin de evaluadores expertos sin especificar
el decremento en la efectividad de la metodologa. Un tercer ejemplo ms actual
puede verse en [CW02]. En este tercer caso, los autores revisan las metodologas
de la Ingeniera de la Usabilidad de Descuento desde el punto de vista del costo-
beneficio. Por un lado, estos autores sealan que los problemas reales de
usabilidad de un determinado sistema se detectan a partir de una compleja
interaccin entre un usuario y ese sistema. En este sentido, el trabajo de [CW02]
sostiene que los mtodos de descuento, como la EH, son demasiado simples para
evaluar de manera adecuada esa compleja interaccin. Contradictoriamente, en el
mismo trabajo se concluye que los mtodos de descuento son tan buenos para
detectar errores de usabilidad que sus beneficios sobrepasan de sobremanera a sus
costos.
Finalmente, un cuarto ejemplo que ilustra tras contradicciones relacionadas con las
ventajas y desventajas de la EH se presenta en[MDJ05]. En este trabajo se
comparan diferentes metodologas de evaluacin de la usabilidad (entre ellas la EH)
aplicadas al sitio web del Hotel Pennsylvania en Nueva York (www.hotelpenn.com)
durante el ao 2003 por 17 equipos de evaluacin de la usabilidad diferentes. Uno
de los 17 equipos utiliz la tcnica tradicional de la EH tal como se presenta en
[NIE90]. Dentro de las conclusiones de [MDJ05] se sostiene que: a) no se
produjeron falsas alarmas en relacin a los problemas de usabilidad detectados por
los evaluadores, conclusin que se contradice con la afirmacin dentro del mismo
trabajo que advierte sobre las falsas alarmas provocadas por la EH y; b) los
evaluadores expertos identificaron la misma proporcin de problemas de usabilidad
muy severos y poco severos que los Testeo de Usabilidad, conclusin que se
contradice con la afirmacin anteriormente indicada en el mismo trabajo acerca de
la mayor eficiencia de las evaluaciones realizadas por expertos sobre la menor
eficiencia de las evaluaciones realizadas por medio de un testeo.
3. El concepto de Principio Heurstico

La Heurstica, tambin conocida como denominada Principio Heurstico (PH) o
criterio heurstico, trata de aplicar normas conversacionales a la interaccin entre
una persona a un sistema: su objetivo es intentar crear un "puente comunicacional
en el que tanto la persona como el sistema se entiendan y trabajen juntos en pos
de un objetivo a alcanzar. Estas reglas empricas generales son utilizadas dentro de
la planificacin de una HE como punto de partida para la creacin de una lista de
comprobacin de tems que posteriormente utilizar el evaluador experto dentro de
la puesta en marcha de la evaluacin. De esta manera, esas reglas generales son
adecuadas a cada caso concreto de evaluacin para reflejar en los tems a evaluar
la naturaleza y tipo de interfaz a evaluar y el contexto de uso de la misma. Los PHs
pueden servir para varios propsitos:

Guan a diseadores durante el proceso de diseo.
Ayudan a los evaluadores a identificar problemas en las interfaces de
usuario, comprobando que las reglas de usabilidad se respeten.
Explican problemas de usabilidad observados,
Dan pautas sobre porqu los usuarios cometen determinados errores.

Muchos autores han publicado PH para interfaces de usuario. En el ao 1986
Schneiderman public las "ocho reglas de oro del diseo de interfaces y
posteriormente diversos autores desarrollaron listados similares de PHs basados en
problemas observados de usabilidad. A continuacin se detalla en orden cronolgico
una seleccin de los ms relevantes:

3.1. Las 8 reglas de oro de Ben Schneiderman

En el ao 1986, Ben Schneiderman presenta sus "Ocho reglas de oro para el diseo
de Interfaces (Por ms informacin consultar en http://www.cs.utexas.edu/
users/almstrum/cs370/elvisino/rules.html). En la actualidad, esas ocho reglas de
oro son entendidas como PHs generales que pueden guiar tanto el diseo como la
evaluacin de la usabilidad de un sistema interactivo. Es evidente que, tal como se
explica anteriormente, para llevar a cabo una EH concreta deben traducirse estas
ocho reglas de oro a una lista de tems plausibles de ser evaluados en relacin a
una determinada interfaz concreta. Las ocho reglas de oro de Schneiderman son:

Esforzarse por la consistencia: Las secuencias constantes de acciones se
deben repetir en situaciones similares; la misma terminologa se debe
utilizar en avisos, mens, y pantallas de la ayuda; y los comandos
constantes se deben emplear en todas partes del mismo modo.
Crear atajos para los usuarios frecuentes: cuando la frecuencia de uso
aumenta, los usuario agradecen reducir el nmero de interacciones. Las
abreviaturas, los comandos ocultos, y las macro son muy tiles para un
usuario experto.
Ofrecer feedback: Para cada accin del usuario, debe haber una cierta
regeneracin del sistema. Para las acciones frecuentes y de menor
importancia, la respuesta puede ser modesta, mientras que para las
acciones infrecuentes e importantes, la respuesta debe ser ms substancial.
Disear el dilogo para mostrar trabajo pendiente: Las secuencias de
acciones se deben organizar en grupos con un inicio, un medio y un final. La
regeneracin informativa en la terminacin de un grupo de acciones da a
usuarios la satisfaccin de la realizacin, y una indicacin clara para
prepararse para el grupo siguiente de acciones.
Ofrecer una gestin sencilla de los errores: Tanto como sea posible, el
sistema ha de estar diseado para que el usuario no puede causar un error
grave. En el caso que ocurra un error, el sistema debe poder detectar el
error, y ofrecer mecanismos para poder recuperarse o manejar el error.
Permitir una fcil recuperacin de acciones: Esta caracterstica ofrece
tranquilidad al usuario, puesto que sabe que los errores pueden ser
deshechos; anima as la exploracin de opciones desconocedoras. La
recuperacin puede ser una sola accin, una entrada de datos, o un grupo
completo de acciones.
Soportar el control por el usuario: Los usuarios experimentados desean
tener el control total del sistema y que el sistema responda a sus acciones.
El diseo del sistema debe responder a las acciones del usuario, y que estos

sean los iniciadores de las acciones, no solo los que respondan a acciones
del sistema.
Reducir la carga de memoria reciente en el usuario: La limitacin
humana del tratamiento de la informacin en memoria a corto plazo requiere
que lo que se muestra por pantalla sea simple.

3.2. Principios heursticos de Molich y Nielsen

En el ao 1990 R. Molich y J. Nielsen acuaron una serie de PHs a los que
denominaron "heursticas [NIE90b, MOL90]. Cuatro aos ms tarde, J. Nielsen
presenta un conjunto minimal de heursticas de mximo poder expresivo, el cual se
basa en los trabajos originales realizados con R. Molich y en la observacin de de
249 problemas de usabilidad pertenecientes a proyectos de Diseo Centrado en el
Usuario que J. Nielsen presenta en [NIE94a]. Ese conjunto minimal de PHs
generales fueron publicados en [NIE94] y sus elementos se presentan a
continuacin:
1. Visibilidad del Estado del Sistema. El sistema debe siempre
mantener a los usuarios informados del estado del sistema, con una
realimentacin apropiada y en un tiempo razonable.
2. Lenguaje de los Usuarios. El sistema debe hablar el lenguaje de
los usuarios, con las palabras, las frases y los conceptos familiares,
en lugar de que los trminos estn orientados al sistema. Utilizar
convenciones del mundo real, haciendo que la informacin aparezca
en un orden natural y lgico.
3. Control y libertad para el Usuario. Los usuarios eligen a veces
funciones del sistema por error y necesitan a menudo una salida de
emergencia claramente marcada, esto es, salir del estado indeseado
sin tener que pasar por un dilogo extendido. Es importante disponer
de deshacer y rehacer.
4. Consistencia y Estndares. Los usuarios no deben tener que
preguntarse si las diversas palabras, situaciones, o acciones
significan la misma cosa. En general siga las normas y convenciones
de la plataforma sobre la que se est implementando el sistema.
5. Ayuda a los Usuarios para Reconocimiento, Diagnstico y
Recuperacin de errores. Que los mensajes de error se deben
expresar en un lenguaje claro (no haya cdigos extraos), se debe
indicar exactamente el problema, y deben ser constructivos.
6. Prevencin de Errores. Es importante prevenir la aparicin de
errores que mejor que generar buenos mensajes de error.
7. Reconocimiento antes que Cancelacin. El usuario no debera
tener que recordar la informacin de una parte de dilogo a la otra
Es mejor mantener objetos, acciones, y las opciones visibles que
memorizar.
8. Flexibilidad y eficiencia de uso. Las instrucciones para el uso del
sistema deben ser visibles o fcilmente accesibles siempre que se
necesiten. Los aceleradores no vistos por el usuario principiante,
mejoran la interaccin para el usuario experto de tal manera que el
sistema puede servir para usuarios inexpertos y experimentados. Es
importante que el sistema permita personalizar acciones frecuentes.
9. Esttica de dilogos y Diseo minimalista. No deben contener la
informacin que sea inaplicable o se necesite raramente. Cada unidad
adicional de la informacin en un dilogo compite con las unidades
relevantes de la informacin y disminuye su visibilidad relativa.
10. Ayuda General y Documentacin. Aunque es mejor si el sistema
se pueda usar sin documentacin, puede ser necesario disponer de
ayuda y documentacin. sta ha de ser fcil de buscar, centrada en
las tareas del usuario, tener informacin de las etapas a realizar y
que no sea muy extensa.

3.2.1. Aplicacin de los Principios heursticos
de Molich y Nielsen: la lista de comprobacin
de tems de D. Pierotti

El conjunto de PHs presentado en la lista anterior ha sido el punto de partida para
la creacin de numerosas listas de comprobacin de tems (sub-heursticas o sub-
PHs) que luego de ser definidas durante la Etapa de Planificacin de una EH
particular (ver Etapa de Planificacin de una EH en Seccin 4.1) son utilizadas por
los evaluadores expertos dentro de la Puesta en Marcha de la evaluacin (ver Etapa
de Puesta en Marcha de una EH en Seccin 4.2). A modo de ejemplo, presentamos
a continuacin una lista de tems desarrollada por Deniese Pierotti y utilizada por la
empresa Xerox Corporation para evaluar la usabilidad de interfaces
norteamericanas orientadas a la web (ver tems 2.20 y 5.14) mediante la
metodologa de la EH [Pie04]. Cabe mencionar que esta lista agrega a los 10
principios de Nielsen tres PHs ms:

11. Habilidades: el sistema debera tener en cuenta, extender, suplementar
e incentivar las habilidades del usuario, sus conocimientos y su experticia.
12. Interaccin con el Usuario Placentera y Respetuosa: las
interacciones de los usuarios con el sistema deben favorecer la calidad de su
vida. El usuario debe ser tratado con respeto. El diseo debe ser esttico y
placentero, en donde los valores artsticos se igualen a los valores
funcionales.
13. Privacidad: el sistema debe ayudar al usuario a proteger la informacin
personal o privada, tanto la que pertenece al propio usuario como la que
pertenece a los clientes del usuario.

A continuacin se detallas las sub-heursticas (o sub-PHs) definidos por D. Pierotti
tanto para los 10 PHs de Nieslen (puntos 1 al 10 de la siguiente lista) como para los
tres PHs agregados por ella misma (puntos 11 a 13 de la siguiente lista) [Pie04]:

1. tems definidos para PH "Visibilidad del Estado del Sistema":
1.1. Cada parte de la interfaz comienza con un ttulo o encabezamiento
que describa el contenido de la pantalla?
1.2. El esquema de diseo de los conos y su esttica es consistente en
todo el sistema?
1.3. Cuando se selecciona un icono particular rodeado por otros conos,
se distingue el icono seleccionado claramente?
1.4. Los mens de instrucciones, puntos de entrada de datos y mensajes
de error aparecen en el mismo lugar de la pantalla o en el mismo
men?

1.5. En pantallas mltiples para entrada de datos cada pgina esta
etiquetada para mostrar su relacin con las otras?
1.6. Si el sistema provee de los modos de sobre-escritura y de insercin,
hay informacin visible de cul de los dos modos est activado?
1.7. Si se utilizan ventanas emergentes (pop-up) para mostrar mensajes
de error, permiten estas ventanas que el usuario visualice el error
en la interfaz cuando se despliegan?
1.8. Hay algn tipo de "feedback para cada accin u operacin?
1.9. Luego de que usuario completa una accin o un grupo de acciones,
el "feedback del sistema indica que el siguiente grupo de acciones
puede comenzarse?
1.10. El sistema provee algn tipo de "feedback visual en mens o cajas
de dilogo que indiquen las opciones que pueden seleccionarse?
1.11. El sistema provee algn tipo de "feedback visual en mens o cajas
de dilogo que indiquen en cul de las posibles opciones se halla
posicionado el cursor o el puntero del ratn?
1.12. Si hay mens o cajas de dilogo en donde pueden seleccionarse
mltiples opciones, el sistema provee algn tipo de "feedback visual
que indique cules son las opciones que ya han sido seleccionadas?
1.13. Hay algn tipo de "feedback visual cuando los objetos de la interfaz
son seleccionados o movidos?
1.14. Es estado actual de cada icono, es claramente indicado?
1.15. Existe "feedback cuando una tecla de funcin es presionada?
1.16. Si existen demoras mayores a 15 segundos en las respuestas del
sistema, el usuario es informado del progreso en la concrecin de la
respuesta?
1.17. Los tiempos de respuestas son apropiados para cada tarea?
1.18. Tiempo de escritura, movimiento del cursor o seleccin con el ratn:
entre 0,5 y 1,5 milisegundos.
1.19. Tiempo de respuesta de preguntas frecuentes: menos de 1 segundo
1.20. Tareas ms comunes: 2 a 4 segundos
1.21. Tareas complejas: 8 a 12 segundos
1.22. Los tiempos de respuesta del sistema son adecuados al proceso
cognitivo del usuario?
1.23. Necesidad de continuar un mismo proceso de pensamiento donde
cierta informacin debe ser retenida por el usuario: menos de 2
segundos.
1.24. No son necesarios altos niveles de concentracin y no es requerido
retener informacin: 2 a 15 segundos
1.25. La terminologa utilizada en los mens, es consistente con el
dominio de conocimiento del usuario en relacin a la tarea a realizar?
1.26. El sistema provee visibilidad? Es decir, el usuario puede expresar
verbalmente cul es el estado del sistema y que alternativas de
accin posee en un determinado momento?
1.27. Los mens grficos (GUI) muestran de manera obvia cul es el tem
que ha sido seleccionado?
1.28. Los mens grficos (GUI), muestran de manera clara las opciones
que pueden ser deseleccionada?
1.29. Si los usuarios navegan entre diferentes pantallas del sistema, el
sistema utiliza etiquetas conceptuales, mapa de mens o marcas de
navegacin a modo de ayudas para esa navegacin?

2. tems definidos para PH "Lenguaje de los Usuarios":
2.1. Los conos son concretos y familiares para el usuario?
2.2. Dados un determinado usuario, una determinada lista de nombres de
tems y variables para realizar tareas. las opciones en los mens
(nombres de los tems) estn ordenadas en la manera ms lgica
para el usuario?
2.3. Si existe una secuencia natural para la seleccin de elementos en un
men, esta implementada esa secuencia?
2.4. Los campos relacionados e interdependientes, aparecen en la misma
pantalla?
2.5. Si las formas de los objetos de la interfaz son utilizados como pistas
visuales, concuerdan con las convenciones culturales de los
usuarios?
2.6. Los colores seleccionados, corresponden a valores esperados segn
un los cdigos de los usuarios?
2.7. Cuando una tecla o botn virtual para presionar en la pantalla
(prompt) implica una accin necesaria, incluye un mensaje con
palabras consistentes con esa accin?
2.8. Las referencias indicadas en las teclas o botones virtuales de la
interfaz para presionar en la pantalla (prompts), son consistentes
con nombres de teclas reales?
2.9. Cuando se ingresan datos en la pantalla, la terminologa utilizada
para describir la tarea es familiar para los usuarios?
2.10. El sistema provee teclas o botones virtuales de acceso por niveles
(field-level promps) en las pantallas de entrada de datos?
2.11. Cuando la pantalla incluye preguntas que debe ser respondidas, el
lenguaje de esas preguntas es simple y claro?
2.12. Las opciones en los mens, se corresponden lgicamente con
categoras que tengan un significado unvoco?
2.13. Los ttulos de los mens, siguen un mismo estilo gramatical?
2.14. El lenguaje de comandos empleado, utiliza la jerga de los usuarios
evitando el uso vocablos computacionales especficos?
2.15. Los nombres de los comandos, son mas bien especficos antes que
generales?
2.16. El lenguaje utilizado en los comandos, permite utilizar tanto palabras
completas como abreviaturas?
2.17. Son entendibles los cdigos para ingreso de datos?
2.18. Las combinaciones de secuencias de letras extraas o poco
frecuentes, son omitidas siempre que sea posible?
2.19. El sistema ingresa/elimina automticamente espacios en blanco (o
ceros) a fin de alinear cifras con respecto al punto decimal?
2.20. El sistema ingresa de manera automtica los signos de dlar y
decimal cuando se insertan valores monetarios?

2.21. El sistema ingresa de manera automtica comas en valores
superiores a 9999?
2.22. Los mens grficos (GUI) ofrecen activacin? Esto es, es obvia la
manera en que el sistema indica "ahora, haga esto?
2.23. El sistema ha sido diseado de tal manera que las teclas con
nombres similares no ejecuten acciones opuestas (y/o
potencialmente peligrosas?
2.24. Las teclas de funcin estn claramente etiquetadas y se distinguen
con facilidad, an cuando esto implique romper la consistencia en las
reglas?

3. tems definidos para PH "Control y Libertad para el Usuario":
3.1 Si configurar una pantalla es una tarea poco frecuente, es esta tarea
particularmente fcil de recordar?
3.2 En sistemas que permitan el uso de ventanas superpuestas, es fcil
reacomodar (reubicar) esas ventanas en la pantalla?
3.3 En sistemas que permitan el uso de ventanas superpuestas, es fcil
para los usuarios cambiar de una ventana a otra?
3.4 Cuando una tarea efectuada por el usuario se completa, el sistema
espera alguna seal del usuario antes de procesar la tarea?
3.5 Los usuarios pueden escribir por adelantado en un sistema con
muchos mens anidados?
3.6 Se pregunta al usuario que confirme acciones que tendrn
consecuencias drsticas, negativas o destructivas?
3.7 Existe una funcin para "deshacer al nivel de cada accin simple,
cada entrada de datos y cada grupo de acciones completadas?
3.8 Los usuarios pueden cancelar operaciones en progreso?
3.9 La edicin de caracteres est permitida en los comandos?
3.10 Los usuarios pueden reducir el tiempo de entrada de datos copiando
y modificando datos existentes?
3.11 La edicin de caracteres est permitida en los campos de entrada de
datos?
3.12 Si las listas de mens son largas (ms de siete tems), pueden los
usuarios seleccionar un tem tanto moviendo el cursor como
escribiendo un cdigo mnemotcnico?
3.13 Si el sistema utiliza dispositivos de tipo puntero, los usuarios tienen
la opcin tanto de hacer "clic en una lista de tems como de utilizar
atajo usando el teclado?
3.14 Los mens son anchos (muchos tems) antes que profundos (muchos
niveles)?
3.15 Si el sistema posee mens de niveles mltiples, existe algn
mecanismo que permita a los usuarios regresar al men previo?
3.16 Si los usuarios pueden regresar al men previo, pueden tambin
cambiar su eleccin en el men previo nuevamente accedido?
3.17 Los usuarios pueden moverse hacia delante o hacia atrs entre las
opciones de campos o cajas de dilogo?
3.18 Si el sistema posee mltiples pantallas para entrada de datos, los
usuarios pueden moverse hacia delante o hacia atrs entre las
pginas en el conjunto?
3.19 Si el sistema utiliza una interfaz de preguntas y respuestas, pueden
los usuarios regresar a la pregunta anterior o saltear hacia delante
una pregunta?
3.20 Las teclas de funciones que pueden causar serias consecuencias,
poseen una caracterstica para deshacer su accin?
3.21 Los usuarios pueden revertir sus acciones de manera sencilla?
3.22 Si el sistema permite a los usuarios revertir sus acciones, existe un
mecanismo que permita deshacer varias acciones de manera
simultnea?
3.23 Los usuarios pueden configurar la apariencia de su propio sistema,
sesin, archivo, y valores por defecto para la pantalla?

4. tems definidos para PH "Consistencia y Estndares":
4.1 Los formatos de la compaa o de la industria han sido respetados
de manera consistente a lo largo de las distintas pantallas del
sistema?
4.2 El abuso de letras en maysculas en la pantalla ha sido evitado?
4.3 Las abreviaturas no incluyen punto?
4.4 Los nmeros enteros estn justificados a derecha y los nmeros
reales alineados con respecto al punto decimal?
4.5 Los iconos poseen etiqueta?
4.6 No hay ms de 12/20 tipos de iconos?
4.7 Existe algn elemento visual que identifique la ventana activa?
4.8 Cada ventana posee un ttulo?
4.9 Es posible utilizar las barras de desplazamiento horizontal y vertical
en cada ventana?
4.10 La estructura de mens coincide con la estructura de las tareas?
4.11 Han sido establecidos estndares de la compaa o industriales para
el diseo de los mens? Estn aplicados de manera consistente en
todas las pantallas del sistema?
4.12 Los mens son presentados de manera vertical?
4.13 Si una opcin de un men es la de "salir, esta opcin aparece como
ltimo tem del men?
4.14 Los ttulos de los mens estn centrados o justificados a izquierda?
4.15 Los tems de los mens estn justificados a izquierda, con un
nmero o un elemento mnemotcnico precediendo el texto del tem?
4.16 Los apuntadores (prompts) embebidos dentro un tem de un men
mltiple, se despliegan hacia la derecha de la etiqueta del tem?
4.17 Las instrucciones en lnea aparecen en un lugar semejante a lo largo
de las diferentes pantallas?
4.18 Las etiquetas de campos y los campos se distinguen
topogrficamente entre s?
4.19 Las etiquetas de los campos mantienen una forma consistente entre
una pantalla y otra?

4.20 Los campos y las etiquetas estn justificadas a izquierda para listas
alfabticas y a derecha para listas numricas?
4.21 Las etiquetas de campos aparecen a la izquierda de los campos
sencillos y arriba de las listas de campos?
4.22 Las tcnicas para atraer la atencin del usuario estn utilizadas de
manera cuidadosa?
4.23 Intensidad: slo dos niveles
4.24 Tamao: hasta cuatro veces
4.25 Fuentes: hasta tres tipos
4.26 Parpadeo (blink): dos a cuatro hertz
4.27 Color: hasta cuatro colores diferentes (colores adicionales utilizados
ocasionalmente)
4.28 Sonido: tonos suaves para dispositivos de retroalimentacin regular y
bruscos para condiciones crticas.
4.29 Las tcnicas para atraer la atencin del usuario estn utilizadas
solamente en condiciones excepcionales o para tareas dependientes
del tiempo?
4.30 Hay entre cuatro/siete colores como mximo, y pertenecen estos
colores al espectro visible?
4.31 Se provee una leyenda si los cdigos de color son numerosos o
difciles de interpretar?
4.32 Se evitan los pares de colores espectralmente extremos y altamente
cromticos?
4.33 Los azules saturados no se utilizan para texto u otro elemento
pequeo?
4.34 La informacin ms relevante est posicionada al comienzo del
apuntador (prompt)?
4.35 Las acciones del usuario estn nombradas de manera consistente a
lo largo de los diferentes apuntadores del sistema?
4.36 Los objetos del sistema estn nombrados de manera consistente a lo
largo de los diferentes apuntadores del sistema?
4.37 Los apuntadores de nivel de campo proveen ms informacin que
una reafirmacin del nombre del campo?
4.38 Para interfaces de preguntas y respuestas, las entradas vlidas para
una cuestin estn listadas?
4.39 Los nombres de las opciones en los mens son consistentes en
relacin a los dems nombres de tems de los mens del sistema en
cuanto al estilo gramatical y la terminologa?
4.40 La estructura de los nombres de las opciones en los mens coinciden
con su correspondiente ttulo de men? Does the structure of menu
choice names match their corresponding menu titles?
4.41 Los comandos son utilizados de manera similar y poseen el mismo
significado en todas las partes del sistema?
4.42 Los comandos de lenguaje son consistentes, naturales y poseen una
sintaxis fcil de memorizar?
4.43 Las abreviaturas siguen una regla primaria simple? Si es necesario,
puede duplicarse una regla secundaria simple para abreviar una
palabra cuya abreviatura simple coincida con alguna abreviatura
previamente utilizada?
4.44 Es la regla secundaria del tem anterior utilizada solo cuando es
estrictamente necesario?
4.45 Todas las abreviaturas poseen la misma longitud?
4.46 La estructura de entrada de valores (datos) es consistente entre las
diferentes pantallas?
4.47 El mtodo para mover el cursor hacia el campo anterior o posterior
es consistente a lo largo del sistema?
4.48 Si el sistema posee pantallas mltiples para la entrada de datos,
tienen estas pantallas el mismo ttulo?
4.49 Si el sistema posee pantallas mltiples para la entrada de datos, las
correspondientes pantallas estn numeradas de manera secuencial?
4.50 El sistema respeta las convenciones de la industria o los estndares
de la compaa para asignar funciones a las teclas?
4.51 Los colores altamente cromticos son utilizados para atraer la
atencin del usuario?

5. tems definidos para PH "Ayuda a los usuarios Reconocimiento,
diagnstico y recuperacin de errores":
5.1. Los sonidos son utilizados para sealar errores?
5.2. Los apuntadores son presentados de manera constructiva, sin
necesidad de una crtica manifiesta o no manifiesta de los usuarios?
5.3. Los apuntadores implican que el usuario tiene el control?
5.4. Los apuntadores son breves e inequvocos?
5.5. Los mensajes de error estn expresado de manera tal que es el
sistema, y no el usuario, quien se hace cargo de los errores?
5.6. Si se usan mensajes de error con humor, son apropiados y
respetuosos para la comunidad de usuarios?
5.7. Los mensajes de error son gramaticalmente correctos?
5.8. Los mensajes de error evitan el uso de signos de admiracin?
5.9. Los mensajes de error evitan el uso de palabras violentas u hostiles?
5.10. Los mensajes de error evitan el tono antropomrfico?
5.11. Todos los mensajes de error del sistema utilizan un estilo
gramatical, una terminologa, una forma y abreviaturas consistentes?
5.12. Los mensajes colocan al sistema bajo el control del usuario?
5.13. El lenguaje de comandos utiliza la sintaxis habitual accion-objeto?
5.14. El lenguaje de comandos evita las arbitrariedades y el uso no-ingls
de signos de puntuacin, con excepcin de los smbolos conocidos
por el usuario?
5.15. Si se detecta un error en un campo de entrada de datos, el sistema
posiciona el cursor en ese campo o lo resalta de alguna manera?
5.16. Los mensajes de error informan al usuario sobre la severidad del
error cometido?
5.17. Los mensajes de error sugieren la causa del problema que los ha
ocasionado?

5.18. Los mensajes de error proporcionan informacin semntica
apropiada?
5.19. Los mensajes de error proveen informacin sintctica apropiada?
5.20. Los mensajes de error indican que accin debe realizar el usuario
para corregir el error correspondiente?
5.21. Si el sistema esta pensado para que lo utilicen tanto usuarios
expertos como novatos, existen diferentes niveles de complejidad en
los mensajes de error disponibles?

6. tems definidos para PH "Prevencin de errores":
6.1. Si la base de datos incluye grupos de datos, los usuarios pueden
entrar ms de un grupo en una nica pantalla?
6.2. Se han usado puntos o guiones bajos (underscores) para indicar la
longitud de los campos?
6.3. El nombre de la eleccin del men en un men de nivel superior se
usa como ttulo de men para el men de nivel inferior?
6.4. Las elecciones disponibles en el men son lgicas, distinguidas entre
s y mutuamente excluyentes?
6.5. Las entradas de datos son no sensibles a maysculas siempre que
sea posible?
6.6. Si el sistema muestra mltiples ventanas, es la navegacin entre
ellas simple y visible?
6.7. Aquellas teclas de funcin que pueden causar las peores
consecuencias se encuentran ubicadas en posiciones del teclado
difciles de alcanzar?
6.8. Aquellas teclas de funcin que pueden causar las peores
consecuencias se encuentran alejadas de las teclas cuyo uso es
intensivo pero no tiene mayores consecuencias?
6.9. Se ha minimizado el uso de las teclas calificadoras (qualifier keys)?
6.10. Si el sistema utiliza teclas calificadoras, se usa a las mismas
consistentemente en todo el sistema?
6.11. El sistema previene a los usuarios de cometer errores siempre que
esto es posible?
6.12. El sistema alerta a los usuarios si estn a punto de cometer un
error potencialmente serio?
6.13. El sistema interpreta inteligentemente las posibles variaciones en los
comandos de los usuarios?
6.14. Las pantallas para entrada de datos y cajas de dilogo indican el
nmero de espacios en caracteres que estn disponibles para un
campo?
6.15. Los campos en las pantallas de entradas de datos y las cajas de
dilogo, contienen valores por defecto cuando corresponde?

7. tems definidos para PH "Reconocimiento antes que Cancelacin":
7.1. Existen pistas visuales y espacios en blanco para distinguir
preguntas, apuntadores, puntos de insercin de respuestas e
instrucciones en las interfaces de preguntas y respuestas?
7.2. El despliegue de datos comienza en la parte superior izquierda de la
pantalla?
7.3. Las etiquetas de ms de una palabra estn posicionadas de manera
horizontal (no desplegadas de manera vertical)?
7.4. Todos los datos que el usuario necesita se muestran en cada paso
de una transaccin?
7.5. Los apuntadores, pistas visuales y mensajes estas posicionados en
lugares de la pantalla en donde es probable que el usuario dirija su
mirada?
7.6. Los apuntadores presentan un formato que utilice espacios en
blanco, justificaciones y elementos o guas visuales para un fcil
reconocimiento?
7.7. Las reas de texto tienen "espacios de respiracin que las rodeen?
7.8. Existe una distincin visual obvia entre los mens en donde solo es
posible seleccionar una opcin y los mens en donde es posible
seleccionar mltiples opciones?
7.9. Se han preservado las relaciones espaciales entre teclas de funcin
"blandas" (mostradas como elementos en pantalla) y teclas de
funcin "de teclado"?
7.10. El sistema muestra un grisceo o borra las etiquetas de aquellas
teclas de funcin "blandas" que estn actualmente inactivas?
7.11. Se usa el espacio en blanco para crear simetra y guiar al ojo del
usuario en la direccin apropiada?
7.12. Se han agrupado los tems en zonas lgicas, utilizando
encabezamientos para distinguir entre dichas zonas?
7.13. Las zonas tienen como mximo entre doce y catorce caracteres de
ancho, y entre seis y siete lneas de alto?
7.14. Las zonas han sido separadas por espacios, lneas, color, letras,
ttulos resaltados, lneas de separacin o reas sombreadas?
7.15. Las etiquetas de los campos estn cercanas a los mismos, pero
separadas de stos por al menos un espacio en blanco?
7.16. Los campos en columna que son largos se descomponen en grupos
de cinco, separados por una lnea en blanco?
7.17. Los campos de entrada de datos que son opcionales estn
claramente marcados?
7.18. Los smbolos se usan para cortar cadenas de entrada de gran
longitud en "bloques" (chunks)?
7.19. Se utiliza video grabado anteriormente o realce de colores para
lograr la atencin del usuario?
7.20. Se utiliza video grabado anteriormente para indicar que un tem ha
sido escogido?
7.21. Se utiliza tamao de letra, realce de fuente, subrayado, color,
sombreado o tipografa especial para mostrar la cantidad relativa o
importancia de los diferentes tems en pantalla?
7.22. Se utilizan los bordes para identificar grupos significativos?
7.23. Se ha utilizado el mismo color para agrupar elementos relacionados?
7.24. La codificacin de color es consistente dentro de todo el sistema?
7.25. El color se usa en conjuncin con algn otro elemento redundante?

7.26. Existe buen contraste de brillo y de color entre los colores usados
para imgenes y fondo?
7.27. Los colores suaves, brillantes y saturados se han utilizado para
enfatizar datos, mientras que los colores oscuros, opacos y no
saturados han sido usados para des-enfatizar datos?
7.28. La primer palabra de cada opcin del men, es la ms importante?
7.29. El sistema provee un mapeo que hace que el usuario perciba que
existen relaciones entre los controles y las acciones asociadas?
7.30. Los cdigos para ingreso de datos son distintivos?
7.31. Se han eliminado pares de datos frecuentemente confusos cada vez
que fuera posible?
7.32. Aquellas secuencias de nmeros o letras que tienen gran longitud se
han descompuesto en "bloques" (chunks)?
7.33. Los tems inactivos en un men aparecen en gris o estn omitidos?
7.34. Existen elecciones por defecto dentro del men?
7.35. En caso en que el sistema tenga muchos niveles de mens (o niveles
de mens complejos), los usuarios tienen acceso a un mapa espacial
en lnea de los mens existentes?
7.36. Los mens GUI poseen "affordance (esto es, hacen que resulte
obvio donde es posible realizar una seleccin) ?
7.37. Existen elementos visuales llamativos para identificar cul es la
ventana activa?
7.38. Las teclas de funcin se encuentran organizadas en grupos lgicos?
7.39. Las pantallas de entrada de datos y las cajas de dilogo indican
dnde los campos son opcionales?
7.40. En las pantallas de entrada de datos y en las cajas de dilogo, los
campos dependientes se muestran slo cuando es necesario?

8. tems definidos para PH "Flexibilidad y eficiencia de uso":
8.1. Si el sistema soporta tanto a usuarios novicios y expertos, se
encuentran disponibles mltiples niveles de mensaje de error?
8.2. El sistema permite que los usuarios novicios usen una "gramtica de
palabras clave" (keyword grammar) y los expertos una "gramtica
posicional"?
8.3. Pueden los usuarios definir sus propios sinnimos para comandos?
8.4. Permite el sistema que los usuarios novicios entren la forma ms
simple y comn de cada comando, y permitan a los usuarios expertos
aadir parmetros?
8.5. Los usuarios expertos tienen la opcin de ingresar comandos
mltiples en una nica cadena de texto?
8.6. El sistema provee teclas de funcin para comandos de alta
frecuencia?
8.7. Para pantallas de entrada de datos con muchos campos o en los
cuales los documentos fuentes pueden estar incompletos, tienen los
usuarios la posibilidad de grabar una pantalla parcialmente
completada?
8.8. El sistema automticamente ingresa ceros por delante para
alineacin de valores "(leading zeros)"?
8.9. Si las listas de mens son cortas (siete tems o menos), pueden los
usuarios seleccionar un tem moviendo el cursor?
8.10. Si el sistema utiliza la estrategia de teclear por adelantado (type-
ahead), los tems de men tienen asociados cdigos mnemnicos?
8.11. Si el sistema usa un dispositivo apuntador, los usuarios tienen la
opcin de hacer "clic directamente sobre los campos o utilizar un
atajo de teclado?
8.12. El sistema ofrece atajos para "encontrar siguiente" y "encontrar
previo" en bsquedas en bases de datos?
8.13. En las pantallas de entradas de datos, los usuarios tienen la opcin
de hacer "clic directamente sobre un campo o utilizar un atajo de
teclado?
8.14. En los mens, los usuarios tienen la opcin o bien de hacer "clic
directamente en un tem del men o utilizar un atajo de teclado?
8.15. En las cajas de dilogo, los usuarios tienen la opcin de hacer
"clicdirectamente en la opcin de la caja de dilogo o de utilizar un
atajo del teclado?
8.16. Los usuarios expertos pueden saltear las cajas de dilogos anidadas
ya sea a travs de teclear por adelantado (type-ahead), con macros
definidas por el usuario o con atajos de teclado?



9. tems definidos para PH "Esttica de dilogos y diseo
minimalista":
9.1. La informacin esencial para tomar decisiones (y solo esta
informacin) es mostrada en la pantalla?
9.2. Los conos son visualmente distinguibles de acuerdo a su significado
conceptual?
9.3. Los objetos extensos, las lneas resaltadas y las reas simples de la
pantalla, se distinguen de los conos?
9.4. Cada icono esta resaltado con respecto a su fondo?
9.5. Si el sistema utiliza interfaces grficas estndares (GUI) donde la
secuencia de los mens ya ha sido especificada, los mens estn
diseados respetando esa especificacin siempre que es posible?
9.6. Los grupos de tem con significado semejante, estan separados por
espacios en blanco?
9.7. Cada pantalla de entrada de datos incluye un ttulo simple, corto,
claro y suficientemente distintivo?
9.8. Las etiquetas de los campos son familiares y descriptivas?
9.9. Los apuntadores estn expresados de manera positiva y escritos
utilizando el estilo de la voz activa?
9.10. Cada opcin de men posicionada en un nivel inferior est asociada
con solo una opcin del nivel superior?
9.11. Los ttulos de los mens son breves pero suficientemente largos
como para comunicar su contenido?

9.12. Los mens emergentes (pop-up or pull-down menus) con campos
para entradas de datos, poseen varias opciones para entrar esos
datos definidas de manera correcta?

10. tems definidos para PH "Ayuda general y documentacin":
10.1. Si los usuarios trabajan desde el disco rgido, las partes del disco
rgido que se hallan conectadas en lnea (online) estn marcadas?
10.2. Las instrucciones en lnea se distinguen visualmente?
10.3. Las instrucciones siguen la secuencia de las acciones del usuario?
10.4. Si las opciones de los mens son ambiguas, el sistema provee
informacin aclaratoria adicional cuando un tem es seleccionado?
10.5. Las cajas de entrada de datos y de dilogos pueden ser utilizadas en
lnea para completar acciones?
10.6. Idem a tem 10.4
10.7. Hay ayudas de memoria para los comandos, ya sea a travs de
referencias rpidas en lnea o apuntadores?
10.8. La funcin de ayuda del men es visible? (por ejemplo, una tecla
etiquetada AYUDA o un men especial?
10.9. La interfaz de ayuda del sistema (navegacin, presentacin, y
conversacin) es consistente con las interfases de navegacin,
conversacin y presentacin de la aplicacin que soporta?
10.10. Navegacin: la informacin es fcil de encontrar?
10.11. Presentacin: la disposicin visual est bien diseada?
10.12. Conversacin: la informacin es exacta, completa y comprensible?
La informacin es relevante?
10.13. Orientacin a la meta (qu puedo hacer yo con este programa?)
10.14. Descriptivo (para qu es esta cosa?)
10.15. Procedimental (cmo hago yo para hacer esta tarea?)
10.16. Interpretativo (por qu sucedi eso?)
10.17. Navegacional (dnde estoy?)
10.18. Existe ayuda sensible al contexto?
10.19. Puede el usuario cambiar el nivel de detalle disponible?
10.20. Pueden los usuarios cambiar fcilmente entre la ayuda y su trabajo?
10.21. Tras haber accedido a la ayuda pueden los usuarios continuar con su
trabajo desde donde lo dejaron interrumpido?
10.22. Es fcil acceder y regresar del sistema de ayuda?
10.23. Tras haber accedido a la ayuda pueden los usuarios continuar con su
trabajo desde donde lo dejaron interrumpido?

11. tems definidos para PH "Habilidades":
11.1. Pueden los usuarios elegir entre la presentacin de informacin en
forma de texto o con iconos?
11.2. Las operaciones para ventanas son fciles de aprender y usar?
11.3. Si los usuarios son expertos, la utilizacin es frecuente, o el sistema
tiene un bajo tiempo de respuesta, hay en tal caso menos pantallas
(ms informacin por pantalla)?
11.4. Si los usuarios son novicios, la utilizacin es infrecuente o el sistema
tiene un tiempo de respuesta rpido, hay ms pantallas (menos
informacin por pantalla)?
11.5. El sistema codifica automticamente los tems con color, con
esfuerzo escaso o nulo por parte del usuario?
11.6. Si el sistema soporta tanto usuarios expertos como novicios, hay
mltiples niveles de detalle disponibles?
11.7. Son los usuarios los iniciadores de las acciones antes que ser
quienes deben responder ante ellas?
11.8. El sistema realiza traducciones de datos para los usuarios?
11.9. En los valores para campos se evita mezclar caracteres numricos y
alfabticos siempre que sea posible?
11.10. Si el sistema tiene mens profundos (varios niveles), los usuarios
tienen la opcin de teclear por adelantado?
11.11. Cuando el usuario accede a una pantalla o una caja de dilogo, el
cursor ya est posicionado en el campo que ms probablemente el
usuario vaya a necesitar?
11.12. Pueden los usuarios moverse hacia adelante y hacia atrs dentro de
un campo?
11.13. El mtodo para mover el cursor al campo siguiente o previo es
simple y a la vez visible?
11.14. Se ha evitado la auto-tabulacin excepto cuando los campos tienen
longitudes fijas o los usuarios son experimentados?
11.15. Los dispositivos de entrada escogidos coinciden con las capacidades
del usuario?
11.16. Las teclas de cursor se encuentran dispuestas en forma de T
invertida (mejor disposicin para expertos) o en forma de cruz
(mejor configuracin para novicios)?
11.17. Las teclas importantes (por ejemplo ENTER o TAB) son ms grandes
que las dems teclas?
11.18. Hay suficientes teclas de funcin para soportar funcionalidad, pero no
tantas que sea difcil su deteccin y reconocimiento?
11.19. Las teclas de funcin estn reservadas para funciones genricas, de
alta frecuencia e importantes?
11.20. Las asignaciones de teclas de funcin son consistentes a travs de
pantallas, subsistemas y productos relacionados?
11.21. El sistema anticipa y avisa al usuario correctamente acerca de la
prxima actividad que sea ms probable?

12. tems definidos para PH "Interaccin con el Usuario Placentera y
Respetuosa":
12.1. Es cada icono individual un miembro armonioso dentro de una
familia de iconos?
12.2. Se ha evitado el detalle excesivo en el diseo de iconos?
12.3. Se ha usado el color con discrecin?

12.4. La cantidad de administracin de ventanas requerida se ha
mantenido a un mnimo?
12.5. Si los usuarios estn trabajando a partir de una copia impresa el
diseo de pantalla coincide con el formulario en papel?
12.6. El color se ha usado especficamente para llamar la atencin,
comunicar la organizacin, indicar cambios de status y establecer
relaciones?
12.7. Los usuarios pueden desactivar la codificacin automtica de color si
fuera necesario?
12.8. Los requerimientos de tecleo son mnimos para las interfases de
pregunta y respuesta?
12.9. Los dispositivos de entrada seleccionados concuerdan con las
restricciones del medio-ambiente?
12.10. Si el sistema utiliza dispositivos de entrada mltiple, se ha
minimizado el movimiento de mano y ojos entre los dispositivos de
entrada?
12.11. Si el sistema soporta tareas grficas, se ha provisto un dispositivo
apuntador alternativo?
12.12. El teclado numrico se encuentra localizado a la derecha del rea de
teclas alfabticas?
12.13. Las teclas de funcin usadas ms frecuentemente se encuentran en
las posiciones ms accesibles?
12.14. El sistema completa entradas parciales inequvocas en un campo de
entrada de datos?

13. tems definidos para PH "Privacidad":
Las reas protegidas son completamente inaccesibles?
Puede accederse con ciertas palabras claves a las reas
confidenciales o protegidas?
Es la caracterstica del punto anterior efectiva y exitosa?

3.3 Principios heursticos de Constantine

En el ao 1994 Larry Constantine propone varios principios de usabilidad que deben
aplicarse para alcanzar el desarrollo de un interfaz altamente usable (para ms
detalle sobre los principios de L. Constantine consultar http://www.foruse.com/).
Esos principios, que actualmente se consideran PHs generales capaces de guiar la
definicin de una EH, fueron planteados por su autor como la siguiente lista:

Estructura: organizar la informacin agrupada por su significado.
Simplicidad: hacer fciles las tareas comunes que el usuario realice
habitualmente.
Visibilidad: mostrar toda aquella informacin necesaria para una tarea que
deba realizar el usuario.
Retroalimentacin: mantener informados a los usuarios en todo momento
segn las acciones que hayan realizado.
Tolerancia: permitir a los usuarios en todo momento: cancelar, deshacer,
volver.
Reutilizacin: reducir la necesidad de los usuarios de recordar.

3.4 Principios heursticos para Web de
Instone

En el ao 1996 Keith Instone redacta un informe tcnico denomindado "Usability
Engineering on the Web (para ms detalle ver http://instone.org/node/12). En ese
informe, considerado actualmente como uno de los pilares en cuanto a la definicin
de PHs para la web, la autora enumera a una serie de principios bsicos a tener en
cuenta al disear una interfaz para la World Wide Web. Esos principios se resumen
en los siguientes puntos:

Dilogo simple y natural. Llevar conversaciones al nivel del usuario.
Hablar el lenguaje del usuario. Utilizar el lenguaje del usuario, siempre
que sea posible.
Minimiza la carga de memoria del usuario. Procurar que los datos que
deba recordar el usuario sean de fcil acceso o estn presentes en la
interfaz.
Consistencia. Ser consistentes en cuanto a diseo de la interfaz.
Retroalimentacin. El sistema debe informar al usuario de los cambios
producidos por alguna accin del usuario.
Salidas claramente marcadas. El usuario ha de poder identificar
fcilmente como salir de la aplicacin.
Atajos. Siempre que sea posible, pensar en los usuarios con experiencia y
facilitarles atajos para que puedan llegar a la informacin ms fcilmente.
Buenos mensajes de error. Cuando suceda un error informar al usuario,
siempre que sea posible, de forma clara (no con cdigos de errores).
Prevencin de errores. Intentar minimizar todos los posibles errores que
se puedan producir en la aplicacin y controlarlos.
Ayuda y documentacin. Informar al usuario o prestarle ayuda cuando la
aplicacin lo requiera.

3.5 Principios heursticos para DCU de
Mayhew

De manera similar a los autores anteriores, en el ao 1999 D. Mayhew propuso una
serie de principios para el Diseo de Sistemas Centrados en el Usuario o DCU
[MAY99]. Estos principios pueden ser interpretados como guas en el momento del
diseo de un sistema interactivo o como PHs a la hora de evaluar la calidad de una
determinada interfaz desde el punto de vista del DCU. Los mismos son:


Compatibilidad del usuario, del producto, de las tareas y de los
procesos del sistema: para que est todo coordinado adecuadamente para
que el producto final se adapte perfectamente al usuario que lo usar.
Consistencia y robustez: que el sistema no sea vulnerable a errores.
Familiaridad: un usuario que ya est familiarizado con un sistema similar o
anterior se adaptar mejor al nuevo producto.
Simplicidad: un sistema simple es mas fcil de usar.
Manipulacin directa: el usuario maneja directamente los elementos del
sistema.
Control: el usuario en todo momento ha de tener el control del sistema.
WYSIWYG: para poder trabajar con un documento con el aspecto real que
tendr.
Flexibilidad: si el sistema es flexible, puede adaptarse a cualquier tipo de
usuarios.
Sensibilidad y feedback: que el sistema interacte con el usuario.
Tecnologa invisible: que la tecnologa usada en un sistema se mantenga
invisible al usuario.
Proteccin: un sistema en el que sus datos queden a salvo de intrusos.
Facilidad de aprendizaje y facilidad de uso: para que un usuario pueda
usar el sistema fcilmente.
3.6. Principios heursticos para pginas
de inicio de Nielsen y Tahir

Luego de un exhaustivo estudio de la pgina de inicio de ms de 200 sitios web
pertenecientes al contexto de uso anglosajn, Jacob Nielsen y Marie Tahir publican
en el ao 2002 un compendio de PHs para la evaluacin de pginas de inicio
[NITA02]. En esta obra, estos autores ilustran su trabajo con la puesta en marcha
de evaluaciones de la usabilidad de 50 pginas de inicio pertenecientes al
mencionado contexto de uso. Los 10 PHs ms significativos planteados en [NITA02]
se describen a continuacin:

Visibilidad del estado del sistema: se necesita informar a los usuarios
sobre lo que est aconteciendo, favoreciendo un "feedback adecuado en un
tiempo razonable
Compatibilidad entre el sistema y el mundo real: el sistema debe
adecuar su lenguaje al utilizado por el usuario en vez de orientarlo hacia el
sistema. Se deben seguir las convenciones del mundo real favoreciendo que
la informacin aparezca de una manera natural y lgico para el usuario.
Control y libertad del usuario: usualmente los usuarios escogen funciones
del sistema incorrectas. Debe proporcionrseles elementos claros que les
permita actuar en situaciones indeseadas sin necesidad de recorrer un largo
camino para deshacer las opciones que le llevaron al error.
Consistencia y estndares: los usuarios no deberan necesitar adivinar
que diferentes conceptos o palabras significan cosas iguales. Se deben
seguir las convenciones propias de la plataforma computacional que se este
utilizando.
Prevencin de errores: se deben incluir elementos que permitan prevenir
los errores antes de favorecer los mensajes de dilogo una vez que los
errores han sido cometidos.
Reconocimiento ms que recuerdo: optar por la visibilidad y dotar a las
metforas grficas de un gran "affrodance. No aadir carteles que el
usuario leer en una parte del sistema necesarios para actuar en otra parte
del sistema. Las instrucciones para el uso del sistema deben ser fcilmente
accesibles por el usuario cada vez que lo requiera.
Flexibilidad y eficiencia de uso: Los usuarios novatos deberan poder
convertirse en usuarios expertos con el tiempo de uso. Debe favorecerse
distintos tiempos de respuesta del sistema de acuerdo a la experticia o perfil
del usuario que esta interactuando con el mismo. Debe favorecerse que los
usuarios expertos salteen acciones para ejecutar las tareas de manera ms
eficiente.
Diseo esttico y minimalista: debe obviarse la informacin irrelevante.
La informacin o elementos secundarios deben disminuir su visibilidad en
favcor de los elementos o la informacin crucial de la pgina web.
Ayuda al usuario en el reconocimiento, diagnstico y recuperacin
de errores: los mensajes de error deben estar expresados de manera clara,
simple y concisa. No deben incluir cdigos. Es ideal que incluyan una serie
de instrucciones que sugieran una solucin.
Ayuda y documentacin: aunque un sistema pueda ser utilizado sin
ayuda, es conveniente incluirla en forma de "ayuda en lnea. La informacin
descripta en cada ayuda debe ser fcil de encontrar, debe estar dirigida
hacia la accin del usuario y no extenderse demasiado.

3.7. Principios heursticos para Web de
Tognazzini

En el ao 2003, Tognazzini publica en su sitio "Ask Tog una serie de PHs bsicos
para el diseo de una interfaz (para visitar el sitio web "Ask Tog consultar
http://www.asktog.com/basics/firstPrinciples.html). Esos PHs son:

Anticipacin: el sitio Web debe anticiparse a las necesidades del usuario.
Autonoma: los usuarios deben tener el control sobre el sitio Web. Los
usuarios sienten que controlan un sitio web si conocen su situacin en un
entorno abarcable y no infinito.
Ceguera al color: Los colores han de utilizarse con precaucin para no
dificultar el acceso a los usuarios con problemas de distincin de colores
(aprox. un 15% del total).
Consistencia:las aplicaciones deben ser consistentes con las expectativas
de los usuarios, es decir, con su aprendizaje previo
Configuraciones por defecto: Los campos que contienen informacin por
defecto deben ser lo seleccionado, de este modo, los usuarios puede
modificar segn su criterio rpida y fcilmente.
Eficiencia del usuario: los sitios Web se deben centrar en la productividad
del usuario, no en la del propio sitio Web. Por ejemplo, en ocasiones tareas
con mayor nmero de pasos son ms rpidas de realizar para una persona
que otras tareas con menos pasos, pero ms complejas.

Interfaces explorables: hacer que las acciones sean reversibles, que
siempre se encuentre la posibilidad de "deshacer" cualquier accin.
Ley de Fitts: que el tiempo para alcanzar un objetivo con el ratn esta en
funcin de la distancia y el tamao del objetivo. A menor distancia y mayor
tamao ms facilidad para usar un mecanismo de interaccin (Ver ms
sobre Ley de Fitts en http://en.wikipedia.org/wiki/Fittslaw).
Objetos de interfaz humanos: que los objetos de la interfaz sean lo mas
parecido al mundo real de este modo a los usuarios les ser familiares, y de
fcil comprensin.
Reduccin de tiempos de latencia: Hace posible optimizar el tiempo de
espera del usuario, permitiendo la realizacin de otras tareas mientras se
completa la previa e informando al usuario del tiempo pendiente para la
finalizacin de la tarea.
Aprendizaje: los sitios Web deben requerir un mnimo proceso de
aprendizaje y deben poder ser utilizados desde el primer momento.
Uso de metforas: Su uso adecuado facilita el aprendizaje de un sitio Web,
pero un uso inadecuado de estas puede dificultar enormemente el
aprendizaje.
Proteccin del trabajo del usuario: se debe asegurar que los usuarios
nunca pierden su trabajo como consecuencia de un error
Legibilidad: el color de los textos debe contrastar con el del fondo, y el
tamao de fuente debe ser suficientemente grande
Seguir el estado: conocer y almacenar informacin sobre el
comportamiento previo del usuario ha de permitir posteriormente realizar
operaciones frecuentes de manera ms rpida
Navegacin visible: Se deben evitar elementos invisibles de navegacin
que han de ser inferidos por los usuarios, mens desplegables, indicaciones
ocultas, etc.

El conjunto de todos los PHs presentados anteriormente es potencialmente
suficiente para llevar a cabo cualquier EH, pero en la prctica son demasiado
generales y se muestran insuficientes para una evaluacin eficiente. Es por ello que
la EH incluye diferentes pasos de adecuacin de los PHs generales que es necesario
efectuar previamente a la Puesta en Marcha de la misma. Estos pasos son
descriptos en la prxima seccin.

4. Pasos de una Evaluacin Heurstica
4.1. Planificacin de una Evaluacin
Heurstica

El primer paso de una EH es la planificacin. Durante toda esta etapa es
fundamental tener en cuenta que cada contexto de uso (universidades, compaas
de seguros, entidades bancarias, administraciones pblicas, etc.) posee sus normas
o convenciones, las cuales deberan reflejarse en la interfaz de sus sitios y
aplicaciones y en la forma de trabajo de sus usuarios. Es por ello que un paso
crucial dentro de la etapa de planificacin de la EH es la adecuacin de cada criterio
que se utilizar al contexto de uso al cual pertenece el sistema que se desea
evaluar [MOL90]. Primeramente, un paso crucial relacionado con la Planificacin de
una EH es la seleccin de los evaluadores que debern llevar a cabo la etapa
siguiente en el proceso de evaluacin. Si esta seleccin se realiza como primer paso
dentro de la Planificacin, podr contarse con la recomendable presencia de estas
personas durante el resto de la Planificacin. En este sentido, se ha observado que
diferentes personas aplicando los mismos PHs encuentran diferentes tipos de
problemas de usabilidad en un mismo sistema que se esta evaluando. Es por ello
que diversos autores sostienen que los resultados de una EH que involucre a un
solo evaluador experto no sern suficientemente confiables [MOL90, NIE92,
NITA02].

En relacin a lo discutido en el prrafo anterior, una decisin trascendental para el
posterior desarrollo de la EH es la seleccin de cuantos evaluadores se incluirn en
la EH y cul ser el perfil de esos evaluadores. En este sentido, la Figura 1 muestra
una grfica que compara los cuatro experimentos (Teledata, Mantel, Savings y
Transport) analizados por [MOL90]. En esta grfica puede observarse como al
realizar la EH con un solo evaluador no se encuentran tantos problemas de
usabilidad como con cinco evaluadores. De la misma manera, tambin se observa
que a partir de la inclusin de 15 evaluadores la deteccin de problemas de
usabilidad se estabiliza. Otro resultado interesante con respecto a la cantidad de
evaluadores a incluir en una EH se presenta en la Figura 2. En este caso, J. Nielsen
analiza la relacin costo-beneficio entre la cantidad de evaluadores involucrados en
una EH y los beneficios obtenidos (Para ms informacin consultar
http://www.useit.com/papers/heuristic/heuristic_ evaluation.html )


Figura 1 Proporcin media de problemas de usabilidad encontrados
entre treinta evaluadores [MOL90]




Figura 2 Costo-beneficio en relacin a la cantidad de evaluadores necesarios para
llevar a cabo una EH. Extrado de "How to Conduct a Heuristic Evaluation (J.
Nielsen), en http://www.useit.com/papers/heuristic/heuristic_evaluation.html

Por lo expuesto anteriormente, la metodologa tradicional sostiene que el nmero
de evaluadores necesario para realizar una EH no tiene que ser demasiado grande.
Nielsen y Landauer [NIL93] proponen como ideal seleccionar entre tres a cinco
evaluadores ya que, segn estos autores, con ellos ya se encuentran
aproximadamente el 75 % de los errores en un interfaz del sistema que se analice
a travs de la EH. Estos autores propusieron una funcin matemtica que calcula la
potencialidad de una EH (en funcin de la cantidad de problemas que sern
detectados) de acuerdo a la siguiente ecuacin:
ProblemasEncontrados(i) = N(1 - (1 - l)
i
)

En donde ProblemasEncontrados(i) es el nmero de problemas de usabilidad
encontrado durante i evaluaciones (es decir, i evaluadores en el mismo ciclo
iterativo y con el mismo sistema o prototipo), N es el nmero total de problemas de
usabilidad en la interfaz de usuario, e l es la probabilidad de encontrar un problema
de usabilidad cuando el sistema se evala con un slo evaluadora travs de la
metodologa de la EH.


Figura 3 Clculo promedio de la funcin "ProblemasEncontrados para seis
interfaces[NIL93]. Extrado de "How to Conduct a Heuristic Evaluation (J. Nielsen),
en http://www.useit.com/papers/heuristic/heuristic_evaluation.html

La Figura 3 muestra el clculo de esta funcin para el caso de un ejemplo prctico
presentado por J. Nielsen en donde se calcula la funcin "ProblemasEnocntrados
para seis interfaces diferentes (Para detalles sobre las caractersticas de la
experimentacin realizada por J. Nielsen consultar http://www.useit.com/papers/
heuristic/heuristic_evaluation.html).

Como ya se menciona anteriormente, otro segundo aspecto relacionado con la
seleccin de los evaluadores es su perfil ideal. Mientras que la metodologa
tradicional sugiere contar con evaluadores que tengan algn conocimiento sobre los
principios de la usabilidad [MOL90]. Posteriormente, se crey que el mtodo poda
ser ms efectivo cuando los evaluadores eran expertos en usabilidad. Sin embargo,
y en concordancia con el auge del Diseo Centrado en el Usuario, algunos autores
proponen involucrar como evaluadores a posibles usuarios de la aplicacin e incluso
a desarrolladores de aplicaciones [NIE92, MUL98, GPL04]. Veamos las distintas
caractersticas de cada tipo de evaluador:

Los expertos en usabilidad: segn las posturas ms tradicionales son los
ms apropiados para ste mtodo porque es difcil que un desarrollador o un
usuario pueda encontrar todos los problemas de usabilidad en una interfaz a
partir de los criterios heursticos [MOL90]. Sin embargo, autores como
[GPL04] sostienen que el experto en usabilidad no tiene experiencia en el
dominio de uso de la aplicacin y tiende a informar solamente de problemas
potenciales que otros perfiles de evaluadores no detectara.

Los desarrolladores: los desarrolladores sin experiencia especfica en
usabilidad pueden cumplir el rol de evaluadores de una EH. Sin embargo,
resultados obtenidos sobre distintas pruebas sugieren que este perfil de
evaluadores no es suficientemente apropiado ya que tiende a concentrarse
en problemas tcnicos, sugiriendo cambios que estn fuera del alcance de la
IPO y que se relacionan ms con la funcionalidad que con la interfaz del
sistema que se desea evaluar.

Los usuarios potenciales: Los usuarios inexpertos pueden ser bastante
confusos al realizar una EH, principalmente porque no pueden expresar
correctamente los problemas que detectan y no son claros a la hora de
plantear problemticas que ayuden a los diseadores a la posterior mejora
de la interfaz evaluada. Sin embargo, se ha observado que si los usuarios
conocen medianamente el sistema a evaluar o si son expertos en su uso o
han sido involucrados en su desarrollo; entonces tienden a detectar
problemas de usabilidad muy eficazmente [GLP04].

Una vez que el equipo evaluador de la usabilidad ha sido conformado se debe
proceder a seleccionar que PHs incluirn en la evaluacin a realizar, teniendo en
cuenta el cubrimiento de los puntos clave del sistema a evaluar y tratando de evitar
la posible solapacin de los mismos. Una vez seleccionados los HPs que se incluirn
debe encarase la delicada tarea de adecuarlos al contexto de uso a evaluar tal
como se indica en el prrafo anterior. Es evidente que cuanto ms adecuados al
contexto de uso estn los HPs seleccionados, ms relevantes sern los resultados
obtenidos por la EH. Este tipo de problemticas es estudiada por la llamada
Usabilidad Transcultural [SHWP06].



Figura 4. Interfaz de UsabAIPO-GestorHeurstica.
Pantalla para ingreso de resultados.

En tercer lugar, cada PH considerado puede traducirse en una serie de preguntas o
sub-PHs capaces de instanciarse de manera natural en el sistema a evaluar. Deben
clasificarse los problemas que van a registrar asocindose a cada PH o sub-PH
preguntas que posteriormente deber contestar el evaluador durante el proceso de
inspeccin. Adems, debe elegirse una escala de valores para cada una de las
posibles respuestas, indicando el significado de cada valor posible. Esta escala de
valores puede incluir parmetros numricos discretos (del tipo, 1,2,..,5),
parmetros numricos continuos (del tipo 0,5-1), parmetros alfabticos (del tipo
mucho-poco-nada), parmetros alfanumricos (del tipo A1, A2,.,A10), etc. La
definicin de una escala de valores clara y concisa mejorar el anlisis posterior de
resultados, minimizndose la subjetividad de los evaluadores expertos y
propicindose el anlisis comparativo de las diferentes puestas en marcha a
ejecutar. Sin embargo, a veces algunas preguntas solo podrn ser respondidas por
el equipo evaluador utilizando lenguaje natural.
Como resultado de la etapa de planificacin de la EH debe obtenerse una especie
de "planilla en blanco donde se liste cada una de las preguntas a evaluar, se
indique escala de valores y significado de cada valor, y se deje espacio para que
durante la posterior Puesta en Marcha los evaluadores expertos completen la
evaluacin. Es importante dejar siempre espacio para las anotaciones personales de
los evaluadores, las cuales pueden ayudar a interpretar resultados y aclarar puntos
oscuros de la evaluacin. Si la EH a realizar es muy compleja o muy grande, puede
opcionalmente reemplazarse a esa planilla por la utilizacin de alguna herramienta
informtica que ayude a gestionar la EH. En este sentido, las Figuras 4 y 5
muestran la interfaz de la plataforma "UsabAIPO-GestorHeurstica [GLP06] creada
dentro de la planificacin de la Segunda Etapa de la Iniciativa UsabAIPO [LGP05,
LGP06, GLPG06] y utilizada durante la Puesta en Marcha de la EH de 69 sitios web
pertenecientes a la red "Universia (ver pgina de inicio de red Universia en
www.universia.es).


Figura 5. Interfaz de UsabAIPO-GestorHeurstica.
Pantalla para ingreso de comentarios en lenguaje natural.

La plataforma UsabAIPO-GestorHeuristica [GLPG06] permite almacenar informacin
pertinente a la Puesta en Marcha de la EH que se desee efectuar, datos de las
interfaces a evaluar (en este caso pginas web de universidades) y las preguntas
heursticas asociadas a cada PH que se ha decidido incluir en la EH (Figura 4).
Adems, esta base de datos permite almacenar los resultados obtenidos al realizar
la inspeccin de cada interfaz considerada. Consecuentemente, para el diseo de la
interfaz de la plataforma UsabAIPO-GestorHeurstica se tuvo en cuenta que toda la
informacin asociada a cada PH includo en la EH fuera altamente visible. De esta
manera se intenta ayudar al evaluador brindndole diferentes datos que beneficien
su ubicacin temporal (momento de la evaluacin) y espacial (interfaz que se est
evaluando y PHs a considerar). En particular, UsabAIPO-GestorHeurstica provee la
facilidad de incluir el nombre de la interfaz que se esta evaluando junto a
informacin referida al PH que se est considerando (nombre, texto de la pregunta,
observaciones asociadas y significado de cada posible respuesta). En cuanto a la
necesidad de brindar al evaluador un sitio en donde introducir comentarios u,
ocasionalmente, un nuevo PH a considerar, la plataforma UsabAIPO-
GestorHeurstica incluye una especie de bloc de notas (Figura 5) en donde el
evaluador podr puntualizar algn dato o aadir comentarios en lenguaje natural
asociados a cada PH.

Cabe mencionar que si bien la potencialidad de este tipo de plataformas queda
evidenciada en la Puesta en Marcha de la EH, su adecuacin y preparacin se
realiza durante la etapa de planificacin, ya que es necesario adecuar al gestor a
utilizar introduciendo todos los datos particulares de la EH que se est llevando a
cabo.

4.2. Puesta en Marcha de una Evaluacin
Heurstica

Una vez concluida la etapa de Planificacin debe procederse a la Puesta en Marcha
de la EH. En esta etapa es imprescindible contar con la presencia de los
evaluadores, quienes debern preceder a la inspeccin de la interfaz del sistema
que se est evaluando. Con respecto a esta etapa, la metodologa clsica asociada
a la EH plantea que los evaluadores deben inspeccionar la interfaz del sistema a
evaluar de manera individual y slo despus de la evaluacin pueden comunicar sus
hallazgos [NIE94, DR99]. Este procedimiento es importante para asegurar
evaluaciones independientes e imparciales de cada evaluador. Es recomendable que
los evaluadores examinen cada parte de la interfaz del sistema evaluado al menos
dos veces para que se familiaricen con su estructura y antes de comenzar con la
evaluacin propiamente dicha [LAI04].

En cuanto a la temporizacin de la Puerta en Marcha de una EH, Nielsen [NIE94]
recomienda sesiones de evaluacin de aproximadamente una o dos horas por cada
parte de la interfaz a evaluar. Los evaluadores utilizan la lista de comprobacin
generada en la etapa anterior y si es estrictamente necesario pueden incorporar
nuevos PHs a los ya existentes. En general, las fases de la Puesta en Marcha de
una EH son las siguientes [MOL90]:

Entrenamiento previo a la evaluacin: Hay que dar a los evaluadores
conocimiento del tema e informacin. No obstante, si el interfaz es del tipo
de "llegar y usar" los evaluadores no necesitan esta introduccin. Este tipo
de interfaces son los que los usuarios deberan ser capaces de utilizar por s
mismos sin ningn tipo de instruccin. Tambin es necesario que los
evaluadores se familiaricen con los diferentes perfiles de usuarios que se
consideran en la EH, ya que durante la segunda fase de la puesta en marcha
debern intentar emular su comportamiento frente a la interfaz del sistema
a evaluar.

Evaluacin propiamente dicha: Los evaluadores expertos evalan el
interfaz con el objetivo de detectar errores de usabilidad. Es conveniente
que el entorno en el cual se desarrolla la EH sea similar para las distintas
sesiones de inspeccin (espacio fsico, condiciones ambientales, hora del da,
nivel de ruido, luminosidad, etc), a fin de minimizar el impacto de factores
externos que pueden afectar a la capacidad cognitiva de los evaluadores.
Cada medicin realizada es plasmada en la lista en blanco que ha sido
generada en el paso anterior. Durante la evaluacin, los evaluadores no tan
expertos pueden guiarse con las heursticas para chequear de este modo los
posibles problemas de usabilidad del sistema.
Segn el autor Jacob Nielsen (puede consultarse sobre este tema en
http://www.useit.com/papers/heuristic/severityrating.html), cuando un
evaluador experto punta la gravedad de un problema de usabilidad esa
medida debera reflejar a los siguientes tres factores:
La frecuencia con la que el problema ocurre, si es comn o raro
que pase una cosa.
El impacto del problema cuando sucede, si los usuarios tendrn
muchos problemas cuando pase.
La persistencia del problema, si el problema es resuelto la
primera vez que se use el sitio web o aparece repetidamente

Puntuacin: En este punto se tiene que determinar la severidad de cada uno de
los problemas encontrados de acuerdo a la escala de valores definida durante la
Planificacin. En cuanto a la jerarquizacin de la gravedad de los problemas de la
interfaz evaluada, tambin es necesario evaluar el "impacto del mercado de cada
problema detectado, puesto que algunos problemas pueden ser de poca
importancia pero afectar mucho a la imagen del sistema. En este sentido
comienzan a perfilarse algunas propuestas que proponen aadir una puntuacin
adicional a los problemas de usabilidad detectados segn la siguiente escala
(consultar http://www.useit.com/papers/heuristic/severityrating.html):

[0=] No es un problema de usabilidad.
[1=] Problema sin importancia: no necesita arreglarse a menos que haya
tiempo de sobra.
[2=] Problema de poca importancia: arreglarlo no tiene mucha importancia.
[3=] Problema grave: es importante arreglarlo.
[4=] Catstrofe: Es obligatorio arreglarlo.

Cabe destacar que diferentes autores coinciden en que es difcil conseguir
que los evaluadores definan durante una sesin heurstica unas buenas
estimaciones de la "severidad asociada a cada problema de usabilidad
[MOL90, NIE92, DR99].

Discusin: Luego de determinar la puntuacin de cada tem observado en la
interfaz que se esta evaluando, es necesario establecer el grado de severidad de
cada uno de los problemas encontrados. Esto se hace distribuyendo la lista
completa de errores encontrados a todos los evaluadores, y puntundola. Puede
considerarse a este paso como parte de la Puesta en Marcha o como parte de la
etapa de Anlisis de Resultados de la EH (ms adecuado en nuestra opinin).

De acuerdo a lo presentado en la Seccin 4.1, si la EH que se esta poniendo en
marcha es lo suficientemente compleja o grande, la utilizacin de una plataforma
que ayude a su gestin puede resultar de sumo inters. Un ejemplo de estas
plataformas lo constituye el software UsabAIPO-GestorHeurstica [GPL06]
presentado dentro de la etapa de Planificacin.
4.3. Anlisis de resultados de una
Evaluacin Heurstica

La EH es una metodologa de evaluacin de la usabilidad que busca resultados
cualitativos que ayuden a enfatizar que problemas de usabilidad presenta la
interfaz del sistema interactivo evaluado por sobre el clculo de funciones
matemticas llamadas mtricas, las cuales sintetizan en un solo valor numrico el
resultado de la evaluacin. Sin embargo, a pesar de su naturaleza cualitativa, la EH
tambin puede brindar valiosos resultados cuantitativos que ayuden a tener una
visin global de los resultados obtenidos en la Puesta en Marcha. Por lo tanto,
concluiremos que el procesamiento de los resultados obtenidos durante la Puesta
en Marcha de una EH puede ser llevado a cabo desde dos puntos de vista no
excluyentes y complementarios:


1. Desde el punto de vista cuantitativo pueden utilizarse herramientas
como la Estadstica para condensar en grficos y funciones matemticas
tanto los resultados obtenidos por un solo evaluador (visin "sumativa
de cada una de las inspecciones realizadas) como los resultados
obtenidos por diferentes evaluadores (visin "comparativa de resultados
obtenidos). Estos resultados cuantitativos ayudarn a resumir de manera
clara y precisa la ponderacin de cada una de las preguntas que
cristalizan a los PHs generales con respecto a la interfaz evaluada.

2. Desde el punto de vista cualitativo los evaluadores elaborarn una
lista de problemas de usabilidad con tems (problemas hallados) que
sern justificados de acuerdo a los PHs que se hayan considerado en la
EH. Segn la metodologa tradicional, el anlisis de cada problema se ha
de realizar por separado y no en conjunto. Sin embargo, nuevas
metodologas como las presentadas en [GGL06] defienden la riqueza de
un anlisis cualitativo general de resultados que permita extrapolar
patrones de comportamiento generales presentes en los datos
provenientes de las distintas evaluaciones efectuadas por los diferentes.
En este sentido herramientas como las Tcnicas del Descubrimiento de
Conocimiento en Base de Datos (Datamining) pueden ser utilizadas para
hallar de manera algortmica (es decir de de manera imparcial y
objetiva) patrones de comportamiento desconocidos y potencialmente
tiles presentes en los datos provenientes de cualquier evaluacin
cualitativa de la usabilidad, en particular provenientes de la Puesta en
Marcha de una EH [GGL06].

Los resultados de la evaluacin se pueden registrar como informes escritos de cada
evaluador o haciendo que los evaluadores comuniquen verbalmente sus
comentarios a un observador mientras inspeccionan la interfaz. Estos informes
tienen la ventaja de presentar un expediente formal de la evaluacin, pero
requieren un esfuerzo adicional para los evaluadores y la necesidad de leerlo y
disear un documento que integre el trabajo de todos los evaluadores por parte del
encargado de la evaluacin. En este sentido, el contar con una plataforma de
software que ayude a gestionar la EH como la presentada en la etapa de
Planificacin puede minimizar considerablemente los esfuerzos posteriores a la
Puesta en Marcha y ayudar a reflejar de manera ms metdica y concreta los
resultados obtenidos [GPL06]. Adems, el uso de este tipo de soporte digital para
la EH supone que los resultados de la evaluacin estn disponibles de manera
inmediata cuando finaliza la etapa de la Puesta en Marcha descrita en la seccin
anterior.

En cuanto a la jerarquizacin de la gravedad de los problemas de la interfaz
evaluada, aqu se pone de manifiesto la importancia de haber definido una escala
de valores para cada una de las posibles respuestas asociadas a los HPs
considerados durante la etapa de Planificacin de la EH. Deber prestarse especial
atencin a los comentarios aadidos por los evaluadores as como a posibles
nuevos PHs que hayan tenido que incluirse con la finalidad de inspeccionar
correctamente la interfaz. Algunos autores sugieren que es conveniente enviar un
cuestionario a los evaluadores despus de las sesiones reales de la evaluacin para
recoger los grados de la severidad, enumerando completamente el sistema segn
los problemas de usabilidad que se han descubierto, y pidiendo que clasifiquen la
severidad de cada problema. Para ello, y debido a que cada evaluador ha
identificado solamente un subconjunto de los problemas incluidos en la lista, los
problemas necesitan ser descritos en la profundidad razonable, usando
posiblemente ilustraciones. Las descripciones se pueden sintetizar agregando
comentarios hechos por los evaluadores que haban encontrado cada problema (si
se utilizan los informes escritos de la evaluacin, las descripciones se pueden
sintetizar de las descripciones incluidas en los informes). Estas descripciones
permiten que los evaluadores determinen varios problemas muy fcilmente incluso
si no los han encontrado en su propia sesin de la evaluacin. Tpicamente,
[MOL90] sugiere que se necesitan alrededor de 30 minutos para realizar estas
puntuaciones, pero es importante observar que cada evaluador debe proporcionar
grados individuales de la severidad independientemente de los otros evaluadores.

5. Conclusiones

La evaluacin es un aspecto fundamental a tener en cuenta en el diseo de
sistemas interactivos. La evaluacin heurstica (EH) es un mtodo por inspeccin de
sencilla aplicacin y relativamente econmico que puede utilizarse en cualquier
etapa del desarrollo de un sistema interactivo. Ha sido demostrado empricamente
que la EH detecta un promedio de aproximadamente 75% del total de problemas
de usabilidad de la interfaz de cualquier sistema interactivo, lo que lo postula como
un mtodo relativamente confiable y altamente recomendable [NIE93, DR99].

En este Captulo hemos visto que existe una amplia bibliogrfica a la hora de definir
los Principios Heursticos (PHs) generales que sustenten tericamente a las
heursticas que guen a una HE. Cabe destacar que en una HE real no es necesario
limitarse a un solo autor de los aqu presentados, sino que los distintos PHs
presentados pueden utilizarse de manera combinada de acuerdo al aspecto que
desee enfatizarse durante la inspeccin de la interfaz que ser evaluada. Para
optimizar el xito de la aplicacin de esta tcnica de evaluacin de la usabilidad,
siempre ha de tenerse en cuenta que una definicin adecuada de criterios
heursticos debe derivarse de un profundo conocimiento de las caractersticas
propias del contexto que se desee evaluar.

Finalmente queremos enfatizar que una EH consta de diferentes pasos, siendo cada
uno de ellos crucial para lograr un mayor xito y una mayor efectividad. En este
sentido, los recursos y el tiempo que se destinen a la Planificacin de la HE se
vern compensados por una Puesta en Marcha ms controlada, efectiva y
sustentable desde una postura cientfica. De la misma manera, un adecuado
Procesamiento de los resultados obtenidos ser fundamental para poder asegurar la
validez y la relevancia de las conclusiones a las que se arribe tras haber evaluado
un sistema interactivo a travs de la metodologa de la EH.
Agradecimientos
Agradecemos al Dr Toni Granollers de la Universitat de Lleida por sus sugerencias
para mejorar la calidad del presente captulo.
Referencias
[CW02] Cockton G., Woolrych, A. Sale must end: Should discount methods be
cleared off HCI's shelves?. En revista Interactions, nm. 9, vol. 5,

pg. 13-18, 2002.
[DKA92] Desurvire H., Kondziela J., Atwood, M. What is Gained and Lost When
Using Evaluation Methods Other Than Empirical Testing. En
Proceedings del Congreso HCI 1992. En Monk, A., Diaper, D., and
Harrison, M.D (eds.) Cambridge University Press, pg. 15-18, 1992.
[DMJ04] Dumas J.S., Molich R., Jeffries R. Describing Usability Problems - Are
We Sending the Right Message?. En Revista Interactions, July-August
2004, pag 24-29.
[DR99] DUMAS J. S., REDISH J. C.. A Practical Guide to Usability Testing.
Intellect Books, 1999.
[GGL06] GONZLEZ M. P., GRANOLLERS T., LORS J.. A Hybrid Approach for
Modelling Early Prototype Evaluation under User-Centred Design
through Association Rules. XIII International Workshop on Design,
Specification and Verification of Interactive System DSV-IS '06. A
publicarse en revista LNCS, 2006 (en prensa).
[GLPG06] GONZLEZ M. P., LORS J., PASCUAL A., Granollers A. Evaluacin
Heurstica de Sitios Web Acadmicos Latinoamericanos dentro de la
Iniciativa UsabAIPO. Remitido a Int. Conf. Interaccin 2006, en
proceso de evaluacin.
[GPL04] GRANOLLERS A., PERDRIX A., LORS J. Incorporacin de Usuarios en
la Evaluacin de la Usabilidad por Recorrido Cognitivo. En Proocedings
de Interaccin 2004, Lleida, pg. 291-295.

[ISO98] ISO Standards No. 9241-11: Guidance on usability. Geneva,
Switzerland: ISO, 1998.
[JMWU91] JEFFRIES R., MILLER J. R., WHARTON C., UYEDA K. User interface
evaluation in the real world: a comparison of four techniques. En
Proocedings de la SIGCHI Conference on Human Factors in Computing
Systems CHI '91. ACM Press, pg. 119-124, 1991.
(http://doi.acm.org/10.1145/108844.108862)
[JEF94] Jeffries, R. Usability Problem Reports: Helping Evaluators Comunicate
Effectively with Developers. In Nielsen, J., and Mack, R.L. (Eds.),
Usability Inspection Methods, John Wiley & Sons, pg. 273-294, 1994.
[JD92] Jeffries R., Desurvire H. Usability testing vs. heuristic evaluation: Was
there a contest?. En revista SIGCHI, num 24, vo. 4, pg. 39-41, 1992.
[KR97] Kantner, L. and Rosenbaum, S. Usability Studies of WWW Sites:
Heuristic Evaluation vs. Laboratory Testing. ACM, 1997. En Proc. del
15 th International Conference on Computer Documentation SIGDOC
'97: Crossroads in Communication. Snowbird, UT. New York, NY: ACM
Press, pg. 153-160, 1997.
[LAI04] LAI-CHONG E. L., HVANNBERG E. T. Analysis of strategies for
improving and estimating the effectiveness of heuristic evaluation. En
Proocedings de NordiCHI '04. ACM Press, 1994.
(http://doi.acm.org/10.1145/1028014.1028051)
[LGP06] LORS J., GONZLEZ M. P., PASCUAL A. Iniciativa UsabAIPO.
Primeros Resultados. En revista Interaccin, vol 1. Asociacin AIPO,
2006 (en prensa).
[LGP05] LORS J., GONZLEZ M. P., PASCUAL A. Primera fase de anlisis del
Proyecto UsabAIPO. En Proceedings del VI Congreso Espaol de
Interaccin Persona Ordenador (INTERACCIN2005), dentro del I
Congreso Espaol de Informtica CEDI05, pg. 217-221, 2005.
[MAY99] MAYHEW D. J. The Usability Engineering Lifecycle: a practitioner's
Handbook for User Interface Design. ACM Press, 1999.
[MD] Molic R., Ede M. R., Kaasgaard K., Karyukin B. Comparative usability
evaluation. En Journal Behav. Inf. Tech., vol.23, num. 1. Taylor &
Francis Inc., pg 65-74, 2004
[MOL90] MOLICH R., NIELSEN J. Improving a human-computer dialogue. En
Communications of the ACM, num33, vol. 3. ACM Press, pg 338-348,
1990.
[MUL98] MULLER M. J., MATHESON L., PAGE C., GALLUP R. Methods & tools:
participatory heuristic evaluation. En Proocedings de Interaction98.
ACM Press, 1998.
(http://doi.acm.org/10.1145/285213.285219)
[MW00] MARCUS A., WEST E. G. Crosscurrents: Cultural Dimensions and
Global Web-User Interface Design. En ACM Interactions, vol VII, num.
4. ACM Press, 2000, pg. 32-46.
[NITA02] NIESLEN J., TAHIR M. Usabilidad de pginas de inicio. Anlisis de 50
sitios Web. Prentice Hall, 2002.
[Nie99] Nielsen, J. Usability engineering at a discount. En G. Salvendy & M.J.
Smith (Eds.), Designing and using human-computer interfaces and
knowledge based systems (pp 394-401). Amsterdam, The
Netherlands: Elsevier Science Publishers, B.V, 1999.
[NIE94] NIELSEN J. Heuristic evaluation. In Nielsen, J., and Mack, R.L. (Eds.),
Usability Inspection Methods, John Wiley & Sons, 1994.
(http://www.useit.com/jakob/inspectbook.html)
[NIE94a] NIELSEN J. Enhancing the explanatory power of usability heuristics.
En Proceedings del ACM CHI'94 Conf. ACM Press, pg 152-158.
[NIE93] NIELSEN J. Usability Engineering. John Wiley & Sons, 1993.
[NIL93] NIELSEN J., LANDAUER T. K. A mathematical model of the finding of
usability problems. En Proocedings de CHI'93. ACM Press, 1993.
(http://doi.acm.org/10.1145/169059.169166)
[NIE92] NIELSEN J. Finding usability problems through heuristic evaluation. En
Proocedings de CHI '92. ACM Press, 1992.
(http://doi.acm.org/10.1145/142750.142834)
[NIE90] NIELSEN J, MOLICH R. Heuristic evaluation of user interfaces. En
Proceedings of ACM CHI 1990. ACM Press, 1990, Pg. 249-256, 1990.
[NIE89] Nielsen, J. Usability engineering at a discount. In G. Salvendy & M.J.
Smith (Eds.), Designing and using human-computer interfaces and
knowledge based systems (pg. 394-401). Elsevier Science
Publishers, B.V, 1989.
[Pie04] PIEROTTI D. Heuristic Evaluation - A System Checklist. Society for
Technical Communication. 1998-2004. Recuperado en junio 2006.
(http://www.stcsig.org/usability/topics/articles/he-checklist.html
[SC99] Slavkovic A., Cross K. Novice Heuristics Evaluation of a Complex
Inter-face. Publicado en Extended Abstracts of the ACM CHI 1999
Conference on Human Factors in Computing Systems, 1999.
[UNET06] Usability Net: International standards for HCI and usability. Disponible
en http://www.usabilitynet.org/tools/r_international.htm (Consultada
en Marzo de 2006).

[SHWP06] SHEN S. T., WOOLEY M., PRIOR S. Towards culture-centred design.
En revista Interacting with Computers (en prensa), 2006, pg. 1-33.
[WRLP94] WHARTON C., RIEMAN J., LEWIS C., POLSON P. The cognitive
walkthrough method: A practitioners guide. En J. Nielsen & R. L. Mack
(Eds.), Usability Inspection Methods, New York: John Wiley & Sons
Inc., 1994, pg. 105-140.

Bibliografa
ALVA M. E., MARTINEZ A. B., CUEVA J. M. Usabilidad: Medicin a travs de
mtodos y herramientas. En Proocedings de Interaccin03. Vigo, 2003.
GRANOLLERS A. MPlu+a. Una Metodologa que integra la Ingeniera del Software,
la Interaccin Persona-Ordenador y la Accesibilidad en el contexto de equipos de
desarrollo multidisciplinares. Tesis doctoral. Universidad de Lrida, 2004.
(http://griho.udl.es/catala/equip/invest/granollers.html)
HASSAN MONTERO Y., MARTIN FERNANDEZ F. J. Gua de Evaluacin Heurstica de
Sitios Web. Publicado en NSU No Solo Usabilidad Magazine, versin digital online,
30 de marzo de 2003. Recuperado en junio 2006.
(http://www.nosolousabilidad.com/articulos/heuristica.htm#identidad)
MANCHON EDUARDO. Un Caso real: Evaluacin Heurstica de renfe.es. Recuperado
de Gestiopolis.com en junio de 2006.
(http://www.gestiopolis.com/canales5/ger/ainda/32.htm)
MULLER J. M., McCLARD A. Validating an extension to participatory heuristic
evaluation: quality of work and quality of work life. En Proocedings de CHI'95. ACM
Press, 1995.
(http://doi.acm.org/10.1145/223355.223457)
PREECE J., ROGERS I., SHARP H. Interaction Design. Beyond Human Computer
Interaction. Chapter 13: Ask Users and Experts. John Wiley & Sons, 2002, pg.
359-389.