INTRODUCCIÓN Este trabajo nace como una inquietud sobre el problema de la usabilidad en el diseño industrial, en el marco de la materia: Diseño de interfaces, nuevos escenarios. Queriendo profundizar en esta dimensión desde el diseño, se inició un levantamiento de información asociada al tema, encontrando como elemento característico que el concepto de usabilidad se está direccionando en la mayoría de los casos al medio informático. La desmaterialización del objeto y la tendencia a la miniaturización han hecho que la interfaz en los productos por los avances tecnológicos asociados a la electrónica, hayan hecho posible que la discusión en torno a la usabilidad se asocie solamente al sistema de relación que se está construyendo en la interfaz hombre-medio informático. En algunos casos se encontraron observaciones asociadas a la ergonomía (sistema de relación hombre- máquina) y el papel que desempeña en la configuración de nuevos productos. Profundizando y especializando aún más la búsqueda en temas asociados al desarrollo de producto, apareció la visión desde la ingeniería, que se condensa en el método QFD empleado desde la ingeniería concurrente al interior de las organizaciones productivas. De esta amalgama de visiones entorno a la usabilidad, es de donde se parte en este trabajo, para tratar de caracterizar la usabilidad desde un punto de vista más genérico y que permita a su vez estructurar una visión más centrada en el problema del uso y en la interacción entre el hombre y el objeto-producto, pues en síntesis es ahí donde debe concentrarse la discusión. En la estructura del trabajo encontraremos estos apartes, y en cada uno de ellos se hará una reflexión desde la visión del Diseño Industrial. Se debe tener en cuenta que dichas reflexiones parten de la visión como diseñador industrial latinoamericano, la cual se distancia de la visión española que se direcciona más hacia la ingeniería de diseño.

PRINCIPIOS DEL DISEÑO CENTRADO EN EL USUARIO

El diseño, sea cual sea el objeto del mismo, tiene que basarse en el usuario, y el usuario puede ser cualquier individuo (Diseño para Todos). Vamos a ver que los principios del diseño centrado en el usuario no son más que una reformulación de los principios más elementales de la Ergonomía Clásica y de aquellos se derivan, en general, las guías de accesibilidad. Lamentablemente, no son pocos los diseñadores que no advierten tal circunstancia, resultando conveniente explicitar ciertos aspectos que proporcionarán una perspectiva más amplia, sin duda, a estos principios. Otros, simplemente, considerarán inviable el planteamiento. No hay que confundirse: nadie puede hacer un producto absolutamente accesible. Podrá hacerse, en todo caso, más accesible, pero siempre habrá personas que no puedan hacer uso del mismo. Estos principios, pues, deberían servir para incrementar el cuidado y la comprensión de los diseñadores a la hora de plantearse determinadas preguntas. Los diseñadores deben llevar en mente estos principios de forma continua. Es interesante ver como de nuevo se pone en boga la usabilidad, por el mismo mercado, el cuál se direcciona en estos momentos sobre la plataforma del marketing....

FACTORES QUE DETERMINAN LA USABILIDAD

1. El control de la situación debe estar en manos del usuario:

Ha de ser el usuario quien inicie las acciones y controle las tareas.

El usuario ha de tener la oportunidad de

personalizar la interfaz.

El sistema debe ser lo más interactivo posible, facilitando el cambio y gestión de sus modos.

Estos principios asociados a la interfaz informática, que se podría decir más asociados a un problema de comunicación que desemboca en soluciones de interacción, pueden extrapolarse a cualquier tipo de producto, más aún cuando la tendencia en la mayoría de los objetos a los cuales nos enfrentamos,

2

tienen una interfaz asociada a estos sistemas (como ejemplo tenemos los nuevos electrodomésticos de línea blanca, que tienden a conectarse al ordenador, o a tener sistemas de control asociado a microprocesadores). 2. Es preciso un planteamiento directo:

El usuario ha de comprobar cómo sus acciones afectan a la salida del sistema.

La accesibilidad de la información y de las

opciones van a reducir la carga mental de trabajo del usuario.

Las metáforas familiares proporcionan una

interfaz intuitiva.

Se asocia un significado con un objeto mejor que con un comando, siempre y cuando la asociación resulte apropiada.

3. La consistencia es parte indispensable en el diseño:

Se ha de facilitar la aplicación de los conocimientos adquiridos de forma previa al desarrollo de nuevas tareas, lo que a su vez se va a traducir en un aprendizaje rápido.

Consistencia y estabilidad se van

a traducir en facilidad de uso.

Ha de darse la consistencia dentro de un producto (el mismo comando desarrollaría funciones que el usuario interpreta como similares), en un entorno (se efectúa una adopción de convenciones para todo el conjunto), con las metáforas (si un comportamiento particular es más característico de un objeto diferente que el que su metáfora

implica, el usuario puede tener dificultad en asociar comportamiento y objeto). NOTA: El concepto de metáfora está asociado al conocimiento previo adquirido por el usuario en el proceso de aprendizaje, tanto formal (escolarizado), como no formal (experiencias de la vida cotidiana). Esto es lo que permite afirmar que lo que yo no conozco, no existe para mí. 4. Hay que posibilitar la recuperación de los errores:

El diseño minimiza los riesgos y las consecuencias adversas de las acciones accidentales o involuntarias.

3

Hay que posibilitar el descubrimiento interactivo y el aprendizaje ensayo-error.

Hay que posibilitar la reversibilidad y la recuperabilidad de las acciones.

Hay que contemplar los potenciales errores de los usuarios.

Esto es válido para cualquier tipo de producto, pues es el proceso de aprendizaje que tiene el usuario cuando se ve enfrentado a un nuevo producto. 5. Retroalimentación apropiada por el sistema:

Es precisa una respuesta apropiada a las acciones del usuario por parte del sistema.

Tal respuesta ha de ser

inevitablemente de complejidad variable y ha de darse en un tiempo apropiado.

El estado de un sistema

(esperando entrada, comprobando, transfiriendo datos,...) debería estar siempre disponible para el usuario.

Hay que aclarar en este punto que en últimas esta es la relación de input-output de cualquier sistema que se genere para satisfacer cualquier tipo de necesidad; esto es lo que ha permitido revaluar el concepto de los setentas de caja negra, en donde el usuario no sabia lo que sucedía, y en algunos casos ni siquiera podía identificar la diferencia entre un sistema y otro, pues el significante era similar en multitud de objetos.(tenemos como ejemplo los equipos electrónicos de esta época). 6. No se puede descuidar la estética:

Determinados atributos visuales o auditivos concentran la atención del usuario en la tarea que está desarrollando.

Es preciso proporcionar un entorno agradable que contribuya al entendimiento por

parte del usuario de la información presentada. Es de anotar como en estos momentos, no solamente en la interfaz informática, esto adquiere relevancia, la tendencia en los productos es a que los atributos perceptivos no se centren solamente en lo visual, sino en lo gustativo, olfativo, táctil, auditivo y en la percepción áptica, que pueden coadyuvar en la comprensión e información que puede proveer el producto al usuario.

4

7. El diseño debe caracterizarse por su simplicidad:

La interfaz ha de ser simple (que no simplista), fácil de aprender y usar, con funcionalidades accesibles y bien definidas.

El uso del diseño ha de ser fácil de

entender, independientemente de la experiencia, conocimiento, capacidades lingüísticas o nivel de concentración del usuario.

Hay que controlar la información

explicitada, que se ha de reducir al mínimo necesario.

El diseño ha de comunicar la información

necesaria al usuario de forma efectiva, independientemente de las condiciones ambientales o de las capacidades sensoriales del mismo.

Este es uno de los factores, que pone al descubierto la necesidad de una visión mucho más amplia en los procesos de configuración de nuevos productos. El concepto de diseño para todos, es lo que más se aproxima a estos requerimientos.... 8. Es fundamental seguir una rigurosa metodología de diseño:

Una actitud centrada en el usuario, en etapas iniciales y durante el diseño, así como una rigurosa metodología que contemple los principios que se tratan.

En este factor, es donde más trabajo se ha desarrollado, tratando de construir herramientas, que faciliten la participación del usuario, en las diferentes fases del proceso de diseño; en el anexo de metodologías para el análisis y evaluación de la usabilidad en los productos se puede apreciar más claramente. 9. El equipo de diseño debe ser equilibrado:

Se han de cubrir todos los aspectos: desarrollo, expresión, representación, factores humanos, usabilidad...

El trabajo en equipo ha de caracterizarse por la posibilidad de una comunicación e

interacción rápida y efectiva.

5

FASES EN EL PROCESO DE DISEÑO DESDE LA USABILIDAD

Es importante recalcar, que las fases que se distinguen desde la dimensión de la usabilidad, no se contraponen a las del proceso de diseño visto al interior de una organización productiva. Lo que permiten es incorporar al usuario en el proceso de toma de decisiones que se efectúa en este, permitiendo la posterior fabricación de productos más eficientes y que se adecúen en mayor medida a las necesidades reales de estos.

Definición clara de los objetivos, entendiendo a los usuarios y contemplando factores como la edad, la experiencia, las limitaciones físicas, las necesidades más especiales, el entorno de trabajo, las influencias sociales y culturales... Hay que definir el marco de trabajo conceptual para presentar el producto en cuestión con el conocimiento y la experiencia de la audiencia objetivo; a partir de ahí, procede una documentación apropiada a este estado.

Comunicación del diseño mediante el prototipado y establecimiento de un flujo de

tareas. Se puede tratar de incluir más aspectos y comprobar la reacción a los mismos de los usuarios objetivo o tratar de centrarse en los detalles de dichos aspectos, en su funcionalidad.

Mediante el test, en el proceso de diseño, la participación del usuario proporciona

la inestimable ayuda de determinar en qué medida el producto se está ajustando a las necesidades y a las expectativas creadas. No se trata tanto de evaluar la eficiencia de las tareas y los posibles errores en el diseño, sino de conocer las percepciones del usuario, su satisfacción, sus preguntas, sus problemas,...

Después del test va a ser preciso el rediseño en mayor o menor medida, tras el

cual inevitablemente, es preciso de nuevo el test, volviendo así a iniciar el ciclo. Observaciones:

En todas las etapas del proceso de diseño, se aplicarán las técnicas de evaluación de la usabilidad que se estimen más apropiadas.

Las diferencias en los modos de aprendizaje reflejan múltiples variantes que se

manifiestan en un continuo desde ligeras preferencias hasta profundas necesidades. Así, es preciso acomodar esta diversidad mediante representaciones alternativas de la información clave. A partir de diferentes preferencias y necesidades (originadas por el propósito de la actividad de trabajo o aprendizaje y, por supuesto, de la naturaleza de los propios usuarios) se puede seleccionar el medio de representación o forma más apropiado.

Siempre habrá consideraciones de marketing que afectan a la forma del producto y que pueden condicionar, en un determinado momento, un rediseño a mayor o menor escala.

6

PERO.. ¿QUÉ ES, REALMENTE, LA USABILIDAD?

La usabilidad es algo más que el potencial o las posibilidades de uso de un producto.

”.

La utilidad de un sistema [Nielsen, 93], en tanto que medio para conseguir un objetivo, tiene una componente de funcionalidad (utilidad funcional) y otra basada en el modo en que los usuarios pueden usar dicha funcionalidad. Es esta componente la que nos interesa ahora.

“Podemos definir la usabilidad como la medida en la cual un producto puede ser usado por usuarios específicos para conseguir objetivos específicos con efectividad, eficiencia y satisfacción en un contexto de uso especificado

Por efectividad se entenderá la precisión y la plenitud con las que los usuarios alcanzan los objetivos especificados. A esta idea van asociadas la facilidad de aprendizaje (en la medida en que este sea lo más amplio y profundo posible), la tasa de errores del sistema y la facilidad del sistema para ser recordado (que no se olviden las funcionalidades ni sus procedimientos), independiente del tipo de producto con el cuál se esté relacionando.

Por eficiencia se entenderán los recursos empleados en relación con la precisión y plenitud con que los usuarios alcanzan los objetivos especificados. A esta idea van asociadas la facilidad de aprendizaje (en tanto que supone un coste en tiempo; igualmente, si se requiere un acceso continuo a los mecanismos de ayuda del sistema), la

7

tasa de errores del sistema y la facilidad del sistema para ser recordado (una asimilación inapropiada puede traducirse en errores de usuario). En este punto hay que aclarar que el concepto de sistema analizado en este trabajo independientemente de las fuentes de la información, hace referencia a cualquier tipo de sistema desarrollado por el hombre que tenga un fin específico, en donde las partes interactúan entre sí para poder lograr los objetivos que se persiguen.

Por satisfacción se entenderá la ausencia de incomodidad y la actitud positiva en el uso del producto. Se trata, pues, de un factor subjetivo. Este factor está mas asociado al gusto o goce que logre el usuario en la interacción con el objeto-producto (fruición de uso).

La usabilidad, hace referencia, a la rapidez y facilidad con que las personas llevan cabo sus tareas propias a través del uso del producto objeto de interés, idea que descansa en cuatro puntos:

Una aproximación al usuario: Usabilidad significa enfocarse en los usuarios. Para desarrollar un producto usable, se tienen que conocer, entender y trabajar con las personas que representan a los usuarios actuales o potenciales del producto.

Un amplio conocimiento del contexto de uso: Las personas utilizan los productos para incrementar su propia productividad. Un producto se considera fácil de aprender y usar en términos del tiempo que toma el usuario para llevar a cabo su objetivo, el número de pasos que tiene que realizar para ello, y el éxito que tiene en predecir la acción apropiada para llevar a cabo.

Para desarrollar productos usables hay que entender los objetivos del usuario, hay

que conocer los trabajos y tareas del usuario que el producto automatiza, modifica o mejora. El producto ha de satisfacer la necesidades del usuario: Los usuarios son gente ocupada intentando llevar a cabo una tarea. Se va a relacionar usabilidad con productividad y calidad.

“Son los usuarios, y no los diseñadores y los desarrolladores, los que determinan

cuando un producto es fácil de usar”. 1. Importancia de la usabilidad El establecimiento de unos principios de diseño en ingeniería de usabilidad han tenido como consecuencia probada:

Una reducción de los costes de producción: los costes y tiempos de desarrollo totales pueden ser reducidos evitando el sobrediseño y reduciendo el número de cambios posteriores requeridos en el producto.

Reducción de los costes de mantenimiento y apoyo: los sistemas que son

fáciles de usar requieren menos entrenamiento, menos soporte para el usuario y menos mantenimiento.

8

Reducción de los costes de uso: los sistemas que mejor se ajustan a las necesidades del usuario mejoran la productividad y la calidad de las acciones y las decisiones. Los sistemas más fáciles de utilizar reducen el esfuerzo (stress) y permiten a los trabajadores manejar una variedad más amplia de tareas. Los sistemas difíciles de usar disminuyen la salud, bienestar y motivación y pueden incrementar el absentismo. Tales sistemas suponen pérdidas en los tiempos de uso y no son explotados en su totalidad en la medida en que el usuario pierde interés en el uso de las características avanzadas del sistema, que en algunos casos podrían no utilizarse nunca. (caso de los sistemas de reproducción de vídeo)

Mejora en la calidad del producto: el diseño centrado en el usuario resulta en

productos de mayor calidad de uso, más competitivos en un mercado que demanda productos de fácil uso.

2. Cuando se ha de considerar la usabilidad La usabilidad debería ser considerada en todo momento, desde el mismo comienzo del proceso de desarrollo hasta las últimas acciones antes de hacer el sistema, producto o servicio disponible al público. Antes de iniciar el proyecto es esencial tener una idea acerca de las características de los usuarios y de los aspectos del producto de mayor interés y necesidad. Teniendo en cuenta estas consideraciones de forma temprana se ahorra tiempo y dinero, dado que la posterior implementación de nuevos aspectos o nuevas interfaces de usuario implican un enorme esfuerzo adicional. Incluso una vez que el producto está en el mercado se debería preguntar a los usuarios acerca de sus necesidades y actitud respecto del mismo.

DISEÑO CENTRADO EN EL USUARIO Podemos ceñirnos al significado literal de la expresión y pensar que el Diseño Centrado en el Usuario consiste en diseñar por y para el usuario. La aparición del término "Diseño Participativo", por otra parte, va a plantear la necesidad de efectuar una serie de consideraciones acerca de la figura del diseñador en el proceso de desarrollo Frente a esta discusión, que hago la aclaración se centra en la interfaz informática y su desarrollo en términos de diseño, se puede extrapolar de una manera más amplia al campo del diseño de cualquier tipo de producto, se convierte en la conceptualización que han realizado diferentes equipos de trabajo e investigación frente al tema. Para poder caracterizar la diferencia de conceptos podemos evidenciarlos de acuerdo a quien y como los definieron, pues no solo es una cuestión de semántica: David Travis, de System-Concepts (http://www.system-concepts.com/), indica que la idea de "diseño centrado en el usuario" propone que los diseñadores comprenden el contexto de uso: esto significa un profundo entendimiento del usuario, del entorno en el que se desarrolla el trabajo y las tareas de usuario. En contraste, la expresión "diseño centrado en el uso" sugiere que el diseñador sólo necesita concentrarse en las tareas de usuario, lo que parece que hace entender al usuario y al contexto como algo menos

9

importante. Sin embargo Travis indica que en la práctica, se plantean muy pocas diferencias entre ambas aproximaciones, y entiende el término "centrado en el uso" como una cuestión de marketing. Jan Gulliksen, de la Universidad de Uppsala (Departamento de Interacción Hombre-Computadora), presenta una opción casi opuesta, pues alega que el diseño centrado en el uso no involucra al usuario en el proceso de diseño, mientras que el diseño centrado en el usuario apunta a una presencia activa directa de este en el proceso de desarrollo del mismo, entendiendo el concepto de la misma forma que los norteamericanos entienden el de "diseño participativo". Además lleva por delante la importante distinción entre comprador y usuario final (un administrativo en una corporación no elige la aplicación informática mediante la cual realizará su trabajo). Gulliksen propone cuatro principios básicos en la aproximación al Diseño Centrado en el Usuario:

Un reparto apropiado de funciones entre usuarios y sistema Una participación activa de los usuarios Iteraciones en las soluciones de diseño Equipos de Diseño Multidisciplinares

Heimrich Kanis, de la Delft University Technology (Departamento de Ergonomía), asume otro significado de la expresión "centrado en el uso" y habla de modos o posibilidades de uso. Así, en el estudio de una interacción particular producto-usuario se requerirán de dos fuentes de datos básicas: las procedentes de los estudios ergonómicos (antropometría, funciones fisiológicas,...) y las de las actividades de los individuos en su uso del producto como gran condicionante de la funcionalidad del mismo. Al igual que Gulliksen, conviene que lo verdaderamente importante es, pues, el modo en el que el usuario interacciona con un producto y, en particular, con un prototipo, durante los diversos experimentos en el proceso de desarrollo. 1. Diseño centrado en el usuario – diseño participativo Se diferencia el Diseño Participativo del Diseño Centrado en el Usuario en que mientras éste considera al usuario tan sólo al comienzo y al final del proceso de diseño, aquel lo integra por completo en el proceso de desarrollo. La distinción es importante porque las gestiones de los respectivos procesos de desarrollo son completamente diferentes y especialmente más complejos en el caso del diseño participativo. Sin embargo, esta diferencia que se está estableciendo sólo es válida en el ámbito norteamericano, dado que en Europa se habla de Diseño Centrado en el Usuario (más bien se está empezando a hablar) con el mismo significado que el Diseño Participativo en Estados Unidos. Allí, el Diseño Participativo es más que desarrollar sistemas, quedando íntimamente relacionado con una perspectiva de democratización del lugar de trabajo que potencia al trabajador. En este sentido podríamos decir no solamente trabajador sino usuario, pues la dimensión puede ser aplicada a cualquier tipo de producto. Una vez establecida la distinción entre Diseño Centrado en el Usuario y Diseño Participativo, resulta conceptualmente sencillo asumir que este último no sólo involucra a diseñadores y usuarios sino también a expertos en factores humanos e integrantes de la

10

dirección. Tal variedad se va a traducir inevitablemente en conflictos de objetivos, competencias e incluso valores que conviene tener presentes. En síntesis el concepto de diseño centrado en el usuario puede ser sinónimo del diseño participativo para poder generalizar las visiones tanto norteamericana como europea. El diseño centrado en el uso , podría considerarse como una visión menos integral en el proceso de diseño, puesto que deja al usuario fuera del proceso y solo lo atiende en la información de entrada de este y en la retroalimentación que se genera al final cuando se pretende comprobar que lo realizado si cumple con los objetivos iniciales. Siendo un poco fuertes en la percepción, esto es lo que permite el QFD, con la visión desde la ingeniería, en donde el usuario se convierte en una serie de datos que alimentan el modelo y que permiten en “teoría” llegar a una respuesta óptima en el desarrollo del producto. En este punto quisiera aclarar una concepción que se tiene desde la formación de diseñadores industriales alejados de la concepción de la ingeniería: La razón de ser del diseñador no es el objeto, es el usuario, por lo tanto los objetos se deben a los usuarios y en esta medida su existencia depende de ellos, no de su fabricación, rentabilidad, o puesta en escena en el mercado. Suena un poco romántica la posición, pero en esencia esa es la razón de la existencia del diseñador, pues es el canal dentro de los sistemas de producción y del mercado, que le permiten participar al usuario en lo que realmente quieren.... Esta visión dista mucho de la acuñada desde la ingeniería en donde sucede todo lo contrario, pues el objeto es un fin y no un medio para la satisfacción de las necesidades, expectativas y deseos de los “usuarios”, “demandantes” o como se les quiera denominar a las personas a las que van dirigidos los objetos-producto.

EL DISEÑADOR EN EL PROCESO DE DESARROLLO

Vamos a revisar rápidamente una serie de cuestiones a las que se tiene que enfrentar el diseñador en el proceso de desarrollo y que revelan la necesidad de participación e integración para una evolución apropiada del diseño. Un primer, y sorprendente, problema va a aparecer en la elección del investigador o del equipo encargado del trabajo de campo, de la búsqueda de requerimientos del usuario y del análisis del contexto. No abundan los especialistas en factores humanos y usabilidad, siendo frecuente que diseñadores y técnicos hayan de asumir ciertas funciones ampliando su formación. La noción de investigar un contexto o un espacio de diseño, de contemplar y combinar variadas soluciones no les resulta sencilla a los diseñadores, acostumbrados a que se les planteen problemas bien definidos para los que buscan una solución directa. La comunicación con el usuario y, lo más importante, el entendimiento del mismo, peligran en estas situaciones. También puede ocurrir que usuarios experimentados y veteranos sean destinados a la dirección de proyectos con el propósito de superar más rápidamente una etapa de captación de requerimientos. Se busca, además, partir con cierta ventaja sobre

11

experiencias previas, pero supone un riesgo importante la adopción de un actitud inmovilista respecto de las experiencias propias. Hemos oído muchas veces eso de que los usuarios no son diseñadores y los diseñadores no son usuarios. Efectivamente, es frecuente que a la hora de llevar a la práctica determinadas metodologías de participación, los diseñadores partan con ideas preconcebidas acerca de los usuarios. Los diseñadores piensan en ocasiones que los usuarios no entienden de cuestiones técnicas o tecnológicas, que no saben lo que necesitan o que son incapaces de generar ideas de diseño. Tal circunstancia se puede traducir en la contaminación de las sesiones de participación, pues el diseñador, en caso de intervenir, no potencia al máximo, e incluso rehuye, el diálogo y la interacción. El diseñador, por otra parte, trata, a menudo, de expresarse a través de su diseño, lo que, dada, en general, la complejidad y amplitud de su formación, puede reflejarse en sistemas excesivamente complejos que el usuario, inevitablemente, rechaza en el momento que se le solicita para trabajar con los correspondientes prototipos También se plantean conflictos de objetivos entre diseñadores y expertos en factores humanos. Los especialistas en ergonomía cognitiva no tienen una especial predilección por el diseño, que, explícitamente, asocian con tecnología. En muchas ocasiones, su trabajo se relega a fases finales del proyecto; es, a posteriori, cuando han de asesorar al usuario y evalúan el impacto del diseño. Sin embargo, su actividad es fundamental en las etapas iniciales al desarrollo. No faltan conflictos entre desarrolladores y dirección. La dirección soporta presiones con una continua exigencia de resultados y los directivos acuden a los diseñadores: necesitan algo que enseñar. Probablemente el diseño no estará terminado o requerirá modificaciones, ensayos, inspecciones, pero pasará a tener un carácter de compromiso hacia los altos ejecutivos.

FACTORES HUMANOS Y MARKETING

Aunque no es el único factor para la venta de un equipo o la contratación de un servicio, cada vez más productos cuelgan la etiqueta de "fácil de usar" como un argumento con el objetivo de ganar al cliente en estos tiempos de feroz competencia.

Atrás quedan los tiempos en que las novedades tecnológicas justificaban por sí mismas la dificultad de uso. Un claro ejemplo son los ordenadores domésticos,

12

uno de los equipos de consumo doméstico que más crecimiento tendrán en un futuro muy próximo. Si con los primeros equipos era imprescindible leerse un largo manual simplemente para poder interconectar los distintos componentes y ponerlo a funcionar, ahora esto es impensable en un equipo dirigido al consumo doméstico. Pero lo mismo puede decirse de los vídeo-cassettes domésticos (la dificultad de su programación, que todos hemos experimentado, es el ejemplo más común de "falta de usabilidad"), aparatos de fax, sistemas de sonido domésticos, que en muchos casos incorporan múltiples funciones de las cuales luego se usan únicamente unas pocas. Todos estos hechos son extensibles a los nuevos servicios de telecomunicaciones, como los servicios suplementarios en la red telefónica básica o en los nuevos servicios móviles.

En un mercado cada vez más maduro y competitivo, el precio no es el principal argumento para un consumidor a la hora de tomar una decisión. Más bien debiéramos hablar de la relación calidad/precio. Factores como la integración de todos los elementos de un sistema, su facilidad de uso y el óptimo ajuste de las funciones a las necesidades y deseos de los usuarios, y la calidad global del servicio son argumentos decisivos para la venta de un producto de alta tecnología.

Los objetivos de Factores Humanos y del Marketing de los productos son complementarios: en el primer caso, se trata de garantizar al máximo que el sistema o servicio se ajusta a las necesidades y capacidades de los usuarios, y en el segundo, convencer a los posibles clientes de que con el producto se satisfarán sus necesidades, y que el precio que pagarán por él corresponde a la calidad con que está desarrollado. De hecho, ambas áreas tienen en común el uso de una misma metodología, que implica muy de cerca a los usuarios en el desarrollo y comercialización de los productos, y que puede perfectamente llevarse en paralelo. Los Factores Humanos se centran en la etapa de diseño funcional y desarrollo del producto, y el Marketing en los argumentos de venta, la publicidad y los canales de distribución.

La conjunción de las herramientas y conocimientos de ambas disciplinas son la garantía del éxito en un mercado cada vez más difícil, con el objetivo final que podemos resumir en siguiente lema: "conoce a tus usuarios, convéncelos de que tus productos son los mejores, y garantiza su satisfacción a lo largo del tiempo".

Como vemos el problema de la usabilidad es un tema que cada día toma más vigencia e importancia al interior de las organizaciones que desarrollan productos, y por ende dentro de los procesos de desarrollo de productos. Es un factor que empieza a relacionar las diferentes áreas de la empresa, pues en últimas la organización tiene sentido en la medida que venda los productos, satisfaga las necesidades de sus clientes de una manera óptima (mejor que la competencia), y aquí es donde la usabilidad tiene sentido, pues se convierte en un factor diferenciador, de captación de nuevos clientes y por ende de permanencia en el mercado.

Aunque no lo creamos se convierte en un factor de vital importancia hasta en la reducción de costes al interior de la organización y por ende, incremento en la rentabilidad de los productos y de la ampliación del ciclo de vida de estos, que cada día se hace mas corta.

13

COSTE Y BENEFICIO DE LA INGENIERÍA DE "USABILIDAD" Marcos F. Sanz, Enrique J. Gómez, Francisco del Pozo Grupo de Bioingeniería y Telemedicina ETSI Telecomunicación - Ciudad Universitaria s/n 28040 Madrid · Tel. (91) 549 57 00 ext. 332 Fax (91) 336 68 28 · Email marcos@teb.upm.es

A menudo, los ingenieros de "usabilidad" tienen ciertas dificultades para encontrar argumentos que justifiquen el consumo de recursos en la mejora substancial de las interfaces de usuario de los sistemas de información interactivos.

En este artículo se pretende ayudar a esgrimir esos argumentos de una forma más comprensible para los gestores de empresas o los directores de proyecto: utilizando parámetros económicos.

Se describen los beneficios de la Ingeniería de "usabilidad" y se revisan ejemplos de su traducción a términos económicos.

Asimismo, se revisa un modelo simplificado para el cálculo de la relación coste-beneficio de un proceso de desarrollo caracterizado por iteraciones de diseño con evaluaciones de "usabilidad".

Finalmente se busca el proceso de este tipo que presenta una relación beneficio-coste máxima, en función del número de iteraciones y del número de usuarios utilizados.

"Estoy seguro de que le encantaría hacer algún experimento con usuarios, pero no hay tiempo ni presupuesto en nuestra planificación; además me preocuparé más sobre la interfaz de usuario cuando alguien pueda demostrar que provoca un aumento en las ventas".

Con esta frase zanjaría un gestor la petición de un ingeniero de consumir más recursos en el desarrollo de la interfaz de usuario.

Sabemos que la Ingeniería de "Usabilidad" produce mejores interfaces de usuario para los sistemas de información, y sabemos cómo lo consigue, pero es difícil convencer a los gestores de que vale la pena gastar ciertos recursos en esas actividades; en general piensan que es un lujo que no se pueden permitir.

La razón principal es que mientras los costes de los procesos de diseño son fácilmente calculables, los beneficios son mucho menos tangibles, más aún si se desarrollan productos comerciales que no hay que "sufrir" internamente en la organización.

Un incremento en las ventas que muchos piensan que es atribuible directamente a la Ingeniería de "Usabilidad" es muy difícil de medir porque la "usabilidad" es sólo un componente del reclamo total de un producto.

14

El público compra por razones muy diferentes y diversas, y un producto difícil de usar puede ganar un gran sector de mercado porque otras características compensan su falta de "usabilidad" (o por una gran campaña publicitaria).

El resultado es que tenemos pocos argumentos para convencer del valor de la Ingeniería de "Usabilidad" en términos económicos y obtener así más recursos para realizar una actividad de trascendental importancia para alcanzar competitividad en el desarrollo de sistemas de información.

Para ello en primer lugar se describirán lo que se consideran beneficios de la Ingeniería de "usabilidad", incluyendo algunos ejemplos reales.

En segundo lugar se revisarán dos estudios con datos significativos sobre el dinero ahorrado gracias a esta actividad, los cuales nos servirán para ver ejemplos de cálculo de la relación coste-beneficio de la Ingeniería de "Usabilidad".

En tercer lugar se reproduce un modelo simplificado del cálculo de la relación coste-beneficio, que podría ser particularizado para las actividades concretas de Ingeniería de "usabilidad" que se realicen en cada empresa.

Teniendo en cuenta que una actividad prácticamente común a todos los procesos de Ingeniería de "usabilidad" es el rediseño de prototipos de la interfaz de usuario tras evaluaciones de usabilidad (iteraciones de diseño), se revisará a continuación un estudio que, basándose en el modelo anterior de coste-beneficio, trata de obtener el número óptimo de usuarios en cada evaluación y el número óptimo de iteraciones de diseño, para obtener la mejor relación beneficio-coste.

Finalmente, se discuten los resultados de todos estos estudios y se propone un proceso básico de Ingeniería de "Usabilidad" caracterizado por el número de usuarios involucrados y el número de iteraciones de diseño.

1. Beneficios de la Ingeniería de "Usabilidad"

Podemos dividir estos beneficios en dos grupos: los beneficios para el equipo que desarrolla un producto, y los beneficios para el cliente que lo compra (o usuario).

Estos últimos deben influir en el aumento de ventas (aunque no esté claro cómo), o convertirse en beneficios para la propia organización si se está desarrollando un producto de uso interno.

Beneficios para el equipo de desarrollo: Reducción de los costes del desarrollo y del control de calidad, y salida al

mercado más rápida.

El diseño, desarrollo y prueba de prestaciones con baja "usabilidad" suelen consumir más recursos porque necesitan más modificaciones al no cumplir fielmente los requisitos de usuario.

Reducción del coste de las ventas y ciclos de venta más cortos.

15

Tener un producto deseable hace más fácil su venta, pero además, un producto utilizable facilita la instalación, la configuración, las demostraciones, la distribución y su aprendizaje. Los beneficios durante estas actividades se pueden medir directamente multiplicando el ahorro de tiempo en la venta por el coste de los vendedores.

Posible aumento de ventas del producto.

Los usuarios se sienten mejor con un producto utilizable (recuérdese que la actitud del usuario es un componente de la "usabilidad"). Esta actitud es completamente subjetiva, pero la decisión de compra también es en gran parte subjetiva.

Reducción de los costes del soporte al usuario.

Los productos fáciles de instalar, de aprender y de usar generan menos peticiones de soporte.

Beneficios para el usuario (que puede ser la misma organización que desarrolla):

Reducción del tiempo de realización de tareas.

Una mayor eficiencia y efectividad, como componentes de la "usabilidad", provocan una reducción directa del tiempo que se tarda en realizar tareas. Esta reducción de tiempo por el coste del usuario (como empleado) da una medida directa del ahorro.

Reducción de la tasa de errores del usuario.

La mayor eficiencia y efectividad de un sistema utilizable también provoca una reducción directa del número de errores en la realización de tareas. Se puede calcular el beneficio multiplicando el número de errores evitados por el coste de cada error (en tiempo de recuperación, perdida de calidad del resultado de la tarea, etc.).

Aumento de la satisfacción.

La satisfacción del usuario es un componente de la "usabilidad" que debe provocar un aumento del rendimiento, pero su traducción a parámetros económicos es muy difícil (salvo que se pudiera medir, por ejemplo, una reducción del absentismo laboral).

Reducción del coste de mantenimiento.

Un producto fácil de instalar y de usar, presenta menos fallos, y necesita mucho menos mantenimiento interno.

Reducción del coste de entrenamiento inicial y de re-entrenamiento.

16

Si el producto es fácil de aprender y de recordar, se puede calcular el beneficio multiplicando el tiempo ahorrado por el coste del usuario (como empleado).

En muchos casos estos beneficios han podido calcularse en términos económicos.

Por ejemplo, Brad Myers (Carnegie Mellon University) refiere [MYER94]:

• Un estudio demostró que el ahorro conseguido como consecuencia del desarrollo de una buena interfaz de usuario fue de 41.700 dólares en una aplicación sencilla utilizada por 23.000 empleados, y de 6.800.000 dólares para una aplicación compleja utilizada por 240.000 empleados.

• Otros estudios han estimado que la relación entre el beneficio obtenido y el coste de desarrollar una buena interfaz puede ser más de 5.000 a 1.

• Se han desarrollado incluso modelos matemáticos que estiman el ahorro en 39.000 dólares para un proyecto pequeño, 613.000 dólares para un proyecto mediano, y 8.200.000 dólares para un proyecto grande.

Bill Curtis y Bill Hefley (Carnegie Mellon University) [CURT94] refieren que durante un estudio comparativo entre dos estaciones de trabajo con funciones similares se estimó que una diferencia de 0,8 segundos en cada transacción de cada operador ahorraba 2.400.000 dólares al año.

S. Dray (Dray & Associates.) refiere lo siguiente [DRAY95]:

• Un estudio de la compañía NCR mostró un incremento en la producción del 25% y una reducción adicional del número de errores también del 25%, como resultado del nuevo diseño de la interfaces de usuario.

• En otra compañía, el resultado de un análisis fue que una buena interfaz de usuario reducía el entrenamiento necesario en un 35% y reducía el tiempo de supervisión en un 30%.

• Un estudio similar en IBM mostró que el tiempo de entrenamiento para un sistema era de una hora, frente a una semana en un sistema equivalente sin una buena interfaz de usuario.

Por supuesto, también se pueden encontrar perjuicios debidos a que no se practica la Ingeniería de "Usabilidad".

S. Dray refiere también [DRAY95]:

• Una compañía de seguros invirtió 3 millones de dólares en una aplicación para sus agentes; sin embargo, estos se negaron a utilizarla porque era "imposible de usar y de aprender".

• En otra empresa el entrenamiento en su sistema duraba normalmente 6 meses, pero sus empleados trabajaban sólo durante 18 meses.

• En un sistema de soporte a la gestión una de las funcionalidades más relevante y cara no fue utilizada nunca porque los usuarios olvidaron como acceder a ella una semana después del entrenamiento.

17

Brad Myers (Carnegie Mellon University) refiere [MYER94]:

• La complicada interfaz de usuario del sistema de seguimiento Aegis contribuyó al derribo erróneo del avión de pasajeros Iraní.

• La incapacidad del barco estadounidense Stark para repeler los misiles Exocet fue debida en parte a una interfaz de usuario.

• Un error en la implementación del manejo del cursor contribuyó a la muerte de varios pacientes por exceso de radiación en su tratamiento.

2. Ejemplos de cálculo de la relación coste-beneficio

Para ilustrar como se podría realizar el cálculo de la relación coste-beneficio de practicar la Ingeniería de "Usabilidad" revisamos dos estudios realizados por Clare-Marie Karat de IBM [KARA93].

Primer estudio

El primer proyecto estudiado por Karat consistía en reemplazar un sistema de información para gestión y añadir una nueva función.

El proceso de Ingeniería de "Usabilidad" se completó dentro de los siete meses planificados para la duración del proyecto.

Este proceso incluyó tres iteraciones con evaluaciones de "usabilidad", las cuales eran una mezcla de pruebas, tanto de prototipos como de la aplicación final, en entornos reales y en laboratorios. También incluyó análisis de tareas, diseño de pantallas, y elaboración de informes y recomendaciones de rediseño.

El coste de la Ingeniería de "Usabilidad", mostrado en la Tabla 1, incluye el coste de los recursos consumidos (básicamente el tiempo del ingeniero), los viajes de los usuarios, y el trabajo relacionado con las evaluaciones. El coste total fue de 20.700 dólares.

Karat calculó el beneficio de la Ingeniería de "Usabilidad" como el aumento de la productividad del usuario en la realización de las tres primeras tareas con el nuevo sistema.

La mejora de la productividad fue medida en términos de los cambios que se debían directamente a mejoras en el diseño de la interfaz de usuario, medidos entre la primera evaluación de "usabilidad" (primera iteración de diseño) y la última.

Estos cambios en la productividad eran debidos exclusivamente a la Ingeniería de "Usabilidad", ya que el equipo del proyecto declaró que sin evaluaciones de "usabilidad" habría implementado la primera interfaz propuesta, por lo que ésta (la interfaz de la primera iteración) es el punto de partida para calcular los beneficios de la Ingeniería de "Usabilidad".

18

El valor del aumento en la productividad del usuario con el nuevo sistema (41.700 dólares; ver Tabla 1) fue calculado multiplicando la diferencia en el tiempo empleado en las tareas entre la primera iteración de diseño y la última (4,67 minutos) por la población de usuarios (22.786); las horas resultantes (1.781 horas) se multiplicaron por una tasa de productividad menor que 100% (los empleados nunca trabajan el 100% del tiempo que pasan en el trabajo) y después por el coste del personal, según la administración de la empresa.

Estos datos muestran un beneficio que es el doble del coste, sólo considerando las tres primeras realizaciones de las tareas; pero, en realidad, el beneficio sería mucho mayor si se tuviera en cuenta el incremento posterior en la productividad, tras un entrenamiento mayor con el sistema, y contabilizando todas las realizaciones de las tareas.

Segundo estudio

El segundo proyecto estudiado por Karat consistía en la sustitución de un proceso semiautomático por otro completamente automático.

Se trataba de una aplicación compleja de gestión que se desarrolló a lo largo de 21 meses.

La Ingeniería de "Usabilidad" incluía análisis de tareas, diseño de pantallas, evaluación del punto de partida para las mejoras, evaluación de la "usabilidad" de prototipos, y elaboración de informes y recomendaciones de rediseño.

Los costes son similares a los del ejemplo anterior pero añadiendo el coste adicional de desarrollar un prototipo funcional (ver la Tabla 2).

Los beneficios obtenidos fueron calculados multiplicando la media del tiempo ahorrado en las tareas del usuario entre la primera iteración de diseño y la última (9,6 minutos) por el número de tareas completadas con el sistema en un año (1.308.000); al igual que en el ejemplo anterior, las horas resultantes (209.208) se multiplican por una tasa de rendimiento menor de 100%, y por los costes del personal.

19

El ahorro total resultó ser de 6.800.000 dólares en un año, lo que supone un balance entre el coste y el beneficio de 1:100.

¿No deberían servir estos datos para con vencer a los gestores y clientes de que sistemas de información desarrollados siguiendo un proceso de Ingeniería de "Usabilidad", se amortizan más rápidamente y generan un aumento de la productividad durante un largo plazo?

Si aún no son suficientemente convincentes, Karat refiere algunas estadísticas muy interesantes sobre el ciclo de vida del "software" (también Myers y Rosson en [MYER92]):

* La interfaz de usuario es aproximadamente el 60% de las líneas de código del total de un sistema de información interactivo.

* Una interfaz de usuario gráfica supone como mínimo el 29% del presupuesto de desarrollo de un sistema de información interactivo.

* El 80% por ciento de los costes del ciclo de vida del "software" se produce después de que el producto haya sido distribuido, y el 80% por ciento de este coste se debe a requisitos no cumplidos (sólo el 20% por ciento es debido a errores o falta de fiabilidad).

Todas estas estadísticas son aún más significativas si tenemos en cuenta que un estudio de 1993 concluyó que el 97% de todo el desarrollo de "software" sobre UNIX incluía una interfaz de usuario gráfica [XBUS94].

3. Modelo coste-beneficio

En un trabajo de Jacob Nielsen y Tom Landauer, de los laboratorios Bell [NIEL93a], se describe un modelo sencillo para el cálculo de la relación coste-beneficio.

20

Este modelo fue utilizado para estimar el número de usuarios óptimo en un proceso típico de Ingeniería de "Usabilidad" que se caracteriza por incorporar varias iteraciones de diseño y evaluación.

3.1 Modelo simplificado de coste

Nielsen describe el cálculo del coste de la Ingeniería de "Usabilidad" de la siguiente manera:

Coste: tiempo empleado por especialistas en usabilidad (programadores, asistentes de laboratorio, etc.) y usuarios, multiplicado por el coste de cada uno, que incluye: sueldo, espacio de oficina, uso de laboratorios, equipos especiales para evaluaciones de "usabilidad", consumibles (generalmente son despreciables).

Estos costes, para cada actividad de Ingeniería de "Usabilidad", en general se pueden dividir en costes variables y costes fijos.

Los costes fijos son los resultantes de planificar y preparar la actividad, y los variables son los resultantes de repetir la actividad (en cada iteración).

Sin embargo, ambos costes dependen fuertemente de las características del sistema que se desarrolla y de su complejidad.

3.2 Modelo simplificado de beneficio

Para calcular los beneficios Nielsen distingue entre los sistemas de información que se desarrollan para ser utilizados en la misma organización (o internos) y sistemas de información comerciales:

Sistemas internos:

Incremento de la productividad del usuario. Reducción del tiempo de entrenamiento. Incremento de la satisfacción del usuario (difícil de cuantificar

económicamente).

Sistemas comerciales:

¿Incremento de ventas o del precio?.

Los beneficios para el cliente son los mismos que los anteriores, pero son difíciles de convertir a beneficios para el productor, que debe intentar vender más o más caro; esta dificultad está disminuyendo a medida que la "usabilidad" se está convirtiendo en un importante factor de compra.

Reducción del coste del soporte (por ejemplo, menos llamadas al servicio técnico).

21

Relación coste -beneficio óptima en función del número de usuarios en una evaluación

Para encontrar la relación coste-beneficio óptima, Nielsen y Landauer, analizando 12 proyectos, desarrollaron un modelo de la búsqueda de problemas de "usabilidad" durante un proceso de Ingeniería de "Usabilidad" que incluía evaluaciones con usuarios.

La Ecuación 1 representa dicho modelo.

En esta ecuación PU(i) es el número de problemas de "usabilidad" encontrado en i evaluaciones (es decir, i usuarios en el mismo ciclo iterativo y con el mismo sistema o prototipo), N es el número total de problemas de "usabilidad" en la interfaz de usuario, y l es la probabilidad de encontrar un problema de "usabilidad" cuando el sistema se evalúa con un sólo usuario.

3.3 Número óptimo de usuarios

Para aplicar de forma práctica este modelo hay que tener en cuenta que no se pueden utilizar un número infinito de usuarios en cada evaluación para encontrar todos los problemas de "usabilidad"; ni siquiera es práctico utilizar un número elevado de usuarios.

Afortunadamente los usuarios no buscan perfección, por lo que Nielsen propone encontrar el número de usuarios para cada evaluación que proporciona una relación beneficio-coste máxima.

Para ello Nielsen parte de dos premisas:

a) Los costes fijos y variables son conocidos: los costes fijos se amortizan al aumentar el número de usuarios, mientras que los costes variables se incrementan proporcionalmente al número de usuarios.

b) Hay un valor estimado para el beneficio de encontrar y solucionar cada problema de "usabilidad": este valor es muy difícil de calcular, más aún teniendo en cuenta que los beneficios crecen con la magnitud del problema y que es difícil solucionar problemas graves dentro de la planificación del proyecto. Nielsen (suponemos que basándose en su experiencia) refiere 15.000 dólares como un valor representativo del beneficio por cada problema de "usabilidad" solucionado.

En la Figura 1 reproducimos la variación de la relación coste-beneficio en función del número de usuarios de la evaluación, que Nielsen proporciona teniendo en cuenta datos sobre proyectos de tamaño medio.

22

Se observa que evaluando sólo con un usuario, el beneficio es 50 veces el coste, y que la relación máxima (70 veces) se obtiene evaluando con 3 usuarios.

En cualquier caso, los beneficios son siempre muy superiores al coste.

Nielsen reconoce que las suposiciones hechas y los números utilizados para llegar a esta curva pueden no ser aplicables a otros proyectos, pero afirma que la forma general de la curva si es representativa.

Nielsen concluye sosteniendo que, en cualquier caso, el número óptimo de usuarios está entre tres y cinco; es decir, realizando una evaluación con ese número de usuarios, se obtiene una relación beneficio-coste máxima (teniendo en cuenta que el beneficio es siempre mayor que el coste mientras no se sobrepase un número muy alto de usuarios).

3.4 Número óptimo de iteraciones

Ni los mejores expertos en "usabilidad" pueden diseñar una interfaz de usuario perfecta en el primer intento. Como ya se ha mencionado en la introducción, los ciclos iterativos de diseño son una característica básica de los procesos de diseño de interfaces de usuario. En otro estudio realizado también por Jacob Nielsen [NIEL93b] se demuestra el aumento de "usabilidad" del sistema en cada ciclo de rediseño, y por lo tanto se deduce un aumento del beneficio.

Sin embargo, no se puede estimar un modelo para este beneficio, ni por lo tanto un modelo de la relación coste-beneficio, ya que no existe ninguna relación entre los problemas de "usabilidad" que se solucionan en un ciclo y los que se solucionan en el siguiente.

En cada ciclo, la interfaz sufre cambios en el diseño, con los que algunos problemas de "usabilidad" desaparecerán, pero no se puede asegurar que no se crearán otros (de hecho es así casi siempre).

Esta falta de relación entre los problemas de "usabilidad" en dos ciclos de desarrollo es total si como resultado de una evaluación se decide un nuevo diseño debido al fracaso del anterior.

23

La cuestión de hasta donde se puede llegar en el aumento de la "usabilidad" de un sistema, incrementando el número de ciclos iterativos de diseño, sigue abierta.

Lo único que se puede inferir del estudio realizado por Nielsen es que, en general, la mayor parte de las mejoras, y las más importantes, se consiguen en los primeros ciclos, y que las mejoras disminuyen al aumentar el número de iteraciones.

Concretamente, Nielsen propone dos iteraciones, o sea, tres versiones del sistema.

Discusión

Hay varios comentarios que matizan las conclusiones de Nielsen.

En primer lugar, hay que resaltar la dificultad de aplicar a todos los proyectos el razonamiento que sigue Nielsen (como él mismo reconoce).

La estimación general del beneficio de solucionar un problema de "usabilidad" parece imposible debido a la infinita variedad de proyectos y problemas de "usabilidad" con los que nos podemos encontrar.

Un buen diseño inicial de la interfaz de usuario disminuirá enormemente el beneficio que se obtiene al solucionar pequeños problemas de "usabilidad" (que son los que quedan), mientras que un diseño inicial desastroso puede agigantar estos beneficios si, por ejemplo, como resultado de la evaluación, se decide un cambio radical en la interfaz de usuario.

24

Por ello, aunque la forma general de la curva de la Figura 1 es aceptable (porque además es totalmente lógica), es tremendamente arriesgado estimar un número óptimo de usuarios en función de una estimación general del beneficio de solucionar un problema de "usabilidad".

Por otro lado, y en la misma línea, no se puede asegurar que cualquier problema de "usabilidad" que tenga un usuario, sea un problema general de "usabilidad" del sistema; quizá simplemente se deba a características concretas de ese usuario experimental.

En consecuencia, con pocos usuarios evaluando el sistema, la confianza estadística que podemos tener sobre si los problemas encontrados son los problemas típicos de esa clase de usuarios es muy baja (recuérdese que la "usabilidad" de un sistema de información interactivo tiene sentido cuando se define para una clase concreta de usuarios).

A pesar de todo ello, la experiencia nos muestra (coincidiendo con la de Nielsen y otros autores), que los problemas graves de "usabilidad" aparecen rápidamente, y que se presentan como tales para la mayoría de los usuarios; por ello, aunque no se pueda precisar un número óptimo de usuarios para todos los proyectos, sí es razonable que este número sea bajo.

En segundo lugar, este razonamiento puede ser válido para realizar evaluaciones formativas (para obtener recomendaciones de diseño), ya que lo que importa obtener en este caso son datos cualitativos sobre el uso del sistema.

Pero en el caso de evaluaciones sumativas, en las que se pretenden obtener datos cuantitativos para comparar el sistema con otros (o con versiones anteriores del mismo sistema), con pocos usuarios cualquier posible interpretación de los resultados no será estadísticamente significativa.

Conclusiones

Podemos concluir, por lo tanto, que una evaluación formativa siempre valdrá la pena, pero que es recomendable utilizar pocos usuarios.

Quizá el número óptimo estaría entre 3 y 8, dependiendo de la complejidad del proyecto; parece razonable que en proyectos con alto presupuesto e interfaces de usuario complejas, haya más problemas de "usabilidad" que encontrar, más recursos para buscarlos, y más necesidad de confianza estadística en los resultados.

Además, en el caso de que se utilicen menos de 6 usuarios, es necesario interpretar los problemas encontrados para consumir los recursos disponibles solucionando antes los que sean más representativos de la clase de usuarios a la que se dirige el sistema.

Como segunda conclusión podemos decir que las evaluaciones sumativas no tienen sentido si no se consiguen resultados con una confianza estadística mínima, por lo que el número óptimo de usuarios podría estar entre 6 y 10.

25

En cuanto al número de iteraciones, es razonable también que sean más necesarias en proyectos complejos con interfaces de usuario complejas.

Por ello se propone ampliar el margen del número de iteraciones a 1 ó 3, según sea la complejidad del proyecto.

En definitiva, un proceso de Ingeniería de "usabilidad" que involucre a usuarios en evaluaciones de "usabilidad" de prototipos, podría obtener una relación coste-beneficio óptima si incluye entre 1 y 3 evaluaciones formativas, utilizando en cada una entre 3 y 8 usuarios.

Sin embargo, esto no quiere decir que en cualquier caso éste sea el proceso óptimo, ya que, muchas veces, otras técnicas de diseño que no utilizan usuarios (por que los sustituyen) pueden obtener una relación coste-beneficio mejor.

La razón es que, con estas técnicas, se puede conseguir un diseño inicial suficientemente bueno como para reducir el número de ciclos de iteración.

En resumen, con usuarios, o sin usuarios, los beneficios de la Ingeniería de "Usabilidad", sea cual sea el proceso concreto de diseño que se siga, son siempre muy superiores a su coste, y aunque se disponga de pocos recursos para mejorar el diseño de la interfaz de usuario, cualquier trabajo en este sentido será ampliamente recompensado.

Sin embargo, los argumentos económicos probablemente serán sólo un eslabón, aunque esencial, del razonamiento necesario para convencer a los gestores de la importancia de la Ingeniería de "Usabilidad".

Primero sería necesario alinear esta actividad de ingeniería con los planes de la empresa.

Por ejemplo, sería muy efectivo mostrar que la Ingeniería de "Usabilidad" es el medio adecuado para alcanzar objetivos expresados por frases como: "la seguridad de nuestros empleos aumentará en función de la calidad del servicio que ofrecemos a nuestros clientes", "necesitamos pasar más tiempo con nuestros clientes", o "necesitamos descartar las prácticas del pasado y mirar a las del futuro para mejorar nuestro rendimiento".

En segundo lugar hay que mostrar claramente la necesidad de un cambio.

Mucha gente se ha adaptado a la tecnología durante tanto tiempo que no se dan cuenta de que la tecnología puede ser desarrollada para adaptarse a ellos.

Demostraciones de problemas de "usabilidad" encontrados por clientes, o conferencias con ejemplos de buenos y malos diseños pueden alertar a los gestores.

En tercer lugar hay que mostrar los beneficios del tal cambio, y aquí es donde interviene el análisis de coste-beneficio de la Ingeniería de "Usabilidad" que se ha ilustrado.

Finalmente hay que elaborar planes de incorporación de la Ingeniería de "Usabilidad" a las actividades de desarrollo de la empresa.

26

ANEXOS

COMPILACIÓN DE MÉTODOS DE USABILIDAD QUE ES ESO LLAMADO USABILIDAD

27

ANEXO 1 COMPILACIÓN DE MÉTODOS

DE USABILIDAD

El siguiente documento consiste en una recopilación de herramientas de usabilidad y Diseño centrado en el usuario. En la misma, se han establecido cuatro categorías (Indagación, Inspección, Test y Técnicas Relacionadas), proporcionándose una breve descripción de cada una de ellas, al igual que de los métodos que comprenden. La traducción de los nombres de dichos métodos al castellano (la práctica totalidad de la bibliografía disponible está en lengua inglesa) se ha llevado a cabo con la intención de reproducir con la mayor fidelidad posible el significado de la herramienta. Sin embargo, el autor espera, y desea, que surjan opiniones, comentarios, propuestas alternativas y correcciones. Este documento es la recopilación de herramientas de usabilidad de James Hom (The Usability Methods Toolbox) mientras que los demás están vinculados con lo que podría entenderse como la referencia básica. Es objetivo a corto plazo efectuar un tratamiento de estos últimos métodos en castellano con indicaciones y bibliografía adicional. Mientras tanto, esta página pretende tener más un carácter bibliográfico, dando la oportunidad al lector, al mismo tiempo, de adquirir una perspectiva sobre las técnicas de Diseño Centrado en el Usuario. Métodos de Indagación

Aproximación contextual Aproximación por grupos Aproximación individual Participación remota Generación de ideas Métodos de observación experta

Prototipado y categorización

Prototipado Según la funcionalidad reproducida Según la fidelidad de la reproducción de la interfaz Otras técnicas de prototipado Prototipado rápido Prototipado por vídeo Métodos de categorización

28

MÉTODOS DE INDAGACIÓN APROXIMACIÓN CONTEXTUAL Dentro de la aproximación contextual es posible distinguir dos variantes claramente diferenciadas: Una aproximación contextual propiamente dicha, para la cual el método característico es el de Indagación en el Contexto (Contextual Inquiry). Se trata, básicamente, de un método estructurado de entrevista de campo caracterizado por la necesidad de comprender el contexto, de asimilar al usuario en el proceso de diseño y de plantear un objetivo (focus) en su aplicación. Una aproximación etnográfica, para la cual la bibliografía ofrece muchas denominaciones. Una de las más comunes es el de Estudio etnográfico u Observación de Campo (Etnographic study/Field Observation). Consiste en la observación del usuario y su interacción con el producto en su entorno habitual, prescindiendo de las ventajas del laboratorio a la hora de captar y registrar datos. También se habla de la "Observación al Natural" (Naturalistic Observation), como una variante, menos "agresiva", de la Indagación en el Contexto. Se tiene mayor interés en tareas y en procesos, y se desmarca ligeramente del carácter antropológico del Estudio Etnográfico. De la misma forma, el Estudio de Campo Orientado a la Actividad (Proactive Field Study), contempla, además de la observación de las características de los usuarios, el análisis de tareas, el análisis de objetivos y la evolución del usuario con el sistema sometido a estudio. Una variante de interés es la denominada Etnografía Rápida (Rapid Ethnography), que cuestiona la necesidad de precisión ante la velocidad de obtención de resultados aceptables generados por aproximaciones razonables. También se habla de la Video-Etnografía (Video ethnography) y de la Observación Directa (Direct Observation) como sistemas de Observación Experta, que se caracterizan por ser llevados a cabo por grupos expertos cuyos servicios se alquilan. Indagación (Inquiry) Una primera categoría para la clasificación de los métodos de usabilidad es la de indagación. La identificación de requerimientos, tanto los del usuario como los de nuestro producto, son indispensables en una etapa temprana de un proceso de desarrollo que culmina en la satisfacción de una necesidad del usuario, quien con eficiencia y efectividad habrá de realizar las funciones que ese producto le ofrece. Por tanto, inicialmente, hay que descubrir, y va a resultar de especial interés que las metodologías a aplicar en una primera fase proporcionen información acerca de la usabilidad de un producto que aún no se ha empezado a fabricar.

29

Indagación en el Contexto (Contextual Inquiry) ¿En qué consiste? La indagación en el contexto es básicamente un método estructurado de entrevista de campo, basado en unos pocos principios fundamentales que diferencian este método de la simple entrevista periodística. Así, es más un proceso de descubrimiento que un proceso de evaluación; es más parecido a aprender que a evaluar. Este método se basa en tres principios fundamentales: que entender el contexto en el que un producto es utilizado (el trabajo que está siendo realizado) es esencial para un diseño elegante, que el usuario es parte del proceso de diseño y que el proceso de diseño para la usabilidad, incluyendo los métodos para su mejora como la indagación en el contexto y test de usabilidad, deben tener un objeto o focus. Supongamos, por ejemplo, que se necesita mejorar la usabilidad de una herramienta, una llave, para la reparación de vehículos. Utilizando esta técnica se empezará visitando a los mecánicos al taller de reparaciones, y no sólo habría de fijarse uno en las disposiciones físicas, como pueda ser la localización de las herramientas o las condiciones dentro de los compartimentos del motor, sino también en las cuestiones ambientales, tales como la limpieza de las manos, el nivel de ruido en el taller, o la rigidez de los horarios impuestos por los jefes. Todo esto ayudaría a definir el contexto de su trabajo así como el contexto de uso del producto, la llave. También se oirían quejas sobre la herramienta; cómo se les escapa de las manos si han estado trabajando con sustancias grasas, cómo roe las esquinas de los pernos. Habría que preguntar a los mecánicos qué facilitaría su trabajo, que cambios en el diseño les ayudarían. Forman parte del proceso de diseño. Desde luego, toda esta búsqueda se conduciría sobre la cuestión que se está analizando, esto es, la herramienta. Este enfoque es importante, puesto que establece las metas para la visita (por ejemplo, se necesita saber cómo se guardan las llaves). Una vez que se ha realizado la visita, se podrá comprobar de las notas tomadas si se encontró lo que se necesitaba saber. ¿Cómo lo llevo a cabo? La indagación en el contexto sigue muchos de los pasos de las observaciones de campo y las entrevistas. Sin embargo, es preciso mantener diversas consideraciones en mente con algunas partes del proceso. Por ejemplo, entrevistar durante un estudio basado en este método no contempla la formulación de preguntas completas ni elaboradas. Sin embargo , la relación establecida entre entrevistador y entrevistado desembocará en un diálogo en el que es posible determinar tanto las opiniones y experiencias del usuario como sus motivaciones y contexto. En muchas ocasiones, la presencia del entrevistador va a incomodar al entrevistado. Como entrevistador, es realmente preciso ser parte del mundo del usuario para conseguir la efectividad deseada, lo que puede llevar tiempo hasta que el usuario se acostumbra a

30

su presencia. En ese punto, el trabajo se vuelve mucho más fácil, dado que al usuario le resulta mucho más fácil expresar lo que realmente piensa del producto. Esta circunstancia se traduce en un estudio de larga duración; se establece una relación con la organización que se está estudiando, y se determinan las visitas, su frecuencia y su duración. Se puede establecer un similitud con los estudios etnográficos, en los que el etnógrafo vive durante uno o dos años con una determinada cultura. Es muy importante determinar a quién se va a entrevistar. En muchas ocasiones el usuario final que tenemos en mente no es la persona que más se va a ver afectada por nuestro diseño o rediseño. Por ejemplo, cuando se cambian o actualizan las aplicaciones informáticas de una corporación, la persona más afectada es la encargada de la dirección de los sistemas de información que tiene que instalar la aplicación en cuestión en cada ordenador del edificio. Trabajar con esta persona durante un día nos puede dar una aproximación de lo bien diseñado que está el proceso de instalación y la interfaz. Tras cada visita es preciso determinar si se alcanzaron los objetivos planteados así como las preguntas a efectuar en la próxima visita. ¿Cuándo debería usar esta técnica? La indagación en el contexto es uno de los mejores métodos a utilizar cuando es realmente preciso entender el contexto de trabajo del usuario. El entorno en el que las personas trabajan influye realmente en el modo en el que se hace uso de un producto (¡hay personas que imprimen su correo e indican sus comentarios sobre el mismo antes de contestar!). ¿Quién me puede decir más acerca de ella? Beyer, Hugh, "Getting Started with Contextual Techniques". Beyer, Hugh, and Holtzblatt, Karen, "Apprenticing with the Customer: A Collaborative Approach to Requirements Definition," Communications of the ACM, May 1995. Beyer, Hugh, and Holtzblatt, Karen, Contextual Design : A Customer-Centered Approach to Systems Designs, 1997, Morgan Kaufman Publishers, ISBN: 1558604111 Holtzblatt, Karen, and Beyer, Hugh, "Making Customer-Centered Design Work for Teams," Communications of the ACM, October 1993. Holtzblatt, K., and Jones, S. "Contextual Inquiry: A Participatory Technique for System Design.'' in Schuler, D., and Namioka, A. (eds.) Participatory Design: Principles and Practice. Lawrence Earlbaum, Hillsdale, NJ. 1993: 180-193. Aproximación ContextualCopyright James Hom (1996). Traducido por Alejandro Floría (Enero 2000) alejandrofc00@hotmail.com Área de Ingeniería de Proyectos. Departamento de Ingeniería de Diseño y Fabricación. Centro Politécnico Superior | Universidad de Zaragoza. María de Luna, 3, 50.015, Zaragoza, España. Estudio

31

Estudio Etnográfico / Observación de Campo (Etnographic Study / Field Observation) ¿En qué consiste? La observación de los usuarios en su entorno habitual es, a menudo, la mejor forma de determinar sus requerimientos de usabilidad. Mientras que el test de usabilidad tradicional proporciona un entorno de laboratorio que facilita la captación y registro de datos, al mismo tiempo saca al usuario y al producto del contexto del lugar de trabajo. En ocasiones es preferible ver cómo se hacen las cosas en el mundo real. ¿Cómo lo llevo a cabo? Se comienza disponiendo la visita de campo con los usuarios. Hay que elegir una amplia variedad de usuarios para el producto, procedentes de diversos lugares de trabajo, industrias y contextos, con los que se podría establecer contacto a través de organizaciones de consumidores. Hay que utilizar el tiempo con inteligencia. Por lo general se dispondrán de unas pocas horas en el lugar en cuestión, por lo que se habrá de captar la mayor cantidad de información posible mientras se está allí, relegando cualquier tipo de análisis de la misma, con posterioridad, a nuestro lugar de trabajo. Una parte de la observación de campo consiste en indagar; esto es, entrevistar a los usuarios acerca de sus trabajos y la forma en que hacen uso del producto. La otra parte consiste en la observación propiamente dicha, la del modo en el que las personas harían uso del producto en el curso de un día de su vida cotidiana. Una manera de asegurar una captación de datos apropiada es la de identificar el mayor número de artefactos (artifacts) y "afloramientos" (outcroppings) posibles:

los artefactos son objetos físicos utilizados en un determinado lugar (cuadernos, formularios, informes, tablones,...)

con "afloramientos" se hace referencia a los rasgos físicos que caracterizan al

lugar en cuestión (el tamaño de los despachos, de las pizarras, lo que hay escrito en ellas, los uniformes de determinados miembros del personal).

Ambos términos provienen de la Antropología, en relación a la observación etnográfica, lo que viene a significar "observar a las personas". Así, las notas Post-It pueden entenderse tanto como artefactos como "afloramientos". La disposición de los despachos, la localización del personal (quién se sienta cerca del jefe, quién se sienta cerca del muelle de carga, etc) pueden resultar también de interés. Alguien de quien se solicite consejo o información no entrará dentro de ninguna de las dos categorías, pero puede ser caracterizado como parte de una relación. Cómo reunir artefactos y datos de los "afloramientos" Lo cierto es que suena cómo si se participara en una excavación arqueológica, pero realmente es bastante parecido. De la misma forma que un arqueólogo se fija en el cuenco de una civilización antigua para determinar aspectos acerca de su nutrición, es

32

posible encontrar objetos durante una observación de campo que indiquen el modo en el que los usuarios hacen uso del producto. Se trataría de seguir los siguientes pasos:

identificar los artefactos y "afloramientos" durante la entrevista u observación reunirlos y marcarlos en el propio lugar tomar fotos, guardar archivos en discos, solicitar planos o disposiciones de los

objetos es posible realizar una observación remota mediante la ubicación de una cámara

en el lugar en cuestión, discutiendo con posterioridad las imágenes por teléfono con los sujetos de interés del lugar

Cuando se utilizan estos datos para tomar decisiones o establecer una primeras opiniones acerca de las alternativas de diseño, son recomendables las siguientes representaciones:

Mostrar el artefacto en cuestión Mostrar una foto del artefacto o del "afloramiento" Mostrar un diagrama del artefacto o del "afloramiento" Mostrar un dibujo del objeto con sus parte etiquetadas Mostrar un dibujo del objeto antes y después del uso Mostrar variantes del artefacto o afloramiento

Las relaciones de grupo pueden ayudar a identificar el flujo de proceso y de información. Estas incluyen la organización, jerarquía, relaciones y vínculos formales e informales entre grupos, relaciones de carácter informativo,... Patrones de Comunicación Los patrones de comunicación muestran quién habla con quién y con qué frecuencia. Para productos asociados a una comunicación intensiva, como telefonía, correo electrónico o publicidad, esta información es vital. Indagación Cuando se pregunta cómo se hacen las cosas o cómo se supone que deben hacerse, conviene utilizar fórmulas como "¿funciona?", "¿lo hace alguien de forma diferente?", "¿por qué?". ¿Cuándo debería usar esta técnica? Esta técnica se utilizaría preferentemente en las etapas tempranas del proceso de desarrollo, cuando se necesita conocer más acerca de los aspectos que rodean el uso de un producto que de los aspectos del mismo susceptibles de ser medidos. En estas etapas, cuando tan apenas se tiene la idea de que se requiere un determinado producto para satisfacer una necesidad particular, las observaciones de campo ayudan a establecer los requerimientos del usuario así como otros elementos a incorporar en diseños preliminares. ¿Quién me puede decir más acerca de ella? Kane, Kate, "Anthropologists Go Native In The Corporate Village," October/November 1996, Fast Company magazine. Artículo sobre la búsqueda de trabajo de los etnógrafos en corporaciones.

33

Macht, Joshua, "The New Market Research," July 1998, Inc. magazine. Artículo sobre los estudios de campo con bajo componente tecnológico frente a los costosos "focus groups" para investigación de mercado y usuario. Tamakoshi, Laura, 1996, Field Methods, and Field Notes. Páginas Web en línea en http://www.truman.edu/academics/ss/faculty/tamakoshil/. Se describen los métodos de Tamakoshi empleados durante su investigación antropológica en Papua Nueva Guinea. Orientado hacia los antropólogos, pero de utilidad. Wixon, D. , and Ramey, Judith (Eds.), 1996, Field Methods Casebook for Software Design, John Wiley & Sons, Inc., New York, NY. ISBN: 0-471-14967-5 Un agradable vistazo a las técnicas etnográficas aplicadas en el diseño de software; de hecho, el único libro encontrado por el autor en este sentido. Similar al Wiklund book en el que se discuten las experiencias de quien ha practicado esta técnica. APROXIMACIÓN POR GRUPOS

Se ha escogido la denominación de aproximación por grupos porque, si bien los integrantes de los mismos han de ser usuarios representativos del producto sometido a estudio, y por tanto integrantes de un contexto, durante la sesión no se encuentran en dicho contexto, aunque van a ser sus experiencias e impresiones en el mismo, y sus propias relaciones personales, las que conducidas por un moderador de manera formal y estructurada van a proporcionar datos y generar ideas. El de los Grupos Orientados (Focus Groups) es probablemente uno de los métodos más conocidos y característicos, en los que la figura del moderador es fundamental y su proceder es determinante para el éxito de la sesión. La bibliografía es abundante y muy interesante. En los Grupos de Debate (Group Discussion / Future Workshops), sin embargo, el moderador ya no tiene la misión de estimular y guiar la discusión sino que conduce, establece y propone los temas a tratar en las sesiones. Los usuarios debaten ideas y opciones de diseño según tres etapas básicas: crítica a la situación presente, fantasía en la generación de ideas e implementación de las mismas. Es frecuente la combinación de estas sesiones con técnicas de generación de ideas tan conocidas como el Brainstorming y el Mental Imaging. Entrevistas y Grupos Orientados (Interviews and Focus Groups) ¿En qué consiste? Las entrevistas y los Grupos Orientados nos permiten preguntar a los usuarios acerca de sus experiencias y preferencias respecto de un producto. Ambos son eventos formales y estructurados en los que se interactúa directamente con los usuarios, a quienes se les solicita que expresen sus opiniones acerca del producto.

34

¿Cómo lo llevo a cabo? Se comienza formulando preguntas acerca del producto basadas en el tipo de información que se quiere conocer. Las fuentes mostradas al final de esta página proporcionan mayor información acerca del diseño de preguntas efectivas. Entonces, tan sólo hay que solicitar a los usuarios que respondan estas preguntas. En las entrevistas y los Grupos Orientados, de forma opuesta a las encuestas y los cuestionarios, uno ha de estar presente para interactuar y facilitar la discusón acerca de los aspectos que surjan de las preguntas realizadas. Cuando participan varios usuarios, tal y como sucede con los Grupos Orientados, la interaccón entre los mismos dará lugar a la consideracón de interesantes aspectos adicionales o identificará problemas comunes experimentados por muchas personas. ¿Cuándo debería usar esta técnica? Esta técnica puede ser utilizada en cualquier etapa del proceso de desarrollo, dependiendo de las preguntas que sean formuladas. A menudo, las entrevistas y los Grupos Orientados; son utilizados una vez que el producto ha sido lanzado con el objetivo de mejorar la satisfacción el cliente respecto del mismo. Será más frecuente, sin embargo, que estos métodos se pongan en práctica a etapas muy tempranas del desarrollo, cuando los requerimientos del productos no son firmes o no están completamente definidos. Es entonces cuando se utilizan los Grupos Orientados; para captar los requerimientos del usuario de forma previa al diseño inicial. ¿Quién me puede decir más acerca de ella? Greenbaum, Thomas L.,"Focus Groups: A Help or a Waste of Time?" de los página con los artículos de Tom en http://www.groupsplus.com/ . Hay muchos más. Greenbaum tiene también un par de articulos sobre los Grupos Orientados por vídeo: "Focus Group By Video - Next Trend Of The 90's" y "Is Your Moderator Ready for Videoconferencing?" en su sitio web. Greenbaum, Thomas L., The Handbook for Focus Group Research, 1997, Sage Pubns; ISBN: 0761912533 Nielsen, Jakob, "The Use and Misuse of Focus Groups" Templeton, Jane F., The Focus Group : A Strategic Guide to Organizing, Conducting and Analyzing the Focus Group Interview, 1994, Probus Pub Co; ISBN: 1557385300 Maya Design y W3Focus hacen Grupos Orientados on-line: FAQ Maya Design también lleva a cabo telephone focus groups (Grupos Orientados por vía telefónica) Silverman, George, "How to Get Beneath the Surface in Focus Groups" de los artículos de George en http://www.mnav.com/index.html.

35

Grupos de Debate (Group Discussion)

¿En qué consiste?

Los grupos de debate se basan en la idea de la discusión entre los implicados en el proceso de diseño (stakeholders) de nuevas ideas, opciones de diseño, costes y beneficios y otros aspectos relevantes al proceso de diseño. Tal situación facilitará el resumen y organización de las ideas e información manejada por cada individuo, estableciéndose la visión colectiva, mucho más amplia que la de las partes individuales. No hay que confundir, sin embargo, esta técnica con la de los Grupos Orientados (más basada en la idea estímulo-respuesta) dado que el moderador tiene, ahora, una función más de organizador que de entrevistador.

¿Cómo lo llevo a cabo?

Disposición de la sesión y reunión de participantes

Hay que empezar decidiendo los objetivos de la sesión y los participantes requeridos para la misma. Al contactar con los participantes, es preciso explicarles claramente los aspectos a considerar así como el formato de la reunión. Es preciso establecer un acuerdo acerca de las técnicas de registro o grabación a utilizar (audio, vídeo,...).

Conviene, además, desarrollar un horario de la sesión y conducir una prueba piloto para comprobar que tal horario es realista.

Conducir la sesión

Durante la sesión, el moderador deberá participar activamente fomentando la discusión (sugerirá normas para el debate, ayudará a los participantes en la formulación del problema, asegurará que todos los participantes tengan la oportunidad de contribuir y que la sesión no esté dominada por ninguna persona o grupo) y reunirá los resultados obtenidos al final de cada aspecto tratado. Es importante distinguir entre el consenso del grupo y la opinión de los diferentes participantes. Si se requiere información adicional de los componentes del grupo, se habrá de preparar un cuestionario apropiado para antes o después de la sesión.

¿Cuándo debería usar esta técnica?

En etapas tempranas, o incluso de prediseño, cuando se busca obtener opiniones de forma eficiente de un amplio número de personas.

¿Quién me puede decir más acerca de ella?

Proyecto RESPECT:http://www.ucc.ie/ucc/research/hfrg/projects/respect/urmethods/group.htm

Técnicas para Grupos de Debate: http://www.cet.sfsu.edu/collaboratory/colab.htm

36

Brainstorming

¿En qué consiste?

El brainstorm es probablemente la más conocida de las aproximaciones contextuales. Se basa en el establecimiento de un grupo multidisciplinar (la diversidad es fundamental) en la fase de generación de ideas del proceso de desarrollo. El brainstorm se utiliza para generar nuevas ideas, liberando la mente para aceptar cualquier idea que se proponga, permitiendo, así, la libertad para la creatividad. El resultado de una sesión será un conjunto de buenas ideas, y un sentimiento general de haber resuelto el problema y la combinación con otros métodos de grupo servirá para destacar los logros obtenidos en estas sesiones.

¿Cómo lo llevo a cabo?

Disposición de la sesión y reunión de participantes

Inicialmente hay que decidir los objetivos de la sesión así como los participantes requeridos para la misma. Al contactar con los participantes, se les habrá de explicar claramente los aspectos a considerar así como el formato de la reunión. Es preciso establecer un acuerdo acerca de las técnicas de registro o grabación a utilizar (audio, vídeo,...). Conviene plantear un horario de la sesión y conducir una prueba piloto para comprobar que tal horario es realista.

Conducir la sesión

Durante la sesión, el moderador deberá participar activamente fomentando la discusión (no permitiendo la crítica de ideas durante la sesión, fomentando la expresión de muchas ideas aceptando cualquier idea por irrelevante que parezca,...) y reunirá los resultados obtenidos al final de cada aspecto tratado. Será importante distinguir entre el consenso del grupo y la opinión de los diferentes participantes. Si se requiere, por otra parte información adicional de los componentes del grupo, se habrá de preparar un cuestionario apropiado para antes o después de la sesión.

¿Cuándo debería usar esta técnica?

En las etapas tempranas del proceso de desarrollo (incluso de prediseño), cuando se conoce poco acerca del diseño real y hay necesidad de nuevas ideas.

¿Quién me puede decir más acerca de ella?

Proyecto RESPECT: http://www.ucc.ie/ucc/research/hfrg/projects/respect/urmethods/brains.htm Brainstorming Techniques: http://www.kanten.com/RBWV/bstechs.html Braistorming Training http://www.brainstorming.co.uk/tutorials/tutorialcontents.html

37

APROXIMACIÓN INDIVIDUAL Aunque presentan diferentes estructuras y procedimientos, el factor común, y el más importante, es la formulación de preguntas efectivas. Las metodologías más habituales son: Las Encuestas (Surveys) son interactivas, pero ni poseen un carácter estructurado ni se establecen ni organizan formalmente. Por otra parte, en los Cuestionarios (Questionnaires), es característico el formato de lista de las preguntas, así como el requerimiento de un esfuerzo adicional por parte del usuario, quien contesta y envía de vuelta el cuestionario al evaluador. Hay algunos cuestionarios muy conocidos. En la Entrevistas (One-to-one Interviews) de forma similar a los Grupos Orientados, rige la filosofía estímulo-respuesta (Stimulus & Response). De hecho, es frecuente ver unidas a ambas técnicas en algunas recopilaciones de herramientas por este motivo. Aunque no se deja de proponer mecanismos para desarrollar preguntas efectivas y aplicar las técnicas de forma apropiada, las aplicaciones de estos métodos son frecuentemente alquiladas a profesionales expertos (Proffesional Trackers). Así se habla también de Entrevistas Expertas (Expert Interviews). Encuestas (Surveys) ¿En qué consiste? Las encuestas consisten en entrevistas con los usuarios en las que se formulan un conjunto de preguntas y se registran las respuestas. Las encuestas difieren de los cuestionarios en el carácter interactivo de las primeras, aunque no son estructuradas de la forma que los son las indagaciones en el contexto ni formalmente establecidas ni organizadas como lo pueden ser los Grupos Orientados. ¿Cómo lo llevo a cabo? Se comienza formulando preguntas acerca del producto basadas en el tipo de información que se quiere conocer. Las fuentes mostradas al final de esta página proporcionan mayor información acerca del diseño de preguntas efectivas. Entonces, tan sólo hay que solicitar a los usuarios que respondan estas preguntas. ¿Cuándo debería usar esta técnica? Esta técnica puede ser utilizada en cualquier etapa del proceso de desarrollo, dependiendo de las preguntas formuladas en la encuesta. A menudo, las encuestas son utilizadas una vez que el producto ha sido lanzado con el objetivo de mejorar la satisfacción el cliente respecto del mismo. Tales encuestas identifican a menudo determinadas cuestiones de usabilidad que deberían haber sido captadas con antelación antes de que el producto fuera lanzado al mercado. ¿Quién me puede decir más acerca de ella? Alreck, Pamela L., and Settle, Robert B., The Survey Research Handbook, 1994, Irwin Professional Publishing, Chicago, IL, ISBN: 0-256-10321-6 (ISBN is for cheaper paperbound 1995 version)

38

Salant, Priscilla, and Dillman, Don A., How to Conduct Your Own Survey, 1994, John Wiley & Sons, New York, NY, ISBN: 0471012734 Cuestionarios (Questionnaires) ¿En qué consiste? Los cuestionarios son listas escritas de preguntas que se distribuyen entre los usuarios. Los cuestionarios difieren de las encuestas en que se tratan de listas escritas y no de entrevistas como tales, de modo que requieren un esfuerzo adicional por parte de los usuarios, quienes habrán de rellenarlo y enviarlo de vuelta. ¿Cómo lo llevo a cabo? Se comienza formulando preguntas acerca del producto basadas en el tipo de información que se quiere conocer. Las fuentes mostradas al final de esta página proporcionan mayor información acerca del diseño de preguntas efectivas. ¿Cuándo debería usar esta técnica? Esta técnica puede ser utilizada en cualquier etapa del proceso de desarrollo, dependiendo de las preguntas formuladas en el cuestionario. A menudo, los cuestionarios son utilizados una vez que el producto ha sido lanzado con el objetivo de mejorar la satisfacción el cliente respecto del mismo. Tales cuestionarios identifican a menudo determinados aspectos de usabilidad que deberían haber sido captados con antelación antes de que el producto fuera lanzado al mercado. ¿Quién me puede decir más acerca de ella? Foddy, William, Constructing Questions for Interviews and Questionnaires: Theory and Practice in Social Research, Cambridge Univ Pr (Pap Txt); ISBN: 0521467330. Lessler, Judith L., Questionnaire Design in the Cognitive Research Laboratory, ISBN 0840604122. Oppenheim, A. N., Questionnaire Design, Interviewing and Attitude Measurement, 1992,

inter Pub Ltd; ISBN: 1855670445 P PARTICIPACIÓN REMOTA En muchas ocasiones nos encontraremos con que el objetivo de un experimento remoto es evaluar o testear un producto, o al menos así lo manifestará la bibliografía, pero la distancia no debe suponer un obstáculo, por otra parte, a una primera fase de investigación e indagación contextual. Hay dos fuentes básicas de referencia: • "Remote Usability Evaluation at a Glance " • "The User-Reported Critical Incident Method at a Glance"

39

El Cuestionario o Encuesta Remota es la versión a distancia de las aproximaciones individuales, con la misma dificultad que presenta la formulación de preguntas efectivas pero con la ventaja que puede suponer el retorno de la información a través de la red. También se habla de sistemas automatizados de captación y reunión de datos. Las técnicas más habituales son las Sesiones Guiadas (Journaled Sessions) y las Fotografías de Pantalla (Screen Snapshots) y, por lo general, están destinadas a la evaluación o test de software. En ambos casos se proporciona un prototipo del producto a testear y un mecanismo para el registro de datos. Un posible punto de partida en el proceso de diseño es una nueva evaluación o test de una versión previa del producto objetivo. El paso del tiempo trae, a menudo, y especialmente en lo que se refiere a productos con un importante componente tecnológico, nuevas consideraciones y perspectivas que aportan nuevos datos e impresiones. El Registro por parte del Usuario (Self-reporting Logs) es una variante en lápiz y papel de los procedimientos automatizados descubiertos con anterioridad que. Lógicamente, requerirá un mayor esfuerzo por parte del usuario (otra posibilidad en este sentido es el Método del Diario). En la misma línea, se tienen las Sesiones de Registro del Uso Real (Logging Actual Use Sessions), una variante de las anteriores, más propia de la bibliografía del software, automatizada, que conserva la posibilidad de realización remota pero se plantea como interesante como trabajo de campo. El Informe por el Usuario de Incidencias Críticas (User-Reported Critical Incident Report) es propio de la bibliografía de la evaluación remota. Los usuarios son entrenados para identificar incidencias críticas e informar de manera específica mientras realizan las tareas habituales en su contexto de trabajo. Los procedimientos mediante servicios comerciales de usabilidad (Third-Party) agrupan los casos de la evaluación en laboratorio (Laboratory Evaluation) o inspección de usabilidad (Usability Inspection). Posteriormente se recibe un informe del laboratorio o consultora que llevó a cabo la investigación. También se plantea dentro de esta posibilidad la Evaluación basada en Videoconferencia (Video-Conferencing supported Evaluation). Evaluación Remota (Remote Evaluation)

Servicios comerciales de usabilidad

Los desarrolladores pueden utilizar la red para gestionar documentación y material de diseño, pero no se va a utilizar para la conexión con el participante remoto. Esto es, la evaluación es local respecto de los evaluadores y remota respecto de los miembros del equipo de desarrollo.

Evaluación en laboratorio por terceros

Se trata simplemente de una evaluación de usabilidad formal que pone en la práctica un laboratorio con usuarios y tareas representativas. Los resultados suelen proporcionar

40

medidas cuantitativas, opiniones de los usuarios, sugerencias e incluso un registro de la sesión en el formato en que se establezca.

Inspección de usabilidad por terceros

La inspección de usabilidad va a depender en buena parte de las habilidades y los conocimientos de los evaluadores. Ya se señaló en la traducción del material de James Hom que era preciso un conocimiento suficiente del sistema y sus características (¿podría encontrar a un experto en HCI que domine la contabilidad?).

Encuesta o Cuestionario Remoto

El Cuestionario o Encuesta Remota es la versión a distancia de las aproximaciones individuales, con la misma dificultad que presenta la formulación de preguntas efectivas pero con la ventaja que puede suponer el retorno de la información a través de la red. Lo habitual es que la aplicación de software a evaluar contenga un cuestionario de usuario para reunir datos preferenciales del participante sobre la aplicación y su interfaz. Este cuestionario suele aparecer en respuesta a un evento (la finalización de la tarea)y cuenta con la ventaja de que las reacciones del usuario son recientes, aunque su expresión queda limitado al formato de las preguntas.

Evaluación basada en Videoconferencia

La Evaluación basada en Videoconferencia no es más que una extensión de la forma de comunicación que en ocasiones se mantiene en evaluaciones locales entre habitaciones adyacentes. Se trata de un mecanismo de transporte de datos (audio y vídeo) en tiempo real, lo que puede crear un ambiente similar a la evaluación local. El mayor problema que presenta este método es, como no, los retrasos en la red.

Captación de datos instrumentada o automatizada

Se trata de una versión automatizada de los Registros por el Usuario, una idea similar a las Sesiones Guiadas. Así se van a registrar de forma automática una serie de aspectos caracterísiticos del trabajo del usuario: tasa de uso de las aplicaciones, tasa de uso de la red, otros datos como secuencias sobre teclado y movimientos de puntero,... Como supondrá el lector, el análisis de los datos registrados se efectuará posteriormente, quizás mediante patrones de reconocimiento, también automatizados, que revelarán los problemas de usabilidad.

Método de Información de Incidencias Críticas

El método de información por el usuario de incidencias críticas se basa en el registro por el participante de una determinada cuestión o aspectos problemáticos que surgen en el desarrollo de sus tareas en el contexto normal de trabajo. Resulta un método efectivo, de fácil implementación, puesto que el usuario reúne datos en el propio contexto y los evaluadores los revisan.

41

Evaluación Remota Colaborativa

Se va a utilizar, de nuevo, la red y se van a hacer uso de una serie de herramientas que van a facilitar la colaboración síncrona o asíncrona, como, por ejemplo, aplicaciones compartidas en tiempo real, soporte de audio para conferencia, aplicaciones de dibujo compartidas (muy útiles, para compartir datos gráficos y fotos de pantalla) y de transferencia de ficheros. También se han llegado a crear espacios virtuales compartidos, llevando las ideas de localidad y sincronismo a su máxima expresión. Sin embargo, una colaboración asíncrona siempre resultará más flexible al evaluador que procederá a su propio ritmo.

Sesiones Guiadas (Journaled Sessions)

¿En qué consiste?

Este método constituye un puente uniendo los métodos de indagación, cuando se pregunta a las personas acerca de sus experiencias con el producto, y el test de usabilidad, cuando se observa a las personas experimentando con la interfaz de usuario del producto.

Se trata de un método de investigación remota para la evaluación de la interfaz de usuario de software. Se distribuye entre los sujetos del test un disco conteniendo un prototipo del producto, así como código adicional para capturar y registrar sus acciones cuando hacen uso del mismo. Los usuarios llevan a cabo varias tareas, más de las que se realiza en un test de usabilidad formal, y sus acciones son registradas por el software adicional proporcionado. Una vez completada una serie de tareas, los usuarios devuelven los discos para su evaluación.

Debido al alto nivel de automatización, esta aproximación a la investigación remota resulta ciertamente mucho más útil que el procedimiento del Registro por el Usuario, en los que se solicita a los usuarios que anoten sus observaciones y comentarios y los envíen de vuelta al evaluador.

¿Cómo lo llevo a cabo?

Ahora va a ser posible llevar a cabo una evaluación de usabilidad a distancia sin muchas complicaciones. Una vez dispuesto y situado el software de seguimiento de las acciones del usuario en el lugar del experimento, la distribución del software a evaluar entre un gran número de participantes resulta relativamente barata.

También hay que indicar a los usuarios qué tareas deben realizar, lo que puede presentarse como parte del software de seguimiento, en busca de una mayor interactividad por parte del usuario.

De modo adicional, y para no limitarnos a un mero registro de los movimientos de cursor, "clicks" del ratón y otras interacciones con la interfaz, también se pueden proporcionar cajas de diálogo en las que el usuario introduzca sus comentarios u observaciones en determinados puntos de ejecución de la tarea. Véase que, hasta cierto punto, este

42

método se aproxima al tipo de indagación interactiva que promueve el método de indagación en el contexto.

La principal desventaja que presenta esta técnica es la ausencia de un observador que capte lo que el usuario está haciendo: la expresión de su rostro, comentarios expresados inconscientemente en los momentos más complicados de la sesión,...

Por supuesto, se ha de proporcionar un sobre pre-pagado para la devolución del registro realizado por los evaluadores.

¿Cuándo debería usar esta técnica?

Esta técnica se utiliza con preferencia en las etapas tempranas del desarrollo, e incluso en un pre-desarrollo, cuando la información que se pretende obtener es más preferencial que empírica.

¿Quién me puede decir más acerca de ella?

Castillo, José, Remote Usability Evaluation Home Page, 1998. Nielsen, Jakob, Usability Engineering, 1993, Academic Press/AP Professional, Cambridge, MA ISBN 0-12-518406-9 (papel) Clickometer es un contador shareware de "clicks" . Invisible Key Logger cuenta las pulsaciones sobre cada tecla. Otros productos de software que cuentan "clicks": RSI prevention software, Mercury Interactive, Segue, Rational, etc.

Registro por el Usuario (Self-reporting Logs)

¿En qué consiste?

Los Registros por el Usuario consisten en sesiones de lápiz y papel en las que se solicita de los usuarios que registren sus acciones y observaciones mientras están interactuando con un determinado producto. Al igual que en las Sesiones Guiadas, se podrá llevar a cabo una evaluación de usuario a distancia. Sin embargo, esta técnica requiere mucho más trabajo por parte de los sujetos participantes.

Se utilizarían Sesiones Guiadas cuando se requiriera información detallada de las evaluaciones remotas; por ejemplo, los movimientos reales del ratón o la secuencia de cajas de diálogo y de menús a los que accede el usuario. Evidentemente, solicitar del usuario un registro de cada acción, después de cada "click", queda fuera de lugar (En caso de hacerlo y conseguirlo, ¿creen que ese sujeto sería representativo de la población de usuarios?...)

Así pues, los Registros por el Usuario se utilizan con preferencia cuando no hay tiempo o recursos para proporcionar el paquete interactivo requerido para las Sesiones Guiadas, o

43

cuando no se requiere el nivel de detalle asociado a estas. Podría buscarse, simplemente, impresiones generales y observaciones de un conjunto amplio de usuarios.

La principal desventaja que presenta esta técnica es la ausencia de un observador que capte lo que el usuario está haciendo: la expresión de su rostro, comentarios expresados inconscientemente en los momentos más complicados de la sesión,...

¿Cómo lo llevo a cabo?

Hay que proporcionar a los usuarios un prototipo del producto, un guión de las tareas a realizar con el mismo y un diario para el registro de sus observaciones y tareas. Resultará de ayuda proporcionar al usuario puntos de parada durante su ejecución de las tareas de test, durante los que puedan tomar las notas correspondientes.

¿Cuándo debería usar esta técnica?

Esta técnica se utiliza con preferencia en las etapas tempranas del desarrollo, e incluso en un predesarrollo, cuando la información que se pretende obtener es más preferencial que empírica.

Por supuesto, se ha de proporcionar un sobre pre-pagado para la devolución del registro realizado por los evaluadores.

¿Quién me puede decir más acerca de ella?

Castillo, José, Remote Usability Evaluation Home Page, 1998. Nielsen, Jakob, Usability Engineering, 1993, Academic Press/AP Professional, Cambridge, MA ISBN 0-12-518406-9 (papel)

Método del Diario (Diary Keeping)

¿En qué consiste?

Los métodos de diario requieren del usuario participante el registro de las actividades de interés a lo largo de un día normal. Los diarios pueden ser abiertos, expresándose el usuario con sus propias palabras, o, también, altamente estructurados, disponiendo este de respuestas con elección múltiple o, simplemente, del tipo sí/no.

Los materiales requeridos van desde el papel y el lápiz, hasta el registro por vídeo y formularios en línea gestionados por una aplicación informática. Por otra parte, no se debe confundir este método con el de las Sesiones Guiadas, como veremos seguidamente en una breve revisión de su procedimiento

¿Cómo lo llevo a cabo?

Hay que decidir si los diarios permitirán la expresión libre del participante o si se establecerán de forma estructurada, con formatos de respuesta fijos, cuyo análisis resulta

44

más sencillo (aunque, quizás, no tan enriquecedor). Para esta opción, se habrá de desarrollar una cuidadosa selección de preguntas (como siempre, una de las cuestiones claves) y categorías para las respuestas.

Otra cuestión a establecer es la frecuencia con la que los usuarios habrán de completar el diario (cada hora, diariamente, semanalmente,...), lo que vendrá determinado por la naturaleza de los datos que se pretendan obtener y las tareas que hayan de llevarse a cabo. En cualquier caso, las instrucciones para completarlo habrán de ser muy claras (un desarrollo inapropiado sería desastroso), siendo recomendable proporcionar algún medio (como un número de teléfono) para que el participante pueda comprobar el procedimiento a seguir.

¿Cuándo debería usar esta técnica?

Es útil en etapas tempranas, incluso de prediseño, para conocer el comportamiento del usuario durante un determinado período de tiempo, evitando, además, la intrusión del investigador en el ámbito de trabajo.

¿Quién me puede decir más acerca de ella?

Proyecto RESPECT

GENERACIÓN DE IDEAS La generación de ideas es también una forma de descubrir, aprender y refinar determinados conceptos de diseño. La participación de los usuarios en estos procedimientos contribuye a ampliar perspectivas y a profundizar en una variedad de consideraciones que, en ocasiones, pasan inadvertidas para el diseñador. Ya se ha mencionado la combinación del Brainstorming y el Mental Imaging con los Grupos Orientados. Se presentan varias posibilidades: Generación de estímulos e impresiones mediante escenarios • Secuencias de Escenarios (Storyboarding/Presentation Scenarios) • Creación de Escenarios (Scenario Building) Distintas formas de análisis cognitivos • Cuadros de Organización de Tareas (Task Allocation Charts) • Análisis de Tareas (Task Analysis) • Matriz de Funcionalidad (Functionality Matrix) Perspectivas de carácter etnográfico • Análisis de Usabilidad del Contexto (Usability Context Analysis) • Test No Directivo: test de diferentes prototipos por diferentes grupos de usuarios con el objetivo de obtener fuentes no influenciadas. • Test de Preferencias: sobre una variedad de prototipos del mismo producto, el usuario muestra sus preferencias, bien sobre algún partes de los mismos

45

Secuencia de Escenarios (Storyboarding)

¿En qué consiste?

Este método se basa en la presentación de secuencias de imágenes que demuestran la relación entre eventos individuales (salidas por pantalla, p.e.) y acciones dentro de un sistema. La constitución de estas representaciones en una secuencia proporciona mucha información, mostrando las posibles estructuras, funcionalidad y opciones en un sistema.

Se requieren pocos recursos técnicos. Es suficiente con herramientas de dibujo, ya estén basadas en ordenador o no. La presentación de escenarios constituye un mecanismo para la exploración de las opciones para los requerimientos de usuario mediante una representación estática que puede ser mostrada a usuarios potenciales o miembros del equipo de diseño. Esto puede resultar en una selección y refinamiento de los requerimientos.

¿Cómo lo llevo a cabo?

Hay que considerar los escenarios de uso que reflejarán la presentación. Una presentación de escenarios puede representar diversas actividades, como la introducción, copia o impresión de una información (no nos limitemos al mundo del software: pensemos en el proceso de activación manual de un sistema de alarmas o en la programación de la lavadora). De forma alternativa, se puede representar cada tema distinto en una presentación.

Hay que construir el escenario como una secuencia de representaciones en pantalla, utilizando imágenes separadas para representar los cambios en la apariencia del sistema. Así, la presentación de escenarios indicará la disponibilidad y el propósito de las ventanas de diálogo, los items del menú, las barras de herramientas, los iconos,...

Los elementos de la presentación (puede tratarse de una hábil secuencia de folios)pueden ser complementados con notas explicativas para facilitar la comprensión de la audiencia y la correspondiente evaluación.

Se puede mostrar la presentación al equipo de diseño así como a los usuarios implicados para obtener información para la evaluación y explorar las opciones de los requerimientos.

¿Cuándo debería usar esta técnica?

Se pueden obtener respuestas sobre la funcionalidad del sistema, así como sobre el estilo y modos de funcionamiento, en etapas tempranas del proceso de desarrollo, cuando los cambios pueden ser más fácilmente implementados. La situación es muy similar a la del prototipado, representándose, además, la gestión y resultados de las funcionalidades del mismo

46

¿Quién me puede decir más acerca de ella?

http://www.ucc.ie/ucc/research/hfrg/projects/respect/urmethods/storyb.htm

Construcción de Escenarios (Scenario Building)

¿En qué consiste?

Los escenarios son caracterizaciones de los usuarios y sus tareas en un contexto específico y ofrecen representaciones concretas de un usuario trabajando con un sistema para conseguir un objetivo específico. El propósito de la construcción de un escenario es generar los requerimientos del usuario final y las metas de usabilidad en las etapas tempranas del ciclo de desarrollo.

¿Cómo lo llevo a cabo?

Disposición de la sesión y reunión de participantes

Para empezar, hay que reunir al equipo de desarrollo con otros individuos de relevancia implicados (stakeholders) bajo la dirección de un experto. Hay que identificar, por otra parte, a los usuarios objetivo, sus tareas y el contexto general (trabajo previo mediante técnicas de indagación). Esta información proporcionará la base para la creación de escenarios por el equipo de desarrollo.

Conducir la sesión

Corresponderá, entonces, descomponer funcionalmente los objetivos de usuario en las operaciones precisas para conseguirlo. Se plantearán como objetivos de usabilidad, en general, los tiempos de tarea y los criterios de finalización de las mismas. En cuanto al registro, la sesión puede ser grabada en vídeo para posterior revisión o transcrita para ampliar su difusión entre los miembros del equipo de diseño. Los resultados podrán ser utilizados para planificar evaluaciones basadas en usuario. En términos de salidas (outputs), el método va a fomentar un entendimiento más profundo de los requerimientos de usuario, pudiendo ser específicamente utilizado para planificar posteriores sesiones de participación.

¿Cuándo debería usar esta técnica?

Las cuestiones de usabilidad podrán ser exploradas en etapas muy tempranas del proceso de diseño, antes de que haya algo decisión fija. Igualmente, los escenarios pueden servir para generar contextos para estudios de evaluación en etapas tempranas-medias, por lo que el potencial de aplicación es amplio.

¿Quién me puede decir más acerca de ella?

http://www.ucc.ie/ucc/research/hfrg/projects/respect/urmethods/scenario.htm

47

Asignación de Tareas (Task Allocation)

¿En qué consiste?

El éxito de un sistema va a depender de una reparto efectivo de tareas entre dicho sistema y los usuarios del mismo. Se necesitará, pues, considerar diferentes opciones en la asignación de tareas antes de especificar una frontera bien definida del sistema. Se han de establecer, además, una variedad de opciones para identificar una división óptima de la labor a realizar, para asegurar la satisfacción en el trabajo, así como una operatividad eficiente en el proceso de trabajo. Esta aproximación va a ser más útil para sistemas que afectan a procesos de trabajo completo y no sólo a productos individuales o productos monotarea.

¿Cómo lo llevo a cabo?

Hay que identificar cada tarea o proceso de trabajo y, en particular, aquellos para los que sería posible plantear una asignación de tareas distinta. Se dibuja, entonces, un diagrama de flujo para cada tarea para mostrar la disgregación de la misma entre usuarios y sistemas y subsistemas, así como las interacciones entre los mismos.

Resulta recomendable generar al menos dos opciones para el reparto y comentar las implicaciones de la satisfacción en el trabajo y la eficiencia en el mismo para cada una de las opciones. Así también se estimulará la discusión entre el equipo de diseño y los usuarios. A partir de ahí se seleccionará la alternativa que resulte más aceptable para el usuario cliente o se procederá a generar nuevas opciones si es preciso.

No conviene emplear demasiado tiempo generando diagramas de flujo. Simples esquemas sobre las posibles asignaciones va a ser más que suficiente.

¿Cuándo debería usar esta técnica?

Será preciso un buen entendimiento de las papeles desempeñados en los distintos puestos de trabajo antes de proceder, así que una participación en alguna técnica contextual (etapas tempranas y de prediseño) podría resultar de utilidad para progresar después más rápidamente.

¿Quién me puede decir más acerca de ella?

http://www.ucc.ie/ucc/research/hfrg/projects/respect/urmethods/taskalloc.htm

Análisis de Tareas (Task Analysis)

¿En qué consiste?

Este método puede ser definido como el estudio de lo que se requiere del usuario en términos de acciones y/o procesos cognitivos para completar una tarea. Así, corresponde

48

un análisis detallado de tareas (sobre un mapa de usuarios relevantes) para entender el sistema actual y los flujos de información en el mismo.

Estos flujos de información son importantes para el mantenimiento de un sistema existente (aquí se manifestará de nuevo la conveniencia de equipos multidisciplinares, en particular por la presencia de técnicos) y deben ser incorporados o substituidos en cualquier nuevo sistema. Fracasar en el reparto de recursos suficientes para esta actividad incrementa la potencial aparición de problemas costosos en las últimas fases del proceso de desarrollo.

Los análisis de tareas hacen posible diseñar y organizar las tareas apropiadamente dentro del nuevo sistema. Las funciones a incluir dentro del sistema y de la interfaz de usuario pueden ser entonces especificadas con precisión.

Si es preciso, se establecen sesiones de observación para disponer de una perspectiva apropiada y se acude a los usuarios cuantas veces sea preciso para aclarar todas las cuestiones que sean precisas.

¿Cómo lo llevo a cabo?

El proceso se divide aquí en dos partes:

• Descomposición de tareas a alto nivel, donde las tareas mayores se dividen en subtareas. Este paso proporciona una buena perspectiva de las tareas que están siendo analizadas. • Diagrama del flujo de tareas, donde las tareas específicas se dividen en pasos básicos de tarea. No hay que descuidar la utilidad de una descripción textual de los diagramas.

Descomposición de tareas

El objetivo aquí es dividir las tareas de alto nivel en sus subtareas y operaciones constitutivas. Esto mostrará una estructura global de las principales tareas de usuario. A un nivel inferior, será deseable mostrar los flujos de tareas, procesos de decisión, e incluso las disposiciones en pantalla o cuadros de control.

El proceso de descomposición de tareas se representa como un cuadro estructurado (similar al utilizado en un análisis jerárquico de tareas). Esto mostrará la secuencia de actividades mediante su ordenación de izquierda a derecha. Para dividir la tarea, se formulará la pregunta "cómo se realiza esta tarea". Si se identifica una tarea a un nivel inferior, será posible construir la estructura preguntando "porqué se hace esto".

La descomposición de tareas se puede llevar a cabo mediante las siguientes etapas:

• Se identifica la tarea a analizar a partir de la lista de tareas. • Se descompone entre 4 y 8 subtareas. Estas subtareas deberían estar especificadas en términos de objetivos y, entre ellas, deberían cubrir el área de interés. • Se dibujan las subtareas como un diagrama asegurando que está completo. • Hay que decidir sobre el nivel de detalle de la descomposición, lo que asegurará un tratamiento consistente de la situación (será de gran ayuda un registro escrito). Podría

49

decidirse que la descomposición de tareas continuara hasta que los flujos fueran representados con mayor facilidad en un diagrama de flujo de tareas.

Como se señaló previamente, es importante que el proceso de definición de requerimientos no se base en el simple registro de las operaciones existentes, sino que también aporte probables mejoras que resulten de la introducción de nuevos sistemas y facilidades. Las implicaciones de los cambios potenciales deberán ser registrados en los propios diagramas de descomposición de tareas.

Diagramas de flujo de tareas

El análisis del flujo de tareas documentará los detalles de las tareas específicas, como los detalles de interacciones entre el usuario y el sistema actual así como cualquier problema relacionado con los mismos. También destacarán las áreas donde los procesos de tareas no están bien entendidos, son llevados a cabo de formas diferentes por distintos individuos o son inconsistentes con el nivel más alto de la estructura de tareas.

¿Cuándo debería usar esta técnica?

Es importante conseguir acceso a los usuarios reales para discutir las tareas presentes o futuras, así como a usuarios representativos. Por lo tanto el procedimiento se puede extender en una etapa temprana.

¿Quién me puede decir más acerca de ella?

http://www.ucc.ie/ucc/research/hfrg/projects/respect/urmethods/taskanalysis.htm

Matriz de Funcionalidad (Functionality Matrix)

¿En qué consiste?

Mediante este procedimiento se van a especificar las funciones del sistema que cada usuario requerirá para las diferentes tareas que habrá de realizar. Se tratará, además, de identificar las funciones más críticas de las tareas para poder dedicarles mayor atención durante el test de usabilidad en el proceso de diseño.

¿Cómo lo llevo a cabo?

Primero se identificarán los grupos de usuarios, así como las tareas por grupos de usuarios, datos que se situarán ordenados por filas en una matriz. Según las columnas en la matriz, después, se desarrollará una lista de funciones y características potenciales. En esta situación se identificarán las funciones que son críticas para la tarea así como las que se utilizan de forma ocasional.

En sucesivas revisiones, se añadirán nuevas funciones y características allá donde se detecten carencias en las tareas y se eliminarán las funciones innecesarias. Puede resultar conveniente el desarrollo de prototipos para ayudar a crear una especificación de

50

los requerimientos de usuario más detallada, lo que puede alargar el procedimiento si el producto de interés es hardware.

¿Cuándo debería usar esta técnica?

Esta técnica se utilizará en etapas tempranas, cuando se trata de especificar los requerimientos de usuario (la matriz podría empezar a elaborarse durante la aplicación de una técnica contextual) y resultará útil para sistemas donde el número de posibles funciones es elevado (por ejemplo un paquete genérico de software), y donde el número de tareas que el usuario podrá realizar está bien especificado.

¿Quién me puede decir más acerca de ella?

http://www.ucc.ie/ucc/research/hfrg/projects/respect/urmethods/functional.htm

Métodos de Observación Experta Ya se han hecho referencia a ellos en la medida en que hace referencia a la contratación de los servicios de consultoras o laboratorios especializados. Además de los habituales servicios de los laboratorios de usabilidad aparecen técnicas más novedosas. Igualmente, también se ha de mencionar a los expertos en captación de datos. Aunque puede entenderse como un enfoque demasiado comercial (son recursos propios del Marketing) conviene no olvidar que la información acerca del consumidor actual del producto sometido a estudio puede constituir una valiosísima fuente de datos que puede plantear objetivos de test.

Algunas técnicas novedosas

• Análisis longitudinal: se basa en el hecho de que sucesivas evaluaciones sobre la misma persona pueden permitir la descripción del desarrollo físico y mental en la infancia, adolescencia y madurez. La planificación del estudio y el análisis de los datos requieren, lógicamente, soporte estadístico. • Análisis de tareas / estudio de tiempos y movimiento: los datos a proporcionar van a ser eminentemente cuantitativos: cuanto cuestan tantas tareas realizadas en un orden específico por un individuo en particular. El objetivo es detectar problemas y cuellos de botella. • Restos físicos: increíble, pero cierto; se trata de una revisión exhaustiva del entorno en el que ha tenido lugar un proceso de trabajo en busca de pistas que desvelen qué ha tenido lugar y qué consecuencias ha tenido. • Seguimientos: ¿quién no ha oído la expresión "convertirse en la sombra de alguien"?; de eso se trata, se abandona el carácter pasivo del observador para pasar a involucrarse en todas las actividades en las que toma parte el participante. Hay que evitar la formulación de cualquier tipo de pregunta estructurada y lo recomendable puede ser emplear días, y no unas pocas horas, en el seguimiento a realizar. • Tests fisiológicos: habitual en ergonomía, los parámetros a contemplar son antropométricos y lo que importa es el modo en el que el producto se adapta al usuario en los usos estático y dinámico (repetitivo).

51

Expertos en captación de datos

Denominados en la literatura anglosajona como Professional Trackers algunas de las técnicas más características:

• Profesionales del Futuro: se basa en un análisis de tendencias combinado con técnicas de generación de ideas sobre toda la información disponible, siendo esta de cualquier tipo posible. • Estudios de los Estilos de Vida: recopilación e investigación de una variedad de estilos de vida y comportamiento, muy orientado hacia la juventud. • Encuestas de Opinión: se trata de las encuestas a las que ya nos hemos referido en las aproximaciones individuales de los métodos de indagación. A tener en cuenta pues la correcta elaboración del cuestionario y la selección de una muestra significativa de la población objetivo.

Información del Consumidor Actual

La información acerca del consumidor actual del producto sometido a estudio puede constituir una valiosísima fuente de datos que puede plantear objetivos de test durante el proceso de desarrollo. Los mecanismos para su obtención han correspondido habitualmente a los Departamentos de Marketing, que pueden proporcionar "feedback" a los equipos de desarrollo. Son por todos conocidas las siguientes técnicas:

• Información en línea y cifras de ventas • Fuentes de Información Pública • Información en Tiempo Real • Tests de Mercado, Ensayos, Estudios Piloto • Visitas a Clientes, fiestas y eventos promocionales

Sesiones Guiadas (Journaled Sessions) ¿En qué consiste? Este método constituye un puente uniendo los métodos de indagación, cuando se pregunta a las personas acerca de sus experiencias con el producto, y el test de usabilidad, cuando se observa a las personas experimentando con la interfaz de usuario del producto. Se trata de un método de investigación remota para la evaluación de la interfaz de usuario de software. Se distribuye entre los sujetos del test un disco conteniendo un prototipo del producto, así como código adicional para capturar y registrar sus acciones cuando hacen uso del mismo. Los usuarios llevan a cabo varias tareas, más de las que se realiza en un test de usabilidad formal, y sus acciones son registradas por el software adicional proporcionado. Una vez completada una serie de tareas, los usuarios devuelven los discos para su evaluación. Debido al alto nivel de automatización, esta aproximación a la investigación remota resulta ciertamente mucho más útil que el procedimiento del Registro por el Usuario, en los que se solicita a los usuarios que anoten sus observaciones y comentarios y los envíen de vuelta al evaluador.

52

¿Cómo lo llevo a cabo? Ahora va a ser posible llevar a cabo una evaluación de usabilidad a distancia sin muchas complicaciones. Una vez dispuesto y situado el software de seguimiento de las acciones del usuario en el lugar del experimento, la distribución del software a evaluar entre un gran número de participantes resulta relativamente barata. También hay que indicar a los usuarios qué tareas deben realizar, lo que puede presentarse como parte del software de seguimiento, en busca de una mayor interactividad por parte del usuario. De modo adicional, y para no limitarnos a un mero registro de los movimientos de cursor, "clicks" del ratón y otras interacciones con la interfaz, también se pueden proporcionar cajas de diálogo en las que el usuario introduzca sus comentarios u observaciones en determinados puntos de ejecución de la tarea. Véase que, hasta cierto punto, este método se aproxima al tipo de indagación interactiva que promueve el método de indagación en el contexto. La principal desventaja que presenta esta técnica es la ausencia de un observador que capte lo que el usuario está haciendo: la expresión de su rostro, comentarios expresados inconscientemente en los momentos más complicados de la sesión,... Por supuesto, se ha de proporcionar un sobre pre-pagado para la devolución del registro realizado por los evaluadores. ¿Cuándo debería usar esta técnica? Esta técnica se utiliza con preferencia en las etapas tempranas del desarrollo, e incluso en un pre-desarrollo, cuando la información que se pretende obtener es más preferencial que empírica. ¿Quién me puede decir más acerca de ella? Castillo, José, Remote Usability Evaluation Home Page, 1998. Nielsen, Jakob, Usability Engineering, 1993, Academic Press/AP Professional, Cambridge, MA ISBN 0-12-518406-9 (papel) Clickometer es un contador shareware de "clicks" . Invisible Key Logger cuenta las pulsaciones sobre cada tecla. Otros productos de software que cuentan "clicks": RSI prevention software, Mercury Interactive, Segue, Rational, etc. Registro por el Usuario (Self-reporting Logs) ¿En qué consiste? Los Registros por el Usuario consisten en sesiones de lápiz y papel en las que se solicita de los usuarios que registren sus acciones y observaciones mientras están interactuando con un determinado producto. Al igual que en las Sesiones Guiadas, se podrá llevar a

53

cabo una evaluación de usuario a distancia. Sin embargo, esta técnica requiere mucho más trabajo por parte de los sujetos participantes. Se utilizarían Sesiones Guiadas cuando se requiriera información detallada de las evaluaciones remotas; por ejemplo, los movimientos reales del ratón o la secuencia de cajas de diálogo y de menús a los que accede el usuario. Evidentemente, solicitar del usuario un registro de cada acción, después de cada "click", queda fuera de lugar (En caso de hacerlo y conseguirlo, ¿creen que ese sujeto sería representativo de la población de usuarios?...) Así pues, los Registros por el Usuario se utilizan con preferencia cuando no hay tiempo o recursos para proporcionar el paquete interactivo requerido para las Sesiones Guiadas, o cuando no se requiere el nivel de detalle asociado a estas. Podría buscarse, simplemente, impresiones generales y observaciones de un conjunto amplio de usuarios. La principal desventaja que presenta esta técnica es la ausencia de un observador que capte lo que el usuario está haciendo: la expresión de su rostro, comentarios expresados inconscientemente en los momentos más complicados de la sesión,... ¿Cómo lo llevo a cabo? Hay que proporcionar a los usuarios un prototipo del producto, un guión de las tareas a realizar con el mismo y un diario para el registro de sus observaciones y tareas. Resultará de ayuda proporcionar al usuario puntos de parada durante su ejecución de las tareas de test, durante los que puedan tomar las notas correspondientes. ¿Cuándo debería usar esta técnica? Esta técnica se utiliza con preferencia en las etapas tempranas del desarrollo, e incluso en un predesarrollo, cuando la información que se pretende obtener es más preferencial que empírica. Por supuesto, se ha de proporcionar un sobre pre-pagado para la devolución del registro realizado por los evaluadores. ¿Quién me puede decir más acerca de ella? Castillo, José, Remote Usability Evaluation Home Page, 1998. Nielsen, Jakob, Usability Engineering, 1993, Academic Press/AP Professional, Cambridge, MA ISBN 0-12-518406-9 (papel) Inspección (Inspection) El proceso de diseño tiene, necesariamente, carácter iterativo y su planificación ha de contemplar tal circunstancia. A pesar de que los métodos que se están mostrando son específicamente recomendados para una etapa concreta de dicho proceso se puede comprobar que su flexibilidad admite su utilización en prácticamente cualquier momento. Así, los métodos de inspección pueden parecer pensados como una revisión del producto próximo a sus etapas finales de fabricación, pero se trata más de una madurez conceptual que física. De esta forma, indagación, inspección y test se presentan casi como procesos concurrentes con una introducción en el proceso productivo muy compleja, que nos llevaría a establecer, incluso, una escala de madurez respecto de la usabilidad y el diseño

54

centrado en el usuario según el modo en el que estas y otras metodologías son asimiladas por las diversas corporaciones.

CONCEPTOS GENERALES ACERCA DEL TEST DE USABILIDAD (GENERAL CONCEPTS ABOUT USABILITY TESTING)

¿En qué consiste? El test de usabilidad desarrolla experimentos para obtener información específica acerca de un diseño. Los test tienen su raíz en la psicología experimental, lo que viene a significar la confianza en el tratamiento estadístico de los datos. Hoy, con más interés en la interpretación de los resultados que en las cifras a las que conducen los datos, se da menos importancia a los números y más o otras cuestiones que surgen o se descubren en el test. Por ejemplo, en la actualidad, muchos tests hacen uso del protocolo del pensamiento manifestado en conjunción con alguna forma de realización de medidas. Mientras la realización de medidas es todavía de utilidad, la información obtenida de las manifestaciones en voz alta se abre camino hacia el producto más rápidamente, sin ser precisa su consideración o análisis de forma previa a cualquier actuación sobre el mismo. ¿Cómo lo llevo a cabo? El proceso global es simple; hay que conseguir un cierto número de usuarios y descubrir cómo trabajan con el producto objeto del test. Normalmente se va a observar a usuarios operando de forma individual con el producto y se recogen datos acerca de cómo lo hacen (por ejemplo, cuánto tardan en realizar las tareas, cuantos errores cometen). Entonces se analizan los errores detectados en todos los experimentos de forma conjunta para detectar tendencias. Esta sección, basada en el libro de Rubin "Handbook of Usability Testing", entra en estas fases con mayor detalle: Determinar qué es lo que se está buscando ¿Qué se quiere conocer del producto? Se comienza estableciendo un propósito global para la investigación; podría querer determinarse, por ejemplo, el motivo por el que se han disparado las llamadas al servicio técnico después de la última salida al mercado o si, tras haber perdido parte de la cuota del mercado, los productos de la competencia se venden mejor porque son más usables. Manifestar este propósito en unos pocos objetivos para el test No es un objetivo apropiado plantearse la medida en la que el producto es usable. El objetivo es algo para lo que se pueda desarrollar un test. Por ejemplo, ¿es el retraso en la carga de la aplicación Java lo que lleva a los usuarios a abandonar la página?, ¿cuánto le cuesta a alguien sin conocimientos previos hacer su declaración de la renta con este software?, ¿proporciona suficiente información el sistema de ayuda en línea?, ¿es fácil de entender esa información o se basa en jerga burocrática? Diseñar el test Identificar a los usuarios a participar Es fundamental determinar el tipo de usuario que va a participar: hombres, mujeres o ambos, expertos en el uso del producto o novatos, jóvenes o ancianos... ¿Quiénes son los usuarios objetivo para nuestro producto?. Si lo que se pretende es realizar un test sobre los mandos de un avión de combate, no interesará una horda de escolares corriendo entre nuestros escenarios de test; de la misma forma, si se somete a test una máquina de refrescos incluiremos a los escolares en la población de usuarios, además de a los pilotos

55

de combate. El perfil de usuario del producto es fundamental a la hora de desarrollar el diseño del test y elegir a la muestra de sujetos. Determinación del diseño experimental El diseño experimental hace referencia a la forma en que se ordenarán y conducirán los experimentos para eliminar las variables carentes de interés de nuestro análisis. Por ejemplo, supongamos que estamos comprobando un software para el cálculo de impuestos. ¿Buscaremos usuarios que hayan hecho la declaración de la renta mediante este software y ya tengan un cierto conocimiento del producto?. Podría resultar interesante dirigir dos grupos, uno que agrupara a los novatos y otro que agrupara a usuarios con un cierto nivel de experiencia. Desarrollar las tareas que los usuarios llevarán a cabo durante cada experimento Lógicamente, estas deberían derivarse de las que los usuarios normalmente realizan cuando están haciendo uso del producto. Hay que especificar qué es lo que se necesita para establecer el escenario: los estados de la máquina o del sistema en cuestión, pantallas, documentación y cualquier otro tipo de ayudas en el trabajo que deban estar presentes. Igualmente hay que determinar qué es lo que se va a entender por tarea completada (esto es, si el usuario guarda con éxito el documento editado, o completa una determinada operación de manufactura) Especificar la aparamenta del test En la experimentación científica tradicional, por ejemplo, en la investigación química o biológica, de las que derivan últimamente las metodologías de test de usabilidad, la aparamenta de test haría referencia al típico material de laboratorio, como los mecheros Bunsen, las probetas y pipetas y demás dispositivos utilizados en el transcurso de un experimento. En el caso del test de usabilidad, se tratará del ordenador y del software, o de la maqueta de un puesto de trabajo de manufactura, o del prototipo del cuadro de mandos de un coche. La aparamenta de test también incluye otros dispositivos presentes en el desarrollo del test, como las cámaras de vídeo para registrar las acciones del usuario, los dispositivos para registrar las acciones en la pantalla, grabadoras de audio para registrar comentarios, preguntas formuladas y respuestas, espejos unidireccionales, que mantendrán al experimentador fuera de la línea de acción del sujeto, y demás. Habitualmente se le da mucha importancia a estas cuestiones pero no tiene porqué ser así. Tanto si se utiliza un simple cámara portátil como si no existe en absoluto registro en vídeo, es posible obtener una gran cantidad de información de gran utilidad. Identificar al personal requerido Será preciso como mínimo un experimentador para conducir el test, desde dar la bienvenida al usuario hasta explicarle la secuencia de test y trabajar con el mismo durante cada tarea. Podría resultar conveniente la presencia de uno o dos observadores que contribuyeran a reducir la carga de trabajo del experimentador encargándose de parte del registro de datos. Disponer de algunos usuarios Establecer una lista de usuarios de la que se obtendrá una muestra poblacional de sujetos de test.

56

Se ha escrito tanto sobre la elección de sujetos de test que resultaría muy difícil entrar a considerar todos los aspectos, pero vamos a proporcionar algunas indicaciones. Se va a precisar del suficiente número de sujetos para completar la muestra de la población en tanto que ha de contemplar una variedad de capacidades, experiencias y características demográficas y teniendo en cuenta que otros factores pueden perjudicar el diseño experimental e influir en los datos. El perfil de usuario determinado durante el diseño experimental ayudará a determinar al tipo de usuario de nuestro producto. Por ejemplo, los mandos de un avión de combate podrían ser utilizados no sólo por los propios pilotos sino también por el equipo de mantenimiento, los instaladores, el equipo de diagnóstico y los instructores. Sin embargo, para el propósito de lo que se pretende descubrir (¿Permite al usuario el sistema de detección de tráfico aéreo evitar una colisión durante el vuelo invertido?), el interés prevalecerá sobre un único segmento de la población de usuarios, los pilotos. Incluso si se ha reducido la población de usuarios a un único perfil (por ejemplo, piloto de combate, hombre o mujer, con una visión 20/20 y edades entre los 22 y los 35 años, con, al menos, un nivel de diplomatura o equivalente), aún será preciso recabar más información. ¿Qué experiencia tiene cada usuario con este mando? ¿Están acostumbrados a los antiguos accionamientos mecánicos o prefieren dispositivos digitalizados de alta tecnología? ¿Alguno tiene ceguera de color? ¿Cuál de sus ojos es el dominante?. Y así se podría seguir y seguir, pero cuanto más conocimiento se tenga acerca de los usuarios de test, menor será la posibilidad de que algún factor extraño nos sorprenda de entre los datos experimentales. ¿Y cómo se encuentra a estos usuarios?. Por cualquier medio disponible, como puedan ser empleados y familiares de los mismos, agencias de trabajo temporal, empresas analistas de mercado. Indudablemente esto supone un gasto pero se consigue un importante ahorro en tiempo a la hora de establecer categorías y analizar características. También se puede acudir a los registro de los servicios técnicos y de los equipos de ventas, asociaciones de consumidores y organizaciones industriales. Dependiendo del tipo de población que se requiera se puede solicitar la ayuda de asociaciones de jubilados, que van a disponer de más tiempo libre, u ofrecer visitas escolares a los colegios, por ejemplo. Indudablemente, surgirán problemas al buscar una población entre pilotos de combate, como en el ejemplo utilizado anteriormente, o ejecutivos de alto nivel, si se pretendiera testear un sistema de información ejecutiva (Executive Information System, EIS), por ejemplo. Establecer el test Preparar la aparamenta del test La aparamenta requerida para un test de usabilidad incluye el ordenador y el software para un test de software, o una máquina o una maqueta para un test de hardware. Algunos test se desarrollan con prototipos; en tal caso, es preciso asegurarse de que los estados a los que se haya de acceder en cada escenario de tareas se encuentren disponibles en el prototipo. Del mismo modo, habrá de considerarse el material que haya que proporcionar al sujeto del test y al experimentador durante el transcurso del mismo. El sujeto contará con una lista de las tareas a realizar. Los pasos a través de los cuales se realizará la tarea se omitirán intencionalmente si lo que se pretende es descubrir la accesibilidad de ciertas secuencias de comandos. El experimentador dispondrá habitualmente de un esquema básico que reflejará el modo en el que presentará las tareas al sujeto usuario, así como un formulario para registrar observaciones durante el

57

test. En ocasiones, se puede acordar el uso de un cuaderno de taquigrafía, que resulta útil cuando se pretende captar absolutamente todo lo que está sucediendo. Preparar la muestra del test La muestra del test es el conjunto de sujetos a los que se conducirá a través del test. ¿Cuántos se necesitan?. La mayoría de las recomendaciones indican que al menos cuatro o cinco participantes son precisos para encontrar la mayoría de los problemas de usabilidad. La muestra se habrá de escoger en base a los objetivos y los perfiles de usuario, así como en la disponibilidad en las fechas de realización del test. Conducir el test Preparar a los sujetos para el test Dado que la mayoría de las personas se sienten incómodas cuando se les mete en un laboratorio y se les solicita que realicen una serie de tareas, mientras están siendo cronometrados y sus errores están siendo registrados para ser analizados, es fundamental ponerle las cosas fáciles al sujeto de test. Hay que explicarle que puede detener el test en cualquier momento, que puede salir al baño, o realizar un descanso si es preciso. Hay que recalcar que lo que se está testeando es el producto y, en ningún caso, el usuario, que no ha de sentirse presionado en ningún sentido por el test. Y, por supuesto, hay que agradecer al usuario su participación. En la mayoría de los tests se firman, con antelación al mismo, acuerdos acerca del respeto de la confidencialidad de las partes, así como los medios consentidos para el registro de los datos. Como parte de este papeleo previo, se puede solicitar del participante la cumplimentación de un cuestionario para identificar sus áreas de conocimiento o su actitud o simplemente para tener más información acerca de las características del mismo. Conducir al sujeto a través de las tareas y reunir los datos Un test típico consiste en un individuo ante una estación de trabajo realizando tareas escritas mientas un experimentador observa al usuario y le formula preguntas o proporciona indicaciones si es necesario. Los test que buscan datos preferenciales o conceptuales (a través del pensamiento manifestado, por ejemplo) pueden dar lugar a una extensa interacción entre experimentador y sujeto. Los tests en los que se tratan de descubrir datos empíricos, como tasas de error, exigen, por otra parte, la reducción a la mínima expresión de tal interacción. Hay que permitir trabajar al sujeto a través de las tareas sin demasiadas interferencias. Resultará difícil verlo esforzarse en momentos complicados, pero es preferible aprender de su esfuerzo en el laboratorio antes de que sufra esa situación tras haber pagado por el producto y habérselo llevado a casa. Desde luego, si el sujeto llegara a las lágrimas o pretendiera marcharse del laboratorio (lo que, efectivamente, puede ocurrir), correspondería solucionar de forma inmediata el problema o, simplemente, dar paso a otra tarea. Incluso si no se está haciendo uso del protocolo del pensamiento manifiesto, podría resultar de interés formular al sujeto ciertas preguntas durante el test si se considera de mayor interés descubrir el motivo por el que el usuario hizo algo de una forma determinada.

58

Hacer dar parte al usuario Discutir el test con el usuario Una vez que se han completado las tareas, y el test ha finalizado, se pasa a charlar con el usuario acerca del mismo. Conviene volver sobre los sucesos que pudieron tener lugar durante el test para reunir más información a partir de lo que el usuario estaba pensando en ese momento. Una forma de revisar estos momentos es volviendo a los mismos y discutirlos con el sujeto, o, simplemente, preguntarle qué momentos del test considera más notables. Hay que agradecer al usuario su participación. No se puede olvidar que nos están haciendo un gran favor, y es fundamental mostrarles nuestro aprecio. La mayoría de los laboratorios realizan algún regalo después del test. Además, manteniendo al usuario contento, se mantiene la posibilidad de su colaboración en experimentos futuros. Analizar los datos Encontrar primero los problemas más graves La identificación de los problemas más graves es la más sencilla en tanto que estos se van a evidenciar de las notas tomadas durante la sesión. Si cada usuario tuvo algún problema con el mismo elemento de un menú, evidentemente dicho elemento requerirá un revisión. Resumir los datos de realización recopilados Los datos de realización, como tasas de error y duraciones de las tareas, se evalúan mediante un análisis estadístico sobre el conjunto de los datos. La mayoría de los análisis consisten en el cálculo de una media y una desviación estándar así como de una comprobación de los datos para su validez. ¿Se advierte alguna tendencia de los datos? ¿Son más complejas determinadas partes del producto? Resumir los datos sobre preferencias recopilados Mediante la observación de las acciones de los usuarios, registrando sus opiniones, durante el test, formulando preguntas o registrando sus manifestaciones y antes o después del mismo, mediante el uso de cuestionarios, surgen una enorme cantidad de datos preferenciales. La mayoría de los diseños de los cuestionarios permiten cuantificar opiniones mediante el uso de escalas numéricas, y los datos cuantitativos encontrados pueden ser analizados mediante análisis estadístico. ¿Cuándo debería usar esta técnica? El test de usabilidad se utiliza a través del ciclo de vida del desarrollo del producto. En las etapas tempranas del proceso de desarrollo, el test de una versión previa o del producto de un competidor proporciona referencias muy útiles al equipo de diseño. En las etapas medias, el test valida el diseño e informa sobre las posibilidades de refinamiento del mismo. En etapas posteriores, el test asegura que el producto alcanza ls objetivos del diseño. ¿Quién me puede decir más acerca de ella? Dumas, JS, and Redish, Janice, A Practical Guide to Usability Testing, 1993, Ablex, Norwood, NJ ISBN 0-89391-991-8 (papel) Lindgaard, G., Usability Testing and System Evaluation: A Guide for Designing Useful

59

Computer Systems, 1994, Chapman and Hall, London, U.K. ISBN 0-412-46100-5 Rubin, Jeffrey, Handbook of Usability Testing, 1994, John Wiley and Sons, New York, NY ISBN 0-471-59403-2 (papel) Información adicional Bell, Brigham, Rieman, John, and Lewis, Clayton. "Usability Testing of a Graphical Programming System: Things We Missed in a Programming Walkthrough.'' Communications of the ACM volume/number unknown (1991): 7-12 Chartier, Donald A. "Usability Labs: The Trojan Technology.'' Cline, June A., Omanson, Richard C., and Marcotte, Donald A. "ThinkLink: An Evaluation of a Multimedia Interactive Learning Project.'' Haigh, Ruth, and Rogers, Andrew. "Usability Solutions for a Personal Alarm Device.'' Ergonomics In Design (July 1994): 12-21 Heller, Hagan, and Ruberg, Alan. "Usability Studies on a Tight Budget.'' Design+Software: Newsletter of the ASD (1994) Jordan, Patrick W., Thomas, Bruce, Weerdmeester, Bernard, (Eds.), Usability Evaluation in Industry, 1996, Taylor & Francis, Inc., London, UK. ISBN: 0-74-840460-0 Lund, Arnold M. "Ameritech's Usability Laboratory: From Prototype to Final Design.'' Whiteside, John, Bennett, John, and Holtzblatt, Karen. "Usability Engineering: Our Experience and Evolution'' from Handbook of Human-Computer Interaction, M. Helander (ed.). Elsevier Science Publishers B.V. (North Holland), 1988: 791-804. Wiklund, Michael E., Usability in Practice, 1994, AP Professional, Cambridge, MA ISBN 0-12-751250-0 Yuschick, Matt, Schwab, Eileen, and Griffith, Laura. "ACNA--The Ameritech Customer Name and Address Service.'' Técnicas y aspectos del test de usabilidad Bailey, R. W., et. al. "Usability Testing versus Heuristic Evaluation: A Head-to-Head Comparison.'' Proceedings of the Human Factors Society 36th Annual Meeting, (1992): 409-413. Dayton, Tom, et. al. "Skills Needed By User-Centered Design Practitioners in Real Software Development Enironments: Report on the CHI `92 Workshop.'' SIGCHI Bulletin v25 n3, (July 1993): 16-31. Jeffries, R., et. al., "User Interface Evaluation in the Real World: A Comparison of Four Techniques.'' Reaching through Technology: Proceedings of the 1991 CHI Conference, New Orleans, April-May 1991, NY: Association for Computing Machinery (ACM), 119-124. Virzi, Robert A. "Refining the Test Phase of Usability Evaluation: How Many Subjects is Enough?'' Human Factors, v34, n4 (1992): 457-468.

60

Métodos de Test Se puede conseguir una aproximación apropiada a las necesidades del usuario, se pueden contemplar la existencia de múltiples contextos de trabajo, se puede, también, hacer del usuario parte del proceso de diseño en una fase de evaluación o inspección, pero ¿existe algún método para detectar el origen de los problemas de usabilidad?, ¿es posible plantear un experimento con un objetivo particular (y no la medida en que un determinado producto sea usable)?. El test de usabilidad va a desarrollar experimentos para obtener información específica acerca de un diseño. Así, antes de pasar a las técnicas, conviene hacer primero un recorrido por los Conceptos Generales acerca del Test de Usabilidad. • Protocolos de Expresión del Usuario • Realización de medidas • Variantes del Test de Usabilidad clásico Protocolos de Expresión del Usuario En la mayoría de las técnicas de Test aplicadas se va a contemplar la captación de las impresiones y sensaciones que el usuario manifiesta oralmente, diciéndose entonces que se están aplicando Protocolos de Expresión de Usuario, donde se distinguen: • Protocolo del Pensamiento Manifestado (Thinking Aloud Protocol). Durante el transcurso del test, donde el participante está realizando una tarea como parte de un escenario de usuario, se solicita de este que exprese en voz alta sus pensamientos, sensaciones y opiniones mientras interactúa con el producto. • • Protocolo de Preguntas (Question-Asking Protocol). Este método lleva un paso más allá al protocolo del pensamiento manifestado al provocar las manifestaciones del usuario respecto del producto mediante la formulación de preguntas directas acerca del mismo. Realización de Medidas Los objetivos de test han de ser, además de testeables (¡un error frecuente es que esto no sea así!) cuantificables y pronto se revela como importante la Realización de medidas (Performance Measurement), aunque esta técnica decae en los últimos tiempos con su aplicación a productos hardware, cobrando importancia los modos de uso (y los contextos en que suceden). La importancia de los datos, junto con el modo en que los usuarios interaccionan con el prototipo, es una de las cuestiones más estudiadas, objeto de

iscusiones y amplios estudios. d Variantes del Test de Usabilidad clásico Otras variantes del Test de Usabilidad clásico: • Método Tutorado(Coaching Method). Ya sea el experimentador u otro experto van a contestar con la mayor precisión posible cualquier pregunta que formulen los usuarios de test acerca del sistema. • Método de Seguimiento (Shadowing Method).

61

• Método de Instrucción previa (Teaching Method). En una fase previa se permite a ls participantes interaccionar con el sistema para adquirir cierta solutra en su manejo. Después, habrán de ayudar a un usuario inexperto a realizar las tareas que se le encomienden. • Método del Descubrimiento Conjunto (Co-discovery Method). Es una variante del test de usabilidad en la que dos participantes intentan realizar las tareas juntos mientras están siendo observados. Tal circunstancia se aproxima a la situación real del contexto de uso y aporta más datos. A este método también se le denomina Aprendizaje por Descubrimiento Conjunto • Test Retrospectivo (Retrospective Testing). Consiste en la revisión de los registros realizados durante el Test.

PROTOTIPADO Y CATEGORIZACIÓN La aplicación de la técnica de prototipado va a ser fundamental en el desarrollo e implementación de los métodos para la inspección y test de un producto, dado que, habitualmente, no será el producto final lo que se someta a los diversos experimentos, sino un prototipo del mismo con unas determinadas características, en virtud de las cuales se enfocarán los métodos en una dirección concreta. En definitiva, se trata de una cuestión indispensable, presente incluso en ciertos métodos contextuales (¡la versión previa de un producto puede constituir una forma de prototipo para la nueva generación!). Por otra parte, los métodos de categorización que se citan, y después su conexión con el amplio y complejo mundo de la Calidad, tan sólo recuerdan la necesidad de una planificación meticulosa que nos ha obligado a hablar muchas veces de etapas de prediseño. Más concretamente, la Categorización por Tarjetas, sugerirá casi de inmediato al lector cómo establecer el contenido de los menús de una aplicación informática. • Prototipado • Según la funcionalidad reproducida • Según la fidelidad de la reproducción de la interfaz • Otras técnicas de prototipado • Prototipado Rápido • Prototipado por Vídeo • Métodos de Categorización Prototipado El prototipado modela el producto final y permite efectuar un test sobre determinados atributos del mismo sin necesidad de que está disponible. Se trata, simplemente, de testear haciendo uso del modelo. De acuerdo con las características del prototipo en cuanto a interfaz, funcionalidad, posibilidades de ampliación,... tenemos variadas posibilidades. En muchas ocasiones se dirá que Cuanto más próximo se encuentre el prototipo al producto real, mejor será la evaluación, pero veremos que esto no tiene por qué ser así.

62

Según la funcionalidad reproducida Podemos distinguir dos tipos: • Prototipado Horizontal (Horizontal Prototyping): los prototipos horizontales exhiben un amplio espectro de las características del producto, pero sin el respaldo de una funcionalidad relativamente amplia. • Prototipado Vertical (Vertical Prototyping): los prototipos verticales muestran la funcionalidad exacta de un producto para una pequeña parte del conjunto completo. Por ejemplo, un prototipo vertical de un procesador de textos podría mostrar todas las funciones de comprobación de ortografía y gramática, pero ninguna función relacionada con la entrada de texto o su formato. Prototipado Horizontal (Horizontal prototyping)

¿En qué consiste?

Los prototipos horizontales exhiben un amplio espectro de las características del producto, pero sin el respaldo de una funcionalidad relativamente amplia. Los prototipos horizontales se utilizan con frecuencia para evaluar las preferencias de los usuarios respecto de las interfaces de usuario, cuando las funciones reales operativas aún no han sido implementadas. Tales prototipos permiten una evaluación del diseño de la interfaz, así como la ubicación y accesibilidad de determinados aspectos y características, sin requerir el funcionamiento real de las funciones que representan.

¿Cómo lo llevo a cabo?

A menudo, los prototipos horizontales se confeccionan como de baja fidelidad, consistiendo en pocos más que dibujos y listas manuscritas, pasando por maquetas realizadas por ordenador que tienen el mismo aspecto que el producto final. Las maquetas realistas pueden construirse con la mayoría de los entornos de desarrollo gráfico.

¿Cuándo debería usar esta técnica?

Esta técnica se utiliza con preferencia en las etapas tempranas del proceso de desarrollo, cuando el trabajo sobre las funciones reales del producto aún no ha dado comienzo, pero el conjunto de características es conocido.

¿Quién me puede decir más acerca de ella?

Nielsen, Jakob, Usability Engineering, 1993, Academic Press/AP Professional, Cambridge, MA ISBN 0-12-518406-9 (papel)

63

Prototipado Vertical (Vertical Prototyping)

¿En qué consiste?

Los prototipos verticales muestran la funcionalidad exacta de un producto para una pequeña parte del conjunto completo. Por ejemplo, un prototipo vertical de un procesador de textos podría mostrar todas las funciones de comprobación de ortografía y gramática, pero ninguna función relacionada con la entrada de texto o su formato. Todas las funciones de un prototipo vertical imitan sus equivalente reales tanto como sea posible.

¿Cómo lo llevo a cabo?

Dado que un prototipo vertical ha de ser funcional prácticamente de forma completa (aunque sólo para una pequeña parte de la interfaz del producto), quizás la mejor forma de obtener un prototipo vertical es utilizar un módulo completamente operativo de un producto. Para aplicaciones software que se han desarrollado con arquitectura modular, esto resulta relativamente sencillo, aunque las interfaces a otros módulos no funcionarán (lo que no supone ningún problema porque es la funcionalidad de las secciones dadas las que serán inspeccionadas o testeadas, y no otras).En el caso de un coche, sería el asiento y el tablero de mandos lo que podría ser testeado, mientras que el chasis, la carrocería y otros elementos aún no están disponibles.

¿Cuándo debería usar esta técnica?

Esta técnica se utiliza cuando el diseño para una parte del producto en particular está prácticamente completa y merece la pena evaluarla en tanto que es un elemento contiguo a otro. Aun cuando algunas partes del producto aún no están listas para el test, es posible determinar ciertos problemas con alguna parte en concreto mientras las demás se encuentran aún en fase de desarrollo.

¿Quién me puede decir más acerca de ella?

Nielsen, Jakob, Usability Engineering, 1993, Academic Press/AP Professional, Cambridge, MA ISBN 0-12-518406-9 (papel)

Según la fidelidad de la reproducción de la interfaz Podemos distinguir dos tipos: • Prototipado de Alta Fidelidad (High-Fidelity Prototyping): el prototipo será prácticamente idéntico al producto final. • Prototipado de Baja Fidelidad (Low-Fidelity Prototyping): el aspecto del prototipo no se corresponderá con el del producto final, si bien reproducirá la disposición de sus características, dimensiones y otros aspectos (de hecho, se trata de prototipos horizontales, habitualmente). Frecuentemente se hablará de Prototipado de Papel (Paper prototyping) como uno de los mecanismos más económicos, en tiempo y dinero, para desarrollar prototipos. Ha sido una herramienta tradicionalmente destinada a software,

64

pero se está empezando a comprobar que prototipos bi- y tridimensionales para hardware proporcionan resultados magníficos. Por otra parte, estos prototipos admiten, en general, rápidas modificaciones, admitiendo, en el momento del test, la inclusión en el mismo de variadas características. Prototipado de Alta Fidelidad (High-Fidelity prototyping)

¿En qué consiste?

El prototipado de alta fidelidad es un método donde el prototipo utilizado para el test se corresponde con la interfaz real en la mayor medida posible. Normalmente, y en particular para interfaces de software, es otra herramienta de software la utilizada para maquetar la interfaz, Dicha herramienta acepta entradas desde ratón o teclado, tal y como haría la interfaz real y responde a esos eventos de idéntica forma (mostrando una ventana en particular, un mensaje, cambiando de estado, etc).

¿Cómo lo llevo a cabo?

Se ha de utilizar una herramienta que permita imitar el aspecto y el comportamiento de la interfaz real en la mayor medida de los posible. Muchos prototipos de software se construyen utilizando herramientas multimedia. Dichas herramientas, además, permiten imitar la existencia de retrasos en máquinas más lentas o la espera a la respuesta de un servidor.

Las interfaces basadas en la Web se prototipan bastante bien con HTML y HTML Dinámico, siendo posible reutilizar algunos fragmentos de código del prototipo en la interfaz real.

Los prototipos de software pueden utilizar espuma o goma para proporcionar una representación física realista del producto. Si se pretende testear con frecuencia con el prototipo, es recomendable utilizar otro tipo de materiales, como pueda ser madera o panel, por ejemplo. Los salpicaderos de los automóviles, por ejemplo, suelen ser testeados mediante maquetas de arcilla esculpida sobre marcos de madera y alambre.

¿Cuándo debería usar esta técnica?

Como cualquier método de prototipado, se puede utilizar esta técnica cuando aún no se dispone de la interfaz real, normalmente, en las etapas iniciales del proceso de desarrollo. Esta técnica es ideal cuando se dispone de poco tiempo y dinero para gastar y no es necesario recurrir al prototipado de baja fidelidad. Cuanto mejor sea el prototipo, mejores serán los resultados obtenidos. Si la fidelidad del prototipo es realmente buena, este puede ser usado en tests cuantitativos.

¿Quién me puede decir más acerca de ella?

Dumas, JS, and Redish, Janice, A Practical Guide to Usability Testing, 1993, Ablex, Norwood, NJ ISBN 0-89391-991-8 (papel)

65

Rubin, Jeffrey, Handbook of Usability Testing, 1994, John Wiley and Sons, New York, NY ISBN 0-471-59403-2 (papel

Prototipado de Baja Fidelidad (Low-Fidelity prototyping)

¿En qué consiste?

El prototipado de baja fidelidad es una manera barata de proporcionar prototipos para su uso en test y sesiones de diseño participativo. Baja-fidelidad significa que los prototipos a utilizar no tienen el aspecto real de la interfaz que se está testeando, aun cuando operan de la misma forma.

La idea es conseguir una gran cantidad de información de la interacción entre la interfaz y el usuario mediante la evaluación de este prototipo. Dado que los prototipos de baja fidelidad son baratos, tanto en términos de dinero como de tiempo, es posible permitirse un mayor número de ciclos de test, más sujetos o más prototipos.

¿Cómo lo llevo a cabo?

Preparando el prototipo

El ejemplo clásico del prototipado de baja fidelidad es el uso de lápiz y papel para maquetar interfaces en pantallas. Esto puede resultar tan simple como dibujar a mano cajas con controles garabateados, o imprimir el dibujo si se opta por un programa de ordenador. Habría de hacerse uno por cada pantalla de la interfaz.

Del mismo modo habrían de hacerse representaciones de los menús, grupos de botones, y demás elementos...Las notas Post-It resultan útiles, dado que mediante su movimiento y disposición se puede imitar la evolución en una estructura de menús.

Hay quien utiliza transparencias para simular una estructura de capas según la cual se disponen los diversos elementos, pero supone una complicación importante e innecesaria. La ventaja del prototipado de baja fidelidad es la ventaja de poder inventar a lo largo de la sesión nuevos elementos en la interfaz, bastando con incluirlos en una nota Post It.

El prototipado de baja fidelidad en acción

Llega el momento de utilizar el prototipo en una sesión de evaluación. Por ejemplo, en un test de usabilidad en el que se plantea de modo informal un protocolo de pensamiento manifestado, se pueden utilizar dos evaluadores, uno para la conducción del test y el otro para la manipulación del prototipo. Este segundo evaluador haría la función del ordenador, moviendo, reagrupando y exhibiendo diversos elementos en respuesta a las "entradas" proporcionadas por el primer evaluador.

En ocasiones, la evaluación puede volverse muy agitada, especialmente si se cuenta con un experto al que le encanta "hacer click" en todos los sitios. Resulta de ayuda disponer

66

de una serie de elementos dibujados con antelación y organizados, para disponer inmediatamente de un elemento cuando sea necesario.

¿Cuándo debería usar esta técnica?

Al igual que cualquier método de prototipado, esta técnica se utilizaría cuando no se dispusiera todavía de la interfaz real, previsiblemente en las primeras etapas del proceso de desarrollo. Esta técnica es ideal cuando se dispone de poco tiempo y dinero para gastar y resulta de mayor interés la información aportada por el usuario que la reunión de datos.

¿Quién me puede decir más acerca de ella?

Dumas, JS, and Redish, Janice, A Practical Guide to Usability Testing, 1993, Ablex, Norwood, NJ ISBN 0-89391-991-8 (papel) Nielsen, Jakob, "Paper versus Computer Implementations as Mockup Scenarios for Heuristic Evaluation'', Human-Computer Interaction-Interact `90, D. Diaper et. al. (ed.) Elsevier Science Publishers B.V. (North Holland), 1990: 315-320 Rettig, Marc, "Prototyping for Tiny Fingers (Everything I Need to Know About Prototyping, I Learned In Kindergarten)'', Communications of the ACM, April 1994. Rubin, Jeffrey, Handbook of Usability Testing, 1994, John Wiley and Sons, New York, NY ISBN 0-471-59403-2 (papel) Snyder, Carolyn, "Using Paper Prototypes to Manage Risk," October 1996, Software Design and Publisher Magazine Virzi, Robert A, Sokolov, Jeff, and Karis, Demetrios. "Usability Problem Identification Using Both Low- and High-Fidelity Prototypes,'' 1995: Obtenido directamente de los autores.

Prototipado de Papel (Paper Prototyping)

¿En qué consiste?

Este método se caracteriza por el uso de materiales y equipo sencillos para crear una simulación basada en papel de la interfaz de un sistema con el objetivo de explorar los requerimientos de usuario (Después, durante el proceso de diseño, los prototipos de papel van a constituirse como medios valiosos y rentables para evaluar las opciones de diseño. Los elementos de la interfaz, como menús, ventanas, diálogos e iconos, se crean utilizando papel, tarjetas, acetato, bolígrafos,..). El resultado obtenido se denomina frecuentemente prototipo de baja fidelidad.

¿Cómo lo llevo a cabo?

No es este el lugar para entrar en consideraciones sobre gestión de proyectos, pero es claro que hay que disponer del tiempo suficiente para crear el prototipo (tiene especial interés el modo en el que se representen los elementos cuya apariencia va a cambiar),

67

diseñar algunas tareas, reunir usuarios, conducir la evaluación del prototipo e informar de los resultados.

Hay que seleccionar a los usuarios apropiados para el test del prototipo (hay que tratar de cubrir una amplia variedad) y preparar escenarios de tareas realistas para la evaluación. Se va a descuidar en ocasiones la realización de pruebas previas para practicar con el manejo del prototipo, que habrá de manipularse a medida que el usuario trabaja en las tareas según las instrucciones proporcionadas.

En cuanto a la observación, se podrán tomar notas de determinados problemas, así como de soluciones potenciales durante la sesión para su posterior consideración.Si es preciso, además, se conducirán las entrevistas necesarias con el usuario tras la sesión basándose en preguntas preestablecidas así como otros aspectos que hayan surgido durante la evaluación.

Tras el análisis, resumir y evaluación de la información obtenida y las observaciones realizadas se habrá de la severidad de los problemas identificados, lo que se traducirá en una serie de implicaciones en los requerimientos de usuario. Donde sea necesario, se refinará el prototipo de papel y se repetirá el proceso anterior.

¿Cuándo debería usar esta técnica?

Se requieren materiales y recursos mínimos para lograr una sensación de producto y esto puede ser un motivo para proceder con ella. Además también puede ser llevada a cabo con poca o ninguna experiencia en factores humanos. En cuanto a consideraciones temporales, un prototipo de papel y lápiz puede desarrollarse en cualquier momento en cuestión de horas.

¿Quién me puede decir más acerca de ella?

http://www.ucc.ie/ucc/research/hfrg/projects/respect/urmethods/paperproto.htm En cuanto al prototipado en papel de sitios Web, son una interesante fuente de información los artículos de Jakob Nielsen.

Otras técnicas de prototipado

Prototipado Reutilizable (Reusable Prototyping), más frecuentemente denominado Prototipado Evolutivo (Evolutionary Prototyping).

Prototipado Modular (Modular Prototyping), también más conocido como

Prototipado Incremental (Incremental prototyping) Prototipado Rápido El Prototipado Rápido se describe como un método basado en ordenador que pretende reducir la iteraciones en el ciclo de diseño. Habitualmente se desarrollan prototipos que son rápidamente reemplazados o modificados como consecuencia de los datos proporcionados por continuos experimentos. Efectivamente es pues un método caracterísitico del software (esta filosofía se plantea posible para el hardware, pero

68

requiere más medios) y la participación del usuario se relega al test del prototipo. Dos casos particulares son: • RAD (Rapid Application Development o Desarrollo Rápido de Aplicaciones) • JAD (Joint Application Development o Desarrollo Conjunto de Aplicaciones) Prototipado por Vídeo Como se verá, el nombre de la técnica no debe inducir a confusión (¡nada que ver con la etnografía!): el prototipo consiste en una simulación por vídeo de la funcionalidad de una interfaz. Ver más información. Métodos de Categorización Hay dos métodos característicos • Categorización por Tarjetas (Card Sorting). Se trata de un método de categorización donde los usuarios clasifican tarjetas, en las que se representan varios conceptos, en diversas categorías. • Diagramas de Afinidad (Affinity Diagram). Es un método de categorización en el que los usuarios clasifican varios conceptos, que escriben en notas Post It, en diversas categorías. Este método suele ser utilizado por un equipo para organizar una gran cantidad de datos, organizando las notas en grupos basándose en las relaciones y asociaciones que establecen entre los distintos conceptos. Estos dos métodos provienen realmente del mundo de la calidad. Así, conviene echar un vistazo a: • Las Siete Herramientas para el Control de la Calidad (The Seven Quality Control Tools ) • Las Siete Herramientas para la Planifición y la Dirección (The Seven Management and Planning Tools) Pensar en términos de calidad nos lleva a considerar otro método de activa participación del usuario: el Despliegue de la Función de Calidad (QFD: Quality Function Deployment). El objetivo que se plantea este método es conseguir un producto con las propiedades deseadas por el cliente o usuario, en lugar de tratar de asignarle todas las tecnológicamente posibles. Son esas expectativas del cliente las que drigen el proceso de desarrollo, dándose aquí uno de los casos de participación más destacados. En la red hay una gran cantidad de información al respecto (se obtienen más de 4000 salidas con el buscador Google), pero con el propósito de adentrarse de lleno en el mundo de la calidad y entender la amplitud de conceptos que contempla, se recomienda el "Manual de Gestión e Ingeniería de la Calidad" de Tilo Pfeifer y Fernando Torres (Mira Editores). Métodos de Inspección Se van a establecer cinco aproximaciones básicas: • Inspecciones • Evaluación Heurística • Paseos Cognitivos • Listas de Comprobación • Otras perspectivas

69

Inspecciones Vamos a que ver que tenemos varios tipos de técnicas que podemos catalogar como Inspecciones. Sin embargo, son las denominadas Inspecciones Formales de Usabilidad las que, procediendo de la metodología de las Inspecciones de Código, se llevan a la práctica con más frecuencia y contemplan con mayor amplitud los conceptos que manejamos. • Inspecciones Formales de Usabilidad (Formal Usability Inspections). Los inspectores van a recorren meticulosamente las tareas con los propósitos y objetivos de los usuarios en mente, de forma similar a los paseos cognitivos , si bien el énfasis radica menos en la teoría cognitiva y más en el hallazgo de errores. Las heurísticas van a ser utilizadas como una ayuda para los no profesionales de la usabilidad en la búsqueda de defectos. • Inspecciones de Características (Feature Inspections). La inspección de características analiza únicamente un conjunto de características determinadas del producto, proporcionándose escenarios de usuario para el resultado final a obtener del uso del producto. Así, se trabajará frecuentemente con prototipos verticales. • Inspecciones de Consistencia (Consistency Inspections). El objetivo de las inspecciones de consistencia es asegurar la misma a través de múltiples productos procedentes del mismo esfuerzo de desarrollo, como pueda ser una suite de ofimática o un sitio web. • Inspecciones de Estándares (Standard Inspections). Las inspecciones de estándares garantizan el ajuste a los estándares industriales. No hay que olvidar que productos diseñados para ser comercializados en un país en particular deben poseer la conformidad con los estándares de ergonomía del país en cuestión. Evaluación Heurística La Evaluación Heurística es una variante de la Inspección de Usabilidad donde los especialistas en usabilidad juzgan si cada elemento de la interfaz de usuario sigue los principios de usabilidad establecidos. La Evaluación Heurística puede ser utilizada en, prácticamente, cualquier momento del ciclo de desarrollo, aunque probablemente se adapta mejor en etapas tempranas, cuando no hay material lo suficientemente firme para efectuar un test. No requiere, pues, gran despliegue de medios y puede ser llevado a cabo por personal no especializado e incluso por usuarios tipo. Ya son un clásico en la materia las heurísticas de Jakob Nielsen. Paseos Cognitivos (Walkthroughs) Los Paseos Cognitivos derivan de los análisis cognitivos y reciben este nombre porque el especialista que realiza la sesión recorre un escenario de tareas determinado como habría de hacerlo un usuario tipo. Según se plantee la sesión de forma individual o en grupo (usuarios, desarrolladores y profesionales de la usabilidad): • Paseo Cognitivo (Cognitive Walkthrough). • Paseo Cognitivo Conjunto (Pluralistic Walkthrough) Listas de Comprobación Las técnicas más características son: • Guías de Comprobación (Guidelines Checklist). Las guías y las listas de comprobación ayudan a asegurar que los principios de usabilidad sean considerados en

70

un diseño. Normalmente, las listas de comprobación se utilizan en combinación con algún método de inspección de usabilidad y sirven de referencia. • Listas de Comprobación Basadas en Escenarios (Scenario-Based Checklist). Se puede entender como una particularización de la anterior en la que la inspección se lleva a cabo a través de tres escenarios: usuario novel, usuario experto y manejo de errores. Para cada uno se proporcionará una lista de aspectos a comprobar. En la Web, una implementación automatizada de las listas de comprobación (así como un magnífico medio hacia la accesibilidad de los sitios web) la constituyen: • Validador de HTML 4.0 • Validador de Hojas de Estilo CSS2 • Validador de Accesibilidad Bobby 3.1.1

OTRAS PERSPECTIVAS Una perspectiva más participativa se plantea con la Evaluación Cooperativa (Co-operative Evaluation), siendo la participación del usuario más manifiesta, ya sea como usuario experto, usuario convencional o usuario LCU (Least Competent User o Usuario menos Competente). De nuevo, estamos hablando aquí de "evaluación" pero la técnica tiene ya connotaciones de test. Dentro de los métodos de inspección, otros que presentan, también, una orientación al Test • Métodos de Diario (Diary methods). Se requiere de los usuarios que registren las actividades que desarrollan en su entorno de trabajo durante un día normal. El registro puede tener o no carácter estructurado. • Modelado por Empatía (Empathic Modelling). Se trata de un método desarrollado para aplicar con usuarios con discapacidades, de modo que el dseñador/desarrollador trata de ponerse en la situación del usuario simulando tal discapacidad. Tal circunstancia es muy compleja, requiriendo amplios estudios e investigaciones. Evaluación de Usabilidad Formativa Índice • Definición • Cuestiones a las que puede dar respuesta la evaluación formativa • Beneficios de la evaluación formativa • PASO 1. DISEÑO DE LA EVALUACIÓN. • PASO 2. DESARROLLO DE UN PROTOCOLO PARA LAS SESIONES DE TEST. • PASO 3. EFECTUAR UN TEST PILOTO DE LOS PROTOCOLOS DE LA SESIÓN. • PASO 4. CONDUCIR LAS SESIONES DE EVALUACIÓN REALES. • PASO 5. INTERPRETAR LOS DATOS REUNIDOS. • PASO 6. PREPARAR UN INFORME. Definición Se trata de la evaluación de un interfaz de usuario sin terminar, varias veces realizada durante cada ciclo, que tiene como objetivo averiguar los problemas de usabilidad que existen en la iteración actual. Cuestiones a las que puede dar respuesta la evaluación formativa • ¿Hay partes de la interfaz propensas a los errores? • ¿Precisan algunas tareas más tiempo del esperado? • ¿Encuentran los usuarios algunas tareas especialmente difíciles? • ¿Viola la interfaz las guías comunes de la usabilidad?

71

• ¿Hay suficiente ayuda disponible? • ¿Qué cambios les gustaría ver a los usuarios? • ¿Qué quejas tienen los usuarios? • ¿Qué errores cometen los usuarios? • ¿Dónde es más probable que los usuarios se queden bloqueados • ¿Necesitarán los usuarios algún tipo de asistencia que les guíe en el desarrollo de las tareas más complejas? Beneficios de la evaluación formativa • Debe realizarse en las etapas tempranas del proceso de diseño, cuando se han empleado aproximadamente un 10% de los recursos del proyecto disponibles. • Proporciona las primeras medidas sólidas de la realización de tareas • Facilita a los diseñadores ponerse en el lugar de las personas que hacen uso del sistema en el mundo real • Ayuda a decidir a los diseñadores el paso a la siguiente fase del proceso • Puede incrementar el interés del usuario y una aceptación eventual del producto final • Puede descubrir problemas que no se advirtieron durante el prototipado iterativo PASO 1. DISEÑO DE LA EVALUACIÓN. Establecimiento de metas • Diagnóstico: determinar si existen problemas de usabilidad • Verificación: determinar si el diseño se ajusta a las referencias establecidas y satisface los requerimientos de usabilidad especificados • Validación: determinar si el diseño será usable en la práctica por los usuarios Identificar las entradas y salidas deseadas 1. Posibles entradas (inputs) • prototipo de la interfaz • lista de preguntas, si se plantea una entrevista estructurada • lista de comprobación, si se va a realizar una evaluación heurística • Referencias para los requerimientos de usabilidad • Instrucciones y directrices para el test derivados de los escenarios de tareas 2. Posibles salidas (outputs) • Informes de test individuales • Datos adicionales, agregados o tabulados, del conjunto de los informes de test • Análisis de los problemas encontrados • Lista de peticiones de cambios según prioridad Elegir una estrategia de evaluación, que puede ser una o más de las siguientes: 1. Reunión y análisis estadístico de los datos de forma automatizada mediante software apropiado 2. Revisión por personal especializado 3. Evaluación Heurística basada en guías de comprobación apropiadas 4. Encuesta de usuarios • Cuestionario de preferencias de usuario • Entrevista estructurada • Focus Groups 5. Test basado en Escenarios • Entradas

72

o Instrucciones orales o escritas para el participante, paso a paso, subtarea a subtarea o Instrucciones escritas para el evaluador, paso a paso, subtarea a subtarea • Salidas o El participante tiene que completar tareas con una serie de parámetros como referencia o participa según un protocolo de expresión o Registro de los errores cometidos o Pistas proporcionadas por el Evaluador al Participante en cada subtarea o Datos temporales sobre la realización de las tareas o Comentarios del participante o Comentarios del Evaluador Elegir un evaluador • Para reducir la polarización, el evaluador no debería ser miembro del equipo de desarrollo • Los evaluadores deberían ser personas receptivas y de mentalidad abierta, listos para recibir tanta información negativa como los participantes quieran proporcionar. Elegir a participantes para el test • Identificar a los participantes potenciales sobre un perfil de la población objetivo • Dividir a los participantes en "clases de usabilidad" según factores como "posee experiencia con sistemas similares", "posee experiencia con este sistema",... Si todavía no se ha llevado a cabo, desarrollar un análisis de tareas y, a partir de aquí, desarrollar un modelo de tareas jerárquico. Si todavía no se ha llevado a cabo, construir un escenario de tareas representativo para cada tipo de tarea de usuario de alto nivel. Las tareas obvias no deben ser excluidas Utilizar los escenarios de tareas representativos como una guía y establecer un conjunto de instrucciones y directrices PASO 2. DESARROLLO DE UN PROTOCOLO PARA LAS SESIONES DE TEST. Decidir el modo en el que se seguirán instrucciones y directrices 1. El evaluador proporciona el total del conjunto de instrucciones al participante: • No recomendado • Puede crear una sensación de presión sobre el participante 2. El evaluador proporciona las instrucciones escritas para cada tarea a medida que el participante progresa: • Recomendado • Preferible para tareas más complejas 3. El evaluador proporciona las instrucciones orales para cada tarea a medida que el participante progresa: • Recomendado • preferible para tareas más simples Determinar si la sesión será conducida en laboratorio o en campo • El test en laboratorio es preferible para etapas tempranas-medias • El test de campo es preferible para las últimas etapas Determinar si el test se llevará a cabo en una etapa temprana o en una etapa final • Protocolo en etapa temprana de aproximadamente una hora de duración o Establecer el entorno de Test o Establecer un ambiente de colaboración con el participante

73

o Si no se ha realizado, proceder a la firma por el participante del formulario de consentimiento o Proporcionar instrucciones al participante y establecer el papel del coevaluador o Proceder y estimular la expresión por el participante de sus impresiones y acciones o Entrevistar al participante según una serie de preguntas predeterminada o Discutir y revisar los resultados con el participante • Protocolo en etapa media de aproximadamente una hora de duración o Establecer el entorno de Test o Establecer un ambiente de colaboración con el participante o Si no se ha realizado, proceder a la firma por el participante del formulario de consentimiento o Proporcionar instrucciones al participante y establecer el papel del observador o Conducir dos o tres tareas según el procedimiento y efectuar el registro de datos o Mantener un tiempo de conversación con el participante o Conducir, de nuevo, dos o tres tareas según el procedimiento y efectuar el registro de datos o Entrevistar al participante según una serie de preguntas predeterminada o Discutir y revisar los resultados con el participante • NOTAS a. Se requiere una hoja de instrucciones por cuestiones de consistencia y reutilizabilidad o se indica que es el producto el que se somete a test, y no el participante o se explican la duración del test y el procedimiento básico o se explican los derechos del participante o se explica qué es lo que se está midiendo y el motivo b. Se requiere una hoja de consentimiento por cuestiones legales y éticas o para el consentimiento explícito y por firmado del participante o para el compromiso explícito y por firmado del participante o para que el participante ceda ciertos derechos en el proceso de test c. Se pueden requerir otros papeles, dependiendo de la situación o encuestas o cuestionarios para antes y después del test o listas de comprobación para la evaluación heurística Determinar si se enfatizarán los datos cuantitativos o cualitativos Identificar las herramientas que se utilizarán durante el test Diseñar los formularios que se utilizarán durante el test • formularios para mostrar el consentimiento del participante • hojas de instrucciones • formularios para el registro PASO 3. EFECTUAR UN TEST PILOTO DE LOS PROTOCOLOS DE LA SESIÓN. Seguir el protocolo para etapas tempranas descrito con anterioridad Localizar los problemas descubiertos • problemas en el protocolo • problemas en las instrucciones y directrices • problemas en los formularios

74

PASO 4. CONDUCIR LAS SESIONES DE EVALUACIÓN REALES. Empezar registrando la sesión con una videocámara, orientándola de modo que se capturen las manos del usuario interactuando con el sistema Seguir el protocolo para la sesión Observar al participante a medida que evoluciona en sus tareas Registrar cualquier incidente crítico que tenga lugar y considerar proseguir, cuando ello ocurra, con una o dos preguntas abiertas Tras los incidentes de carácter negativo • ¿tiene algún problema? • ¿está bloqueado? • ¿necesita una pista? • ¿es ese el resultado que buscaba? • ¿resulta más difícil de lo que debería? • ¿qué piensa llegando a este punto? • ¿qué intenta hacer? • ¿qué cree que ocurriría? Tras los incidentes de carácter positivo • ¿se siente ahora más confiado? • ¿encontró alguna pista específica que le ayudara a resolver el problema? • ¿qué le hizo pensar que funcionaría esta aproximación? Tomar notas de forma cuidadosa en tiempo real, pues va a resultar más eficiente que haciéndolo de forma retrospectiva Agradecer y gratificar al participante. PASO 5. INTERPRETAR LOS DATOS REUNIDOS. Usar todos los datos reunidos para identificar los problemas de la interfaz. • Tasas de fallos en tareas en particular • Tiempos requeridos para determinadas tareas • Referencias no alcanzadas • Aspectos no verificados en las listas de comprobación para la usabilidad Caracterización de los problemas De acuerdo con la causa (si se conoce) De acuerdo con la frecuencia de ocurrencia De acuerdo con la severidad • Crítico. Los problemas críticos son aquellos que hacen imposible la conclusión de la tarea por el participante. El producto no puede ser distribuido, ni siquiera para un test beta. • Serio. Un mejor diseño hubiera evitado que el participante tuviera que sufrir serios problemas debido a algún error. El producto sólo puede ser distribuido para un test beta • Menor. Los problemas menores son los que llevan al participante a momentos de distracción, confusión o desorientación. El producto podría distribuirse entre los clientes si fuera necesario PASO 6. PREPARAR UN INFORME Proporcionar un resumen de los hallazgos, subtarea a subtarea, en una tabla bajo los siguientes encabezados:

75

• descripción de la tarea • estado de realización de la tarea a. tarea abandonada en ___ ocasiones después de ___ segundos (medio) y ___ errores (medio) b. tarea completada con éxito en ___ ocasiones después de ___ segundos (medio) y tras ___ errores (medio) c. si hay sospecha de desviaciones estadísticas, se habrán de calcular media y desviación estándar Efectuar un resumen en una tabla de los hallazgos relevantes si había requerimientos de usabilidad (para tareas y subtareas específicas), bajo los siguientes encabezados: • descripción general de la tarea o subtarea • referencia específica aplicada • peor realización aceptable para la referencia dada (en número de errores o tiempos máximos) • objetivos de realización planificados para la referencia dada (en número de errores o tiempos aceptables) • mejor realización posible para la referencia dada (en número de errores o tiempos mínimos) • realización observada para la referencia dada (en número de errores o tiempos reales) Si se hizo uso de la evaluación heurística, hacer un listado de las áreas del sistema donde el diseño no cumpla con las guías a aplicar. Efectuar un listado de los problemas expuestos durante el test en una tabla bajo los encabezados: • descripción del problema • severidad del problema • frecuencia del problema • posible remedio para el problema Listar los cambios requeridos por la interfaz en orden de prioridad, considerando que hay que dar una prioridad alta: • a los problemas más severos • a los problemas más comunes • a los problemas cuya localización resulta económica • a los problemas que pueden ser localizados rápidamente Cambios recomendados Revisar las grabaciones en vídeo de las sesiones y prepara una colección de secuencias para apoyar la solicitud o recomendación de cambios

76

ANEXO 2

¿QUÉ ES ESO LLAMADO USABILIDAD?.

Miguel Angel Sánchez elefónica Investigación y Desarrollo Grupo Factores Humanos

Resumen

En las últimas décadas el estudio de la interacción Hombre-Máquina ha cobrado especial relevancia.

¿Qué es eso llamado Usabilidad?

El estudio de la interacción Hombre-Máquina cobra una especial relevancia en el caso concreto de los sistemas informáticos y de telecomunicación. En las últimas décadas, el aumento de la población de usuarios potenciales y reales de este tipo de servicios, así como la creciente complejidad de estos y de las tareas que realizan, hacen del diseño centrado en el usuario uno de los factores clave en el éxito comercial de cualquier sistema o servicio que haya de competir en un mercado abierto. En este sentido, gran parte del trabajo realizado por los grupos de Factores Humanos que investigan en este área consiste en la recolección de datos empíricos tendentes a caracterizar y estimar la influencia que un determinado diseño ejerce en la capacidad del producto de ser usado fácil, efectiva y eficientemente por los usuarios especificados; es decir, en lo que se ha dado en llamar seguramente de una manera no muy afortunada, la usabilidad ("Usability") del desarrollo final.

Factores de usabilidad

La evaluación empírica de la usabilidad de cualquier producto, servicio o sistema informático o de telecomunicaciones conlleva toda una serie de problemas metodológicos, de los cuales el principal es la identificación y operativización de los factores fundamentales o índices que configuran este constructo teórico. Una revisión exhaustiva de la literatura de investigación sobre el tema nos permite identificar los siguientes factores de usabilidad:

· Capacidad de aprendizaje ("Learnability"): El tiempo y esfuerzo requerido para que un usuario alcance un determinado nivel de ejecución en un sistema dado.

· Rendimiento ("Throughput"): La velocidad en la ejecución de las tareas y el número y tipo de errores cometidos por el usuario en su realización.

· Satisfacción ("Satisfaction"): Medidas del confort la aceptabilidad y la actitud positiva generada por el servicio/sistema en las personas afectadas por su uso.

· Flexibilidad ("Flexibility"): La capacidad del sistema de poder trabajar con diferentes métodos en función del nivel de experiencia del usuario.

77

· Efectividad ("Effectiveness"): El grado de exactitud con que el sistema completa la/s tarea/s para las que esta diseñado

· Eficiencia ("Efficiency"): Hace referencia al número de pasos que el usuario debe llevar a cabo para completar la tarea

Medida de la usabilidad

A continuación, y como final de este breve apunte acerca de la usabilidad, presentamos el siguiente esquema, el cual resume los tipos de medida y los métodos de medición más comúnmente empleados en la evaluación de usabilidad. Hasta el próximo número.

A) MEDIDAS OBJETIVAS

A.1 MEDIDAS DE EJECUCION DE LA TAREA:

* Grado de exactitud en la ejecución de la tarea

* Tiempo empleado en acabar la tarea

* Tasa de errores

A.2 MEDIDAS PSICO-FISIOLOGICAS

* Tasa cardíaca

* Secreción de adrenalina

* Potenciales evocados

METODOS DE MEDIDA: Observación directa de la ejecución de la tarea, Registros audiovisuales, "Logfiles",ECG,GSR,ERP, Análisis bioquímicos

B) MEDIDAS SUBJETIVAS

B.1 MEDIDAS ACTITUDINALES Y DE OPINION:

* Satisfacción subjetiva del uso

* Confort

* Aceptación del sistema

78

* Estética del producto

* Esfuerzo empleado en la realización de las tareas

METODOS DE MEDIDA: Cuestionarios de opinión y actitud, Entrevistas, Observación participante, Autodescripción, "Rating-Scales"

79

CONCLUSIONES GENERALES

Después de haber profundizado en el tema, descubro que es mucho lo que se ha desarrollado, y que el problema es buscar las fuentes, lo cual realmente no es nada fácil. Otro elemento a tener en cuenta dentro de las conclusiones, es la facilidad con la cuál te puedes perder en el tema investigado, en donde pueden haber muchas cosas pertinentes, pero en algún momento se debe parar.... por lo cual muchas cosas no se encontrarán en este documento, pero dejo los hipervínculos para quien quiera profundizar, más aún cuando, parte de la información se encuentra en inglés, y el proceso de traducción es realmente dispendioso. Dentro de este acercamiento a los procesos de investigación, lo cual es solo un primer paso, como tantos otros precedentes, especialmente el de: Alejandro Floría Cortés (Febrero 2000). alejandrofc00@hotmail.com Área de Ingeniería de Proyectos. Departamento de Ingeniería de Diseño y Fabricación. Centro Politécnico Superior | Universidad de Zaragoza que inicia un camino hacia la traducción de material bibliográfico pertinente al tema, y lo más importante lo pone a disposición en la red, con lo cual el trabajo se puede socializar y convertirse en plataforma, para nuevas aproximaciones como la de este trabajo, que pretende mirar bajo este conocimiento como se puede traducir de una manera más generalizada hacia la investigación de la usabilidad en los objetos-producto, no solamente como herramientas asociadas al mundo del medio informático y como se pueden construir sistemas más coherentes de comunicación y de interfaz con las necesidades del usuario. Ya para terminar, referido al tema específicamente podemos concluir que tanto las metodologías como la teoría básica de aproximación a la usabilidad puede ampliarse a cualquier tipo de producto, dado que en últimas se actúa sobre el mismo problema: como caracterizar sistemas de comunicación y de interfaz para satisfacer a los usuarios o consumidores de productos, aprovechando al máximo tanto la tecnología como los medios que se tienen para lograrlo.

80

BIBLIOGRAFIA Bibliografía ] Alejandro Floría Cortés (Febrero 2000). alejandrofc00@hotmail.com Área de Ingeniería de Proyectos. Departamento de Ingeniería de Diseño y Fabricación. Centro Politécnico Superior | Universidad de Zaragoza. Bibliografía "User Centered Design in Practice - Problems and Possibilities" Jan Gulliksen, Ann Lantz and Inger Boivie. Technical report TRITA-NA-D9813, CID-40. http://www.nada.kth.se/cid/pdf/cid_40.pdf Royal Institute of Technology, Numeric Analysis and Computing Science. Centre for User Oriented IT Design. Participatory Design in Work Context: Why is it so hard to involve users? Anne-Laure Fayard. Artículo en "User Centered Design in Practice - Problems and Possibilities", perteneciente al informe anterior. Páginas de IDEO Product Development donde encontramos una amplia variedad de ejemplos de "smart products" [Servicio de certificación de la W3C] [Página de Bobby]

Calvino, Italo. Seis propuestas para el próximo milenio. Madrid: Siruela, 1996.

Galdo, Elisa del; Nielsen, Jakob. International user interfaces, NY: John Wiley & Sons, 1996.

Kundera, Milan. La insoportable levedad del ser. Barcelona: Tusquets, 1982.

Lewis, Lawrence. Code, and other laws of cyberspace. NY: Basic Books, 1999.

Marías, Julián. Cara y cruz de la electrónica. Madrid: Espasa-Calpe, 1985.

Shneiderman, Ben. "Universal usability". En: Communications of the ACM, 2000, vol. 43, n. 5, mayo, pp. 85-91.

Tognazzini, Bruce. "On walls and mouse holes: security and privacy". Ask Tog, noviembre, 1999.

[CURT94] Curtis, B., Hefley, B. "A WIMP No More. The Maturing of User Interface Design". Interactions, Enero, 1994, pág. 22-34.

[DRAY95] Dray, S. "The Importance of Designing Usable Systems". Interactions, Enero, 1995, pág. 17-20.

81

[KARA93] Karat, C-M. "Usability Engineering in dollars and cents". IEEE Software, Mayo, 1993, pág. 88-89.

[MYER92] Myers, B., Rosson, M. "Survey on User Interface Programming". Proceedings CHI'92, New York, ACM, 1992, pág. 195-202.

[MYER94] Myers, B. "Challenges of HCI Design and Implementation". Interactions, Enero, 1994, pág. 73-83.

[NIEL93a] Nielsen, J., "Is Usability Engineering really worth it?". IEEE Software, Noviembre 1993, pág. 90-92.

[NIEL93b] Nielsen, J. Iterative user-interface design". IEEE Computer, Noviembre, 1993, pág. 32-41.

[XBUS94] X Business Group, Inc. "Interface Development Technology". 3155 Keraney Street, Suite 160, Fremont, CA 94538, (510) 226-1975, 1994. Observación: esta bibliografía es la encontrada en las Fuentes de la web. OTROS: PAGE, Alvaro y otros. “Nuevas técnicas para el desarrollo de productos innovadores orientados al usuario”. IBV y ADCV. 2001. Valencia España. CAPUZ R., Salvador.” Introducción al proyecto de producción” Ingeniería concurrente para el diseño de producto. Universidad Politécnica de Valencia.1999. Valencia España.

82