tesis web transaccionales-rof

PONTIFICIA UNIVERSIDAD CATÓLICA DE VALPARAÍSO

FACULTAD DE INGENIERÍA

ESCUELA DE INGENIERÍA INFORMÁTICA

METODOLOGÍA DE EVALUACIÓN DE USABILIDAD PARA

APLICACIONES WEB TRANSACCIONALES

RENATO ALEJANDRO OTAÍZA FUENTES

TESIS DE GRADO

MAGÍSTER EN INGENIERÍA INFORMÁTICA

DICIEMBRE 2008

Pontificia Universidad Católica de Valparaíso Facultad de Ingeniería

Escuela de Ingeniería Informática

METODOLOGÍA DE EVALUACIÓN DE USABILIDAD PARA

APLICACIONES WEB TRANSACCIONALES

RENATO ALEJANDRO OTAIZA FUENTES

Profesor Guía: Cristian Alexandru Rusu

Programa: Magíster en Ingeniería Informática

Diciembre 2008

RESUMEN

La usabilidad se considera como uno de los atributos básicos de cualquier sistema software interactivo. Corresponde

a un concepto que engloba una serie de métricas y métodos con el objetivo de obtener sistemas fáciles de usar y de

aprender. Los métodos de evaluación de usabilidad, que permiten medir la aplicación de este atributo, son bastante

diversos. Su realización depende de variables tales como los costos, la disponibilidad de tiempo y recursos humanos

que interpreten los resultados, entre otras. Esta investigación se enfoca en el estudio de los métodos de evaluación de

usabilidad en aplicaciones web transaccionales, contrastando sus características, y entregando una propuesta de una

metodología de evaluación, con el fin de obtener la mayor cantidad de información relevante respecto de la

usabilidad de este tipo de aplicaciones.

Palabras Clave: Usabilidad, Metodología de Evaluación de Usabilidad, Aplicaciones Web Transaccionales.

ABSTRACT

The usability is considered one of the basic attributes of any interactive software system. It is a concept that includes

a set of metrics and methods with the objective to obtain software easy to use and easy to learn. The usability

evaluation methods, that allow the measurement of the usability attribute, are very diverse. Its realization depends of

variables like the costs, the time availability and human resources that interpret the results, among others. This

investigation is focused in the analysis of the usability evaluation methods in transactional web applications,

contrasting its characteristics, and delivering a proposal of a usability evaluation methodology, with the objective to

obtain the major amount of relevant information when evaluating this type of applications.

Keywords: Usability, Usability Evaluation Methodology, Transactional Web Applications.

“Metodología de Evaluación de Usabilidad para Aplicaciones Web Transaccionales”

Tesis de Grado – Magíster en Ingeniería Informática Página i

CONTENIDO

LISTA DE FIGURAS ............................................................................................................................................ iv LISTA DE TABLAS .............................................................................................................................................. v GLOSARIO DE TÉRMINOS ................................................................................................................................ vi

1. INTRODUCCIÓN .......................................................................................................................................... 1 1.1. Discusión Bibliográfica................................................................................................................................... 2 1.2. Descripción del Problema ............................................................................................................................... 3

2. DEFINICIÓN DEL PROYECTO .................................................................................................................... 4 2.1. Objetivos del Proyecto .................................................................................................................................... 4

2.1.1. Objetivo General .................................................................................................................................... 4 2.1.2. Objetivos Específicos.............................................................................................................................. 4

2.2. Metodología de Trabajo .................................................................................................................................. 5 2.3. Plan de Trabajo ............................................................................................................................................... 6 2.4. Hipótesis del Proyecto .................................................................................................................................... 9

3. INGENIERÍA WEB ..................................................................................................................................... 10 3.1. Definiciones ................................................................................................................................................. 10 3.2. Aplicaciones Web ......................................................................................................................................... 13

4. USABILIDAD ............................................................................................................................................. 17 4.1. ¿Qué es la Usabilidad? .................................................................................................................................. 17 4.2. Atributos de Usabilidad ................................................................................................................................ 20 4.3. Paradigmas de Usabilidad ............................................................................................................................. 24 4.4. Principios de Usabilidad ............................................................................................................................... 25 4.5. La Usabilidad en la Web ............................................................................................................................... 27

4.5.1. Problemas de Usabilidad Comunes en la Web ....................................................................................... 27 4.5.2. Beneficios de la Usabilidad en la Web................................................................................................... 28

5. MÉTODOS DE EVALUACIÓN DE USABILIDAD .................................................................................... 29 5.1. Métodos de Inspección de Usabilidad ............................................................................................................ 32

5.1.1. Evaluación Heurística ........................................................................................................................... 32 5.1.1.1. Evaluadores ............................................................................................................................... 33 5.1.1.2. Heurísticas ................................................................................................................................. 35 5.1.1.3. Técnica ...................................................................................................................................... 35

5.1.2. Recorrido Cognitivo ............................................................................................................................. 39 5.1.2.1. Preparación del Recorrido Cognitivo .......................................................................................... 39 5.1.2.2. Desarrollo del Recorrido Cognitivo ............................................................................................ 40

5.1.3. Análisis de Acciones ............................................................................................................................. 41 5.1.3.1. Análisis de Acciones Formal ...................................................................................................... 41 5.1.3.2. Análisis de Acciones Informal .................................................................................................... 43

5.2. Métodos de Prueba de Usabilidad.................................................................................................................. 44 5.2.1. Pruebas en Papel ................................................................................................................................... 49 5.2.2. Pensando en Voz Alta ........................................................................................................................... 51 5.2.3. Interacción Constructiva ....................................................................................................................... 52 5.2.4. Experimentos Formales......................................................................................................................... 52 5.2.5. Técnicas de Interrogación ..................................................................................................................... 53 5.2.6. Ordenamiento de Tarjetas ..................................................................................................................... 53

5.3. Análisis Comparativo de los Métodos de Evaluación de Usabilidad ............................................................... 55


Tesis de Grado – Magíster en Ingeniería Informática Página ii

6. MÉTODOS DE EVALUACIÓN DE USABILIDAD EN APLICACIONES WEB TRANSACCIONALES.... 63 6.1. Caso de Estudio: Prototipo Web Cadena de Supermercados ........................................................................... 66

6.1.1. Evaluaciones Realizadas ....................................................................................................................... 67 6.1.1.1. Evaluación Heurística ................................................................................................................ 68 6.1.1.2. Pruebas en Papel ........................................................................................................................ 76 6.1.1.3. Pensamiento en Voz Alta ........................................................................................................... 80 6.1.1.4. Interacción Constructiva............................................................................................................. 83 6.1.1.5. Experimentos Formales .............................................................................................................. 86 6.1.1.6. Técnicas de Interrogación........................................................................................................... 90 6.1.1.7. Ordenamiento de Tarjetas........................................................................................................... 93

6.1.2. Análisis de Resultados .......................................................................................................................... 96 6.1.2.1. Tiempos Involucrados ................................................................................................................ 96 6.1.2.2. Problemas Identificados ............................................................................................................ 100

6.2. Caso de Estudio: Navegador Académico PUCV ........................................................................................... 104 6.2.1. Evaluaciones Realizadas ...................................................................................................................... 106

6.2.1.1. Evaluación Heurística ............................................................................................................... 106 6.2.1.2. Pruebas en Papel ....................................................................................................................... 114 6.2.1.3. Pensamiento en Voz Alta .......................................................................................................... 117 6.2.1.4. Interacción Constructiva............................................................................................................ 119 6.2.1.5. Experimentos Formales ............................................................................................................. 121 6.2.1.6. Técnicas de Interrogación.......................................................................................................... 125 6.2.1.7. Ordenamiento de Tarjetas.......................................................................................................... 128

6.2.2. Análisis de Resultados ......................................................................................................................... 130 6.2.2.1. Tiempos Involucrados ............................................................................................................... 130 6.2.2.2. Problemas Identificados ............................................................................................................ 133

6.3. Particularización de los Métodos de Evaluación de Usabilidad sobre Aplicaciones Web Transaccionales ...... 136

7. METODOLOGÍA DE EVALUACIÓN DE USABILIDAD PARA APLICACIONES WEB

TRANSACCIONALES ....................................................................................................................................... 140 7.1. Propuesta de Metodología de Evaluación de Usabilidad ............................................................................... 140 7.2. Validación de la Metodología Mediante Sistema Biblioteca PUCV ............................................................... 145

7.2.1. Evaluaciones Realizadas ...................................................................................................................... 147 7.2.1.1. Evaluación Heurística ............................................................................................................... 148 7.2.1.2. Interacción Constructiva............................................................................................................ 156 7.2.1.3. Experimentos Formales ............................................................................................................. 159 7.2.1.4. Técnicas de Interrogación.......................................................................................................... 162

7.2.2. Análisis de Resultados ......................................................................................................................... 164 7.3. Conclusiones sobre la Metodología .............................................................................................................. 165

8. CONCLUSIONES ....................................................................................................................................... 168 8.1. Cumplimiento de Objetivos.......................................................................................................................... 169 8.2. Trabajo Futuro ............................................................................................................................................. 170

REFERENCIAS .................................................................................................................................................. 171

ANEXOS ............................................................................................................................................................ 172 Anexo 1: Documento Evaluación Heurística para Evaluadores.............................................................................. 173 Anexo 2: Acuerdo de Confidencialidad ................................................................................................................ 177 Anexo 3: Evaluación Heurística Prototipo Web Cadena Supermercados................................................................ 179 Anexo 4: Evaluación Heurística Navegador Académico PUCV ............................................................................ 181 Anexo 5: Evaluación Heurística Sistema Biblioteca PUCV ................................................................................... 184 Anexo 6: Listado de Tareas Experimentos Formales Prototipo Web Cadena Supermercados ................................. 187 Anexo 7: Listado de Tareas Experimentos Formales Navegador Académico PUCV .............................................. 189


Tesis de Grado – Magíster en Ingeniería Informática Página iii

Anexo 8: Listado de Tareas Experimentos Formales Sistema Biblioteca PUCV .................................................... 191 Anexo 9: Cuestionario Prototipo Web Cadena Supermercados .............................................................................. 193 Anexo 10: Cuestionario Navegador Académico PUCV ......................................................................................... 195 Anexo 11: Cuestionario Sistema Biblioteca PUCV ............................................................................................... 197


Tesis de Grado – Magíster en Ingeniería Informática Página iv

LISTA DE FIGURAS

Figura 3.1: Categorías de Aplicaciones Web ........................................................................................................ 14 Figura 4.1: Modelo de Calidad de Software de la ISO .......................................................................................... 20 Figura 4.2: Modelo de los Atributos de Aceptabilidad de un Sistema .................................................................... 22 Figura 5.1: Problemas Identificados Evaluación Heurística de un Sistema Bancario .............................................. 33 Figura 5.2: Número de Evaluadores vs Proporción de Problemas Encontrados ...................................................... 34 Figura 5.3: Número de Evaluadores vs Relación Costo/Beneficio ......................................................................... 34 Figura 5.4: Laboratorio de Usabilidad Simple ...................................................................................................... 46 Figura 5.5: Laboratorio de Usabilidad Completo .................................................................................................. 47 Figura 5.6: Ejemplo de Prototipo en Papel ............................................................................................................ 50 Figura 6.1: Página Inicial del Prototipo de Sistema Web de la Cadena de Supermercados ..................................... 66 Figura 6.2: Sección Crédito del Prototipo de Sistema Web de la Cadena de Supermercados .................................. 67 Figura 6.3: Prototipo en Papel Página Inicial de Prototipo Web Cadena Supermercados ........................................ 77 Figura 6.4: Prototipo en Papel Sección Crédito de Prototipo Web Cadena Supermercados .................................... 78 Figura 6.5: Página con Información Beneficios de Prototipo Web Cadena Supermercados .................................... 81 Figura 6.6: Página Principal del Navegador Académico, Perfil Jefe de Docencia.................................................. 104 Figura 6.7: Página de Matrículas del Alumno del Navegador Académico ............................................................. 105 Figura 6.8: Prototipo en Papel Página Principal del Navegador Académico .......................................................... 115 Figura 6.9: Prototipo en Papel Página de Búsqueda de la Sección Alumnos ......................................................... 116 Figura 7.1: Metodología de Evaluación para Aplicaciones Web Transaccionales - Evaluación Global .................. 142 Figura 7.2: Metodología de Evaluación para Aplicaciones Web Transaccionales - Evaluación Específica............. 143 Figura 7.3: Metodología de Evaluación para Aplicaciones Web Transaccionales - Factor Tiempo No Es Crítico .. 144 Figura 7.4: Página Inicial Sistema Biblioteca PUCV ........................................................................................... 145 Figura 7.5: Sección de Búsqueda del Sistema Biblioteca de la PUCV .................................................................. 146


Tesis de Grado – Magíster en Ingeniería Informática Página v

LISTA DE TABLAS

Tabla 2.1: Etapas del Proyecto ............................................................................................................................... 7 Tabla 2.2: Plan de Trabajo del Proyecto ................................................................................................................. 8 Tabla 3.1: Categorías de Aplicaciones Web .......................................................................................................... 15 Tabla 4.1: Medición de los Atributos de Usabilidad .............................................................................................. 23 Tabla 5.1: Escala de Severidad ............................................................................................................................. 38 Tabla 5.2: Escala de Frecuencia ........................................................................................................................... 38 Tabla 5.3: Tiempos Promedio de un Análisis de Acciones Típico ......................................................................... 42 Tabla 5.4: Ventajas y Desventajas de los Métodos de Evaluación de Usabilidad .................................................... 55 Tabla 5.5: Tabla Comparativa de los Métodos de Inspección de Usabilidad .......................................................... 59 Tabla 5.6: Tabla Comparativa de los Métodos de Prueba de Usabilidad ................................................................ 60 Tabla 6.1: Principios de Usabilidad en Aplicaciones Web Transaccionales ........................................................... 68 Tabla 6.2: Problemas de Usabilidad Evaluación Heurística por Principio .............................................................. 70 Tabla 6.3: Problemas Encontrados con la Evaluación Heurística ........................................................................... 71 Tabla 6.4: Ranking con los Problemas con Mayor Criticidad ................................................................................ 74 Tabla 6.5: Problemas Identificados con el Pensamiento en Voz Alta ..................................................................... 82 Tabla 6.6: Problemas Identificados con la Interacción Constructiva ...................................................................... 84 Tabla 6.7: Definición de Tareas para los Experimentos Formales .......................................................................... 87 Tabla 6.8: Resultados Experimentos Formales ...................................................................................................... 88 Tabla 6.9: Preguntas del Cuestionario................................................................................................................... 90 Tabla 6.10: Promedio de las Respuestas al Cuestionario ....................................................................................... 91 Tabla 6.11: Agrupación Actual de “Tarjetas” Prototipo Web Cadena de Supermercados ....................................... 94 Tabla 6.12: Tiempos Involucrados en las Etapas de los Métodos de Evaluación .................................................... 98 Tabla 6.13: Tiempos Involucrados en las Etapas de los Métodos de Evaluación por Escala de Tiempo .................. 99 Tabla 6.14: Problemas Evaluación Heurística confirmados por Métodos de Prueba .............................................. 102 Tabla 6.15: Problemas de Usabilidad Evaluación Heurística por Principio ........................................................... 107 Tabla 6.16: Lista Completa de Problemas Identificados por la Evaluación Heurística ........................................... 108 Tabla 6.17: Ranking de Problemas por Criticidad ................................................................................................ 112 Tabla 6.18: Problemas Identificados con el Pensamiento en Voz Alta .................................................................. 118 Tabla 6.19: Problemas Identificados mediante la Interacción Constructiva ........................................................... 120 Tabla 6.20: Definición de Tareas para Experimentos Formales ............................................................................ 122 Tabla 6.21: Resultados del Experimento Formal .................................................................................................. 123 Tabla 6.22: Preguntas del Cuestionario ................................................................................................................ 125 Tabla 6.23: Promedios de las Respuestas al Cuestionario ..................................................................................... 126 Tabla 6.24: Agrupación Actual de las “Tarjetas” del Navegador Académico ........................................................ 128 Tabla 6.25: Tiempos de Desarrollo de los Métodos de Evaluación por Etapas ...................................................... 131 Tabla 6.26: Tiempos Involucrados en las Etapas de los Métodos de Evaluación por Escala de Tiempo ................. 132 Tabla 6.27: Problemas de Evaluación Heurística Confirmados por Métodos de Prueba......................................... 134 Tabla 6.28: Ventajas y Desventajas de los Métodos de Evaluación de Usabilidad en Aplicaciones Web

Transaccionales ................................................................................................................................................... 136 Tabla 6.29: Tiempos de los Métodos de Evaluación de Usabilidad en Aplicaciones Web Transaccionales ............ 139 Tabla 6.30: Características Sobresalientes de los Métodos de Evaluación de Usabilidad ....................................... 139 Tabla 7.1: Problemas de Usabilidad Identificados por Principio ........................................................................... 149 Tabla 7.2: Problemas Identificados Evaluación Heurística ................................................................................... 150 Tabla 7.3: Ranking de Problemas por Criticidad .................................................................................................. 155 Tabla 7.4: Problemas Identificados Interacción Constructiva ............................................................................... 157 Tabla 7.5: Definición de Tareas para Experimentos Formales .............................................................................. 160 Tabla 7.6: Resultados de los Experimentos Formales ........................................................................................... 161 Tabla 7.7: Preguntas del Cuestionario.................................................................................................................. 162 Tabla 7.8: Resultados del Cuestionario ................................................................................................................ 163 Tabla 7.9: Metodología de Evaluación de Usabilidad para Aplicaciones Web Transaccionales ............................. 167


Tesis de Grado – Magíster en Ingeniería Informática Página vi

GLOSARIO DE TÉRMINOS

Actividad: Conjunto de tareas que se realizan para lograr un objetivo específico.

Error: Diferencia entre un valor o condición computada, observada o medida y el valor o condición verdadero,

específico o teóricamente correcto.

Link o Enlace: Referencia que conecta dos nodos en la web, usando fuentes y áreas de destino únicas con esos

nodos.

Metodología: Procedimientos que permiten llegar al conocimiento de la verdad específica.

Proceso: Conjunto de actividades que se realizan para lograr un propósito específico.

Proceso Incremental: Un proceso es incremental si el sistema en desarrollo es creado gradualmente expandiendo su

funcionalidad, por ejemplo, sucesivas versiones expanden la funcionalidad disponible mediante incrementos. Un

incremento es una parte pequeña y manejable de un sistema.

Proceso Iterativo: Un proceso es iterativo si el producto final es creado por un conjunto diverso de actividades que

resultan en una versión externa o interna.

Prototipo: Modelo de un sistema a ser implementado. Tienen un ancho rango de niveles de maduración, desde

prototipos en papel hasta prototipos electrónicos altamente funcionales.

Tarea: Unidad atómica de trabajo que puede administrarse.


Tesis de Grado – Magíster en Ingeniería Informática Página 1

1. INTRODUCCIÓN

El creciente desarrollo del comercio electrónico y el desplazamiento de la gran mayoría de las

organizaciones hacia la Web, entre muchos otros factores, han generado un gran aumento y una constante evolución

de las aplicaciones web. En la actualidad, se nota claramente el aumento de las transacciones financieras en línea, la

transferencia de gran cantidad de archivos e información confidencial en línea y la ejecución de procesos en línea,

entre muchas otras cosas. Esto implica un constante desafío, como es controlar y mejorar la calidad de las

aplicaciones web, su desarrollo y mantenimiento, lo cual se traduce en la calidad de sus atributos: funcionalidad,

fiabilidad, eficiencia, mantenibilidad, usabilidad, portabilidad.

Generalmente, los desarrolladores prestan mucha atención en lo que son los atributos relacionados con las

características de cierta forma más internas del sistema, sin considerar de la forma correcta la parte de la interacción

del usuario con el propio sistema, situación que toma mayor relevancia al hablar de aplicaciones web, cuya principal

característica es la interacción con el usuario.

Uno de los factores más importantes al evaluar la calidad de una aplicación web y de cualquier software

corresponde al éxito o fracaso del usuario en las tareas que realiza. La satisfacción del usuario durante la realización

de estas tareas, y el entendimiento real de la estructura del sistema con el cual interactúa también son factores a

considerar. Esto es lo que se denomina como la experiencia de uso. En una palabra, usabilidad.

Así, la usabilidad se considera como uno de los atributos básicos de cualquier sistema software interactivo.

Corresponde a un concepto que engloba una serie de métricas y métodos con el objetivo de obtener sistemas fáciles

de usar y de aprender. Es el atributo más visible, puesto que determina la satisfacción del usuario con el sistema, lo

que a su vez determina la postura de éste al volver a utilizar este mismo sistema. En muchos casos, la realización de

pequeñas mejoras en la usabilidad de un sistema contribuye a un significativo aumento de la calidad de la

experiencia del usuario con el sistema.

Los métodos de evaluación de usabilidad, que permiten medir la aplicación de éste atributo en cierto sistema

y bajo ciertos factores, son bastante diversos. Su realización depende de variables tales como los costos, la

disponibilidad tiempo y recursos humanos que interpreten los resultados, entre otros. Así, no es trivial la elección de

cuál método de evaluación llevar a cabo para medir la usabilidad de una aplicación web.

Esta investigación se enfoca en el estudio de los métodos de evaluación de usabilidad en aplicaciones web

transaccionales, contrastando sus características, y entregando una propuesta de una metodología de evaluación de

usabilidad, con el fin obtener la mayor cantidad de información relevante respecto de la usabilidad de estas

aplicaciones web transaccionales, considerando tiempos involucrados en las evaluaciones, criticidad de los

problemas de usabilidad encontrados, etcétera.



1.1. Discusión Bibliográfica

El término usabilidad, y todos los aspectos que involucra, ha tenido un despliegue bastante grande dentro de

los últimos años. Ha pasado de ser un término usado por grupos de investigadores y unos pocos desarrolladores de

software a ser parte del vocabulario relativamente común en muchas áreas, principalmente las relacionadas con la

informática.

Uno de los artículos de la publicación española “Anuario ThinkEPI” del año 2007 [1], da a conocer todo

este impacto de la usabilidad, y el boom que está poco a poco desatando. Este artículo se enfoca en lo que es la

usabilidad en España, pero, tal como dice su propia autora, es perfectamente aplicable a muchos otros países.

La usabilidad y algunos de sus términos afines como diseño de la interacción, diseño centrado en el usuario,

interacción persona-computador, etcétera, están pasando por un momento de “moda” en el mejor de los sentidos [1].

Así describe la autora toda esta situación, que claramente está generando cierto impacto e interés, principalmente

observado por el surgimiento de empresas encargadas exclusivamente de la presencia de este atributo en los sistemas

de sus clientes, la creciente consideración de la usabilidad en el desarrollo de software, charlas y congresos de la

usabilidad, la inserción de asignaturas relacionadas con este tema en las mallas curriculares de carreras profesionales

y programas de postgrado, etcétera.

Una de las posibles razones de este fenómeno está en la evolución de los tipos de usuarios de las

Tecnologías de Información y Comunicación (TIC) y el papel protagonista que estos han asumido de manera

paulatina y que, sin duda, los expertos e investigadores han sabido apreciar. Estos se han dado cuenta de la gran

importancia del usuario y de cómo se siente durante la interacción, tal como se explica en una de las publicaciones de

la revista “No Solo Usabilidad”: en general, cuando el usuario puede hacer uso de TIC usables se siente más

satisfecho que cuando no puede hacer uso de los requisitos básicos de usabilidad en las mismas [2].

Asimismo, la identificación de distintos tipos de usuarios ha sido factor influyente en esta revolución que la

usabilidad ha generado en el último tiempo. Otra de las interesantes publicaciones de la revista “No Solo Usabilidad”

habla de la capacidad de los usuarios actuales para aportar, difundir, compartir y colaborar [3], sintiéndose un actor

principal, lo cual se relaciona directamente con el hecho de disponer de aplicaciones cada vez más usables, diseñadas

para el usuario.

Finalmente, se puede decir que el boom de la usabilidad es claro tanto a nivel mundial como particularmente

en Chile, aunque en menor grado. La usabilidad ha logrado penetrar, sustancialmente, en el vocabulario común

principalmente de los profesionales, investigadores y estudiantes del área informática, y este denominado boom sigue

en crecimiento. Por lo demás, claro está que esta investigación pretende contribuir y es parte de este boom de la

usabilidad.



1.2. Descripción del Problema

La usabilidad es considerada como un atributo crucial de cualquier sistema software interactivo. Ésta puede

ser descrita en términos de efectividad, eficiencia y satisfacción del usuario. Existen algunos atributos de la

usabilidad que se consideran imprescindibles al diseñar interfaces de usuario. Así también se han postulado los

principios de usabilidad, los cuales indican caminos para la solución de problemas prácticos.

Existen distintas variedades de técnicas para evaluar precisamente si se están aplicando los principios de

usabilidad, es decir, para evaluar la usabilidad de los sistemas software. Estas se encasillan generalmente en dos

grupos distintos: métodos de inspección de usabilidad y métodos de prueba de usabilidad, los cuales pueden ser

usados iterativamente y en etapas distintas del desarrollo de un software.

El camino más común para hacer estas evaluaciones de usabilidad es realizar por lo menos uno de los

métodos de inspección de usabilidad y uno de los métodos de prueba, dependiendo de la situación que se presenta.

Esto porque los métodos de inspección de usabilidad son realizados por analistas y expertos en usabilidad con el

objetivo de identificar errores y problemas de diseño del sistema en cuestión, mientras que los métodos de prueba de

usabilidad permiten evaluar el sistema realizando pruebas empíricas del diseño de la interfaz con usuarios

representativos. Así, es posible definir los problemas de usabilidad en una primera etapa, para luego evaluar

empíricamente la influencia de esos problemas.

Ahora bien, la variedad de métodos de evaluación de usabilidad, tanto de inspección como de prueba, ofrece

distintos factores que influyen en su realización, con características que determinan el tipo de información que se

puede rescatar, las etapas en que pueden ser desarrollados, etcétera. Además, se producen diferencias en los tiempos

necesarios para llevar a cabo cierto método de evaluación, los equipos necesarios, cantidad de expertos en usabilidad

y usuarios de prueba representativos, entre otros factores.

Por otro lado, las aplicaciones web transaccionales poseen características que las diferencian de otros tipos

de sistemas, por lo que la evaluación de éstas no es simplemente una generalización de lo que se realiza con

cualquier tipo de sistema software interactivo. Todos los métodos de evaluación de usabilidad pueden ser

desarrollados sobre las aplicaciones web transaccionales, pero la incógnita está en el nivel de la información que

entrega cada uno de ellos y/o la combinación de unos con otros.

El problema surge, entonces, al momento de decidir cuál de los métodos de evaluación de usabilidad

existentes o cuál combinación de métodos de evaluación de usabilidad (métodos de inspección y métodos de prueba)

es realizable sobre aplicaciones web transaccionales con más eficiencia, de manera de obtener la mayor cantidad de

información relevante, considerando tiempos razonables, obtención de problemas importantes, etcétera.



2. DEFINICIÓN DEL PROYECTO

La información base para llevar a cabo de manera clara y ordenada el presente proyecto se detalla en este

capítulo. Se comienza definiendo los objetivos del proyecto, luego la metodología y el plan de trabajo, para terminar

con las hipótesis del mismo, sentando así las bases para el desarrollo de la metodología de evaluación de usabilidad

para aplicaciones web transaccionales.

2.1. Objetivos del Proyecto

Para la consecución de este proyecto se ha definido un objetivo general y cuatro objetivos específicos, los

cuales se detallan a continuación. La realización de estos cuatro objetivos específicos permitirá que la investigación

llegue a buen término, marcando el camino hacia el cumplimiento del objetivo general.

2.1.1. Objetivo General

Establecer una metodología de evaluación de usabilidad para aplicaciones web transaccionales.

2.1.2. Objetivos Específicos

Analizar los atributos, principios y métodos de evaluación de usabilidad.

Particularizar los métodos de evaluación de usabilidad a aplicaciones web transaccionales.

Proponer una metodología de evaluación de usabilidad para aplicaciones web transaccionales.

Comprobar la eficiencia de la metodología de evaluación sobre aplicaciones web transaccionales.



2.2. Metodología de Trabajo

El desarrollo de este proyecto está ligado a una metodología de trabajo que permitirá visualizar de mejor

manera todo el proceso involucrado, programar una serie de actividades y coordinarlas de manera de asegurar que el

avance del proyecto sea el que corresponde, paso a paso y de manera lógica, hacia una fructuosa y satisfactoria

culminación.

Así, en un principio se realizará una metodología exploratoria, donde se realizará una recolección de

material bibliográfico relacionado con los temas involucrados en el proyecto, desde distintas fuentes y procedencias,

sean estos libros, revistas, publicaciones académicas, páginas web o apuntes académicos. Se analizarán conceptos

relacionados con la ingeniería y aplicaciones web, la usabilidad y los métodos de evaluación de usabilidad, gracias al

material bibliográfico recolectado. Así, se cubrirán los tópicos más importantes que se asocian a la presente

investigación.

Luego se continuará con una metodología descriptiva, en la cual se explicarán las características más

importantes y sobresalientes de la información recolectada anteriormente. Esto con el fin de formalizar las bases en

que se sostiene la presente investigación, y estableciendo cierta solidez teórica para ir acercándose a los resultados

que se esperan.

Posteriormente se desarrollará una metodología correlacional, que contemplará la identificación de

características y relaciones de los métodos de evaluación de usabilidad en aplicaciones web transaccionales que

guarden relación con la obtención de medidas de la usabilidad de la forma más completa posible. Se analizarán las

características comunes y distintivas de cada uno de los métodos, para luego postular las combinaciones adecuadas

de estos, con su correspondiente análisis de efectividad.

Finalmente, se realizará una metodología explicativa, con el fin de presentar resultados de la investigación y

explicando el por qué de estos resultados, previa validación, para terminar con las conclusiones que ha dejado el

desarrollo de este proyecto.



2.3. Plan de Trabajo

Las etapas involucradas en el desarrollo de esta investigación son las siguientes:

1ra etapa: Formulación del proyecto.

2da etapa: Estudio del estado del arte asociado.

3ra etapa: Aplicación de los métodos de evaluación de usabilidad sobre los casos de estudio.

4ta etapa: Propuesta de la metodología de evaluación de usabilidad.

5ta etapa: Conclusiones.

La primera etapa inserta es la relacionada con la definición del proyecto. En esta etapa se definen los puntos

básicos involucrados con el desarrollo del proyecto, se analiza el problema en cuestión y se estudia la viabilidad de

llevar a cabo el proyecto.

Luego viene una etapa de recopilación de la información relacionada con el tema en desarrollo, es decir, se

realiza un estudio del estado del arte de los temas más importantes asociados al proyecto.

La aplicación de los métodos de evaluación de usabilidad a los casos de estudio corresponde a otra etapa, la

cual incluye todo lo relacionado al diseño de las pruebas, la ejecución misma de éstas, recopilación de información

obtenida con los métodos, y análisis de los resultados. Esta etapa se torna muy importante, ya que corresponde a la

etapa en donde se obtienen todos los datos relevantes para poder realizar las propuestas que buscan el cumplimiento

del objetivo general.

La cuarta etapa es la de presentación de la propuesta de la metodología de evaluación de usabilidad, junto

con la validación de la misma, estudiando la verdadera eficiencia de las mezclas de métodos propuestas.

La quinta y última etapa es la de las conclusiones del trabajo realizado. En ésta, se evalúa el cumplimiento

de los objetivos y el nivel de legitimidad de la propuesta final realizada.

La Tabla 2.1, a continuación, muestra las actividades involucradas en cada una de las etapas de la

metodología de trabajo del proyecto.



Tabla 2.1: Etapas del Proyecto

Etapa Actividades

1ra etapa Formulación del Proyecto

Formulación del Proyecto (descripción del problema,

definición de objetivos, metodología y plan de trabajo,

hipótesis del proyecto).

2da etapa Estudio del Estado del Arte

Asociado

Análisis de la ingeniería y aplicaciones web.

Análisis de los atributos y principios de usabilidad, y de los

métodos de evaluación de usabilidad.

3ra etapa

Aplicación de los Métodos de

Evaluación de Usabilidad sobre

los Casos de Estudio

Diseño de las pruebas a realizar sobre los casos de estudio.

Pruebas Piloto sobre los casos de estudio.

Realización de los métodos de evaluación de usabilidad

sobre los casos de estudio.

Procesamiento de los resultados obtenidos en la realización

de los métodos de evaluación.

Particularización de los métodos de evaluación sobre

aplicaciones web transaccionales.

4ta etapa Propuesta de Metodología de

Evaluación de Usabilidad

Propuesta de la metodología de evaluación de usabilidad

sobre aplicaciones web transaccionales.

Validación de la metodología propuesta.

5ta etapa Conclusiones Conclusiones del proyecto.

A base de estas etapas y actividades de cada una, se desarrolla el plan de trabajo del proyecto, el cual se

muestra en la Tabla 2.2, a continuación.



Tabla 2.2: Plan de Trabajo del Proyecto

Seminario de Tesis Proyecto de Tesis

Período (mes / año 2008)

Actividades

Mar Abr May Jun Jul Ago Sep Oct Nov Dic

Formulación del Tema. X X

Análisis de la ingeniería y

aplicaciones web. X X

Análisis de los atributos y

principios de usabilidad, y de los

métodos de evaluación de

usabilidad.

X X

Diseño de las pruebas a realizar

sobre los casos de estudio. X

Pruebas Piloto sobre los casos de

estudio. X

Realización de los métodos de

evaluación de usabilidad sobre los

casos de estudio.

X X X

Procesamiento de los resultados

obtenidos en la realización de los

métodos de evaluación.

X X X

Particularización de los métodos

de evaluación sobre aplicaciones

web transaccionales.

X X X X

Propuesta de metodología de

evaluación para aplicaciones web

transaccionales.

X X X X

Validación de la metodología de

evaluación propuesta. X X X

Conclusiones del proyecto X



2.4. Hipótesis del Proyecto

El planteamiento de la hipótesis del proyecto está en torno a la realización de la metodología de evaluación

de usabilidad y su efectividad al momento de obtener información sobre la usabilidad en aplicaciones web

transaccionales. Así, se define la hipótesis de investigación y la hipótesis nula de la siguiente manera:

Hipótesis de Investigación (H1): La aplicación de una metodología de evaluación de usabilidad sobre aplicaciones

web transaccionales entrega mayor información que la aplicación aislada de los

métodos de evaluación de usabilidad.

Hipótesis Nula (H0): La aplicación de una metodología de evaluación de usabilidad sobre aplicaciones

web transaccionales no entrega mayor información que la aplicación aislada de

los métodos de evaluación de usabilidad.

Como se ha definido en los subcapítulos anteriores, la presente investigación comienza con la aplicación

aislada de los métodos de evaluación sobre los casos de estudio seleccionados, para luego generar una metodología

de evaluación, validada por otro caso de estudio. Con el análisis de los antecedentes entregados en dichos procesos, y

a base de los procedimientos empíricos que se muestran a lo largo de la investigación, se espera que al finalizar el

proyecto la hipótesis sea satisfecha.



3. INGENIERÍA WEB

El surgimiento de la web y la gran explosión que ha tenido durante los últimos años ha dado paso a una

nueva visión de la ingeniería de software y los usuarios. Existe un abanico gigantesco de perfiles de usuario en esta

enorme plataforma como es la web. Desde un estudiante que lee noticias en un portal de información regional hasta

un ejecutivo que realiza transacciones en línea en el sitio de su banco. Se percibe mucha información, muchas formas

de llegar a ella, muchas necesidades y muchas opciones para satisfacerlas.

Lo anterior conlleva al apercibimiento natural de los conceptos asociados al mundo de la web. Links, sitios,

páginas, navegadores, internet, entre muchos otros conceptos, ya son parte del vocabulario común de las personas.

Sin duda, las aplicaciones web y, por lo tanto, la ingeniería web, son términos sumamente vigentes no solo

dentro de la informática, y conforman una fuente muy interesante de estudio, lo que se transforma en uno de los

principales motivos de consideración en esta investigación.

Este capítulo contempla, en un comienzo, la definición del concepto de ingeniería web y algunos de sus

principios generales, para luego hacer un análisis de las aplicaciones web, sus consideraciones más importantes y sus

distintos tipos de categorías.

3.1. Definiciones

La ingeniería web tiene sentido por la siguiente afirmación: una aplicación web se desmarca (es diferente)

de un producto software tradicional. La naturaleza de la web es la que marca esa diferencia. Asimismo, el proceso de

desarrollo de una aplicación web tiene sus diferencias con el proceso de desarrollo de un software tradicional, sobre

todo al considerar la necesidad de incorporar el atributo de la usabilidad en ese desarrollo.

Las diferencias más marcadas entre una aplicación web y un producto software tradicional, son las que se

detallan a continuación, en el contexto de la usabilidad [4]:

En el diseño de productos y software, los usuarios pagan de antemano, y experimentan la

usabilidad después.

En la web, los usuarios experimentan primero la usabilidad y pagan después.

Las expectativas infladas de los usuarios sobre la tecnología del internet pueden ser difíciles de

satisfacer.



Una aplicación web puede atender a multiplicidad de perfiles de usuario y sus distintos

requerimientos. El construir un sitio orientado a audiencias no siempre es fácil.

En la web el usuario no ha hecho una inversión en un sitio particular, y otras opciones son

fácilmente disponibles y accesibles.

La mayoría de los sitios web requieren estar operativos en un corto espacio de tiempo y esto

dificulta el nivel de rigor de varias actividades del proceso.

La ingeniería web corresponde a un proceso en el que está envuelto el proceso de vida de una aplicación

web, tal como lo es la ingeniería de software para un producto software tradicional. Pero, ¿es realmente válido

separar lo que es la ingeniería web de la ingeniería de software? ¿Corresponden a disciplinas distintas?

La “disciplina” es un término utilizado para denominar áreas de estudio, como las matemáticas, el derecho,

la educación, la ingeniería, etcétera. Un área o campo de estudio de una ciencia incluye investigaciones, enseñanzas,

conocimientos científicos bien establecidos, etcétera. Para Gerti Kappel, conocido investigador de la ingeniería web,

la gran cantidad de publicaciones, lecturas, conferencias y talleres demuestran que, acorde a la definición de

disciplina, la ingeniería web puede ser considerada como una rama independiente de la clásica ingeniería de

software.

Los desarrolladores de productos software para la web necesitan adoptar procesos de desarrollo

disciplinados, que sirvan como guías para la construcción de aplicaciones web. Para ellos es imperativo poseer

metodologías establecidas, buenas herramientas de desarrollo y un conjunto de buenas directrices.

A continuación se muestra una secuencia de términos con sus definiciones que ayudarán a entregar una

definición propia de la ingeniería web [5]:

Ingeniería: Aplicación práctica de la ciencia en el comercio o industria con el fin de

diseñar aplicaciones de la mejor forma posible.

Ingeniería de Software: Aplicación de la ciencia y de las matemáticas en donde las capacidades

de los equipamientos computacionales se hacen útiles para los humanos

a través de programas computacionales, procedimientos y

documentación asociada.

A partir de estos conceptos se puede explicar lo que es la ingeniería web:

La ingeniería web es la aplicación de enfoques sistemáticos y cuantificables (conceptos,

métodos, técnicas y herramientas) al análisis de requerimientos, diseño,

implementación, testeo, operación y mantenimiento de aplicaciones web de alta



calidad. Además, la ingeniería web es la disciplina científica cuyo interés es el estudio

de estos enfoques.

Para complementar, y con el objetivo de aclarar el concepto de la mejor manera, se entrega otra definición

propuesta por un par de conocidos investigadores del tema, junto con algunos interesantes comentarios [6]:

La ingeniería web es una disciplina que se basa en enfoques sistemáticos y principios

científicos, ingenieriles y de gestión para desarrollar, desplegar y mantener

satisfactoriamente sistemas y aplicaciones web de alta calidad. Lo que lleva a alcanzar

un desarrollo de sistemas basados en la web bajo control, minimizando los riesgos y

aumentando la calidad, mantenibilidad y escalabilidad de las aplicaciones web.

La esencia de la ingeniería web es administrar satisfactoriamente la diversidad y

complejidad del desarrollo de aplicaciones web, y con ello, evitar fallas potenciales que

pueden tener serias implicancias en el producto.

Desde el punto de vista de la ingeniería de software, el desarrollo de aplicaciones web se considera como un

nuevo dominio de aplicación. En algunos casos, existen muchas similitudes entre las características de una aplicación

web y un producto software tradicional, pero en otros casos, las diferencias son más marcadas.

Claramente, la ingeniería web posee principios básicos al igual que cualquier disciplina que se interesa en

cierta área de estudio. Estos principios se pueden nivelar con los principios básicos de la ingeniería de software, son

similares, pero los primeros enfocados en la web. Así, los principios básicos de la ingeniería web son:

Definición clara de los objetivos y requerimientos.

Desarrollo sistemático de la aplicación web en fases.

Planificación cuidadosa de las denominadas fases.

Auditoría continua del proceso de desarrollo completo.

Al igual que en la ingeniería de software, un proceso de desarrollo del producto iterativo e incremental sería

lo más conveniente, ya que se realza un crecimiento evolutivo y ordenado de la aplicación web. Así además, se

asegura de mejor forma la calidad de la aplicación web, también reduciendo costos y disminuyendo las pérdidas, ya

que se obtienen resultados en cada fase, los cuales se pueden evaluar cada vez para ir avanzando a las etapas

siguientes. Es decir, la calidad va a aumentando en su medida en cada término de una fase.



3.2. Aplicaciones Web

Luego de haber estudiado lo que es la ingeniería web, es necesario conocer sobre los productos que

desarrolla esta disciplina, los cuales serán objeto de estudio dentro de esta investigación: las aplicaciones web.

Hoy en día, las aplicaciones web son sistemas software particularmente complejos, en donde existe una

interacción constante con el usuario y pueden ser repositorios de gran cantidad de información, además de ofrecer

servicios que pueden ser accedidos desde cualquier lugar y desde variados dispositivos. Esto aporta también a la

diferenciación ya analizada de las aplicaciones web con los productos software tradicionales. Así, una aplicación

web puede ser definida como [5]:

Una aplicación web es un sistema software basado en las tecnologías y estándares del

World Wide Web Consortium (W3C) que ofrece recursos específicos de la web, como

contenidos y servicios, mediante una interfaz de usuario denominada navegador web.

Con esta definición se confirma la importancia de las aplicaciones web, ya que pueden ofrecer una infinidad

de recursos a una infinidad de usuarios distintos. Las aplicaciones web, en estos momentos, constituyen la mejor

interfaz de integración de servicios, conectando tanto a organizaciones como a personas naturales, y generando

además las denominadas redes sociales. Así es, las redes sociales en la web obvian grandes cantidades de kilómetros

de distancia, no importando el lugar ni el medio de acceso a ésta. ¿Están tomando importancia las aplicaciones web?

Claro que sí.

Ahora bien, desde el surgimiento de la web y de las aplicaciones web, se han ido desarrollando distintos

tipos de aplicaciones, dependiendo de las necesidades del momento y de las potencialidades de las herramientas

asociadas. A base de esto, la Figura 3.1 muestra un gráfico de las categorías de aplicaciones web, en donde se puede

ver la evolución en la historia de estas aplicaciones y el grado de complejidad de las mismas. Además, en cada una se

muestran algunos ejemplos de aplicaciones, que ayudarán a tener una visión más completa de lo que representa cada

una de estas categorías.

Cabe destacar que el surgimiento de nuevas categorías con el tiempo, generalmente más complejas, no

implica necesariamente el reemplazo de estas nuevas por las anteriores. Además, se puede notar en el gráfico que en

los comienzos de la historia las categorías nuevas eran bastantes más complejas que las anteriores, no así con las

categorías más recientes, en donde, en algunos casos, ha disminuido en cierto grado la complejidad, lo que no

significa que sean menos eficientes que las anteriores. Es interesante esta situación, ya que, en ciertos casos, las

necesidades crecientes de los usuarios no ameritan la creación de sistemas sumamente complejos respecto de los

casos anteriores.



Otro punto a considerar es la cantidad de aplicaciones que abarca cada categoría, pasando por variados tipos

de usuarios, distintos campos, negocios, niveles, etcétera. Por ejemplo, la categoría de aplicaciones web

transaccionales involucra una gran cantidad de aplicaciones, sean éstas de entidades bancarias, venta de insumos

computacionales, venta de libros, tiendas de ropa, música, etcétera.

Figura 3.1: Categorías de Aplicaciones Web [5]

Desarrollo en la Historia

Co

mp

lejid

ad

Centradas en

Documentos

Interactivas

Transaccionales

Orientadas al

Flujo de Trabajo

Portales

Colaborativas

Sociales

Web Semántica

Ubicuas

También es notoria la cantidad de categorías que han surgido en los últimos años respecto de las categorías

de aplicaciones web del comienzo. El comienzo de la historia fue relativamente pasivo en cuanto a surgimiento de

categorías y creciente en el grado de complejidad de estas, pero con el tiempo se generaron más categorías y con

distintos tipos de complejidad.

Las descripciones de las categorías de las aplicaciones web, junto con algunos ejemplos, se muestran en la

Tabla 3.1 a continuación, basada en la clasificación postulada en [5].



Tabla 3.1: Categorías de Aplicaciones Web

Categoría Descripción Ejemplos

Centradas en

Documentos

Precursor de las aplicaciones web. Aplicaciones simples y

estáticas. Generalmente, son páginas web subidas

manualmente mediante ciertas herramientas. Su objetivo

es mostrar documentación a terceros mediante la web. Se

caracterizan por su simplicidad, estabilidad y bajo tiempo

de respuesta.

- Diarios en línea.

- Libros en línea.

- Manuales.

- Sitios simples de

organizaciones

pequeñas.

Interactivas

Aplicaciones caracterizadas por la navegabilidad del

usuario encontrando información. Distintas páginas y

enlaces son encontrados por el usuario durante la

navegación.

- Formularios de registro.

- Juegos en línea.

- Sitios de noticias.

Transaccionales

Creadas para proveer mayor interactividad, permitiendo al

usuario no solo interactuar con la aplicación mediante la

lectura, sino que también generando actualizaciones sobre

el contenido asociado.

- Sistemas bancarios.

- Compras en línea.

- Sistemas de reserva.

Orientadas al Flujo de

Trabajo

Aplicaciones web complejas que permiten el manejo de

flujos de trabajo entre distintas organizaciones, empresas

y/o personas. Se caracterizan por la disponibilidad de

servicios web apropiados que garantizan la

interoperabilidad.

- Comercio en línea.

- Sistemas de gobierno en

línea.

- Sistemas médicos.

Colaborativas

Desarrollados especialmente para propósitos cooperativos

en operaciones no estructuradas. Se dan por la necesidad

de cooperación entre usuarios cooperativos en áreas

específicas. Soportan el compartimiento de la información

(creación, edición y gestión de ésta).

- Plataformas e-learning.

- Salas de chateo.

- Servicios Peer to Peer

(P2P)

Sociales

Los usuarios se identifican (contrario a lo tradicional,

donde reina el anonimato) y comparten intereses con otros

usuarios dentro de pequeñas comunidades. Los usuarios

pueden buscar usuarios y comunidades, generando redes

sociales en línea.

- Weblogs.

- Grupos de discusión.

- Facebook.



Tabla 3.1 (continuación): Categorías de Aplicaciones Web

Categoría Descripción Ejemplos

Portales

Permiten el acceso a recursos heterogéneos de

información y servicios. Existen varios especializados en

áreas de interés específicas.

- Portales de negocios.

- Portales de mercado.

- Portales comunitarios.

Ubicuas

Ofrecen servicios a medida, a cualquier hora, cualquier

lugar y desde cualquier dispositivo, facilitando el acceso

ubicuo.

- Servicios a medida.

- Servicios perceptores de

ubicación.

Web Semántica

Su objetivo es que la información no solo sea entendida

por las personas, sino que también por las máquinas, lo

que facilita la administración del conocimiento en la web,

permitiendo además la automatización de tareas

repetitivas.

- Sistemas de

recomendación.

- Sistemas de

administración del

conocimiento.

Como muestra la tabla anterior, la evolución y crecimiento de la complejidad de las aplicaciones web es

bastante clara. Se ha pasado de aplicaciones cuyo único objetivo es la publicación de información a terceros, a

aplicaciones inteligentes que tienen la capacidad de ser leídas por máquinas, y que permiten accesos sin límites.

Es importante plasmar que en los últimos años han reinado los intentos de crear una convergencia entre las

industrias más importantes y significativas de la sociedad (Industria TIMES: Telecommunications, Information

technology, Multimedia, Education and Entertainment, Security; en español, telecomunicaciones, tecnología de la

información, multimedia, educación y entretenimiento, seguridad), que liderarán en un futuro no muy lejano gracias

a las aplicaciones ubicuas, que por su complejidad no han logrado establecerse completamente. Por esta razón, nace

la web semántica, que está reemplazando temporalmente a las aplicaciones ubicuas, en su afán de establecer las

aplicaciones inteligentes.

Para la realización de esta investigación, se considerarán las aplicaciones web transaccionales, las cuales

permiten una interacción del usuario con la aplicación además de la posibilidad de generar actualizaciones sobre el

contenido de ésta. Se ha escogido este tipo de aplicaciones web por su gran importancia en la sociedad, ya que se

ocupan para realizar distintos tipos de transacciones bancarias, académicas, comerciales, etcétera, por lo que la

usabilidad de éstas debe ser de un buen nivel. Además, día a día más usuarios estar ocupando la web para realizar

este tipo de transacciones, las cuales son ciertamente más cómodas que tener que realizarlas físicamente en lugares

muy concurridos y/o lejanos.



4. USABILIDAD

Este capítulo tiene como objetivo analizar los conceptos más importantes relacionados con la usabilidad. De

esta forma, se comenzará con la definición del concepto de usabilidad que será utilizado como base para la

investigación, a base de las propuestas y/o comentarios realizados por distintos autores en torno al tema. Luego, se

analizan, separadamente, los atributos, paradigmas y principios de usabilidad, para terminar con el subcapítulo de la

usabilidad en la web, donde se detallan, entre otras cosas, los problemas y beneficios más comunes de la usabilidad

precisamente en la web.

4.1. ¿Qué es la Usabilidad?

En la literatura, el término Usabilidad es bastante utilizado y se presentan variadas definiciones. Algunos

investigadores de la usabilidad han postulado sus definiciones del término, así como también han realizado

comentarios que pueden ayudar a obtener visiones más completas y claras de la usabilidad. Por ejemplo, Guillemette

[7] postula que:

“La usabilidad se refiere al grado de eficacia del probable uso de la documentación

por parte de los usuarios finales durante la ejecución de tareas dentro de las

restricciones y requerimientos del entorno real”

El autor establece cierta importancia al uso de la documentación, la cual es parte de los análisis al evaluar la

usabilidad de algún producto. Además resalta la eficacia de uso de esta documentación como aspecto fundamental en

la realización de tareas por los usuarios.

Donald A. Norman [8] en su libro “Invisible Computer” fundamenta que:

“Los sistemas que sean usables, seguros y funcionales acercarán mutuamente al

usuario y el ordenador y, por lo tanto, harán que el espacio entre la tecnología y las

personas disminuya”

Además postula que ese espacio que se genera entre las personas y la tecnología podría ser nulo, llegando al

resultado ideal de que el computador sea “invisible”, queriendo decir que un sistema completamente usable sería

ideal, ya que el usuario trabajaría en óptimas condiciones.

Otra definición es la que propone Kristoffer Bohmann [9]. Simplemente:

“La usabilidad es que los usuarios puedan completar sus tareas”



En particular, los usuarios y sus necesidades son conocidos a un nivel detallado. Los usuarios pueden

completas sus tareas sin retrasos y errores, y disfrutan de la experiencia.

Para Jakob Nielsen, considerado como uno de los gurús en usabilidad a nivel mundial, la usabilidad se

define entorno al siguiente comentario:

“La utilidad de un sistema en cuanto a medio para conseguir un objetivo, tiene un

componente de funcionalidad (utilidad funcional) y otro basado en el modo en que los

usuarios pueden usar esta funcionalidad”

Se destaca la importancia que le da al usuario para evaluar la utilidad de un producto software,

distinguiendo y nivelando las funcionalidades del sistema y la forma en que son ocupadas estas funcionalidades.

Además asocia, como la gran mayoría de los autores, el cumplimiento de objetivos o tareas al concepto propio de la

usabilidad.

Otra definición es la que describe Montero [10]:

“La Usabilidad es la disciplina que estudia la forma de diseñar sitios web para que los

usuarios puedan interactuar con ellos de la forma más fácil, cómoda e intuitiva

posible”

En esta definición el autor acota el objetivo de la usabilidad solo a los sitios web. Es muy común que se

defina a la usabilidad en torno a la web, ya que es un campo bastante amplio en el que puede interferir la usabilidad,

pero la usabilidad es mucho más amplia y abarca todo tipo de sistemas software interactivos. Esta investigación se

enfoca en el estudio de los métodos de evaluación de usabilidad en aplicaciones web, por lo que esta definición está

dentro del contexto del trabajo, pero no se puede limitar el concepto de usabilidad a este tipo de sistemas solamente.

Krug establece el siguiente comentario respecto de la usabilidad:

“No me hagas pensar”

Así, establece la gran importancia de la usabilidad, ya que debe permitir a los usuarios trabajar de forma

completamente normal y simplificada. El aspecto y la información que entrega un sistema debe ser obvia, evidente,

clara y fácil de entender.

La IEEE’90 (Institute of Electrical and Electronics Engineers) define la usabilidad como:

“Es la facilidad con la que un usuario puede aprender a operar, realizar inputs e

interpretar outputs de un sistema”



Se destaca la interacción existente entre el usuario y el sistema. Normalmente, el usuario ingresa

información al sistema y éste le entrega información, estableciendo una importancia a la interpretación de esa

información.

Para terminar, la Organización Internacional para la Estandarización o International Organization for

Standarization (ISO) posee dos definiciones de este término justamente en dos de sus normas. La norma ISO/IEC

9126 define:

“La usabilidad se refiere a la capacidad de un software de ser comprendido,

aprendido, usado y atractivo para el usuario, en condiciones específicas de uso”

La definición deja en claro la fuerte correlación existente entre el usuario y la usabilidad, es decir, la medida

en que un software es usable solamente se puede llevar a cabo con usuarios. Además, esta medida está asociada a

condiciones específicas de uso, por lo que es sumamente importante el contexto en que se está midiendo la

usabilidad de un software.

La norma ISO/IEC 9241 define la usabilidad de la siguiente manera:

“La usabilidad es la efectividad, eficiencia y satisfacción con la que un producto

permite alcanzar objetivos específicos a usuarios específicos en un contexto de uso

específico”

Efectividad se refiere al nivel de exactitud con que el usuario cumple los objetivos; eficiencia se

refiere a los recursos usados para la concreción de estos objetivos por parte del usuario; satisfacción relacionada

con la comodidad y postura del usuario durante la interacción con el producto.

En esta definición se acotan y se detallan las condiciones en que la usabilidad debe ser valorada. Se deben

establecer los objetivos (considerando también tareas y actividades), usuarios pertenecientes a perfiles específicos, y

dentro de un contexto de uso dado.

Como se puede notar, todas las definiciones se enmarcan dentro un mismo alero, enfocado directamente en

el usuario y en la forma en que lleva a cabo sus tareas. Para el desarrollo de esta investigación se considerará la

definición postulada en la norma ISO/EIC 9241 como el significado preciso para el término Usabilidad, ya que

engloba los comentarios y definiciones anteriores, y representa completamente el sentido del término en cuestión.



4.2. Atributos de Usabilidad

La usabilidad corresponde a uno de los atributos básicos de cualquier producto software. Según la

Organización Internacional para la Estandarización en su norma ISO/IEC 9126, la calidad de un producto en el

contexto de la ingeniería de software está dada por la implementación de seis atributos básicos, como se muestra en

la Figura 4.1. En el modelo presentado en la figura se puede encontrar a la usabilidad como uno de los seis atributos

más importantes que debe poseer cualquier producto software, junto con las características más importantes de cada

uno de estos.

Figura 4.1: Modelo de Calidad de Software de la ISO

CALIDAD DE USO

Funcionalidad

Exactitud

Idoneidad

Interoperabilidad

Seguridad

Fiabilidad

Madurez

Tolerancia a Fallos

Recuperabilidad

Disponibilidad

Usabilidad

Facilidad de Aprendizaje

Flexibilidad

Robustez

Eficiencia

Tiempo de Respuesta

Recursos

Utilización

Mantenibilidad

Capacidad de Análisis

Capacidad de Cambios

Estabilidad

Capacidad de Pruebas

Portabilidad

Adaptabilidad

Capacidad de Instalación

Conformidad

Capacidad de Reemplazo



Así, se puede notar la importancia de la usabilidad dentro de la ingeniería de software, ya que, según la ISO,

se encuentra en el mismo nivel de importancia que otros atributos clásicamente considerados como lo son la

funcionalidad, fiabilidad y eficiencia.

Ahora, según este modelo propuesto por la ISO, la usabilidad también posee sus propios atributos: Facilidad

de Aprendizaje, Flexibilidad y Robustez.

Facilidad de Aprendizaje: Se refiere a la facilidad con que los nuevos usuarios pueden tener una

interacción efectiva. Está relacionada con la predicibilidad, sintetización,

familiaridad, la generalización de los conocimientos previos y la consistencia.

Flexibilidad: Hace referencia a la variedad de posibilidades con las que el usuario y el

sistema pueden intercambiar información. También abarca la posibilidad de

diálogo, la multiplicidad de vías para realizar la tarea, similitud con tareas

anteriores y la optimización entre el usuario y el sistema.

Robustez: Es el nivel de apoyo al usuario que facilita el cumplimiento de sus objetivos.

Está relacionada con la capacidad de observación del usuario, de recuperación

de la información y de ajuste de la tarea al usuario.

Sin embargo, Jakob Nielsen propuso otra descomposición de la usabilidad, postulando cinco atributos

básicos de ésta. Esto, dentro del contexto del estudio de los atributos involucrados en la aceptabilidad de un sistema.

La Figura 4.2 muestra el modelo de los atributos de aceptabilidad de un sistema, en el cual está presente la usabilidad

con sus cinco atributos básicos propuestos por Nielsen. Éste argumenta que la usabilidad es una cualidad demasiado

abstracta como para medirla directamente. Así, los atributos básicos de la usabilidad, según Nielsen, se detallan a

continuación [11]:

Facilidad de Aprendizaje: El mismo sentido que el atributo postulado por la ISO. El sistema debe ser

fácil de aprender para que cualquier usuario pueda rápidamente realizar tareas

en el sistema son mayores problemas. Este atributo es muy importante al

considerar usuarios novatos.

Eficiencia de Uso: El sistema debe ser eficiente al usarlo, de modo que cuando un usuario ha

aprendido a usar el sistema, éste pueda obtener el más alto nivel de

productividad posible. Cuanto mayor es la usabilidad del sistema, más rápido

es el usuario al utilizarlo, por lo que las tareas del usuario se concretan más

rápidamente.



Figura 4.2: Modelo de los Atributos de Aceptabilidad de un Sistema

ACEPTABILIDAD DEL SISTEMA

Aceptabilidad Práctica

Aceptabilidad Social

Costo Compatibilidad Fiabilidad Satisfacción Etc.

Usabilidad Utilidad

Facilidad de Aprendizaje

Eficiencia de Uso

Recuerdo en el Tiempo

Tasa de ErroresSatisfacción

Subjetiva

Recuerdo en el Tiempo: El sistema debe ser fácil de recordar, para que un usuario casual del sistema

(que no utiliza el sistema regularmente) sea capaz de retornar a éste después

de un período de tiempo sin usarlo, sin tener que aprender todo de nuevo.

Tasa de Errores: El sistema debe tener una baja tasa de errores, para que los usuarios cometan

la menor cantidad posible de errores durante la interacción con el sistema, y

para que cuando los cometan puedan fácilmente recuperarse de estos. Los

errores reducen la eficiencia y satisfacción del usuario.

Satisfacción Subjetiva: El sistema debe ser placentero al usarlo. Cuando los usuarios quedan

subjetivamente satisfechos al usar un sistema, el sistema les gusta.



Estos cinco atributos de usabilidad propuestos por Nielsen son ciertamente más expresivos respecto de lo

que debe hacer y poseer un sistema y lo que no. Además, establece indirectamente una diferencia entre los tipos de

usuario de un sistema. Los atributos Facilidad de Aprendizaje, Eficiencia de Uso y Recuerdo en el Tiempo se asocian

de cierta forma a tres distintos tipos de usuarios, como son usuarios novatos, usuarios expertos y usuarios

ocasionales, respectivamente.

Ahora bien, ¿cómo se puede medir la aplicación de estos atributos de usabilidad en los sistemas software?

La Tabla 4.1 a continuación muestra las formas más comunes de medición para cada atributo:

Tabla 4.1: Medición de los Atributos de Usabilidad

Atributo Medición

Facilidad de Aprendizaje Tiempo necesario para cumplir ciertas tareas, previa distinción entre usuarios

expertos e inexpertos

Eficiencia de Uso Tiempo necesario por usuarios expertos para cumplir ciertas tareas típicas

del sistema.

Recuerdo en el Tiempo Tiempo necesario por usuarios que no han utilizado últimamente el sistema

para realizar ciertas tareas del sistema.

Tasa de Errores Cantidad de errores cometidos por los usuarios al realizar tareas típicas.

Satisfacción Subjetiva Cuestionarios.

Al analizar las formas de medir los atributos de usabilidad se puede notar más claramente la importancia de

la diferenciación establecida entre los tipos de usuario de los sistemas, ya que se consideran los tiempos que emplea

cada uno de los tipos de usuario en realizar ciertas tareas, como base para obtener la medida en que los atributos de

usabilidad respectivos están implementados en el sistema en estudio.



4.3. Paradigmas de Usabilidad

Existe un conjunto de paradigmas o reglas de la usabilidad, que permiten obtener una visión general de las

características que deben tener los sistemas software para que sean usables. El objetivo principal de estos paradigmas

es maximizar la usabilidad de los sistemas y surgen como resultado de la experiencia. Así, los paradigmas de

usabilidad son los que se muestran a continuación, basados en los comentarios de distintos autores, principalmente

en:

Acceso

En muchas ocasiones existen usuarios expertos en ciertas áreas de aplicación y que deben utilizar un

sistema diseñado para esa área. En estos casos, el usuario debe poder utilizar el sistema sin la

necesidad de cursos ni capacitaciones, lo que hace que el sistema sea usable.

Eficacia

Para usuarios con experiencia en el uso del sistema no deben existir obstáculos ni limitaciones, por lo

que el sistema debe permitir un trabajo eficiente para estos.

Ascenso

Con el correr del tiempo, los usuarios van adquiriendo cierta experiencia en el uso del sistema. El

sistema debe permitir el constante avance en habilidades y conocimientos de los usuarios para con el

sistema, acomodándose a los cambios progresivos.

Soporte

El sistema debe apoyar el trabajo agradable del usuario, permitiendo realizar las tareas de éste de

forma simple, fácil, rápida y divertida. Además, debe permitir que el usuario realice cosas nuevas o de

distintas formas.

Contexto

Los sistemas son usados bajo condiciones específicas, en entornos específicos, los cuales deben ser

considerados al diseñar un sistema. Así, el sistema debe adaptarse al contexto de uso real en que está

inserto.



4.4. Principios de Usabilidad

La usabilidad, como muchas otras disciplinas, posee una lista de principios que la componen. Estos

corresponden a principios generales de usabilidad para el diseño de interfaces de usuario y son más específicos que

los paradigmas de usabilidad, indicando caminos para la solución de problemas prácticos. Su objetivo principal es el

mismo que el de los paradigmas de usabilidad: maximizar la usabilidad de los sistemas.

Nuevamente se debe recurrir a las teorías de Jakob Nielsen para explicar estos principios. Este importante y

reconocido investigador de la usabilidad estableció diez principios básicos de la usabilidad, también llamados

principios heurísticos, los cuales se detallan a continuación [12]:

1. Visibilidad del Estado del Sistema.

El sistema debe mantener siempre a los usuarios informados sobre lo que ocurre, mediante una apropiada

retroalimentación y con tiempos razonables.

2. Conexión entre el Sistema y el Mundo Real.

El sistema debe hablar el lenguaje del usuario, con palabras, frases y conceptos familiares al usuario, en

lugar de términos orientados al sistema. Seguir convenciones del mundo real, haciendo aparecer la

información en un orden natural y lógico.

3. Control y Libertad del Usuario.

A menudo los usuarios eligen funciones del sistema por error, por lo que necesitan una “salida de

emergencia” marcada claramente para dejar ese estado no querido sin tener que soportar extensos cuadros

de diálogo. Debe permitir las funciones deshacer y rehacer.

4. Consistencia y Estándares.

Los usuarios no deberían tener que preguntarse si diferentes palabras, situaciones o acciones significan lo

mismo. Se debe utilizar plataformas de convenciones.

5. Prevención de Errores.

Incluso mejor que un buen mensaje de error es un diseño cuidadoso que prevenga que un problema ocurra

primero. Eliminar o chequear las condiciones propensas a errores y presentar a los usuarios opciones de

confirmación antes de realizar la acción.



6. Reconocimiento en lugar de Recordar.

Minimizar la carga de memoria del usuario, haciendo objetos, acciones y opciones visibles. El usuario no

debe tener que recordar información de una parte de un diálogo en otra. Las instrucciones de uso de un

sistema deben ser visibles o fácilmente recuperables cuando sea apropiado.

7. Flexibilidad y Eficiencia de Uso.

Los aceleradores, no vistos por usuarios novatos, deben a menudo acelerar la interacción de un usuario

experto para que el sistema pueda atender tanto a usuarios inexpertos como a usuarios expertos. Debe

permitir a los usuarios realizar acciones frecuentes a su medida.

8. Diseño Estético y Minimalista.

Los diálogos no deben contener información irrelevante o raramente necesitada por el usuario. Cada unidad

adicional de información en un diálogo compite con las unidades relevantes de información, disminuyendo

su visibilidad relativa.

9. Ayuda a los Usuarios a Reconocer, Diagnosticar y Recuperarse de Errores.

Los mensajes de error deben ser expresivos en lenguaje plano (sin códigos), indicando precisamente el

problema, y sugiriendo constructivamente una solución.

10. Ayuda y Documentación.

Incluso aunque es mucho mejor que un sistema pueda ser usado sin documentación, debe ser necesario

proveer al usuario de ayuda y documentación. Cualquier información debe ser fácil de buscar, enfocada en

las tareas del usuario, con una lista de pasos concretos que deben llevarse a cabo, y no debe ser demasiado

larga.

Originalmente, los principios de usabilidad fueron desarrollados para la evaluación heurística por parte de

Jakob Nielsen en colaboración con Rolf Molich en 1990. Desde ese entonces, Nielsen ha refinado esos principios

basándose en el análisis factorial de 249 problemas de usabilidad, para derivar en un conjunto de principios con el

máximo poder explicativo, los cuales se detallaron anteriormente.



4.5. La Usabilidad en la Web

Es necesario acudir nuevamente a la situación que está generando la web en la sociedad. El impacto y

distribución de la web en la sociedad es irrefutable. Cada vez es más gente la que accede a esta interesante

plataforma y que aprovecha la infinidad de información y servicios que ésta ofrece; son pocos los que aún no están

insertos, ya sea por la imposibilidad de acceso, o por la poca familiaridad y entendimiento de las aplicaciones web.

Este último punto es el que involucra a la usabilidad. La facilidad de uso de las aplicaciones web es la que

impide que nuevos usuarios tengan acceso al mundo de la web. Las empresas están perdiendo clientes que puedan

realizar transacciones en línea para abaratar costos, y otras no pueden darse a conocer porque estos usuarios no

entienden la estructura de la información que se muestra en pantalla. ¿Es importante la usabilidad en la web? No

cabe duda.

La usabilidad va a permitir que los usuarios que visiten un sitio web se queden en éste, disfruten de la

interacción, y tengan las ganas de volver a visitarlo en el futuro. Si se quiere lograr esto, las páginas, los contenidos,

los menús, los cuadros de texto, etcétera, deben estar diseñados e implementados para que cualquier persona pueda

utilizarlos y entenderlos sin problemas.

4.5.1. Problemas de Usabilidad Comunes en la Web

Lamentablemente, la mayoría de las aplicaciones web no cumple con niveles considerables de aplicación

del atributo de la usabilidad, lo que impide que se cumpla este ideal expuesto en los párrafos anteriores. Los

problemas de usabilidad en las aplicaciones web son muy comunes. Los más serios son los que se detallan a

continuación [13]:

Problemas de percepción humana:

Se da en los casos que un conjunto de páginas está diseñado de acuerdo a cómo la información

está físicamente almacenada, en lugar de cómo ésta debe ser presentada para su comprensión,

generando confusión por parte del usuario.

Frustrantes problemas de navegación:

Desorientan al usuario, generando que éste no sepa en qué lugar del sitio se encuentra, cómo ha

llegado a ese punto, y qué debe hacer para volver a un punto conocido. Todo esto se agrava

cuando existe ambigüedad en la comprensión de los enlaces o no se siguen los estándares de los

elementos de navegación.



Alta exigencia de la memoria del usuario:

Craso error. Es imperativo tener en cuenta aspectos importantes acerca de la memoria humana, y

así lo dice uno de los atributos de usabilidad. Si los usuarios tienen que recordar un elevado

número de ítems, de seguro se desorientarán, más aún si deben recordar ciertos ítems de una

página a otra.

Consistencia:

Gran parte de los contenidos que ofrecen las aplicaciones web provienen de información

almacenada en las bases de datos. Esto a veces conlleva a un problema de consistencia entre la

información mostrada en pantalla con los datos reales que la base de datos dispone, lo que se

transforma en un problema de usabilidad para el usuario final.

Problemas varios:

Contenidos pobres, lentitud de las descargas, enlaces rotos, opciones y menús confusos, abuso de

ventanas emergentes, letra muy pequeña o muy grande, etc.

4.5.2. Beneficios de la Usabilidad en la Web

Algunos de los beneficios que se pueden obtener con la aplicación de este atributo en las aplicaciones web

ya se han nombrado. Sin embargo, aquí se muestra una lista de los beneficios más sobresalientes:

Disminución de los costos de producción y mantenimiento de la aplicación web.

Disminución de los costos de uso de la aplicación web.

Disminución de los costos de desarrollo.

Disminución de los costos de servicios.

Aumento de la productividad y eficiencia de uso durante la interacción del usuario con la

aplicación web.

Reducción del esfuerzo del usuario.

Aumento de las posibilidades de que el usuario vuelva a utilizar la aplicación web.



5. MÉTODOS DE EVALUACIÓN DE USABILIDAD

La evaluación de la usabilidad de un sistema software es una de las etapas más importantes dentro del

diseño centrado en el usuario, ya que permite obtener las características de la usabilidad de un sistema y la medida en

que los atributos, paradigmas y principios de usabilidad se están aplicando en éste.

Es por esto que los métodos de evaluación de usabilidad se han convertido en una fuente interesante de

estudio por parte de los investigadores de la usabilidad, sus características de aplicación, la variedad de métodos

existentes y los resultados que entregan.

Como ya se ha dicho, existen distintos tipos de métodos de evaluación de usabilidad, cada uno con sus

características propias, los cuales se pueden desarrollar sobre diferentes representaciones del sistema, sean prototipos

en papel, prototipos software, sistemas terminados, etcétera. Estos métodos permiten establecer una comunicación

entre el usuario y los desarrolladores, ya que estos últimos descubren los objetivos, percepciones, problemas y

cuestionamientos de los usuarios. Además, los métodos de evaluación de usabilidad permiten validar las decisiones

de diseño, descubriendo los problemas y los aciertos asociados al sistema, marcando las diferencias y pensamientos

comunes, respectivamente, entre los desarrolladores y los usuarios.

La importancia de los métodos de evaluación de usabilidad se fundamenta por varios factores. Los más

importantes son los que se detallan a continuación [14]:

Desarrolladores y usuarios poseen diferentes modelos.

Los usuarios y los desarrolladores tienen distintas expectativas y niveles de conocimiento. El

conocimiento especializado de los desarrolladores permite su trato con situaciones complejas o

ambiguas en ciertos contextos, las cuales no son visibles por los usuarios. Además, los

desarrolladores usan frecuentemente una terminología que no siempre coincide con la de los

usuarios.

La intuición de los desarrolladores no es siempre la correcta.

La intuición de los diseñadores, o de cualquier persona envuelta en el diseño, es propensa a

errores, sin importar cuán bien o mal desarrollan su trabajo. Ciertos estudios han encontrado que la

intuición de los desarrolladores sobre la velocidad de control de uso no es igual a las velocidades

medidas. La intuición es demasiado superficial como para ser la base de las decisiones de diseño

de sistemas software.



No existen usuarios promedio.

Todos los usuarios difieren en cuanto a sus observaciones, sentimientos, habilidades motoras,

habilidades intelectuales, velocidad y habilidad de aprendizaje, preferencias de control de los

dispositivos, etcétera. Por ejemplo, en una tarea de ingreso de datos mediante el teclado,

probablemente los mejores usuarios serán el doble más rápidos que los más eficientes, y cometan

10 veces menos errores. El diseño debe permitir que gente con características ampliamente

variadas puedan aprender y desarrollar confortable y satisfactoriamente las tareas del sistema.

Es imposible predecir la usabilidad de un sistema por su apariencia.

Al igual como es imposible juzgar la personalidad de una persona por cómo se ve, es imposible

predecir la usabilidad de un sistema por su apariencia.

Los estándares y guías de diseño no son suficientes.

Los estándares y guías de diseño son componentes importantes para un buen diseño, generando la

base de consistencia de un sistema. Pero estos estándares y guías de diseño no son suficientes. No

pueden ser la base del diseño de todos los elementos de interacción necesarios para un sistema

completo.

La retroalimentación informal es insuficiente.

La retroalimentación informal es una propuesta que probablemente llevará al fracaso. Todas las

partes del sistema deben estar completamente revisadas y los problemas significativos deben estar

siempre documentados.

Los productos construidos por partes casi siempre poseen inconsistencias.

Cuando distintos desarrolladores trabajan en diferentes partes del sistema, el resultado normal y

esperado es que el producto final posea inconsistencias. Claramente los desarrolladores difieren,

no existen desarrolladores promedio.

Mientras más tarde se encuentran los problemas, más cara y dificultosa es su reparación.

Si un problema es encontrado en etapas tempranas del desarrollo de un sistema, no se torna tan

dificultosa ni cara su reparación, ya que es posible hacer los cambios y rehacer lo desarrollado.

Mientras más tarde, peor. A menos que los problemas sean realmente severos, estos nunca deben

ser reparados.



Los problemas reparados durante el desarrollo reducen los costos de mantenimiento en el futuro.

Los costos de mantenimiento son directamente proporcionales con los problemas de usabilidad

que permanecen después del desarrollo. Mientras más problemas de usabilidad, mayores son los

costos de mantenimiento.

Un producto puede llegar a ser satisfactorio.

Los productos son hechos para hacer algo. Los productos satisfactorios son los que permiten hacer

ese algo de manera fácil.

Ahora bien, los métodos de evaluación de usabilidad pueden ser clasificados en dos grupos:

Métodos de Inspección de Usabilidad: Inspecciones del diseño de la interfaz usando métodos

empíricos.

Métodos de Prueba de Usabilidad: Pruebas empíricas del diseño de la interfaz con

usuarios representativos.

Estas clasificaciones y los métodos involucrados en cada uno de los grupos serán analizados a continuación.

Se destacan los procesos involucrados para realizar cada uno de ellos, además de sus ventajas y desventajas más

generales, entre otras cosas.



5.1. Métodos de Inspección de Usabilidad

Los métodos de inspección de usabilidad corresponden a métodos de evaluación de usabilidad en que se

realizan inspecciones del diseño de la interfaz usando métodos heurísticos. Se basan en el análisis en vez de la

experiencia. Son realizados por expertos en usabilidad, y se basan en el recorrido y análisis del sistema que se está

evaluando, identificando errores y problemas de diseño.

Los métodos de inspección de usabilidad más reconocidos y utilizados son los siguientes:

Evaluación Heurística: Un grupo de evaluadores inspecciona el diseño de la interfaz a base de

los principios reconocidos de la usabilidad.

Recorrido Cognitivo: Análisis del aprendizaje. Recorrido orientado a tareas basado en el

modelo cognitivo formal de comportamiento de usuarios principiantes.

Análisis de Acciones: Análisis de la eficiencia. Análisis cuantitativo de las acciones con el

objetivo de predecir los tiempos requeridos por usuarios experimentados

para realizar ciertas tareas, en base a los tiempos estimados en realizar

acciones comunes en la interfaz.

5.1.1. Evaluación Heurística

La evaluación heurística (Heuristic Evaluation) es un método de evaluación de usabilidad en que un

pequeño grupo de evaluadores, generalmente especialistas en usabilidad, inspeccionan sistemáticamente el diseño de

la interfaz del sistema en cuestión basándose en los principios de usabilidad, también llamados principios heurísticos

o simplemente heurísticas.

Este método de evaluación de usabilidad es el más popular de los métodos de inspección, básicamente por

su facilidad y rapidez de realización. Puede ser realizado en distintas etapas del desarrollo de software, incluso muy

tempranamente, por lo que no es necesaria la disponibilidad de una versión terminada del sistema. Aunque el método

es simple, los problemas no necesariamente son fáciles de encontrar, siempre dependiendo de la cantidad y nivel de

los evaluadores. Es bastante eficiente, pero no es un método tan exhaustivo como para encontrar todos y cada uno de

los problemas de usabilidad en un sistema.

En muchos casos, con la evaluación heurística se encuentran problemas de usabilidad no percibidos con la

realización de algunos de los métodos de prueba, y viceversa, claramente por la característica empírica que presentan

estos últimos.



5.1.1.1. Evaluadores

Los tipos de evaluadores envueltos en la evaluación heurística poseen una importancia no menor, ya que

influyen directamente en los resultados que presenta la realización de este método de evaluación de usabilidad.

Deben ser personas que conocen en cierto grado las características que debe poseer un sistema usable, y que tengan

cierta experiencia en lo que son las evaluaciones heurísticas, es decir, deben ser especialistas en usabilidad, algunos

más que otros, pero lo óptimo es que todos lo sean en niveles aceptables.

Una evaluación heurística satisfactoria, que entregue resultados relevantes, debería ser realizada por más de

un evaluador, ya que con una persona no es posible encontrar todos los problemas de usabilidad de la interfaz de un

sistema. Ciertos estudios han encontrado que diferentes evaluadores encuentran distintos problemas de usabilidad,

por lo que la participación de varios evaluadores en una evaluación heurística permite que se encuentren mayor

cantidad de problemas de usabilidad, mejorando la eficiencia de este método.

La Figura 5.1 es la muestra de los resultados que obtuvo una investigación de la evaluación heurística y sus

evaluadores, para un caso de estudio en que 19 (diecinueve) evaluadores realizaban una inspección de un sistema

bancario, el cual poseía 16 (dieciséis) problemas de usabilidad. Cada casilla negra corresponde a un problema

encontrado por un evaluador. La gráfica marca la diferencia, de izquierda a derecha, entre los problemas más

difíciles de encontrar y los fáciles, como también, de arriba hacia abajo, entre los evaluadores que encontraron menos

problemas y los que encontraron más.

Figura 5.1: Problemas Identificados Evaluación Heurística de un Sistema Bancario [12]

Conclusiones de este estudio hay varias. No hay un patrón que establezca que tipo de problemas encuentran

los evaluadores con más facilidad. Algunos problemas fáciles de encontrar no fueron encontrados por todos, y

algunos problemas difíciles fueron encontrados por evaluadores que no encontraron muchos problemas. No hay

forma de justificar cuáles evaluadores son mejores, ni cual evaluador será el que siempre encontrará muchos

problemas y/o problemas difíciles de encontrar.



Ahora bien, ¿cuál es la cantidad óptima de evaluadores para realizar una evaluación heurística? La Figura

5.2 y la Figura 5.3 son gráficos representativos de estudios realizados por Jakob Nielsen, para determinar el número

de evaluadores necesario para obtener resultados eficientes con una buena relación costo/beneficio. Sus resultados

son a base de la realización de evaluaciones heurísticas sobre seis casos de estudio distintos.

Figura 5.2: Número de Evaluadores vs Proporción de Problemas Encontrados [12]

Figura 5.3: Número de Evaluadores vs Relación Costo/Beneficio [12]

La Figura 5.2 muestra claramente que el uso de sólo un evaluador en una evaluación heurística no es

eficiente. Sin embargo, una evaluación heurística con cinco evaluadores sería más que razonable, ya que se obtienen

aproximadamente el 75% de los problemas sin tener que involucrar grandes cantidades de evaluadores.



La Figura 5.3 indica que la mejor relación costo/beneficios se da involucrando a cuatro evaluadores en la

evaluación heurística, con beneficios que llegan a superar 62 (sesenta y dos) veces a los costos.

Finalmente, y a base de lo analizado en los estudios anteriormente mostrados, el número óptimo de

evaluadores para realizar una evaluación heurística es entre tres y cinco, ya que se obtiene un buen porcentaje de

problemas de usabilidad y la relación costo/beneficio es la mejor.

5.1.1.2. Heurísticas

Las heurísticas o principios heurísticos en que se basan los evaluadores pueden ser de distintas fuentes o

autores. Generalmente, los principios de usabilidad propuestos por Jakob Nielsen (véase subcapítulo 4.4) son los más

utilizados como las heurísticas que guían este tipo de evaluación.

5.1.1.3. Técnica

El proceso involucrado en el desarrollo de una evaluación heurística consta de distintas etapas. Las

actividades de cada una de éstas serán presentadas a continuación, para luego analizar detalladamente sus aspectos

más importantes [14]:

Preparación de la sesión: Para dar comienzo a la evaluación heurística se debe, primeramente,

seleccionar a los evaluadores participantes de la evaluación. Idealmente entre tres y cinco, y con

cierta familiaridad con el sistema y/o el área de éste. Luego, se debe preparar los materiales

necesarios para el evaluador, como son la visión del proyecto o sistema, y la lista de los principios

heurísticos. Finalmente se ejecuta una reunión con los evaluadores para instruirlos en la evaluación

y resolver las dudas que puedan surgir, para posteriormente comenzar la evaluación sin ningún tipo

de problemas. Así, las actividades involucradas en la preparación de la sesión son las siguientes:

o Selección de los evaluadores.

o Preparación de:

Visión general del proyecto.

Lista de los principios heurísticos.

o Instrucción de los evaluadores:

Revisión del propósito de la evaluación.



Revisión del proceso de la evaluación.

Presentación de la visión general del proyecto y los principios heurísticos.

Resolución de preguntas de los evaluadores.

Proporcionar capacitaciones especiales a los evaluadores, si es necesario.

Desarrollo de la sesión: Cada uno de los evaluadores debe comenzar a inspeccionar el sistema en

solitario, asegurando así la imparcialidad e independencia de las evaluaciones de cada uno. Estos

deben establecer su propio método de revisión del sistema en cuestión. Si el sistema no es familiar

para el evaluador, éste debe crearse escenarios para así seguir ciertos pasos secuenciales dentro del

sistema, realizando tareas características y realistas de los usuarios con el sistema.

Durante la sesión, los evaluadores deben comparar sus descubrimientos con la lista de los

principios de usabilidad, alineando cada uno de los problemas encontrados con el principio de

usabilidad que viola, pudiendo darse el caso que un problema viole más de uno.

Los comentarios (problemas y cosas buenas del sistema) que identifica el evaluador pueden ser

apuntados por este mismo o por un observador o administrador de la evaluación heurística. Si es

este último el que guarda los comentarios, es posible que el evaluador se enfoque completamente

en la inspección del sistema, solamente verbalizando los comentarios al observador. Es más, si el

mismo observador es el que apunta los comentarios de todos los evaluadores, se agiliza el proceso

ya que puede ordenar e integrar todos los problemas inmediatamente. El observador debe, además,

responder preguntas del evaluador si se le solicita y dar consejos.

Por último, la sesión no debería durar más de dos horas, principalmente por razones de cansancio y

fatiga de los evaluadores. En resumen, las actividades son:

o Cada evaluador inspecciona el sistema en solitario.

o El evaluador debe:

Establecer su propio proceso o método de inspección del sistema.

Proporcionar escenarios de uso, si es necesario.

Comparar sus problemas con los principios de usabilidad.

Identificar cualquier otro problema o asunto importante.

Realizar al menos dos pasadas inspeccionando el sistema.



o Los problemas detectados deben ser alineados con los principios heurísticos que violan.

o Los comentarios son guardados por el evaluador y/o un administrador.

o El administrador debe responder preguntas y dar consejos.

o Restricción de la sesión a no más de dos horas.

Post-sesión: Luego de haber realizado el proceso mismo de inspección del sistema por los

evaluadores, se debe establecer una reunión entre el observador y todos los evaluadores. Estos

últimos presentan los problemas encontrados y los principios heurísticos que viola cada uno. Si no

se ha realizado, se debe generar una lista con todos los problemas encontrados, de forma integrada,

es decir, que no se repitan problemas iguales o muy parecidos, para luego discutir sugerencias para

mejorar los aspectos problemáticos del sistema.

Después de esta reunión, se debe generar un ranking de los problemas de usabilidad encontrados a

base de las calificaciones que entregan cada uno de los evaluadores (la forma de calificación de los

problemas se mostrará más adelante), para terminar con un análisis de los resultados y propuestas

de solución de los problemas. En resumidas cuentas, el proceso es el que sigue:

o Reunión del administrador con los evaluadores:

Cada evaluador presenta los problemas detectados y la heurística que viola.

Creación de una lista integrada de los problemas de todos los evaluadores.

Diseño de sugerencias para mejorar los aspectos problemáticos del sistema.

o Post-reunión:

Cada evaluador, independientemente, asigna calificaciones a los problemas de la

lista integrada.

Generación de un ranking de problemas en orden de importancia, según las

calificaciones promediadas.

Análisis de los resultados y establecimiento de un programa de corrección de los

problemas.



En esta última etapa, como se puede notar en las actividades anteriormente analizadas, se debe realizar una

clasificación o priorización de los problemas encontrados por los evaluadores, mediante la asignación de

calificaciones que determinarán la criticidad de cada problema. Cada evaluador asigna, de forma independiente, un

valor de severidad (escala de 0 a 4, como muestra la Tabla 5.1) y un valor de frecuencia (escala de 0 a 4, como

muestra la Tabla 5.2) a cada uno de los problemas, permitiendo calcular la criticidad del problema de la siguiente

forma:

Criticidad = Severidad + Frecuencia

Tabla 5.1: Escala de Severidad

Calificación Severidad Prioridad de corrección

4 Problema catastrófico Imperativo

3 Problema mayor Alta

2 Problema menor Baja

1 Problema cosmético -

0 No es un problema -

Tabla 5.2: Escala de Frecuencia

Calificación Frecuencia (f)

4 f > 90%

3 50% < f ≤ 90%

2 10% < f ≤ 50 %

1 1% < f ≤ 10%

0 0% ≤ f ≤ 1%

Las tablas muestran que mientras mayor es la calificación, ya sea en cuanto a severidad o frecuencia, el

problema de usabilidad es mayor, lo que se verá reflejado en la criticidad del problema que corresponde a la suma de

las dos calificaciones anteriores.



Así, los problemas con mayor calificación serán ordenados al principio del ranking, desde los que necesitan

corrección de forma imperativa o urgente, hasta los problemas que en realidad no tienen importancia o no

corresponden. Un problema con calificación cero, claramente no corresponde a un problema de usabilidad.

5.1.2. Recorrido Cognitivo

Este método de inspección de usabilidad, conocido también como Cognitive Walkthrough, se enfoca

explícitamente en lo que es el aprendizaje. Corresponde a un recorrido de la interfaz orientado a tareas basado en el

modelo cognitivo formal de comportamiento de usuarios principiantes. Está basado en la teoría de aprendizaje por

exploración, en que los usuarios infieren los pasos que deben seguir para realizar ciertas tareas del sistema. De esta

forma, los usuarios no se apoyan de documentos de ayuda o manuales de uso al momento de enfrentarse a sistemas

nuevos, sino que aprenden explorando el sistema.

Para el desarrollo del recorrido cognitivo los analistas deben tomar en cuenta detalladamente el modelo

mental de los usuarios para con el sistema, en desmedro de la realización de evaluaciones de las características del

diseño de la interfaz. Así, estudian el comportamiento del usuario para inferir las acciones típicas que tomará con el

sistema.

Al igual que en las evaluaciones heurísticas, para la realización del método del recorrido cognitivo no es

necesaria la disponibilidad de una versión terminada del sistema a evaluar. Es más, al realizar el recorrido cognitivo

en etapas iniciales del desarrollo de software, es posible determinar la calidad del diseño que se está implementando.

Por el contrario, no es recomendable realizar este método en las etapas finales, ya que un método de prueba de

usabilidad sería más eficiente.

5.1.2.1. Preparación del Recorrido Cognitivo

La preparación del recorrido cognitivo tiene como objetivo principal determinar las tareas comunes de los

usuarios y la secuencia de pasos que realizará para completar esta tarea con éxito. Así, la preparación involucra lo

siguiente:

Identificación de la población de usuarios: Identificación de los usuarios participantes de la

evaluación, su experiencia previa y conocimiento técnico con interfaces de usuario y tareas

similares.

Definición de un conjunto de tareas representativas: Definición de un conjunto limitado pero

representativo de tareas de los usuarios. La selección de estas tareas no es trivial, ya que se debe



considerar muchos aspectos, desde estudios de marketing hasta análisis de requerimientos de los

usuarios.

Descripción o implementación de la interfaz de usuario: Definición de las señales que el usuario

debe soportar para apoyar el desempeño de cada una de las tareas, indicaciones para cada acción y

retroalimentación de estas acciones.

Definición de las secuencias de acciones para realizar las tareas: Definición de los objetivos que

visualizará el usuario para realizar cada una de las tareas y qué acciones ejecutará para realizar ese

objetivo.

5.1.2.2. Desarrollo del Recorrido Cognitivo

Luego de haber definido completamente las tareas representativas del usuario para con el sistema, y la

secuencia de pasos que el usuario realizará durante la ejecución de la tarea para completarla con éxito, es posible

comenzar el desarrollo del recorrido cognitivo.

Es importante destacar que el recorrido cognitivo no es realizado por usuarios reales, sino que el recorrido

lo hacen los mismos diseñadores, ingenieros de software, especialistas en usabilidad, etcétera. Así, el o los analistas

presentan el sistema a el o los usuarios que realizarán el recorrido. Los usuarios comienzan a realizar las tareas que

se les solicita, mientras los analistas estudian el comportamiento de estos usuarios. El análisis se limita solamente a

las tareas seleccionadas en las etapas anteriores, prestando atención a cada una de las acciones que se desarrollan.

En resumen, el análisis se concentra en tres aspectos importantes:

Soporte del sistema para con el usuario para cumplir su objetivo.

Forma en que el sistema entrega indicadores para realizar cierta tarea.

Retroalimentación del sistema.

Además, los analistas se enfocan en cuatro preguntas relacionadas con cada tarea, que permitirán dilucidar

la concordancia entre lo que los analistas definieron y lo que los usuarios realizan. Estas preguntas son [15]:

1. ¿Intentará el usuario obtener el efecto correcto? ¿El usuario dividirá las tareas en acciones similares a

las que los analistas asumieron?

2. ¿El usuario sabrá si la acción correcta está disponible? ¿El usuario es capaz de percibir los controles

necesarios o, de lo contrario, saber qué hacer?



3. ¿El usuario asociará que la acción correcta tendrá el efecto deseado? ¿Las etiquetas, iconos y

terminología son claras para el usuario?

4. Si el usuario realiza la acción correcta, ¿sabrá que el objetivo está más cerca? ¿La retroalimentación del

sistema es la suficiente?

A base de todos estos parámetros, los analistas deben estudiar si el diseño de la interfaz del sistema es el

correcto. Los analistas se preocupan de las tareas que los usuarios no pudieron realizar o que realizaron con

dificultades, ya que son las que entregan información sobre los problemas de usabilidad existentes. Las tareas que se

realizaron con éxito corresponden a aciertos de los analistas, por lo que se dejan en el pasado y se presta la atención

en las otras tareas que sí entregaron problemas de usabilidad.

5.1.3. Análisis de Acciones

El método de evaluación de usabilidad conocido como análisis de acciones (Action Analysis) corresponde a

un análisis cuantitativo de las acciones para predecir el tiempo requerido por usuarios expertos para realizar ciertas

tareas, basándose en los tiempos estimados para realizar acciones típicas del sistema. Así, su principal objetivo es la

medida de la usabilidad en torno a usuarios expertos, es decir, se enfoca en el análisis de la eficiencia del diseño de la

interfaz del sistema. Este método posee dos niveles de detalle: formal e informal, los cuales serán analizados

detalladamente a continuación.

5.1.3.1. Análisis de Acciones Formal

El análisis de acciones formal, también conocido como “nivel golpe de teclado”, posee un nivel de detalle

considerable. Fue desarrollado a partir del modelo GOMS (Goals, Operators, Methods, Selection), es decir, el

modelo de objetivos, operadores, métodos y selección. Al ser un análisis de acciones muy detallado, logra obtener

altos niveles de eficiencia, llegando a predecir la duración de una tarea con un margen de error del 20%. Sin

embargo, es complicado llevarla a cabo, ya que, por su extremada característica de incurrir en los detalles, se torna

muy tediosa.

Su aplicación está en los sistemas de alto nivel de uso, en que el tiempo es de suma importancia, los cuales

necesitan grandes niveles de eficiencia. El nivel de detalle de este método llegar a considerar el tiempo en fracciones

de segundos, analizando cada una de las acciones que un usuario experto realiza sobre el sistema.

El proceso para desarrollar un análisis de acciones formal es el siguiente:



Definición de las tareas representativas de un usuario experto en el sistema.

División de las tareas en subtareas, de modo que el nivel de detalle llegue a fracciones de segundos.

Asignar valores de tiempo a cada una de las subtareas.

Este último punto es muy importante y complicado de desarrollar, ya que conlleva un análisis de cada uno

de los movimientos que el usuario realiza durante la interacción con el sistema, por lo que se debe recurrir a literatura

específica en este ámbito. La tabla a continuación muestra los tiempos promedio de un análisis de acciones formal

típico.

Tabla 5.3: Tiempos Promedio de un Análisis de Acciones Típico [16]

Acción Tiempo (segundos)

Movimientos Físicos

Golpe de teclado

Click al mouse

Movimiento de la mano al mouse o al teclado

0.28

1.5

0.3

Percepción Visual

Respuesta a estímulo luminoso

Reconocimiento de palabra de seis letras

Movimiento de los ojos a una nueva área de la pantalla

0.1

0.34

0.23

Acciones Mentales

Recuperar un elemento de la memoria a largo plazo

Aprendizaje de un paso del procedimiento

Ejecución de un paso mental

Elección entre métodos

1.2

25

0.075

1.2

La Tabla 5.3 toma los valores de tiempo basándose en estudios anteriores descubiertos en la literatura. Al

realizar el análisis de acciones, los analistas no estudian la veracidad de estos tiempos para determinar la eficiencia,

sino que toman como base las publicaciones que muestran estos resultados.



5.1.3.2. Análisis de Acciones Informal

El análisis de acciones informal posee un nivel de detalles muy inferior al presentando anteriormente,

evaluando y analizando las acciones involucradas en las tareas comunes de un usuario experimentado a un nivel un

poco más amplio.

Los analistas intentan medir la eficiencia del sistema en cuanto a la usabilidad a grandes rasgos,

enfocándose en acciones más palpables, como por ejemplo la confirmación de una acción presionando el botón OK,

el paso a una siguiente etapa o página presionando el botón siguiente, el ingreso de una clave, el relleno de un campo

de identificación, etcétera.

Así, el proceso para el análisis de acciones informal es casi idéntico al de análisis informal, con la gran

diferencia en el nivel de detalle de las acciones:

Definición de las tareas representativas de un usuario experto en el sistema.

División de las tareas en subtareas, de modo que el nivel de detalle llegue a algunos segundos.

Asignar valores de tiempo a cada una de las subtareas.

Esto permitirá una estimación más rápida de los tiempos envueltos en la realización de cierta tarea por un

usuario experto, aunque con un poco menos de exactitud que con el método anterior.



5.2. Métodos de Prueba de Usabilidad

Los métodos de prueba de usabilidad corresponden a métodos de evaluación de usabilidad que realizan

pruebas empíricas del diseño de la interfaz con usuarios representativos, es decir, son pruebas basadas en la

experiencia real de los usuarios.

Los métodos de prueba de usabilidad más reconocidos y utilizados son los siguientes:

Pruebas en Papel: Se muestran aspectos de la interfaz al usuario, y responde a

ciertas preguntas.

Pensando en Voz Alta: Los usuarios verbalizan sus impresiones mientras interactúan

con el sistema.

Interacción Constructiva: Un par de usuarios exploran la interfaz en conjunto y comentan

sus impresiones durante la interacción.

Experimentos Formales: Los usuarios realizan las tareas solicitadas por los evaluadores

de forma controlada y medible, permitiendo un análisis

estadístico.

Técnicas de Interrogación: Los usuarios responden a entrevistas y/o cuestionarios.

Ordenamiento de Tarjetas: Los usuarios agrupan y asocian tarjetas etiquetadas con las

categorías temáticas del sistema en evaluación.

Dentro de las características más importantes de estos métodos de evaluación de usabilidad está el hecho de

que la evaluación es realizada bajo condiciones controladas y de la forma más representativa posible de la realidad

(lugar real de trabajo con el sistema o laboratorios de usabilidad), en donde los usuarios realizan ciertas acciones

asignadas por los evaluadores con el fin de rescatar información de su experiencia con el sistema que se está

analizando, de manera de encontrar problemas de usabilidad.

Las ventajas de realización de los métodos de prueba de usabilidad son la ya nombrada representatividad del

mundo real del entorno de la prueba y la buena capacidad de encontrar problemas importantes, serios y recurrentes

de la usabilidad del sistema en evaluación. Ahora bien, su desventaja más importante está en el costo de

establecimiento de las instalaciones necesarias para un ambiente lo más representativo posible.



Todos estos tipos de métodos de evaluación de usabilidad siguen un mismo proceso, en donde es necesaria

la preparación de la prueba a realizar, el entorno de la prueba, definición de los perfiles de usuarios, selección de los

usuarios representativos, diseño de la prueba, entre otros aspectos necesarios para su realización, todos los cuales

serán analizados detalladamente más adelante.

Los métodos de prueba de la usabilidad pueden ser desarrollados para dos distintos propósitos: evaluación

formativa o evaluación aditiva.

Evaluación Formativa: Ayuda a mejorar el diseño de la interfaz, permitiendo aprender el por

qué de los errores encontrados. Se realiza una recolección de datos,

correspondientes a observaciones cualitativas de lo que está pasando y

por qué.

Evaluación Aditiva: Evaluación de la calidad en general de la interfaz, realizando

comparaciones de alternativas de diseño y definición de requerimientos

de eficiencia. Se realiza una recolección de datos cuantitativos como los

tiempos envueltos en una tarea, cantidad de errores, etcétera.

El lugar físico de desarrollo de los métodos de prueba de usabilidad es un tema que no se debe dejar de

considerar. Este aspecto es muy importante ya que, al ser pruebas empíricas, los usuarios deben sentirse cómodos en

el lugar en que realizan las pruebas y debe ser un ambiente lo más representativo posible de la realidad, sino el

mismo lugar de interacción con el sistema. Debe ser un lugar tranquilo, silencioso, con luces adecuadas y donde no

se permita la desconcentración de los usuarios.

Para este objetivo, algunos investigadores, organizaciones, universidades o agentes investigadores de la

usabilidad, han construido los denominados laboratorios de usabilidad. Los laboratorios de usabilidad son

habitaciones diseñadas exclusivamente para la realización de los métodos de prueba de usabilidad. Estos permiten

tener un mayor control de usuario y de las acciones que desarrolla, ya que los usuarios y evaluadores se encuentran

en un lugar adaptado especialmente para las pruebas y, por lo tanto, las medidas se tornan más precisas.

Para los evaluadores, el laboratorio de usabilidad es una herramienta muy provechosa, por las ventajas y

características que ofrece; para los participantes de las pruebas, sin embargo, el hecho de tener que trasladarse a estos

laboratorios puede ser un pequeño obstáculo en ciertas ocasiones.



Las Figuras 5.4 y 5.5, a continuación, muestran distintos tipos de laboratorios de usabilidad, con

considerables diferencias en los niveles de equipamiento. El primer caso (Figura 5.4) corresponde a una habitación

simple, en que el evaluador rescata la información solamente con sus percepciones visuales. Por otro lado, la Figura

5.5 corresponde a un laboratorio de usabilidad completo, que posee todos los implementos necesarios para un

análisis detallado de la interacción (espejo unidireccional, cámaras de video, micrófonos, computadores para

visualizar la interacción, etcétera).

Figura 5.4: Laboratorio de Usabilidad Simple [16]



Figura 5.5: Laboratorio de Usabilidad Completo [16]

Es momento de hacer una revisión del proceso involucrado en el desarrollo de los métodos de prueba de

usabilidad. Para realizar cualquiera de estos métodos es necesario seguir algunos pasos, los cuales se analizan a

continuación:

Definición de la prueba: Esta parte es muy importante, ya que corresponde a la definición de todos

los aspectos básicos para realizar la prueba, lo que permitirá obtener una clara visión del plan y los

objetivos de la prueba. La definición incluye el propósito de la prueba, descripciones, recursos

necesarios y un programa a seguir, entre otras cosas. En definitiva, la definición de la prueba debe

incluir:

o Propósito de la prueba: Evaluación formativa o aditiva.

o Descripción del problema: Definición del problema que motiva la realización de la prueba

sobre el sistema.

o Perfiles de usuarios: Definición de los tipos de usuarios que serán considerados para las

pruebas.

o Metodología de la prueba: Diseño de la prueba.



o Lista de tareas: Definición de las tareas a realizar por el usuario, priorizándolas por

frecuencia y criticidad. Definición de los prerrequisitos, criterios de concreción, tiempos y

errores posibles para cada una de las tareas.

o Entorno de la prueba: Definición del lugar físico de realización de la prueba e

implementos necesarios para llevarla a cabo.

o Datos a recolectar: Definición de los tipos de datos que se rescatarán para su evaluación.

o Contenido del informe: Definición del contenido y estructura del informe final con el

análisis de los resultados obtenidos.

Selección de participantes: Los participantes de la prueba deben corresponder a usuarios

representativos que se encajen en alguno de los perfiles de usuario definidos en la sección anterior,

mediante la realización de un pequeño cuestionario. Se deben obtener al menos cuatro usuarios

representativos para cada uno de los perfiles. Estos pueden ser estudiantes, usuarios reales o

cualquier persona que se encaje al perfil. En algunos casos se poseen bases de datos con

potenciales participantes, a la cual se van agregando registros cada vez que se obtienen

participantes nuevos.

Preparación de los materiales: Preparación de la documentación necesaria para realizar la prueba,

como los acuerdos de confidencialidad, posibles documentos de orientación sobre la prueba,

apuntes para evaluar el progreso de la prueba, cuestionarios pre y postprueba y cualquier

documento que se deba disponer.

Ejecución de prueba piloto: Antes de realizar la prueba misma es necesario ejecutar una prueba

piloto, que asegure una correcta definición de la prueba y de los pasos envueltos en ella. Sirve

además para evaluar el correcto desempeño de los implementos, para estimar la duración de las

tareas y del proceso. Se debe realizar previamente a la ejecución de las pruebas reales (un par de

días) para poder tomar medidas correctivas si es necesario.

Realización de la prueba: Los participantes realizan, uno a uno, la prueba de usabilidad. Debe

existir una persona encargada de la comunicación con el participante, mientras los analistas sólo se

encargan de observar el proceso para obtener la información necesaria. Es importante recalcar al

participante que la prueba tiene sólo fines de evaluación de la usabilidad del producto, no del nivel

de eficiencia o inteligencia de la persona. El participante realiza las tareas que se le solicitan de

forma ininterrumpida, salvo que éste solicite ayuda o se vea con muchas dificultades. Al final de la

prueba, es posible realizar cuestionarios o entrevistas. Toda la información es almacenada para su

posterior análisis.



Análisis de la prueba: En esta parte se estructuran las interpretaciones y descripciones de la

experiencia del usuario. Se analizan los problemas de usabilidad encontrados y se postulan

recomendaciones para mejorar esos problemas y la usabilidad íntegra de la interfaz que se está

evaluando. En términos generales, se deben realizar dos conjuntos de acciones importantes:

o Síntesis de los datos: Recolección y síntesis de los datos relevantes para su posterior

análisis como los tiempos de las tareas, información estadística (promedios, mínimos,

máximos, etcétera), porcentajes de concreción de las tareas, tasas de error, gráficos

representativos, etcétera.

o Análisis de los datos: Se realiza un estudio de los datos recolectados para identificar y

formalizar los problemas de usabilidad. Se identifican los errores y sus causas, creando

finalmente una lista con todos los problemas ordenados según severidad o criticidad junto

con las posibles soluciones a esos problemas.

Finalmente, se desarrolla un informe final de la prueba, el cual contiene toda la información del

proceso, desde los datos de definición de la prueba (propósito, perfiles de usuario, entorno,

etcétera), participantes, materiales, prueba piloto, desarrollo de la prueba, hasta la información

sobre los problemas de usabilidad encontrados que entregó el análisis.

Todo este proceso puede ser aplicado a cualquiera de los métodos de prueba de usabilidad que serán

analizados posteriormente. Al final del proceso completo ya se han encontrado los problemas de usabilidad del

sistema en evaluación y se han postulado algunas posibles soluciones, por lo que ya es factible y recomendable

realizar los cambios en el sistema para mejorar su usabilidad y la experiencia del usuario durante la interacción. Así,

se reconoce un proceso iterativo, en que los métodos de prueba de usabilidad encuentran los problemas de usabilidad

para la posterior modificación del sistema, luego se evalúa nuevamente el sistema mediante las pruebas y se hacen

los cambios y así sucesivamente, hasta que sea necesario o se cuente con la factibilidad técnica y económica para

realizar el proceso.

Cada uno de los métodos de prueba de usabilidad será analizado a continuación, destacando sus

características más importantes y su forma de implementación.

5.2.1. Pruebas en Papel

Las pruebas en papel son realizadas para evaluar el diseño de la interfaz principalmente en etapas tempranas

del desarrollo de un producto software. En rigor, antes de la implementación, en donde ya es posible disponer de

prototipos del sistema en algún dispositivo.



En este tipo de pruebas, se crea un prototipo de la interfaz en papel y se hacen preguntas a los usuarios, con

el objetivo de identificar problemas de usabilidad con anterioridad a la implementación. Las preguntas deben estar

previamente diseñadas para rescatar información relevante a base de lo que se muestra al usuario, pero en algunos

casos es posible realizar preguntas en el momento dependiendo del avance de la prueba. El formato de las

preguntas/respuestas puede ser en papel o simplemente a viva voz, siempre considerando que el prototipo que se

muestra al usuario es en papel.

Claramente, el propósito de este tipo de método de prueba de usabilidad es la evaluación formativa, ya que

se recolectan datos que servirán como una retroalimentación para el diseño de la interfaz, aprendiendo de los errores

encontrados en los prototipos en papel.

Las ventajas de este método de evaluación de usabilidad están en su eficiencia para encontrar problemas de

usabilidad tempranamente dentro del desarrollo de un producto software, además de su bajo costo de

implementación (son pruebas con papel y lápiz, como dice su nombre en inglés “Paper and Pencil Test”) y su

rapidez.

Un ejemplo de un prototipo en papel para este tipo de prueba es el que se muestra en la Figura 5.6. Se nota

claramente que corresponde a un bosquejo de lo que se pretende implementar. Lo interesante de este método es que a

base de este tipo de bosquejos es posible evaluar la usabilidad.

Figura 5.6: Ejemplo de Prototipo en Papel



5.2.2. Pensando en Voz Alta

Este método de prueba de usabilidad, originalmente denominada Thinking Aloud, tiene como característica

principal que los usuarios, mientras realizan ciertas tareas, expresan sus pensamientos a viva voz. Por lo mismo,

permite rescatar información cualitativa sobre las percepciones del usuario durante la interacción, ya que el usuario

verbaliza sus interpretaciones sobre el sistema, los beneficios, problemas y dificultades que experimenta.

Los participantes deben verbalizar sus impresiones en el mismo momento en que las piensan, mientras los

analistas deben rescatar todas esas impresiones que serán relevantes para el posterior análisis. En general, los

usuarios deben expresar lo siguiente [16]:

Lo que están intentando hacer.

Lo que leen.

Preguntas que pasan por su mente.

Situaciones o elementos que lo confunden.

Decisiones que toman.

Es imperativo instruir al usuario sobre el formato de la prueba y sobre la importancia de que exprese a viva

voz todas las situaciones mostradas anteriormente. Esto, en algunos casos, es ciertamente complicado, ya que lo

usuarios no verbalizan todo por razones de incomodidad o timidez. Por lo mismo, también es posible que un analista

o encargado de la prueba realice algunas preguntas durante la interacción para motivar al participante y rescatar más

información.

Las ventajas de este método están un su gran capacidad para encontrar problemas de usabilidad y el por qué

de estos problemas con un número reducido de participantes (en general, de tres a cinco participantes), mientras que

la desventaja más sobresaliente es que, en algunos casos, la expresión de los pensamientos por parte de los usuarios

puede influir en su interacción con el sistema.



5.2.3. Interacción Constructiva

La interacción constructiva es un método de prueba de usabilidad en que dos usuarios interactúan

conjuntamente, descubriendo las características del sistema en evaluación, mientras verbalizan sus impresiones

mutuamente, como una conversación. Así, los usuarios establecen una comunicación e interacción natural mientras

descubren el sistema, sin limitarse a una lista de tareas específica.

Este método de prueba surgió en parte para solucionar las desventajas que mostraba el método

anteriormente analizado, de pensamiento en voz alta. Al ser esta última una prueba en que un usuario verbaliza sus

impresiones, se generan ciertas dificultades en él para expresar todo lo que piensa, ya que el ambiente es

relativamente irreal. Por esto, la interacción constructiva propone que dos participantes interactúen con el sistema

expresando sus impresiones de una forma más realista, conversando entre sí.

Sin embargo, este tipo de prueba también posee sus desventajas: los usuarios no poseen las mismas

estrategias de resolución de tareas y los sistemas evaluados no son comúnmente usados por dos personas a la vez, lo

que haría perder el grado de representación de la realidad.

5.2.4. Experimentos Formales

Los experimentos formales corresponden a experimentos controlados y medibles con usuarios de prueba.

Los usuarios realizan las tareas solicitadas sobre el sistema mientras los analistas observan la interacción. Se

almacena toda la información necesaria para su posterior estudio, desde los archivos de video con las acciones que

realiza el usuario en la interfaz hasta los videos de las reacciones del mismo durante la interacción.

Así, es posible realizar un análisis estadístico de las acciones del usuario, considerando los tiempos

involucrados, tasa de errores, etcétera.

El propósito de este método de prueba de usabilidad es la evaluación aditiva, ya que se evalúa la usabilidad

íntegra del sistema en cuestión y es posible realizar comparaciones entre alternativas de diseño si se dispone de ellas,

además de la característica ya nombrada de recolección de datos cuantitativos como las cantidades involucradas con

los tiempos y errores.

Este tipo de evaluación es bastante ocupado y reconocido como método de medición de la usabilidad. Es

bastante común percibir mediciones de la usabilidad en ciertos sistemas realizando el método de inspección de

usabilidad conocido como la evaluación heurística, analizado anteriormente, y este método de prueba de usabilidad.



Las ventajas de este método están en la capacidad de poder evaluar distintas alternativas de diseño y de

poder recolectar y analizar datos cuantitativos de distintos niveles de complejidad. Sus desventajas se enmarcan en

torno al número de usuarios (entre dieciséis y veinte participantes) necesario para hacer un análisis estadístico y la

posibilidad de realizar el método sólo en etapas finales del proceso de desarrollo de software.

5.2.5. Técnicas de Interrogación

Las técnicas de interrogación corresponden a preguntas a los participantes de pruebas de usabilidad después

de haber realizado las tareas solicitadas. Su objetivo principal es la obtención de información subjetiva sobre el

sistema que se está evaluando. Permiten rescatar información que no es posible captar con las pruebas mismas.

Una de las técnicas de interrogación son las entrevistas. Al finalizar la prueba de usabilidad, el usuario se

somete a una entrevista en la cual se intentará rescatar información sobre la experiencia con el sistema, sus

perspectivas, impresiones, consejos, etcétera.

Los cuestionarios corresponden a otro tipo de técnica de interrogación. Son cuestionarios escritos que

buscan obtener información cualitativa y cuantitativa sobre la experiencia del usuario. Al ser cuestionarios en papel

que el participante debe rellenar, es más fácil su almacenamiento y posterior análisis, pero se pierde la relación

directa con el éste.

Claramente, sus ventajas están en la simplicidad y bajo costo de realización, mientras que la desventaja es

que la información subjetiva en algunos casos es poco fiable.

5.2.6. Ordenamiento de Tarjetas

Este método de prueba de usabilidad, conocido originalmente como Card Sorting, se asocia a la arquitectura

de la información en el diseño de sitios web. Por esto, es la técnica más usada para visualizar el pensamiento de los

usuarios respecto de la organización de la información en cualquier medio interactivo.

La técnica consiste básicamente en que los usuarios agrupan y asocian un número predeterminado de

tarjetas etiquetadas con las diferentes categorías temáticas del sistema a evaluar. Para esto, en un principio los

evaluadores deben identificar las distintas categorías que se representarán en las tarjetas. Después de la creación de

las tarjetas y la disposición de los usuarios, se procede a la realización de la prueba, donde el evaluador no debe

poner ningún tipo de indicación que pueda influenciar a los usuarios en su decisión, así como ningún tópico que

induzca a la agrupación de términos, como los típicos archivo, edición, ver, etcétera.



La ordenación de tarjetas es uno de los métodos de prueba de usabilidad más simples de realizar, fácil de

entender y fácil de aplicar. Además, sus características hacen que su realización sea económica y rápida.



5.3. Análisis Comparativo de los Métodos de Evaluación de Usabilidad

Claramente, cada uno de los métodos de evaluación de usabilidad tiene sus propias características y sus

propias ventajas y desventajas que lo diferencian de los otros, lo que permite captar las fortalezas y debilidades que

determinarán cuándo y bajo qué parámetros es conveniente realizar uno de los métodos sobre otro, ya sea para los

métodos de inspección como para los métodos de prueba. Algunos de estos ya se nombraron en las secciones

anteriores al analizar cada uno de los métodos por separado, pero solo se mostraron una o dos ventajas y/o

desventajas (las más importantes), por lo que ahora se analizará cada una de éstas con el fin de obtener una visión

más completa de las características de los métodos de evaluación de usabilidad. Esto permitirá, finalmente, realizar

un análisis comparativo de las características de cada uno de los métodos.

Las ventajas y desventajas de los métodos de evaluación de usabilidad se muestran en la Tabla 5.4 a

continuación, que corresponde a una recopilación de distintas fuentes bibliográficas relacionadas con el tema [14, 15,

16, 17].

Tabla 5.4: Ventajas y Desventajas de los Métodos de Evaluación de Usabilidad

Método de Evaluación Ventajas Desventajas

Evaluación Heurística

Fácil de conducir.

Rápida y económica.

Permite la identificación de

muchos problemas (mayores y

menores).

Puede ser usado tempranamente

en el período de desarrollo de

software.

No se consume tiempo de los

usuarios.

Se pueden pasar por alto

problemas específicos del

dominio de la aplicación.

Recorrido Cognitivo

Encuentra problemas orientados a tareas.

Ayuda a definir los objetivos e

ideas del usuario.


en el período de desarrollo de

software.

No se requiere de un prototipo

operativo.

Consume tiempo.

Se requiere cierto entrenamiento

para su realización.

Necesita de una metodología de

definición de tareas.

Aplicable sólo para encontrar

problemas de aprendizaje.



Tabla 5.4 (continuación): Ventajas y Desventajas de los Métodos de Evaluación de Usabilidad


Análisis de Acciones

Se realizan estimaciones

precisas de los tiempos

involucrados en las tareas de los

usuarios.

Se genera un profundo

conocimiento del

comportamiento de los usuarios.

Consume mucho tiempo.

Necesita expertos del más alto nivel.

Pruebas en Papel Rápido, efectivo, barato.

No representa de forma completa

y real el diseño y la interacción

con el sistema en cuestión.

Pensando en Voz Alta

Se encuentran muchos problemas de usabilidad.

Se encuentran las razones por

las que ocurren los problemas.

Puede ser usado tempranamente en el período de desarrollo de

software.

Necesidad de pocos usuarios.

El pensamiento en voz alta puede

interferir la conducta normal del

usuario.

No se obtiene información

cuantitativa.

Interacción Constructiva

Se encuentran muchos

problemas de usabilidad.




en el período de desarrollo de software.


La interacción de los usuarios no

representa el uso del sistema en

condiciones normales.

No se obtiene información cuantitativa.

Experimentos Formales

Permite la comparación de

alternativas de diseño.

Recolección de información

cuantitativa.

Se necesita un número

significativo de usuarios.

Puede ser realizado solo en

etapas finales del desarrollo de

software.

No entrega información sobre las

razones de los problemas.



Tabla 5.4 (continuación): Ventajas y Desventajas de los Métodos de Evaluación de Usabilidad


Técnicas de

Interrogación

Entrega información subjetiva

sobre las impresiones del

usuario.

Entrega información cuantitativa y cualitativa.

Simples y económicas.

Fiabilidad de la información

subjetiva.

Ordenamiento de

Tarjetas Simple, económico y rápido.

No considera tareas y

funcionalidad.

El análisis de la tabla permite captar las algunas de las diferencias existentes tanto dentro de los métodos de

inspección como de los métodos de prueba de usabilidad, así como también algunas de sus características comunes.

Para el primer caso, respecto de los métodos de inspección de usabilidad, se puede decir que, en ciertos aspectos, las

evaluaciones heurísticas toman alguna ventaja sobre los otros métodos, principalmente por la facilidad de llevarla a

cabo, lo que no se cumple para el recorrido cognitivo ni para el análisis de acciones, que necesitan de un espacio

temporal más grande para su realización. Además, para el análisis de acciones se necesitan expertos del más alto

nivel, y para el recorrido cognitivo se deben establecer metodologías de definición de tareas y ciertos

entrenamientos, características que aumentan la complejidad de llevarlos a cabo. Sin embargo, las potencialidades de

estos dos últimos métodos de inspección de usabilidad no están en duda, ya que si se dispone del tiempo y de las

características necesarias para llevarlos a cabo, se pueden obtener muy provechosos resultados.

En definitiva, cada uno de los tres métodos de inspección de usabilidad que se han analizado durante la

presente investigación posee características que lo desmarcan de los otros y que lo hacen único dentro de dichas

potencialidades. Las evaluaciones heurísticas permiten obtener la medida de la usabilidad en base a los principios de

usabilidad, es decir, se mide la usabilidad en general (para cualquier tipo de usuario) del sistema en cuestión; el

recorrido cognitivo permite la medición de la usabilidad enfocándose en el aprendizaje, es decir, en usuarios novatos;

finalmente, el análisis de acciones mide la usabilidad en torno a usuarios expertos. Si se dispone de poco tiempo y se

quiere obtener una buena medida de la usabilidad, las evaluaciones heurísticas son las mejores. Si se desea obtener la

usabilidad en torno al aprendizaje, se debe invertir cierta cantidad de tiempo y conocimientos para realizar el

recorrido cognitivo, ya que es el mejor en este sentido. Si se pretende la medida en torno a usuarios expertos,

claramente el análisis de acciones es lo adecuado, con la inversión de tiempos y recursos necesarios.



Ahora bien, respecto de los métodos de prueba de usabilidad, sus ventajas y desventajas son bastante

variadas. Todas las técnicas permiten obtener la información sobre la usabilidad del sistema en evaluación mediante

distintas actividades, con distintos costos de por medio, cantidad de usuarios, etapas de realización dentro del ciclo

de desarrollo de software, etcétera.

Así, es posible establecer ciertas comparaciones entre estos métodos de prueba de la usabilidad. Las pruebas

en papel, por ejemplo, se constituyen, junto con las técnicas de interrogación y el ordenamiento de tarjetas, como los

métodos de prueba más sencillos de realizar. Sus características permiten que, con pocos recursos económicos y con

una preparación que no consume demasiado tiempo, se obtengan resultados satisfactorios respecto de la usabilidad

del sistema que se está evaluando. Esto principalmente porque no se necesitan herramientas sofisticadas para realizar

estas pruebas, sólo basta con un papel y lápiz, y la participación de uno o dos evaluadores que establezcan la

comunicación con los participantes de la prueba. Estas características comunes encuentran su contraparte al analizar

el tipo de resultados que cada uno de estos métodos de prueba de la usabilidad entrega. Las pruebas en papel tienen

como propósito la evaluación formativa, generando una retroalimentación respecto del diseño de la interfaz,

principalmente en las etapas tempranas del desarrollo de software, por lo que sus resultados circundan alrededor de

ello. En cambio, las técnicas de interrogación tienen como principal objetivo la obtención de información subjetiva

del sistema que se está evaluando, rescatando, en muchos casos, información que no fue posible obtener mediante

otro tipo de evaluaciones. Por último, el ordenamiento de tarjetas se enfoca en la arquitectura del diseño de la

información del sistema en evaluación.

Otros métodos de prueba de la usabilidad que poseen ciertas características en común son el pensamiento en

voz alta y la interacción constructiva. Estos dos tipos de evaluación con usuarios se caracterizan porque los

participantes verbalizan sus impresiones durante la interacción con el sistema, permitiendo a los evaluadores rescatar

la información sobre el diseño de la interfaz del sistema, identificando los problemas de usabilidad expresados

directa o indirectamente por los usuarios de las pruebas. El número de problemas de usabilidad que se pueden

rescatar con la realización de estas pruebas es bueno, además de que es posible encontrar las razones de estos

problemas gracias a los comentarios de los evaluadores durante el desarrollo de la prueba. Todo esto, con una

cantidad baja de usuarios. La única desventaja en común que poseen estas evaluaciones es que solo entregan

información cualitativa. Respecto de las diferencias de estas evaluaciones, la técnica del pensamiento en voz alta

incluye un diseño previo de las tareas que el usuario debe realizar, mientras que en la interacción constructiva esto no

es necesario, ya que los dos participantes de la prueba sólo deben descubrir el sistema a la vez que verbalizan sus

impresiones como en una conversación normal. Es por esto que, para el caso de la técnica de pensamiento en voz

alta, se dice que sus características hacen que las verbalizaciones del usuario durante la interacción interfieran el

comportamiento normal de éste, posiblemente ralentizando el proceso o no concentrándose precisamente en la

interacción. No así para la interacción constructiva, que supera esta desventaja, ya que, al ser dos usuarios los que

verbalizan sus impresiones, se logra un buen nivel de realismo, ya que prácticamente se establece una conversación



normal. Sin embargo, el contra de la interacción constructiva respecto de este tipo de conversación, es que, en

general, no son dos usuarios los que trabajan con un sistema, sino que uno.

Por último, los experimentos formales corresponden a uno de los métodos de evaluación de usabilidad más

usados y reconocidos para la medición de este importante atributo. Al ser una técnica que permite captar información

cuantitativa eficientemente, se desmarca, en este sentido, de otros métodos de prueba de la usabilidad, como el

pensamiento en voz alta y la interacción constructiva. Las técnicas de interrogación, por otro lado, entregan

información cualitativa y cuantitativa, pero son los experimentos formales los que entregan de una forma más

completa la información cuantitativa, al ser evaluaciones en que se realizan análisis estadísticos de los problemas y

acontecimientos durante la prueba. Esta es la principal razón del buen prestigio de los experimentos formales, junto

con la buena representación de la realidad, al crear escenarios adecuados, listas de tareas adecuadas y usuarios

representativos. El principal contra de este método, respecto de los otros, es que necesita un número considerable de

usuarios para obtener resultados satisfactorios (entre 16 y 20 usuarios), un factor no menor, ya que en muchos casos

la disponibilidad de usuarios de prueba se torna bastante complicada, considerando además que deben encasillarse

dentro de alguno de los perfiles de usuarios definidos para la prueba.

Las Tablas 5.5 y 5.6, a continuación, corresponden a un resúmenes comparativos de las características más

importantes de los métodos de evaluación de usabilidad basados en [16], primero para el caso de los métodos de

inspección y luego para los de prueba.

Tabla 5.5: Tabla Comparativa de los Métodos de Inspección de Usabilidad

Evaluación Heurística Recorrido Cognitivo Análisis de Acciones

Etapa Todas Todas Diseño

Objetividad Subjetivo Subjetivo Subjetivo

Tipo Cualitativo Cualitativo Cuantitativo

Datos Procesados Procesados Primarios

Intrusivo No No No

Tiempo Bajo Medio Medio/Alto

Equipamiento Bajo Bajo Bajo

Nivel Expertos Medio Alto Medio/Alto

Evaluadores 3-5 3-5 1-2

Usuarios 0 0 0



Tabla 5.6: Tabla Comparativa de los Métodos de Prueba de Usabilidad

Pruebas en

Papel

Pensando

en Voz Alta

Interacción

Constructiva

Experimentos

Formales

Técnicas de

Interrogación

Ordenamiento

de Tarjetas

Etapa Diseño Diseño Diseño Pruebas

Finales

Todas Diseño

Objetividad Subjetiva Subjetiva Subjetiva Objetiva Subjetiva Subjetiva

Tipo Cualitativa Cualitativa Cualitativa Cuantitativa Ambas Ambas

Datos Procesados Procesados Procesados Primarios Primarios Primarios

Intrusivo Sí Sí Sí Sí No No

Tiempo Bajo Medio Medio Alto Bajo Bajo/Medio

Equipamiento Bajo Bajo/Medio Bajo/Medio Medio Bajo Bajo

Nivel Expertos Bajo Bajo/Medio Bajo/Medio Medio/Alto Bajo Bajo

Evaluadores 1-2 1-2 1-2 1-2 1-2 1-2

Usuarios 3-5 3-5 4-10 16-20 >5 >5

Las tablas anteriores permiten establecer ciertas comparaciones puntuales. Dentro de los métodos de

inspección de usabilidad, los factores como el tiempo, equipamiento y nivel de los expertos perfila a la evaluación

heurística como el método más simple de realizar, confirmando las ideas planteadas anteriormente. Sin embargo, las

características del recorrido cognitivo son casi iguales que las de la evaluación heurística, salvo por el factor nivel de

expertos (o evaluadores), donde el recorrido cognitivo necesita mayores niveles (nivel medio para la evaluación

heurística y nivel alto para el recorrido cognitivo). Si se sigue con esta línea, el análisis de acciones vendría siendo el

método de inspección de usabilidad más complejo de realizar, pero hay otros factores que lo benefician respecto de

los otros, como los datos y la cantidad de evaluadores necesarios.

Respecto de los métodos de prueba de la usabilidad, es destacable el distanciamiento de los experimentos

formales respecto de las otras técnicas. El factor de la objetividad, por ejemplo, tiene un carácter objetivo para el

caso de los experimentos formales, y no así para los demás casos, donde se obtiene información subjetiva. Es más,

los experimentos formales corresponden al único de todos los métodos de evaluación de usabilidad de carácter

objetivo. El tiempo, el nivel de expertos y especialmente la cantidad de usuarios, son los factores que marcan este

distanciamiento, ya que la realización de experimentos formales consume una buena cantidad de tiempo, necesita de

expertos capacitados para analizar la información rescatada y la cantidad de usuarios es mucho mayor que con las

otras técnicas.



Un estudio comparativo en que se involucran varios investigadores establece las diferencias existentes entre

los métodos de inspección y los métodos prueba de la usabilidad, precisamente entre la evaluación heurística y los

experimentos formales. El objetivo de este estudio es confirmar una de las ideas ya mencionadas anteriormente en la

presente investigación, en que se dice que es recomendable realizar uno de los métodos de inspección de usabilidad

para luego desarrollar uno de los métodos de prueba.

La primera parte del estudio identifica que existen tres niveles distintos de comportamiento humano en el

contexto de la usabilidad [14]:

Nivel basado en el entrenamiento: Depende de la habilidad de los usuarios para reconocer y

reaccionar rápidamente a las señales presentadas en la interfaz. Algunos elementos no críticos

como animaciones o imágenes pueden captar la atención del usuario en instantes en que debe

concentrarse en las tareas que realmente importan. Esto puede generar errores o una disminución

de la velocidad para realizar las tareas.

Nivel basado en las reglas: Depende de la habilidad de los usuarios para percibir y responder a las

señales asociadas con la tarea en ejecución. Los usuarios tropiezan o se desconcentran cuando

fallan en completar uno o varios pasos en el desarrollo de una tarea, ya que la información del

estado y/o del próximo estado del sistema no ha sido notificada o claramente presentada.

Nivel basado en el conocimiento: Depende de la habilidad de los usuarios para desarrollar un

modelo mental correcto del sistema con que están interactuando. Las acciones de los usuarios

basadas en un modelo mental incorrecto o incompleto pueden causar una acción equivocada, lo que

se constituye en un error.

El estudio consideró un sistema que poseía 39 problemas de usabilidad. La evaluación heurística identificó

un 87% de los problemas, mientras que el experimento formal identificó un 54% de estos. Al categorizar los

problemas de usabilidad encontrados dentro de los niveles mostrados anteriormente, se descubrió que la evaluación

heurística y los experimentos formales identificaron grupos complementarios de problemas. La evaluación heurística

identificó problemas significativos que se cuadran principalmente dentro de los niveles basados en el entrenamiento

y en las reglas. Los experimentos formales, en cambio, identificaron mayor cantidad de problemas correspondientes

al nivel basado en el conocimiento.

Las razones de estos resultados están en que, esencialmente, las evaluaciones heurísticas identifican

problemas relacionados principalmente con el entendimiento de la percepción humana y el pensamiento cognitivo,

ya que explotan estas características al evaluar el sistema desde el punto de vista de un usuario. Así, para la

evaluación heurística es más fácil reconocer problemas de diseño o detalles de presentación que pueden impedir el

progreso de los usuarios al desarrollar cierta tarea.



Los experimentos formales, por otro lado, identifican más fácilmente las diferencias existentes entre el

modelo conceptual del sistema y el modelo mental de los usuarios, en el contexto de cómo el sistema está siendo

usado. El motivo es que los usuarios de la prueba desarrollan las tareas solicitadas siguiendo su modelo mental, lo

que, en muchas ocasiones, genera estas diferencias por el incorrecto modelamiento del sistema, que impide o

dificulta la realización de las tareas de los usuarios.

Finalmente, este estudio concluyó que la técnica más efectiva es realizar ambas técnicas en espacios

temporales distintos dentro del proceso de diseño. Las evaluaciones heurísticas deberían ser aplicadas primero y/o

tempranamente en el proceso de diseño, con el fin de identificar los problemas basados en el entrenamiento o las

reglas. Luego de resolver esos problemas, los experimentos formales pueden ser desarrollados enfocándose

solamente en el nivel basado en el conocimiento, dejando de lado los otros niveles para evitar distracciones.

Estas conclusiones podrían ser generalizadas a cada uno de los grupos de métodos a los cuales pertenecen

las técnicas estudiadas, por la naturaleza de estos. Así, sería recomendable realizar, en un principio, uno de los

métodos de inspección de usabilidad, para luego desarrollar uno de los métodos de prueba. Estas afirmaciones

podrán ser confirmadas posteriormente junto con el desarrollo de esta investigación, realizando cada uno de estos

métodos y analizando sus resultados, en el contexto de las aplicaciones web transaccionales.



6. MÉTODOS DE EVALUACIÓN DE USABILIDAD EN APLICACIONES WEB

TRANSACCIONALES

En este capítulo se procede con la realización de los métodos de evaluaciones de usabilidad sobre

aplicaciones web transaccionales. En un principio se desarrollarán los distintos tipos de evaluaciones, para luego

analizar los resultados de cada uno, terminando con una propuesta de los resultados y conclusiones a base de los

métodos y casos de estudio escogidos.

Los métodos de evaluación de usabilidad escogidos para desarrollar sobre los casos de estudio y

posteriormente evaluar los parámetros asociados a su realización involucran, por el lado de los métodos de

inspección, sólo a las evaluaciones heurísticas, mientras que se considerarán todos los métodos de prueba analizados

en las secciones anteriores. Así, la evaluación heurística, considerada la evaluación de inspección más eficiente y la

más utilizada, podrá ser la base de comparación para el análisis de los métodos de prueba.

Los casos de estudio para esta investigación se enmarcan dentro de las aplicaciones web transaccionales.

Así, se dispone de distintas aplicaciones, que cubren distintos mercados y con distintos objetivos.

El primer grupo de casos de estudio disponibles corresponden a prototipos web de distintas organizaciones.

Entre estos se encuentran sistemas web de entidades bancarias, en donde se pueden realizar consultas sobre cuentas

corrientes, solicitud de tarjetas, etcétera; un sistema web de una caja de compensación, en el cual se pueden realizar

principalmente consultas sobre los beneficios y servicios para los clientes; un sistema de una corporación estatal de

apoyo a empresas, en donde es posible realizar consultas sobre los apoyos disponibles, postulación a beneficios,

entre otras cosas; y finalmente, un prototipo de un sistema web transaccional de una cadena de supermercados, en el

cual se realizan acciones relacionadas principalmente con la obtención vía web de la tarjeta de esta cadena, además

de poder realizar transacciones con esta tarjeta, como la compra de algunos artículos, pago de servicios como luz,

agua o gas, solicitar créditos, y contratar seguros y/o asistencias.

Otros de los casos de estudio disponibles corresponden al Navegador Académico de la PUCV (versión 1.0)

y al Sistema de Biblioteca de la misma (versión 1.0). El primero corresponde a un sistema web académico, de acceso

a alumnos, profesores y jefes de docencia, entre otros, en el cual se pueden realizar inscripciones de asignaturas,

solicitudes de certificados, obtener información de tesorería y consultar historiales académicos, entre muchas otras

cosas. El segundo, posee información sobre libros, revistas y documentos de acceso principalmente a alumnos y

profesores, además de servicios de reserva de distintos espacios académicos de la universidad, entre otras

funcionalidades.

Finalmente, el último caso de estudio que se dispone corresponde a un sistema de gestión de contenidos

web, que permite desarrollar distintas funciones, como la creación de distintas páginas, administración de los

contenidos de éstas, diseño de las páginas, etcétera.



Para esta parte de la investigación, se escogerán dos de todas las aplicaciones web disponibles. La elección

de éstas es sumamente importante, ya que las dos aplicaciones escogidas serán la base del camino para lograr la

concreción de los objetivos; en otras palabras, los sistemas a elegir se transformarán en las fuentes representativas de

las aplicaciones web transaccionales, por lo que la inclinación hacia un sistema más representativo en desmedro de

los menos será, de cierta forma, la clave para encontrar la metodología de evaluaciones de usabilidad que permita

obtener la medida de la usabilidad de buena forma en el contexto de las aplicaciones web transaccionales. Más

adelante se deberá escoger un tercer caso de estudio para la validación de la metodología propuesta. Las aplicaciones

web transaccionales escogidas como casos de estudio para esta etapa son:

Caso de Estudio 1: Prototipo de Sistema Web de Cadena de Supermercados.

Caso de Estudio 2: Navegador Académico PUCV.

Se ha escogido el prototipo del sistema web de la cadena de supermercados, porque dispone de mayores

funcionalidades y un mayor nivel de navegabilidad en el sitio respecto de los otros prototipos disponibles. Por lo

mismo, es posible realizar mayor cantidad de transacciones representativas, por lo que las evaluaciones permiten

enfocarse en esta característica importante y distintiva de las aplicaciones web en estudio.

Respecto del navegador académico de la PUCV, su importancia y relevancia tanto para los estudiantes y

profesores como para los usuarios administrativos de la universidad, amerita un estudio de la usabilidad, abriendo la

posibilidad de sustanciales mejoras al sistema que vayan en beneficio directo de sus usuarios. Así, se generará una

cooperación mutua: los encargados del sistema obtendrán la medida de la usabilidad de su producto, y esta

investigación contará con este importante sistema web como base para obtener resultados respecto de los métodos de

evaluación de usabilidad.

Estos sistemas web escogidos serán la base de estudio para la postulación de las metodologías de evaluación

de aplicaciones web transaccionales. Los métodos de evaluación escogidos para su análisis serán realizados sobre

estos sistemas, primeramente con el prototipo de sistema web de la cadena de supermercados y, en una segunda

etapa, sobre el navegador académico de la PUCV.

Los resultados que se obtendrán, luego de realizar los métodos de evaluación de usabilidad sobre estos casos

de estudio, permitirán obtener algunas conclusiones que, claramente, serán entregadas acorde a la evaluación con los

dos casos de estudio, esperando que estos resultados sean una generalización de lo que pasa con cualquier aplicación

web transaccional. Por lo mismo, la metodología de evaluación propuesta deberá ser validada, exponiéndola a una

posible confirmación o un posible rechazo, mediante otro caso de estudio que se escogerá en su debido momento.



Para cada uno de los casos de estudio se realizarán las siguientes evaluaciones:

Método de Inspección:

o Evaluación Heurística.

Métodos de Prueba:

o Pruebas en Papel.

o Pensando en Voz Alta.

o Interacción Constructiva.

o Experimentos Formales.

o Técnicas de Interrogación.

o Ordenamiento de Tarjetas.

Es importante destacar que el análisis de los métodos de evaluación incluye la preparación, desarrollo y

análisis mismo de los resultados que entrega el proceso, incluyendo la cantidad y tipo de errores que se pueden

identificar con cada uno, por lo que la investigación no pretende ir más allá de esto, es decir, no se postulan mejoras

sobre el sistema, ya que esto sobrepasa los límites de los objetivos de la investigación. La investigación se enfoca en

los resultados obtenidos con cada método respecto de los problemas de usabilidad del sistema, y las características

asociadas a cada uno, que lo harán más adecuado que otro para ciertos casos.



6.1. Caso de Estudio: Prototipo Web Cadena de Supermercados

El caso de estudio 1, tal como se estableció anteriormente, corresponde a un prototipo de un sistema web

transaccional de una cadena de supermercados, en el cual se realizan acciones relacionadas principalmente con la

obtención vía web de la tarjeta de esta cadena, además de poder realizar transacciones con esta tarjeta, como la

compra de algunos artículos, pago de servicios como luz, agua, gas, etcétera, solicitar créditos, y contratar seguros

y/o asistencias. Se recalca la característica de prototipo, por lo que corresponde a un sistema no terminado

completamente, por lo que algunas de sus funciones no están disponibles.

Las figuras 6.1 y 6.2, a continuación, corresponden a capturas de la página inicial del prototipo de sistema

web de la cadena de supermercados y de la pestaña relacionada con los créditos que ofrece la organización,

respectivamente.

Figura 6.1: Página Inicial del Prototipo de Sistema Web de la Cadena de Supermercados



Figura 6.2: Sección Crédito del Prototipo de Sistema Web de la Cadena de Supermercados

Las capturas dejan evidenciada claramente la característica de prototipo de este caso de estudio, lo cual, para

esta investigación, se torna como una ventaja, ya que servirá como base comparativa para estudiar las características

de los métodos de evaluación de usabilidad en etapas distintas del proceso de desarrollo de software.

6.1.1. Evaluaciones Realizadas

A continuación se muestra el detalle de cada uno de los métodos realizados sobre el caso de estudio 1,

pasando por la preparación de las evaluaciones, los evaluadores involucrados, los perfiles de usuarios representativos

cuando corresponda, etcétera. Además, se desarrollan los análisis de las evaluaciones, mostrando los errores

encontrados en cada una.



6.1.1.1. Evaluación Heurística

La evaluación heurística, único de los métodos de inspección de usabilidad realizados hasta el momento, fue

realizada por cuatro evaluadores con experiencia media en usabilidad. Los coordinadores de la prueba fueron otros

dos evaluadores distintos, que no participaron de la evaluación heurística ya que conocían el sistema, lo que podría

haber influenciado en su inspección.

El perfil de los evaluadores, las heurísticas utilizadas, los errores encontrados y el análisis de estos se

muestra a continuación.

6.1.1.1.1. Perfil de los Evaluadores

Este método de inspección de usabilidad se realizó gracias a la colaboración de cuatro evaluadores que

cumplen con el siguiente perfil:

Alumnos del programa de Magíster en Ingeniería Informática de la Escuela de Ingeniería

Informática de la Pontificia Universidad Católica de Valparaíso (PUCV).

Investigadores de distintos tópicos relacionados con la usabilidad.

Experiencia media en evaluaciones heurísticas.

6.1.1.1.2. Heurísticas

Las heurísticas a utilizar para el desarrollo de esta evaluación corresponden a los diez principios básicos de

usabilidad propuestos por Nielsen, los cuales se detallaron en el subcapítulo 4.4 de la presente investigación. Estos

principios deben aplicarse al caso de estudio, perteneciente a las aplicaciones web transaccionales, por lo que a

continuación se muestran los principios de usabilidad aplicados a este tipo de aplicaciones, en la Tabla 6.1 (para más

información véase el Anexo 1, correspondiente al documento presentado a los evaluadores):

Tabla 6.1: Principios de Usabilidad en Aplicaciones Web Transaccionales

Principio Descripción

Visibilidad del Estado

Sistema.

El sistema transaccional, debería mantener siempre informados a los

usuarios sobre qué está haciendo, a través de una retroalimentación

apropiada y en un tiempo razonable.



Tabla 6.1 (continuación): Principios de Usabilidad en Aplicaciones Web Transaccionales


Conexión entre el

Sistema y el Mundo

Real.

El sistema transaccional debería hablar el lenguaje del usuario, esto es, usar

palabras, frases y conceptos que le fueran familiares, siguiendo los

convenios del mundo real y haciendo que la información aparezca en un

orden lógico y natural.

Control y Libertad del

Usuario.

Puesto que muchas veces los usuarios se equivocan y eligen alguna función

del sistema por error, es necesario que haya siempre una “salida de

emergencia” para salir de esa opción lo más cómodamente posible y, en

general, proporcionar mecanismos que permitan deshacer los cambios

producidos por una acción no deseada, así como repetir acciones ejecutadas

con anterioridad. Rehacer, Deshacer.

Consistencia y

Estándares.

Los sistemas transaccionales deben evitar el empleo de distintas palabras,

situaciones o acciones para el mismo elemento. Hay que seguir, además, en

cada caso, los convenios existentes.

Prevención de Errores.

Es mucho mejor disponer de un diseño cuidadoso que prevenga que se

produzcan errores, a que se diseñe para que se envíe buenos mensajes de

error.

Reconocer Mejor que

Recordar.

Los sistemas transaccionales deben hacer que los objetos, acciones, y

opciones sean visibles para el usuario, el que no debe tener que recordar la

información de una parte del diálogo a otra.

Flexibilidad y Eficiencia

de Uso.

El sistema transaccional podría proporcionar una serie de atajos para los

usuarios expertos, sin que éstos sean perceptibles para los principiantes,

adaptándose así a ambos tipos de usuarios. También debería permitir

personalizar aquellas acciones más frecuentes que llevan a cabo los

usuarios.

Diseño Estético y

Minimalista.

Se debe evitar mostrar información irrelevante o que rara vez es necesaria.

Cada unidad extra de información que incluyamos en una pantalla o interfaz

del sitio transaccional va a competir con el resto y disminuir así, la

visibilidad relativa de otra información más importante.



Tabla 6.1 (continuación): Principios de Usabilidad en Aplicaciones Web Transaccionales


Ayuda al Usuario a

Reconocer, Diagnosticar

y Recuperarse de

Errores.

Los mensajes de error presentes en los sistemas transaccionales deben ser

expresados en lenguaje natural (nada de códigos de error), indicando el

problema de forma precisa y sugiriendo una solución constructiva.

Ayuda y

Documentación.

Los sistemas transaccionales deben proporcionar ayuda y documentación. Si

dispone de ésta documentación esta debe ser fácil de buscar, estar centrada

en la tarea del usuario, enumerar los pasos concretos que se deben realizar, y

no ser demasiado extensa.

6.1.1.1.3. Problemas Identificados

La evaluación heurística arrojó un total de 29 problemas encontrados por los evaluadores. Estos fueron

categorizados según el principio de usabilidad que cada uno contradice. La Tabla 6.2, a continuación, muestra la

cantidad de problemas encontrados organizados por principios.

Tabla 6.2: Problemas de Usabilidad Evaluación Heurística por Principio

Principio de Usabilidad Cantidad de Problemas

Visibilidad del Estado del Sistema 3

Conexión entre el Sistema y el Mundo Real 1

Control y Libertad del Usuario 2

Consistencia y Estándares 8

Prevención de Errores 1

Reconocer Mejor que Recordar 1

Flexibilidad y Eficiencia de Uso 1

Diseño Estético y Minimalista 8

Ayuda al Usuario a Reconocer, Diagnosticar y Recuperarse de Errores 1

Ayuda y Documentación 3



El análisis de la tabla permite obtener algunas conclusiones iniciales. Se destaca la supremacía en cuanto a

cantidad de errores de los principios “Consistencia y Estándares” y “Diseño Estético y Minimalista” respecto de los

otros principios de usabilidad en que no se encontraron cantidades elevadas de problemas. Otra consideración

interesante es que todos los principios poseen por lo menos un problema. Un análisis más detallado de esto y otros

aspectos relacionados con los problemas encontrados con esta evaluación heurística será desarrollado más adelante.

La Tabla 6.3 muestra la lista de todos los problemas encontrados, agrupados por principios de usabilidad.

En ella es posible visualizar los promedios de las calificaciones asignadas por los cuatro evaluadores, tanto de

Severidad y Frecuencia, como de Criticidad.

Se muestra la lista completa de los problemas debido a que no es una cantidad muy grande como en otros

casos de evaluaciones heurísticas, por lo que es posible visualizar todos los problemas simplemente. Además,

posteriormente se realizarán comparaciones de los problemas encontrados en cada una de las evaluaciones, por lo

que se hace necesario conocer cada uno de estos problemas, o sus principales alineamientos. La tabla completa con

las calificaciones de cada uno de los evaluadores está disponible en el Anexo 3.

Tabla 6.3: Problemas Encontrados con la Evaluación Heurística

Principio de

Usabilidad Nro Problema Severidad Frecuencia Criticidad

Visibilidad y Estado

del Sistema

1

No se indica claramente al usuario el

lugar que se encuentra al navegar el sitio,

indicando la ruta de acceso desde el home.

2,75 3,00 5,75

2

Al querer obtener una tarjeta Presto, al ir

avanzando en el formulario, se pierde el

título, el usuario se puede perder.

2,75 2,00 4,75

3 Bloque de mensajes, no especifica

cuántos caracteres se pueden ingresar. 2,25 2,00 4,25

Conexión entre el

Sistema y el Mundo

Real

4

No habla el lenguaje del usuario, al utilizar la frase “Ingreso a sesión

personal”, la palabra sesión puede no ser

entendida por los usuarios que ingresan

al sitio.

2,50 2,75 5,25

Control y Libertad

del Usuario

5 No permite utilizar el scroll del mouse. 3,25 3,50 6,75

6

No presenta funciones para volver a un

estado anterior de la navegación, incluso ni siquiera se pueden utilizar los botones

estándar del navegador, ya que al

utilizarlos se regresa a la página principal

de la aplicación y no a la anterior, por lo

que el usuario tiene que recordar todo el

camino recorrido para volver a donde

estaba.

3,75 3,50 7,25



Tabla 6.3 (continuación): Problemas Encontrados con la Evaluación Heurística

Principio de


Consistencia y

Estándares

7

Uso de metáforas casi nulo, que eviten

que el usuario tenga que leer lo que

hacen las opciones o vínculos presentes

en el sistema (Imprimir, Guardar).

2,75 3,25 6,00

8

En el formulario "Obtener tarjeta Presto"

no es consistente la utilización de las

ayudas para los campos del formulario,

se utiliza el mismo formato y color de

fuente para expresar que un campo es

requerido y que otro es opcional.

2,75 3,00 5,75

9 No se entiende la funcionalidad de

algunos símbolos o metáforas utilizadas. 2,75 2,50 5,25

10

En la sección de “Obtener Tarjeta

Presto”, pierde la consistencia en el

diseño ya que desaparece la sección

izquierda presente en las demás opciones

de la aplicación.

2,75 3,00 5,75

11

Inconsistencia en la presentación de las

opciones del menú principal, en la

página Home aparecen en un recuadro a

la derecha como vínculos y agrupadas

como “Servicios Financieros” y en las

demás opciones se presenta como un menú en la parte superior.

2,50 3,00 5,50

12

La presentación de enlaces no es consistente, algunos aparecen con letra

cursiva, otros en negrilla y no se entiende

por qué se hace esa distinción.

2,75 2,75 5,50

13

La opción “Ejemplo de estado de cuenta

” muestra una ventana emergente en la

cual las opciones sobre ella no se

presentan con el mismo estilo,

“Imprimir” y “Guardar” son enlaces

mientras que “Cerrar ventana” es un

botón que no ejecuta la función esperada.

2,50 3,00 5,50

14

Al ir a "Obtener tarjeta Presto", el

mensaje que dice "2 minutos" puede ser

un buen gancho, pero otras transacciones

no tienen esa métrica.

2,75 3,00 5,75

Prevención de

Errores 15

En el formulario de “Datos de Usuario”

en la sección de “Obtener Crédito”, el

vínculo “Recordar” es ambiguo, no se sabe si se refiere a recordar los datos

ingresados en el computador o si es una

opción para recuperar la clave en caso de

haberla olvidado.

2,75 2,25 5,00

Reconocer Mejor que

Recordar 16

No se marcan los enlaces que ya han sido

visitados lo que desorienta al usuario. 3,50 3,25 6,75




Principio de


Flexibilidad y

Eficiencia de Uso 17

No queda claro que existan diferentes

formas de acceder a las funcionalidades

y contenidos proporcionados por el sitio

para usuarios novatos o expertos.

2,75 3,00 5,75

Diseño Estético y

Minimalista

18

No se distingue claramente cuales son

áreas transaccionales y cuales son zonas

de acceso libre.

2,75 3,25 6,00

19 Hay demasiada información en cada

página que confunden al usuario. 3,25 3,25 6,50

20

La navegación a través del sitio es muy

compleja, hay múltiples enlaces lo que lo

hace muy confuso.

3,25 3,00 6,25

21

No se diferencia lo importante de lo

superfluo, prácticamente todo tiene el

mismo tamaño.

3,25 2,75 6,00

22

Utilización de colores poco llamativos,

combinación muy simple que no expresa

diferencias entre las diferentes opciones

de la aplicación, que por lo menos

ayuden al usuario a ubicarse dentro de la

aplicación.

2,75 3,50 6,25

23

La forma de presentar el ítem "¿Qué más

puedo hacer?" No es intuitiva para

usuarios con poca práctica.

3,00 2,50 5,50

24

A pesar de ser un sitio promocional y

que desea llamar la atención, la

redundancia de opciones en el pie de la

página (que seguramente serán flash) y el

menú izquierdo, dificultan la

concentración para buscar lo que se

desea hacer.

2,50 3,25 5,75

25

Bloque de beneficios debiera ir primero,

ya que es esa la información que el

usuario irá a buscar en ese ítem.

2,75 1,75 4,50

Ayuda al Usuario a

Reconocer,

Diagnosticar y

Recuperarse de

Errores

26

No queda claro si el usuario puede

recuperarse de errores o cancelar una

operación o rehacerla por ejemplo al

solicitar una tarjeta de la cadena de

supermercados.

3,25 2,00 5,25




Principio de


Ayuda y

Documentación

27 No está claro en la portada del sitio para

un usuario común cual es su propósito. 3,25 2,25 5,50

28

No existe ayuda en línea o ayuda

contextual que describan lo que se puede

hacer en cada opción de los menús

presentes. Tampoco existen "demos" que permitan mostrar al usuario la forma en

que debe realizar una determinada

transacción.

3,00 2,75 5,75

29

Mensajes de ayuda (al confirmar la

solicitud de Tarjeta Presto) y sugerencias

al usuario demasiado largos (sección

amarilla) y otros largos y con tamaño de

fuente demasiado pequeña (fuente

verde), que implica mayor esfuerzo para

que el usuario los lea, por lo que puede

pasarlos por alto y cometer errores.

2,75 2,50 5,25

Por último, y con el objetivo de visualizar los problemas más críticos, según los evaluadores, se muestra una

lista con los problemas con mayores niveles de criticidad promedio.

Tabla 6.4: Ranking con los Problemas con Mayor Criticidad

Nro Problema Criticidad

6 No presenta funciones para volver a un estado anterior de la navegación, incluso ni siquiera se

pueden utilizar los botones estándar del navegador, ya que al utilizarlos se regresa a la página

principal de la aplicación y no a la anterior, por lo que el usuario tiene que recordar todo el

camino recorrido para volver a donde estaba.

7,25

5 No permite utilizar el scroll del mouse. 6,75

16 No se marcan los enlaces que ya han sido visitados lo que desorienta al usuario. 6,75

19 Hay demasiada información en cada página que confunden al usuario. 6,50

20 La navegación a través del sitio es muy compleja, hay múltiples enlaces lo que lo hace muy

confuso. 6,25

22 Utilización de colores poco llamativos, combinación muy simple que no expresa diferencias

entre las diferentes opciones de la aplicación, que por lo menos ayuden al usuario a ubicarse

dentro de la aplicación.

6,25

7 Uso de metáforas casi nulo, que eviten que el usuario tenga que leer lo que hacen las opciones

o vínculos presentes en el sistema (Imprimir, Guardar). 6,00

18 No se distingue claramente cuales son áreas transaccionales y cuales son zonas de acceso

libre. 6,00

21 No se diferencia lo importante de lo superfluo, prácticamente todo tiene el mismo tamaño. 6,00



6.1.1.1.4. Conclusiones de la Evaluación

En general, el nivel de criticidad de los problemas no es muy alto. La mayoría de los problemas fueron

calificados, en promedio, con notas inferiores a seis. Sólo nueve de los veintinueve errores encontrados fueron

calificados con notas mayores a seis.

Un asunto interesante es que los problemas evaluados con mayor criticidad no pertenecen a los principios de

usabilidad con mayor cantidad de problemas. Los tres primeros problemas en el ranking contradicen a los principios

“Control y Libertad del Usuario” y “Reconocer Mejor que Recordar”, mientras que los principios con más problemas

clasificados corresponden a “Diseño Estético y Minimalista” y “Consistencia y Estándares”.

Desde otra perspectiva, relacionado con la característica del sistema en evaluación de ser un prototipo, es

posible obtener algunas conclusiones distintas. Podría postularse que los tres primeros problemas del ranking según

criticidad, entre otros problemas de la lista, se asocian al nivel de construcción del sistema, es decir, a ser

precisamente un prototipo. Claramente se destaca el reconocimiento de estos problemas gracias a la prueba, lo cual

no está en juicio, pero si consideramos una nueva iteración en el desarrollo del sistema no sería sorpresivo que estos

problemas estén solucionados. Sin embargo, los problemas número 19 y 20 (cuarto y quinto lugar del ranking por

criticidad, respectivamente), que contradicen el principio de “Diseño Estético y Minimalista”, están relacionados con

la estructura y características del sitio, por lo que probablemente no serían solucionados en una nueva iteración si no

hubiesen sido descubiertos por un método de evaluación de la usabilidad como éste.



6.1.1.2. Pruebas en Papel

Este método de prueba de la usabilidad fue realizado en distintas ubicaciones de la Escuela de Ingeniería

Informática de la PUCV. Una de ellas es, por supuesto, el laboratorio de usabilidad. Por la naturaleza de la

evaluación, algunas fueron realizadas en lugares un poco más informales, como salas de estudio y salas de clases. Se

desarrollaron siete pruebas en papel, con los usuarios adecuados a los perfiles que se presentan más adelante, y que

permitieron obtener los resultados para los posteriores análisis.

6.1.1.2.1. Perfiles de Usuario

Para el caso de estudio del prototipo del sistema web de la cadena de supermercados se consideró sólo un

tipo de perfil de usuario. Este corresponde a usuarios novatos en el uso del sistema, es decir, usuarios representativos

que no habían tenido experiencia previa en el uso del sistema. Estos usuarios representativos corresponden

principalmente a alumnos de la carrera de Ingeniería Civil en Informática de la Escuela de Ingeniería Informática de

la PUCV, por lo que poseen un grado aceptable de experiencia de uso de aplicaciones web, entre otros tipos de

sistemas software interactivos. Algunos otros usuarios son estudiantes de otras carreras de la PUCV que igualmente

se encajan dentro de este perfil, ya que poseen un nivel de experiencia en aplicaciones web considerable y no tienen

experiencia previa en el uso del prototipo de sistema web de la cadena de supermercados.

6.1.1.2.2. Diseño de la Prueba

La preparación de la prueba comenzó con el análisis del prototipo de sistema web de la cadena de

supermercados. Se recorrieron cada una de las páginas para identificar las que se ocupaban de manera más común,

además de identificar los patrones de diseño implementados en la aplicación, para así poder realizar la traducción en

papel.

Así, las preguntas realizadas a los participantes se enfocarán en páginas representativas del sistema en

general, es decir, de la forma en que la aplicación web diseña sus páginas comúnmente. Estas preguntas que forman

parte de la entrevista que se realiza al usuario buscaron, de cierta forma, poder confirmar o desechar alguno de los

problemas identificados en la evaluación heurística, principalmente el relacionado con la gran cantidad de

información en pantalla que obstaculiza la interacción del usuario con el sistema. Otro de los problemas críticos era

el nivel de la navegabilidad en el sistema, el cual claramente no puede ser evaluado con este tipo de evaluación.

Las figuras mostradas a continuación, representan dos de los prototipos en papel que se mostraron a los

usuarios representativos.



Figura 6.3: Prototipo en Papel Página Inicial de Prototipo Web Cadena Supermercados

La Figura 6.3 corresponde a la página inicial de la aplicación web en evaluación, donde se diferencian

claramente cuatro secciones: la primera relacionada con el ingreso a la sesión personal, otra sección de servicios

financieros (agrupa las categorías principales de la aplicación), de oportunidades al pagar con la tarjeta de la cadena

de supermercados y de los beneficios que podrían obtener al hacerse cliente.

La Figura 6.4, a continuación, corresponde a la página principal de la categoría de Crédito. Es perceptible la

utilización de pestañas para diferenciar las categorías y hacer notar en cuál se está trabajando, así como también la

división de la página en secciones principalmente relacionadas con el crédito (la aplicación mantiene en la gran

mayoría de las páginas una sección con los potenciales beneficios alcanzables al hacerse cliente).



Figura 6.4: Prototipo en Papel Sección Crédito de Prototipo Web Cadena Supermercados


El desarrollo de este tipo de método de prueba de la usabilidad permitió obtener, como era de esperar,

información sobre la usabilidad en cuanto al diseño de la interfaz de la aplicación web transaccional. Mediante la

muestra de los prototipos en papel a los siete usuarios representativos y el intercambio de preguntas/respuestas con el

evaluador se obtuvieron variadas conclusiones que principalmente son positivas.

Luego de haber instruido a estos usuarios sobre el contexto de la aplicación web en evaluación

correspondiente a la cadena de supermercados y sobre la prueba en sí, se prosiguió con las consultas, que se

desarrollaron de una manera ciertamente informal, pero rescatando la información necesaria.



Los usuarios, al ser consultados por su primera percepción de la página inicial, respondieron, en general,

que la estructura se veía adecuada para el negocio de la aplicación, destacando las claras diferencias existentes entre

las distintas secciones (inicio de sesión, oportunidades, etcétera). Así, en un principio no se captaron mayores

problemas.

Al ir poco a poco exhibiendo las distintas hojas con los prototipos fueron surgiendo algunas dudas. La más

común dice relación con la estructura de las pestañas. Los usuarios captaron que las pestañas no seguían de manera

consistente con lo que se había mostrado en la página inicial, la cual mostraba cinco categorías principales en la

sección de servicios financieros, sin embargo, en las páginas interiores mostraban siete pestañas, es decir, dos más

que las categorías anteriormente reconocidas. Así, algunos rechazaron esta disposición de las pestañas, pero otros la

consideraron apropiada.

Asimismo, la primera pestaña a la izquierda que puede ser captada lleva el nombre “Home”. La mayoría de

los usuarios rechazó esta pestaña, ya que la vuelta a la página inicial no forma parte de la estructura general de la

página, sólo hay que considerarla como realmente es: una página inicial. Así, proponían volver a la página inicial

mediante el logo de la marca y/o mediante la creación, en algún lugar de las páginas, de un enlace que represente

claramente la vuelta a esta página inicial.

Fuera de estas consideraciones, los usuarios representativos consideraron que la aplicación se notaba

consistente y simple. Por otro lado, la impresión de estos usuarios es que la cercanía de los prototipos en papel con la

realidad del sistema implementado no es mucha, es decir, consideraron que, estos prototipos se veían bien a groso

modo, pero esto puede variar bastante dependiendo de la forma en que se rellenan cada una de las secciones. En otras

palabras, las páginas se ven bien, pero si se sobrecarga de información a cada una de las secciones, o si estas mismas

no son consistentes, todo lo bueno que se percibe se perdería.

Los comentarios anteriores son justificados, y tomarán consideración más adelante cuando se desarrollen los

análisis pertinentes.



6.1.1.3. Pensamiento en Voz Alta

La evaluación fue realizada en el laboratorio de usabilidad de la Escuela de Ingeniería Informática de la

PUCV, con la participación de cuatro usuarios representativos. Luego de la firma del acuerdo de confidencialidad

(véase Anexo 2), se procedió a realizar las evaluaciones, en donde cada uno de los usuarios debía basarse en algunas

guías por parte del evaluador para realizar sus acciones sobre el sistema, al mismo tiempo que expresaban sus

impresiones en voz alta. Se almacenaron los archivos que capturaban los movimientos en pantalla y el audio

asociado durante la ejecución de la prueba. El pensamiento en voz alta, al ser una prueba que no necesita de un

listado de tareas específico, no amerita un diseño formal de tareas, por lo que no se incluye esa sección.


Los usuarios participantes de este método de prueba de la usabilidad pertenecen al perfil de usuario novato,

es decir, que no poseen experiencia previa en el uso de sistema. Estos usuarios corresponden a alumnos de la carrera

Ingeniería Civil Informática de la Escuela de Ingeniería Informática de la PUCV, por lo que poseen cierta

experiencia en el uso de aplicaciones web.


La realización de este método de evaluación de usabilidad sobre el prototipo de sistema de la cadena de

supermercado ha permitido, de forma general, confirmar los problemas más críticos que había entregado la

evaluación heurística realizada anteriormente.

Uno de los problemas principales que se obtuvieron con la realización de este método de prueba, dice

relación con la información de los beneficios obtenibles con la tarjeta de la cadena de supermercados. Algunos de

estos beneficios se muestran en la página inicial, mientras que, supuestamente, la mejor oferta asociada a la

utilización de la tarjeta de la cadena de supermercados se encuentra dentro de subsecciones que no son ciertamente

fáciles de acceder. ¿Es consecuente que el beneficio destacado sea visible después de navegar por muchas páginas,

siendo que otros beneficios comunes se encuentran en la página inicial? Probablemente no. La página que contiene la

información del beneficio destacado se muestra en la Figura 6.5, a continuación.



Figura 6.5: Página con Información Beneficios de Prototipo Web Cadena Supermercados

Respecto de la característica de este método de prueba, en que el usuario debe expresar en voz alta sus

impresiones mientras realiza la interacción, se evidenció claramente que esto influye en su capacidad para realizar las

tareas. El usuario trabaja de forma más lenta y un poco menos concentrada en la tarea que realiza, por lo que un

análisis estadístico de los tiempos involucrados en la realización de cada una de las tareas no sería representativo.

Además, fue posible confirmar la dificultad de los usuarios para expresar sus impresiones, principalmente

por timidez, inseguridad o temor a equivocarse, por lo que la creación de la interacción constructiva como respuesta

a este problema podría considerarse, hasta el momento, asertiva.

Como se nombró anteriormente, la prueba buscaba evaluar los problemas más críticos que se identificaron

en la evaluación heurística. Estos son la gran cantidad de información en pantalla, que confunde al usuario, y la

deficiencia en la navegabilidad dentro del sitio, los cuales pudieron ser completamente confirmados luego de realizar

esta prueba, junto con algunos otros problemas, como el de los beneficios, analizado recientemente. La Tabla 6.5, a

continuación, muestra los problemas de usabilidad identificados con este método de prueba.



Tabla 6.5: Problemas Identificados con el Pensamiento en Voz Alta

Número Problema

1 No hay ayuda para el formato de ingreso del RUT.

2 Navegabilidad muy compleja. Se debe hacer mucho para cumplir

un objetivo.

3 Sobrecarga de información en las páginas.

4 No se indica claramente dónde se encuentra el usuario. El usuario

se pierde y confunde.

5 Uso de colores poco llamativo.

6 No existen opciones para volver a estados anteriores.

7 No se puede usar el scroll del mouse.

8 Páginas muy planas. No hay diferencias marcadas.

9 Inconsistencia en presentación de beneficios.

En general, se puede decir que hubo cierta equivalencia entre la cantidad de problemas de usabilidad

encontrados mediante la expresión de las impresiones y mediante el análisis propio de la interacción en pantalla. Así,

es destacable la característica principal de esta prueba: el pensamiento en voz alta. Sin embargo, la efectividad

depende en alto grado de la personalidad de cada uno de los usuarios representativos, ya que, generalmente, se

sienten con temor al momento de expresar sus impresiones, por lo que podrían identificarse muchos más problemas

si los usuarios realmente pensaran en voz alta.



6.1.1.4. Interacción Constructiva

Este método de prueba de usabilidad fue realizado en el laboratorio de usabilidad de la Escuela de

Ingeniería Informática de la PUCV, gracias a la participación de cuatro usuarios representativos que se adecuan al

perfil de usuario definido, por lo que, debido a la naturaleza de la prueba, se realizaron dos interacciones

constructivas. Previa firma del acuerdo de confidencialidad (véase Anexo 2), se grabó el audio y los sucesos

ocurridos en pantalla durante el desarrollo de la prueba, con el fin de analizar posteriormente las conversaciones de

los usuarios a la vez que interactuaban con el sistema.

Esta técnica no restringe a los usuarios a realizar una serie de tareas, sino que da la libertad de que estos

descubran el sistema en conjunto, por lo que no necesita de un diseño de tareas, lo que la hace ciertamente más

simple en este sentido. Así, los perfiles de usuario considerados para esta evaluación y el análisis de la información

obtenida se presentan a continuación.


Se consideró sólo un tipo de perfil de usuario para la realización de esta prueba sobre el caso de estudio del

prototipo del sistema web de la cadena de supermercados. El perfil corresponde a usuarios novatos en el uso del

sistema, es decir, usuarios representativos que no habían tenido experiencia previa en el uso del sistema. Estos

usuarios representativos corresponden a alumnos de la carrera de Ingeniería Civil en Informática de la Escuela de

Ingeniería Informática de la PUCV, por lo que poseen un grado aceptable de experiencia de uso de aplicaciones web,

entre otros tipos de sistemas software interactivos.


El desarrollo de este método de evaluación de usabilidad ha permitido identificar una buna cantidad de

errores, respondiendo a las características que lo describían en la bibliografía consultada.

Las dos interacciones constructivas entregaron tanto información común (problemas que en las dos se

pudieron identificar), como problemas que cada una entregó por sí sola. La primera interacción duró

aproximadamente 37 minutos, mientras que la segunda tuvo un período de tiempo de 21 minutos aproximadamente.

La lista de los problemas identificados con estas pruebas con usuarios se muestra a continuación en la Tabla

6.6, la cual integra los resultados de las dos interacciones constructivas.



Tabla 6.6: Problemas Identificados con la Interacción Constructiva

Número Problema

1 No hay ayuda para el formato de ingreso del RUT.

2 Inconsistencia en el formato de ingreso de los números telefónicos.

3 Muchos pasos y relleno de información para cumplir un objetivo,

por ejemplo para obtener la tarjeta de la cadena de supermercados.

4 Mucha información en cada página.

5 Inconsistencia en la presentación de menús.

6 No se indica claramente dónde se encuentra el usuario. El usuario

se pierde y confunde.

7 Mucho texto en cada página. Pocas metáforas.

8 Uso de colores poco llamativo.

9 No se dispone de la función volver a estados anteriores. Ni siquiera

los botones estándar del browser lo permiten.

10 Inconsistencia en la presentación de detalles. Algunos se muestran

en ventajas emergentes y otros en una nueva página.

11 Páginas largas, con espacios vacíos al final de cada una.

12 No se puede usar el scroll del mouse.

13

Inconsistencia en la presentación de beneficios. Algunos se

muestran en la página inicial y otros (posiblemente más

importantes) son accesibles después de la navegación.

14 Mapa del sitio poco visible.

15 Páginas muy planas. No hay diferencias marcadas.

16 No se muestran funciones para cancelar operaciones.



Los problemas obtenidos al analizar audio y video durante la interacción de los usuarios con el sistema

cubren distintos aspectos. Algunos responden a situaciones puntuales que surgen dentro del sitio, pero otros se

relacionan con la estructura básica de la página.

En general, los usuarios enfatizaron sus comentarios respecto de la gran cantidad de información en pantalla

en cada página, lo que los bombardea y confunde. Les fue difícil encontrar información y en muchos casos se

encontraban desorientados u olvidaban en que sección se encontraban, ya que no se dispone de información en las

páginas que indique la sección en que se encuentra el usuario desde la página principal.

Otro punto a considerar es que los usuarios se sintieron aburridos en las partes en que debían completar

información para realizar alguna transacción. Es mucha la información que hay que rellenar y en distintos pasos, que

junto con la muestra poco agradable de la información en pantalla, hacía que los usuarios rápidamente se aburrieran

durante la interacción.

Así, los problemas más críticos según lo expresado por los usuarios están en torno, nuevamente, a la

navegabilidad dentro del sitio y la gran cantidad de información en cada página. Los problemas número 3, 4 y 6 se

enmarcan dentro de estos aspectos.

Los problemas número 9 y 13 también son interesantes. El primero, respecto de la no disponibilidad de la

función volver en las páginas, y el segundo respecto de la consistencia en la presentación y organización de

información, precisamente de los beneficios obtenibles con la tarjeta de la cadena de supermercados. Problemas que

también fueron obtenidos con la realización de los experimentos formales, lo que dará para establecer algunas

conclusiones en las secciones posteriores.

Finalmente, el único aspecto positivo mencionado en las dos interacciones constructivas realizadas es la

disposición, en algunas de las páginas, de un cuadro de asesoramiento o de ayuda al usuario sobre el objetivo de la

página o los pasos principales para realizar alguna acción dentro de ésta o dentro del proceso en que se está inmerso.



6.1.1.5. Experimentos Formales

Este método de prueba de la usabilidad fue desarrollado en el laboratorio de usabilidad de la Escuela de

Ingeniería Informática de la PUCV, con la participación de cinco usuarios representativos que se adecuan al único

perfil de usuario definido para esta prueba. Previa firma del acuerdo de confidencialidad (véase Anexo 2), se

grabaron los sucesos ocurridos en la interfaz durante la prueba, y se archivó la documentación entregada a los

usuarios para que estos respondieran a las solicitudes. El perfil de usuario, la definición de las tareas y el análisis de

los resultados obtenidos se muestra a continuación.


Para el caso de estudio del prototipo del sistema web de la cadena de supermercados se consideró sólo un

tipo de perfil de usuario. Este corresponde a usuarios novatos en el uso del sistema, es decir, usuarios representativos

que no habían tenido experiencia previa en el uso del sistema. Estos usuarios representativos corresponden a alumnos

de la carrera de Ingeniería Civil en Informática de la Escuela de Ingeniería Informática de la PUCV, por lo que

poseen un grado aceptable de experiencia de uso de aplicaciones web, entre otros tipos de sistemas software

interactivos.


Las tareas que se consideraron para la realización de esta prueba fueron diseñadas a partir de los problemas

de usabilidad identificados en la evaluación heurística, considerando los más críticos, tomando en cuenta la

característica de prototipo del sistema: sobrecarga de información y complejidad en la navegación.

Así, las tareas se definen, por una parte, en torno a la navegabilidad dentro del sitio. Se diseñaron tareas de

realización de transacciones, donde el usuario debe agregar información e ir navegando por la página y siguiendo

ciertos pasos para poder completar la tarea. Las tareas también se enfocaron en la búsqueda de información dentro

del sitio. La evaluación heurística, al arrojar el problema de que el sitio dispone de mucha información en pantalla

que confunde al usuario, ameritó el diseño de algunas tareas que respondan a este problema, para evaluarlo

empíricamente. La definición de las tareas se muestra a continuación, en la Tabla 6.7, mientras que el listado de

tareas realizado por los usuarios está disponible en el Anexo 6.



Tabla 6.7: Definición de Tareas para los Experimentos Formales

Tarea N° 1

Descripción Solicitar la obtención de la tarjeta de la cadena de supermercados.

Tiempo Máximo 8 minutos.

Caso Éxito Lograr la solicitud de la tarjeta.

Error No lograr la solicitud de la tarjeta.

Tarea N° 2

Descripción Simular la petición de un crédito.


Caso Éxito Lograr simular la petición del crédito.

Error No lograr simular la petición del crédito.

Tarea N° 3

Descripción Buscar información sobre las tiendas y locales que aceptan la tarjeta de la

cadena de supermercados.

Tiempo Máximo 7 minutos

Caso Éxito Encontrar la información y anotar lo solicitado.

Error No encontrar la información.

Tarea N° 4

Descripción Buscar información sobre productos con descuento al usar la tarjeta de la

cadena de supermercados.


Caso Éxito Encontrar la información y anotar lo solicitado.





Luego de haber realizado este método de prueba de la usabilidad con cinco usuarios representativos, se

procedió al análisis de los videos y los documentos en que debían responder algunas preguntas sobre información a

buscar. El análisis da para variadas conclusiones. Los resultados del desarrollo de los experimentos formales se

muestran en la Tabla 6.8, a continuación, que muestran los porcentajes asociados a si los usuarios realizaron

exitosamente cada una de las tareas solicitadas, además del tiempo promedio que los usuarios demoraron en la

realización de cada una de éstas.

Tabla 6.8: Resultados Experimentos Formales

Número Tarea Porcentaje de Éxito Tiempo Promedio

Tarea N° 1 100% 3 min 7 seg




Es notoriamente visible la diferencia en los porcentajes de éxito. Todos los usuarios pudieron realizar las

tareas número 1, 2 y 3, mientras que la tarea número 4 pudo ser realizada sólo por dos de los cinco usuarios

representativos (ninguno de los usuarios sobrepasó el tiempo máximo para cada tarea). Respecto de los tiempos,

estos fueron bastante bajos, aunque igualmente se notaron algunas pequeñas dificultades que se detallan más

adelante; en cuanto a los tiempos de la tarea que algunos usuarios no pudieron realizar, tampoco se superó el tiempo

máximo, ya que los usuarios se “rindieron” antes de ello.

La tarea número 4 dice relación con la búsqueda de información en el sitio, por lo que incluye los dos

objetivos de evaluación de la prueba: la navegabilidad del sitio y la sobrecarga de información en las páginas. Los

usuarios no pudieron encontrar la información solicitada, por lo que esta prueba empírica ha confirmado, en cierto

sentido, que los dos problemas que arrojó la evaluación heurística y que se consideraron para el diseño de las prueba,

poseen un alto grado de realismo, ya que se encontraron con un método de inspección y luego se confirmaron con

este método de prueba.



No sólo por el bajo porcentaje de éxito de la tarea número 4 es que se sacaron las conclusiones anteriores. El

análisis de los videos ha entregado información que también se relaciona con los problemas mencionados

previamente, entre otros. A pesar de que las tres primeras tareas entregaron un porcentaje completo de realización,

los usuarios se vieron un poco dudativos durante la interacción, por lo que en muchos casos tomaron caminos

erróneos antes de llegar al resultado que hacía completar la tarea.

Las dificultades se captaron generalmente en el reconocimiento de información que conducía al camino para

completar la tarea. Esto confirma nuevamente la confusión del usuario al recibir mucha información en pantalla, por

lo que le costaba encontrar las secciones que buscaba. Por ejemplo, el enlace que dirige el camino hacia la

realización de la tarea número 3 se encuentra en la página inicial, precisamente donde debe estar el usuario al

comienzo de esta tarea. Sin embargo, los usuarios no encontraron la información de manera simple, a pesar de

observar por cierto lapso de tiempo la página inicial buscando el enlace.

Además de este problema ya mencionado, se deducen problemas en la estructura y organización de la

información. Fue dificultoso para los usuarios encontrar cierta información agrupada en secciones que el usuario no

visitó, sino que buscó por otros lados. Precisamente fue uno de los motivos del bajo porcentaje de éxito de

realización de la tarea número 4, ya que la información solicitada se encontraba en una sección específica de la

página, a la cual la mayoría de los usuarios no pudo llegar (véase Figura 6.2 y comentarios relacionados).



6.1.1.6. Técnicas de Interrogación

Este método de prueba de la usabilidad fue desarrollado en el mismo laboratorio de usabilidad de la Escuela

de Ingeniería Informática, luego que los usuarios realizaron algunos de los otros métodos de prueba explicados

anteriormente. Así, los usuarios que realizaron el pensamiento en voz alta, experimentos formales o la interacción

constructiva, luego de haber interactuado con el sistema, fueron sometidos a esta prueba, con el fin de obtener su

percepción desde distintos aspectos sobre la aplicación web transaccional en evaluación. Sumando la cantidad de

usuarios de las evaluaciones anteriores, se realizaron trece evaluaciones de este tipo, una cifra aceptable para poder

obtener conclusiones sobre la percepción subjetiva de estos usuarios.


Los perfiles de usuario son los mismos que los perfiles de los métodos de prueba de usabilidad anteriores:

usuarios novatos sin experiencia previa en el uso del sistema, estudiantes de Ingeniería Civil Informática de la

PUCV.


El cuestionario se diseñó a base de los problemas encontrados en la evaluación heurística, relacionados

principalmente con la navegabilidad en el sitio y la disposición de la información en él. Así, las preguntas son las

siguientes, todas con una escala de 1 a 7:

Tabla 6.9: Preguntas del Cuestionario

Número Pregunta Nota Menor (1) Nota Mayor (7)

1 La disposición de la información en el sitio es: Muy difusa Muy clara

2 La navegabilidad del sitio es: Muy confusa Muy intuitiva

3 ¿El diseño del sitio es consistente? No Sí

4 ¿El sitio se preocupa de la satisfacción del usuario? Nunca Definitivamente

5 La funcionalidad del sitio es: Inútil Muy útil

6 ¿Visitaría nuevamente el sitio? Nunca Definitivamente

7 ¿Cómo evalúa su experiencia como colaborador de esta

prueba? Muy desagradable Muy agradable



El diseño de las preguntas y el significado de las notas fueron creados para que las notas mínimas

correspondan a evaluaciones que reprueban o califican de mala manera lo que se está preguntando, mientras que las

notas máximas corresponden a una aprobación o que la pregunta está siendo calificada positivamente.

Las seis primeras preguntas buscan rescatar la información respecto de la impresión del usuario sobre el

sitio, siendo la última de estas (pregunta número 6) la más general. La última pregunta del cuestionario responde a la

satisfacción del usuario en la prueba misma, para conocer si la forma de comunicación del evaluador con el usuario,

la evaluación en sí, y todos los aspectos relacionados, han sido los adecuados. El cuestionario presentado a los

usuarios está disponible en el Anexo 9.


El desarrollo de este método de prueba de la usabilidad, correspondiente a las técnicas de interrogación, ha

entregado los siguientes promedios de las respuestas de los usuarios que colaboraron con la prueba, que se muestran

en la Tabla 6.10.

Tabla 6.10: Promedio de las Respuestas al Cuestionario

Número Pregunta

Nota Menor

(1)

Promedio

(Escala de 1 a 7)

Nota Mayor

(7)

1 La disposición de la información en el

sitio es: Muy difusa 3,7 Muy clara

2 La navegabilidad del sitio es: Muy confusa 4,0 Muy intuitiva

3 ¿El diseño del sitio es consistente? No 4,8 Sí

4 ¿El sitio se preocupa de la satisfacción

del usuario? Nunca 4,9 Definitivamente

5 La funcionalidad del sitio es: Inútil 4,6 Muy útil

6 ¿Visitaría nuevamente el sitio? Nunca 3,9 Definitivamente

7 ¿Cómo evalúa su experiencia como

colaborador de esta prueba?

Muy

desagradable 6,0 Muy agradable

La nota promedio más baja corresponde a la pregunta número 1, sobre la disposición de la información en el

sitio. Consecuentemente con los problemas encontrados en los métodos de evaluación anteriormente desarrollados,

lo usuarios captaron y sintieron que la información no es presentada y organizada de buena forma.



Otras dos preguntas obtuvieron resultados cercanos un poco más bajos al compararse con las otras

preguntas. La pregunta número 2 obtuvo un promedio regular, que comunica que los usuarios no se sintieron

satisfechos con la navegabilidad de la cual dispone el sitio, un problema que también fue dado a la luz con los otros

métodos de evaluación realizados, y que ahora se confirma. La pregunta número 6, que posee un nivel de generalidad

mayor, ya que pregunta si el usuario volvería al sitio, obtuve también un promedio bajo. Se puede entonces que, en

general, los usuarios no se sintieron satisfechos durante la interacción con el sistema, ya que están más cercanos al

extremo de que nunca volverían a visitar el sitio, lo cual no es menor.

En general todas las preguntas arrojaron resultados que no son muy alentadores respecto de la satisfacción

subjetiva de los usuarios con el sistema. Ninguna de las preguntas relacionadas con la percepción de la interacción

(las seis primeras) supera la nota 5, por lo que se puede decir que, en general, los usuarios opinan que la disposición

de la información, la navegabilidad, el diseño del sitio, la funcionalidad, y su satisfacción como usuario no fue muy

buena.

La única pregunta de la cual se obtuvieron resultados positivos y alentadores es la número 7, la cual buscaba

percibir la satisfacción del usuario respecto de la evaluación misma, es decir, su experiencia como colaborador. Los

resultados, muy cercanos a la nota máxima, que evalúa como muy agradable la experiencia, indican que la forma de

interacción y comunicación con los usuarios ha sido la correcta, no han sido pasados a llevar y han comprendido que

el objetivo de las evaluaciones es medir el nivel de usabilidad del sistema y no su eficiencia y/o inteligencia como

usuario.



6.1.1.7. Ordenamiento de Tarjetas

El ordenamiento de tarjetas, perteneciente a los métodos de prueba de la usabilidad, fue realizado por la

mayoría de los participantes en el laboratorio de usabilidad de la Escuela de Ingeniería Informática de la PUCV.

Algunas otras pruebas fueron realizadas en otros lugares un poco más informales, como salas de estudio y salas de

clases. Se realizaron siete evaluaciones de este tipo, con la participación de usuarios adecuados para el perfil que se

define más adelante.

Claramente, este método de evaluación entregará resultados distintos a los que han entregado las otras

evaluaciones, ya que se preocupa de analizar principalmente la calidad del diseño del sitio. Así, se identificará el

modelo mental de los usuarios, que posteriormente será comparado con el diseño que propone el sistema de la

cadena de supermercados. De esta forma, se podrá obtener el nivel de concordancia del modelo de los diseñadores

del sitio con el de usuarios representativos.

De forma secundaria y dependiendo de los resultados, probablemente será posible concluir que algunos de

los problemas identificados con alguno de los otros métodos de prueba de la usabilidad se deba a algún problema de

diseño que se identifique con el ordenamiento de tarjetas.


Los siete usuarios de prueba que participaron del ordenamiento de tarjetas correspondían al perfil de

usuarios novatos, es decir, sin experiencia previa en el uso del sistema. Correspondían a estudiantes de la PUCV con

cierta experiencia de uso en aplicaciones web.


La preparación de este método de prueba de la usabilidad se enfoca principalmente en el diseño de las

tarjetas que los usuarios deberán ordenar posteriormente. Debido a que el sistema en evaluación ya está en una etapa

de desarrollo avanzada, fue necesario realizar la denominada ingeniería inversa, por lo que se realizó una inspección

del sistema para identificar las distintas categorías temáticas, y las formas de agrupación de las mismas.

El análisis del sistema concluyó con una identificación de 29 tarjetas, que corresponden a las distintas

categorías temáticas nombradas anteriormente, con la característica de que algunas tarjetas agrupan a otro conjunto

de ellas. Cada una de estas tarjetas se muestra a continuación, en la Tabla 6.11, agrupadas de la forma en que está

diseñado el sistema actualmente.



Tabla 6.11: Agrupación Actual de “Tarjetas” Prototipo Web Cadena de Supermercados

Servicios Financieros

Tarjeta Red de Servicios Crédito Seguros Asistencias

Obtención de la

Tarjeta

Pago de Cuentas o

Servicios

Simulación del

Crédito

Seguro Automotriz Contratar Asistencia

Tiendas que Aceptan

la Tarjeta

Costo del Servicio Conozca el Crédito Seguros de Vida ¿Cómo Usar una

Asistencia?

Beneficios de la

Tarjeta

¿Qué Puedo Pagar? Seguros de Hogar PC Asistencia

Oportunidades al

Pagar con Tarjeta

Medios de Pago Otra Familia de

Seguros

Asistencia Mascota

Solicitud de un

Seguro

Asistencia en Viaje

Ruta Asistencia

Asistencia Full

Asistencia Hogar

El sitio de la cadena de supermercados agrupa todas sus categorías con el nombre de Servicios Financieros,

el cual incluye cinco subcategorías: Tarjeta, Red de Servicios, Crédito, Seguros y Asistencias. Se podría decir que

estas últimas corresponden a las opciones principales del sitio, las cuales incluyen otro conjunto de categorías, tal

como se muestra en la tabla anterior.

Luego de la definición de cada una de las tarjetas, se procede a la realización misma de la prueba. En un

principio se realizó una introducción verbal por parte del evaluador a los usuarios sobre el tipo de prueba que se

estaba realizando y sobre la aplicación web transaccional en evaluación.

Las 29 tarjetas fueron dispuestas a los usuarios representativos de forma que no se establezca ningún tipo de

indicación que pueda influenciar a los usuarios en sus decisiones. De manera independiente y gradual, los

participantes identificaron cada una de las tarjetas y realizaron las distintas agrupaciones, en un tiempo promedio de

10 minutos aproximadamente. Las conclusiones del ordenamiento de tarjetas realizados por los siete participantes se

muestra a continuación.




El análisis de los resultados de las agrupaciones realizadas por los usuarios ha permitido identificar algunos

problemas de usabilidad referidos principalmente a la arquitectura de la información en el diseño del prototipo de

sistema web de la cadena de supermercados.

El primer problema identificado está relacionado con la arquitectura principal de la aplicación web

transaccional. Ésta comunica al usuario que se trata de una aplicación web de servicios financieros que posee cinco

categorías distintas: tarjeta de la cadena de supermercados, red de servicios de la cadena de supermercados, crédito,

seguros y asistencias. Sin embargo, los usuarios dispusieron las tarjetas de forma que identifican que el título o

categoría principal de la aplicación web corresponde a la red de servicios de la cadena de supermercados, que incluye

como subcategorías a los servicios financieros, la tarjeta de la cadena de supermercados, crédito, seguros y

asistencias.

Otro problema dice relación con la disposición de las tarjetas más específicas dentro de las subcategorías

nombradas anteriormente. La sección crédito fue comúnmente agrupada dentro de la subcategoría servicios

financieros, junto con las tarjetas afines (simulación del crédito, conozca el crédito), y no de la forma que dispone

actualmente la aplicación web, que trata a crédito como una subcategoría. Esto se debe, principalmente, a que las

tarjetas relacionadas con el crédito son muy pocas (sólo 3), cantidad que los usuarios consideraron baja como para

ser una subcategoría por sí sola, por lo que la agruparon dentro de otra un poco más general.

Los dos problemas nombrados anteriormente son los más destacables y representativos. En general, la

identificación de las subcategorías y las tarjetas correspondientes a ellas fue acorde con la arquitectura del diseño de

la página, salvo el caso que se detalló en el párrafo anterior.



6.1.2. Análisis de Resultados

Esta sección tiene como objetivo establecer algunas comparaciones de los métodos de evaluación de

usabilidad sobre aplicaciones web transaccionales, en base a las evaluaciones desarrolladas sobre el caso de estudio

1, correspondiente al prototipo del sitio web de la una cadena de supermercados, cuyos resultados se analizaron

anteriormente para cada uno de los métodos realizados. Esos análisis anteriores se establecieron enfocándose

solamente en los resultados entregados por el método en ejecución, por lo que ahora esos análisis se tomarán para

compararlos con los resultados de los otros métodos.

En un principio se realizará un análisis comparativo de los tiempos involucrados en cada método, luego de

los errores encontrados y finalmente una comparación en general de los aspectos restantes. Además, en algunos

casos se compararán todos los métodos en general, es decir, considerándolos como métodos de evaluación de

usabilidad y en otros se realizará la separación de los métodos de inspección con los de prueba de la usabilidad, para

analizarlos dentro de esta categorización, lo cual depende de los factores en comparación.

6.1.2.1. Tiempos Involucrados

Los tiempos involucrados en casa método pueden ser determinantes para escoger uno de estos sobre otro,

principalmente cuando el tiempo es escaso, lo cual se da en la mayoría de los casos.

Así, una primera comparación de los métodos de evaluación de usabilidad realizados puede enfocarse en

torno a la preparación de estos distintos tipos de técnicas. La evaluación heurística no necesitó de una preparación

previa para que los evaluadores inspeccionen el sistema, sólo fue necesario un pequeño acercamiento al sistema y sus

principales características, y los principios de usabilidad aplicados al caso. La interacción constructiva, por su lado,

tampoco ameritó una preparación para poder llevarse a cabo, es más, al ser un método de prueba que no necesita de

un diseño de tareas, su simplicidad respecto de la preparación es considerable, al igual que el pensamiento en voz

alta. Por otro lado están los experimentos formales, que sí necesitaron de un diseño de tareas por lo que, en este

sentido, ameritan un poco más de tiempo en la preparación para su desarrollo. Asimismo, las técnicas de

interrogación deben tener como base un conjunto de preguntas, las cuales debieron ser diseñadas con anterioridad.

Finalmente, las pruebas en papel y el ordenamiento de tarjetas ameritaron un análisis de la aplicación web para

identificar los prototipos a “dibujar” y las tarjetas, respectivamente, situaciones que consumen tiempos

medianamente elevados.

Para el caso de los experimentos formales el factor del tiempo en la etapa de preparación de la prueba fue un

poco más crítico ya que, al ser aplicaciones web transaccionales las que se están evaluando, se debió crear tipos de

transacciones a realizar, evaluar su importancia y probarlas. Además, se agrega el detalle de cada una de las tareas,

que incluye criterios de éxito y fracaso, tiempos máximos, etcétera.



Ahora bien, respecto del proceso mismo de desarrollo del método de evaluación, los tiempos involucrados

generaron más diferencias que el proceso anterior (de preparación de la evaluación). La evaluación heurística, a

pesar de ser un método calificado como simple para desarrollar, necesita de un período de tiempo considerable para

que los evaluadores puedan inspeccionar el sistema tranquilamente y conocerlo. Por su característica de que cada

evaluador puede inspeccionar el sistema de forma independiente, se tornó un poco complicado reunir todos los

problemas, por la disponibilidad de tiempo de cada uno, por lo que el tiempo desde que se presentó el sistema a los

evaluadores hasta que se obtuvieron las calificaciones de todos los problemas integrados no fue menor. Claramente

que esto depende de muchos factores, pero para el caso realizado se dio de la forma mencionada. Si se compara este

tiempo con los otros métodos, la evaluación heurística fue el método más demoroso. Todas las evaluaciones de

prueba de la usabilidad demoraron el tiempo en que los usuarios realizaron la prueba. Los experimentos formales y el

pensamiento en voz alta mantuvieron a los usuarios interactuando con la aplicación web por un período aproximado

de dos horas. La interacción constructiva también se realizó en un período aproximado de dos horas, mientras que los

cuestionarios sólo tomaron algunos pocos minutos. Las pruebas en papel y el ordenamiento de tarjetas, por su parte,

necesitaron de un poco más de tiempo que el que se presupuestaba: 40 minutos el primero y una hora el segundo,

aproximadamente.

Los tiempos involucrados en analizar los resultados obtenidos también pasaron a ser un factor de

comparación debido a las variaciones entre los métodos. La evaluación heurística, por su lado, identifica y asigna

valores a los problemas durante el proceso, por lo que en la parte de análisis ya se disponían de los problemas,

necesitando solamente ordenarlos, profundizar en ellos para explicarlos y posiblemente fundamentar sus causas, lo

que no fue un proceso ciertamente largo ni complicado. Los experimentos formales, el pensamiento en voz alta y la

interacción constructiva necesitan para su análisis el tiempo para visualizar la interacción de los usuarios con el

sistema mediante los videos, por lo que el tiempo está asociado directamente al tiempo de desarrollo de todas las

pruebas: dos horas para cada uno de los métodos, aproximadamente. Claramente hay que agregar otro lapso de

tiempo a esto para integrar, documentar y explicar los problemas encontrados, sobretodo para los experimentos

formales, que desarrollan análisis estadísticos de los resultados. Los cuestionarios disponen de la información

inmediatamente, por lo que deben hacerse los análisis estadísticos necesarios con las respuestas de los usuarios y

sacar conclusiones. Algo parecido ocurrió con las pruebas en papel, donde se debió principalmente analizar y

documentar las impresiones que expresaron los usuarios. Finalmente, el ordenamiento de tarjetas ameritó un poco

más de análisis ya que, en general, los usuarios ordenaron de distintas formas las tarjetas, por lo que la identificación

de patrones que siguieron en la ordenación es la situación más demorosa de identificar.

La Tabla 6.12, a continuación, resume los niveles de tiempo asociados a cada etapa de los métodos de

evaluación de usabilidad realizados.



Tabla 6.12: Tiempos Involucrados en las Etapas de los Métodos de Evaluación

Método de Evaluación Preparación Proceso Análisis TOTAL

Evaluación Heurística 30 minutos 1 día 1 hora 25:30 hrs.

Pruebas en Papel 1,5 horas 40 minutos 1 hora 03:10 hrs.

Pensamiento en Voz Alta 30 minutos 2 horas 3 horas 05:30 hrs.

Interacción Constructiva 30 minutos 2 horas 3 horas 05:30 hrs.

Experimentos Formales 2,5 horas 2 horas 4 horas 08:30 hrs.

Técnicas de Interrogación 1,5 horas 20 minutos 1 hora 02:50 hrs.

Ordenamiento de Tarjetas 1,5 horas 1 hora 2 horas 04:30 hrs.

En resumidas cuentas, la tabla anterior indica que para el proceso de preparación, la evaluación heurística, el

pensamiento en voz alta y la interacción constructiva son los más sencillos en cuanto a tiempo. Dentro del proceso de

mismo de ejecución, no hay dudas de que las técnicas de interrogación son las que consumen menos tiempo, seguida

de cerca por las pruebas en papel. Finalmente, para la parte de análisis, la evaluación heurística, las pruebas en papel

y nuevamente las técnicas de interrogación toman la ventaja.

Ahora bien, respecto de los tiempos totales que muestra la tabla que se está evaluando, hay una diferencia

marcada en cuanto al método de evaluación que tomó más tiempo por sobre todas las demás. Esa es la evaluación

heurística. Al ser un método de inspección de usabilidad en el que están involucrados varios evaluadores expertos, el

tiempo aumenta bastante. Pese a ello, la evaluación heurística se considera esencial, ya que marca una pauta para las

demás evaluaciones (de prueba). A continuación se muestra un pequeño “ranking” con los tiempos totales que

necesitó cada método de evaluación (de menos a más):

1. Técnicas de Interrogación.

2. Pruebas en Papel.

3. Ordenamiento de Tarjetas.

4. Interacción Constructiva.

5. Pensamiento en Voz Alta.

6. Experimentos Formales.

7. Evaluación Heurística.



Los tres primeros métodos de evaluación corresponden a pruebas con un nivel considerable de subjetividad,

y que entregan resultados generales en cuanto a la usabilidad de la aplicación web transaccional. Lo más interesante

de este “ranking” es la posición de la interacción constructiva y el pensamiento en voz alta, ubicadas sobre otros

métodos más “clásicos” en el tema de evaluación de usabilidad.

Para definir una base más palpable para la comparación y futura definición de la metodología de evaluación

de usabilidad, la Tabla 6.13, muestra un cuadro comparativo de los tiempos involucrados en cada etapa del desarrollo

de cada uno de los métodos de evaluación:

Tabla 6.13: Tiempos Involucrados en las Etapas de los Métodos de Evaluación por Escala de Tiempo

Método de Evaluación Preparación Proceso Análisis

Evaluación Heurística Muy Bajo Muy Alto Bajo

Pruebas en Papel Bajo Muy Bajo Bajo

Pensamiento en Voz Alta Muy Bajo Medio Medio

Interacción Constructiva Muy Bajo Medio Medio

Experimentos Formales Medio Medio Alto

Técnicas de Interrogación Bajo Muy Bajo Bajo

Ordenamiento de Tarjetas Bajo Bajo Medio

La tabla anterior se basa en los lapsos de tiempo que muestra la siguiente escala:

Muy Bajo: 0:00 a 0:59 hrs.

Bajo: 1:00 a 1:59 hrs.

Medio: 2:00 a 3:59 hrs.

Alto: 4:00 a 6:00 hrs.

Muy Alto: Más de 6:00 hrs.



6.1.2.2. Problemas Identificados

Los problemas identificados en cada uno de los métodos de evaluación de usabilidad realizados también se

tornan como factores importantes a considerar, ya que son el objetivo principal de estas evaluaciones.

Según los resultados mostrados en las secciones anteriores, la evaluación heurística identificó un total de 29

problemas de usabilidad en el caso de estudio del prototipo del sistema web de la cadena de supermercados. Al ser

éste el único de los métodos de inspección de usabilidad que se ha realizado hasta el momento, no será comparado

con los otros para esta parte, ya que los demás corresponden a métodos de prueba realizados con usuarios

representativos. Así, se tomará a la evaluación heurística como base para hacer comparaciones entre los métodos de

prueba de la usabilidad que se han realizado hasta el momento. Se considerarán los problemas identificados en la

evaluación heurística y se evaluará si estos fueron confirmados en las pruebas con usuario, para cada tipo de método.

Sólo si es muy necesaria y relevante una comparación de la evaluación heurística con alguno de los métodos de

prueba, se llevará a cabo el susodicho.

Así entonces, la evaluación heurística identificó 29 problemas de usabilidad, algunos más críticos que otros,

destacándose los problemas de diseño, consistencia y control del usuario. Por la característica de prototipo del

sistema en evaluación, se enfatizaron los problemas de navegabilidad y la gran cantidad de información en las

páginas, motivo de confusión de los usuarios, lo cual claramente influye en la realización de transacciones que,

muchas veces, están asociadas a contratos y/o pagos en línea, entre otras cosas.

El desarrollo de los experimentos formales está asociado a una lista de tareas que los usuarios

representativos deben realizar. Así, se busca comprobar empíricamente la usabilidad del sistema, generalmente

creando la lista de tareas basándose en la identificación de problemas de usabilidad con uno de los métodos de

inspección (evaluación heurística, en este caso). En esta línea, la lista de tareas para este tipo de método de prueba

realizado se enfocó en los problemas de navegabilidad y el bombardeo de información en cada página del sitio, como

ya se mencionó en su debido momento. Esta característica hace que la interacción del usuario se acote al listado de

tareas, por lo que no se realiza un análisis completo del sistema. Satisfactoriamente, se confirmaron empíricamente

los problemas que se pretendía evaluar, por lo que su eficiencia está a la vista. Es más, se obtuvieron problemas que

no se descubrieron con la evaluación heurística.

Por otro lado, se pudo notar que el pensamiento en voz alta no es una evaluación satisfactoria para los

usuarios de prueba, en general. Estos, al interactuar con la aplicación web en evaluación, se notaron relativamente

incómodos: en muchos casos se bloqueaban mientras expresaban a viva voz sus impresiones o se complicaban al dar

sus argumentos. Esto claramente fue una influencia en cuanto a los tiempos que demoraron en realizar las tareas, por

lo que no es posible realizar un análisis estadístico de los tiempos necesarios para realizar cada una de las tareas de

manera efectiva. Sin embargo, su realización también permitió confirmar los problemas más críticos identificados en

la evaluación heurística realizada anteriormente.



La interacción constructiva, por su parte, arrojó resultados bastante sorprendentes. Su realización permitió

obtener varios problemas de usabilidad, los cuales, en su mayoría, correspondían también a problemas que la

evaluación heurística había identificado. La gran diferencia de este método con los experimentos formales, es que

éste encuentra problemas en cualquier parte del sistema en evaluación, no así con el susodicho, que encuentran los

problemas en un escenario específico dentro del sistema, determinado por el listado de tareas; su diferencia

significativa con el pensamiento en voz alta está en el número de usuarios que interactúan con la aplicación: la

interacción constructiva (dos usuarios) permite una fluidez en los comentarios a viva voz, mientras que el

pensamiento en voz alta (un usuario) obstaculiza, de cierta forma, el actuar normal de los usuarios.

De igual forma que los experimentos formales y el pensamiento en voz alta, la interacción constructiva

permitió confirmar empíricamente los principales problemas de la evaluación heurística, además de otros problemas

que no se habían descubierto.

Caso aparte es el relacionado con las pruebas en papel, técnicas de interrogación y ordenamiento de tarjetas

que, pese a confirmar de forma general algunos problemas de la evaluación heurística, sus resultados no pueden ser

comparables con los otros métodos ya mencionados.

La Tabla 6.14 corresponde a la lista de los problemas encontrados en la evaluación heurística y algunos de

los métodos de prueba de la usabilidad realizados, que permitieron confirmar cada uno de esos problemas. Los

problemas destacados (celdas sombreadas) corresponden a los nueve problemas más altos en el ranking de criticidad

de la evaluación heurística, correspondiente a las notas con promedio de calificación sobre seis. No se agregan las

pruebas en papel, técnicas de interrogación ni ordenamiento de tarjetas en esta tabla por la naturaleza de cada uno de

ellos, que entrega información más global y subjetiva sobre la experiencia del usuario, por lo que no podrían

compararse con los otros métodos, que entregan problemas específicos. Tampoco se agregan los experimentos

formales que, a pesar de realizar una interacción directa del usuario con la aplicación, no permite una comparación

específica (problema a problema). Además, al enfocarse en escenarios específicos determinados por la lista de tareas,

se distancia de la interacción constructiva y el pensamiento en voz alta, que realizan una evaluación un poco más

global de la aplicación web.

Claramente, la interacción constructiva toma ventaja respecto del pensamiento en voz alta. De los nueve

problemas más críticos identificados por la evaluación heurística, la interacción constructiva identificó siete (casi un

80%). Además, permitió identificar otros seis problemas de usabilidad que no habían sido identificados por la

evaluación heurística, destacando el relacionado con los beneficios, que también fue descubierto en el experimento

formal y en el pensamiento en voz alta.

El pensamiento en voz alta se ubica entre los métodos analizados anteriormente. Su realización logró

confirmar un 28% del total de problemas encontrados por la evaluación heurística y un 56% de los más críticos. Así,

supera a los experimentos formales en su capacidad de encontrar problemas. La desventaja de este método, como ya



se ha dicho anteriormente, es la interferencia de la expresión a viva voz de las impresiones de los usuarios en la

interacción normal con el sistema.

Tabla 6.14: Problemas Evaluación Heurística confirmados por Métodos de Prueba

Principio Problema Pensando en

Voz Alta

Interacción

Constructiva

1

1 X X

2

3

2 4

3 5 X X

6 X X

4

7 X

8

9 X

10

11 X

12

13

14

5 15

6 16

7 17

8

18

19 X X

20 X X

21 X

22 X X

23

24

25 X

9 26 X

10

27

28

29

Problemas Totales

Confirmados 8 (28%) 11 (40%)

Problemas Críticos

Confirmados 5 (56%) 7 (78%)

Otros Problemas 2 6

TOTAL 10 17



Finalmente, si se realiza un análisis comparativo de los tres métodos de prueba de la usabilidad que realizan

una interacción directa del usuario con la aplicación web transaccional (pensamiento en voz alta, interacción

constructiva y experimentos formales), se concluye que estos tres métodos de prueba de la usabilidad confirmaron

los problemas más importantes que se identificaron en la evaluación heurística, algunos con más especificación que

otros, y con algunas diferencias. Las mayores diferencias están, primeramente, en el enfoque en escenarios por parte

de los experimentos formales y en su posibilidad de realizar análisis cuantitativo de la interacción de los usuarios con

el sistema, lo cual se torna como una de sus mayores ventajas.

La interacción constructiva y el pensamiento en voz alta se preocupan de la aplicación web transaccional de

una forma más global y, aunque no permiten análisis cuantitativos, permiten identificar muchos problemas que con

algunos de los otros métodos de prueba no sería posible identificar. Claro está, gracias al análisis de la tabla anterior,

que la interacción constructiva destaca en este sentido.

Pasando al análisis de los otros tres métodos de prueba de la usabilidad que no se incluyeron en la tabla

anterior, las pruebas en papel permitieron identificar algunos problemas de usabilidad pero que no se consideran

críticos. Se captaron algunos pequeños problemas de diseño, aunque de manera muy subjetiva, ya que los usuarios

no realizan ninguna interacción con el sistema, sólo analizan los prototipos en papel. Es destacable el período en que

se realizó este método de prueba; la bibliografía dice que debe ser realizado en etapas tempranas del desarrollo de

software, pero para este caso se realizó en etapas finales e igualmente se obtuvieron algunos resultados.

Las técnicas de interrogación, por su parte, confirmaron subjetivamente pero habiendo experimentado una

interacción con el sistema, que el prototipo del sitio web de la cadena de supermercados posee problemas de

navegación, diseño y sobrecarga de información, lo que hará que los usuarios no se sientan cómodos al visitar el

sitio. Esto es muy importante, ya que la prueba funciona como un complemento para que los usuarios califiquen si

los problemas que se identificaron anteriormente son tan reales como se propone.

Finalmente, el ordenamiento de tarjetas también permitió obtener errores en cuanto al diseño de la

aplicación. Estos problemas pueden estar asociados a la dificultad por parte de los usuarios en encontrar la

información necesaria, por lo que se une a los otros métodos que lograron confirmar este problema crítico. También

se destaca la etapa en el proceso de desarrollo de software en que se realiza. Se sabe que es complicado hacer

modificaciones de diseño a estas alturas sobre la aplicación, pero la efectividad en la obtención de problemas de

usabilidad en cuanto a diseño en esta etapa es clara.



6.2. Caso de Estudio: Navegador Académico PUCV

El segundo caso de estudio a considerar para la presente investigación corresponde al Navegador

Académico de la PUCV (http://navegador.ucv.cl), versión 1.0. Esta aplicación web transaccional es usada por

distintos grupos de personas que tienen alguna relación con la universidad, sean estos alumnos, profesores, jefes de

docencia, administrativos, etcétera. Así, estos usuarios pueden realizar transacciones relacionadas, por ejemplo, con

la pre-inscripción y/o inscripción de asignaturas, pago de matrículas, ingreso de evaluaciones, búsquedas de

información, etcétera.

El perfil que se dispone y que se considerará para la evaluación corresponde al de Jefe de Docencia, el cual

posee una buena cantidad de funcionalidades y/o páginas web que pertenecen a otros perfiles (alumnos, profesores,

etcétera), por lo que se podrá realizar una evaluación ciertamente más general. La página inicial del jefe de docencia,

luego de haber iniciado la sesión, se muestra en la Figura 6.6, a continuación.

Figura 6.6: Página Principal del Navegador Académico, Perfil Jefe de Docencia

http://navegador.ucv.cl/



Figura 6.7: Página de Matrículas del Alumno del Navegador Académico

La Figura 6.7, que se aprecia más arriba, corresponde a una de las páginas de la información del alumno,

específicamente de sus matrículas. La parte superior se utiliza para los nombres y encabezados, la parte izquierda

para la disposición de los menús, y todo el resto para la información de cada una de las páginas.

A continuación se muestran las distintas evaluaciones realizadas sobre este caso de estudio. Luego se realiza

un análisis que establecerá algunas de las diferencias que se asocian a la realización de estas evaluaciones, primero

respecto del tiempo y luego respecto de los errores identificados.




Se realizaron los mismos métodos de evaluación de usabilidad que se realizaron para el caso de estudio 1.

Así, en un principio se desarrolló la evaluación heurística, prosiguiendo con todos los métodos de prueba de la

usabilidad. El acceso privilegiado a los perfiles en evaluación limitó el desarrollo de todos estos métodos de

evaluación a desarrollarse en el laboratorio de usabilidad de la Escuela de Informática de la PUCV.


Este método de inspección de usabilidad fue realizado por cuatro evaluadores con experiencia media en este

tipo de evaluaciones. Fue desarrollado en el laboratorio de usabilidad, en donde se analizaron las características en

cuanto a usabilidad del Navegador Académico, con el perfil jefe de docencia.

El perfil de los evaluadores, las heurísticas consideradas como base para la evaluación, los problemas

identificados y el análisis de los resultados se muestra a continuación.


Este método de inspección de usabilidad se realizó gracias a la colaboración de cuatro evaluadores que


Alumnos del programa de Magíster en Ingeniería Informática de la Escuela de Ingeniería

Informática de la Pontificia Universidad Católica de Valparaíso (PUCV).




Las heurísticas que se utilizaron como base para la evaluación corresponden a las propuestas por Jakob

Nielsen, aunque particularizadas para las aplicaciones web transaccionales, como muestra la Tabla 6.1, al comienzo

de este capítulo.




La evaluación heurística realizada por los cuatro evaluadores permitió identificar una cantidad elevada de

problemas (un total de 43), por lo que se puede decir que la usabilidad de la aplicación web en evaluación no es de

las mejores. Estos fueron agrupados según el principio de usabilidad que contradice, como se muestra en la Tabla

6.16, a continuación.

Tabla 6.15: Problemas de Usabilidad Evaluación Heurística por Principio



Conexión entre el Sistema y el Mundo Real. 7

Control y Libertad del Usuario. 3

Consistencia y Estándares. 7

Prevención de Errores. 4

Reconocer Mejor que Recordar. 6

Flexibilidad y Eficiencia de Uso. 7

Diseño Estético y Minimalista. 6

Ayuda al Usuario a Reconocer, Diagnosticar y Recuperarse de Errores. 2

Ayuda y Documentación. 1

El análisis de la tabla anterior comunica que los problemas están relativamente distribuidos en la mayoría de

los principios de usabilidad propuestos por Nielsen, salvo un par de casos. Esto quiere decir que, posiblemente, en la

etapa en que se encuentra el sistema no se ha considerado este importante atributo, razón por la cual existen

problemas de variados ámbitos.

Según los resultados, los principios que más fueron sobrepasados son los de Conexión entre el Sistema y el

Mundo Real, Consistencia y Estándares, Reconocer Mejor que Recordar, Flexibilidad y Eficiencia de Uso y Diseño

Estético y Minimalista. Resulta interesante que respecto del principio de Visibilidad del Estado del Sistema no se

identificó ningún problema.

La lista completa de los problemas identificados, separados por principio y con las calificaciones promedio

en cuanto a severidad, frecuencia y criticidad se muestra a continuación, en la Tabla 6.17 (el Anexo 4 presenta las

calificaciones individuales de cada uno de los evaluadores para cada principio).



Tabla 6.16: Lista Completa de Problemas Identificados por la Evaluación Heurística

Principio de


Conexión entre el

Sistema y el

Mundo Real

1 Menú principal poco representativo. No

equilibrado. 3,00 3,50 6,50

2 Títulos poco representativos (“Eliminados”,

por ejemplo). 2,75 2,50 5,25

3 Puntero Mouse no representativo. 3,00 3,25 6,25

4

La opción Administrar eliminados en la

opción Carrera no es muy intuitiva en

cuanto a la acción que ejecuta

2,75 2,50 5,25

5

La sección Varios hace pensar que adentro

hay muchas cosas cuando en realidad sólo

hay 2 opciones: reportes y encuestas.

1,50 3,00 4,50

6

En la página de Alumnos Carrera, el "Año"

llega hasta el "2018". Claramente no existen

alumnos matriculados hasta ese año.

2,50 2,00 4,50

7 Al ir a Varios, hay un link Reportes que no

se entiende que significa. 2,75 2,25 5,00

Control y

Libertad del

Usuario

8

Los vínculos Inicio y Volver no se destacan

mucho por lo que el usuario los puede pasar

por alto

3,00 3,00 6,00

9 No hay opción Cerrar sesión. 4,00 4,00 8,00

10 En el sector de "Búsqueda", los Links Inicio

y Volver envían al mismo lugar. 2,50 3,25 5,75

Consistencia y

Estándares

11 Inconsistencia en muestra de opciones: 2

“Inicio”. 2,50 2,75 5,25

12

Inconsistencia opciones menú. Por ejemplo,

se muestran 3 opciones, pero al ingresar en

alguna de éstas el link se elimina, no así en

otros casos. En otros casos simplemente el

menú se elimina.

3,50 3,25 6,75

13 Inconsistencia menús (formato y colores). 2,50 2,75 5,25

14

El enlace ALUMNOS es poco intuitivo

respecto a lo que se espera encontrar que

podría ser opciones sobre los perfiles

alumnos; y lo que aparece es simplemente

un buscador de alumnos, por lo que el título del enlace debería especificar directamente

"BUSQUEDA DE ALUMNOS"

3,25 3,00 6,25

15

Al ingresar a la opción CARRERAS,

nuevamente aparece un sistema de búsqueda

de carreras; sin embargo la página muestra

por default los resultados de una búsqueda

que no he ejecutado; debería ser consistente

con la presentación del sistema de búsqueda

de usuarios.

3,00 3,00 6,00



Tabla 6.16 (continuación): Lista Completa de Problemas Identificados por la Evaluación Heurística

Principio de


Consistencia y

Estándares

16

En la búsqueda hay una palabra (bajo el

escudo) que dice sugerencias. No es clara su

función.

2,25 1,75 4,00

17

Al ingresar a la "Comparación Malla" de un

alumno, [Aprobado] pareciera que fuera un

link (color azul) y no lo es. No así la Clave

de la Asignatura.

3,00 3,00 6,00

Prevención de

Errores

18

Los vínculos VARIOS, FINANCIEROS,

INDICADORES DE GESTIÓN, se

encuentran mal elaborados, pues sólo parte

de la palabra se comporta como vínculo.

2,25 3,00 5,25

19

En el formulario de búsqueda de

ALUMNOS, el mensaje "sin dígito

verificador" junto al campo RUT no es muy

sugerente, sería mejor colocar el mensaje

acompañado de un ejemplo de RUT .

2,50 2,25 4,75

20

En la búsqueda de Carreras, el campo

unidad académica es un listado de selección, mientras que el campo Carrera es un cuadro

de texto en el que el usuario debe ingresar el

nombre de la carrera a buscar; ambos

campos deberían ser listado de opciones

predefinidas para evitar que el usuario

cometa errores al ingresar el nombre de una

carrera.

2,25 3,00 5,25

21

Al realizar una búsqueda o un "cambio" de

los datos (el mail por ejemplo), no se realiza

ninguna pregunta de confirmación de los

cambios.

3,25 3,25 6,50

Reconocimiento

en Lugar de

Recordar

22 Mala ubicación de títulos de páginas

(carreras, por ejemplo). 2,25 3,00 5,25

23 Opción Buscar poco visible o no existente

(en ciertos casos). 3,50 2,75 6,25

24 Algunas páginas sin título. 3,00 2,50 5,50

25

¿Buscar qué? (En algunos ok: “Buscar

profesores”; en otros solo se muestra

“Buscar”).

2,50 2,50 5,00

26 No se destacan los vínculos ya visitados 3,25 3,50 6,75

27

Al listar los alumnos de la carrera (que son

muchos), la "leyenda" de los atributos está

ubicada al final de la página, para saber que

significa, se debe llegar hasta el final de

ésta.

2,75 3,75 6,50




Principio de


Flexibilidad y

Eficiencia de Uso

28 Búsqueda Alumnos: tecla Enter no

habilitada. 2,50 3,50 6,00

29

Título Navegador Académico es solo una

imagen, podría ser un link a la página

inicial.

2,50 3,25 5,75

30

No es posible ingresar a información de

profesores si no se ingresa a la opción de

búsqueda de ellos. Se muestran sus nombres

en los cursos, pero no como links.

3,25 3,00 6,25

31

El botón LIMPIAR del formulario de

búsqueda de usuarios no hace ninguna

acción

2,50 3,00 5,50

32

En Carreras hay un combobox que lista las

unidades académicas y arriba un input para

hacer una búsqueda sobre el combobox

elegido. En cambio, cuando se listan todos

los alumnos de la carrera esta opción no

existe, cuando sería más útil.

2,25 3,25 5,50

33

En la ficha de un alumno la opción buscar es

la última de las opciones, cuando debería ser unas de las más importantes, o al menos

debería estar más visible.

2,50 2,75 5,25

34

Al ir a Varios, y al listar todos los espacios

físicos, la lista no está ordenada según algún

patrón. Solo si conozco lo que busco podre

encontrarlo con facilidad.

3,50 2,75 6,25

Diseño Estético y

Minimalista

35

El botón BUSCAR de los formulario de

búsqueda se muestra activado aún cuando

no se ha ingresado ningún campo de

búsqueda

2,00 3,00 5,00

36

Al entrar en la sección ALUMNOS luego de

buscar alguno, se presenta un listado de

opciones en la parte izquierda que no

muestran ningún un orden u organización,

todas las opciones se encuentran al mismo

nivel

3,25 3,50 6,75

37 En Unidades académicas y actas los

combobox se ven superpuestos. 1,75 2,75 4,50

38 Tamaño de las letras de menú (azules) son

muy pequeñas y pierden su efecto de guía. 3,00 3,25 6,25

39

Las opciones del menú lateral no parecen

botones, son simplemente un lista de texto,

algunos con links otros desactivados. Como

metáfora sería mejor que fueran botones y

no simplemente un texto plano.

2,75 3,25 6,00




Principio de


Diseño Estético y

Minimalista 40

Al listar todos los alumnos o todos los

profesores, todos aparecen en una sola

página, debería separarse quizás por

abecedario o simplemente por paginas.

Debería tener un filtro.

2,75 3,25 6,00

Ayuda a los

Usuarios a

Reconocer,

Diagnosticar y

Recuperarse de

Errores

41 No se manejan con mensajes entendibles los

errores o fallas de conexión con el servidor 3,75 3,25 7,00

42

El campo RUT no se valida, se puede

ejecutar la búsqueda ingresando el RUT con

dígito verificador aún cuando el mensaje

pide que no se ingrese de esa manera, y el

mensaje que se obtiene es que no se

encontraron coincidencias.

3,25 3,50 6,75

Ayuda y

Documentación 43 No posee ningún tipo de ayuda. 3,75 3,75 7,50

Como ya se ha dicho, es notable la gran cantidad de problemas encontrados, además del alto nivel de las

calificaciones, lo cual se ve reflejada en la Tabla 6.18 que se muestra más adelante. Ésta corresponde al ranking de

los problemas más críticos identificados por la evaluación heurística (calificaciones sobre 6, inclusive), que posee un

total de 23 problemas de usabilidad.

6.2.1.1.4. Análisis de Resultados

De manera unánime y con una calificación promedio ocho, el problema de usabilidad más crítico

corresponde a la inexistencia de una opción de cierre de sesión. Esto se justifica, sin duda, por el nivel de seguridad

que deben poseer los usuarios al ingresar a un sistema en el que realizan transacciones que afectan su integridad y/o,

en algunos casos, la integridad de terceras personas. Sin esta opción, los usuarios se sienten inseguros.

El segundo problema en la lista de criticidad es el que dice relación con la ayuda y documentación de la

aplicación web. Ésta no dispone de ningún tipo de ayuda por lo que, si el usuario se ve en dificultades, la aplicación

no aconseja absolutamente nada. Esto claramente es crítico ya que, si el usuario desea realizar alguna transacción

importante y no puede llevarla a cabo, simplemente verá fracasada su intención, por lo que su insatisfacción será

obvia en cuanto a la interacción con el sistema.

El siguiente problema en la lista se refiere a la deficiente administración de los mensajes de error. Estos

deberían ser lo suficientemente claros como para hacer saber al usuario su equivocación y ofrecer algún camino

alternativo, situación que claramente no ofrece el Navegador Académico.



Tabla 6.17: Ranking de Problemas por Criticidad


9 No hay opción Cerrar sesión. 8,00

43 No posee ningún tipo de ayuda. 7,50

41 No se manejan con mensajes entendibles los errores o fallas de conexión con el servidor 7,00

12

Inconsistencia opciones menú. Por ejemplo, se muestran 3 opciones, pero al ingresar en

alguna de éstas el link se elimina, no así en otros casos. En otros casos simplemente el

menú se elimina.

6,75

26 No se destacan los vínculos ya visitados 6,75

36

Al entrar en la sección ALUMNOS luego de buscar alguno, se presenta un listado de

opciones en la parte izquierda que no muestran ningún un orden u organización, todas las

opciones se encuentran al mismo nivel

6,75

42

El campo RUT no se valida, se puede ejecutar la búsqueda ingresando el RUT con dígito

verificador aún cuando el mensaje pide que no se ingrese de esa manera, y el mensaje que se obtiene es que no se encontraron coincidencias.

6,75

1 Menú principal poco representativo. No equilibrado. 6,50

21 Al realizar una búsqueda o un "cambio" de los datos (el mail por ejemplo), no se realiza

ninguna pregunta de confirmación de los cambios. 6,50

27 Al listar los alumnos de la carrera (que son muchos), la "leyenda" de los atributos está

ubicada al final de la página, para saber que significa, se debe llegar hasta el final de ésta. 6,50

3 Puntero Mouse no representativo. 6,25

14

El enlace ALUMNOS es poco intuitivo respecto a lo que se espera encontrar que podría

ser opciones sobre los perfiles alumnos; y lo que aparece es simplemente un buscador de

alumnos, por lo que el título del enlace debería especificar directamente "BUSQUEDA

DE ALUMNOS"

6,25

23 Opción Buscar poco visible o no existente (en ciertos casos). 6,25

30 No es posible ingresar a información de profesores si no se ingresa a la opción de

búsqueda de ellos. Se muestran sus nombres en los cursos, pero no como links. 6,25

34 Al ir a Varios, y al listar todos los espacios físicos, la lista no está ordenada según algún

patrón. Solo si conozco lo que busco podre encontrarlo con facilidad. 6,25

38 Tamaño de las letras de menú (azules) son muy pequeñas y pierden su efecto de guía. 6,25

8 Los vínculos Inicio y Volver no se destacan mucho por lo que el usuario los puede pasar

por alto 6,00

15

Al ingresar a la opción CARRERAS, nuevamente aparece un sistema de búsqueda de

carreras; sin embargo la página muestra por default los resultados de una búsqueda que no

he ejecutado; debería ser consistente con la presentación del sistema de búsqueda de

usuarios.

6,00

17 Al ingresar a la "Comparación Malla" de un alumno, [Aprobado] pareciera que fuera un

link (color azul) y no lo es. No así la Clave de la Asignatura. 6,00

28 Búsqueda Alumnos: tecla Enter no habilitada. 6,00

39

Las opciones del menú lateral no parecen botones, son simplemente un lista de texto,

algunos con links otros desactivados. Como metáfora sería mejor que fueran botones y no

simplemente un texto plano.

6,00

40

Al listar todos los alumnos o todos los profesores, todos aparecen en una sola página,

debería separarse quizás por abecedario o simplemente por páginas. Debería tener un

filtro.

6,00



Los problemas que siguen en la lista dejan a la vista la variedad de problemas que se distribuyen por

distintas partes de la aplicación web. Estos contradicen, además, distintos principios de usabilidad. Es posible

concluir que todos estos problemas afectan de manera rotunda el accionar normal de usuarios comunes,

principalmente obstaculizando la navegación y búsqueda de información ya que, a saber de las listas de problemas

anteriores, los usuarios no se acostumbran a la disposición de la información de las páginas, considerando que, en

general, una página se presenta de una forma pero la siguiente ya no es igual, viéndose modificadas las opciones, las

estructuras de los menús, etcétera.

Además, no hay una conexión entre el lenguaje que se ocupa en el sitio y el lenguaje que los usuarios

comunes utilizan, no existan mensajes que guíen al usuario en su navegación o que lo ayuden a recuperarse de

errores, no se maneja de forma clara la retroalimentación de forma de informar al usuario sus posibilidades o

simplemente su estado actual.

En resumen y basándose solamente en esta evaluación heurística, la usabilidad de esta aplicación web

transaccional deja mucho que desear. Sin embargo, para los objetivos de la investigación esto no constituye un

problema; es más, podría considerarse como positivo para la obtención de los resultados, ya que permitirá realizar un

análisis comparativo más detallado de las conclusiones que cada método de evaluación de usabilidad entregue.



6.2.1.2. Pruebas en Papel

Este método de prueba de la usabilidad fue realizado en la Laboratorio de Usabilidad de la Escuela de

Ingeniería Informática. Luego de la firma del acuerdo de confidencialidad (véase Anexo 2), un total de ocho usuarios

representativos comenzaron independientemente con la realización de la evaluación, de forma que el evaluador hacía

una muestra secuencial de los prototipos en papel diseñados previamente, a la vez que cada uno de los usuarios

expresaba sus impresiones respecto de ello. El perfil de los usuarios, el diseño de la prueba y los resultados de esta

evaluación se muestran a continuación.


Los usuarios participantes de esta prueba se adecúan al Perfil de Usuario Novato, que responde a las

siguientes características: experiencia previa en uso del Navegador Académico Perfil Alumno, sin experiencia previa

en uso del Navegador Académico Perfil Jefe de Docencia. Los ocho participantes corresponden a alumnos de la

carrera de Ingeniería Civil Informática, por lo que poseen cierto grado de uso de aplicaciones web transaccionales,

que ayuda también a su adecuación a este perfil.


El proceso de creación de los prototipos en papel se desarrolló a base del sistema que actualmente está en

uso, al igual que con todos los demás métodos de evaluación ejecutados. Así, se desarrolló una suerte de ingeniería

inversa, en la cual, a partir de la aplicación web transaccional, se fueron creando los prototipos en papel para la

futura realización de la prueba con los usuarios representativos.

Se desarrollaron prototipos de variadas páginas de la aplicación web, comenzando por la página inicial, en

la que se muestran las opciones principales que posee el jefe de docencia para llevar a cabo sus objetivos. Luego se

crearon prototipos de las páginas más representativas de cada una de las secciones principales, de manera de hacer

saber a los participantes de la prueba la estructura general del diseño de las páginas, y generando algún tipo de

navegación de forma bastante general.

Las Figura 6.8, a continuación, corresponde al prototipo en papel de la página inicial del Navegador

Académico mediante el perfil jefe de docencia, ya iniciada la sesión mediante su código identificador y contraseña.

Ésta presenta un menú principal en que se disponen las opciones más generales del sistema, categorías que, como se

verá más adelante, no guardan relación con el pensamiento de los usuarios representativos.



Figura 6.8: Prototipo en Papel Página Principal del Navegador Académico

Otro de los prototipos en papel que fue presentado a los usuarios representativos es el que se muestra en la

Figura 6.9. En ésta, es posible apreciar las tres secciones que comúnmente presentan las páginas del Navegador

Académico. En la parte superior, se sitúan los títulos de las páginas junto con el nombre de la aplicación web; la

parte izquierda corresponden al lugar donde se concentran los menús asociadas a cada categoría; finalmente la

sección derecha (la más amplia) muestra la información específica de cada una de las páginas, en este caso, el

resultado de una búsqueda específica de un alumno.



Figura 6.9: Prototipo en Papel Página de Búsqueda de la Sección Alumnos


La principal conclusión que ha entregado el desarrollo de esta evaluación está en torno a la confusión de los

usuarios respecto de la ubicación de las opciones que buscan. El menú principal no ayuda al usuario a organizarse

dentro de la aplicación web transaccional, por el contrario, lo desorienta.

Más allá de lo anterior, los usuarios consideran adecuada la arquitectura de la información de la aplicación,

aunque no de las mejores. Así, se ha permitido confirmar uno de los problemas críticos del ranking de la evaluación

heurística, respecto de la disposición del menú principal, el cual es poco representativo y no equilibrado.

Al igual que con el caso de estudio anterior, los usuarios consideran de baja representatividad la muestra de

los prototipos en papel; la interacción real con el sistema es altamente variable. Por esto, a pesar de evidenciar

algunos pocos problemas generales, no es posible confirmar muchos de los problemas identificados en la evaluación

anterior.



6.2.1.3. Pensamiento en Voz Alta

La evaluación de usabilidad conocida como pensamiento en voz alta fue realizada en el laboratorio de

usabilidad de la Escuela de Ingeniería Informática de la PUCV, con la participación de cuatro usuarios

representativos. Luego de la firma del acuerdo de confidencialidad (véase Anexo 2), se procedió a realizar las

evaluaciones, en donde cada uno de los usuarios debía interactuar con el sistema al mismo tiempo que expresaban

sus impresiones en voz alta. Se almacenaron los archivos que capturaban los movimientos en pantalla y el audio

asociado durante la ejecución de la prueba.


El perfil de los usuarios participantes de esta prueba corresponde al perfil de usuarios novatos, los cuales

poseen la característica de poseer cierta experiencia en el Navegador Académico con su perfil de alumno, mas no con

el perfil jefe de docencia, el cual está en evaluación. Los usuarios representativos corresponden a estudiantes tanto de

la carrera de Ingeniería Civil Informática como de Ingeniería de Ejecución Informática de la Escuela de Ingeniería

Informática de la PUCV.


El desarrollo de esta evaluación ha permitido confirmar algunos de los problemas que se esperaba. Es

destacable, sin embargo y nuevamente, la incomodidad de los usuarios al realizar sus tareas. Estos se veían

relativamente complicados al tener que realizar sus tareas al mismo tiempo que comunicar sus impresiones, lo que

puede que haya influenciado en la realización correcta de sus objetivos.

Dentro de los principales problemas identificados con la realización de este método de prueba de la

usabilidad, se encuentra uno relacionado con la disposición y arquitectura de la información. En específico, la página

principal de un alumno muestra solamente una dirección, que corresponde a la dirección permanente, por lo que si un

alumno posee otra dirección durante el período académico, ésta se encuentra “escondida” en páginas que ameritan

mayor navegabilidad, pero que confunde al usuario por la razón expuesta al principio.

Otro problema de usabilidad también está relacionado con la arquitectura de la información, pero esta vez

un poco más crítico. En general, cuando los usuarios desearon buscar información sobre algún ayudante de ciertas

asignaturas, se encontraron con el problema de que la información de éste se encuentra en la categoría de profesores,

siendo que todos los usuarios buscaron, en su primer intento, en la categoría de alumnos. Claramente existe una

incompatibilidad entre el diseño de la arquitectura de la información y lo que piensan los usuarios.



Otro problema está en la inexistencia de algunas opciones que hacen más eficiente la realización de tareas

para usuarios un poco más experimentos en el uso del sistema. Por ejemplo, respecto de la cantidad de alumnos

reprobados en cierta asignatura, la aplicación no dispone de ningún conteo de esto, solo presenta la lista de los

alumnos y su situación final (aprobado o reprobado), por lo que deben realizar un conteo manual, que claramente

necesita de una cantidad de tiempo mayor.

Además, la realización del pensamiento en voz alta ha permitido obtener conclusiones respecto de la

disposición, organización y consistencia de los menús, que dejan mucho que desear en cuanto a la usabilidad de la

aplicación web. Por ejemplo, la información de las asignaturas de estudio general se encuentra dentro de una de las

categorías principales, pero su opción dentro del menú lateral es muy poco visible, por lo que los usuarios

difícilmente podrán llegar a dicha información.

La Tabla 6.18, a continuación, muestra los problemas de usabilidad identificados con la prueba, ligados a la

realización de las tareas y las impresiones a viva voz que ejecutaron los usuarios.

Tabla 6.18: Problemas Identificados con el Pensamiento en Voz Alta

Número Problema

1 Arquitectura de la información deficiente.

2 Inexistencia de opciones aceleradoras de la interacción.

3 Inconsistencia y baja notoriedad de los menús

4 Baja eficiencia y notoriedad de opciones Volver e Inicio

5 Búsquedas mostradas por defecto confunden al usuario.

6 Nombre poco representativo de algunas opciones.

Es importante recalcar la baja eficiencia de las expresiones a viva voz en cuanto al reconocimiento de

problemas de usabilidad, ya que varios de los usuarios se vieron incómodos, afectando su éxito en las tareas.

Es considerable también que los problemas identificados en la tabla anterior pueden abarcar algunos más

específicos de la lista de problemas de la evaluación heurística, por lo que estos seis problemas pueden verse

proyectados en varios más de dicha lista, al igual que con Prototipo Web de la Cadena de Supermercados.




La interacción constructiva se realizó con la participación de cuatro usuarios representativos adecuados al

perfil que se detalla más adelante. Estos realizaron la interacción con la aplicación web transaccionales de manera

conjunta, es decir, agrupados en parejas. La prueba fue realizada en el laboratorio de usabilidad de la Escuela de

Ingeniería Informática. A continuación se muestran los factores implicados en esta prueba; no se incluye el diseño de

la prueba ya que ésta no necesita de una lista de tareas a ser realizada por los usuarios, ya que estos deben interactuar

con el sistema de forma libre al mismo tiempo de ir expresando sus impresiones a viva voz, de la misma forma que

una conversación.


Este método de prueba de la usabilidad se realizó con la participación de cuatro usuarios representativos,

que se adecúan al Perfil de Usuario Novato, que responde a las siguientes características: experiencia previa en uso

del Navegador Académico Perfil Alumno, sin experiencia previa en uso del Navegador Académico Perfil Jefe de

Docencia. Estos corresponden a alumnos de la carrera de Ingeniería Civil Informática, por lo que poseen cierto grado

de uso de aplicaciones web transaccionales, que ayuda también a su adecuación a este perfil.


El desarrollo de la interacción no estuvo exento de dificultades, debido principalmente a algunos problemas

de conexión que generaron algunas pausas en las pruebas. Sin embargo, esto no afectó la obtención de resultados

satisfactorios respecto de la usabilidad de la aplicación web transaccional, ya que las pruebas finalmente se

desarrollaron de forma completa entregando las conclusiones que se detallan en esta sección.

La Tabla 6.19, a continuación, muestra los problemas de usabilidad identificados mediante la realización de

esta prueba. Se identificaron 17 problemas, que potencialmente representarán a un número superior de problemas al

realizar las comparaciones posteriores, donde se tomará en cuenta la evaluación heurística.

La interacción constructiva ha permitido confirmar varios de los problemas de la evaluación heurística. Los

más importantes están en torno a la desorientación del usuario respecto de su ubicación en las páginas. No logra

identificar el objetivo de las páginas ni la arquitectura de la información, encuentra distintos menús en varias partes,

que a veces comparten opciones y en otras ocasiones no, lo que se ha llamado anteriormente como inconsistencia.

Muchos de los demás problemas de la lista aportan en esta desorientación.



Tabla 6.19: Problemas Identificados mediante la Interacción Constructiva

Número Problema

1 Desorientación del usuario. No conoce el objetivo de las páginas ni

dónde está ubicado.

2 Títulos poco visibles.

3 Listas o páginas muy largas y sin ningún patrón de ordenación.

4 Ineficiencia para volver a páginas anteriores.

5 Tecla Enter no activada para realizar búsquedas.

6 Inconsistencia en opciones de menú. Por ej: 2 “Inicio”

7 Significado de algunas metáforas en lugares poco visibles (final de

la página)

8 Las listas ordenadas no resaltan el patrón de ordenación.

9 Nombre opciones no entendibles. Poco representativos.

10 Replicación de información en listas.

11 Ayuda deficiente para formato de ingreso RUT.

12 Búsquedas mostradas por defecto confunden al usuario.

13 Resultados poco eficientes de algunas búsquedas.

14 Mala elaboración de algunos enlaces del menú principal. Por ej.

parte una palabra es enlace y la otra solo texto.

15 Inadecuada presentación de número de créditos por asignatura.

16 Inexistencia de opción para buscar el histórico de cursos dictados

por un profesor.

17 Manual de ingreso de actas está disponible en una página que no

corresponde.




Los experimentos formales fueron realizados en el laboratorio de usabilidad de la Escuela de Ingeniería

Informática de la PUCV con la participación de cinco usuarios representativos adecuados al perfil que se presenta

más adelante. Luego de la firma del acuerdo de confidencialidad (véase Anexo 2) se procedió a la realización de la

prueba. Fueron almacenados los respectivos videos y documentación necesaria para el posterior análisis. Los perfiles

de usuario, el diseño de la prueba y las conclusiones de la realización de este método de prueba de la usabilidad se

muestran a continuación.


Los usuarios participantes de esta prueba se adecúan al Perfil de Usuario Novato, que responde a las


en uso del Navegador Académico Perfil Jefe de Docencia. Los cinco participantes corresponden a alumnos de la

carrera de Ingeniería Civil Informática, por lo que poseen cierto grado de uso de aplicaciones web transaccionales,

que ayuda también a su adecuación a este perfil.


El diseño de la lista de tareas se realizó a base de los resultados de la evaluación heurística realizada

anteriormente. Así, con la realización de este método de prueba de la usabilidad, se espera confirmar algunos de los

problemas más críticos que entregó dicha evaluación, por lo menos.

Los problemas de usabilidad más críticos según el ranking de la evaluación heurística disponible en la Tabla

6.16 son, como dijo en su momento, bastantes variados y contradicen distintos problemas de usabilidad. Con el

objetivo de buscar alguna lista de tareas que pueda llevar a la confirmación de estos problemas, se desarrollarán

tareas relacionadas con la búsqueda de información en distintas partes del sitio. De esta forma, será posible evaluar la

deficiente presentación de muchos de los menús de cada página, la baja representatividad del menú principal, la

inconsistencia en algunas opciones, la mala administración de los mensajes de error, entre muchos de los otros

problemas críticos que, sin duda, afectan de manera directa la realización normal y eficiente de tareas en la

aplicación web transaccional.

La definición de las tareas para los experimentos formales se muestra en la Tabla 6.20, a continuación. En

ella, se muestra el tiempo máximo, el caso de éxito y de error asociado a cada una de las tareas. El documento con la

lista detallada de las tareas que se presentó a los usuarios está disponible en el Anexo 7.



Tabla 6.20: Definición de Tareas para Experimentos Formales

Tarea N° 1

Descripción Búsqueda de información específica sobre un alumno.


Caso Éxito Encontrar e ingresar la información.


Tarea N° 2

Descripción Búsqueda de información específica sobre un ayudante.




Tarea N° 3

Descripción Búsqueda de información específica sobre la escuela de agronomía y sus

asignaturas.




Como se puede apreciar en la tabla, la prueba de usabilidad fue dividida en tres tareas generales. La primera

dice relación con la búsqueda de información de un alumno específico. Mediante esta tarea será posible evaluar la

interacción del usuario con el sistema ejecutando búsquedas y analizando los resultados de ella, además de la

organización de la información, estableciendo cierta navegación que permitirá evaluar la influencia de algunos de los

problemas nombrados anteriormente.

La segunda tarea tiene como objetivo encontrar información sobre un ayudante específico. Se asemeja un

poco a la tarea anterior en cuanto a los problemas que potencialmente confirmará, pero además se podrá evaluar, de

cierta forma, la arquitectura del diseño de la aplicación.



La tercera y última tarea de la lista de estos experimentos formales propone la búsqueda de información

sobre la escuela de agronomía y las asignaturas disponibles para sus alumnos. Mediante esta tarea se buscará evaluar

otro camino de navegación en el cual también deberán realizar algunas transacciones con el fin de buscar la

información solicitada, entre varios otros de los problemas de usabilidad encontrados con el método de inspección

realizado en la etapa anterior.


Luego de haber realizado los experimentos formales con los cinco usuarios representativos, prosigue el

análisis de los resultados. La Tabla 6.21, a continuación, presenta los porcentajes de éxito asociados a cada tarea,

además del tiempo promedio que tomaron los usuarios en realizar exitosamente sus tareas (el promedio de tiempos

no considera los usuarios que no lograron realizar la tarea).

Tabla 6.21: Resultados del Experimento Formal





La primera conclusión que se puede obtener, si se recuerda el pensamiento en voz alta realizado

anteriormente, es que la expresión en voz alta de las impresiones de los usuarios mientras interactúan con el sistema

efectivamente afecta la realización normal de las tareas. Los usuarios realizaron las tareas sin preocuparse de otra

cosa que no sea el desarrollo efectivo de ellas. Por lo mismo, el análisis de los tiempos que los usuarios demoraron n

llevar a cabo con éxito los tareas es claramente representativo.

La tarea número uno pudo realizarse con éxito por todos los usuarios. Sin embargo, las dos siguientes tareas

no lograron igual resultado. La tarea número dos no pudo ser realizada por uno de los usuarios, el cual representa, de

cierta forma, a la mayoría de los demás, ya que a casi todos les fue relativamente dificultoso llegar a la información

que debían obtener. Esto se debe a la mala arquitectura de la información de la aplicación web, que no es acorde a la

estructura que los usuarios poseen de ésta. Específicamente, la información de los ayudantes se encuentra en la

categoría de profesores, siendo que la gran mayoría de los usuarios buscó primero en la categoría de alumnos.

Además, a pesar que al buscar en alumnos se encuentra a esta persona (ayudante), la aplicación no ofrece encontrar

información asociada a su ayudantía si no es ingresando por la categoría de profesores.



La tercera y última tarea es la que entregó los resultados más bajos en cuanto al porcentaje de éxito, lo que,

sin duda, está asociado a los problemas de usabilidad que posee la aplicación. La razón principal es, nuevamente, la

mala arquitectura de la información del sitio. A esto hay agregar la deficiencia en cuanto a los menús, ya sea por la

inconsistencia en la muestra de ellos en las distintas páginas como también por la presentación inadecuada de los

opciones. Algunos de los usuarios llegaron a la página donde se encontraba el enlace que guiaba a sus resultados,

pero no captaron la opción por las razones anteriormente nombradas.




Este método de prueba de la usabilidad fue realizado por trece usuarios representativos, que corresponden a

todos los participantes de las pruebas anteriores que ameritaban una interacción con el sistema: el pensamiento en

voz alta, la interacción constructiva y los experimentos formales. Los usuarios, luego de realizar estas pruebas,

fueron sometidos a un cuestionario escrito y a algunas preguntas un poco más informales, de la forma de una

entrevista. Los perfiles de usuario, el diseño de la prueba y los resultados se muestran a continuación.


El perfil de los usuarios es el mismo que el de las pruebas nombradas en el párrafo anterior: Perfil de

usuarios novato, con experiencia en el Navegador Académico perfil Alumno, pero sin experiencia en el perfil que se

evalúa en esta ocasión.


Las preguntas que se realizaron para evaluar algunos aspectos de la aplicación web se basaron en los

resultados de la evaluación heurística realizada anteriormente. La Tabla 6.22, a continuación, presenta el diseño de

las preguntas realizadas en el cuestionario, junto con el significado de las notas máxima y mínima.








6 El mecanismo de búsqueda del sitio es: Muy ineficiente Muy eficiente

7 ¿Cómo evalúa su experiencia como usuario del sitio? Muy desagradable Muy agradable



Como se puede notar en la tabla, las preguntas son muy similares a las desarrolladas en el cuestionario del

prototipo de sistema web de la cadena de supermercados. La similitud tiene su justificación, ya que el Navegador

Académico, al igual que el caso de estudio anterior, posee los ya nombrados problemas de arquitectura de la

información y dificultad por encontrar los objetivos, entre variados otros problemas que, en conjunto, hacen que la

interacción del usuario con el sistema no sea ciertamente satisfactoria. Mediante este cuestionario, será posible

conocer si los usuarios subjetivamente confirman estos problemas entregados por la evaluación heurística.

En el Anexo 10 está disponible el documento con el cuestionario presentado a cada uno de los usuarios

participantes de las pruebas.


El desarrollo de esta técnica de interrogación ha entregado los resultados que se muestran en la Tabla 6.23.

En ella se encuentran dispuestos los promedios con que los usuarios calificaron la aplicación web transaccional en

evaluación.

Tabla 6.23: Promedios de las Respuestas al Cuestionario

Número Pregunta Nota Menor (1) Promedio

(Escala de 1 a 7) Nota Mayor (7)

1 La disposición de la información en el sitio

es: Muy difusa 3,8 Muy clara



4 ¿El sitio se preocupa de la satisfacción del

usuario? Nunca 3,1 Definitivamente


6 El mecanismo de búsqueda del sitio es: Muy ineficiente 4,0 Muy eficiente

7 ¿Cómo evalúa su experiencia como usuario

del sitio?

Muy

desagradable 3,8 Muy agradable



La tabla muestra que los promedios de las respuestas de los usuarios no son muy alentadores. La pregunta

con la mejor evaluación (aunque no necesariamente buena), corresponde a la relacionada con la funcionalidad de la

aplicación web. Los usuarios consideraron que la funcionalidad, por lo menos, es mejor que las características de la

aplicación, por lo que, de partida, hay una insatisfacción en la interacción.

El bajo nivel de las calificaciones que los usuarios asignaron a las distintas preguntas indica que,

subjetivamente, los usuarios no se agradaron con el sistema. Esto queda demostrado directamente con la pregunta

número cuatro, que obtuvo el promedio de respuesta más bajo, indicando que la aplicación no se preocupa de la

experiencia del usuario y, por lo tanto, los usuarios fueron insatisfechos.

Se puede decir que, en general, los usuarios consideraron deficiente el sitio. La disposición de la

información era un problema identificado con la evaluación heurística, y que esta evaluación permitió confirmar. Lo

mismo con la navegabilidad y diseño del sitio, aunque en menor grado que el que se esperaba. Esto porque el

promedio respecto de la consistencia no es tan bajo como los demás, aunque igualmente no es una calificación

buena.



6.2.1.7. Ordenamiento de Tarjetas

El ordenamiento de tarjetas fue realizado tanto en el laboratorio de usabilidad de la Escuela de Ingeniería

Informática de la PUCV como en lugares de estudio de la misma escuela. Fue desarrollado con la participación de

siete usuarios representativos.


El perfil de los usuarios participantes de esta prueba se corresponde al de Usuario Novato, que posee las


en uso del Navegador Académico Perfil Jefe de Docencia. Los participantes corresponden a alumnos de la carrera de

Ingeniería Civil Informática, por lo que poseen cierto grado de uso de aplicaciones web transaccionales, que ayuda

también a su adecuación a este perfil.


Para el diseño de la prueba fue necesario un análisis del sistema actual, identificando las categorías

principales, sub-categorías, etcétera. Así, se realizó una especie de ingeniería inversa, basándose en el sistema actual

y, desde ahí, diseñando las tarjetas. Se concluyó con la identificación de 27 tarjetas, las cuales se muestran en la

Tabla 6.24, a continuación.

Tabla 6.24: Agrupación Actual de las “Tarjetas” del Navegador Académico

Alumnos Carreras Profesores Unidades

Académicas Asignaturas Varios

Buscar Alumno Buscar Carrera Buscar Profesor Ficha Unidades

Académicas

Buscar

Asignatura Reportes

Ficha Alumno Ficha Carrera Ficha Profesor Programación de

Docencia Ficha Asignatura Encuestas

Malla Curricular Ficha Ayudante Prestación de

Servicios Espacios Físicos

Alumnos Carrera Cursos Dictados Estudios

Generales

Actividades

Académicas

Actas

Legislativas



En la tabla se muestran las opciones a las cuales fue posible acceder debido a los permisos necesarios. En el

menú principal, por ejemplo, existe un par de opciones que no se consideraron para la confección de las tarjetas, ya

que no se conoce su funcionalidad ni las sub-categorías que posee.

El orden que se muestra en la tabla es el que posee el sistema en la actualidad, es decir, ese es el orden que

deberían desarrollar los usuarios representativos si es que la aplicación se corresponde con lo que los usuarios

piensan, siendo cada una de las celdas de la tabla una tarjeta a ordenar.


El desarrollo de esta evaluación ha permitido encontrar problemas de usabilidad respecto de la arquitectura

de la información en el diseño de la aplicación web transaccional que se evalúa.

Los usuarios representativos se inclinaron, en general, por un diseño muy distinto al que propone la

aplicación web transaccional. La actual aplicación muestra un menú principal en el que se muestran las distintas

categorías del sitio: alumnos, carreras, profesores, unidades académicas, asignaturas y varios. Sin embargo, la visión

de los usuarios es muy distinta a esta arquitectura de la información del diseño de la aplicación web transaccional.

La mayoría de los usuarios ubica a las unidades académicas como la categoría general, que contiene a todas

las demás tarjetas. Así, los alumnos, profesores y carreras vendrían a ser, según los usuarios, sub-categorías de

unidades académicas.

Otro aspecto importante es la disposición de las asignaturas. Algunos usuarios las ubican en relación directa

con los profesores y no al mismo nivel, como propone el sistema actual. Otro grupo de usuarios la ubica como parte

de carreras, desplegando en ella toda la información de las asignaturas.

Finalmente, otra discordancia está en la ubicación de la información de los ayudantes. La aplicación web la

ubica dentro de la categoría de profesores, mientras que los usuarios la ubican ya sea como parte de la información

de los alumnos o como información de cada una de las asignaturas. Este corresponde a uno de los problemas

causantes de varias dificultades en las pruebas con listado de tareas, en las cuales se pedía encontrar información de

un ayudante específico, situación que complicó bastante a los usuarios representativos.




En esta sección se realizarán las distintas comparaciones entre los métodos de evaluación desarrollados

sobre este segundo caso de estudio, correspondiente al Navegador Académico de la PUCV, perfil jefe de docencia.

Se comienza con un análisis de los tiempos involucrados en cada uno de estos métodos de evaluación, para luego

analizar los problemas identificados. Este análisis de resultados, junto con el desarrollado en el caso del Prototipo

Web de la Cadena de Supermercados, será la base para la futura propuesta de la metodología de evaluación de

usabilidad para aplicaciones web transaccionales.

6.2.2.1. Tiempos Involucrados

Al igual que en el análisis de los resultados del primer caso de estudio, los tiempos involucrados en el

desarrollo de los métodos de evaluación de usabilidad se ha dividido en tres partes: preparación, proceso y análisis.

Se realizará un análisis comparativo de cada una de estas tres partes, comparando además con los resultados del caso

de estudio anterior, de forma de evaluar si los resultados son similares, para así poder establecer consistentemente las

conclusiones futuras respecto de la metodología de evaluación de usabilidad.

En primer término, se analizarán los tiempos involucrados en la primera etapa, de preparación. Para el caso

de la evaluación heurística, la experiencia es muy similar a la del caso de estudio anterior. Es más, fue un poco

menor, debido a que el pequeño informe con las instrucciones y los principios de usabilidad a considerar en la

evaluación (véase Anexo 1) ya estaba desarrollado, por lo que se debió realizar solo algunos pocos cambios.

Analizando la misma etapa, pero ahora enfocándose en los métodos de prueba de la usabilidad, en primer

lugar, las pruebas en papel ameritaron el tiempo necesario para evaluar el sistema actual y crear los prototipos en

papel, lo cual demoró aproximadamente un par de horas. La misma cantidad de tiempo fue necesaria para la

preparación del ordenamiento de tarjetas. Las técnicas de interrogación, por su lado, necesitaron de un poco menos

de tiempo dentro de esta etapa, aproximadamente una hora, debido a la experiencia adquirida en la realización de la

prueba y la similitud con los objetivos del cuestionario realizado para el primer caso del Prototipo Web de la Cadena

de Supermercados.

Pasando a los métodos de prueba que desarrollan una interacción directa del usuario con el sistema,

nuevamente el pensamiento en voz alta junto con la interacción constructiva presentaron un tiempo bajo de

preparación, de aproximadamente 30 minutos, principalmente dedicado a la recolección de usuarios representativos.

Por el contrario, los experimentos formales necesitaron más tiempo para su preparación, enfocado a la creación del

listado de tareas para que los usuarios limiten la interacción. El tiempo aproximado para la preparación de esta última

fue de 2 horas.



Respecto del proceso mismo de desarrollo de los métodos de evaluación de usabilidad, la evaluación

heurística es la que más tiempo consideró, principalmente por la coordinación de los tiempos de cada uno de los

evaluadores. En total, considerando tiempo operativo, la evaluación demoró un tiempo aproximado de 15 horas.

El tiempo de los métodos de prueba para realizar el proceso mismo de la evaluación es claramente más bajo

que para la evaluación heurística. Las técnicas de interrogación demoraron muy poco tiempo, ya que los usuarios

solo deben contestar algunas preguntas generalmente cortas, por lo que el tiempo total aproximado fue de 30

minutos. Las pruebas en papel y el ordenamiento de tarjetas también tomaron poco tiempo: 1 hora y 1,5 horas,

aproximada y respectivamente. Finalmente, son los métodos de interacción directa con el sistema los que ameritan

más tiempo al considerar sólo los métodos de prueba de la usabilidad, como muestra la Tabla 6.25 más adelante.

Para finalizar el análisis de los tiempos involucrados, la parte precisamente de análisis también establece

algunas diferencias entre los métodos. Se destaca a los experimentos formales como la más demorosa en esta parte.

La Tabla 6.25, a continuación, presenta los tiempos involucrados en cada una de las etapas.

Tabla 6.25: Tiempos de Desarrollo de los Métodos de Evaluación por Etapas

Método de Evaluación Preparación Proceso Análisis TOTAL

Evaluación Heurística 15 minutos 15 horas 2 horas 17:15 hrs.

Pruebas en Papel 2 horas 1 hora 1,5 horas 04:30 hrs.

Pensando en Voz Alta 30 minutos 1,5 horas 2,5 horas 04:30 hrs.

Interacción Constructiva 30 minutos 1,5 horas 2,5 horas 04:30 hrs.

Experimentos Formales 2 horas 1,5 horas 3 horas 06:30 hrs.

Técnicas de Interrogación 1 hora 30 minutos 1 hora 02:30 hrs.

Ordenamiento de Tarjetas 2 horas 1,5 horas 2 horas 05:30 hrs.

Al igual que lo ocurrido con el Prototipo Web de la Cadena de Supermercados, se desatan diferencias

marcadas en cada una de las etapas. En la primera, por ejemplo, la evaluación heurística, el pensamiento en voz alta

y la interacción constructiva están bastante por debajo de los otros métodos de evaluación. En la etapa intermedia,

donde se realiza el proceso mismo, la evaluación heurística está al otro extremo: demora mucho más tiempo que los

demás. En la última etapa hay un poco más de igualdad en los tiempos, aunque relativamente inclinada la balanza

hacia las pruebas de interacción directa con el sistema, siendo los experimentos formales los de mayor tiempo.

La tabla muestra, además, los tiempos totales que se invirtieron en la realización de los distintos métodos de

evaluación. Si realizamos un ranking, este difiere un poco respecto del caso de estudio anterior, pero mantiene una

estructura similar, considerando los métodos más comparables. El ranking se muestra a continuación, ordenados

desde el de menor tiempo de realización hasta el mayor.



1. Técnicas de Interrogación.

2. Pruebas en Papel.

3. Pensamiento en Voz Alta.

4. Interacción Constructiva.

5. Ordenamiento de Tarjetas.

6. Experimentos Formales.

7. Evaluación Heurística.

Todo este análisis de los tiempos, las tablas y rankings asociados servirán como base para la futura

propuesta de la metodología de evaluación de usabilidad para las aplicaciones web transaccionales.

Finalmente, la Tabla 6.26, a continuación, muestra los tiempos involucrados en las distintas etapas de los

métodos de evaluación, por escalas de tiempo. La escala es la misma que para el primer caso de estudio.

Tabla 6.26: Tiempos Involucrados en las Etapas de los Métodos de Evaluación por Escala de Tiempo


Evaluación Heurística Muy Bajo Muy Alto Medio

Pruebas en Papel Medio Bajo Bajo

Pensamiento en Voz Alta Muy Bajo Bajo Medio

Interacción Constructiva Muy Bajo Bajo Medio

Experimentos Formales Medio Bajo Medio


Ordenamiento de Tarjetas Medio Bajo Medio

Escala:


Bajo: 1:00 a 1:59 hrs.

Medio: 2:00 a 3:59 hrs.

Alto: 4:00 a 6:00 hrs.




6.2.2.2. Problemas Identificados

Los problemas identificados por los distintos de métodos de evaluación de usabilidad se tornan como uno de

los factores importantes a considerar para realizar las comparaciones necesarias para llegar al objetivo de la presente

investigación: establecer una metodología de evaluación de usabilidad para aplicaciones web transaccionales.

Para este análisis se considerará como punto de referencia a la evaluación heurística, la cual identificó un

total de 43 problemas de usabilidad, de los cuales 22 forma parte de la lista de problemas críticos (calificación

promedio desde seis hacia arriba).

Para comenzar, hay que destacar que todos los métodos de prueba permitieron, de cierta forma, confirmar

algunos de los problemas de usabilidad que se presentaron en las listas de la evaluación heurística. Es más, todos

identificaron problemas que son parte de la lista de problemas críticos. Para el análisis es necesario realizar una

separación dentro de los métodos de prueba: evaluaciones sin interacción con la aplicación (pruebas en papel,

técnicas de interrogación y ordenamiento de tarjetas) y evaluaciones de relación directa con la aplicación web

transaccional (pensamiento en voz alta, interacción constructiva y experimentos formales).

Para el primer caso, las evaluaciones no entregan problemas de usabilidad en gran cantidad y detalle. Su

realización permite obtener resultados más bien generales. Respecto del caso de estudio, las pruebas en papel

permitieron obtener resultados de la usabilidad en torno a la arquitectura de la información. Los usuarios

consideraron que el menú principal es poco representativo, por ejemplo.

Las técnicas de interrogación, por su lado, permitieron obtener algunos pocos más problemas que el método

de prueba anterior. Esto depende, claramente del buen diseño de la prueba, que debe saber rescatar la información

que se quiere y cómo se quiere. En resumidas cuentas, el cuestionario diseñado permitió confirmar, de manera

subjetiva, que la disposición de la información es deficiente, que la navegabilidad que ofrece el sitio no es de las

mejores y que el diseño no es consistente. Además, los usuarios expresaron que no se sintieron satisfechos durante la

interacción, comunicando tajantemente que la aplicación no considera de la forma adecuada a la usabilidad como

uno de sus atributos básicos.

El ordenamiento de tarjetas también logró confirmar problemas de usabilidad. Por la naturaleza de este

método de prueba, los resultados están en torno a la arquitectura de la información en cuanto al diseño de la

aplicación web transaccional. El modelo mental de los usuarios no coincide con el modelo que presenta el sistema

web, identificando elevadas diferencias, que influyen directamente en la interacción de los usuarios con la

aplicación. El menú principal, nuevamente, es considerado poco representativo.



Ahora bien, los métodos de prueba que realizan directamente una interacción del usuario con la aplicación

que entregan más problemas de usabilidad y que permiten una comparación directa con la evaluación heurística son

el pensamiento en voz alta y la interacción constructiva. La Tabla 6.27, a continuación, corresponde a la lista de los

problemas de usabilidad identificados por la evaluación heurística; con una cruz se marcan los que fueron

confirmados por el método de prueba respectivo. Además las filas sombreadas corresponden a los problemas críticos.

Tabla 6.27: Problemas de Evaluación Heurística Confirmados por Métodos de Prueba


Voz Alta

Interacción

Constructiva

Experimentos

Formales

2

1 X X X

2

3

X

4

X

5

6

X

7

X

3

8 X X X

9

10

4

11

X

12 X X

13

14

15 X X

16

17

5

18

X

19 X

20

21

6

22

X

23

24

25

26

27

X

7

28 X X

29

30

31

32

33

34



Tabla 6.27 (continuación): Problemas de Evaluación Heurística Confirmados por Métodos de Prueba


Voz Alta

Interacción

Constructiva

Experimentos

Formales

8

35

36

37

38

X

39

40

X X

9 41

42

10 43

Problemas Totales

Confirmados 6 (14%) 14 (33%) 4 (9%)

Problemas Críticos

Confirmados 5 (23%) 8 (36%) 4 (18%)

Otros Problemas 2 6 2

TOTAL 13 28 10

A pesar de que los dos métodos de prueba que se muestran en la tabla confirmaron los problemas más

generales que se identificaron (mala disposición de la información, inconsistencia del diseño), al realizar este análisis

más específico se desatan las diferencias. Claramente, el método de prueba que permitió confirmar más problemas de

usabilidad es la interacción constructiva, tanto problemas generales como los problemas más críticos. Así, toma

ventaja respecto del pensamiento en voz alta al igual que con el primer caso de estudio, repitiendo su eficacia. Así, se

puede establecer una lejanía en las características de ambos métodos que no se había dado para el análisis temporal.

Los experimentos formales, por su parte, son los únicos métodos que poseen una lista de tareas para que los

usuarios interactúen limitadamente sobre el sistema, lo cual, de cierta forma, podría tomarse como una ventaja que lo

desmarca de los otros métodos, por la objetividad de la prueba que no poseen los demás. Los experimentos formales

confirmaron los problemas más críticos y generales de la aplicación. La ventaja determinante de este método de

prueba es su alto nivel de objetividad, permitiendo realizar análisis estadísticos de los tiempos involucrados en las

tareas, cuando sea necesario.

Satisfactoriamente, los resultados obtenidos mediante esta aplicación son muy similares a los asociados al

primer caso de estudio, el Prototipo Web de la Cadena de Supermercados, por lo que las conclusiones que se

presentarán más adelante tienen una base sólida en la cual argumentarse.



6.3. Particularización de los Métodos de Evaluación de Usabilidad sobre Aplicaciones

Web Transaccionales

En este subcapítulo se realizará un análisis de las características específicas de los métodos de evaluación de

usabilidad en aplicaciones web transaccionales. Así, a partir de las postulaciones generales de las evaluaciones, se

desarrollará un marco característico enfocado sólo en este tipo de aplicaciones, basándose en la experiencia que se ha

obtenido mediante el desarrollo de los métodos de evaluación en los casos de estudio presentados en las secciones

anteriores.

La Tabla 6.28, que se muestra a continuación, corresponde a las ventajas y desventajas de los métodos de

evaluación de usabilidad en aplicaciones web transaccionales. Ésta toma como referencia la Tabla 5.4, la cual

presenta las ventajas y desventajas de los métodos de evaluación en forma general. De esta forma, algunas

afirmaciones se mantienen, otras se eliminaron y algunas otras se agregaron.

Tabla 6.28: Ventajas y Desventajas de los Métodos de Evaluación de Usabilidad en Aplicaciones Web Transaccionales


Evaluación Heurística

Fácil de conducir.

Económica.

Permite la identificación de

muchos problemas (mayores y

menores).

No se consume tiempo de los usuarios.

Se pueden pasar por alto

problemas específicos del

dominio de la aplicación.

Pruebas en Papel Relativamente Rápido.

Económico.

No representa de forma completa

y real el diseño y la interacción

con el sistema, no permitiendo

evaluar transacciones ni

escenarios de navegación.

Altamente subjetivo.

Pensando en Voz Alta




Bajo tiempo en relación a otros

métodos de interacción directa

con la aplicación.

El pensamiento en voz alta

interfiere la conducta normal del

usuario.

No se obtiene información

cuantitativa.



Tabla 6.28 (continuación): Ventajas y Desventajas de los Métodos de Evaluación de Usabilidad en Aplicaciones Web

Transaccionales


Interacción Constructiva

Se encuentran muchos

problemas de usabilidad.




Bajo tiempo en relación a otros

métodos de interacción directa

con la aplicación.

La interacción de los usuarios no

representa el uso del sistema en

condiciones normales.

No se obtiene información cuantitativa.

Experimentos Formales

Único método realmente

objetivo.

Recolección de información

cuantitativa.

Alta inversión de tiempo en

relación a otros métodos de

interacción directa con la aplicación.

No entrega información sobre las

razones de los problemas.

Técnicas de

Interrogación

Entrega información

cuantitativa y cualitativa.

Simple.

Económica.

Fiabilidad de la información

subjetiva.

Ordenamiento de

Tarjetas

Simple

Económico.

Eficiente en cuanto a la

información de diseño.

No permite evaluar transacciones

ni escenarios de navegación.

La evaluación heurística destaca por su gran capacidad para encontrar problemas, mientras que su

desventaja está en la influencia del dominio de la aplicación. Los evaluadores pueden tener mucha experiencia en

este tipo de evaluaciones, pero si no conocen las reglas del negocio, probablemente varios problemas de usabilidad

no podrán ser identificados.

Otra ventaja importante de la evaluación heurística es su facilidad de llevar a cabo, en comparación con los

otros métodos de inspección de usabilidad. En la presente investigación no se consideraron estas otras evaluaciones,

pero la literatura eleva las capacidades de la evaluación heurística por sobre las otras, además de ser el método de

inspección más utilizado para la identificación de problemas.



Respecto de los métodos de prueba, las pruebas en papel, las técnicas de interrogación y el ordenamiento de

tarjetas destacan por su bajo costo para llevarse a cabo. Esto se debe a que los recursos necesarios para realizarlos no

van más allá de papeles y lápices; no dependen de máquinas computacionales. Sus desventajas van por el mismo

lado. Al no realizar interacciones directas con la aplicación web transaccional, la información se torna ciertamente

subjetiva. De esto se pueden liberar las técnicas de interrogación si es que son realizadas luego que los usuarios

hayan interactuado con la aplicación mediante el desarrollo de otro de los métodos de prueba, como ocurrió en la

presente investigación.

Ahora bien, resta comentar las características de los métodos de prueba que realizan una interacción directa

del usuario con la aplicación: pensamiento en voz alta, interacción constructiva y experimentos formales. Es posible

realizar algunas comparaciones cruzadas entre dichos métodos, ya que comparten algunas características.

En primer término, el pensamiento en voz alta y la interacción constructiva poseen dentro de sus ventajas la

posibilidad de obtener resultados con la participación de pocos usuarios representativos. Esto tiene su fundamento

por la expresión de la impresiones de los usuarios mientras realizan la interacción. Para los casos de estudio, sin

embargo, la interacción constructiva saca más provecho de este aspecto, ya que los usuarios trabajan en parejas, por

lo que la fluidez de los comentarios es mayor; en consecuencia, mayor cantidad de problemas de usabilidad. La

experiencia, además, concluyó que el pensamiento en voz alta incomoda relativamente a los usuarios, aunque

igualmente se obtienen resultados.

Un factor importante también está en el tiempo: el pensamiento en voz alta y la interacción constructiva

ameritan menor cantidad de tiempo que el otro método de interacción directa con la aplicación web, los

experimentos formales.

Siguiendo con las características comunes de los dos métodos expuestos en el párrafo anterior, ambos

destacan, también, porque identifican las razones de los problemas. Esto es fundamental. Esta ventaja es la que

permite que, en las tablas comparativas de los métodos desarrolladas en secciones anteriores, se confirmen varios

problemas de usabilidad respecto de las evaluaciones heurísticas.

Los experimentos formales, por su parte, se basan una lista de tareas que los usuarios deben desarrollar

durante la interacción con la aplicación web transaccional. Por ello, los experimentos formales permiten un análisis

cuantitativo, llegando a un nivel de objetividad que es irrevocable. Este análisis cuantitativo es el que hace que los

experimentos formales consuman un poco más de tiempo que los demás métodos de prueba. Con el objetivo de

realizar un análisis integrador de los resultados obtenidos durante la experimentación y que permiten generalizar las

características de los métodos de evaluación sobre las aplicaciones web transaccionales, es que la Tabla 6.29, a

continuación, muestra los tiempos involucrados en las distintas etapas, a base de las tablas 6.13 y 6.26.



Tabla 6.29: Tiempos de los Métodos de Evaluación de Usabilidad en Aplicaciones Web Transaccionales


Evaluación Heurística Muy Bajo Muy Alto Bajo/Medio

Pruebas en Papel Bajo/Medio Muy Bajo/Bajo Bajo

Pensando en Voz Alta Muy Bajo Bajo/Medio Medio

Interacción Constructiva Muy Bajo Bajo/Medio Medio

Experimentos Formales Medio Bajo/Medio Medio/Alto


Ordenamiento de Tarjetas Bajo/Medio Bajo Medio

Los valores de la tabla responden a la misma escala de tiempo utilizada para los casos anteriores:


Bajo: 1:00 a 1:59 hrs.

Medio: 2:00 a 3:59 hrs.

Alto: 4:00 a 6:00 hrs.


Finalmente, la Tabla 6.30, a continuación, presenta las características sobresalientes de cada uno de los

métodos, de forma de generar un pequeño acercamiento a los factores más influyentes para la próxima postulación

de la metodología de evaluación de usabilidad para aplicaciones web transaccionales.

Tabla 6.30: Características Sobresalientes de los Métodos de Evaluación de Usabilidad

Método de Prueba Características

Evaluación Heurística Identificación de muchos problemas. Único método de inspección analizado.

Pruebas en Papel No permite evaluar transacciones ni escenarios concretos de navegación.

Pensando en Voz Alta Interferencia del pensamiento en voz alta en la conducta normal del usuario.

Interacción Constructiva Se encuentran muchos problemas en toda la aplicación. Bajo tiempo en relación

a otros métodos de interacción directa con la aplicación.

Experimentos Formales Objetividad. Recoge Información cuantitativa. Alta inversión de tiempo.

Evaluación enfocada a escenarios.

Técnicas de Interrogación Simple y económica. Información cuantitativa y cualitativa. Buen complemento

para la obtención de información subjetiva.

Ordenamiento de Tarjetas Información sobre el diseño. No permite evaluar transacciones ni escenarios de

navegación.



7. METODOLOGÍA DE EVALUACIÓN DE USABILIDAD PARA APLICACIONES

WEB TRANSACCIONALES

Este capítulo tiene como objetivo presentar la metodología de evaluación de usabilidad para las aplicaciones

web transaccionales. El análisis de los resultados de cada uno de los métodos de evaluación de usabilidad

desarrollados sobre los dos casos de estudio anteriores (Prototipo Web de Cadena de Supermercados y Navegador

Académico PUCV) y los análisis comparativos entre ellos, han permitido llegar a la propuesta de la metodología que

se muestra más adelante.

Posterior a ello, se realizará la validación de la propuesta mediante un nuevo caso de estudio, que será el

Sistema de Biblioteca de la PUCV, para finalmente desarrollar los análisis que permitan concluir si la propuesta es

realmente eficiente y adecuada para las aplicaciones web transaccionales.

7.1. Propuesta de Metodología de Evaluación de Usabilidad

La propuesta de la metodología de evaluación de usabilidad para aplicaciones web transaccionales

claramente deberá incluir, por lo menos, uno de los métodos de inspección y uno de los métodos de prueba de

usabilidad, tal como recomiendan muchos autores ligados al tema.

Así, la evaluación heurística, que fue el único método de inspección de usabilidad considerado para los

análisis por su indiscutida supremacía en la identificación de problemas de cualquier tipo sobre los otros métodos de

su clase, será parte de esta metodología, ya que es el único que puede identificar problemas de usabilidad mediante

inspecciones a la aplicación web transaccional. Su capacidad para encontrar problemas de distintos niveles y que

contradicen distintos principios de usabilidad apoya esta inclusión, gracias al análisis sobre los casos de estudio

anteriores.

En cuanto a los métodos de prueba, es claro que debe existir, por lo menos, una de las evaluaciones que

realizan una interacción directa del usuario con la aplicación web, es decir, el pensamiento en voz alta, la interacción

constructiva y los experimentos formales. La definición de cuál(es) de estos métodos debe ser considerado se

discutirá más adelante.

Respecto de los métodos de prueba que no consideran una interacción directa con la aplicación web

transaccional, entre los cuales se encuentran las pruebas en papel, las técnicas de interrogación y el ordenamiento de

tarjetas, hay uno de ellos que toma ventaja. Las pruebas en papel entregaron algo de información sobre la usabilidad,

pero no de la forma esperada. El ordenamiento de tarjetas permitió obtener algunos problemas de usabilidad respecto

de la arquitectura de la información en cuanto al diseño. Pero son las técnicas de interrogación las que permitieron la



identificación tanto de problemas de diseño como de navegación, además de captar la satisfacción del usuario luego

de interactuar con la aplicación transaccional mediante uno de los otros métodos de prueba de la usabilidad.

Esta última característica también es definitoria al momento de inclinarse por las técnicas de interrogación,

ya que éstas funcionan como complemento a los métodos de prueba que realizan la interacción directa con la

aplicación web transaccional: se mitiga la desventaja que presentan las técnicas de interrogación, en cuanto a la baja

representatividad de la prueba, que no considera, por sí sola, una interacción con la aplicación. Así, las técnicas de

interrogación, en especial, los cuestionarios, se realizan después de que los usuarios realicen el pensamiento en voz

alta, la interacción constructiva y/o los experimentos formales, dependiendo de los resultados del análisis que se

realizará a continuación.

La discusión se evocará, entonces, a la definición de él o los métodos intermedios que deben realizarse para

obtener, en buena medida, la usabilidad de las aplicaciones web transaccionales.

Evaluación Heurística ??? Técnicas de Interrogación

Tanto el pensamiento en voz alta como la interacción constructiva y los experimentos formales han

permitido confirmar, de forma general, los problemas más importantes identificados por la evaluación heurística,

además de encontrar algunos otros problemas. Sin embargo, se han marcado algunas diferencias. Las pruebas

realizadas sobre el caso de estudio manifestaron que la interacción constructiva encontró más problemas de

usabilidad que los otros dos: se confirmaron empíricamente los problemas más críticos identificados por la

evaluación heurística y se encontraron varios otros problemas que no habían sido previamente identificados. El

pensamiento en voz alta también logró lo mismo, pero a una escala menor, y los experimentos formales, por sus

características, permiten obtener problemas ciertamente más generales y a base de los escenarios asociados al listado

de tareas diseñado para la evaluación.

Ahora bien, si se consideran los tiempos involucrados en la realización de estos tres métodos de prueba, las

conclusiones son similares en cuanto a las diferencias que se establecen. La experimentación concluyó que el

pensamiento en voz alta y la interacción constructiva consumen menos tiempo, en total, que el otro método de

prueba en discusión, los experimentos formales. La diferencia se establece en la etapa inicial y final de las pruebas,

de preparación y de análisis, respectivamente. El pensamiento en voz alta y la interacción constructiva no necesitan

de un diseño de tareas para su realización, mientras que los experimentos formales sí lo necesitan. Además, estos

últimos ameritan una cantidad de tiempo mayor para el análisis de las evaluaciones, principalmente por los estudios

estadísticos que se deben realizar.

Esta igualdad temporal del pensamiento en voz alta con la interacción constructiva ve su lado contrario en la

cantidad de problemas que cada uno de estos métodos identifica, tanto problemas totales como críticos, como se

nombró anteriormente. En este sentido, la interacción constructiva es la que toma la ventaja.



Otro factor importante para llegar a la metodología de evaluación de usabilidad para las aplicaciones web

transaccionales está relacionado con lo que abarca cada evaluación, es decir, las áreas de la aplicación que evalúa. El

pensamiento en voz alta y la interacción constructiva, al ser dos métodos de prueba que no limitan a los usuarios

representativos a enfocarse en áreas específicas de la aplicación web, permiten realizar un análisis completo de ésta;

por lo mismo, encuentran muchos más problemas de usabilidad que los experimentos formales. Claramente, no

ocurre lo mismo con estos últimos. El listado de tareas asociado a los experimentos formales hace que se limite la

interacción a las partes que el diseño de tareas sugiere, lo cual no es una desventaja, pero claramente no permite una

evaluación completa del sistema, sino más bien de áreas o funcionalidades específicas de la aplicación transaccional.

A base de todos los argumentos presentados anteriormente, es que se propone la metodología de evaluación

de usabilidad para aplicaciones web transaccionales, que sigue a continuación. Se propondrán tres caminos distintos,

dependiendo de los objetivos de la evaluación y de algunos otros factores.

Si el objetivo del desarrollo de los métodos de evaluación es analizar la aplicación de web de manera

completa, y considerando que el factor tiempo es comúnmente crítico, la metodología de evaluación de usabilidad

incluye los siguientes métodos: evaluación heurística, interacción constructiva y técnicas de interrogación. La Figura

7.1 muestra la secuencia.

Figura 7.1: Metodología de Evaluación para Aplicaciones Web Transaccionales - Evaluación Global

Bajo los factores ya mencionados esta metodología sería la más eficiente, ya que, en principio, la evaluación

heurística permite identificar gran parte de los problemas con la participación de los evaluadores expertos. Luego, la

interacción constructiva permite confirmar varios de esos problemas con la participación de usuarios representativos,

que interactúan a través de toda la aplicación web, por lo que, al igual que la evaluación heurística, se evalúa la

aplicación en completitud. No se considera el pensamiento en voz alta por su desventaja comprobada de la dificultad

de los usuarios de expresar a viva voz sus impresiones y por la baja cantidad de problemas encontrados en

comparación con la interacción constructiva. Finalmente, las técnicas de interrogación permiten rescatar la

información de forma más subjetiva de la experiencia de los usuarios, además permitiendo confirmar los problemas

más generales identificados por la evaluación heurística, funcionando como un eficiente complemento.



Ahora bien, si el objetivo de la metodología de evaluación es precisamente evaluar solo ciertos escenarios

del sistema o algunos aspectos o funcionalidades específicas, y considerando el tiempo como un factor crítico, los

experimentos formales serían los adecuados dentro de ésta, en desmedro de la interacción constructiva y el

pensamiento en voz alta, ya que se asegurará la evaluación empírica sobre lo deseado mediante una lista de tareas

diseñada especialmente para ello. Además, si el sistema es muy grande, la interacción constructiva y el pensamiento

en voz alta probablemente no alcancen a cubrir todo el sistema y podría pasar por alto lo que realmente se quiere

evaluar. Así, se podrán evaluar los escenarios, áreas o funcionalidades de la aplicación web de manera objetiva,

entregando problemas de usabilidad y además permitiendo realizar análisis estadísticos en cuanto a la interacción de

los usuarios representativos. La metodología se muestra en la Figura 7.2, a continuación.

Figura 7.2: Metodología de Evaluación para Aplicaciones Web Transaccionales - Evaluación Específica

Finalmente, existe una metodología de evaluación de usabilidad para aplicaciones web transaccionales que,

sin duda, entregaría de forma más completa que las anteriores la información sobre la usabilidad de la aplicación.

Claro que está determinada por un factor importante, que es la disponibilidad de tiempo. La metodología que se

presenta a continuación considera que no hay problemas de tiempo para realizar las evaluaciones, es decir, se

dispone del tiempo necesario para realizar evaluaciones hasta el punto de encontrar la medida de la usabilidad en

buena forma.

Si se da el caso de que hay una cantidad de tiempo considerable para realizar las evaluaciones (no infinita,

claramente), la experiencia considera que la metodología debe contener los siguientes métodos de evaluación:

Evaluación Heurística.

Interacción Constructiva.

Experimentos Formales.

Técnicas de Interrogación.



Mediante el desarrollo de dichos métodos de evaluación de usabilidad se obtendrá la medida de ésta de muy

buena forma, ya que se realizarán inspecciones por parte de evaluadores expertos, luego se realizarán inspecciones

de usuarios por la aplicación, se podrá realizar análisis estadísticos de las interacciones mediante los experimentos

formales, y finalmente se obtendrá información sobre las percepciones más subjetivas (cualitativas y cuantitativas)

de los usuarios representativos. La metodología se muestra en la Figura 7.3, a continuación.

Figura 7.3: Metodología de Evaluación para Aplicaciones Web Transaccionales - Factor Tiempo No es Crítico.

Esta metodología permitiría cubrir los puntos más críticos para obtener la medida de la usabilidad en un

punto totalmente aceptable. Primero, existe, por lo menos, un método de inspección y un método de prueba. En

segundo lugar, incluye evaluaciones que realizan análisis cuantitativos y cualitativos, objetivos y subjetivos, y de

evaluación global y evaluación específica de la aplicación. Por esto, es posible decir que se están cubriendo todos los

factores necesarios para obtener, en buena medida, el nivel de usabilidad de las aplicaciones web transaccionales.

En consecuencia, y tal como se ha definido al comienzo de la investigación, este subcapítulo ha permitido

definir una metodología de evaluación de usabilidad para aplicaciones web transaccionales. Esta metodología posee

tres formas o caminos distintos de aplicación, dependiendo de los factores que motivan el desarrollo de una

evaluación del nivel de usabilidad de cierta aplicación web transaccional. A continuación, se procede a realizar un

análisis, mediante un caso de estudio, con el fin de validar la propuesta, para finalmente realizar algunas

conclusiones de la metodología de evaluación de usabilidad.



7.2. Validación de la Metodología Mediante Sistema Biblioteca PUCV

La metodología de evaluación de usabilidad para aplicaciones web transaccionales anteriormente propuesta

será validada mediante el Sistema de Biblioteca de la Pontificia Universidad Católica de Valparaíso, versión 1.0. Se

realizará cada uno de los métodos de evaluación envueltos en los distintos caminos de la metodología, con el fin de

determinar si realmente la propuesta permite obtener la medida de la usabilidad de buena forma en las aplicaciones

web transaccionales.

El Sistema de Biblioteca de la PUCV (http://biblioteca.ucv.cl) corresponde a un sitio web transaccional de

acceso a alumnos, ex-alumnos y profesores, entre otros, que tiene como principales opciones la búsqueda de libros,

revistas, tesis y documentos académicos, además de la posibilidad de reservar cubículos de estudio, salas de video,

etcétera. Una captura de la página inicial de esta aplicación web transaccional se muestra a continuación, en la Figura

7.4.

Figura 7.4: Página Inicial Sistema Biblioteca PUCV

La figura muestra claramente una buena cantidad de enlaces en su parte central que llevan a diferentes

fuentes bibliográficas y sistemas de búsqueda de distintas bases de datos. La sección superior muestra el nombre y

logo del sitio, y el menú principal de la aplicación. Hacia abajo se puede apreciar un cuadro de búsqueda e

información sobre publicaciones internacionales de la PUCV.

http://biblioteca.ucv.cl/



Otra captura de la aplicación se muestra en la Figura 7.5, a continuación, que corresponde a la sección de

búsqueda de libros, tesis y cualquier documento académico disponible en alguna de las bibliotecas físicas de la

universidad.

Figura 7.5: Sección de Búsqueda del Sistema Biblioteca de la PUCV

La imagen anterior es bastante representativa en cuanto a la interfaz de las distintas búsquedas que se

pueden realizar en las diversas bases de datos disponibles. La parte superior incluye información sobre el sitio y la

misma página junto con algunas opciones de menú, y en la parte central se ubican los campos de texto para editar las

búsquedas.

A continuación se muestra el proceso de realización de cada uno de los métodos envueltos en la

metodología de evaluación de usabilidad para aplicaciones web transaccionales, las conclusiones asociadas a cada

uno y finalmente un análisis de resultados que permitirá confirmar o desechar la propuesta.




Las evaluaciones a realizar en esta etapa corresponden, como ya se ha dicho, a los métodos de evaluación

que forman parte de la metodología propuesta en las secciones anteriores. Los tres caminos que puede tomar la

metodología, dependiendo de los distintos factores analizados, incluyen los siguientes métodos de evaluación de

usabilidad:

Evaluación Heurística.

Interacción Constructiva.

Experimentos Formales.

Técnicas de Interrogación.

Así, en un principio se realizará el método de inspección que forma parte fundamental de la metodología

(los tres caminos la incluyen), luego los dos métodos de prueba que realizan una interacción directa del usuario con

la aplicación web y, finalmente el otro método de prueba, que funciona como complemento de las demás para

rescatar la información subjetiva de los usuarios respecto de su experiencia con la aplicación web transaccional

(también presente en los tres posibles caminos).

El espacio temporal en que se realizarán estos métodos de evaluación permitirá realizar los análisis

respectivos para validar la propuesta de la metodología de evaluación de usabilidad. Para el primer camino, se

considera la realización de la evaluación heurística, la interacción constructiva y las técnicas de interrogación, no

considerando los experimentos formales. Para el segundo camino es la interacción constructiva la que no se debe

considerar, mientras que para el último camino presentado, que sería el más óptimo si se dispone de cierta cantidad

de tiempo holgada para realizar los pruebas con tranquilidad, se consideran todos los métodos de evaluación

nombrados anteriormente.

Un punto importante a considerar es que los métodos fueron realizados en distintas etapas. La evaluación

heurística se realizó en un comienza, emitiendo un informe a los administradores del Sistema de Biblioteca de la

PUCV, realizando algunos de los cambios recomendados por los encargados de la evaluación, y posteriormente a

ello se desarrollaron los métodos de prueba de la usabilidad. Por esto, algunos problemas identificados por la

evaluación heurística probablemente no serán confirmados por alguno de los métodos de prueba debido a la

corrección de estos por parte del equipo de la aplicación evaluada. Por lo mismo, los métodos que ameritaban de un

diseño de la prueba fueron desarrollados a base del sistema en el momento posterior a la corrección. Todo lo anterior

tiene su fundamento porque los métodos de evaluación pueden desarrollarse en distintos períodos del desarrollo de

software.




La evaluación heurística realizada sobre el Sistema de Biblioteca de la PUCV fue desarrollada por cinco

evaluadores con experiencia media en este tipo de evaluaciones. A ellos se les facilitó el documento que explica de

forma general el proceso involucrado en la evaluación y las heurísticas a aplicar (véase Anexo 1). Los perfiles de los

evaluadores, las heurísticas utilizadas, los problemas encontrados y las conclusiones de la evaluación se muestran a

continuación.


Este método de inspección de usabilidad fue desarrollado con la participación de cinco evaluadores que


Alumnos de Ingeniería Civil Informática o del programa de Magíster en Ingeniería Informática de

la PUCV.




Las heurísticas en que se basaron los evaluadores para realizar la inspección sobre la aplicación web

transaccional son basadas en las propuestas por Jakob Nielsen, que fueron particularizadas a este tipo de

aplicaciones, como se muestra en la Tabla 6.1 del capítulo anterior.


La evaluación heurística permitió identificar un número no menor de problemas de usabilidad: cincuenta y

cinco problemas. Esta alta cantidad de problemas identificados contradice distintos principios de usabilidad. La

Tabla 7.1, a continuación, muestra precisamente el número de problemas identificados separados por principio de

usabilidad.



Tabla 7.1: Problemas de Usabilidad Identificados por Principio



Conexión entre el Sistema y el Mundo Real. 4

Control y Libertad del Usuario. 3

Consistencia y Estándares. 9

Prevención de Errores. 8

Reconocer Mejor que Recordar. 1

Flexibilidad y Eficiencia de Uso. 8

Diseño Estético y Minimalista. 9

Ayuda al Usuario a Reconocer, Diagnosticar y Recuperarse de Errores. 8

Ayuda y Documentación. 3

La tabla indica una distribución relativamente equitativa de los problemas dentro de los principios de

usabilidad. Los principios que se ven mayormente sobrepasados son:

Consistencia y Estándares.

Prevención de Errores.

Flexibilidad y Eficiencia de Uso.

Diseño Estético y Minimalista.

Ayuda al Usuario a Reconocer, Diagnosticar y Recuperarse de Errores.

Según lo anterior, la mitad de los principios de usabilidad están siendo contradichos en un número alto (8 ó

9 problemas de usabilidad identificados), por lo que se puede decir que el sitio del Sistema de Biblioteca de la PUCV

no posee inmerso el atributo de la usabilidad en un grado aceptable, asunto que podrá ser confirmado más adelante

con los métodos de prueba de usabilidad, en donde se podrá ver la interacción del usuario con la aplicación.

A continuación, se presenta la lista de los problemas de usabilidad identificados por la evaluación heurística,

en la Tabla 7.2.



Tabla 7.2: Problemas Identificados Evaluación Heurística

Principio N° Problema Severidad Frecuencia Criticidad

Visibilidad del

Estado del

Sistema

1

La página de resultados de la búsqueda se abre

en una ventana o pestaña nueva, si uno vuelve a

la pestaña del portal y realiza una nueva

búsqueda, la pestaña de resultados se actualiza

pero no gana foco, el navegador sigue en el

portal.

2,80 3,20 6,00

2 El usuario no sabe en qué parte específica del

sistema se encuentra, al no marcar una ruta. 2,80 2,80 5,60

Correspondencia

entre el Sistema

y el Mundo Real

3

El vínculo "plan 2005-2009" en la página

principal, no es intuitivo. El usuario debe darse

cuenta de eso por sus propios medios, no es

familiar.

2,40 2,40 4,80

4

Pareciera ser que algunos scripts fueron

traducidos al castellano literalmente, ejemplo el

del buscador interno del sitio web. Utiliza palabras como "caso insensible". Y en general

la explicación de utilización pudiera resultar

poco entendible para los usuarios.

3,00 2,60 5,60

5

Hay palabras en inglés, algunas representan

vínculos y otras más ambiguas. Ej.: "Home" en

e-bibliotecario.

2,80 2,40 5,20

6 Las opciones de búsqueda son poco

significativas para un usuario común. 3,40 3,20 6,60

Control y

Libertad del

Usuario

7

Hay sectores que no poseen un link para volver

a la página principal. Por ejemplo e-

bibliotecario, y el proyecto Poseidón

2,60 2,60 5,20

8

En recursos hay un menú de revistas de texto

completo que son secciones nuevas al parecer.

La de Harvard pide un "Login" que no se

especifica antes en la página de biblioteca. Algo

similar pasa en otras.

2,60 2,40 5,00

9 Algunas secciones no presentan rutas de

regreso, ejemplo: Poseidón 3,00 2,60 5,60

Consistencia y

Estándares

10

En la búsqueda en catálogos, el botón "su

selección" implica imprimir lo seleccionado,

pero no queda claro.

2,80 2,40 5,20

11 En la búsqueda en catálogos, la opción "libre"

no es clara 2,60 2,40 5,00

12

En Mozilla Firefox, el puntero del mouse se

muestra como editor de texto cuando debería

ser una mano (por consistencia) en los submenús de la página principal.

2,80 3,20 6,00

13 La vista previa de revistas en línea y la página a

la que realmente se llega difieren. 2,20 3,20 5,40



Tabla 7.2 (continuación): Problemas Identificados Evaluación Heurística


Consistencia Y

Estándares

14

El Fondo "Bundge" y "Margot Loyola"

aparecen en 2 menús, el de Catálogos y el de

Proyectos. Si bien en uno trata de explicar sobre

el fondo y en el otro pareciera ser un buscador

de las publicaciones en ellas, quizás podrían

estar juntas (información y buscador). Además

el menú principal del sitio se bloquea en la página de proyecto "Fondo Bundge"

2,80 3,00 5,80

15 En algunas secciones el menú vertical aparece más de una vez.

2,40 2,60 5,00

16 En algunas secciones el logo de biblioteca actúa como link al HOME, pero en otras secciones no

es así.

2,40 2,80 5,20

17

Las publicaciones internacionales se abren en

una página distinta (blank) sin embargo poseen

un botón de "Volver" que lleva de vuelta al

portal de biblioteca. ¿Porqué retornar a un lugar

del que no se ha salido?

2,40 3,00 5,40

18

Hacer clic en el menú superior hace que las

opciones desaparezcan, la única forma de

hacerlas aparecer es pasar el Mouse sobre un

ítem.

2,80 2,20 5,00

Prevención de

Errores

19

En el sistema de reserva de biblioteca al

"loguearse", si se ingresa mal el RUT dice que

éste es erróneo. Debiera existir un ejemplo del

formato de cómo deberia ingresarse el RUT.

2,80 3,20 6,00

20

Los tipos de búsqueda no explican cómo será

ésta, el usuario no sabe bien lo que está

haciendo.

3,20 3,40 6,60

21

En la búsqueda en catálogos, las opciones de

búsqueda son "Libre", "Básico" y "Avanzado",

siendo la más compleja la que está por defecto.

1,40 2,40 3,80

22 Presionar Enter en el campo de texto de

búsqueda hace que la página se reinicie. 3,40 3,60 7,00

23 Existen menús verticales hechos en java script

que presentan problemas con FIREFOX 2,80 2,60 5,40

24

El buscador interno entrega como resultados

páginas que no tienen contenido, parecieran ser

archivos con funciones para otras páginas.

3,60 3,40 7,00

25

En FIREFOX el sistema e-bibliotecario

presenta errores en la mayoría de sus servicios,

y no hay especificación si es recomendable

utilizar IE.

3,40 3,60 7,00

26

Al realizar una búsqueda en el sistema de

biblioteca pero sin seleccionar un "buscador" sale un mensaje de error que alerta de esto. Sin

embargo, abre una nueva página con error.

2,40 3,40 5,80





Reconocimiento

en Lugar de

Recordar

27

Al entrar en Catálogos las opciones poseen en

su mayoría igual interfaz. No se sabe en cual

uno se encuentra, sólo se puede distinguir por el

nombre de la base de datos, pero tampoco son

representativos los nombres.

3,20 3,20 6,40

Flexibilidad y

Eficiencia de Uso

28

En general, el motor de búsqueda es poco

flexible siendo muy dependiente de expresiones

regulares y ecuaciones de búsqueda. Tal vez

con el tiempo el usuario pueda sacar provecho

de esto, pero la curva de aprendizaje es mayor

para usuarios nuevos. Ejemplo

http://biblioteca.ucv.cl/cintas/todos/index.php

2,80 3,40 6,20

29

Realizar una búsqueda de más de una palabra,

con opción Opac, lleva a la página de búsqueda

de catálogo, es decir un búsqueda lleva a otra

página de búsqueda. La búsqueda debería realizarse directamente y ofrecer una búsqueda

avanzada si es necesario realizar “ecuaciones de

búsqueda”.

2,80 2,60 5,40

30

Las búsquedas en el catalogo de "cybertesis" no

muestran el título de la tesis (es decir, de que se

trata) sólo el autor y la sección donde se

encontró el resultado.

2,80 3,00 5,80

31 Una búsqueda con opción "scopus" lleva a una

página de id de usuario. 2,80 3,00 5,80

32

Una búsqueda con opción "grokker" lleva a otra

página de búsqueda, sin ningún término escrito

en el campo de texto (se podría al menos enviar

el termino de búsqueda como parámetro).

2,60 2,80 5,40

33

En una búsqueda con opción "grokker", existe

un problema de consistencia de lenguaje y

navegación con las opciones de búsqueda, ya

que las opciones Básico y Avanzado parecen

ser lo mismo.

2,20 2,60 4,80

34 La página de "proyectos" posee el menú lateral

repetido. 2,00 3,00 5,00

35 Los resultados de la búsqueda en sistema de

biblioteca no cumplen con las expectativas. 3,60 3,40 7,00

Diseño Estético y

Minimalista

36

Los enlaces a otras áreas del sitio están en

mayor jerarquía que la búsqueda y están

agrupados sin un nombre de grupo o título que

ayude al usuario a saber a que pertenecen.

3,40 3,60 7,00

37 Casi no se percibe que hay un menú debajo del

logo del sistema. 3,20 3,20 6,40

38 El logo del sistema es muy pequeño y el

nombre de la universidad es casi imperceptible. 2,40 2,80 5,20






Diseño Estético

y Minimalista

39

En el sector de las últimas publicaciones

internacionales de la universidad, es difícil leer

lo que dice tanto por el tamaño de letra, cómo

por el contraste que se forma con el fondo y el

color de las letras.

2,40 2,40 4,80

40

El sistema no oculta la complejidad interna al

usuario, no enmascara su estructura para darle

una interfaz más "centrada en usuarios"

3,20 3,00 6,20

41

Aparecen nombres de sistemas para búsqueda o

sus páginas, pero no se explica qué es cada

sistema y si realmente será útil buscar ahí.

3,20 3,40 6,60

42

Menú horizontal principal es muy pequeño y

todo amontonado cuando se expanden sus opciones. Molesta el hecho de querer hacer clic

en una sección y que quede subrayado el menú

en vez de ir a la página solicitada.

3,00 2,80 5,80

43

En opciones bajo una misma categoría, el

sistema abre ventanas externas y lleva al usuario

a otros sistemas.

2,60 2,80 5,40

44 Algunos menús con muchos submenús. 2,60 3,20 5,80

Ayuda a los

Usuarios a

Reconocer,

Diagnosticar y

Recuperarse de

Errores

45 Al pedir cubículo, ocurren fallas y no explica

cual es la falla. 3,40 2,60 6,00

46

Si no se tiene configurado Outlook, se tienen

problemas al poner el link de contacto, ya que

trata de cargar el programa.

2,80 2,80 5,60

47 Las fallas o errores son explicados mediante

código. 3,60 2,60 6,20

48 Una búsqueda con opción "Biblioteca ágora"

lleva a una página de error 404 3,60 3,80 7,40

49 Realizar la búsqueda sin elegir una opción envía

a una página 404 3,40 3,60 7,00

50 Las búsquedas al catálogo de revistas no cargan. 3,60 3,20 6,80

51 Una búsqueda de una palabra con acento con la

opción "oister" lleva a una error 3,00 2,40 5,40

52 Una búsqueda con opción "doi resolver" lleva a

una página de error 3,20 3,20 6,40

Ayuda y

Documentación

53 La página de información está en construcción

desde el año 2006!! 3,00 3,20 6,20

54 Al pedir cubículo, no especifica claramente como es el "login".

2,80 3,60 6,40

55 El sistema no cuenta con un modulo de ayuda al usuario

4,00 4,00 8,00



La Tabla 7.2 ha permitido notar la gran cantidad de problemas de usabilidad identificados. Al ser problemas

que contradicen distintos tipo de principios de usabilidad, no es posible establecer que los problemas se inclinan

hacia cierto ámbito de problemas. Es destacable, eso sí, que existan muchos problemas de consistencia y del diseño

de la aplicación web, lo que claramente impide en forma directa la interacción de los usuarios con la aplicación.

Otro punto que marca un importante obstáculo para los usuarios está en la prevención de errores, asunto

que, a la vista de los resultados de los problemas identificados por la evaluación heurística, no ha sido considerado

para el Sistema de Biblioteca de la PUCV. Los usuarios no pueden realizar las tareas de forma normal ya que se

encuentran con errores de manera constante, y no existe un mecanismo eficiente que alerte o guíe a los usuarios

sobre posibles caminos a seguir, decisiones a tomar, etcétera, que permiten que los usuarios no caigan en esos errores

que, a la larga, desgastan al usuario. Esto va de la mano con la debilidad del sistema de ayuda a los usuarios a

gestionar esos errores en que han caído, según el alto número de problemas de usabilidad pertenecientes al principio

relacionado con ello.

Un último punto está en la flexibilidad y eficiencia de uso de la aplicación web transaccional. Al parecer, el

Sistema de Biblioteca de la PUCV no se preocupa por la satisfacción del usuario en cuanto a encontrar un sitio

acorde a sus modelos y permitir la aceleración de algunos procesos para usuario un poco más experimentados.

7.2.1.1.4. Análisis de Resultados

Claramente, los resultados de las inspecciones realizadas por los cinco evaluadores indican que la aplicación

web transaccional posee una elevada cantidad de problemas de usabilidad y que rompen distintos principios. La

Tabla 7.3, mostrada más adelante, corresponde al ranking de los problemas con mayor criticidad, con calificaciones

iguales o superiores a seis.

Es destacable la cantidad de problemas con calificaciones de criticidad superiores a siete, lo que indica que,

además de ser muchos los problemas identificados, varios de ellos contradicen en alto nivel a los principios de

usabilidad.

El primer problema en la lista corresponde a la inexistencia de documentos de ayuda al usuario que

permitan apoyar la interacción en casos que sean necesarios. Muchos de los siguientes problemas en la lista están

relacionados con el sistema de búsqueda de la aplicación, lo cual es parte fundamental del mismo, ya que,

generalmente, los usuarios ingresan al sitio precisamente para realizar búsquedas de diferentes documentos

bibliográficos en las bases de datos de la aplicación. Otro problema importante está en la disposición de la

información en las distintas páginas, especialmente en la inicial, que posee una buena cantidad de enlaces, ya sea a

destinos internos o externos a la universidad, que no comunican de forma clara su objetivo ni poseen alguna

agrupación que ayude al usuario a su identificación.



Tabla 7.3: Ranking de Problemas por Criticidad


55 El sistema no cuenta con un módulo de ayuda al usuario 8,00

48 Una búsqueda con opción "Biblioteca ágora" lleva a una página de error 404 7,40

22 Presionar la tecla “Enter” en el campo de texto de búsqueda hace que la página se reinicie. 7,00

24 El buscador interno entrega como resultados páginas que no tienen contenido, parecieran ser

archivos con funciones para otras páginas. 7,00

25 En FIREFOX el sistema e-bibliotecario presenta errores en la mayoría de sus servicios, y no

hay especificación si es recomendable utilizar IE. 7,00

35 Los resultados de la búsqueda en sistema de biblioteca no cumplen con las expectativas. 7,00

36 Los enlaces a otras áreas del sitio están en mayor jerarquía que la búsqueda y están agrupados

sin un nombre de grupo o título que ayude al usuario a saber a que pertenecen. 7,00

49 Realizar la búsqueda sin elegir una opción envía a una página 404 7,00

50 Las búsquedas al catálogo de revistas no cargan. 6,80

6 Las opciones de búsqueda son poco significativas para un usuario común. 6,60

20 Los tipos de búsqueda no explican cómo será ésta, el usuario no sabe bien lo que está

haciendo. 6,60

41 Aparecen nombres de sistemas para búsqueda o sus páginas, pero no se explica qué es cada

sistema y si realmente será útil buscar ahí. 6,60

27

Al entrar en Catálogos las opciones poseen en su mayoría igual interfaz. No se sabe en cual

uno se encuentra, sólo se puede distinguir por el nombre de la base de datos, pero tampoco

son representativos los nombres.

6,40

37 Casi no se percibe que hay un menú debajo del logo del sistema. 6,40

52 Una búsqueda con opción "doi resolver" lleva a una página de error 6,40

54 Al pedir cubículo, no especifica claramente como es el "login". 6,40

28

En general, el motor de búsqueda es poco flexible siendo muy dependiente de expresiones

regulares y ecuaciones de búsqueda. Tal vez con el tiempo el usuario pueda sacar provecho de

esto, pero la curva de aprendizaje es mayor para usuarios nuevos. Ejemplo


6,20

40 El sistema no oculta la complejidad interna al usuario, no enmascara su estructura para darle

una interfaz más "centrada en usuarios" 6,20

47 Las fallas o errores son explicados mediante código. 6,20

53 La página de información está en construcción desde el año 2006. 6,20

1

La página de resultados de la búsqueda se abre en una ventana o pestaña nueva, si uno vuelve

a la pestaña del portal y realiza una nueva búsqueda, la pestaña de resultados se actualiza pero no gana foco, el navegador sigue en el portal.

6,00

12 En Mozilla Firefox, el puntero del mouse se muestra como editor de texto cuando debería ser

una mano (por consistencia) en los submenús de la página principal. 6,00

19 En el sistema de reserva de biblioteca al "loguearse", si se ingresa mal el RUT dice que éste es

erróneo. Debiera existir un ejemplo del formato de cómo debería ingresarse el RUT. 6,00

45 Al pedir cubículo, ocurren fallas y no explica cual es la falla. 6,00





Este método de prueba de la usabilidad, que forma parte de dos de los tres caminos que puede tomar la

metodología dependiendo de los factores considerados, fue realizado en el Laboratorio de Usabilidad de la Escuela

de Ingeniería Informática con la participación de cuatro usuarios representativos. Previa firma del Acuerdo de

Confidencialidad (véase Anexo 2), las parejas de usuarios realizaron la interacción sobre la aplicación web

transaccional, al mismo tiempo que intercambiaban sus impresiones a viva voz. Se almacenaron los archivos de las

acciones de los usuarios en pantalla y el audio asociado a las conversaciones de los mismos.

A continuación se muestran los perfiles de usuario de los participantes de la prueba y posteriormente un

análisis de los resultados de la evaluación. Claramente, este método de evaluación no requiere de un diseño de lista

de tareas, debido a la interacción libre, de forma de inspección, que realizan los usuarios representativos.


Para esta evaluación participaron cuatro usuarios representativos, los cuales se adecúan al perfil de usuario

medio, que corresponde a alumnos de las Pontificia Universidad Católica de Valparaíso que conocen el Sistema

Biblioteca de la universidad, teniendo algún tipo de interacción previa con la aplicación web. Los participantes son

estudiantes de Ingeniería Civil Informática de la PUCV y poseen un grado de experiencia media y avanzada de uso

de aplicaciones web transaccionales en general.


La realización de este tipo de método de prueba de la usabilidad ha permitido obtener conclusiones tanto

respecto de la interacción misma de los usuarios para con el sistema, mediante el análisis de sus acciones sobre la

aplicación, como de la expresión a viva voz de sus impresiones.

Las dos parejas de participantes interactuaron con el sistema por un tiempo aproximado de 30 y 55 minutos

cada una, desarrollando de manera exitosa la idea de conversación que debían llevar a cabo, manifestando sus ideas e

impresiones respecto de la interacción que realizaban con la aplicación web transaccional.

Los problemas identificados por la interacción constructiva, basándose en las dos fuentes de información

nombradas anteriormente se muestran a continuación, en la Tabla 7.4. En ella es posible notar que los problemas más

críticos identificados por la evaluación heurística, en general, pudieron ser confirmados por este método de

evaluación con usuarios representativos.



Tabla 7.4: Problemas Identificados Interacción Constructiva

Número Problema

1 En muchas ocasiones, las páginas de búsqueda no cargan, llevando

a una página en blanco.

2 Opciones de búsqueda poco representativas para los usuarios.

3 La sección de búsqueda de la página principal no es claramente

visible entre la demás información que muestra la misma.

4

Los resultados de búsqueda se abren en otra ventana o pestaña,

pero no se hace saber de esto al usuario, por lo que probablemente

no note la apertura de esta nueva ventana o pestaña.

5 Los enlaces de la página principal no comunican ningún tipo de

agrupación.

6 Nombres o títulos de algunas páginas poco representativos.

7 Las vistas previas de los enlaces de los sitios en la página inicial

molestan la interacción del usuario.

8 Lentitud en la carga de algunas páginas.

9 Existencia de muchas opciones que confunden al usuario.

10 Algunas opciones no necesarias para el objetivo del sitio.

11

Sobrecarga de opciones. Los enlaces principales mostrados en la

página inicial también se muestran en el menú, confundiendo al

usuario sobre su agrupación.

12 Demasiada cantidad de opciones por menú.

13

El ingreso de sesión para la reserva de cubículos no presenta la

ayuda necesaria sobre el formato de ingreso del Rut y Rol del

usuario.

14 El sitio no posee mecanismos que indiquen que la página está

cargando.

15 Algunas páginas no poseen opciones para volver a páginas

anteriores o la página inicial.

16 Existe una ayuda para la búsqueda de libros que no es visible para

los usuarios por su posición dentro del menú.



Tabla 7.4 (continuación): Problemas Identificados Interacción Constructiva

Número Problema

17 No se establece ningún tipo de diferencia entre vínculos a páginas

internas o externas a la aplicación.

18 La aplicación no explica sus funcionalidades siendo que posee una

gran cantidad de opciones.

19 Algunas páginas propias del sitio salen totalmente del contexto del

mismo.

20 Ayudas contextuales con nombres genéricos.

21 Resultados de búsqueda no cumplen con las expectativas.

22 Los botones de ayuda y para volver a la página inicial, entre otros,

son muy pequeños, poco visibles.

23 No se indica claramente las páginas, secciones o menús en que se

está situado.

24 No existen ayudas ni consejos de búsqueda que ayudan al usuario.

25 La ayuda general de la aplicación no está operativa.

Como indica la tabla anterior, la interacción constructiva permitió identificar muchos problemas de

usabilidad de distintas partes de la aplicación. Con esto, se confirma que esta evaluación permite realizar una

evaluación empírica de la aplicación web en forma global, identificando problemas en los distintos módulos.

Se pudo confirmar muchos de los problemas identificados por la evaluación heurística. En cuanto a los más

críticos, se pudo confirmar la inexistencia de ayuda para los usuarios, la deficiencia en el sistema de búsquedas y la

mala o inexistente agrupación de los enlaces de la página principal, incluso los menús. Los problemas de usabilidad

del sistema de búsqueda son muy importantes, ya que esa funcionalidad es la primordial de la aplicación: los

usuarios, generalmente, ingresan para buscar información sobre distintos documentos académicos.




Los experimentos formales fueron desarrollados en el Laboratorio de Usabilidad de la Escuela de Ingeniería

Informática, con la participación de cinco usuarios representativos. Luego de la firma del acuerdo de

confidencialidad (véase Anexo 2) se desarrollaron las evaluaciones a base de la lista de tareas diseñada. Se

almacenaron los archivos que muestran la interacción de los usuarios en pantalla para el posterior análisis de ellos,

realizando el respectivo análisis estadístico.


Los usuarios participantes de esta prueba, al igual que para el caso de la interacción constructiva, se

corresponden con el perfil de usuario medio, que posee cierto conocimiento de la aplicación web. Los cinco usuarios

de prueba son alumnos de Ingeniería Civil Informática de la PUCV.


Este método de evaluación de usabilidad se basó en los problemas más críticos identificados por la

evaluación heurística para el diseño de la prueba. Estos corresponden principalmente a la inexistencia y/o deficiencia

de la documentación de ayuda, problemas con el sistema de búsqueda del Sistema de Biblioteca, además de algunos

problemas de agrupación de información y de los menús.

La Tabla 7.5, disponible más adelante, corresponde a la definición de las tareas diseñadas para este método

de prueba. La tarea número uno, de búsqueda de información sobre una de las bibliotecas físicas, busca evaluar la

organización de las opciones de la aplicación. Para realizarla exitosamente los usuarios deben identificar las opciones

dentro de las opciones principales del menú.

Las siguientes tareas permiten evaluar el sistema de búsqueda de una forma más general. Se solicita la

búsqueda de un libro, una revista digital y una tesis de grado. Esta información se encuentra en distintas bases de

datos, por lo que los usuarios deben identificar las opciones que lo lleven a los objetivos solicitados.

Así, esta evaluación permitirá confirmar empíricamente la veracidad de algunos de los problemas

(especialmente más críticos) identificados por la evaluación heurística. El enfoque es hacia el sistema de búsqueda,

es decir, esta funcionalidad es el foco principal de evaluación, entre los otros ya mencionados.

El listado de tareas completo que se presentó a los usuarios representativos para su desarrollo está

disponible en el Anexo 8.



Tabla 7.5: Definición de Tareas para Experimentos Formales

Tarea N° 1

Descripción Búsqueda de información sobre una biblioteca.




Tarea N° 2

Descripción Búsqueda de información sobre un libro de la red de bibliotecas.




Tarea N° 3

Descripción Búsqueda una revista digital.


Caso Éxito Encontrar e ingresar la información solicitada.


Tarea N° 4

Descripción Búsqueda de información sobre una tesis.


Caso Éxito Encontrar e ingresar la información solicitada.





La realización de los experimentos formales ha permitido realizar los análisis que se mostrarán en esta

sección. La Tabla 7.6, a continuación, presenta los porcentajes de éxito de las cuatro tareas diseñadas y el promedio

de realización de cada una de ellas (el promedio de tiempos no considera los usuarios que no lograron realizar la

tarea).

Tabla 7.6: Resultados de los Experimentos Formales






Según la tabla, sólo la mitad de las tareas pudo ser realizada de manera exitosa por todos los usuarios

representativos. La primera tarea, que tenía como objetivo evaluar la disposición de la información en la aplicación,

en específico, en el menú principal, fue desarrollada por el 100% de los usuarios. A pesar de ello, el análisis de los

videos muestra que fue dificultoso llegar al objetivo de la tarea, ya que los usuarios navegaron bastante por distintas

opciones antes de llegar a la correcta.

Las siguientes tareas, que evaluaban empíricamente el sistema de búsqueda, permitieron confirmar de

distintas formas algunos problemas de usabilidad. Las tareas relacionadas con la búsqueda de un libro y de una tesis

en la red de bibliotecas confirmaron la deficiencia en la búsqueda. La sección de búsqueda de la página inicial

entregaba resultados de búsqueda que no correspondían a los términos ingresados y los nombres de las distintas

bases de datos no se correspondían con los que los usuarios buscaban.

En general, los experimentos formales permitieron confirmar los problemas que se estaban evaluando. Al

buscar opciones de búsqueda, los usuarios no la encontraron, el sistema de búsqueda es ineficiente y las agrupaciones

de las opciones y de los menús no es la adecuada.




Este método de evaluación de usabilidad fue realizado en el Laboratorio de Usabilidad de la Escuela de

Ingeniería Informática con la participación de nueve usuarios representativos. Estos corresponden a los participantes

de los dos métodos de prueba analizados anteriormente, los cuales, luego de haber interactuado con la aplicación web

transaccional, procedieron a responder las preguntas solicitadas.


El perfil de usuario de los participantes de la prueba corresponde al explicado en la interacción constructiva

y los experimentos formales. Este corresponde al perfil de usuario medio: alumnos de la PUCV que conoce el

Sistema de Biblioteca de la PUCV y que ha realizado, en algún momento, cierta interacción con la aplicación. Todos

los participantes corresponden a alumnos de Ingeniería Civil Informática.


La Tabla 7.7, a continuación, corresponde a las preguntas diseñadas para el cuestionario que los usuarios

representativos debían responder luego de haber interactuado con la aplicación web transaccional. Éstas se basaron

en los problemas identificados en la evaluación heurística, de manera de obtener la información subjetiva de los

usuarios respecto de los aspectos más importantes y críticos de la aplicación web. El documento presentado a los

participantes está disponible en el Anexo 11.







5 ¿El mecanismo de búsqueda del sitio es eficiente? No Sí

6 ¿El mecanismo de búsqueda del sitio es claro e

intuitivo? No Sí

7 El sistema de ayuda del sitio es: Pésimo Muy bueno


9 ¿Cómo evalúa su experiencia como usuario del sitio? Muy desagradable Muy agradable

10 De ser necesario, ¿Hacia dónde se inclinaría para

cumplir sus intereses? Bibliotecas Físicas

Sistema Web

Biblioteca

11 ¿Volvería ingresar al sitio? No Sí




Los resultados de la realización de este método de evaluación de usabilidad se muestran en la Tabla 7.8, a

continuación.

Tabla 7.8: Resultados del Cuestionario

Nro Pregunta Nota Menor (1) Promedio

(Escala de 1 a 7) Nota Mayor (7)

1 La disposición de la información en el sitio es: Muy difusa 2,3 Muy clara




5 ¿El mecanismo de búsqueda del sitio es

eficiente? No

2,5 Sí

6 ¿El mecanismo de búsqueda del sitio es claro e

intuitivo? No

1,5 Sí

7 El sistema de ayuda del sitio es: Pésimo 2,0 Muy bueno

8 ¿El sitio se preocupa de la satisfacción del

usuario? Nunca

2,8 Definitivamente

9 ¿Cómo evalúa su experiencia como usuario del

sitio?

Muy

desagradable

2,6 Muy agradable

10 De ser necesario, ¿Hacia dónde se inclinaría

para cumplir sus intereses?

Bibliotecas

Físicas

3,4 Sistema Web

Biblioteca

11 ¿Volvería ingresar al sitio? No 3,5 Sí

Los resultados de las calificaciones asignadas por los participantes de la prueba indican claramente una mala

percepción del Sistema de Biblioteca de la PUCV. Las preguntas con menor calificación corresponden a los aspectos

más interesantes de la evaluación. El mecanismo de búsqueda, el sistema de ayuda, la navegabilidad y la disposición

de la información en el sitio son precisamente los problemas generales más críticos que se obtuvieron con la

evaluación heurística. Así, este método de evaluación ha permitido confirmar que, subjetivamente, los usuarios se

sienten insatisfechos.

La pregunta número cuatro, relacionada con la funcionalidad del sitio, obtuvo la calificación más alta. A

pesar de ser solamente una nota cuatro en una escala de uno a siete, se puede concluir que los usuarios observan que

la funcionalidad del sitio es importante. Si la usabilidad de la aplicación apoyara de buena forma la funcionalidad,

probablemente sería un sistema muy utilizado por los alumnos de la universidad.




Las conclusiones derivadas de la realización de cada uno de los métodos de evaluación pertenecientes a la

metodología de evaluación de usabilidad para aplicaciones web transaccionales han sido exitosas. Los métodos de

prueba, independientemente, han confirmado los problemas más críticos identificados por la evaluación heurística.

Las técnicas para rescatar esa información es distinta pero cada uno, pero lo importante es que han cumplido con lo

esperado.

La interacción constructiva nuevamente es el método de prueba que identifica mayor cantidad de problemas.

La inspección de los participantes por la aplicación web y la expresión en voz alta de sus impresiones generan una

importante fuente de información.

Los experimentos formales, gracias a la lista de tareas que se diseñó especialmente para confirmar

problemas críticos, también permitieron confirmar, a su manera, estos problemas de usabilidad. Al enfocarse en los

escenarios dispuestos en la lista de tareas y analizando tiempos y criterios de éxito, la evaluación entregó los

resultados esperados.

Finalmente, las técnicas de interrogación funcionaron como buen complemento para identificar las

impresiones de manera más subjetiva, pero medible, de los usuarios. Las respuestas de los usuarios fueron bastante

negativas, sobre todo con los aspectos relacionados directamente con los problemas de usabilidad de la evaluación

heurística.

Respecto de los tiempos, la secuencia es similar a la obtenida en los dos casos de estudio anteriores. Las

técnicas de interrogación toman muy poco tiempo en llevarse a cabo, mientras que la interacción constructiva y los

experimentos formales demoran el tiempo que los usuarios toman en realizar las respectivas interacciones. El diseño

de las pruebas, para el caso de las técnicas de interrogación y los experimentos formales, hace que su preparación sea

más larga. Para la parte de análisis, los experimentos formales ameritan mayor cantidad de tiempo, debido a la

inversión temporal en el análisis de los videos, de éxitos o fracasos de tareas y de los estudios estadísticos.

En general, es posible determinar que las características más importantes postuladas en las secciones previas

a la propuesta de la metodología se han confirmado mediante el presente caso de estudio, ya sea en cuanto a la

identificación de problemas de usabilidad, tiempos involucrados, y conceptos relacionados específicamente con las

aplicaciones web transaccionales. Esto es fundamental para las conclusiones respecto de la metodología, que se

muestran a continuación.



7.3. Conclusiones sobre la Metodología

En el comienzo de este capítulo se postuló una metodología de evaluación de usabilidad para aplicaciones

web transaccionales. Más adelante, mediante el caso de estudio Sistema de Biblioteca de la PUCV, se procedió a

validar dicha propuesta, intentando verificar que las características identificadas sobre los métodos de evaluación

estaban en lo correcto. Finalmente, este subcapítulo tiene como objetivo determinar si la propuesta y la validación de

la misma han sido consistentes.

El primer camino de la metodología, aplicable cuando es necesaria una evaluación global de la aplicación

web transaccional, incluía la realización de una evaluación heurística, una interacción constructiva y, finalmente, las

técnicas de interrogación. Los análisis realizados sobre el último caso de estudio han determinado,

satisfactoriamente, que este camino sirve perfectamente cuando se necesita un análisis del tipo global. Se obtuvieron

muchos problemas de usabilidad, tanto por parte de los evaluadores como del análisis de la interacción de los

usuarios representativos, que cubrían aspectos de distintos módulos o secciones del Sistema de Biblioteca. Las

técnicas de interrogación permitieron, en la parte final, obtener resultados tanto cuantitativos como cualitativos que

confirmaron también lo determinado por los dos métodos anteriormente realizados.

El segundo camino de la metodología, determinado por la necesidad de evaluar áreas o funcionalidades

específicas de la aplicación web transaccional, incluye la realización de una evaluación heurística, luego los

experimentos formales y, finalmente, las técnicas de interrogación. La experiencia con el último caso de estudio

generó resultados alentadores respecto de la postulación de este camino (y de la metodología en general).

Claramente, los tres métodos aportan sus importantes características en este camino, pero son los experimentos

formales los que marcan la diferencia, respecto del camino anterior. Estos últimos permitieron realizar un eficiente

análisis de los aspectos de interés (sistema de ayuda, mecanismos de búsqueda, disposición y agrupación de la

información, entre otros menos importantes), por lo que los escenarios que se esperaba evaluar entregaron la

información requerida, en este caso, para determinar que los problemas se daban empíricamente, como lo había

postulado la evaluación heurística. Las técnicas de interrogación también se transformaron en un importante

complemento, ya que permitieron rescatar la información subjetiva que precisamente no entregaron los experimentos

formales, que corresponden al único método evaluación que entrega información completamente objetiva.

El tercer y último camino de la metodología propuesta, considera la realización de todos los métodos

realizados para este caso de estudio. Este camino se debe tomar si la disponibilidad de tiempo es alta, es decir, que el

factor tiempo no es crítico, considerando que en la mayoría de los casos la información se necesita de la forma más

inmediata posible. Si se toman en cuenta todos estos métodos de evaluación, claramente la información sobre la

usabilidad será más completa. La evaluación heurística, la interacción constructiva, los experimentos formales y las

técnicas de interrogación se complementan de muy buena forma.



La experiencia con el Sistema de Biblioteca de la PUCV confirmó que la evaluación heurística es muy

eficiente para determinar problemas de usabilidad basándose en los principios. La interacción constructiva aportó

con un análisis empírico muy completo de la aplicación web en general, con varios problemas identificados y en

distintas secciones. Los experimentos formales permitieron realizar un análisis más enfocado en áreas específicas,

además de un análisis más objetivo de la interacción de los usuarios. Y finalmente las técnicas de interrogación

entregaron la información subjetiva de forma directa de los usuarios, funcionando como un fuerte complemento para

completar la información que probablemente no se había obtenido con los otros métodos desarrollados.

En resumen, la metodología de evaluación de usabilidad para aplicaciones web transaccionales ha tenido

una base firme para su postulación mediante dos casos de estudio (Prototipo Web de Cadena de Supermercados y

Navegador Académico PUCV) que posteriormente ha sido validada exitosamente mediante un tercer caso de estudio

(Sistema Biblioteca PUCV).

Así, el resultado de la investigación, validado empíricamente, es el que se muestra a continuación.

Corresponde a una metodología de evaluación de usabilidad con tres caminos distintos, cada uno con su secuencia de

métodos de evaluación a desarrollar:

Metodología de Evaluación para Aplicaciones Web Transaccionales:

Evaluación Global de la Aplicación:

Evaluación Heurística – Interacción Constructiva – Técnicas de Interrogación.

Evaluación de Áreas o Funcionalidades Específicas:

Evaluación Heurística – Experimentos Formales – Técnicas de Interrogación.

El Tiempo No es un Factor Crítico:

Evaluación Heurística – Interacción Constructiva – Experimentos Formales – Técnicas de

Interrogación.

En consecuencia, y con el fin de generar cierta orientación para discernir de mejor manera cuándo cada uno

de los caminos es aplicable, la Tabla 7.9, a continuación, muestra las características y situaciones más importantes

en las cuales se puede enmarcar la evaluación de cierta aplicación web transaccional, y el camino correspondiente de

la metodología. Además, la última columna detalla un ejemplo.



Tabla 7.9: Metodología de Evaluación de Usabilidad para Aplicaciones Web Transaccionales

Camino de la Metodología Características de Aplicación Ejemplo

Evaluación Global

Analizar la usabilidad del sistema en

forma global, de las funcionalidades

generales de la aplicación, sin

privilegiar algún área, módulo o

funcionalidad específico. El tiempo es

un factor crítico para el proceso de

evaluación de la aplicación.

Evaluar la usabilidad de una aplicación

web del rubro alimenticio, que permite

hacer búsquedas de productos y

agregarlos a un “Carro de Compra”,

hacer solicitudes de despacho, acceder

a información nutricional de los

productos (o de un conjunto de estos),

entre otras cosas. El objetivo de la

evaluación es obtener la medida de

usabilidad general del sistema.

Evaluación Específica

Evaluar ciertas áreas, módulos o

funcionalidades específicas de la

aplicación web transaccional. El tiempo

es un factor crítico para el proceso de

evaluación de la aplicación.

Evaluar la usabilidad del módulo de

transferencias de un sistema web

bancario.

Factor Tiempo No Es Crítico

El tiempo no es un factor crítico para el

proceso de evaluación de la aplicación.

Se desea realizar una evaluación

completa de la usabilidad de la

aplicación web transaccional, tanto de

forma general, como de áreas, módulos

o funcionalidades específicas.

Evaluar la usabilidad de forma integral

de una aplicación web administradora

de proyectos, la cual permite hacer

seguimiento a los mismos, tomar

decisiones (modificar presupuestos,

tiempos, etcétera), obtener informes,

entre otras funcionalidades.

Como se puede notar, cada uno de los caminos posee sus características de aplicación propias, que los hacen

marcan diferencias con las demás. Los dos primeros se desmarcan del “Factor Tiempo No Es Crítico” precisamente

por la disponibilidad de tiempo, sin embargo, si los objetivos de evaluación son claros, se obtendrá la información

requerida exitosamente. Asimismo, la “Evaluación Global” y “Evaluación Específica” se diferencian por el objetivo

de evaluación: uno privilegiando un análisis general de la aplicación; el otro, de ciertos aspectos definidos.

Sea como sea, cualquiera de los tres caminos permite obtener la medida de la usabilidad en buen término, y

de mejor forma que la realización de los métodos de evaluación de forma aislada.



8. CONCLUSIONES

Luego de haber estudiado los conceptos relacionados con el tema de investigación a desarrollar, se confirma

la relevancia e influencia de estos en la vida cotidiana y especialmente dentro del mundo de la informática. Por un

lado están la ingeniería y aplicaciones web que, sin lugar a dudas y desde un tiempo a esta parte, reinan el mundo de

las comunicaciones con sus impactantes características como el compartimiento de información y la transferencia y

almacenamiento de datos.

Por otro lado, la literatura consultada ha demostrado que la usabilidad, progresivamente, se ha transformado

en un término común para las personas relacionadas de alguna forma con las tecnologías de información y

comunicación, y se está creando una especie de cultura sobre la grata influencia de la usabilidad en la facilidad y

eficiencia de uso de los productos software. Sin embargo, es notoria la diferencia existente en la disponibilidad de

documentos bibliográficos e investigaciones en lenguaje inglés, que representa la mayor cantidad de material

disponible, respecto del lenguaje español, lo que permite deducir que todavía la inmersión de la usabilidad no es tan

completa, sobre todo por este lado del mundo.

Cada uno de los métodos de evaluación de usabilidad posee sus características que lo diferencian de los

demás. Los métodos de inspección, por ejemplo, no pueden ser reemplazados por métodos de prueba de usabilidad y

viceversa, ya que no se obtendrán resultados satisfactorios por la naturaleza de cada uno. La secuencia es clara:

primero realizar los métodos de inspección y luego los de prueba.

El trabajo realizado ha permitido concluir y confirmar que cada uno de los métodos entrega los problemas

de usabilidad de distinta forma, en ocasiones complementarios y en otras no, por lo que ningún método es

reemplazable por otro. Por esto, de manera ideal, si se realizan todos los métodos de evaluación de usabilidad sobre

una aplicación web transaccional, cada uno entregará su propuesta mediante su propia técnica, y se obtendrá la

medida de la usabilidad del sistema de una forma muy completa.

La metodología de evaluación de usabilidad para aplicaciones web transaccionales presentada en la

investigación ha sido postulada mediante el análisis de dos casos de estudio representativos de estas aplicaciones.

Luego, la validación se realizó a través de un tercer caso de estudio, que permitió, exitosamente, confirmar que la

metodología es aplicable perfectamente a las aplicaciones web transaccionales. Así, dependiendo de los factores y de

los objetivos de evaluación de cierta aplicación, cada uno de los tres caminos de la metodología entrega los

resultados de la medida de la usabilidad de una muy buena forma.

Con todos estos antecedentes, además, se ha logrado confirmar la hipótesis definida al comienzo de la

investigación. Sin lugar a dudas, la aplicación de cualquiera de los tres caminos propuestos dentro de la metodología,

entrega mayor información respecto de la usabilidad que la aplicación aislada de los métodos de evaluación.



8.1. Cumplimiento de Objetivos

Dentro de los objetivos específicos definidos al comienzo del proyecto están los relacionados con la

comprensión del estado del arte asociado al tema de investigación. Todos los aspectos básicos relacionados con la

usabilidad forman parte de una riqueza académica muy necesaria para el posterior desarrollo del proyecto,

especialmente los aspectos relacionados con los métodos de evaluación de usabilidad.

El primer objetivo cumplido, de comprensión de los atributos, principios básicos y métodos de evaluación

de usabilidad, ha permitido obtener las bases en que se sostiene la usabilidad. La ingeniería de software considera a

la usabilidad como uno de los atributos básicos de cualquier producto software, por lo que es posible decir que los

atributos mismos de la usabilidad también forman parte de lo que un producto software debe poseer para cumplir con

los requerimientos básicos que debe poseer.

Por su parte, los métodos de evaluación de usabilidad son bastante diversos. Varían en sus características de

implementación, en la participación de usuarios, la inserción de especialistas de usabilidad, el tipo de análisis,

etcétera. Esto demuestra la importancia de las mediciones de la usabilidad, ya que se han creado muchos métodos

que buscan medir este atributo desde la mayor cantidad de aspectos posibles y con la mayor de las precisiones, lo

cual, sin duda, es un tema no menor.

La particularización de los métodos de evaluación de usabilidad a las aplicaciones web transaccionales

también corresponde a un objetivo cumplido. Las características identificadas se basaron en el desarrollo de los

métodos de evaluación sobre los casos de estudio, rescatando las ventajas y desventajas más importantes sobre las

aplicaciones web transaccionales. En la sección correspondiente, además, se destacaron las características más

influyentes que determinarían la postulación de la metodología de evaluación de usabilidad.

El tercer objetivo específico corresponde a la propuesta de la metodología de evaluación de usabilidad para

aplicaciones web transaccionales, el cual también está cumplido, como se puede específicamente en el subcapítulo

7.1 de la presente investigación.

Finalmente, el objetivo relacionado con la validación de la metodología de evaluación de usabilidad para

aplicaciones web transaccionales ha sido desarrollado en esta última etapa de manera exitosa. La validación

mediante un tercer caso de estudio entregó los resultados esperados, permitiendo confirmar que la metodología

propuesta se adecúa perfectamente a las aplicaciones web transaccionales.

Así, todos los objetivos específicos han sido cumplidos, por lo que es posible determinar que el objetivo

general del proyecto también está realizado: Establecer una metodología de evaluación de usabilidad para

aplicaciones web transaccionales.



8.2. Trabajo Futuro

Luego de haber satisfecho cada uno de los objetivos específicos de la investigación y, por lo tanto, el

objetivo general, las principales actividades futuras están posiblemente en el refinamiento de la metodología de

evaluación de usabilidad para aplicaciones web transaccionales.

La utilización de los distintos caminos propios de la metodología en distintas aplicaciones web

transaccionales servirá como retroalimentación para conocer el comportamiento en el tiempo de la misma. Es

probable que, con el paso del tiempo y la gran velocidad de cambio del comercio electrónico y de las tecnologías de

información y comunicación, la metodología deba ser adaptada a otros aspectos, eventualmente modificando algunos

de los métodos de evaluación estudiados de manera de obtener de forma adecuada la medida de la usabilidad del

sistema en cuestión.

El trabajo futuro puede estar enfocado, además, en el establecimiento de metodologías de evaluación para

otros tipos de sistemas software, probablemente comprobando la adecuación del postulado en la presente

investigación para otros casos, o derechamente analizando cada uno de los métodos de evaluación para el tipo de

sistema que se desee analizar.



REFERENCIAS

[1] Mari Carmen Marcos, “La usabilidad en España, un boom muy necesario”, Anuario ThinkEPI, pp. 178-183,

2007.

[2] Carmen Aránega Pardo, “Usabilidad y Satisfacción de las Personas que Trabajan con Tecnologías de la

Información y de la Comunicación”, No Solo Usabilidad, n°8, 2009.

[3] Sergio Ortega Santamaría, “Evolución del Perfil de Usuario: Usuarios 2.0”, No Solo Usabilidad, n°6, 2007.

[4] J. M. Cueva Lovelle, B. M. González Rodríguez, L. Joyanes Aguilar, J. E. Labra Gayo, M. del Puerto Paule

de Ruiz, “Web Engineering”, Softcover, 2003.

[5] Gerti Kappel, Birgit Pröll, Siegfried Reich, Wemer Retschitzzeger, “Web Engineering”, Jhon Wiley & Sons

Ltd., 2006.

[6] San Murugesan, Athula Ginige, “Web Engineering: Introduction and Perspectives”, Springer Berlin, 2005.

[7] Jordi Grau, “Pensando en el Usuario: La Usabilidad”, Anuario ThinkEPI, pp. 172-177, 2007.

[8] Donald A. Norman: “The Invisible Computer”, Cambridge, 1998.

[9] Kristoffer Bohmann, “Definition of Usability”, 2001. http://www.bohmann.dk/observations/2001oct12.html

[10] Yusef Hassan Montero, “Introducción a la Usabilidad”, No Solo Usabilidad Journal, n° 1, 2002.

[11] Jakob Nielsen, “Usability Engineering”, Morgan Kaufmann Publishers Inc., San Francisco, CA, 1995.

[12] Jakob Nielsen, “Ten Usability Heuristics”, 2005. http://www.useit.com/papers/heuristic/heuristic_list.html

[13] Toni Granollers, Jesús Lorés, “La Ingeniería de la Usabilidad y de la Accesibilidad Aplicada al Diseño y

Desarrollo de Sitios Web”, Departament Informàtica, Universitat de Lleida, Campus de Cappont, 2004.

[14] Wilbert O. Galitz, “The Essential Guide to User Interface Design - An Introduction to GUI Design Principles

and Techniques”, Wiley Publishing Inc., 2007.

[15] Sirpa Riihiaho, “Experiences with Usability Evaluation Methods”, Departament of Computer Science and

Engineering, Helsinki University of Technology, 2000.

[16] Keith Andrews, “Human Computer Interaction”, IICM, Graz University of Technology, 2002.

[17] María Elena Alva Obeso, “Metodología de Medición y Evaluación de la Usabilidad en Sitios Web

Educativos”, Universidad de Oviedo, 2005.

http://www.bohmann.dk/observations/2001oct12.html

http://www.useit.com/papers/heuristic/heuristic_list.html



ANEXOS



Anexo 1: Documento Evaluación Heurística para Evaluadores



EVALUACIÓN HEURÍSTICA

Estimado evaluador(a), de antemano muchas gracias por su colaboración. La presente evaluación heurística tiene

como objetivo detectar problemas de usabilidad en Sitios Transaccionales. Lamentablemente por Acuerdos de

Confidencialidad existentes, no se puede dar a conocer públicamente los nombres de los sitios o de las empresas a

las cuales se les evaluaran los sitios, por lo tanto, se les solicita la mayor confidencialidad, con el objetivo de

resguardar la privacidad de los sitios a evaluar.

1. PROPÓSITO DEL TIPO DE PRODUCTO A EVALUAR

Los sitios transaccionales son aquellos a través de los cuales suele lograrse ahorros significativos de mano de obra,

son muy intensos en entradas y salidas de información, además sus cálculos y procesos suelen ser simples y poco

sofisticados. Además poseen la característica de que son recolectores de información y son fácilmente adaptables a

paquetes de aplicación que se encuentran en el mercado, ya que automatizan los procesos básicos que por lo

general son de uso común en todas las organizaciones. Por lo general se dirigen a las áreas de venta y

mercadotecnia, administración y finanzas y al área de recursos humanos.

2. HEURÍSTICAS A UTILIZAR

Durante la evaluación se utilizarán los 10 principios de usabilidad propuestos por Nielsen los que se detallan a

continuación:

PRINCIPIO DESCRIPCIÓN

Visibilidad del estado

sistema.

El sistema transaccional, debería mantener siempre informados a los usuarios

sobre qué está haciendo, a través de una retroalimentación apropiada y en un

tiempo razonable.

Correspondencia entre el

sistema y el mundo real.

El sistema transaccional debería hablar el lenguaje del usuario, esto es, usar

palabras, frases y conceptos que le fueran familiares, siguiendo los convenios del

mundo real y haciendo que la información aparezca en un orden lógico y natural.

Control del usuario. Puesto que muchas veces los usuarios se equivocan y eligen alguna función del

sistema por error, es necesario que haya siempre una “salida de emergencia” para

salir de esa opción lo más cómodamente posible y, en general, proporcionar

mecanismos que permitan deshacer los cambios producidos por una acción no

deseada, así como repetir acciones ejecutadas con anterioridad. Rehacer,

Deshacer.

Consistencia y estándares. Los sistemas transaccionales deben evitar el empleo de distintas palabras,

situaciones o acciones para el mismo elemento. Hay que seguir, además, en cada

caso, los convenios existentes.



Prevención de errores. Es mucho mejor disponer de un diseño cuidadoso que prevenga que se produzcan

errores, a que se diseñe para que se envíe buenos mensajes de error.

PRINCIPIO DESCRIPCIÓN

Prevención de errores. Es mucho mejor disponer de un diseño cuidadoso que prevenga que se produzcan

errores, a que se diseñe para que se envíe buenos mensajes de error.

Reconocer mejor que

recordar.

Los sistemas transaccionales deben hacer que los objetos, acciones, y opciones

sean visibles para el usuario, el que no debe tener que recordar la información de

una parte del diálogo a otra.

Flexibilidad y eficiencia de

uso.

El sistema transaccional podría proporcionar una serie de atajos para los usuarios

expertos, sin que éstos sean perceptibles para los principiantes, adaptándose así a

ambos tipos de usuarios. También debería permitir personalizar aquellas acciones

más frecuentes que llevan a cabo los usuarios.

Estética y Diseño

minimalista.

Se debe evitar mostrar información irrelevante o que rara vez es necesaria. Cada

unidad extra de información que incluyamos en una pantalla o interfaz del sitio

transaccional va a competir con el resto y disminuir así, la visibilidad relativa de

otra información más importante.

Ayuda al usuario a

reconocer, diagnosticar y

recuperarse de errores.

Los mensajes de error presentes en los sistemas transaccionales deben ser

expresados en lenguaje natural (nada de códigos de error), indicando el problema

de forma precisa y sugiriendo una solución constructiva.

Ayuda y documentación. Los sistemas transaccionales deben proporcionar ayuda y documentación. Si

dispone de ésta documentación esta debe ser fácil de buscar, estar centrada en la

tarea del usuario, enumerar los pasos concretos que se deben realizar, y no ser

demasiado extensa.

3. DESCRIPCIÓN DEL PROCEDIMIENTO DE EVALUACIÓN

PASO 1: Cada evaluador de forma individual inspeccionará la interfaz de cada producto a

evaluar basándose en las heurísticas de Nielsen, registrando de la manera más clara posible

el problema de usabilidad detectado y agrupándolos de acuerdo al principio de usabilidad al

que cometen falta.

PASO 2: Un vez que todos los evaluadores hayan realizado su evaluación individual por

sistema, estas serán enviadas a la persona encargada de reunir los problemas detectados en

una lista única de problemas de usabilidad agrupados de acuerdo al principio de usabilidad al

que cometen falta.



PASO 3: La lista de problemas de usabilidad obtenida en el paso previo será entregado a cada

evaluador, para estimar su severidad y la frecuencia con la que aparece. Se utilizarán las

siguientes tablas para determinar el grado de severidad de cada problema y su frecuencia de

aparición respectivamente.

ESCALA DE SEVERIDAD

NOTA SEVERIDAD PRIORIDAD

0 No es un problema de usabilidad

1 Problema “Cosmético”- No necesita ser resuelto a menos

que se disponga de tiempo extra en el proyecto

2 Problema de usabilidad menor-arreglarlo tiene baja

prioridad Baja

3 Problema de usabilidad mayor-es importante arreglarlo se le

debe dar alta prioridad Alta

4 Problema de usabilidad catastrófico-es imperativo arreglarlo

antes de que el producto sea liberado Imperativo

ORDEN DE FRECUENCIA

NOTA SEVERIDAD FRECUENCIA

0 No es un problema de usabilidad <1%

1 Problema “Cosmético” 1-10%

2 Problema de usabilidad menor 11-50%

3 Problema de usabilidad mayor 51-89%

4 Problema de usabilidad catastrófico >90%

PASO 4: Una vez que todos los evaluadores hayan realizado la valoración de cada problema

de acuerdo a su severidad y frecuencia de aparición, estas serán enviadas a la persona

encargada de reunir los problemas detectados para que los ordene de mayor a menor

severidad.

¡¡ GRACIAS POR SU COLABORACIÓN!!



Anexo 2: Acuerdo de Confidencialidad



Acuerdo de Confidencialidad.

YO _______________________________ ACEPTO participar en un Test de Usabilidad supervisado por

__________________________, el día ___/___/_____, en el Laboratorio de Usabilidad de la Escuela de

Ingeniería Informática de la Pontificia Universidad Católica de Valparaíso.

Comprendo que el test se hace solo para evaluar un sistema de software, NO mis capacidades,

habilidades y conocimientos.

Comprendo que los resultados del experimento se utilizaran solo para propósitos académicos y/o de

investigación, sin que mi identidad sea revelada.

Comprendo que puedo comunicar al supervisor del experimento en cualquier momento, mi malestar,

molestia y/o inconformidad con el test.

Comprendo que puedo abandonar el test y el laboratorio en cualquier momento.

___________________

Firma



Anexo 3: Evaluación Heurística Prototipo Web Cadena Supermercados



Pro

ble

ma

Evaluador 1 Evaluador 2 Evaluador 3 Evaluador 4

Pro

med

io

Seve

rid

ad

Pro

med

io

Frec

uen

cia

Pro

med

io

Cri

tici

dad

Seve

rid

ad

Fre

cuen

cia

Cri

tici

dad

Seve

rid

ad

Fre

cuen

cia

Cri

tici

dad

Seve

rid

ad

Fre

cuen

cia

Cri

tici

dad

Seve

rid

ad

Fre

cuen

cia

Cri

tici

dad

1 3 3 6 3 2 5 2 3 5 3 4 7 2,75 3,00 5,75

2 3 2 5 3 2 5 2 2 4 3 2 5 2,75 2,00 4,75

3 2 2 4 2 2 4 2 1 3 3 3 6 2,25 2,00 4,25

4 2 3 5 3 2 5 3 4 7 2 2 4 2,50 2,75 5,25

5 3 4 7 4 3 7 3 3 6 3 4 7 3,25 3,50 6,75

6 4 4 8 4 4 8 3 2 5 4 4 8 3,75 3,50 7,25

7 2 3 5 4 3 7 2 3 5 3 4 7 2,75 3,25 6,00

8 2 3 5 4 3 7 2 3 5 3 3 6 2,75 3,00 5,75

9 3 2 5 3 2 5 2 3 5 3 3 6 2,75 2,50 5,25

10 3 3 6 3 3 6 2 3 5 3 3 6 2,75 3,00 5,75

11 3 3 6 3 2 5 1 4 5 3 3 6 2,50 3,00 5,50

12 3 2 5 3 3 6 2 3 5 3 3 6 2,75 2,75 5,50

13 2 3 5 4 3 7 1 4 5 3 2 5 2,50 3,00 5,50

14 2 3 5 4 4 8 2 3 5 3 2 5 2,75 3,00 5,75

15 3 2 5 3 3 6 2 2 4 3 2 5 2,75 2,25 5,00

16 4 4 8 4 3 7 3 2 5 3 4 7 3,50 3,25 6,75

17 3 4 7 2 2 4 3 2 5 3 4 7 2,75 3,00 5,75

18 3 3 6 2 2 4 3 4 7 3 4 7 2,75 3,25 6,00

19 4 4 8 3 2 5 2 3 5 4 4 8 3,25 3,25 6,50

20 4 4 8 3 3 6 3 1 4 3 4 7 3,25 3,00 6,25

21 4 3 7 3 3 6 3 1 4 3 4 7 3,25 2,75 6,00

22 3 4 7 4 4 8 2 2 4 2 4 6 2,75 3,50 6,25

23 3 3 6 4 3 7 2 2 4 3 2 5 3,00 2,50 5,50

24 2 3 5 4 3 7 1 3 4 3 4 7 2,50 3,25 5,75

25 3 2 5 3 2 5 2 1 3 3 2 5 2,75 1,75 4,50

26 4 2 6 3 3 6 2 1 3 4 2 6 3,25 2,00 5,25

27 3 3 6 4 3 7 2 1 3 4 2 6 3,25 2,25 5,50

28 4 4 8 3 3 6 1 1 2 4 3 7 3,00 2,75 5,75

29 4 3 7 3 2 5 1 1 2 3 4 7 2,75 2,50 5,25



Anexo 4: Evaluación Heurística Navegador Académico PUCV



Pro

ble

ma


Pro

me

dio

Seve

rid

ad

Pro

me

dio

Fre

cuen

cia

Pro

me

dio

Cri

tici

dad

Seve

rid

ad

Fre

cuen

cia

Cri

tici

dad

Seve

rid

ad

Fre

cuen

cia

Cri

tici

dad

Seve

rid

ad

Fre

cuen

cia

Cri

tici

dad

Seve

rid

ad

Fre

cuen

cia

Cri

tici

dad

1 3 3 6 4 3 7 3 4 7 2 4 6 3,00 3,50 6,50

2 2 3 5 3 3 6 1 2 3 3 4 7 2,25 3,00 5,25

3 2 4 6 3 3 6 3 3 6 2 4 6 2,50 3,50 6,00

4 3 4 7 3 3 6 2 2 4 2 2 4 2,50 2,75 5,25

5 3 4 7 4 3 7 2 2 4 1 4 5 2,50 3,25 5,75

6 3 2 5 4 4 8 3 2 5 4 3 7 3,50 2,75 6,25

7 4 2 6 4 3 7 2 2 4 2 3 5 3,00 2,50 5,50

8 3 2 5 3 3 6 3 2 5 2 3 5 2,75 2,50 5,25

9 3 2 5 3 3 6 2 2 4 2 3 5 2,50 2,50 5,00

10 3 3 6 4 4 8 3 3 6 4 3 7 3,50 3,25 6,75

11 3 3 6 3 3 6 1 2 3 3 3 6 2,50 2,75 5,25

12 3 3 6 4 3 7 3 3 6 3 3 6 3,25 3,00 6,25

13 3 3 6 3 3 6 2 3 5 4 4 8 3,00 3,25 6,25

14 2 4 6 3 3 6 4 3 7 4 4 8 3,25 3,50 6,75

15 3 4 7 3 3 6 3 2 5 4 3 7 3,25 3,00 6,25

16 2 3 5 4 3 7 2 2 4 1 4 5 2,25 3,00 5,25

17 3 3 6 4 4 8 4 2 6 4 4 8 3,75 3,25 7,00

18 1 2 3 2 2 4 3 4 7 2 4 6 2,00 3,00 5,00

19 1 2 3 3 2 5 2 3 5 4 2 6 2,50 2,25 4,75

20 3 4 7 3 3 6 3 3 6 4 4 8 3,25 3,50 6,75

21 1 3 4 4 2 6 3 3 6 2 4 6 2,50 3,00 5,50

22 3 3 6 4 3 7 2 3 5 3 3 6 3,00 3,00 6,00

23 3 4 7 4 3 7 3 4 7 3 3 6 3,25 3,50 6,75

24 2 4 6 4 3 7 3 2 5 3 3 6 3,00 3,00 6,00

25 1 4 5 3 3 6 3 3 6 2 2 4 2,25 3,00 5,25

26 3 3 6 3 3 6 2 2 4 3 2 5 2,75 2,50 5,25

27 3 4 7 3 2 5 0 2 2 0 4 4 1,50 3,00 4,50

28 1 2 3 4 2 6 3 2 5 1 1 2 2,25 1,75 4,00

29 2 3 5 3 3 6 3 3 6 1 4 5 2,25 3,25 5,50

30 4 4 8 4 4 8 4 4 8 4 4 8 4,00 4,00 8,00



Pro

ble

ma


Pro

me

dio

Seve

rid

ad

Pro

me

dio

Fre

cuen

cia

Pro

me

dio

Cri

tici

dad

Seve

rid

ad

Fre

cuen

cia

Cri

tici

dad

Seve

rid

ad

Fre

cuen

cia

Cri

tici

dad

Seve

rid

ad

Fre

cuen

cia

Cri

tici

dad

Seve

rid

ad

Fre

cuen

cia

Cri

tici

dad

31 1 3 4 3 3 6 1 2 3 2 3 5 1,75 2,75 4,5,

32 3 3 6 4 3 7 2 4 6 3 3 6 3,00 3,25 6,25

33 3 3 6 4 3 7 2 3 5 2 4 6 2,75 3,25 6,00

34 3 3 6 4 4 8 2 2 4 1 2 3 2,50 2,75 5,25

35 2 2 4 2 2 4 2 2 4 4 2 6 2,50 2,00 4,50

36 3 3 6 3 3 6 2 3 5 2 4 6 2,50 3,25 5,75

37 3 4 7 4 4 8 3 2 5 3 3 6 3,25 3,25 6,50

38 3 3 6 3 3 6 3 3 6 3 3 6 3,00 3,00 6,00

39 3 4 7 3 3 6 3 4 7 2 4 6 2,75 3,75 6,50

40 3 3 6 4 3 7 3 3 6 1 4 5 2,75 3,25 6,00

41 4 3 7 4 4 8 3 2 5 3 2 5 3,50 2,75 6,25

42 3 3 6 3 3 6 3 2 5 2 1 3 2,75 2,25 5,00

43 4 4 8 3 3 6 4 4 8 4 4 8 3,75 3,75 7,50



Anexo 5: Evaluación Heurística Sistema Biblioteca PUCV



Pro

ble

ma

Evaluador 1 Evaluador 2 Evaluador 3 Evaluador 4 Evaluador 5

Pro

med

io

Seve

rid

ad

Pro

med

io

Frec

uen

cia

Pro

med

io

Cri

tici

dad

Seve

rid

ad

Frec

uen

cia

Cri

tici

dad

Seve

rid

ad

Frec

uen

cia

Cri

tici

dad

Seve

rid

ad

Frec

uen

cia

Cri

tici

dad

Seve

rid

ad

Frec

uen

cia

Cri

tici

dad

Seve

rid

ad

Frec

uen

cia

Cri

tici

dad

1 2 2 4 2 3 5 3 4 7 4 4 8 3 3 6 2,80 3,20 6,00

2 3 3 6 2 3 5 2 3 5 4 3 7 3 2 5 2,80 2,80 5,60

3 2 3 5 2 2 4 3 2 5 2 3 5 3 2 5 2,40 2,40 4,80

4 4 4 8 3 2 5 2 1 3 3 3 6 3 3 6 3,00 2,60 5,60

5 4 3 7 2 2 4 2 2 4 3 3 6 3 2 5 2,80 2,40 5,20

6 4 4 8 3 2 5 3 4 7 4 3 7 3 3 6 3,40 3,20 6,60

7 3 2 5 2 2 4 3 4 7 3 2 5 2 3 5 2,60 2,60 5,20

8 3 3 6 2 2 4 2 3 5 3 2 5 3 2 5 2,60 2,40 5,00

9 3 2 5 4 2 6 2 4 6 3 2 5 3 3 6 3,00 2,60 5,60

10 3 3 6 3 2 5 2 2 4 3 3 6 3 2 5 2,80 2,40 5,20

11 3 3 6 2 2 4 2 2 4 3 3 6 3 2 5 2,60 2,40 5,00

12 3 4 7 3 3 6 3 3 6 2 3 5 3 3 6 2,80 3,20 6,00

13 2 3 5 2 3 5 2 4 6 2 3 5 3 3 6 2,20 3,20 5,40

14 3 4 7 3 2 5 3 2 5 2 4 6 3 3 6 2,80 3,00 5,80

15 2 3 5 3 2 5 2 3 5 3 2 5 2 3 5 2,40 2,60 5,00

16 2 1 3 2 3 5 3 3 6 3 3 6 2 4 6 2,40 2,80 5,20

17 3 3 6 2 3 5 2 2 4 2 4 6 3 3 6 2,40 3,00 5,40

18 3 2 5 3 2 5 3 2 5 2 3 5 3 2 5 2,80 2,20 5,00

19 3 3 6 3 2 5 3 3 6 3 4 7 2 4 6 2,80 3,20 6,00

20 3 3 6 4 3 7 3 4 7 3 4 7 3 3 6 3,20 3,40 6,60

21 2 4 6 2 3 5 2 2 4 0 0 0 1 3 4 1,40 2,40 3,80

22 4 4 8 3 4 7 3 3 6 3 4 7 4 3 7 3,40 3,60 7,00

23 3 3 6 3 2 5 3 4 7 3 2 5 2 2 4 2,80 2,60 5,40

24 4 4 8 4 2 6 3 3 6 4 4 8 3 4 7 3,60 3,40 7,00

25 3 4 7 4 3 7 4 3 7 3 4 7 3 4 7 3,40 3,60 7,00

26 2 3 5 4 4 8 2 3 5 2 4 6 2 3 5 2,40 3,40 5,80

27 3 3 6 3 4 7 2 3 5 4 3 7 4 3 7 3,20 3,20 6,40

28 3 3 6 3 2 5 2 4 6 4 4 8 2 4 6 2,80 3,40 6,20

29 2 2 4 3 3 6 2 2 4 4 4 8 3 2 5 2,80 2,60 5,40

30 2 3 5 4 3 7 3 4 7 3 3 6 2 2 4 2,80 3,00 5,80



Pro

ble

ma

Evaluador 1 Evaluador 2 Evaluador 3 Evaluador 4 Evaluador 5

Pro

med

io

Seve

rid

ad

Pro

med

io

Frec

uen

cia

Pro

med

io

Cri

tici

dad

Seve

rid

ad

Frec

uen

cia

Cri

tici

dad

Seve

rid

ad

Frec

uen

cia

Cri

tici

dad

Seve

rid

ad

Frec

uen

cia

Cri

tici

dad

Seve

rid

ad

Frec

uen

cia

Cri

tici

dad

Seve

rid

ad

Frec

uen

cia

Cri

tici

dad

31 2 3 5 3 3 6 3 2 5 3 4 7 3 3 6 2,80 3,00 5,80

32 2 3 5 3 3 6 3 2 5 2 4 6 3 2 5 2,60 2,80 5,40

33 2 3 5 3 3 6 1 1 2 3 4 7 2 2 4 2,20 2,60 4,80

34 2 3 5 2 3 5 2 2 4 1 4 5 3 3 6 2,00 3,00 5,00

35 4 4 8 4 2 6 3 3 6 4 4 8 3 4 7 3,60 3,40 7,00

36 3 4 7 4 3 7 3 3 6 4 4 8 3 4 7 3,40 3,60 7,00

37 4 4 8 3 3 6 2 2 4 3 4 7 4 3 7 3,20 3,20 6,40

38 3 4 7 2 2 4 2 2 4 2 4 6 3 2 5 2,40 2,80 5,20

39 2 2 4 2 2 4 2 3 5 3 3 6 3 2 5 2,40 2,40 4,80

40 4 3 7 3 3 6 2 2 4 4 3 7 3 4 7 3,20 3,00 6,20

41 3 4 7 3 3 6 3 3 6 4 4 8 3 3 6 3,20 3,40 6,60

42 4 4 8 2 3 5 3 2 5 3 3 6 3 2 5 3,00 2,80 5,80

43 3 3 6 3 2 5 3 3 6 2 3 5 2 3 5 2,60 2,80 5,40

44 4 4 8 2 2 4 2 3 5 3 4 7 2 3 5 2,60 3,20 5,80

45 3 3 6 4 2 6 4 3 7 3 3 6 3 2 5 3,40 2,60 6,00

46 3 4 7 1 1 2 4 3 7 3 3 6 3 3 6 2,80 2,80 5,60

47 3 4 7 4 2 6 4 3 7 4 2 6 3 2 5 3,60 2,60 6,20

48 4 4 8 4 4 8 4 4 8 2 4 6 4 3 7 3,60 3,80 7,40

49 3 4 7 4 4 8 3 3 6 3 4 7 4 3 7 3,40 3,60 7,00

50 3 3 6 4 3 7 4 3 7 3 4 7 4 3 7 3,60 3,20 6,80

51 2 3 5 4 2 6 4 2 6 2 3 5 3 2 5 3,00 2,40 5,40

52 3 3 6 4 4 8 4 2 6 3 4 7 2 3 5 3,20 3,20 6,40

53 4 4 8 4 4 8 4 4 8 0 0 0 3 4 7 3,00 3,20 6,20

54 3 3 6 3 3 6 3 4 7 2 4 6 3 4 7 2,80 3,60 6,40

55 4 4 8 4 4 8 4 4 8 4 4 8 4 4 8 4,00 4,00 8,00



Anexo 6: Listado de Tareas Experimentos Formales Prototipo Web

Cadena Supermercados



Prueba de Usabilidad

Realice las tareas que se muestran a continuación.

Usted dispone de 30 minutos para realizar la prueba.

Ante cualquier duda o consulta diríjase al evaluador.

1. Solicite la obtención de la Tarjeta Presto. a. Ingrese los datos solicitados b. Confirme la solicitud (los datos mostrados no corresponderán a los ingresados por

usted). c. Vuelva a la página de inicio.

2. Simule la petición de un crédito. a. Ingrese los valores solicitados. b. Realice la simulación (los datos mostrados no corresponderán a los ingresados por

usted). c. Vuelva a la página de inicio.

3. Busque información sobre las tiendas y locales que aceptan la tarjeta Presto.

a. Ingrese los datos solicitados para realizar una búsqueda de tiendas.

b. Realice le búsqueda (los datos mostrados no corresponderán a los ingresados por usted).

c. Anote los beneficios de la primera farmacia que se muestra al buscar Remedios:

___________________________________________________

d. Vuelva a la página de inicio.

4. Busque información acerca de productos con descuento que se obtienen con tarjeta Presto. a. Busque productos con ahorro exclusivo en Líder. b. Anote la oferta correspondiente a Producto Destacado:

____________________________________________________

¡Gracias por su colaboración!



Anexo 7: Listado de Tareas Experimentos Formales Navegador

Académico PUCV







1. Busque información del alumno “Cristian Gonzalez Diaz”.

Ingrese el último período académico en que estuvo matriculado en la universidad:

_______________ (Año/Semestre).

Ingrese la cantidad de créditos totales aprobados por el alumno: _______________ .

Ingrese la ciudad de domicilio del estudiante en períodos académicos:

_________________________________ .

Vuelva a la página inicial.

2. Busque información del ayudante “Danilo Gonzalez Diaz”.

Ingrese los cursos dictados durante el 2do semestre 2005: __________________________________

(claves).

Ingrese la cantidad de alumnos reprobados en el ramo AGR357: ________________ .


3. Busque información sobre la escuela de agronomía.

Ingrese la cantidad de asignaturas de Estudio General disponibles para los alumnos de la

escuela de agronomía durante el 1er semestre 2008:

________________________________ .

Ingrese el cupo y el total de inscritos de la asignatura “El Hombre y los Juegos”:

Cupo: _______________________ . Total Inscritos: _______________________ .


¡¡¡ Gracias por su colaboración !!!



Anexo 8: Listado de Tareas Experimentos Formales Sistema Biblioteca

PUCV







1. Busque información sobre la Biblioteca Mayor de Ingeniería.

Ingrese el horario de atención: ________________________________________________________.


2. Busque información sobre un libro de la red de bibliotecas.

Busque el libro “Usabilidad. Diseño de Sitios Web” de Jakob Nielsen, disponible en la

Biblioteca Mayor de Ingeniería.

Ingrese la cantidad de ejemplares disponibles en dicha biblioteca: ________________.


3. Busque información sobre una revista digital.

Busque la revista “No Solo Usabilidad”.

Ingrese la fecha de la publicación relacionada con “Eye-Tracking”: ________________.


4. Busque información sobre una tesis.

Busque la tesis “Evaluación de Usabilidad por Métodos Formales”.

Ingrese el nombre del alumno autor: _________________________________________________.


¡¡¡ Muchas gracias por su colaboración !!!



Anexo 9: Cuestionario Prototipo Web Cadena Supermercados



Cuestionario Post-Test

Evalúe cada una de las siguientes preguntas relacionadas con el prototipo del sitio de la

cadena de supermercados, con una nota entre 1 y 7. En cada pregunta se explica el significado de las

notas mínima y máxima.

1. La disposición de la

información en el sitio es: Muy difusa 1 2 3 4 5 6 7 Muy clara

2. La navegabilidad del sitio es: Muy confusa 1 2 3 4 5 6 7 Muy intuitiva

3. ¿El diseño del sitio es

consistente? No 1 2 3 4 5 6 7 Sí

4. ¿El sitio se preocupa de la

satisfacción del usuario? Nunca 1 2 3 4 5 6 7 Definitivamente

5. La funcionalidad del sitio es: Inútil 1 2 3 4 5 6 7 Muy útil

6. ¿Visitaría nuevamente el

sitio? Nunca 1 2 3 4 5 6 7 Definitivamente

7.

¿Cómo evalúa su experiencia

como colaborador de esta

prueba?

Muy

desagradable 1 2 3 4 5 6 7 Muy agradable

Muchas gracias por su cooperación!!!



Anexo 10: Cuestionario Navegador Académico PUCV




Evalúe cada una de las siguientes preguntas relacionadas con el Navegador Académico, con

una nota entre 1 y 7. En cada pregunta se explica el significado de las notas mínima y máxima.









6. El mecanismo de búsqueda

del sitio es: Muy ineficiente 1 2 3 4 5 6 7 Muy eficiente

7. ¿Cómo evalúa su experiencia

como usuario del sitio?

Muy





Anexo 11: Cuestionario Sistema Biblioteca PUCV




Evalúe cada una de las siguientes preguntas relacionadas con el Sistema de Biblioteca de la

PUCV, con una nota entre 1 y 7. En cada pregunta se explica el significado de las notas mínima y

máxima.







5. ¿El mecanismo de búsqueda

del sitio es eficiente? No 1 2 3 4 5 6 7 Sí

6. ¿El mecanismo de búsqueda

del sitio es claro e intuitivo? No 1 2 3 4 5 6 7 Sí

7. El sistema de ayuda del sitio

es: Pésimo 1 2 3 4 5 6 7 Muy bueno



9. ¿Cómo evalúa su experiencia

como usuario del sitio?

Muy


10.

De ser necesario, ¿Hacia

dónde se inclinaría para

cumplir sus intereses?

Bibliotecas

Físicas 1 2 3 4 5 6 7

Sistema Web

Biblioteca

11. ¿Volvería a ingresar al sitio? No 1 2 3 4 5 6 7 Sí


tesis web transaccionales-rof

Internet