Evaluaciones Centradas en el Usuario

Para poder tener un primer acercamiento sobre el DCU existen varias t´ecnicas y m´etodos que permiten hacerlo. Tal es el caso de MODIHC, MPIu+a, etc. El inconveniente que presentan las t´ecnicas mencionadas son las siguientes:

MODIHC: Es una t´ecnica del DCU que demanda ser embebida desde el principio del ciclo de desarrollo en la etapa de dise˜no misma dentro de una metodolog´ıa de desarrollo [16]. Puede ser incluida dentro de una metodolog´ıa de desarrollo tradicional o ´agil. En este caso como ya se ten´ıa un dise˜no centrado en la tarea (DCT) no era conveniente utilizarla del todo para este caso porque supone la modificaci´on de dise˜no e implementaciones previas. MPIu+a: A diferencia de MODIHC, esta es considerada como una metodolog´ıa de desa- rrollo propia que integra la formalidad de una metodolog´ıa de desarrollo, las caracter´ısticas del DCU y la accesibilidad dentro de s´ı [17]. Por este lado no era conveniente utilizar- la ya que supon´ıa la modificaci´on de dise˜no e implementaciones previas de una manera m´as dr´astica, ya que ciertos artefactos documentales requeridos para est´a metodolog´ıa no fueron creados.

Por otro lado PACT (Personas, Actividades, Contexto y Tecnolog´ıas) es un framework que ayuda a definir de manera clara, las caracter´ısticas angulares para aproximar un dise˜no a la centrades en el usuario [18]. PACT a diferencia de los anteriores no exige ser ejecutado durante alg´un momento espec´ıfico del ciclo de desarrollo, ya que puede ser acoplado en casi cualquier

momento. Adem´as las exigencias de PACT en cuanto a la creaci´on de artefactos adicionales es m´ınima o m´as bien las necesarias para aproximarse al DCU.

De lo anterior podemos decir que PACT se utiliz´o como un mecanismo para generar artefac- tos que fueron utilizados durante el dise˜no centrado en el usuario como el perfil de usuario, las actividades que se pueden hacer en la herramienta, la descripci´on del medio ambiente id´oneo de la interacci´on, la tecnolog´ıa requerida. Consulte el anexo B para mayor informaci´on.

4.2.1. Evaluaci´on Heur´ıstica (SIRIUS)

La evaluaci´on heur´ıstica es un m´etodo informal de an´alisis de usabilidad donde un n´umero de evaluadores se presentan con un dise˜no de la interfaz y se les pidi´o hacer comentarios al respecto [19]. Nielsen posteriormente propuso una serie de normas no formales a las que llam´o heur´ısticas, las cu´ales enmarcan las propiedades deseables que un software debe poseer para considerarse usable. Estas heur´ısticas son tomadas por los evaluadores como pautas para poder calificar un software.

Existen una gran cantidad de formatos dise˜nados para realizar esta tarea de una manera ordenada llamadas checklist. Algunos de ellos pueden resultar ser ´utiles pero depende de las circunstancias en que se utilicen. Lamentablemente la mayor´ıa de ellos proporcionan valores binarios (si/no) para describir si una heur´ıstica es cumplida o no. Por lo regular este valor no resulta ser muy significativo para presentar resultados sobre la usabilidad de un sistema.

Uno de estos checklist que di´o origen a una metodolog´ıa llamada SIRIUS se diferencia de los dem´as en el sentido de que realiza clasificaciones de los sitios web seg´un su prop´osito. Adem´as la organizaci´on de las heur´ısticas est´a mejor organizada. Se hacen grupos de heur´ısticas llamados aspectos y cada propiedad o heur´ıstica bien determinada se llama criterio [6]. Cada aspecto y criterio tiene un peso asociado el cu´al var´ıa seg´un el tipo de sitio web al que pertenezca el software a evaluar; en este caso la herramienta Affect entra en la categor´ıa de software educativo.

Aspecto Descripci´on

Aspectos generales Elementos relacionados con los objetivos del sitio, el look & feel, coherencia y nivel de actualizaci´on de contenidos. Identidad e

Informaci´on

Elementos relacionados con la identidad del sitio, la in- formaci´on proporcionada sobre el proveedor y la autor´ıa de los contenidos.

Estructura y Navegaci´on

Elementos relacionados con la idoneidad de la arquitec- tura de la informaci´on y la navegaci´on del sitio.

Rotulado Elementos relacionados con la significaci´on, correcci´on y familiaridad del rotulado de los contenidos.

Layout de la p´agina

Elementos relacionados con la distribuci´on y el aspec- to de los elementos de navegaci´on e informaci´on en la interfaz

Entendibilidad y facilidad en la

interacci´on

Elementos relacionados con la adecuaci´on y calidad de los contenidos textuales, iconos y controles de la interfaz.

Control y retroalimentaci´on

Elementos relacionados con libertad del usuario en la navegaci´on y la informaci´on proporcionada al mismo en el proceso de interacci´on con el sitio.

Elementos multimedia

Elementos relacionados con el grado de adecuaci´on de los contenidos multimedia al sitio web.

B´usqueda Elementos relacionados con el buscador implementado en el sitio web.

Ayuda Elementos relacionados con la ayuda ofrecida al usuario durante la navegaci´on por el sitio.

Cuadro 3: Aspectos dentro de la metodolog´ıa SIRIUS [6]

Cada aspecto cuenta con su conjunto de criterios espec´ıficos relacionados con cada aspecto. Si se desea saber a detalle en qu´e consiste cada criterio englobado en cada aspecto mencionado anteriormente por favor consulte [6].

SIRIUS cuenta con un archivo excel que por medio de macros y funciones automatiza este proceso por lo que el evaluador simplemente debe evaluar y seleccionar de un conjunto de va- lores predeterminado el que exprese su opini´on al respecto del criterio que se est´e evaluando. Otra aportaci´on de SIRIUS es que adem´as de permitir realizar evaluaciones heur´ısticas m´as r´apidas, tambi´en ofrece un valor porcentual al terminar la evaluaci´on que describe el nivel de usabilidad que un sitio web tiene de acuerdo a la metodolog´ıa SIRIUS.

El plan de trabajo para llevar a cabo la evaluaci´on heur´ıstica por medio de SIRIUS fue organizado de la siguiente manera:

Normalmente cuando se aplican este tipo de evaluaciones la teor´ıa expresa que lo m´as com´un es contratar personal ajeno al proyecto que sean expertos en usabilidad y adem´as

involucra a un personal interno que se encargue de administrar el proceso de la evaluaci´on. Lamentablemente los recurso destinados a este proyecto no fueron suficientes para cubrir este requerimiento por lo que se opt´o por buscar otras alternativas. Es decir, otras personas que pudieran asumir el rol de evaluadores sin demandar un honorario y que su colaboraci´on fuera estrictamente participativa y el equipo de trabajo de este proyecto asumieron el rol de administradores del proceso de la evaluaci´on. Adem´as cada personaje debe contar con un equipo de computo para poder llevar a cabo la prueba, la url de la herramienta que se va a evaluar, un navegador adecuado y el excel de la metodolog´ıa SIRIUS.

Una vez identificados los posibles evaluadores, administradores y confirmada su partici- paci´on se prosigue a llevar en marcha la evaluaci´on. Para esto, con ayuda del artefacto Actividades obtenido del framework PACT (v´ease anexo B) que se implement´o y coment´o anteriormente, se obtuvo la lista de funcionalidades/interacciones que el sistema posee de la cu´al se discriminaron aquellas interacciones que puede realizar el usuario investigador. De esta manera como ya se encuentran delimitadas dentro del artefacto Actividades en que consiste cada funcionalidad, esto le permite al administrador saber cu´al es el dominio de cada funcionalidad.

Posteriormente es el administrador quien se encargar´a de dar indicaciones a los evaluado- res y explicarles el dominio de cada interacci´on que se probar´a sin caer en detalles para no entorpecer la prueba. La idea es ser lo m´as breve posible. Las primeras indicaciones ser´an dar una escueta introducci´on de la metodolog´ıa SIRIUS por si alguno de los evaluadores la desconoce. Posteriormente dar´a una breve explicaci´on de como funciona el excel/chec- klist; aqu´ı si puede explayarse hasta donde sea necesario para que quede claro como debe ser usado el checklist.

Cuando los puntos anteriores se hayan completado, lo que sigue es introducir dentro del checklist los datos del evaluador, del sitio web a evaluar y configurar el tipo de sitio web de acuerdo a la metodolog´ıa SIRIUS. En el caso de esta herramienta se clasific´o como educativa.

Despu´es el administrador otorga a los evaluadores la lista de interacciones que el usuario investigador puede realizar dentro del sistema con una explicaci´on de su dominio. Ensegui- da el administrador pedir´a a los evaluadores que realicen una interacci´on (todos la misma interacci´on) y se dar´a un tiempo para que el evaluador trate de realizar la interacci´on con el sistemas. Este proceso se repite hasta terminar la lista.

Ya que se haya completado el punto anterior se prosigue a que los evaluadores vayan llenando el checklist.

El siguiente paso es analizar los resultados. El administrador se encargar´a de recolectar los valores porcentuales que arroje el checklist de SIRIUS y posteriormente se calcular´a un promedio. Se dice que si el promedio arroja un valor igual o mayor al 75 % se considera que el sistema es lo suficientemente usable y por lo tanto no es necesario modificarlo, sino se continua a verificar cada criterio de cada aspecto e identificar cu´ales de ellos fueron los de puntaje m´as bajo para corregirlos, usualmente el checklist tiene una secci´on donde el evaluador puede describir a detalle seg´un su criterio porque no se cumpli´o con el criterio [6].

La evaluaci´on heur´ıstica se ejecut´o en dos fases: La primera se realiz´o con ayuda de los estudiantes de la segunda generaci´on de la maestr´ıa en sistemas interactivos centrados en el usuario quienes asumieron el rol de evaluadores. El n´umero de evaluadores recabados fueron cuatro. La segunda se llev´o a cabo con ayuda del personal del London Knowledge Lab para ocupar el rol de evaluadores.

4.2.2. Pensando en voz Alta

Es una t´ecnica emp´ırica utilizada para evaluar la usabilidad de la interfaz de un prototipo cualquiera. Para llevarla a cabo se requiere que, mientras un usuario desempe˜na una tarea en un sistema, comente en voz alta lo que est´a pensando. Mientras, el evaluador observa silencio- samente para aprender lo que el usuario piensa de la tarea y los problemas que tiene al usar el sistema [20]. Nielsen N. hace 19 a˜nos otorg´o una definici´on de Pensando en voz alta:

En una prueba pensando en voz alta, se pide a ciertos participantes de la prueba a utilizar un sistema, mientras que continuamente piensan en voz alta; es decir, simplemente verbalizar sus pensamientos mientras se mueven a trav´es de la interfaz de usuario. Aunque esto no es sim- ple para la mayor´ıa de las personas ya que m´as bien se entiende como una especie de mon´ologo en marcha. El facilitador de la prueba tiene que dar la informaci´on que necesitan los usuarios para evitar hablar lo m´as pronto posible [20].

Para ejecutar un pensamiento b´asico en voz alta como estudio de usabilidad, se necesita hacer s´olo 3 cosas [20]:

1. Reclutar a los usuarios representativos. 2. Darles tareas representativas a realizar.

3. Cierre para arriba y dejar que los usuarios sean los que hablen.

En este caso las pautas que sugiere Norman Nielsen ser´an las que se utilizar´a para llevar a cabo esta prueba. Esta evaluaci´on fue llevada a cabo en las instalaciones del London Knowledge Lab, ya que nuestros participantes (usuario investigador) se encuentraban ah´ı.

4.2.3. Test de Usuario

La literatura nos menciona que esta t´ecnica debe ser imprescindible, y que debe ocuparse en casi todo el proceso de desarrollo. Para el caso de las evaluaciones centradas en el usuario por lo regular se realiza despu´es de una evaluaci´on heur´ıstica. Consiste en realizar un peque˜no cuestionario de no m´as de 10 preguntas sobre que le pareci´o al usuario el sistema tras haberlo utilizado. Las preguntas deben ser bien formuladas para que permitan la f´acil extracci´on de in- formaci´on en t´erminos de cambios reflejados en la interfaz del sistema [21]. El proceso h´abitual para realizar esta prueba es el siguiente [21]:

2. Realizar un adecuado y corto test de usuario, teniendo identificado lo que se persigue detectar como anomal´ıas o problemas en la interfaz de usuario.

3. Hacer una convocatoria planeada para reclutar sujetos que cumplan las caracter´ısticas del perfil de usuario.

4. Al iniciar la prueba se hace un pre´ambulo con el encargo de la prueba, el cu´al tiene que hacer en la medida de lo posible que los reclutados se sientan relajados y comunicarles que de presentarse un error o alg´un problema en la interacci´on con el sistema no ser´a su culpa, sino ser´a el dise˜no el que esta mal, y que su participaci´on es muy valiosa.

5. Tener organizadas las funcionalidades que los participantes realizaran. El responsable les dir´a que actividad tienen que hacer pero sin indicarles como hacerlo en el sistema. 6. Una vez terminado el paso anterior se procede a realizar el test de usuario. Si alg´un

participante presenta dificultades en este momento pueden ser atendidas todas sus dudas. 7. Al finalizar la prueba sigue el proceso de an´alisis e interpretaci´on de resultados. Usual- mente este proceso puede ser complicado o no. Todo depende del dise˜no de los tests. Posteriormente se elabora un informe con el resultado de la prueba.