L A
E V A L U A C I Ó N D E S A R R O L L O
D E L
S O F T W A R E
D 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 volumen 1); 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):
Us uario
Tarea
Sistema
Fig. 1 Factores de la Usabilidad 2 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 us o, 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: -
3
Análisis de necesidades de los usuario - Estas son la razón de ser del
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 est as 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 razon able 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 q ue 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 p olí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 usabilildad 5, 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 System atic Design of Instruction . Scott, Foresman/Little Brown. Glenview. BOOTH, Paul 1989. An Introduction to Human -Com puter 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.
5
Aunque ello no significa que son la última etapa; este tipo de evaluación debe realizarse, en lo posible, en paralelo al avance del desarrollo.
H - nuevo texto tomando los nuevos autores