1

Diseño de Interacción Centrado en el

Usuario

Trabajo Final

ANÁLISIS DE USABILIDAD DE LA APLICACIÓN:

OPENCONF: PEER REVIEW & CONFERENCE MANAGEMENT

Buselli, Mauro

9 de marzo de 2010

2

Índice general

1. Introducción ........................................................................................................................... 4

2. Evaluación de principios de usabilidad.................................................................................... 5

a. Learnability ........................................................................................................................ 5

b. Flexibility ............................................................................................................................ 7

c. Robustness ....................................................................................................................... 11

3. Evaluación de heurísticas de usabilidad ................................................................................ 12

a. Visibility of system status ................................................................................................. 12

b. Match between system and the real world ....................................................................... 13

c. User control and freedom ................................................................................................ 15

d. Consistency and standards ............................................................................................... 15

e. Help users recognize, diagnose and recover from errors ................................................... 15

f. Error prevention ............................................................................................................... 16

g. Recognition rather than recall .......................................................................................... 16

h. Flexibility and efficiency of use ......................................................................................... 17

i. Aesthetic and minimalist design ....................................................................................... 17

j. Help and documentation .................................................................................................. 18

4. Evaluación según guías de diseño de interfaz ....................................................................... 18

a. Estructura ........................................................................................................................ 18

i. Ventanas ...................................................................................................................... 18

ii. Cajas de Diálogo ........................................................................................................... 18

iii. Tabs ............................................................................................................................. 18

iv. Menús .......................................................................................................................... 19

v. Barras de herramientas (toolbars) ................................................................................ 20

vi. Relación toolbars, botones y menúes ........................................................................... 20

b. Interacción ....................................................................................................................... 20

i. Command Buttons ........................................................................................................ 20

ii. Radio Buttons ............................................................................................................... 20

iii. Check Boxes ................................................................................................................. 20

iv. Cajas de texto ............................................................................................................... 21

3

v. List Boxes ..................................................................................................................... 21

vi. Tablas ........................................................................................................................... 21

vii. Sliders ....................................................................................................................... 21

c. Presentación .................................................................................................................... 21

i. Layout .......................................................................................................................... 21

ii. Fuentes ........................................................................................................................ 22

iii. Colores ......................................................................................................................... 23

5. Conclusión ........................................................................................................................... 24

4

1. Introducción

El trabajo consiste en realizar un análisis de la usabilidad de la aplicación asignada “Openconf:

Peer Review & Conference Management” teniendo en cuenta los principios, guías y heurísticas de

usabilidad.

La aplicación OpenConf es un sistema para la administración de peer-review que facilita la

presentación y revisión de procesos para conferencias, talleres, encuentros, etc. El software es

flexible y puede también puede ser usado para publicaciones (journals) y libros. Esta desarrollada

usando el lenguaje PHP y la base de datos MySQL, requiere un servidor. Para el corriente trabajo

fue instalada la “Community Edition”, edición con menos características pero gratuita.

5

2. Evaluación de principios de usabilidad

Los principios de usabilidad que se usaran fueron propuestos por Dix[1] y son reglas abstractas y

generales, que en esta ocasión serán aplicadas al diseño de la aplicación de software de OpenConf.

Estos principios se dividen en tres categorías principales: learnability, flexibility y robustness. Cada

una de estas categorías se componen de más principios específicos que la determinan.

a. Learnability

Se analizará el entendimiento del sistema desde el punto de vista de lo familiar que resulta y cuán

fácil es comprender la funcionalidad que ofrece desde que se comienza a interactuar con él.

i. Predictability

En un primer vistazo el programa corre en un explorador web, por lo que tiene algunas de las

características más generales de una página web, como menús en letra color azul que al posicionar

el mouse sobre ellas cambian de color, invitando a presionarlos y haciendo deducible la acción y el

lugar en donde se ejecutará.

Un usuario no familiarizado con la designación de nombres (terminología del dominio) necesitará

un tiempo y esfuerzo extra para entender las acciones ligadas a ellos. Este es el caso de la palabra

“Submission“ para representar las propuestas, presentaciones o artículos que un autor expondrá

para que sean inspeccionadas; como también la terminología “Program Chair” para hacer

referencia al director del comité.

La simpleza de la interfaz usada hace que claramente se visualice la forma de interacción, y que

con poco esfuerzo no haya inconvenientes en accionar la funcionalidad deseada en cada estado en

que se encuentra el sistema. La visibilidad de operaciones puede ser vista a lo largo de toda la

aplicación en forma de menús, que muestran en todo momento qué operaciones están

disponibles.

ii. Synthesizability

Este aspecto se cumple correctamente ya que en todo momento se puede visualizar el estado en

que se encuentra el sistema. En cada selección de alguna de las opciones, la misma es mostrada en

la parte superior de la pantalla. Además se puede observar el rol que cumple el usuario, ya sea de

director del comité (chair), miembro del mismo o autor de alguna presentación, manteniendo así

6

el estado en que nos encontramos. Estas características proporcionan cierto feedback e

información confiable que otorgan una presunción del efecto de las acciones futuras.

iii. Familiarity

En general las características con que cuenta la aplicación para interactuar con el usuario son una

combinación de las usadas en páginas web (point and click) y del tipo form-fills. Ambas son básicas

y cualquier usuario novato se encuentra familiarizado con ellas en experiencias pasadas en otros

sistemas, por lo que no le debería costar trabajo desempeñar las acciones deseadas. En cuanto a

los Form-fills, características como botones, radio buttons, check boxes, cajas de texto, etc.

cuentan con una propuesta de acción ya bien estudiada y conocida.

Por otro lado, hay determinadas acciones que no están visibles, y que se hace saber de la misma

por medio de un texto que, en muchas ocasiones, ni siquiera se encuentra bien ubicado y puede

ser pasado por alto. Como ejemplo de esto se puede ver la siguientes imágenes:

Ilustración 1: ejemplo de acción que no se ofrece correctamente (Affordance).

7

iv. Consistency

La consistencia es un punto fuerte en toda la aplicación, debido a que se mantiene la misma

representación de los menús, la misma apariencia visual en las diferentes partes del sistema, la

manera de requerir entrada de datos mediante formularios (form-fills) y la manera de presentar la

información en forma de cuadros, la terminología se mantiene invariante, al igual que los

mensajes de advertencia o de error, los controles o botones para cancelar o efectuar una acción se

encuentran en las mismas posiciones, etc.

Al mantenerse esta consistencia facilita el aprendizaje de la aplicación, y disminuye la tasa de

equivocaciones.

v. Generalizability

Debido a que básicamente la interfaz está basada en point-and-click y form-fills, y a que son

simples, un usuario está acostumbrado a este tipo de interacción. Por lo que la experiencia en

otras aplicaciones facilita en gran medida su aprendizaje.

b. Flexibility A continuación se analizarán los diferentes principios que componen la flexibilidad del sistema.

Ilustración 2: ejemplo de información que no se destaca de una manera directa.

8

i. Dialogue initiative

El control del flujo de diálogo lo posee el usuario, ya que es este el que inicia las acciones. Gran

parte de los mensajes corresponden a errores de llenado de formularios, algunas veces esto es

necesario pero muchas otras debería llamarse la atención sobre algún campo del formulario mal

cargado en lugar de presentarlo como error al terminar de completarlo.

Considerando las tareas, todas posibilitan abandonarlas o reiniciarlas. En este caso la suspensión

de una tarea no tiene sentido ya que son de naturaleza de ejecución inmediata.

ii. Multi-threading

El sistema permite la ejecución de tareas en simultáneo, esto se realiza mediante la simultánea

conexión al sistema, por medio de internet, de diferentes personas en diferentes máquinas, cada

una de las cuales cumpliendo roles posiblemente diferentes y ejecutando tareas en simultaneidad.

Cabe aclarar que en una sola máquina el sistema no permite esta característica para un solo

usuario, pero de todas maneras no es necesaria debido a que la naturaleza de las operaciones que

pueden llevarse a cabo es secuencial, además ninguna de ellas tiene una demora extensa como

para necesitar la ejecución concurrente.

iii. Task migratability

La tarea particular que posee el director (chair) de asignar inspectores (reviews) y defensores

(advocates) a cada una de las presentaciones (submissions), puede tener diversos conflictos, como

lo son pertenecer a la misma organización, tener diferentes temas de interés, o conflictos

personales. Por lo tanto si es realizada manualmente esta tarea tiene gran probabilidad conllevar a

errores y conflictos. Para solucionar esta condición propensa a error el sistema tiene la opción de

realizarla automáticamente, permitiendo escoger diversas configuraciones, como se puede

apreciar en la siguientes imágenes:

9

La migrabilidad tareas en estos casos se encuentra en la selección manual o automática de la

asignación.

Otra funcionalidad que provee soporte para realizarla automáticamente es el envío de emails, en

la cual se permite escoger entre diversos destinatarios como lo pueden ser todos los autores,

autores estudiantes, autores a los que les falta subir el archivo, autores con la presentación

aceptada o rechazada; como así también el comité del programa o a los inspectores con diversas

condiciones. Además, brinda la posibilidad de usar un template para el texto del mail según su

destinatario. El control de esta funcionalidad puede pasar de tenerlo el sistema o el usuario, en

mayor o en menor medida, para evitar equivocaciones en una actividad rutinaria. En la siguiente

imagen se observa este caso:

Ilustración 4: Migrabilidad en la tarea de envío de emails.

Ilustración 3: Asignación de inspectores manual e automática.

Ilustración 3: Asignación automática de inspectores a presentaciones.

10

iv. Substitutivity

El sistema permite la selección de tipos diferentes de archivos a publicar.

Pero en general el sistema no permite la selección de métodos de interacción adaptables al

usuario, como por ejemplo no permite cambiar la manera de representación de los resultados, ni

diferentes maneras alternativas de desempeñar acciones.

v. Customizability

El sistema es customizable en algunos aspectos pero en otros no.

Entre los aspectos customizables están:

Configuración de formato de archivos válidos, y verificación de que los archivos publicados

se encuentren en un formato válido.

Usar defensores (advocators) o no.

Configuración del formulario de una presentación.

Configuración del texto de mensajes de error o advertencias sobre el formulario de

presentaciones.

Configuración de diversas notificaciones vía email en diferentes oportunidades.

Configuración de visibilidad de presentaciones para los diferentes miembros del comité.

Diferentes temas de presentaciones.

Diferentes estados para permitir o no nuevas presentaciones, inspecciones, etc.

Entre los aspectos no customizables están:

No permite short-cuts.

No permite adaptar las opciones de visualización.

No permite adaptar cantidad o ubicación de métodos en menús de más rápido acceso.

Etc.

11

c. Robustness A continuación se analizarán los diferentes principios que comprenden la robustez del sistema.

i. Observability

El usuario puede evaluar en todo momento el estado interno del sistema observando la parte

superior de la pantalla, en la cual puede percibir en qué opción se encuentra o qué acción se está

ejecutando.

Un punto en contra es la exhibición de gran cantidad de información aclarativa o de advertencia

en diferentes lugares (principalmente en formularios) que agobian al usuario, y hacen menos claro

el estado y un poco más lento el aprendizaje.

Otro de los problemas es que no desactiva acciones que no pueden ser tomadas o que conllevan a

un error.

Una vez que en uno de los menús se elige una tarea, no se visualiza el resto de las tareas a ser

ejecutadas, se pierde la noción del lugar en donde se está. Teniendo que presionar el botón “back”

del explorador para poder retornar al estado anterior.

En algunos casos los feedback por errores producidos se muestran en una pantalla nueva,

teniendo nuevamente que presionar “back” para retomar la pantalla anterior y en ese punto

buscar el lugar en que se produjo el error mencionado, pero en ese punto actual el mensaje no

está disponible por si surgen dudas.

El problema con los feedback es reiterado ya que cuando se completa una acción aparece una

nueva pantalla que solo certifica la correcta acción, pero no da ninguna elección para retomar el

menú principal.

En conclusión, la información sobre dónde estoy, dónde he estado y qué puedo hacer ahora no

siempre están visibles o no se logra percibir.

ii. Recoverability

Los errores que pueden ocurrir en el sistema no son graves, y siempre es posible tomar una acción

correctiva o cancelar la acción. Los principales errores que se pueden producir son por el llenado

incorrecto o no llenado de campos de un formulario.

Uno de los lugares en donde el posible error se hace más peligroso el sistema no se hace cargo de

la recuperación de los datos perdidos en el formulario, mostrando la siguiente advertencia:

“Before submitting your review, consider printing it out and copying/pasting the descriptive text

12

fields to a text document. This way, in case of a network/system problem, you will have all the

information if it needs to be re-entered.”

iii. Responsiveness

Debido a que todas las acciones son de tiempo de respuesta rápido, la respuesta del sistema no

tiene problemas.

iv. Task conformance

Los servicios proveídos por el sistema soportan todas las tareas que el usuario necesita

desempeñar, tanto para el rol de director como para los de inspector y defensor. Son simples de

entender y fáciles de ubicar. Además el sistema proporciona una serie de opciones para listar las

presentaciones de acuerdo con ciertos criterios.

3. Evaluación de heurísticas de usabilidad

A continuación se evaluará la aplicación basando el estudio en los diez principios de usabilidad

propuestos por Nielsen[2], estos son diez principios generales para el diseño de interfaces de

usuario, en este caso son llamadas “heurísticas” debido a que se encuentran más en una

naturaleza de principios guías para ojear en lugar de lineamientos de usabilidad específicos.

a. Visibility of system status En todo momento se puede apreciar el estado en que se encuentra el sistema. Estos estados no

son acciones complejas sino la elección de una actividad en uno de los menús, mediante feedbacks

claros se puede visualizar en la parte superior de la pantalla el titulo del seminario o conferencia

en la que estamos trabajando, el rol que cumplimos, la opción elegida por el usuario, entre otras.

En la siguiente figura se pueden ver estos tipos de feedback nombrados.

13

b. Match between system and the real world

Los nombres tomados para la terminología del sistema no son lo suficientemente generales, y esto

es un problema dado que cuenta con flexibilidad en la forma de uso, es decir que puede ser

utilizado para ofrecer peer-reviews en general. Entre los nombres conflictivos se encuentran

submission, chair, advocators, etc., estos producen una confusión en un usuario que no está

familiarizado con el dominio particular y provocan una merma en la facilidad de aprendizaje.

Cuando se analiza el orden en que aparece la información se nota un inconveniente en la

organización del menú principal del sistema, en el cual se mezclan funciones que pueden ser

accionadas por una persona que está cumpliendo el rol de autor, con opciones que permiten

registrarse a otros roles. Debería haber un nivel de abstracción superior, en el que un usuario

Ilustración 5: Visibilidad del estado del sistema. Feedback informativos.

Ilustración 6: Visibilidad del estado del sistema. Remarcación de opciones a elegir al pasar el cursor sobre ellas.

14

pueda en primer lugar elegir el rol y luego concretar sus actividades. Esta información no aparece

en orden natural y lógico.

Otro inconveniente muy importante se encuentra en la utilización excesiva de id’s para identificar

tanto a las presentaciones como también a los miembros del comité. En todo momento se usan

los id’s y en el caso en que un autor desee modificar alguna de sus presentaciones este deberá

recordarlo, lo que puede acarrear problemas. Todos los listados que se emiten poseen id’s, lo que

la mayor parte del tiempo es irrelevante para un usuario y por sobre todas las cosas no pertenece

a su lenguaje natural.

Por otro lado, en diversos logares se muestran variables raras y de difícil explicación, esto puede

confundir a usuarios que ni siquiera tienen una noción clara del concepto. En la siguiente imagen

se puede distinguir este uso de variables en la configuración de envíos de email a diferentes

destinatarios:

Ilustración 7: Información que no aparece en orden natural y lógico.

Ilustración 8: Ejemplo de listado de presentaciones en el que se usan id’s para identificarlas.

15

c. User control and freedom Las acciones que se pueden tomar son de carácter instantáneo. En el momento de concretar una

publicación de una presentación, si su autor se arrepiente de haberlo hecho, el sistema no le

provee un mecanismo de “undo” inmediato para solucionar su problema, pero de todas maneras

en el menú principal tiene la opción de modificarla o retirarla.

En general el sistema no provee mecanismos de “undo” para acciones de eliminación de

presentaciones o integrantes del comité. Más aún en el segundo caso se remueven

permanentemente todos los registros asociados a las presentaciones que inspeccionaban o

defendían. Esto puede incidir en cometer graves errores de los cuales no hay vuelta atrás.

d. Consistency and standards En cuanto a la consistencia y a los estándares el usuario no debe preocuparse de cometer errores

ya que en todo el sistema se sigue la misma convención de nombres, funciones y acciones. Esto

además facilita el aprendizaje.

e. Help users recognize, diagnose and recover from errors Uno de los errores más comunes que se pueden cometer en el sistema se encuentran en el

llenado de formularios. En este simple caso se notifican los inconvenientes de una forma correcta,

clara y precisa.

Un posible error o inconsistencia se puede presentar en caso de que el archivo asociado a una

presentación no coincida con el tipo de archivo que se especifica en la misma. Esta inconsistencia

no se verifica automáticamente, además de ser un dato redundante.

Ilustración 9: Ejemplo de uso de variables en el envío de email. Esta cuestión no pertenece al lenguaje natural del usuario.

16

Bajo la opción de “Upload File”, que permite asociar un archivo a una planilla que encabeza la

presentación, hay una restricción del tamaño máximo del archivo de 2mb, en caso de no cumplir

con ella el error mostrado es el siguiente: “The file failed to load. Please try again. If the problem

persists, contact the Program Chair”, como se puede observar no indica el problema específico ni

sugiere una solución coherente.

f. Error prevention Sin duda la interfaz no está diseñada con este criterio, son muchos los casos en que no se

chequean los datos de entrada ni bien son ingresados (como sería preferible), y otros en los que

las inconsistencias no se detectan en ningún momento. Un ejemplo de este caso se puede ver en

reiteradas ocasiones, en donde se deja la comprobación de ciertos aspectos a cargo del usuario,

como se puede observar en las siguientes imágenes:

g. Recognition rather than recall En ocasiones un usuario desea poder observar las presentaciones en las que forma parte como

autor, ya sea para modificarlas, editarlas, eliminarlas o solo verlas, pero la manera de tener acceso

a cada una de ellas es recordando su id y contraseña particulares. Esta manera de operar no es

muy adecuada ya que aumenta la carga de memoria que necesita el usuario no solo para números

y códigos, sino también para mantener en mente cada una de las presentaciones que ha realizado.

Una posible opción para mejorar este punto es registrar a cada usuario solo una vez pidiendo su

contraseña, y en este punto tener visible todas las presentaciones que tiene asociadas, para que

Ilustración 10: Prevención de error sin chequeo automático en la opción “Upload File”.

Ilustración 11: Prevención de errores en la realización de una presentación. No se elimina la condición propensa a error desactivando el botón si los campos no están correctamente llenados.

17

las pueda operar según sus necesidades, disminuyendo en gran medida la necesidad de recordar

detalles.

h. Flexibility and efficiency of use La interfaz no posee aceleradores que incrementen la velocidad de alcanzar alguna función, y por

ende un usuario tampoco puede ajustar a su medida alguna acción para alcanzar una interacción

más rápida.

i. Aesthetic and minimalist design La interfaz posee extensos formularios en los que el enfoque minimalista no se aprecia, éstos

poseen varias unidades de información (texto en color verde) que distraen y los hacen más

difusos. En las siguientes imágenes se pueden apreciar estos formularios:

Ilustración 12: Extenso formulario que contiene demasiadas y extensas unidades de información.

Ilustración 13: Extenso formulario que contiene demasiadas y extensas unidades de información.

18

En cuanto a los menús estos poseen un alto contraste con el fondo, los títulos tienen buena

visibilidad.

j. Help and documentation Sólo existe una ayuda para el director (chair), no habiendo ninguna ayuda para los demás

miembros del comité o autores. Esta ayuda no está accesible en todo momento, sólo en el

menú principal del director, no es extensa, está enfocada en las tareas que puede llevar a cabo

y es sólo para comenzar.

4. Evaluación según guías de diseño de interfaz

a. Estructura

i. Ventanas El sistema corre en un explorador web, por lo que cuenta con una única ventana, en casos muy

particulares es posible trabajar, mediante la selección de una opción, en una nueva ventana

separada.

En ningún caso se observó la utilización de scroll horizontal.

ii. Cajas de Diálogo No son utilizadas en el sistema. Éstas serían de gran utilidad ya que el sistema se caracteriza por

tener tareas discretas y pequeñas.

iii. Tabs La interfaz utiliza tabs para opciones de menú más generales, todos se relacionan con un rol que el

usuario juega, la información que proveen es independiente entre sí.

19

iv. Menús Cabe aclarar que en este caso se considera el menú al texto navegable, y no a la barras de tareas

de una aplicación convencional que corre en una ventana estándar, ya que aunque lucen diferente

el principio es el mismo.

Los menús son la principal forma de navegación del sistema. En algunos casos no se encuentran

bien rotulados, como es el caso del menú de “Authors” que se ilustra en la imágen:

Estos menús no poseen aceleradores.

No se utilizan barras espaciadoras, pero en lugar de esto en algunos lugares existen un

agrupamiento de ítems marcado por un espacio de separación mayor.

No se proveen menús del tipo pop-up.

Ilustración 14: Ejemplo de uso de tabs.

Ilustración 15: Ejemplo de mala rotulación en el menú. “Upload File” y “View File” están asociadas a una determinada presentación (submission), pero en el menú esto no se visualiza.

20

v. Barras de herramientas (toolbars)

No posee.

vi. Relación toolbars, botones y menúes Todas las acciones se encuentran en menús.

b. Interacción

i. Command Buttons El sistema utiliza botones para acciones inmediatas, con una rotulación consistente y todos ellos

mantienen un similar tamaño. En general el uso de botones es adecuado.

ii. Radio Buttons Estos son usados en diferentes lugares, en algunos de los cuales no cumplen con las sugerencias,

por ejemplo en la siguiente imagen se puede observar que no se encuentran alineados

verticalmente (Open-Closed) y se hace uso de botones binarios, para este caso deberían ser

usados check box.

iii. Check Boxes Su uso es correcto a lo largo de toda la aplicación.

Ilustración 16: Uso de Radio-Buttons inadecuado.

21

iv. Cajas de texto Son usadas como la principal forma para ingresar datos. En ningún momento se usan datos de solo

lectura que contengan un borde. Todas se encuentran debidamente alineadas y rotuladas en su

izquierda con el uso indicado del “:”.

v. List Boxes Son correctamente usadas. Entre estos usos se encuentra la selección del país de origen, realizar

asignaciones de inspectores a presentaciones (con selección múltiple), etc.

vi. Tablas La interfaz no las utiliza, y no son necesarias.

vii. Sliders La interfaz no los utiliza ya que en ninguna circunstancia hay necesidad de su uso.

c. Presentación A continuación se analizará la manera en que se expone la información.

i. Layout Todas las ventanas están diseñadas de forma vertical, lo cual es bueno porque no requiere de

barras de scroll horizontales.

Un punto importante en contra en este aspecto es que muchas de ellas no tienen una cantidad

apropiada de información debido a que no están organizadas correctamente. Este es el caso de los

Ilustración 17: Correcto uso de check-boxes.

22

formularios, en los que además de ser extensos, mucha información se puede presentar de una

manera más compacta, por ejemplo el ingreso de autores a una presentación está preparado para

contener hasta cinco de ellos, si esta requiere menos entonces muchos campos quedan vacíos, en

cambio si se requieren más, sólo se otorga un campo para ingresar toda la información extra. Esta

entrada de información debería ser mucho más dinámica y estética. Este último aspecto se puede

observar en la siguiente imagen:

En general, la disposición espacial no es un punto fuerte de la intefaz y deja mucho que desear, ya

que los menús están dispuestos a lo largo de la pantalla sobre el sector izquierdo, quedando

demasiado espacio en blanco en la zona centro y derecha de la pantalla, lo que hace necesario la

utilización del scroll para visualizar la totalidad de las opciones del menú.

ii. Fuentes En general el uso de fuentes no tiene ningún problema. Se usa fuentes en negrita para enfatizar,

se mantienen consistentes sus tamaños y sus tipo invariantes.

Ilustración 18: Organización y presentación de la información inadecuada.

23

iii. Colores Los colores se mantienen estables y no se usan en gran medida. El principal uso de colores se

encuentra en las tablas de listados, en donde se respetan el significado cultural para los colores

rojo, amarillo y verde. En toda la interfaz se hace uso de fondos claros para un mejor contraste. No

se observan combinaciones difíciles de leer.

Ilustración 19: Ejemplo de uso de colores, donde se respeta el significado cultural.

24

5. Conclusión

Por lo analizado en el trabajo se puede llegar a la conclusión de que la interfaz de la aplicación

dista mucho de gozar una buena usabilidad, ya que esta, entre otras cosas, no tiene una buena

organización de los menús, no previene las condiciones propensas a error, no ofrece recuperación

de errores o equivocaciones graves, sobrecarga la memoria del usuario pidiendo id’s y

contraseñas, mucha información es exhibida con sus números de id’s (irrelevantes en la mayoría

de los casos), muestra información como los nombres de variables que son poco entendibles para

un usuario y generalmente exhibe grandes unidades de texto informativo que distraen al usuario y

hacen menos nítida la interfaz.

Por otro lado, se puede decir que los servicios del sistema brindan soporte a todas las tareas que

un usuario pueda necesitar desempeñar y algunos de ellos brindan customización para adaptarse

mejor a sus necesidades. Por lo tanto, si se mejorara en gran medida la interfaz del sistema, éste

podría incrementar considerablemente la cantidad de usuarios y convertirlo en un sistema exitoso,

produciéndole una ganancia mucho mayor a la compañía.

En cuanto a los principios de usabilidad, aunque estos son muy generales y abstractos, pueden

beneficiar en gran medida las aplicaciones de software y mejorar su usabilidad, sin embargo, si son

aplicados, es muy importante asegurarse que lo hagan de una manera correcta, de otro modo su

uso puede causar más daño que satisfacción.

La integración de los principios, prototipos y heurísticas de evaluación permite la creación de

interfaces que satisfacen las expectativas del usuario, el cual es el punto de vista más importante

para garantizar la aceptación del sistema.

En esta evaluación de usabilidad de la aplicación se debe tener en cuenta que si bien se trató de

ser un usuario fiel, explorarla y usarla como lo haría un verdadero usuario real, objetivamente no

lo somos. Por otro lado, si bien los resultados obtenidos se pueden acercar bastante al nivel real

de usabilidad, se necesita un estudio basado en una cantidad de usuarios reales para obtener una

mejor precisión.

25

Trabajos citados

[1] Dix, A. J. (2004). Principles to support usability, In Human-Computer Interaction, Third Edition.

Prentice Hall,.

[2] Nielsen, J. a. (1990). Heuristic evaluation of user interfaces.