L A E V A L U A C I Ó N

D E L D E S A R R O L L O

D E S O F T W A R E

M A N U E L G Å N D A R A V Å Z Q U E Z

La evaluación del software educativo ocurre en varias dimensiones: en cuanto a su

capacidad educativa, la evaluación se centra en aspectos de diseño instruccional y la

correción, la completud y la adecuación del contenido (ver Leo®, este mismo

volumen1); en cuanto a desarrollo de software en general, interesa determinar su

correción (que no haya errores de procedimiento que conduzcan a resultados falsos),

su estabilidad (que sea resistente tanto a errores del usuario como a problemas

internos en relación al sistema operativo o el hardware), su elegancia o simplicidad

(que los procesos operen de manera óptima con el mínimo de código indispensable),

y otros parámetros similares.

Nos interesan aqui, en particular, los aspectos menos técnicos, referidos no

tanto a las características de la programación -es decir, desde el punto de vista de la

operación en la máquina- sino aquellos referidos al usuario y que en conjunto han

sido llamados «factores de usabilidad», o simplemente usabilidad . No porque la

usabilidad no esté relacionada a los factores más técnicos, sino porque precisamente

en ella confluirán tanto aspectos de programación como de interfaz al usuario; de

contenido y de forma. Son, en efecto, los que conjuntan aspectos del código con

aspectos del usuario a través de la facilidad con que el usuario podrá desempeñar la

tarea para la que requiere el programa.

En este trabajo presentaremos varias definiciones de usabilidad, así como las

estrategias a considerar para mejorar la usabilidad de los programas, referida al

momento de su evaluación; describiremos tanto los parámetros como las técnicas

normalmente empleadas en la evaluación de la usabilidad del software, para concluír

con algunas sugerencias prácticas para la evaluación del desarrollo de software,

aplicables tanto en la evaluación de prototipos como de los resultados finales.

La Usabilidad

Factores y componentes

Parafraseando a la Organización Internacional de Standards (ISO ) podemos decir que

la usabilidad es el grado al cual usuarios específicos pueden lograr metas específicas

dentro de un ambiente particular, de manera efectiva, cómoda y aceptable. Shackel

ha insistido que la definición se mejore a fin de que sea claro qu é es lo que hay que

medir. Otros autores (como Eason 1976 o Booth 1984) concuerdan en que la

usabilidad tiene que ver con la facilidad con la que un usuario logra realizar una

1 L - cap Leo

tarea de manera eficaz y agradable. En efecto, los diferentes autores coincide n en

que la usabilidad involucra cuando menos tres factores, que impactarán su evaluación

(Eason 1976; ver Fig. 1):

Sistema

Usuario Tarea

Fig. 1 Factores de la Usabilidad2

a) El usuario. Serán relevantes, cuando menos las siguientes características:

- Su conocimiento previo (tanto de cómputo como de la tarea)

- Su motivación (las razones que tiene para usar el software)

- El grado de control (su capacidad para llevar la conducción de la tarea)

b) El sistema. Impactarán la usabilidad:

- La facilidad de aprendizaje del software

- La facilidad de uso

- La congruencia con la tarea

c) La Tarea. Afectará la usabilidad según su:

- Apertura o flexiblidad (qué tan compleja y multifuncional es la tarea)

- Frecuencia (el número de veces que el usuar io la realiza).

La consideración de estos tres factores es importante, dado que su conjunción

implica que la evaluación de la usabilidad realmente es una empresa compleja, cuyo

resultado no depende solamente del software (sistema), sino de la articulació n de los

tres factores. En efecto, será más usable un sistema sencillo y de propósito único que

uno que tenga múltiples módulos de funcionalidad; pero aún éste puede ser

considerado poco amigable cuando la motivación del usuario es mínima (por ejemplo,

cuando tiene que tomar un examen automatizado); o puede ser considerado difícil

para un usuario sin experiencia previa en la materia, aunque sea experto en cómputo.

2 Gi - Ilustración interactiva cuadro sinóptico

Así, es factible que los resultados de la evaluación de la usabilidad varíen conforme

estos factores y sus componentes se combinen de diferentes maneras. Quizá el

usuario no esté dispuesto a aprender software poderoso pero que usará relativamente

poco, aunque sea fácil de aprender; mientras que es capaz de dedicar horas a

desentrañar las complejidades de un juego de aventura cuya complejidad es

precisamente el interés de la tarea.

Shackel (1986) ha insistido en una definición operaciónal de «usabilidad» que

sea mesurable. Para el, el sistema debe ser efectivo (o eficaz), en el sentido de que

una cierta proporción de usuarios a los que está destinado el programa deberán poder

usar el sistema en un número de situaciones, dentro de un tiempo finito y sin

demasiados errores. El sistema debe pasar satisfactoriamente pruebas de criterio que

establezcan su efectividad, «aprendibilidad» (facilidad de aprendizaje, flexibilidad y

actitud del usuario. Estos criterios deben poderse medir. Por ejemplo, la efectividad

puede evaluarse estableciendo un parámetro en cuanto a número de errores o

velocidad de uso para una determinada tarea, en un porcentaje de usuario que logran

la tarea sin errores, en un porcentaje de rango de contextos de uso posible. La

facilidad de aprendizaje, puede evaluarse, por ejemplo, por referencia al tiempo que

toma la capacitación; o el número de intervenciones de soporte y ayuda requeridos

por el usuario. La actitud se puede medir mediante cuestionarios o escalas de

frustración, cansancio, satifacción, etc., y la flexibilidad por el número de tareas a

las que el programa es aplicable.

Booth (1984 1989:110-112) ha complementado este análisis con una

definición en que la usabilidad no es sinónimo de la «amigabilidad» ni de la facilidad

de uso, dado que argumenta, con razón, de que no serviría de mucho que un programa

fuera amigable y fácil de usar pero no permitiera realizar adecuadamente la tarea en

cuestión. Por ello para él la usabilidad debe tener en cuenta los siguientes

parámetros de la usabilidad (ver fig® 3:

- La utilidad - que el software realmente permita realizar la ta rea

- Efectividad (facilidad de uso) - que la tarea se realice con facilidad y eficacia

- Facilidad de Aprendizaje - que se pueda aprender rápidamente y sin dificultad el

software

- Actitud - que el usuario pueda sentirse satisfecho al término del uso, una vez que

ha aprendido el software

Cómo mejorar la usabilidad de un programa

Estrategias

Tal como se ha reiterado ya varias veces en este volumen, la mejor manera de

mejorar la usabilidad de un programa es el preveerla. Es decir, hay que preocu parse

de ella no solamente cuando se terminó el desarrollo, sino desde la fase de diseño.

Ello implica:

- Análisis de necesidades de los usuario - Estas son la razón de ser del

3 Gi - Ilustración interactiva

- Análisis de tareas - que en el caso del software educativo puede ser una operación

muy sofisticada, según algunas versiones del diseño instruccional (ver Dick and

Carey 1990:caps. 10, 11 y 12)

- Análisis situacional - el contexto en que se realizará el uso, y sus consecuencias.

El tomar en cuenta de manera contínua estas estrategias permitirá que

el proceso de ajuste entre la tarea, el sistema y los usuarios potenciales sea iterativo,

ocurra a lo largo del proceso y no sea una tarea que se lleva a cabo al final. La razón

es obvia: para entonces puede resultar mucho más caro o complejo el hacer cambios

o ajustes.

Un punto crucial es el de poder definir c riterios de aceptabilidad. Dado que,

como se argumentó antes, la evaluación de al usabilidad involucra elementos

subjetivos y cambiantes de usuario a usuario, es import ante definir qué constituye

una usabilidad aceptable y para quién. Esto involucra determinar estándares (como el

número de errores en la operación, tiempos promedios de aprendizaje, rangos de

satisfacción, etc.), así como el procurar muestras representati vas de usuarios.

Pruebas de usabilidad

Existen muchas variantes de las pruebas de usabilidad. En todas se busca determinar

los defectos de usabilidad, definidos como «cualquier cosa que evite que un usuario

concluya una tarea meta con un esfuerzo razonable en un tiempo razonable» Booth

(1989:118). Estas pruebas implican determinar tanto escenarios de uso (condiciones

en que el programa se utilizará que puedan afectar su eficacia), como los parámetros

a observar o medir, así como las técnicas precisas que se emplearán en la obtención

de datos.

Por lo que toca a parámetros de usabilidad, generalmente se intenta establecer

factors como el tiempo en la tarea (cuánto lleva a un usuario realizar una determinada

función); el número de errores del usuario (y su tipo); los patrones de barrido visual

(que requieren de equipos sofisticados, pero que permiten determinar si la

composición de las pantallas corresponde a la forma en que un usuario promedio

«lee» la información en el monitor); los patrones de uso (si el usuario típicamente

utiliza sólo un segmento de la funcionalidad disponible); la complejidad conceptual y

léxica (es decir, qué tantos conceptos y palabras potencialmente «difíciles» o

«nuevas» se introducen en el programa); y medidas de actitud (el grado de

«satisfacción/frustración» del usuario al terminar una sesión típica de uso); éstas son

algunas de los parámetros más frecuentemente usados.

En cuanto a las técnicas, éstas pueden involucrar los llamados «protocolos

verbales», en que el usuario va narrando su experiencia y respondiendo a algunas

preguntas prefijadas o simplemente comentado de manera libre sus impresiones ante

una persona o una grabadora; los protocolos visuales, similares a los anteriores, pero

documentados mediante una videograbadora; la simulación de uso, mediante

programas que de manera automatizada toman todas las combinaciones posibles en

busca de errores difíciles de detectar; las reseñas de expertos; los comentarios de

usuarios típicos, de usuarios amigables y de usuarios hostiles ; el número de técnicas

es amplio, como se verá, pero de esta gama no todas son factibles o aplicables a los

contextos educativos, ya sea por su costo o su complejidad técnica.

En cuanto a escenarios posibles, se pueden realizar pruebas controladas en

laboratorio; experiencias «etnográficas» con usuario ya en condiciones de uso

normal; entrevistas y encuestas post -uso, auditorías contra listas checables; y

estudios de seguimiento para ver si lo aprendido por el usuario es retenido a

diferentes lapsos temporales.

A final de cuentas, las pruebas cruciales serán las que se realicen ya en el

campo, con usuarios en condiciones reales. Por ello, algunos desarrolladores optan

por seleccionar sitios y usuarios de prueba para la versión previa a la final (llamada

versión «beta» en el argot del cómputo). La ventaja de contar con p ruebas beta de

campo es que generalmente se obtendrá un rango mayor de usuarios y contextos de

uso, cuyas opiniones favorecerán el desarrollo.

En cualquier caso, es frecuente combinar estas técnicas y escenarios con

estudios de seguimiento que intentan evaluar cuánto ha retenido el usuario desde la

capacitación original, y el rango de tareas y funciones que realmente usa del

programa. Si el usuario tiene problemas frecuentemente, el número d e errores se

incrementó, etc., entonces será necesario revisar qué factores están afectando la

usabilidad en el largo plazo.

En cuanto a los usuarios que participarán en la prueba, conviene contar con

todo el rango posible: desde aquellos con experiencia p revia en la tarea y en la

computadora, hasta otros que son novicios en ambos; desde los que son amistosos y

apoyan nuestro desarrollo, hasta los que son potencialmente hostiles; desde los

expertos en el contenido, hasta aquellos en la estrategia instruccio nal seguida; desde

los que expertos en diseño de interfaz, hasta los expertos en diseño gráfico, de audio

y video. Todos tienen mucho que contribuír, tanto a los aspectos didácticos, como

técnicos y de usabilildad -y en algunos casos, hasta los aspectos políticos: involucrar

a un enemigo potencial en las fases tempranas de la evaluación puede ser la mejor

manera de ahorrarse una batalla en el momento en el que el producto final es

entregado. Y dada la manera en que operan la mayoría de las instituciones

académicas, esta consideración es definitivamente importante.

Por último, se deben evaluar la usabilidad no solamente el software mismo,

sino los materiales de instalación y el manual del usuario y el profesor.

Un protocolo de evaluación

Pensando en voz alta

En general, los protocolos de evaluación son la especificación del procedimiento a

seguir en la evaluación de la usabilidad. Su propósito es uniformar las observaciones

a fin de lograr comparabilidad. Aunque tienen variantes, algunos elementos son

citados por la mayoría de los autores. Un protocolo popular (y barato en

comparación a otros), que es aplicable al desarrollo educativo, es el de «pensar en

voz alta». Los usuarios comentan «pensando en voz alta» mientras usan el software.

Sus comentarios son registrados ya sea por una persona o grabados a medios

magnéticos (audio o videocassette). Para un protocolo de esta naturaleza los pasos

serían, en general, los siguientes (Nicol, citada en Tognazzini 1992:83 -89 - texto

cuya lectura recomendamos)4:

1. Presentarse a si mismo.

4 A - grabar un protocolo de este tipo

2. Describir el propósito de la observación: el de evaluar el desarrollo y detectar

posibles problemas para mejorar el programa. Es crucial clarificar al usuario que

se está evaluando el programa y no a él o ella; y que si experimenta dificultades

al usar el programa, son precisamente esas dificultades las que nos interesa

detectar para poder corregir el programa. Su contribución, aunque sea crítica, es

bienvenida, dado que nos interesa mejorar el desarrollo, por lo que pu ede opinar

con toda confianza.

3. Señalar que puede interrumpir la prueba en cualquier momento o por cualquier

razón si no se siente cómodo.

4. Describir el equipo que se va a usar

5. Explicar en qué consiste el «pensar en voz alta», y cómo aunque quizá el

principio se sienta extraño al hacerlo, se acostumbrarán rápidamente a medida que

le prueba avance.

6. Explicar que no se le proporcionará ayuda. Dado que precisamente interesa

determinar que tan claro, intuible y fácil de usar es el programa, el eva luador no

proporcionará ayuda (salvo en casos extremos); aún así, el útil que el usuario se

haga en voz alta preguntas o exprese sus dudas cuando tenga problemas, porque

precisamente estos son los elementos que nos interesa detectar.

7. Presentar el programa y describir las tareas a realizar. Conviene que los pasos

generales estén escritos (salvo en los casos en que es precisamente la

intuitibilidad de la interfaz lo que interesa evaluar).

8. Determinar si hay preguntas antes de iniciar la prueba; en su caso, resolverlas y

sólo entonces dar inicio.

9. Concluir la observación. Explicar qué era en particular lo que queríamos

evaluar, resolver preguntas y dudas del usuario que no era factible resolver

durante la prueba. Agradecer el apoyo.

10. Usar los resultados. Revisar las notas o las cintas obtenidas durante la pruba,

y trabajar particularmente en aquellas áreas del programa en que los usuarios de

prueba repetidamente tuvieron problemas. Recordar, durante la prueba y despúes,

que cualquier problema es atribuíble al desarrollo, no a los usuarios; dado que se

eligieron para la prueba usuarios promedio, cualquier falla es imputable a la

interfaz o al desarrollo conjunto, y jamás al usuario.

Evidentemente, si el programa es muy largo, quizá requiera ha cer sesiones en

diferentes etapas, a fin de evitar que la tensión y el cansancio del usuario afecten los

resultados. También habrá que hacer ajustes en el caso de que los usuarios, como a

veces pasa en educación, sean niños pequeños. Ahí, una técnica más «etnográfica»,

de observación participante, puede requerirse. Sentarse al lado del niño a «jugar con

él» es más eficaz que tratar de seguir algún protocolo fijo que el niño, simplemente

por su menor lapso de atención, no podría cumplir.

Comentarios finales

El mejor programa educativo puede fracasar si no es usable. Puede incluso

contradecir la intención educativa que lo motivó, si el usuario sale de la experiencia

frustrado, molesto y deseando no saber más sobre el asunto. No importa que el

código del programa sea impecable; que las gráficas y los textos sean buenos; si el

programa no es fácil de aprender, fácil de usar, eficaz y agradable, simplemente no

logrará cumplir su propósito. Idealmente, la mecánica de operación del programa

debe ser inobstrusiva, casi «invisible», de manera que el usuario pueda concentrarse

en la tarea y no en el programa. Los estudios de usabilidad son la herramienta para

acercarse a este objetivo, al ser la etapa final del diseño de interfaz con el usuario y

la etapa final del desarrollo entero 1.

Es predecible que los estudios de usabilildad5, anteriormente restringidos a los

desarrollos de las grandes empresas comerciales, serán de una relevancia e interés

mayor para los desarrolladores educativos. Lo crucial es recordar que, a fin de

cuentas, comprometerse con una filosofía del cómputo centrada en el usuario, no es

otra cosa que aceptar que «el usuario siempre tiene la razón».

Bibliografía

DICK, Walter and Carey, Lou

1990. The Systematic Design of Instruction . Scott, Foresman/Lit tle Brown. Glenview.

BOOTH, Paul

1989. An Introduction to Human-Computer Interaction. Lawrence Erlbaum. London.

PENNY Bauersfeld

1994. Software by Design . M&T Books. New York.

RUBISTEIN, Richard and Hersh, Harry

1984. The Human Factor. Digital Press. Bedford.

TOGNAZZINI, Bruce

1992. Tog on Interface. Addison-Wesley. Reading.

Nota

1. Aunque ello no significa que son la última etapa; este t ipo de evaluación debe realizarse, en lo

posible, en paralelo al avance del desarrollo.

5 H - nuevo texto tomando los nuevos autores