---Ev.gif "Modelo de Proceso")
Basándonos en la clasificación propuesta por el tipo de evaluación vista anteriormente (inspección, indagación y test) veremos en este apartado los métodos más destacados de cada una de las tres categorías.
Finalmente encontaremos una Comparativa de los Métodos de Evaluación de la Usabilidad.
El término inspección aplicado a la usabilidad aglutina un conjunto de métodos para evaluar la usabilidad en los que hay unos expertos conocidos como evaluadores que explican el grado de usabilidad de un sistema basándose en la inspección o examen de la interfaz del mismo.
Existen varios métodos que se enmarcan en la clasificación de evaluación por inspección, siendo los que veremos a continuación los más importantes.
El método fue desarrollado por NIELSEN [NIE94a] y MOLICH [MOL90] y consiste en analizar la conformidad de la interfaz con unos principios reconocidos de usabilidad (la "heurística") mediante la inspección de varios evaluadores expertos.
Para aplicar este método [NIEheu], un conjunto de evaluadores 76 expertos en usabilidad contrasta y valida individualmente las "10 reglas heurísticas de usabilidad" -conjunto revisado de reglas heurísticas de usabilidad a partir del análisis de 249 problemas de usabilidad [NIE94a]- con la interfaz del sistema. Tras las revisiones individuales los resultados son puestos en común y debatidos en una reunión entre los evaluadores y el responsable de la evaluación (denominado observador), quienes generan el informe final de la evaluación.
Este método es, sin ninguna duda, el más conocido y utilizado. Tal es así que incluso muchas personas confunden el concepto global de evaluación de la usabilidad con la evaluación heurística y se refieren únicamente al uso de esta técnica cuando indican que evalúan la usabilidad del sistema concreto.
- Aportes concretos de nuestra investigación al método.
Tras probar esta técnica en la mayoría de los proyectos presentados en el MPIu+a hemos definido una plantilla para los evaluadores basada en las 10 reglas de NIELSEN a la que le hemos introducido unas ligeras variaciones:
- Se introduce una parte introductoria destinada a detallar los objetivos del sistema interactivo a probar. Esta parte es común para todos los evaluadores y es redactada por el observador.
- Relacionado con el punto anterior hemos introducido una nueva regla destinada a valorar el grado de transmisión de los objetivos por parte de la interfaz.
- Cada heurística dispone de una serie de sub-reglas (o sub-heurísticas) que
ayudan notablemente a los evaluadores mejorando los resultados de la prueba.
El evaluador, según su criterio, valora para cada aspecto encontrado su:
- Impacto, que mide, en el subheurístico actual, la dificultad que le puede suponer al usuario superar el problema detectado en la interfaz.
- Frecuencia, que indica con qué frecuencia se produce el problema.
- Persistencia del mismo, como indicador de que una vez resuelto el problema en la parte de la interfaz en la que se ha detectado éste continuará produciéndose en otras partes de la misma.
Muestra de la evaluación de la cuarta regla heurística (control y libertad para el usuario)
- Variantes interesantes de la evaluación heurística.
Evaluar la usabilidad de una aplicación interactiva utilizando la técnica de la evaluación heurística tiene un carácter claramente definido hacia aplicaciones genéricas en el que no interviene ningún tipo de usuario (consecuencia de tratarse de un método de inspección).
No obstante, en el contexto del proyecto europeo CHARADE77, se presentó una aproximación centrada en las tareas para el diseño y la evaluación (formativa) de sistemas interactivos, donde una de las principales novedades fue experimentar la respuesta de las evaluaciones heurísticas tras incorporar usuarios [LIN94].
Para ello, se combinó la evaluación heurística con la observación del usuario. A cada usuario representativo se le facilitaron varios escenarios de tareas para que fuese capaz de evaluar cada tarea y completar el informe de la evaluación. Estos usuarios fueron observados durante la ejecución de cada tarea para ver cómo utilizaban la interfaz durante su realización, qué errores cometían, cuánto tiempo tardaban, etc. Ambas técnicas produjeron datos cualitativos y cuantitativos a la vez que destacaron dificultades con algunos usuarios [DUM93]. Los datos recopilados durante la evaluación fueron procesados mediante análisis estadístico para reflejar aspectos relacionados con la usabilidad. Lo que no se especifica en las conclusiones de CHARADE es acerca del verdadero beneficio o perjuicio que aporta la introducción de usuarios en esta técnica.
- Inconvenientes generales de los procedimientos heurísticos.
Los inconvenientes atribuidos al procedimiento heurístico en sí mismo son que los heurísticos suelen ser específicos del problema a tratar y pocas veces sirven para dar una respuesta concreta al problema. En el fondo lo que buscan los heurísticos es reducir el dominio de las posibles soluciones o aspectos de su aplicación para facilitar el proceso de descubrir soluciones o errores.
-
En el terreno específico de evaluación de la interfaz de usuario o del sistema interactivo en general el principal problema es que no hay participación de usuarios representativos.
Herramientas para la Evaluación Heurística (en recursos >> software).
Recomendación: Excelente capítulo del libro "La Interacción Persona-Ordenador" dedicado a la evaluación heurísitica
.Heuristic Evaluation
Usability Body of knowledge.En el marco de la evaluación de sistemas interactivos por inspección los métodos denominados "recorridos" constituyen una aproximación alternativa a la evaluación heurística con los que se intentan predecir problemas de usabilidad sin realizar tests con usuarios.
En general en todos los recorridos se realiza una revisión detallada de todas las acciones asociadas a la consecución de una o más tareas que el usuario debe poder satisfacer con el uso del sistema. Inicialmente fueron pensados para ser realizados por expertos evaluadores con la ayuda de diseñadores, pero, como veremos, también se ha investigado su validez incorporando usuarios.
Una de estas variantes, a la cual hemos denominado recorrido cognitivo con usuarios [GRA04b], es fruto de las investigaciones colaterales del trabajo presentado en esta tesis.
- Recorrido cognitivo
El recorrido cognitivo (Cognitive Walkthrough) es un método de inspección de la usabilidad que se centra en evaluar en un diseño su facilidad de aprendizaje, básicamente por exploración y está motivado por la observación que muchos usuarios prefieren aprender software a base de explorar sus posibilidades [WHA92].
Los pasos necesarios para la realización del método se estructuran en el documento de la evaluación y son los siguientes:
- Definición de los datos necesarios para el recorrido:
- Se identifican y documentan las características de los usuarios ¿Quiénes serán los usuarios del sistema? La descripción de los usuarios incluirá la experiencia específica acumulada y el conocimiento adquirido como factores determinantes para la comprobación del factor "cognitivo" durante el recorrido.
- Se describe también el prototipo a utilizar para la evaluación, que no es preciso que sea ni completo ni detallado.
- Se enumeran las tareas concretas a desarrollar.
- Para cada tarea se implementa por escrito la lista íntegra de las acciones necesarias para completar la tarea con el prototipo descrito. Esta lista consta de una serie repetitiva de pares de acciones (del usuario) y respuestas (del sistema).
- Recorrer las acciones: Los evaluadores realizan cada una de las tareas determinadas
anteriormente siguiendo los pasos especificados y utilizando el prototipo detallado. En este
proceso, el evaluador utilizará la información del factor cognitivo (experiencia y
conocimiento adquirido) de los usuarios para comprobar si la interfaz es
adecuada para el mismo. Esta revisión ha de ser minuciosa para todas las
acciones especificadas para la consecución de la tarea.
Para ello, el evaluador en cada acción criticará el sistema respondiendo a las siguientes preguntas [DIX98]:
- ¿Son adecuadas las acciones disponibles de acuerdo a la experiencia y al conocimiento del usuario?
- ¿Percibirán los usuarios que está disponible la acción correcta? Esto se relaciona con la visibilidad y la comprensibilidad de las acciones en la interfaz. Aquí no se discutirá sobre si la acción se encuentra en el sitio adecuado o no, sino que se incidirá en si ésta está presente y si es visible.
- Una vez encontrada la acción en la interfaz, ¿asociarán estos usuarios la acción correcta al efecto que se alcanzará?
- Una vez realizada la acción, ¿entenderán los usuarios la
realimentación del sistema?. Tanto si la acción se ha realizado con
éxito como en el caso contrario.
- Documentar los resultados
- El evaluador anotará para cada acción las respuestas del sistema y sus anotaciones.
- El documento incluirá un anexo especial, conocido como Usability Problem Report Sheet [DIX98] detallando los aspectos negativos de la evaluación relacionándolos con un grado de severidad que permita distinguir aquellos errores más perjudiciales de los que no lo son tanto.
Algunos autores sólo consideran importante esta parte de la documentación, pues contiene los problemas a solucionar.
- Definición de los datos necesarios para el recorrido:
A pesar de que esta técnica es idónea en la etapa de diseño del sistema puede también ser aplicada durante el resto de etapas.
Ejemplo 1 Ejemplo 2 Ejemplo 3- Recorrido de la Usabilidad Plural
Método desarrollado en los laboratorios IBM [BIA94b] que comparte algunas características con los recorridos tradicionales pero tiene algunas particularidades que lo diferencian, entre las que cabe destacar la intervención de usuarios finales.
Estas características son las siguientes:
- Este método se realiza con tres tipos de participantes, usuarios representativos, desarrolladores y expertos en usabilidad, que conforman todos los actores implicados en el producto.
- Las pruebas se realizan con prototipos de papel u otros materiales utilizados en escenarios. Cada participante dispone de una copia del escenario de la tarea con datos que se puedan manipular.
- Todos los participantes han de asumir el papel de los usuarios, por tanto, aparte de los usuarios representativos que ya lo son, los desarrolladores y los expertos en usabilidad también lo han de asumir.
- Los participantes han de escribir en cada panel del prototipo la acción que tomarán para seguir la tarea que están realizando, escribiendo las respuestas lo más detalladamente posibles.
- Una vez que todos los participantes han escrito las acciones que tomarían cuando interactuaban con cada panel, comienza el debate. En primer lugar, deben hablar los usuarios representativos y una vez éstos han expuesto completamente sus opiniones, hablan los desarrolladores y después los expertos en usabilidad.
El principal beneficio de esta técnica radica en el fuerte enfoque hacia las tareas de los usuarios [PRE02]. Siendo otra importante característica (constatada en los desarrollos del grupo de investigación GRIHO) la gran aceptación del método por los equipos multidisciplinares. En cuanto a las desventajas, la principal de ellas es lo difícil que suele resultar agrupar tanta gente en una sola sesión.
- Recorrido cognitivo con usuarios.
Este método constituye una nueva aportación surgida a partir del estudio realizado con motivo de esta tesis, que supone la primera aproximación conocida de implicar usuarios a los tradicionales recorridos cognitivos78 [GRA04b].
Conocedores de las ventajas de los recorridos cognitivos pero conscientes a la vez de sus principales problemas decidimos comprobar cómo sería de eficiente extender la mencionada técnica incorporando usuarios.
Estos problemas de los recorridos cognitivos a los que nos referimos son:
- La ausencia de usuarios en las sesiones de evaluación es una carencia común en todos los métodos que solamente se basan en los criterios de unos expertos para decidir sobre aspectos concernientes a terceras personas (los usuarios). Este factor es muy importante, pues por muy expertos que sean los evaluadores siempre habrá aspectos que sólo pondrán de manifiesto los verdaderos interesados. Por tanto, al ser el recorrido cognitivo un método donde no intervienen usuarios tiene esta carencia.
- Por otra parte, el evaluador, para recorrer las acciones, constantemente deberá
ser capaz de responder preguntas del tipo ¿serán capaces los usuarios de esta aplicación
de entender determinado icono o metáfora? o ¿dispondrán del conocimiento necesario cuándo
accedan a determinada función?. Respuestas que deberá contestar basándose en la
descripción de las características de los usuarios en términos de su
conocimiento adquirido y de su experiencia acumulada realizada en la primera
fase del método.
El evaluador, por tanto, tiene que fiarse en esta descripción para interpretar si las tareas son adecuadas o no, lo que introduce un primer nivel de posible incertidumbre o de error.
Es más, aunque las descripciones fuesen del todo correctas, siempre queda de la mano del evaluador la última interpretación, añadiendo, por tanto, un segundo nivel de error. - Y un tercer problema derivado también de la ausencia de usuarios (y por tanto aplicable al resto de métodos por inspección), es que no favorece el diseño participativo [GAF99], tan importante desde la perspectiva de la disciplina de la Interacción Persona-Ordenador.
De todas formas, tal incorporación no puede realizarse livianamente. Como resultado de conocer los factores humanos sabemos que cada persona tiene puntos de vista particulares e ideas propias, realizando cada uno ciertas acciones de manera espontánea, rutinaria o inconsciente mientras que otras se ejecutan voluntariamente en la privacidad; este hecho hace que, paradójicamente, "en muchas ocasiones uno mismo no sea el más apropiado para reflejar los propios pensamientos" [SUT02]. Así que en determinadas ocasiones las respuestas que un usuario puede dar serán menos buenas que las de los expertos. El experto en evaluar interfaces de usuario puede conocer lo que los usuarios están pensando mejor que ellos mismos [DIX03].
Adicionalmente tendremos presente que no será habitual disponer en las evaluaciones de personas que encajen con todos los posibles perfiles de usuario definidos, lo que influirá en la orientación de los tipos de tareas que en cada sesión se plantearán.
Todo ello nos hace plantear la nueva forma de realizar la evaluación por recorrido cognitivo con usuarios partiendo de la propia metodología del recorrido cognitivo y proceder a incorporar cautelosamente usuarios, de tal manera que el hecho de solucionar unas carencias no facilite la aparición de otras.
El proceso planteado es el siguiente;
- Realizar el recorrido cognitivo de la manera tradicional.
- Una vez concluido el punto anterior se incorporarán los usuarios de la
siguiente manera:
- Reclutar usuarios representativos del perfil que se desea evaluar.
- Tras una introducción explicando la prueba, el método, los
objetivos y el prototipo se pide a cada usuario que realice de
manera individual el grupo de tareas definidas en el recorrido
correspondientes a su perfil de usuario.
Se pide a los usuarios que expresen libremente en voz alta sus
pensamientos, sentimientos y opiniones sobre cualquier aspecto
(interactividad, diseño, funcionalidad...) mientras interaccionan
con el sistema o el prototipo; característica adoptada del método de
evaluación thinking aloud [NIE93], que más tarde veremos en este
mismo capítulo.
Cada usuario realizará todas las tareas sin recibir más explicaciones que las anteriores y al finalizarlas deberá complementar la información anotando los principales defectos detectados. - Adicionalmente, una vez el usuario ha finalizado las tareas pueden
comentarse los problemas potenciales identificados en el punto (a)
para conocer su punto de vista más detalladamente.
Este punto, aunque adicional, es altamente recomendable.
- Él o los expertos revisarán a posteriori las cuestiones formadas en la etapa (b) para documentar los resultados finales.
El razonamiento seguido para proceder de la forma explicada es el siguiente: Podría pensarse que, tras la incorporación de los usuarios, el recorrido tradicional realizado en primer lugar (punto a) dejaría de ser necesario; no obstante, las razones de mantener dicha actividad son las siguientes:
- El recorrido realizado por un experto aporta la "imparcialidad" necesaria que los usuarios no pueden aportar. Debemos asegurarnos la posibilidad de que el experto descubra problemas diferentes de aquellos que descubriría una vez ya han intervenido usuarios.
- A su vez, proporciona el "punto de entrada" para la etapa (b) permitiendo que el evaluador observe cómo responde el usuario en aquellos puntos que le resultaron más confusos o erróneos.
Por otra parte, en el punto (b) las razones de poner (a) antes de (c) parecen evidentes: por una parte, (iii) es opcional y, por otra, si se invierte el orden quien no realizaría un recorrido de manera imparcial sería el usuario.
Esta variante del método se ha probado en dos sesiones de evaluación correspondientes a dos casos reales de los proyectos realizados en nuestro grupo de investigación. Los resultados de estos casos y las mejoras del método respecto a su predecesor están explicados en [GRA04b] y concretamente uno de ellos, la web del Congreso i2004, corresponde a uno de los casos utilizados como ejemplos en esta tesis.
Además de aumentar considerablemente el número de errores detectados de la incorporación de usuarios al recorrido cognitivo se han observado las siguientes mejoras:
- Si estamos de acuerdo en que un verdadero DCU debe incorporar usuarios [BEV98] estaremos entonces de acuerdo que los métodos que no incorporan usuarios necesitan complementar sus resultados con resultados obtenidos mediante otras técnicas en las que haya intervención de usuarios finales representativos.
- Con la presencia de usuarios se fomenta el diseño participativo [GAF99] y con ello la formación de equipos multidisciplinares tan importantes en la disciplina de la Interacción Persona-Ordenador.
- Con el material previamente preparado para el recorrido cognitivo y gracias a la técnica de pensar en voz alta (thinking aloud) la participación del usuario es más fluida que ubicándole en un laboratorio en el que le cohíba el sentirse observado.
- Las dudas o errores que pueden haber surgido en la primera fase de la evaluación pueden ser contrastadas rápidamente con usuarios finales y evitar así que se creen indecisiones nocivas para el proyecto.
- En muchas ocasiones, el evaluador no es capaz de detectar los errores correctamente debido a que las especificaciones de la experiencia y del conocimiento de los usuarios son inexactas o incompletas. Complementar la evaluación con los usuarios ayudará además a corroborar, a completar o simplemente a mejorar estas descripciones.
Como contrapartida puede indicarse que el método requiere más recursos para su realización: El evaluador necesita invertir mucho más tiempo y es necesario reclutar usuarios y dedicarles el tiempo necesario. No obstante, tras las experiencias realizadas estamos convencidos que la considerable mejora obtenida justifica dicho incremento.
Para evaluar este método se precisa de un evaluador que sea un experto en el o en los estándares a evaluar. El experto realiza una inspección minuciosa a la interfaz para comprobar que cumple en todo momento y globalmente todos los puntos definidos en el estándar establecido.
¿Qué es un estándar?
Un estándar es un requisito, regla o recomendación basada en principios probados y en la práctica. Representa un acuerdo de un grupo de profesionales oficialmente autorizados a nivel local, nacional o internacional [SMI96].
Y tal como indica D. NORMAN, "los estándares son para siempre, porque una vez establecidos simplifican y dominan las vidas de millones, incluso billones de personas" [NOR95].
El teclado qwerty parece una cosa que siempre ha estado con nosotros, al igual que el sistema métrico decimal. ¿Cuál es el lado correcto para conducir en la carretera? ¿El derecho o el izquierdo? Obviamente, no importa, mientras todos hagamos lo mismo, aunque ¿no sería mejor, para los fabricantes de automóviles y los conductores, si se hubiese convenido un estándar único para todo el mundo?. El impacto de acordar y sobre todo cambiar la conducción de todo el mundo por el mismo lado es enorme y por ello (entre otras razones) parece un problema inabordable, a pesar de que los costes derivados de mantener este estándar son mucho mayores.
Y Norman continúa diciendo que " ...con el tiempo los costes descienden, mientras que los estándares permanecen" [NOR95].
De aquí que decidir un estándar no es una tarea que pueda tomarse a la ligera, pues de esta decisión dependerá el futuro, y si ésta no es la mejor, será un lastre perpetuo.
Tipos de estándares.
- Los estándares de iure son generados por un comité con estatus legal y están
avalados por el apoyo de un gobierno o institución para producir estándares.
En informática existen una serie de comités que han participado en la creación de muchos estándares de iure, los más destacados son: La Organización Internacional para Estándares (International Organization for Standardization, ISO), la Comisión Electrotécnica Internacional (International Electrotechnical Commission, IEC), el Instituto Nacional Americano para Estándares (American National Standards Institute, ANSI), la sección Standards Association del Instituto de Ingenieros Eléctricos y Electrónicos Americano (Institute of Electrical and Electronics Engineers, IEEE), el Comité Europeo para la Estandarización (Comité Européen de Normalisation, CEN) y el Consorcio para World Wide Web (World Wide Web Consortium, W3C).
El proceso para generar un estándar de iure es bastante complejo. De forma resumida, los pasos a seguir son: Primero se confecciona un documento preliminar que debe hacerse público para que después cualquier persona o empresa interesada pueda presentar enmiendas de los borradores del documento. Estas enmiendas han de ser comentadas y resueltas. Tras un cierto tiempo, a veces años, se consigue un consenso y se acepta el nuevo estándar.
- Los estándares de facto que nacen a partir de productos de la industria que tienen
un gran éxito en el mercado, o bien a partir de desarrollos hechos por grupos
de investigación de universidades y que tienen una gran difusión.
Estos productos o proyectos de investigación llegan a tener un uso muy generalizado, convirtiéndose, por tanto, en estándares de facto (por ejemplo el sistema de ventanas con la metáfora del escritorio de fondo). Su definición se encuentra en los manuales, libros o artículos. Son técnicamente muy valiosos y muy utilizados.
Realización del método.
Si bien este método podría realizarse partiendo de prototipos de baja fidelidad, lo más efectivo es realizarlo a partir de prototipos software o incluso mejor con una primera versión del sistema final donde estén implementadas las partes que deben confrontarse con el estándar (que normalmente serán aspectos más relacionados con la interfaz que con las funcionalidades).
En fase de análisis de requisitos se define el estándar que el sistema seguirá (ya sea porque es una especificación del proyecto o uno escogido por sus características) y el experto -en dicho estándar- realiza una inspección minuciosa a la totalidad de la interfaz para comprobar que cumple en todo momento y globalmente todos los puntos definidos en el estándar [WIX94]. Durante esta exploración, al experto no le importa la funcionalidad de las acciones que va realizando.
El proceso de indagación trata de llegar al conocimiento de una cosa discurriendo o por conjeturas y señales. En este tipo de métodos de evaluación de la usabilidad una parte muy significativa del trabajo a realizar consiste en hablar con los usuarios y observarlos detenidamente usando el sistema en trabajo real y obteniendo respuestas a preguntas formuladas verbalmente o por escrito.
Los principales métodos de evaluación por indagación son:
La técnica de evaluación conocida como Observación de Campo tiene como principal objetivo entender cómo los usuarios de los sistemas interactivos realizan sus tareas y más concretamente conocer todas las acciones que éstos realizan durante la realización de las mismas. Con ello se pretende capturar toda la actividad relacionada con la tarea y el contexto de su realización así como entender los diferentes modelos mentales que de las mismas tienen los usuarios.
Para realizar una observación de campo [NIE93] el trabajo que se realiza es visitar el lugar o lugares de trabajo donde se estén realizando las actividades objeto de nuestro estudio en las que encontraremos los usuarios representativos que observaremos.
Procedimiento.
Las visitas de campo deben prepararse previamente (la improvisación induce a la indecisión del evaluador e inseguridad a los usuarios que van a ser observados). Básicamente, esta preparación previa consistirá en:
- Escoger una variedad de usuarios representativos del producto (de diversos lugares de trabajo).
- Utilizar el sitio de observación y el tiempo con eficacia. Nuestras visitas no serán ni muchas ni de mucha duración; por tanto, será vital aprovechar el tiempo al máximo y recoger cuanta más información posible; el análisis de ésta puede realizarse después en nuestra oficina.
- Si pensamos complementar la información a partir de los usuarios es preferible elaborar a priori tanto la lista de las preguntas que necesitemos que las personas contesten como la lista de los datos y objetos que pensamos que nos serán útiles.
Una vez en el lugar, el método se compone básicamente de dos partes complementarias:
- Una parte, la principal, es la observación. Observando todo cuanto acontece el lugar de la acción: De qué manera lo hacen, qué objetos utilizan, cómo los utilizan, dónde están ubicados, para qué los utilizan, qué secuencia de acciones siguen, con quién hablan, en qué orden lo hacen, cuál es la finalidad, etc.
- Y la otra, adicional, consiste en preguntar o entrevistar a los usuarios acerca de su trabajo para complementar la información recabada durante la observación.
Al final de una sesión de observación de campo obtendremos una lista de acciones, objetos, personas y en definitiva todo cuanto acontece en el lugar donde se desarrolla la acción que hace o hará referencia al sistema que estamos evaluando.
La fase del ciclo de vida del modelo de proceso más apropiada para realizar este método es, sin duda, durante el Análisis de Requisitos, momento en el que necesitamos conocer el entorno de trabajo, los objetos, las personas, la organización, los métodos, las tareas que se realizan, etc. para poder recoger requisitos necesarios para el diseño del sistema. Y la técnica de análisis más adecuada para su realización es el análisis etnográfico (técnica que se trata en profundidad posteriormente en el apartado dedicado a la fase del análisis de requisitos).
Debe mencionarse que la observación de campo puede resultar obstrusiva e incluso algunos usuarios pueden variar sus hábitos por el hecho de sentirse observados e incluso negarse a ello.
Ejemplo Observación de campo 1
Ejemplo Observación de campo 2
El Focus Group [NIE93] o grupo de discusión dirigido es una técnica de recogida de datos donde se reúnen de 6 a 9 personas (generalmente usuarios y también implicados) para discutir aspectos relacionados con el sistema. En ellos un evaluador experto en usabilidad y/o accesibilidad (dependiendo del objetivo de la evaluación) realiza la función de moderador. Éste preparará previamente la lista de aspectos a discutir y se encargará de recoger la información que necesita de la discusión.
Esto permite capturar reacciones espontáneas e ideas de los usuarios que evolucionan en el proceso dinámico del grupo.
Procedimiento.
Los procedimientos generales para dirigir un Focus Group son:
- Localizar usuarios representativos (típicamente 6 a 9 por sesión) que quieran participar.
- En ocasiones puede haber uno o varios observadores que no intervienen en el debate y sólo toman anotaciones.
- Preparar una lista de temas a discutir y los objetivos a asumir por los temas propuestos.
- El moderador deberá poner especial énfasis en:
- Que todos los participantes contribuyen a la discusión.
- Que no haya un participante que domine la discusión.
- Controlar la discusión sin inhibir el flujo libre de ideas y comentarios.
- Permitir que la discusión discurra libremente en ciertos momentos pero procurando seguir el esquema planeado.
- Al final el moderador (y el o los observadores) realizarán un informe escrito con
los resultados y las conclusiones del debate. Incluirá las opiniones que han
prevalecido y los comentarios críticos de la sesión.
Aspectos a considerar.
Al dirigir un Focus Group hay una serie de aspectos importantes a tener en cuenta:
- Tener más de un grupo principal, puesto que el resultado de una sola sesión puede no ser representativo o incluso que una parte significativa del tiempo de la discusión pudo haberse centrado en aspectos de importancia menor.
- Es preferible que el moderador tenga dotes dinamizadores y comunicativos. No es tan simple como preparar las preguntas y presentarlas a los usuarios; el moderador necesita facilitar y dirigir la discusión en tiempo real y saber sortear hábilmente todo tipo de imprevistos que puedan surgir.
- Debe dudarse siempre de los datos recogidos, porque debido a su naturaleza desestructurada y de flujo libre tienden a tener una validez cuestionable y son muy difíciles de analizar.
El método se puede aplicar en cualquiera de las fases de ciclo de vida del proceso software, aun así en las que más se ha aplicado (y por tanto de la que se tiene mayor experiencia) es en la fase de lanzamiento.
Una entrevista consiste básicamente en una conversación donde uno o varios usuarios reales del sistema que se va a desarrollar o a rediseñar responden a una serie de preguntas relacionadas con el sistema que el entrevistador les va formulando. En este caso, el entrevistador es el evaluador y va tomando nota de las respuestas para obtener las conclusiones finales.
Entrevistar a los usuarios respecto de su experiencia en un sistema interactivo resulta una manera directa y una técnica potente de adquirir información [ALR94]. Las entrevistas pueden ser estructuradas o abiertas (o desestructuradas), en las primeras el evaluador es más rígido en procurar el buen seguimiento del guión preestablecido, mientras que en las abiertas se da espacio a los contertulios a expresarse con más libertad.
Las cuestiones pueden variar con tal de adaptarlas al contexto. Normalmente, en una entrevista se sigue una aproximación de arriba abajo con el objetivo de seguir un discurso ordenado.
Las entrevistas pueden ser efectivas para una evaluación de alto nivel, particularmente para extraer información sobre las preferencias del usuario, impresiones y actitudes. Puede ayudar a encontrar problemas no previstos en el diseño.
Para que la entrevista sea lo más efectiva posible, ha de ser preparada con antelación, con todo un conjunto de preguntas básicas. El revisor puede adaptar la entrevista al entrevistado y obtener el máximo beneficio.
Esta técnica puede ser utilizada en cualquier etapa del ciclo de vida del desarrollo del producto software, pues en función de las necesidades del propio desarrollo precisaremos diferente información.
Aun así, este tipo de evaluación suele realizarse una vez el sistema ya ha sido puesto en marcha, siendo en este caso el principal objetivo captar la satisfacción del cliente o usuario con el producto. El principal problema en estos casos es que si no se ha realizado una correcta planificación de la usabilidad del sistema en ese momento surgen una serie de características que de haber surgido anteriormente se hubieran ahorrado muchos problemas [SAL94].
Técnicamente, el término cuestionario es una lista de cuestiones o preguntas planteadas sobre algún tema con la finalidad de que alguien las responda.
En el ámbito de la evaluación de sistemas interactivos hablamos de cuestionarios para referimos a listas de preguntas que el avaluador distribuye entre usuarios y/o implicados para que éstos nos las devuelvan respuestas y así poder extraer conclusiones. El cuestionario normalmente se distribuye en formato escrito y las preguntas plantean aspectos relacionados con el sistema o aplicación concreta.
Así pues, la base del cuestionario es la recolección de información a partir de respuestas contestadas por los usuarios y/o los implicados.
Los tipos de preguntas a incluir en un cuestionario son:
- Pregunta de carácter general: Preguntas que ayudan a establecer el perfil de usuario y su puesto dentro de la población en estudio. Incluye cuestiones como edad, sexo, ocupación, lugar de residencia, aficiones, estudios, aficiones, etc.
- Pregunta abierta: Preguntas útiles para recoger información general subjetiva. Pueden dar sugerencias interesantes y encontrar errores no previstos.
- Pregunta de tipo escalar: Permite preguntar al usuario sobre un punto específico en una escala numérica.
- Opción múltiple: En este caso se ofrecen una serie de opciones y se pide
responder a una o varias.
Son particularmente útiles para recoger información de la experiencia previa del usuario. Un caso especial es cuando se le dan opciones para contestar si o no.
- Preguntas ordenadas: Se presentan una serie de opciones que hay que ordenar.
Partes de un Cuestionario.
La actividad de la realización de cuestionarios puede estar ligada a la consecución de ciertas tareas que el evaluador ha creído conveniente realizar (actividad combinada de varios métodos de evaluación) para medir aspectos interactivos del sistema. En estos casos es recomendable dividir el cuestionario en tres partes:
- Pre-tarea: Las preguntas de esta sección suelen ser generales acerca de ciertas habilidades del usuario (esta parte suele aprovecharse para recoger información útil acerca del perfil del usuario).
- Post-tarea: Esta sección se repetirá tantas veces como tareas tenga que resolver el usuario.
- Post-test: Esta sección recogerá aspectos generales acerca de la percepción gomal del usuario tras la consecución de las diferentes tareas planteadas.
Reflexión sobre los cuestionarios y las entrevistas: El cuestionario es menos flexible que la entrevista, pero puede llegar a un grupo más numeroso y se puede analizar con más rigor. Se puede utilizar varias veces en el proceso de diseño. A su vez, la entrevista tiene el factor "interactividad" entre el evaluador y el usuario, lo que es una "arma de doble filo": Permite, por una parte, mejorar la comprensión de ciertos aspectos mientras que, por otra, suele acabar con la pérdida de la estructura inicial que el evaluador se había propuesto.
Más adelante, al hablar de las Métricas de Usabilidad (punto 5.6.2.6), veremos una serie de cuestionarios especialmente diseñados para evaluar la usabilidad de los sistemas interactivos.
La técnica grabación de uso, más conocida como análisis de logs o simplemente logging, se basa en "grabar" o "recoger" todas las actividades realizadas por el usuario con el sistema para su posterior análisis. Para ello es preciso de una aplicación secundaria que realice automáticamente esta labor que pase, además, totalmente desapercibida por el usuario.
El logging implica disponer en el ordenador de una ampliación del sistema que recoja automáticamente estadísticas sobre el uso detallado del sistema. Es útil porque muestra cómo los usuarios realizan su trabajo real y porque es fácil recoger automáticamente datos de una gran cantidad de usuarios que trabajan bajo diversas circunstancias [El logging implica disponer en el ordenador de una ampliación del sistema que recoja automáticamente estadísticas sobre el uso detallado del sistema. Es útil porque muestra cómo los usuarios realizan su trabajo real y porque es fácil recoger automáticamente datos de una gran cantidad de usuarios que trabajan bajo diversas circunstancias [PAG02].
Típicamente, un registro de la interfaz contendrá estadísticas sobre la frecuencia con la que cada usuario ha utilizado cada característica en el programa y la frecuencia con que los diversos eventos de interés (tales como mensajes de error) han ocurrido. La estadística que muestra la frecuencia del uso de comandos y de otras características del sistema se puede utilizar para optimizar características usadas frecuentemente y para identificar las características que se no utilizan o se utilizan raramente. La estadística que muestra la frecuencia de las diversas situaciones de error y el uso de la ayuda se puede utilizar para mejorar la usabilidad del sistema (reajustando las características que causan la mayor parte de los errores y la mayoría de los accesos a la ayuda en línea).
Procedimiento.
El registro se realiza generalmente o bien modificando drivers del sistema como por ejemplo del ratón, del teclado o de otras partes del sistema que permitan registrar las acciones del usuario, o modificando la aplicación que estamos probando. Este último método suele ser el preferido, ya que hace más fácil registrar acontecimientos de interés. Si los únicos datos disponibles son entrada de información y salida sin procesar, es mucho más difícil analizar los acontecimientos de gran interés para el uso del sistema, tal como situaciones del uso de alguna característica o de error. Si el sistema equipado se ejecuta en una unidad central o en sitios de trabajo con un espacio compartido del fichero, es fácil recoger datos de registro simplemente copiando los ficheros de diario de cada usuario en los intervalos regulares. Si no, puede ser necesario recoger datos de registro a través de correo electrónico automáticamente o pidiendo que los usuarios ejecuten periódicamente un programa que envíe el fichero por correo.
Características.
Las principales características que definen este método son:
- Resulta ser un método muy económico, puesto que pueden analizarse las acciones de un número de usuarios muy elevado prácticamente con el mismo coste.
- No se necesita la presencia física de los usuarios (o si éste es realizado para analizar sitios web no es necesario ni un espacio especial para la tarea).
- Puede realizarse remotamente, lo que permite evaluar un gran número de datos de infinidad de usuarios sin desplazarse a su lugar de procedencia.
- Los datos suelen tener un formato estándar, lo que facilita la comparación de datos según diferentes criterios (meses, días, semanas, países, etc.).
- Los resultados se obtienen de manera instantánea. No es necesario esperar a un análisis especial de expertos para entender qué ha pasado, ni se necesitan transcripciones, ver cintas de vídeo, etc.
- Permite tener al usuario en su entorno habitual (el log se recoge con el usuario en su ordenador sin sentirse observado, ofreciendo datos más reales sobre el uso).
- Muestras amplias (normalmente estaremos hablando de miles de usuarios).
- Muestreo de los usuarios a lo largo del tiempo, recogiendo así su variabilidad.
- Está especialmente indicado para analizar sitios web: Se detecta fácilmente el verdadero uso del sitio (páginas más vistas, palabras más buscadas, etc.).
- Esta técnica se puede utilizar en las etapas de prueba de versiones avanzadas del sistema, de despliegue o para el rediseño de aplicaciones existentes (caso para el cual es muy indicado).
Puede observarse que esta técnica es muy apropiada para analizar las acciones que los usuarios realizan en los sitios web. El análisis de los archivos de logs que los usuarios anónimamente van dejando en los servidores web permite realizar reajustes al sitio para mejorar, entre otros aspectos, la usabilidad del mismo.
Test
En los métodos de usabilidad por test usuarios representativos trabajan en tareas utilizando el sistema -o el prototipo- y los evaluadores utilizan los resultados para ver cómo la interfaz de usuario soporta a los usuarios con sus tareas.
Los principales métodos de evaluación por test son:
Este método de evaluación está basado en la toma de medidas acerca del rendimiento u otro tipo de aspecto subjetivo que afecte a la usabilidad del sistema, para lo que será necesario disponer bien sea del sistema ya implementado o de un prototipo que permita evaluar estos aspectos.
- Para ello existen una serie de características importantes a tener en cuenta:
- No debemos olvidar que el objetivo primordial es mejorar la usabilidad del producto; no debe confundirse con un test de funcionalidad, que tiene como objetivo garantizar que el producto funcione de acuerdo con las especificaciones.
- Los participantes en el test (que evidentemente serán usuarios reales realizando tareas reales) se analizarán tanto en la manera como utilizan el producto como midiendo el tiempo que les lleva realizarlo.
- A pesar de que también puede realizarse en el entorno del usuario, este método es muy apropiado realizarlo en un laboratorio de usabilidad.
Un aspecto primordial para la realización del test será la selección de tareas que los usuarios deberán realizar. Los siguientes puntos deberán tenerse presentes a la hora de escoger dichas tareas:
- Tareas que demuestren problemas de usabilidad. El criterio más importante para seleccionar tareas es utilizar aquellas que prueben los problemas potenciales de usabilidad del producto.
- Tareas sugeridas por la propia experiencia. Los desarrolladores siempre tienen algunas ideas respecto de dónde encontrar problemas. Saben qué partes del producto fueron más difíciles de diseñar y cuáles son los problemas que se han de probar.
- Tareas derivadas de otros criterios como, por ejemplo, las tareas que son difíciles de recuperar después de un error.
- Tareas que los usuarios harán con el producto. Se seleccionan tareas habituales en el día a día de los usuarios en orden para optimizar la usabilidad de los aspectos más cotidianos.
Funcionamiento del método.
Como se ha mencionado anteriormente, trataremos en primer lugar de comprender qué es lo que se puede medir. Para ello podemos recoger:
- Medidas de rendimiento. Esto quiere decir contar las acciones y los comportamientos. Este tipo de medidas son cuantitativas, pudiéndose contar personas, número de errores cometidos, cuántas veces repiten el mismo error...
- Medidas subjetivas. Esto quiere decir percepciones de las personas, opiniones y juicios. Pueden ser cuantitativas o cualitativas.
En este método de evaluación conocido como "thinking aloud" descrito por NIELSEN [NIE93] se pide a los usuarios y de forma individual que expresen en voz alta y libremente sus pensamientos, sentimientos y opiniones sobre cualquier aspecto (diseño, funcionalidad...) mientras que interaccionan con el sistema o un prototipo del mismo. Resulta ser un método altamente eficaz para capturar aspectos relacionados con las actividades cognitivas de los usuarios potenciales del sistema evaluado.
Procedimiento.
Se proporciona a los usuarios el prototipo a probar y un conjunto de tareas a realizar.
Se les pide que realicen las tareas y que expliquen en voz alta qué es lo que piensan al respecto mientras están trabajando con la interfaz, describiendo qué es lo que creen que está pasando, por qué toman una u otra acción o qué es lo que están intentando realizar. En definitiva, ¡cuantas más impresiones mejor!.
Pensando en voz alta permite a los evaluadores comprender cómo el usuario se aproxima al objetivo con la interfaz propuesta y qué consideraciones tiene en la mente cuando la usa. El usuario puede expresar que la secuencia de etapas que le dicta el producto para realizar el objetivo de su tarea es diferente de la que esperaba.
Aunque el principal beneficio del método es una mejor comprensión del modelo mental del usuario y la interacción con el producto hay, asimismo, otros beneficios como, por ejemplo, conocer la terminología que el usuario utiliza para expresar una idea o función que debería ir incorporada en el diseño del producto o en su documentación.
Este método tiene como ventaja más importante la simplicidad; requiere realmente poca experiencia para poderlo llevar a cabo y puede proporcionar ideas muy útiles acerca de los problemas con una interfaz [DIX93, pág. 386].
Otras ventajas importantes del método son:
- Que puede ser utilizado para observar cómo el sistema se utiliza actualmente (complemento para el método de Observación de Campo visto anteriormente).
- Que puede realizarse en todas las fases del ciclo de vida (incluso en las más iniciales) y con cualquier tipo de prototipo.
- Que se trata de un método muy económico.
Y como principales inconvenientes tenemos:
- La información proporcionada es subjetiva y selectiva (dependerá de las tareas escogidas).
- El proceso de observación puede alterar la manera en la que los usuarios realizarán sus tareas, pudiendo obtener vistas parciales (describir lo que uno hace a menudo cambia la forma de hacerlo).
Variante del método.
Una variante del thinking aloud es método conocido como evaluación cooperativa, que estimula al usuario a verse a sí mismo como un colaborador de la evaluación más que un simple sujeto experimental.
Este método, conocido también con el nombre de aprendizaje por codescubrimiento, es una derivación del pensando en voz alta e implica tener, en vez de uno, a dos usuarios realizando conjuntamente cada test del sistema [OMA84].
La principal ventaja de este método es que la situación del test es mucho más natural que el pensar en voz alta con usuarios individuales, ya que las personas normalmente verbalizan cuando tratan de resolver un problema conjuntamente y además hacen muchos más comentarios.
Este método tiene la desventaja que los usuarios pueden tener diferentes estrategias de aprendizaje.
Un aspecto a tener en cuenta es que la interacción constructiva requiere el doble de usuarios que el método de pensar en voz alta, aspecto importante a considerar si ello puede tener repercusiones económicas.
Si se ha realizado una grabación en vídeo de la sesión de test es posible recoger más información haciendo que el usuario revise la grabación [HEW87].
Los comentarios del usuario mientras está revisando el vídeo son más extensos que mientras ha estado trabajando en la tarea de test y, por tanto, es posible que el evaluador pare el vídeo y pregunte al usuario con más detalle sin tener miedo de interferir con el test que esencialmente ha sido completado.
El aspecto negativo más evidente es que con cada usuario se tarda como mínimo el doble del tiempo necesario con cualquier otro método.
El método del conductor [MAC92] es algo diferente de estos métodos de test vistos hasta ahora en los que hay una interacción explícita entre el usuario y el evaluador (o conductor). El último trataba de interferir lo menos posible al usuario mientras realizaba el test.
Este caso resulta ser totalmente al contrario en este aspecto: Se conduce al usuario en la dirección correcta mientras se usa el sistema.
Durante el test, el usuario puede preguntar al evaluador cualquier aspecto relacionado con el sistema y éste le responderá.
Este método se centra en el usuario inexperto y el propósito del mismo es descubrir las necesidades de información de los usuarios de tal manera que se proporcione un mejor entrenamiento y documentación al mismo tiempo que un posible rediseño de la interfaz para evitar la necesidad de preguntas.
Este método tiene un enfoque distinto a los presentados anteriormente y a pesar de que, como veremos, suele asociarse con la implementación de la Arquitectura de la Información80 en el diseño de sitios web, es un método completamente válido para relacionar la información de cualquier medio interactivo.
Al comenzar un nuevo ejercicio de diseño de la información es normal encontrarse con una larga lista de ítems sin relacionar que "hay que incluir" y "no sabemos cómo hacerlo". El reto radica en organizar esta información de manera que sea útil y comprensible para los usuarios del sistema.
Aunque es cierto que cuidadas investigaciones sobre el análisis de la información pueden revelar algunas pistas, difícilmente podrá determinarse qué tópicos deben agruparse entre ellos.
La técnica conocida como ordenación de tarjetas, o card sorting, es la utilizada para conocer cómo los usuarios visualizan la organización de la información. El diseñador utiliza las aportaciones de los usuarios para decidir cómo deberá estructurarse la información en la interfaz.
Se trata de una técnica simple -fácil de entender y de aplicar-, barata, rápida y que involucra a los usuarios, que es especialmente indicada cuando disponemos de una serie de ítems que precisen ser catalogados, así como para decidir la estructura organizativa de cualquier sistema de información.
Esta técnica tiene demostrada utilidad para desarrollar sitios web, para la cual está especialmente recomendada [BEV03].
Realización.
Los pasos a seguir para implementar una ordenación de tarjetas son los siguientes:
- Determinar la lista de tópicos Identificar la lista de los ítems a ordenar. Esta lista no debería ser muy extensa (ha de ser manejable) a la vez que debe ser comprensible para todos los participantes de la sesión. El evaluador no debe poner ningún tipo de indicación que pueda influenciar a los usuarios es su decisión, así como ningún tópico que induzca a la agrupación de términos (ej.: Archivo, edición, FAQs).
- Crear las tarjetas Cada tópico deberá escribirse en una tarjeta (papel, cartón) que ocasionalmente puede adjuntar algún tipo de explicación (aunque no es muy recomendable). Deberá, además, proporcionar unas cuantas tarjetas en blanco a los participantes.
- Seleccionar a los participantes Los participantes preferentemente serán usuarios finales (gerentes y otros implicados no son usuarios finales) de quienes deberemos estar seguros que representan fielmente a grupos de usuarios potenciales del sistema.
- Proceder con la/s sesión/es de ordenación
Cada sesión debe comenzar con una explicación del método y de los
objetivos animando a todos los participantes a organizar las tarjetas y
etiquetar, en las tarjetas en blanco, los grupos según sus criterios personales.
El organizador de la sesión debe tomar nota de todo aquello que pueda resultar relevante para la evaluación final.
![Sesión de ordenación de tarjetas correspondiente al sitio web del Congreso i2004, realizado con la ayuda del programa CardZort [TOR01]](imatges/card2.jpg "Sesión de ordenación de tarjetas correspondiente al sitio web del Congreso i2004, realizado con la ayuda del programa CardZort [TOR01]")
- Analizar las agrupaciones
Una vez han concluido todos, el evaluador deberá analizar todas las agrupaciones en un ejercicio de "análisis democrático" para identificar aquellas agrupaciones más frecuentes para poder decidir la estructura final.
Existen programas informáticos específicos [TOR01] que pueden ayudarnos mucho en esta labor de síntesis.
Errores a evitar.
La constante aplicación de esta técnica en todos los proyectos relacionados demuestra que el grado de conocimiento que aporta la experiencia práctica está por encima de la teoría de dicho conocimiento, lo que ha dado lugar a una relación de errores típicos que no se encuentran referenciados en la bibliografía científica. Los errores más frecuentes son:
- Los resultados de las agrupaciones suelen carecer de la fiabilidad necesaria si la comunicación previa a la realización del test con el usuario no ha sido la apropiada. El evaluador debe expresarles los objetivos claros de la prueba de forma "muy concreta" para que los usuarios sepan "exactamente que se espera de ellos" durante la prueba.
- Por otra parte, el evaluador suele caer en la falsa tentación de "querer facilitar el trabajo de los usuarios". Con tal objetivo reduce el número total de tarjetas a base de crear tarjetas que en realidad son agrupaciones de unidades de información con entidad propia, lo que confunde al usuario y dificulta el análisis de los resultados esperados.
Comparativa de los Métodos de Evaluación de la Usabilidad
A continuación (en un enlace) se presenta un cuadro que resume los métodos de evaluación de la usabilidad presentados con la finalidad de disponer de una perspectiva global que permita ver, entre otras cosas, las principales características de cada uno de ellos en relación a las diferentes clasificaciones mostradas, los momentos del ciclo de vida más adecuados para su aplicación o el reflejo de cada uno de ellos respecto a los parámetros que definen la usabilidad.
El cuadro también indica si los resultados obtenidos son cuantitativos o no lo son, o sea, si al final de la prueba dispondremos de una lista de errores o mejoras detectados o de acciones concretas a realizar, o si contrariamente disponemos de un conjunto de datos que posteriormente deben analizarse.
