Manual de T cnicas para el Dise o Participativo-usabilidad ... · I. Usabilidad y Diseño Centrado...

Manual de Técnicas para el Diseño Participativo de Interfaces de Usuario de Sistemas basados en Software y Hardware

Alejandro Floría Cortés Á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

Tomado de: http://www.usabilidad.org/usablog/2002_01_01_arch.shtml

Diciembre 2001

2

¿Qué es un Manual de Técnicas para el Diseño Participativo de Interfaces de Usuario de Sistemas basados en Software y Hardware?

• Manual de técnicas: la idea es una recopilación de herramientas. No se va a entrar a distinguir términos como "técnica", "método", "metodología" o "herramienta" (que los psicólogos y los pedagogos me perdonen): en general se hablará de un conjunto de procedimientos con un clasificación particular, respecto de los que se dará una explicación sobre en qué consisten, cómo se llevan a la práctica, cuáles son los beneficios y las limitaciones de su aplicación y cuál es el momento en el proceso de desarrollo en el que su uso es más apropiado.

• para el diseño participativo: es lo que en el ámbito europeo se conoce como diseño centrado en el usuario y, más concretamente, en el ámbito de la norma ISO 13407, como desarrollo centrado en el hombre. Va a tener sentido hablar de un conjunto de procesos de desarrollo centrado en el hombre que aportarán significado a las categorías en que se van a clasificar las herramientas.

• de interfaces de usuario de sistemas basados en software y hardware: lo que nos lleva a hablar de lo que la norma ISO 13407 define como sistema interactivo. Se dirá que un sistema interactivo es una combinación de componentes de hardware y software que reciben una entrada de, y comunican una salida a, un usuario para asistirle en la realización de una tarea.

Procesos de Desarrollo Centrado en el Hombre. A partir de ahora se hará referencia a los mismos como procesos DCH. Se procede a enumerarlos:

• DCH1 Asegurar el contenido DCH en la estrategia de sistemas • DCH2 Planificar y dirigir el proceso DCH • DCH3 Especificar los requerimientos organizacionales y de los

implicados • DCH4 Entender y especificar el contexto de uso • DCH5 Generar soluciones de diseño • DCH6 Evaluar los diseños contra los requerimientos • DCH7 Presentar y operar el sistema

En este punto, probablemente el lector ya habrá conseguido establecer una relación entre estos procesos y una categorización para las técnicas de diseño (indagación, concepto, categorización y prototipado, inspección, y test). Es claro que:

• DCH1 y DCH2 hacen referencia a la dirección y a la planificación • DCH3 y DCH4 exigen indagar y descubrir

3

• DCH5 sugiere desarrollar el concepto y las especificaciones del sistema y unificar el modelo mental de usuario y diseñador en un prototipo

• DCH6 plantea:¿tenemos lo que queremos?. Hay que inspeccionar, probar, testar, experimentar, obtener respuestas,...

• DCH7 hace referencia a las cuestiones hombres-sistema concernientes a la asistencia e implementación del sistema

Entonces, tendrá sentido hablar de técnicas para el diseño participativo en tanto que entendidas en los procesos de desarrollo centrado en el hombre DCH3 a DCH6

Documentos relacionados con USABILIDAD

PASTOR CASTILLO JAVIER. Desarrollo de prototipos virtuales de interface, paralelamente al prototipo físico en el proceso de desarrollo de productos. MESTRES XAVIER. Técnicas para el análisis de la experiencia de usuario. BEVAN NIGEL, KIRAKOWSKI JUREK, MAISSEL JONATHAN. What is Usability?

FLORÍA CORTÉS ALEJANDRO. La Usabilidad a través del diseño centrado en el usuario.

4

I. Usabilidad y Diseño Centrado en el Usuario 1.1 Usabilidad

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 usabilidad, la que nos interesa ahora.

Aceptabilidad de un sistema____________________________

� aceptabilidad social

� aceptabilidad práctica

• coste

• compatibilidad

• fiabilidad

• utilidad

- utilidad funcional

- usabilidad

• facilidad de aprendizaje

• eficiencia de uso

• facilidad para recordar

• pocos errores

• satisfacción (subjetivo)

Atributos de la aceptabilidad de un sistema (Nielsen, 1993)

En este punto, conviene señalar que se hablará de forma indistinta a lo largo de este documento de producto o sistema, entendido este como sistema interactivo,. En concreto, la norma ISO 13407 define sistema interactivo como una "combinación de componentes de hardware y software que reciben una entrada de, y comunican una salida a, un usuario para asistirle en la realización de su tarea."

Conviene, pues, empezar a plantearse una serie de preguntas:

• ¿Qué es la Usabilidad? • ¿Por qué es importante la Usabilidad? • ¿En qué momento se ha de considerar la Usabilidad? • ¿Cómo se puede definir la actitud de una organización hacia la Usabilidad? • ¿Cómo se puede conseguir un alto nivel de Usabilidad?

5

1.1.1 ¿Qué es la Usabilidad?

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).

• 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 tasa de errores del sistema y la facilidad del sistema para ser recordado (una asimilación inapropiada puede traducirse en errores de usuario).

• 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.

Aprendizaje (Learnability) El sistema debería ser fácil de aprender, de modo que el usuario pueda empezar a realizar algún trabajo con el sistema rápidamente Eficiencia (Efficiency) El sistema debería ser eficiente de usar, de modo que una vez que el usuario ha aprendido a manejarlo sea factible un elevado nivel de productividad Memoria (Memorability) El sistema debería ser fácil de recordar, de manera que el usuario no habitual sea capaz de volver al sistema después de un cierto tiempo sin usarlo, sin tener que aprender todo de nuevo Errores (Errors) El sistema debería tener una baja tasa de errores, de manera que los usuarios cometan pocos errores durante el uso del sistema y, caso de cometerlos se puedan recuperar con facilidad de los mismos. Por otra parte, no deben ocurrir errores catastróficos Satisfacción (Satisfaction) El sistema debería ser agradable de usar, de manera que los usuarios estén subjetivamente satisfechos cuando lo utilizan, que les guste...

Componentes de la Usabilidad (Nielsen, 93)

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 embellece.

6

• 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. El hardware y el software son las herramientas que ayudan a la gente ocupada a realizar su trabajo y a disfrutar de su ocio.

• Son los usuarios, y no los diseñadores y los desarrolladores, los que determinan cuando un producto es fácil de usar.

1.1.2 ¿Por qué es importante la Usabilidad?

El establecimiento de unos principios de diseño en ingeniería de usabilidad (Ver Tabla "Etapas del modelo del ciclo de vida de la ingeniería de la 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.

1. Conocer al usuario a. Características del usuario individual b. Tareas actuales y deseadas del usuario c. Análisis funcional d. Evolución del usuario y su trabajo. 2. Análisis de la competencia 3. Establecimiento de las metas de usabilidad a. Análisis de impacto financiero 4. Diseño paralelo 5. Diseño participativo 6. Diseño coordinado del conjunto de la interfaz 7. Aplicación de guías y análisis heurístico 8. Prototipado 9. Test empírico 10. Diseño iterativo a. Captura de los fundamentos del diseño 11. Reunión de retroalimentación del uso en campo

Etapas del modelo del ciclo de vida de la ingeniería de la usabilidad (Nielsen, 93).

• 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.

• 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.

• 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.

• Su mejor suposición no es lo suficientemente buena • El usuario siempre tiene razón

7

• El usuario no siempre tiene la razón • Los usuarios no son diseñadores • Los diseñadores no son usuarios • Los vicepresidentes no son usuarios • Menos es Más • Los detalles importan • La ayuda no lo es tanto • La ingeniería de la usabilidad es un proceso

Eslóganes de Usabilidad (Nielsen, 93). El objetivo es romper con mitos e ideas preconcebidas en los procesos de diseño.

1.1.3 ¿En qué momento 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.

1.1.4 ¿Cómo se puede definir la actitud de una organización hacia la

Usabilidad? A pesar de presentar los conceptos de Usabilidad y Diseño Centrado en el

Usuario como nuevos, es innegable que las organizaciones empiezan a detectar los problemas a los que hacíamos referencia en la introducción de este documento y en la medida de lo posible tratan de buscar soluciones a estos problemas con mayor o menor éxito. En general se hablará de niveles de madurez respecto de la usabilidad que vendrán caracterizados por la realización de unos procesos y el dominio de unas actitudes en el ámbito organizacional, tal y como podemos ver en las siguientes tablas.

Nivel Atributo No reconocido (no hay indicadores) Reconocido Reconocimiento del problema

Realización de procesos Considerado Conciencia de Calidad en el Uso

Enfoque en el usuario Implementado Participación del usuario

Tecnología de factores humanos Habilidades en factores humanos

Integrado Integración, mejora e iteración Institucionalizado Liderazgo centrado en el hombre

Organización en torno al hombre Niveles de madurez de los procesos centrados en el hombre (Usability Maturity Model: Human Centredness Scale; J. Earthy; Versión 1.2 27/12/1998)

Nivel Citas típicas No reconocido (Nivel X)

Ignorancia: "Nosotros no tenemos problemas con la usabilidad"

Reconocido Duda: "Desconocemos el motivo por el que tenemos problemas de usabilidad"

8

(Nivel A) Considerado (Nivel B)

Despertar: "¿Es absolutamente necesario tener siempre problemas con la usabilidad?"

Implementado (Nivel C)

Destacando: "Mediante el consenso en la dirección y la mejora de los procesos centrados en el hombre, estamos identificando y resolviendo nuestros problemas"

Integrado (Nivel D)

Prudencia: "La prevención de los defectos de usabilidad es parte rutinaria de nuestra operación"

Institucionalizado (Nivel E)

Certeza: "Sabemos por qué no tenemos problemas de usabilidad"

Indicadores de Atributos: Citas Típicas. (Usability Maturity Model: Human Centredness Scale; Annex 4; J. Earthy; Versión 1.2 27/12/1998)

1.1.5 ¿Cómo se puede conseguir un alto nivel de Usabilidad?

Adaptando el proceso de desarrollo a los principios del Diseño Centrado en el Usuario.

1.2 Diseño Centrado en el Usuario 1.2.1 ¿Qué es el Diseño Centrado en el Usuario?

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. Además, se contemplarán los aspectos de mantenimiento del producto o sistema, asistencia al usuario y documentación (Ver, por ejemplo, el anexo sobre Usabilidad de la documentación). En contraste, la expresión "diseño centrado en el uso", muy habitual en el ámbito bibliográfico y ante la que hay que prevenir al lector, 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 importante.

Además, en el estándar ISO 13407, de título "Human centred design processes for interactive systems" (Procesos de diseño centrado en el hombre para sistemas interactivos), se hace uso del término "centrado en el usuario". Sin embargo hay quien 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. Pero no nos confundamos.

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 este 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).

Otro significado, ciertamente más interesante y casi opuesto al mostrado anteriormente, de la expresión "centrado en el uso" es el de modos o posibilidades de uso. Así, en el estudio de una interacción particular producto - usuario se

9

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. Lo verdaderamente importante es, pues, el modo en el que el usuario interactúa con un producto y, en particular, con un prototipo, durante los diversos experimentos en el proceso de desarrollo.

Se podrían proponer cuatro principios básicos en la aproximación al Diseño Centrado en el Usuario: • La implicación activa de los usuarios y un claro entendimiento de los

requerimientos y tareas de usuario • Un reparto apropiado de funciones entre los usuarios y la tecnología • La iteración de las soluciones de diseño • Un diseño multidisciplinar

a. Usuario final b. Comprador, cliente, representante del usuario c. Especialista en el ámbito del sistema, analista de negocios d. Analista de sistemas, ingeniero de sistemas, programador e. Especialistas de mercado, comerciales. f. Diseñador de interfaz de usuario, diseñador visual g. Experto en ergonomía y factores humanos, especialista en la interacción

hombre - máquina h. Escritores técnicos, personal para entrenamiento, asistencia y

mantenimiento. que tal y como indica la norma ISO 13407 son los elementos caracterizadores de "la incorporación de una aproximación centrada en el hombre, de forma independiente del proceso de diseño, del reparto de responsabilidades y de papeles adoptados" que se manifiestan en un serie de actividades que empiezan con la formulación del concepto inicial del producto o sistema y se repiten de forma iterativa hasta que el sistema alcanza los requerimientos.

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 compleja 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 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 que en el viejo continente está ampliamente superada. Una perspectiva tan increíblemente amplia de los procesos de diseño y desarrollo de los que estamos hablando se traduce en multitud de conflictos potenciales entre todas las partes implicadas: directiva, diseñadores, usuarios,

10

clientes, expertos, distribuidores,... Es precisamente el análisis y solución de tales conflictos lo que verdaderamente preocupa a los grandes expertos en la materia a nivel europeo y en ello concentran sus esfuerzos. 1.2.2 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 (Ver Tabla "Decálogo de la Ergonomía") y de aquellos se derivan, en general, las guías de accesibilidad: • El control de la situación debe estar en manos del usuario: - Ha a 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. • 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. Decálogo de la Ergonomía 1. El trabajo, los productos y los servicios deben adaptarse al usuario, respetando sus limitaciones fisiológicas, psicológicas y sociales. 2. Siempre hay que tener en cuenta las diferencias poblacionales, la mejora para los extremos acostumbra a repercutir positivamente para toda la población. 3. El bienestar en el trabajo y el ocio no es fácilmente definible, es el punto de encuentro entre los requerimientos del producto y los deseos del usuario. 4. El usuario es creador; por lo tanto, hay que facilitar su creatividad mediante: - una interacción armónica con el entorno - una mejora en la seguridad en trabajo y ocio - una disminución de la carga física y nerviosa - la creación de puestos de trabajo con elevado contenido, reduciendo la

infracarga. 5. El buen funcionamiento del sistema se basa en unas buenas condiciones de trabajo y uso. 6. El bienestar en el trabajo y el ocio no es un lujo: es una necesidad. 7. El contenido del trabajo es también una parte de las condiciones del trabajo y repercute sobre la salud del usuario. 8. La participación de los usuarios en la organización del trabajo mejora el rendimiento de los sistemas productivos. 9. El usuario es el factor más importante en el diseño, montaje, funcionamiento, mantenimiento, uso y reciclaje de cualquier producto o servicio.

11

10. El análisis exhaustivo en la fase del proyecto de las capacidades fisiológicas, psíquicas y sociales de los usuarios repercutirá en una interacción armónica del sistema Hombre - Máquina que incidirá positivamente en la seguridad, la fiabilidad, la productividad, la calidad y el buen uso.

Decálogo de la Ergonomía. Rubén Rebollar. Ampliación de Proyectos (1996-1997). Área de proyectos del Departamento de Ingeniería de Diseño y Fabricación de la Universidad de Zaragoza • 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).

• 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. - 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. • 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 • 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. • 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 que se explicita, que se ha de reducir al mínimo necesario.

12

- 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.

• 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.

• 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. • Se distinguen cuatro partes en el proceso de diseño: - 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.

• Son indispensables las consideraciones de usabilidad en el proceso de

diseño: - 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. • Hay que entender al usuario : - 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 más apropiado o conseguir la información a través de una amplia gama de medios de representación.

13

- De la misma forma que ningún modo de representación se puede ajustar a todos los usuarios, ningún modo de expresión lo hará tampoco. La forma habitual de expresión ha sido texto impreso, pero otras opciones artísticas, fotográficas, musicales, el vídeo, la animación... resultan una exitosa forma de comunicar ideas para ciertos individuos. Es preciso asumir esta diversidad ofreciendo múltiples opciones para la expresión y el control. Las preferencias y necesidades particulares siempre encontrarán, así, medios, apoyos y opciones que permitan al usuario mostrar su conocimiento de la forma que les resulte más efectiva.

- No cabe la menor duda de que para abordar una tarea, sea el conocimiento y uso de un determinado producto en el contexto que nos ocupa, son precisas unas dosis adecuadas de confianza, entusiasmo e intencionalidad. La misma tarea que influye en el carácter competitivo y en la confianza de un usuario de forma positiva, puede llevar al aburrimiento y a la frustración en otros. La motivación puede venir porque la materia en cuestión resulta fascinante, constituye un reto, el proceso de aprendizaje resulta satisfactorio, la circunstancia de la novedad resulta muy atractiva, las posibilidades de mejorar en el desarrollo de la tarea son enormes por las características de los elementos involucrados, se puede establecer un paralelismo con la vida real. Así, las estrategias de aprendizaje deben soportar diferentes niveles de capacidad, preferencias e intereses, proporcionando opciones flexibles.

• Hay que realizar renuncias en el diseño - Cada aspecto adicional que se incluye en el sistema está afectando

potencialmente a la complejidad, estabilidad, mantenimiento, capacidad de acción, costes de apoyo,...

- 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.

1.3 Procesos para el Desarrollo Centrado en el Hombre

Dentro de la perspectiva genérica que se ha decidido adoptar en el enfoque

de la materia se puede entrar en una dimensión más práctica. Los principios de Diseño Centrado en el Usuario que se acaban de citar constituyen ya por sí mismos una herramienta interesante y la vigilancia de su cumplimiento puede aportar importantes beneficios a un diseño en curso. Sin embargo, tales consideraciones han de estar necesariamente enmarcadas en una filosofía más amplia, en un conjunto de procesos relacionados entre sí, fundamentalmente por la información que generan el modo en el que la gestionan. Asimilando la terminología de la norma ISO 13407 vamos a hablar de los procesos que corresponden a un desarrollo centrado en el hombre, tal y como muestra la siguiente tabla.

Procesos para el desarrollo centrado en el hombre (DCH)

DCH 1 Asegurar el contenido DCH en la estrategia de sistemas

14

DCH 2 Planificar y dirigir el proceso DCH

DCH 3 Especificar los requerimientos organizacionales y de los implicados

DCH 4 Entender y especificar el contexto de uso

DCH 5 Generar soluciones de diseño

DCH 6 Evaluar los diseños contra los requerimientos

DCH 7 Presentar y operar el sistema

Procesos para el desarrollo centrado en el hombre (DCH) (Usability Maturity Model: Human Centredness Scale; Annex 4; J. Earthy; Versión 1.2 27/12/1998)

Seis niveles de capacidad en la realización de los procesos

Nivel 0 Incompleto (incapaz de desarrollar proceso)

Nivel 1 Realizado (algunos individuos desarrollan procesos)

Nivel 2 Dirigido (los requerimientos en calidad, tiempo y recursos para cada proceso son conocidos y controlados)

Nivel 3 Establecido (el proceso se desarrolla tal y como se ha especificado por la organización y los recursos están definidos)

Nivel 4 Predecible (la realización del proceso entra dentro de los límites de calidad y recursos que se predijeron)

Nivel 5 Optimización (la organización puede ajustar de forma fiable el proceso a los requerimientos particulares)

Seis niveles de capacidad en la realización de los procesos (Usability Maturity Model: Human Centredness Scale; Annex 4; J. Earthy; Versión 1.2 27/12/1998)

De la misma forma que se habló de niveles de madurez respecto de la usabilidad con anterioridad, se puede hablar ahora, desde un punto de vista más práctico, de la capacidad de las organizaciones para llevar a cabo estos procesos, tal y como indica la tabla anterior. Los procesos en cuestión van a ser analizados seguidamente. 1.3.1 Asegurar el contenido DCH en la estrategia de sistemas (DCH 1)

El objetivo de este proceso es establecer y mantener un enfoque en los

aspectos relacionados con usuarios y demás implicados en cada parte de la organización que trata con los mercados, conceptos, desarrollo y asistencia al sistema.

Como resultado de una implementación exitosa de este proceso:

- el departamento de marketing tendrá en cuenta cuestiones sobre usabilidad, ergonomía y otros aspectos sociales y tecnológicos

- los sistemas se dirigirán a satisfacer las necesidades y expectativas de los usuarios

- la planificación original tendrá en cuenta los requerimientos de los implicados y de organización para el establecimiento de la estrategia de sistemas

- los sistemas serán admitirán más positivamente los cambios en los usuarios (necesidades, tareas, contexto,...)

- la empresa será más receptiva a los cambios en sus usuarios - los sistemas difícilmente serán rechazados en el mercado

Asegurar el contenido DCH en la estrategia de sistemas Entrada Salida Estrategia de la compañía Visión del sistema o producto

15

Encuestas de mercado Pronósticos tecnológicos Pronósticos expertos Metodologías de estrategia DCH

Especificación original Demandas sociales y sociotécnicas de los grupos objetivo Predicción de los contextos de uso Valoraciones sobre el estado del mercado Análisis de tendencias Proceso contable del sistema Estrategia de sistemas centrada en el hombre

Asegurar el contenido DCH en la estrategia de sistemas (Usability Maturity Model: Human Centredness Scale; Annex 2, Tabla 1; J. Earthy; Versión 1.2 27/12/1998) 1.3.2 Planificar y dirigir el proceso DCH (DCH 2)

El objetivo de este proceso es especificar el modo en el que las actividades centradas en el hombre encajan en el ciclo de vida del sistema completo y en la empresa.

Se ha de desarrollar un plan para especificar el modo en el que las actividades

centradas en el hombre se ajustan en el proceso global de desarrollo del sistema. El plan debería identificar: a. Las actividades del proceso de diseño centrado en el hombre: entender e

identificar el contexto de uso, especificar los requerimientos organizacionales y de usuario, generando prototipos y evaluando los diseños de acuerdo con los criterios de usuario.

b. Procedimientos para la integración de estas actividades con otras vinculadas al desarrollo del sistema; esto es, análisis, diseño y test

c. Los individuos y el responsable de la organizaciones u organizaciones para las actividades de diseño centrado en el hombre así como el espectro de capacidades y puntos de vista que proporcionan

d. Procedimientos efectivos para el establecimiento de retroalimentación y comunicación sobre las actividades de diseño centrado en el hombre en la medida en que afecta a otras actividades de diseño, así como los métodos para documentar estas actividades

e. Referencias apropiadas para la actividades centradas en el hombre integradas en el diseño global y el proceso de desarrollo

f. Espacios de tiempo apropiados que permitan que la retroalimentación, así como los posibles cambios de diseño, sea incorporada en la planificación del proyecto

Para dirigir el proceso de diseño iterativo, será preciso registrar los resultados de las actividades: • Hacer uso del conocimiento existente para generar propuestas con entradas de

carácter multidisciplinar • Concretar las soluciones de diseño a través de simulaciones, modelos,

maquetas,... • Presentar las soluciones de diseño a los usuarios y permitirles la realización de

tareas reales o simuladas • Modificar el diseño en respuesta a la retroalimentación del usuario hasta que se

alcancen las metas de diseño centrado en el hombre

16

Estos registros pueden ser completamente documentales o pueden incluir el artefacto de diseño, por ejemplo, algún prototipo de hardware o software. Incluye: a. Las fuentes del conocimiento existente y los estándares utilizadas, con una

indicación sobre cómo han sido incorporados (o porqué no han sido considerados, caso de que sea apropiado)

b. Los pasos adoptados para asegurar que el prototipo cubre los requerimientos clave y opera según un práctica correcta

c. La naturaleza de los problemas identificados y los cambios procedentes en el diseño

Como resultado de una implementación exitosa de este proceso, por otra

parte: - la planificación del proyecto permitirá la iteración y la incorporación de la

retroalimentación del usuario - se asignarán los recursos para una comunicación efectiva entre los

participantes del equipo de diseño (multidisciplinar) - se solucionaran los conflictos potenciales entre el concepto "centrado en el

hombre" - los procesos centrados en el hombre se incorporarán a los sistemas,

procedimientos y estándares de calidad - el concepto "centrado en el hombre" será apoyado y promovido dentro de la

organización 1.3.3 Especificar los requerimientos organizacionales y de los implicados

(DCH 3)

El objetivo de este proceso es establecer los requerimientos de la organización y demás partes interesadas en el sistema. Este proceso toma en consideración las necesidades, competencias y entornos de trabajo de cada implicado en el sistema de forma relevante.

Como resultado de una implementación exitosa de este proceso, se definirá:

a. Realización requerida del nuevo sistema frente a objetivos operacionales y financieros

b. Requerimientos legislativos o estatutarios relevantes, incluyendo seguridad y salud

c. Cooperación y comunicación entre usuarios y otras partes relevantes d. Los trabajos del usuario (incluyendo el reparto de tareas, el bienestar de los

usuarios y su motivación) e. La realización de tareas f. El trabajo de diseño y su organización g. La dirección y gestión de modificaciones, incluyendo entrenamiento y personal

implicado h. Viabilidad de la operación y del mantenimiento i. Diseño de la interfaz hombre - máquina y diseño del puesto de trabajo La especificación de los requerimientos organizacionales y de usuario deberían, además:

17

a. Identificar el rango de usuarios relevantes y demás personal implicado en el proceso de diseño

b. Proporcionar una situación clara en cuanto a las metas del diseño centrado en el hombre

c. Establecer prioridades apropiadas para los diferentes requerimientos d. Proporcionar un conjunto de criterios susceptibles de ser medidos contra los que

pueda ser testado el diseño en curso e. Confirmación por los usuarios o aquellos que representen sus intereses en el

proceso f. Incluir cualquier requerimiento legislativo o estatutario g. Estar debidamente documentados Especificar los requerimientos organizacionales y de los implicados Entrada Salida Perspectiva del proyecto Representantes del usuario Instrucciones de trabajo Legislación Estándares industriales Estrategia de sistemas Contexto de uso Sistemas competidores

Rango y relevancia de los usuarios y demás personal en el diseño Evaluación de riesgos Establecimiento de las metas de diseño centrado en el hombre Especificación de los requerimientos de usuarios y demás implicados Especificación de los requerimientos de organización Prioridades para los diferentes requerimientos Metas de usabilidad específicas y susceptibles de ser medidas Referencias contra las que testar el diseño Lista de requerimientos estatutarios o legislativos Fuentes de las que derivan los requerimientos de organización y de usuario

Especificar los requerimientos organizacionales y de los implicados (Usability Maturity Model: Human Centredness Scale; Annex 2, Tabla 3; J. Earthy; Versión 1.2 27/12/1998)

1.3.4 Entender y especificar el contexto de uso (DCH 4) El objetivo de este proceso es identificar, clarificar y registrar las

características de los implicados, sus tareas y el entorno físico y organizacional en el que el sistema operará.

La descripción del contexto de uso debería: a. Especificar el rango de los usuarios, tareas y entornos pretendidos en un detalle

suficiente para asistir la actividad de diseño b. Derivar de fuentes apropiadas c. Ser confirmado por los usuarios o, caso de no estar disponibles, por quienes

representan sus intereses del proceso. d. Estar adecuadamente documentada e. Ser puesta a disposición del equipo de diseño en intervalos de tiempo

apropiados y en formatos aptos para las actividades de diseño

18

Como resultado de una implementación exitosa de este proceso, se

conseguirá: - la definición de las características de los usuarios objetivo - la definición de las tareas que los usuarios han de realizar - la definición de la organización y el entorno en el que los sistema han de ser

utilizados - la disponibilidad del contexto de uso para su utilización de todos los puntos

relevantes del ciclo de vida

Entender y especificar el contexto de uso Entrada Salida Requerimientos del sistema Especificación de los requerimientos de usuario y demás implicados Especificación de los requerimientos de organización Perspectiva del proyecto Representantes de los usuarios Instrucciones de trabajo Tiempo y formato de la información sobre el contexto de uso que se proporcionará al equipo de desarrollo

Especificación del rango pretendido de usuarios, tareas y entornos Información sobre los implicados Información sobre el usuario Información sobre la tarea Análisis organizacional Fuentes de las que deriva la información sobre el contexto de uso

Entender y especificar el contexto de uso (Usability Maturity Model: Human Centredness Scale; Annex 2, Tabla 4; J. Earthy; Versión 1.2 27/12/1998)

1.3.5 Generar soluciones de diseño (DCH 5)

El objetivo de este proceso es el de generar potenciales soluciones de diseño a partir de la experiencia, los conocimientos de los participantes y los resultados del análisis del contexto de uso


- se considerará en el diseño el sistema completo con todos sus partes integrantes

- todos los componentes del sistema tienen en cuenta las características y necesidades del usuario

- las características y las necesidades del usuario serán tenidas en cuenta en el diseño del sistema

- se integrará en el sistema el conocimiento existente en disciplinas como ingeniería de sistemas, ergonomía, psicología cognitiva y otras de relevancia.

- la comunicación entre los implicados mejorará porque las decisiones en materia de diseño serán más explícitas

- el equipo de desarrollo tendrá la posibilidad de explorar diversos conceptos de diseño antes de optar por uno

- se incorporará en las etapas tempranas del proceso de desarrollo la retroalimentación procedente de usuarios finales y demás implicados

- será posible evaluar varias iteraciones de un diseño para diseños alternativos - se diseñará la interfaz entre el usuario y el sistema - se desarrollará el entrenamiento y la asistencia al usuario

Generar soluciones de diseño Entrada Salida Requerimientos del sistema Fuentes del conocimiento existente y de los estándares utilizados, con

19

Requerimientos de usuario y demás implicados Requerimientos de organización Contexto de uso Metas de usabilidad susceptibles de ser medidas Requerimientos ergonómicos Estándares y guías Pautas de estilo Experiencia previa Retroalimentación procedente de evaluaciones

una indicación sobre cómo han sido incorporados (o el motivo por el que no han sido seguidos, en caso de que resulte apropiado) Especificación de la interacción del usuario Detalle del diálogo, aspecto y sensaciones Disposición y otras cuestiones sobre interfaces de usuario Simulaciones de la especificación Prototipado del sistema o de alguna o algunas de sus partes Modelo de tareas Asignación de funciones Diseño de la operación del sistema Evidencia de la revisión conforme a los resultados de las evaluaciones Planificación del entrenamiento para usuarios y personal encargado de su soporte y mantenimiento Definición de la asistencia al usuario en relación al sistema Lista de estándares y modo en el que se han aplicado Justificación de las desviaciones de los estándares para llegar a requerimientos específicos Informe sobre el modo en el que los conflictos entre los requerimientos del diseño y los conocimientos previos fueron solventados en el diseño Mecanismos de retroalimentación y utilización de resultados en otras actividades de diseño Pasos seguidos para asegurar que el prototipo o prototipos cubrieron los requerimientos clave y operaron de forma apropiada

Generar soluciones de diseño (Usability Maturity Model: Human Centredness Scale; Annex 2, Tabla 5; J. Earthy; Versión 1.2 27/12/1998)

La utilización de simulaciones modelos, y maquetas y cualquier otra forma de

prototipo en general permite a los diseñadores una comunicación mucho más efectiva con los usuarios y reduce la necesidad y el coste del rediseño que puede ser preciso cundo los productos han de ser revisados con posterioridad, en algunos casos tras su lanzamiento y comercialización entre clientes reales.

Los beneficios son los siguientes:

a. Hacer las decisiones de diseño más explícitas (lo que capacita a los miembros del equipo a comunicarse entre ellos desde etapas tempranas en el proceso de diseño)

b. Permite a los diseñadores explorar diversos conceptos de diseño antes de optar por uno en particular

c. Posibilita la incorporación de la retroalimentación del usuario en la etapas tempranas del proceso de desarrollo

d. Posibilita la evaluación de diversas iteraciones de un diseño y de diseños alternativos

e. Mejora la calidad y el carácter de conjunto de la especificación funcional del diseño

1.3.6 Evaluar los diseños contra los requerimientos (DCH 6)

El objetivo de este proceso es el de reunir retroalimentación sobre el diseño

en desarrollo de los usuarios finales y otras fuentes representativas Como resultado de una implementación exitosa de este proceso:

- la retroalimentación proporcionada contribuye a la mejora del proceso - se evaluará si los objetivos sobre la organización y los implicados han sido

logrados o no - se monitorizará el uso a largo plazo del sistema

20

Caso de que el objetivo de la evaluación sea identificar mejoras en el sistema

(evaluación formativa), una implementación exitosa del proceso reflejará: - los problemas potenciales y la perspectiva en cuanto a las mejoras en:

tecnología, elementos de asistencia, entorno físico y organizacional y entrenamiento

- la opción de diseño que mejor encaja en los requerimientos funcionales, organizacionales, y de los implicados

- retroalimentación y requerimientos adicionales de los usuarios

Caso de que el objetivo de la evaluación sea el de comprobar si los objetivos han sido logrados (evaluación informativa) , una implementación exitosa del proceso reflejará:

- el modo en que el sistema logra las metas organizacionales - que un diseño particular cumple los requerimientos centrados en el hombre - una conformidad con los requerimientos nacionales, internacionales y/o

estatutarios

La evaluación, es un paso esencial en el diseño centrado en el hombre y debería tener lugar en todas las etapas del ciclo de vida del diseño. La evaluación puede ser utilizada para: a. Proporcionar la retroalimentación que puede ser utilizada para mejorar el diseño b. Evaluar si los objetivos organizacionales y de usuario han sido conseguidos c. Monitorización del uso a largo plazo del producto o sistema

En las etapa tempranas del proceso de diseño, el énfasis radica en la obtención de retroalimentación que puede ser utilizada para guiar el diseño, mientras que, más tarde, cuando se ha conseguido un prototipo más completo es posible medir si los objetivos organizacionales y de usuario han sido alcanzados.

En las etapas tempranas del proceso de desarrollo y el proceso de diseño, los cambios son relativamente baratos. Cuanto más haya progresado el proceso y cuanto más completamente está definido, más cara será la introducción de cambios. Así pues, es importante comenzar la evaluación lo más pronto posible..

Un plan de evaluación_______________________________________________

Debería desarrollarse un plan de evaluación que identifique los aspectos relevantes sobre: a. Las metas del diseño centrado en el hombre b. El responsable de la evaluación c. Las partes del sistema a ser evaluadas y el modo en el que han de ser

evaluadas, por ejemplo el uso de los escenarios de test, maquetas, prototipos d. El modo en el que va a ser realizada la evaluación y los procedimientos para

desarrollar los tests

21

e. Recursos requeridos para la evaluación y el análisis de los resultados y el acceso a los usuarios (caso que sea necesario)

f. Establecimiento de horarios sobre las actividades de evaluación y su relación con la planificación del proyecto

g. Retroalimentación y uso de los resultados en otras actividades de diseño

Las técnicas de evaluación varían en el grado de formalidad, rigor e implicación del usuario, dependiendo del entorno en el que la evaluación es conducida. La elección viene determinada por limitaciones financieras y temporales, la etapa en el ciclo de desarrollo y la naturaleza del sistema bajo desarrollo. Interesa proporcionar retroalimentación para el diseño________________

Las evaluaciones deberían tener lugar en todas las etapas en el ciclo de vida del sistema para influir en el sistema a generar. Las metas particulares de la evaluación debería reflejar un o más de los siguientes objetivos: a. Evaluar en qué medida el sistema el sistema alcanza los objetivos

organizacionales b. Diagnosticar problemas potenciales e identificar las necesidades para mejoras

en la interfaz, el material de asistencia, el entorno del lugar de trabajo o los objetivos de entrenamiento.

c. Seleccionar la opción de diseño que mejor se ajusta a los requerimientos funcionales y de usuario

d. Captar la retroalimentación y los requerimientos adicionales de usuario Información de los resultados_________________________________________

Con el propósito de dirigir y gestionar el progreso en el diseño iterativo, los

resultados de las evaluaciones deberían ser registrados de una forma sistemática. Conviene aportar evidencia apropiada de que:

a. Un número apropiado de usuarios tomaron partes en el test y que estos usuarios fueron representativos de aquellos identificados en el contexto de uso

b. Se testaron los objetivos centrados en el hombre más destacados c. Se utilizaron métodos básicos para el test y la reunión de datos. d. Se dio un tratamiento apropiado de los resultados de test e. Las condiciones del test fueron apropiadas

Se consideran tres tipos de información para la evaluación que pueden resultar de utilidad durante el proceso de diseño, dependiendo de si el propósito de la evaluación es proporcionar retroalimentación para el diseño, testar contra estándares específicos o proporcionar la evidencia de la consecución de las metas centradas en el hombre, por ejemplo, en términos de usabilidad o salud y seguridad de usuario • El informe de la retroalimentación hacia el diseño - debería tener lugar en un momento apropiado en el proceso de desarrollo

22

- debería basarse en fuentes apropiadas de evaluación (usuarios, revisiones de diseño,...)

- debería proporcionar retroalimentación de diseño en un formato que asista a las decisiones de diseño

- debería resultar en cambios visibles en el sistema, siempre que sea apropiado • El informe de los tests del diseño contra estándares específicos - debería identificar los estándares relevantes y proporcionar razones para su uso - debería proporcionar evidencia de que la evaluación fue conducida por una

persona competente haciendo uso de procedimientos apropiados - debería proporcionar evidencia de que un conjunto suficiente de partes del

sistema fueron testadas para proporcionar resultados significativos para el sistema como un conjunto

- debería informar sobre el modo en el que las no conformidades son tratadas en el diseño

- debería justificar cualquier desviación de los estándares aplicables • El informe del test de usuario - debería definir el contexto de uso utilizado para la evaluación - debería proporcionar información sobre los requerimientos organizacionales y de

usuario - debería describir el producto testado y su estado (prototipo en evolución) - debería describir las medidas realizadas, y los usuarios y métodos utilizados - debería contener los resultados con un análisis estadístico relevante - debería indicar la decisión de conformidad en relación con los requerimientos 1.3.7 Presentar y operar el sistema (DCH 7)

El objetivo de este proceso es el de establecer las cuestiones hombre - sistema concernientes a la asistencia e implementación del sistema.


- se considerará en el proyecto las necesidades de todos los implicados en el sistema

- se especificará la dirección y gestión de cambios, incluyendo las responsabilidades de usuarios y desarrolladores

- se dirigen los requerimientos de usuarios finales, encargados de mantenimiento y otros implicados

- hay consenso en cuanto a los procedimientos sobre seguridad e higiene - se consideran las variantes del sistema - se reúnen las reacciones de usuario y se informa de los cambios resultantes en

el sistema a los implicados

23

II. Métodos de Indagación en los procesos DCH

Introducción

En el capítulo anterior "Usabilidad y Diseño Centrado en el Usuario" hicimos una revisión de lo que habíamos venido a llamar procesos para el Desarrollo Centrado en el Hombre. Eran los siguientes:

• Asegurar el contenido DCH en la estrategia de sistemas (DCH 1) • Planificar y dirigir el proceso DCH (DCH 2) • Especifica los requerimientos organizacionales y de los implicados

(DCH 3) • Entender y especificar el contexto de uso (DCH 4) • Generar soluciones de diseño (DCH 5) • Evaluar los diseños contra los requerimientos (DCH 6) • Presentar y operar el sistema (DCH 7)

Los dos primeros procesos hacen referencia a cuestiones de gestión y

planificación de proyectos que quedan fuera de los objetivos de este documento. Vamos a centrarnos en los dos siguientes. El objetivo es el diseño de un sistema y queremos centrarnos en el hombre.

Corresponderá, por tanto, en primera instancia establecer los requerimientos

de la organización y demás partes interesadas en el sistema. Se habrá de tomar en consideración las necesidades, competencias y entornos de trabajo de cada implicado en el sistema de forma relevante. No es poco el trabajo que se plantea en este sentido. Ya se indicó que la especificación de los requerimientos organizacionales y de usuario deberían: h. Identificar el rango de usuarios relevantes y demás personal implicado en el

proceso de diseño i. Proporcionar una situación clara en cuanto a las metas del diseño centrado en el

hombre j. Establecer prioridades apropiadas para los diferentes requerimientos k. Proporcionar un conjunto de criterios susceptibles de ser medidos contra los que

pueda ser testado el diseño en curso l. Confirmación por los usuarios o aquellos que representen sus intereses en el

proceso m. Incluir cualquier requerimiento legislativo o estatutario n. Estar debidamente documentados

A priori, partiendo de la consideración de que no existe un historia de diseño como punto de partida, nos encontramos en la necesidad de descubrir, de

24

investigar, de indagar. En este punto hay una especial preocupación por el entorno organizacional, pero no se ha hecho aún referencia al sistema en sí.

Se precisa entonces de un nuevo proceso, mediante el cual se conseguirá

entender y especificar el contexto de uso con el propósito de identificar, clarificar y registrar las características de los implicados, sus tareas y el entorno físico y organizacional en el que el sistema operará. Estos resultados son especialmente interesantes para el equipo de desarrollo mientras que los relacionados con el anterior proceso corresponden en su análisis y gestión a la competencia de los órganos directivos.

El diseño participativo, el diseño centrado en el usuario, aboga por una

comunicación horizontal, dinámica, flexible y colaborativa entre los diferentes departamentos de las organizaciones, por lo que las aproximaciones que seguidamente se van abordar deberían ser llevadas a cabo por equipos multidisciplinares. Estas van a proporcionar resultados útiles para todas las partes y van contribuir a una mejor comprensión y entendimiento entre los distintos departamentos.

Las aproximaciones a las que se hace referencia son tres:

• una aproximación al contexto (de uso) • una aproximación a los grupos • una aproximación al individuo En los anexos de este documento se han incluido un conjunto de

"Formularios para el soporte del proceso de especificación de los requerimientos de usuario" y un conjunto adicional de "Métodos de análisis de usuario" más propios del ámbito industrial, que no hacen otra cosa que particularizar y matizar en determinados aspectos las técnicas que aquí se describen. 2.1 Aproximación al Contexto

Es preciso entender y especificar el contexto de uso para abordar un proceso de desarrollo centrado en el hombre. Como se ha indicado el propósito es el de identificar, clarificar y registrar las características de los implicados, sus tareas y el entorno físico y organizacional en el que el sistema operará.

Se van a contemplar, en general, dos perspectivas desde las que abordar

estos propósitos: • Las entrevistas de campo estructuradas

El objetivo es entrar en contacto directo con los implicados con el sistema en el contexto en el que interactúan con el mismo. Se hablará de una investigación o "indagación en el contexto". • La observación

Ante la posibilidad de perturbar la operación de los usuarios con el sistema se opta en ocasiones por un proceso de observación menos intrusivo con un enfoque particular en el aspecto etnográfico de la relación con el sistema. En esta línea, se hablará de:

25

- un estudio etnográfico u observación de campo, propiamente dicho - un estudio de campo orientado a la actividad, cuando se tiene un mayor

interés en las tareas que se están llevando a cabo 2.2.1 Indagación en el Contexto (Contextual Inquiry)

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 sobe 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 se puede llevar a cabo esta técnica?

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.

26

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 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 usarse 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!).

Esta técnica se usa con preferencia en las etapas tempranas del proceso de

desarrollo, dado que se obtiene una gran cantidad de información de carácter subjetivo—cómo se siente la gente en su trabajo, cómo fluye el trabajo o la información a través de la organización,X

27

2. 2. 2 Observación (Observation)

Los métodos de observación (en ocasiones también se habla de Observación natural (Naturalistic Observation)) consideran a un investigador que ve a los usuarios trabajar (un enfoque más etnográfico, por lo tanto) y toma nota de la actividad que tiene lugar (un enfoque más orientado a la tarea). La observación puede ser directa (encontrándose el observador presente durante la tarea) o indirecta (de modo que la tarea es registrada por medio de una grabadora de vídeo, por ejemplo)

Beneficios

• Esta técnica permite al observador advertir qué es lo que realmente hacen los usuarios en su contexto.

• La observación directa permite al investigador enfocar su atención en áreas específicas de interés.

• La observación indirecta registra la actividad que de otra forma no habría sido advertida o registrada.

Limitaciones

• La observación puede resultar molesta y los sujetos podrían alterar su comportamiento debido a la presencia del observador. la cooperación de los usuarios es vital, de modo que la habilidad del investigador en el trato con la gente es muy importante.

• Las anotaciones y la cinta de vídeo han de ser analizadas posteriormente, lo que llevará un tiempo, y, por otra parte, las tareas no pueden van a poder "fragmentarse" para su análisis por un determinado número de personas.

Beneficios y limitaciones de la aplicación de la técnica de Observación

Para llevar a cabo esta técnica, es preciso disponer de tiempo para el

análisis de los resultados de la observación. La observación indirecta requiere acceso a un equipo para la grabación y reproducción audiovisual. ¿Cómo se puede llevar a cabo esta técnica?

Podemos distinguir una serie de pasos básicos para la implementación de un proceso de estas características: 1. Establecer los objetivos y los requerimientos de información. ¿Se habrá de

realizar un cubrimiento en amplitud o en profundidad?. En este nivel, es extremadamente importante determinar lo que sucederá con el producto final de este proceso, para adecuar la totalidad de dicho proceso a los requerimientos de aquellos que recibirán los resultados.

2. Conseguir contactos, y en especial su cooperación con el proceso de observación que se está tratando de llevar a cabo. Hay que tener en cuenta que en determinados países, la ley prohibe la filmación en vídeo de las personas sin su consentimiento explícito por escrito.

3. Decidir la técnica de registro a utilizar. Se puede optar por anotaciones escritas, grabaciones de audio o grabaciones audiovisuales. Cuanto más completo sea el registro, más tiempo llevará su análisis. Es útil hacer una primera aproximación del análisis durante la observación.

4. Analizar, resumir e informar en relación a los objetivos establecidos en un principio.

De forma adicional, conviene tener en consideración las siguientes guías

prácticas: • Hay que asegurarse de que quien es observado sea consciente de la razón del

estudio (aportar mejoras) para que no haya interpretaciones negativas. Esto es

28

particularmente importante para usuarios ciegos o con una deficiencia mental, que pueden sentirse molestos por una presencia pasiva ante la que no se sienten seguros.

• Conducir una observación piloto para hacerse una idea de lo que se puede esperar, así como para comprobar las hojas de observación. Esto ayudará igualmente a estimar la duración de las sesiones. Si la sesión contempla actividades informales con los miembros del público, estos deben tener la oportunidad de mantener una conversación con el observador. hay que asegurar que habrá tiempo suficiente para que todas estas interacciones tengan lugar.

• Hay que intentar resultar lo menos molesto posible. • Anotar todos los acontecimientos que no se hayan entendido para tratar de

aclararlos con el usuario implicado tan pronto como haya terminado la sesión. • Hay que ser consciente de la cantidad de influencias que están afectando al

usuario. • Fotografiar si es posible el área de trabajo de los usuarios o el área de

operaciones, lo que actuará como recordatorio del contexto ambiental. • Tras las observaciones, anotar las primeras impresiones, antes de que el

análisis tenga lugar. ¿Cuándo debería usarse esta técnica?

Típicamente, las técnicas de observación son útiles en etapas tempranas de

la elaboración de las especificaciones para la obtención de datos cuantitativos así como para el estudio de tareas y procesos que están teniendo lugar.

2.2.2.1 Estudio Etnográfico/Observación de Campo (Ethnographic Study/Field Observation)

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. Entonces, el investigador va a adoptar una perspectiva en la misma línea que haría un etnógrafo. ¿Cómo se puede llevar a cabo esta técnica?

Para poner en marcha este procedimiento 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.

29

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".

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 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

Representación de los datos__________________________________________

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

30

- 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 usarse 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.

2.2.2.2 Estudio de Campo Orientado a la Actividad (Proactive Field Study)

Pensamos ahora, como anunciábamos en la descripción general de las técnicas de observación en un enfoque más orientado a las tareas ya la actividad. Inicialmente, de nuevo, hay que encontrar un grupo de usuarios representativos que puedan participar en el estudio de campo, concertando las citas y reuniones correspondientes en su lugar de trabajo.. Los aspectos a considerar en un estudio de campo de esta características incluyen : • Características del usuario individual, siendo las más destacadas

- experiencia laboral - nivel de estudios realizados - experiencia previa con el sistema en cuestión - entorno de trabajo, etc

31

Hay que identificar los aspectos del usuario que puedan influir en el uso del

sistema y, por tanto en el desarrollo de las tareas, para su control durante el estudio de campo. • Análisis de Tareas: las metas generales de los usuarios, la aproximación

actual a las mismas, el modelo de la tarea que los usuarios han desarrollado, los requerimientos de información y el modo en el que tratan con las circunstancias excepcionales y las emergencias.. El resultado típico de un análisis de tareas incluiría: - una lista de los requerimientos del usuario para adaptarse al sistema - toda la información que requieren para alcanzar sus metas - los pasos que han de ser llevados a cabo y la interdependencia de

estos pasos - los diversos resultados e informes que se han de generar como

consecuencia de la actividad del usuario - los criterios utilizados para determinar la aceptabilidad de estos

resultados - las necesidades de comunicación de los usuarios en la medida en

que intercambian información con otros usuarios mientras llevan a cabo las diferentes tareas o se preparan para ello.

• Análisis Funcional: se da un enfoque en las metas que los usuarios quieren

conseguir, pero sin mantener necesariamente los caminos que siguen los usuarios para proceder. Lo que se está intentando es proporcionar a los usuarios una herramienta poderosa que les permita realizar su trabajo más fácilmente. El análisis funcional debería coordinarse con un análisis de tareas de manera que los nuevos mecanismos para la realización de las tareas sean consistentes en la medida de lo posible con los procedimientos anteriores.

• La Evolución del Usuario: El uso del sistema afecta a los usuarios, y en la

medida en que cambian, harán uso del sistema de diferentes formas. Conviene, pues, estudiar el modo en el que los usuarios han evolucionado en el pasado a través del uso de sistemas parecidos. Un cambio típico es que los usuarios se convierten en expertos después de un tiempo y demandan cortos (también llamados aceleradores)

2.1 Aproximación a los Grupos El interés en la aproximación a los grupos es distintos al de la aproximación al contexto. La circunstancia de constituir un grupo, preferiblemente multidisciplinar, fuera del contexto de uso habitual y el modo en el que se van a relacionar durante determinadas sesiones los integrantes del mismo van a ser clave para la obtención de valiosa información cualitativa. Porque ahora ya no interesa tanto el modo en que los implicados con el sistema interactúan con el mismo como sus intereses, motivaciones, expectativas, deseos,... enfrentados a los de otros usuarios.

32

Así, una variante de la aproximación a los grupos se fundamenta en la filosofía de estímulo y respuesta, en la línea de las entrevistas, constituyéndose como elemento fundamental el moderador de la sesión de lo que llamaremos Grupos Orientado. Orientados, enfocados, hacia todos aquellos aspectos sobre los que el equipo de diseño necesita conocer más, bien en busca de criterios adicionales para su labor, bien en un planteamiento de innovación y creación. De forma más específica, se puede pretender que los grupos a los que hacemos referencia sirvan como fuente adicional de ideas que complementen la creatividad de los desarrolladores. Pueden llevarse entonces a la práctica sesiones de Brainstorming o bien aplicar técnicas más específicas al sistema para la generación de ideas. 2.3.1 Grupos Orientados (Focus Groups)

Los grupos orientados constituyen un método de investigación exploratoria utilizada para ayudar a las compañías a conseguir un entendimiento más profundo de las percepciones, sensaciones, motivaciones y deseos de sus clientes. Se trata de un medio apropiado para reunir información cualitativa de profundidad, como opiniones y actitudes.

Habitualmente, los grupos orientados se constituyen con entre seis y doce participantes reunidos en una discusión informal que dura entre una y dos horas. lo entrevistados son, en general, de características demográficas similares. los entrevistadores moderan la discusión según un perfil proporcionado o aprobado por el cliente. A menudo, representantes de asociaciones de consumidores observan las sesiones a través de espejos unidireccionales o circuitos cerrados de televisión. Estas sesiones son normalmente registradas en audio y vídeo para posteriores análisis.

Los grupos orientados constituyen un método altamente eficiente y relativamente barato para reunir información, en aproximadamente una hora es posible registrar las opiniones de más de media docena de personas. sin embargo, esta información no es objetivo, precisa, definitiva ni sirve de diagnóstico. Sin embargo, se pueden obtener perspectivas descriptivas, exploratorias, subjetivas y aproximadas. Estas sesiones van a proporcionar, por otra parte, controles de calidad y comprobaciones de la fiabilidad de la información.; los participantes tienden a proporcionar opiniones y balances de las opiniones de los demás.

Los grupos orientados van a constituir un forma amena de conseguir información. Sus más frecuentes aplicaciones van a ser: • Analizar las reacciones del consumidor objetivo • Explorar opciones, actitudes, preferencias acerca de productos y servicios, así

como la compra y uso de esos elementos. • Exploración de la reacción del cliente/usuario a los conceptos asociados a un

nuevo producto o servicio • Formulación de hipótesis que pueden ser comprobadas mediante encuestas

cuantitativas

33

• Búsqueda de las preguntas, vocabulario y percepciones de compradores y usuarios de una categoría del producto

• Entender las emociones del consumidor y sus procesos de pensamiento en relación a las decisiones de compra

• Entender las motivaciones inconscientes de los usuarios con respecto al producto y su promoción

Hay tres usos básicos para los grupos orientados. El primero, como método

autocontenido en estudios en los que constituyen la mayor fuente de datos. El segundo, como fuente suplementaria de datos en estudios que se basan en alguna otra fuente primaria de datos como pueda ser una encuesta. Finalmente, se utilizan, también, en estudios multimétodo que combinan dos o más medios de recolección de datos sin que un método primario determine el uso de los demás.

La manera apropiada de hacer uso de los datos obtenidos de los Grupos orientados es en conjunción con otras técnicas de investigación de mercado. Así, pueden ser utilizados para confirmar cifras o sugerir que los datos cuantitativos no levantan un elemento crucial que puede bloquear el éxito de un producto. Serán, pues, de especial utilidad • Cuando se necesitan perspectivas en estudios preliminares o exploratorios • Cuando hay una falta de comunicación o entendimiento entre grupos o

categorías de personas dentro de las diferentes ramas de una compañía • Cuando el propósito es el descubrimiento de factores relacionados con la

motivación o el comportamiento complejo • El investigador desea ideas que emerjan ideas del grupo • El investigador requiere de información adicional para prepara un estudio a gran

escala • Cuando se tiene un gran interés en capturar los comentarios abiertos del cliente

/usuario o de la audiencia objetivo en general

Beneficios

• la capacidad de generar cantidades de datos concentrados en el asunto de interés

• permitir a los participantes expresar detalladamente sus sensaciones, opiniones y actitudes

• descubrir los sentimientos y las motivaciones ocultas • resultan baratos en su implementación • permite a los comerciantes la provisión de mejores bienes y servicios • se aprende qué es lo que los consumidores opinan en el mundo real • ofrece un contacto inmediato con los clientes/usuarios • los participantes tiene reacciones inmediatas • es posible utilizar medios audiovisuales para el registro • es posible formular preguntas del tipo ¿qué pasaría si..?

Inconvenientes

• Número limitado de preguntas, aproximadamente diez a la hora • Presencia de un individuo dominante que da pocas oportunidades a los

demás de expresar sus opiniones. Un moderador puede animar a los demás a hablar, pero el individuo dominante puede resultar de difícil contención. Es precisa una gran habilidad por parte del moderador para conducir una sesión de forma efectiva y eficiente

• A menudo los grupos desarrollan personalidades positivas o negativas hacia un producto o concepto. Esto, desde luego, afecta a los resultados que se obtendrán, y el moderador debe intentar equilibrar esa polarización, lo que puede resultar una difícil tarea. Es aconsejable hacer uso de múltiples entrevistas de grupo para obtener un amplio rango de respuestas.

34

• Un moderador inexperimentado puede optar por solicitar respuestas individuales en lugar de permitir un flujo libre de opiniones. Esto anularía el propósito de los Grupos Orientados

• Basarse en comentarios aislados de individuos para confirma las decisiones es una práctica tan habitual como errónea

• El orden en el que los conceptos sean presentados al grupo afectará el modo en el que los miembros del mismo reaccionen. Es una buena idea alternar o intercambiar el modo en el que se presenta la información para obtener un resultado más equilibrado

• Los Grupos Orientados no son sustitutos de otras técnicas de investigación de mercado y tampoco deberían se retratados como tales. Las opiniones de los individuos no tiene porqué representar a la del total de la población

Beneficios y limitaciones de la aplicación de los Grupos Orientados

¿Cómo se puede llevar a cabo esta técnica?

Podemos distinguir una serie de pasos básicos para la implementación de un proceso de estas características 1. Decidir los objetivos de la sesión y los participantes requeridos para la misma. 2. Al contactar con los participantes, es preciso explicarles claramente los aspectos a considerar así como el formato de la reunión. Es preciso obtener también de antemano un acuerdo acerca de las técnicas de registro o grabación a utilizar (audio, vídeo,...). 3. Desarrollar un horario de la sesión y conducir una prueba piloto para comprobar que tal horario es realista. 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. 4. Durante la sesión, el moderador deberá participar activamente fomentando la discusión 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.

De forma adicional, conviene tener en consideración las siguientes guías prácticas • Crear una buena atmósfera. • Proporcionar a los participantes un formulario simple para completar con sus

detalles personales antes de que la reunión de comienzo. De esta forma se da comienzo a la actividad mientras en el último minuto se requiere alguna disposición adicional o algún participante llega tarde.

• Sugerir normas para el debate • Ayudar a los participantes en la formulación del problema y guiarlos siempre que

sea necesario • Evitar los comportamientos destructivos por parte de ciertos participantes • Proteger a aquellos individuos cuyas ideas y comentarios difieran de los de otros

en el grupo • No sugerir soluciones al problema • Evitar evaluar las soluciones propuestas • Asegurar que todos los participantes tienen la oportunidad de contribuir y que la

sesión no está dominada por ninguna persona o grupo.

35

Diez factores que van a influir en la Calidad de los Grupos Orientados • Claridad de propósito • Entorno apropiado • Recursos suficientes • Participantes apropiados • Moderador Hábil • Preguntas Efectivas • Gestión cuidadosa de los datos captados • Análisis sistemático y fiable • Presentación apropiada • Honrar al participante, al cliente y al método

Diez factores que van a influir en la calidad de los Grupos Orientados (Greenbaum, 1998)

Intervención

Cuando el grupo Debería Diciendo

Pretenda que usted conteste Devolverles la intención "¿Qué opinan?" "Buena pregunta. ¿Quién tiene una respuesta?"

Se desvíe de la cuestiones fundamentales

Ayudarles a volver a enfocarse en las mismas

"Volvamos a lo que nos ocupa. Usted trataba de decirnos algo ..."

Pierda el orden y hablen todos a la vez

Volver a establecer el orden "No interrumpa, Señor X, no tiene la palabra" "Un momento, de uno en uno. Adelante, Señora Y, después seguirá el Señor Z"

Parezca confundido o se aprecie una falta de claridad en la dirección a seguir

Hacerse el tonto "¿Me puede dar alguien una pista en este sentido?" "Estoy perdido. ¿Puede ayudarme alguien?"

Discute sobre los procesos Mediar "Se podría probar de las dos formas. ¿Con cuál empezamos primero?"

Pierde la motivación, el ánimo decae y la situación se enfría.

Aceptarlo, negociarlo, conceder un aplazamiento

"Vamos a darnos cinco minutos más sobre esta cuestión" "¿Les parece bien dejar para otro momento el resto de la agenda para concentrarnos en este aspecto?" "Creo que esta cuestión requiere más tiempo. ¿Qué les parece volver a tratarla el próximo día?"

Reta o provoca al moderador Permanecer en su papel, aceptar el reto, no ponerse a la defensiva

"Disculpe la interrupción, está en lo cierto. Continúe, por favor." "Está en lo cierto. Es lo más apropiado. "

Sobre la actitud del moderador ante el grupo (I) (Greenbaum, 1998)

Prevención

Para representar su papel como

Debería Diciendo

Participante neutral Mantenerse al margen de los contenidos

"No puedo llevar a cabo mi trabajo si tomo partido en cada cuestión." "Ustedes son los expertos. No yo." "En realidad, no tengo una opinión acerca de esto"

Motivador, promotor Mantener de forma continua una actitud positiva

"¿Cómo podemos ganar todos?" "Con el talento de este grupo..."

Monitor de procesos Sugerir procesos o reforzar los existentes

"Hasta el momento hemos estado hablando del producto. Pasemos ahora a los procesos"

Sobre la actitud del moderador ante el grupo (II) (Greenbaum, 1998)

El diálogo moderador - grupo en el desarrollo de los grupos orientados_____

El diálogo moderador - grupo en el desarrollo de los grupos orientados es un factor fundamental para el desarrollo de una sesión con calidad (Ver Tabla "Diez factores que van a influir en la calidad de los Grupos Orientados"). Por ello conviene tener en cuenta unas serie de técnicas para formular preguntas durante la sesión.

36

Igualmente, conviene mantener en consideración un conjunto de preguntas típicas para la variedad de situaciones a las que se enfrenta el moderador así como un conjunto de giros o elementos comodín que sirven de valiosa ayuda al moderador para mantener bien definida la dirección de los grupos (Ver tablas "Sobre la actitud del moderador ante el grupo").

Para el moderador debe resultar bien claro que:

1. Los participantes han de disponer del tiempo suficiente para contestar a lo que se ha preguntado. El silencio puede significar un valioso tiempo de maduración y razonamiento. Para evitar lapsos de silencio demasiado largos, se puede intentar:

a. Repetir la pregunta de otra forma. "¿Cómo he de hacer una pregunta cuando quiero que conteste una persona en concreto? (pausa) Si quiero que conteste una persona en lugar de cualquier otra del grupo, ¿cómo debería formular la correspondiente pregunta?" b. Seguir a la pregunta con un ejemplo o un escenario, para volver a repetir

entonces la pregunta "¿Cómo he de hacer una pregunta cuando quiero que conteste una persona en concreto? (pausa) Digamos que yo sé que el Señor Z tiene mucha experiencia con este proceso y quiero que explique el paso 2 de dicho proceso, ¿cómo debería formular la correspondiente pregunta?" c. Se puede formular inicialmente una pregunta de carácter común, para

pasar después a la que se considera como primordial. "¿Cuántos de ustedes han formado parte de un equipo de estas características? (se levantan manos) . De su experiencia, Señora Z, ¿cuales cree que son los valores más destacados?" d. Solicitar de los participantes que anoten sus contestaciones a la pregunta

que se formuló para recogerlas después. "¿Por qué piensan que los equipos llevan a cabo una mejor resolución de problemas que los individuos particulares?. Anoten un par de ideas y luego las discutimos.

2. Hay que aprender a formular preguntas no agresivas. Utilice frases del tipo "en su opinión...", "basándose en su experiencia...", "qué piensa acerca de..."

3. Conviene incluir escenarios o ejemplos dentro de las preguntas y, allá donde sea apropiado, se pueden utilizar a participantes como actores en el escenario de ejemplo. "Hablemos de los preparativos para una entrevista con los clientes. Supongamos que el Señor X es el cliente y la Señora Z, uno de los suministradores del Señor X, tiene concertada una entrevista con este para la próxima semana. ¿Qué aspectos creen que debería preparar la Señora Z para la entrevista?".

4. Hay que evitar referirse o basarse en unos pocos participantes. Si se basa en unos pocos participantes, el resto del grupo también lo hará, de modo que será difícil obtener información de ese sector de participantes. Es recomendable efectuar preguntas directas y mantener contacto visual con todos los participantes en la sesión.

37

5. Hay que mantener un carácter de conversación a la hora de formular las preguntas, haciendo uso de las respuestas de los participantes para formular más preguntas. Hay que escuchar cuidadosamente a todos los participantes y responderles de forma que indique que se les ha prestado toda la atención. Se pueden formular otras preguntas basadas en las respuestas de los participantes o bien usando las palabras que emplearon en dichas respuestas.

6. Hay que mostrar reconocimiento hacia toda respuesta, tanto si es incorrecta como si está fuera de lugar.

7. Hay que asegurar que las preguntas se formulan con claridad. Hay que añadir guías o pistas antes de introducir las preguntas que fomenten el inicio de la discusión "En un Grupo de Debate en el que se pretende una participación total, ¿por qué son las cuestiones abiertas tan importantes?"

Ejemplos Muestras

Para aclarar algún tipo de información o comentarios

• ¿Puede darnos un ejemplo de este punto de vista?

• ¿Cómo interpretaría o definiría este punto?

• ¿De qué forma difiere esta nueva política con la anterior?

Para mantener activo el intercambio de información y las idas y venidas de ideas entre los miembros del grupo

• Interesante observación, Señora Z. ¿Qué opina sobre ello, Señor Y?

• ¿Hay algún aspecto o cuestión adicional que debiera ser considerada?

• Ahora, que ya nos hemos centrado en la cara amable de la cuestión, ¿hay algún factor negativo que deba ser tenido en consideración?

Para mantener el debate sobre los objetivos

• Francamente interesante. ¿Puede establecer una relación con el aspecto inicial que nos ocupa?

• ¿Qué pregunta les había propuesto?

Para involucrar a los participantes pasivos

• Señora Z, en su experiencia como profesora, ¿cómo cree que afectaría este comportamiento a los demás estudiantes de la clase?

• Señor Y, díganos que opina.

• Señora X, ¿dónde ha visto que suceda esto?

Para considerar y evaluar la información

• A partir de esta información, ¿qué conclusiones podemos ir perfilando?

• ¿Se ajusta esta información de alguna forma a sus experiencias personales?

• ¿Justifican los hechos las conclusiones? ¿Por qué ? ¿Por qué no?

Para llevar la discusión al siguiente punto

• Ahora, ¿cómo se relaciona esta cuestión con la realización del trabajo?

• Ahora que hemos establecido las causas ¿cuál es el siguiente paso lógico?

Para determinar el nivel de entendimiento de la situación por los participantes

• ¿Cuál es el primer paso del proceso?

• ¿Pueden darme un ejemplo del segundo paso?

• ¿Cómo expresaría el tercer paso con sus propias palabras?

• Si tuviera que hacer frente a un problema de suministros, ¿cómo aplicaría entonces estos tres pasos?

• ¿Ha visto alguna vez un procedimiento de estas características en una situación no laboral?

• ¿Por qué es preciso seguir estos paso de forma secuencial?

Para llegar a un acuerdo, solución o conclusión

• ¿Qué conclusiones podemos perfilar de esta información?

• ¿Alguno de ustedes no está de acuerdo con lo que se ha dicho en este punto?

• ¿Qué tenemos por resultado final?

• Conseguida una visión de conjunto, ¿qué significa esto para nosotros como profesionales?

Algunas preguntas típicas en las situaciones más frecuentes en las que se encuentra el moderador (Greenbaum, 1998)

38

El éxito en el desarrollo de los Grupos Orientados________________________

El desarrollo de los grupos orientados es un procedimiento de gran desgaste que, en caso de tratar de eludirlo, puede provocar muchos problemas. Hay que tener siempre presente que: 1. Nunca se hace demasiado en el intento por planificar un Grupo Orientado.

El esfuerzo en la planificación de un grupo orientado se traduce siempre en un incremento de la calidad global a la salida del proceso. Esto incluye la consideración de los más apropiados parámetros de reclutamiento de participantes, el contenido y flujo de la discusión, y los estímulos externos de los que se hace uso para provocar reacciones entre los participantes.

2. Hay que dirigir la selección de participantes de forma activa para asegurarse de

la presencia de los individuos apropiados en los grupos. A pesar de las buenas intenciones que se tengan en el momento de reclutar

usuarios, es el moderador quien tiene la última responsabilidad sobre la calidad de los participantes. Dado que la calidad de los resultados de los grupos orientados depende de la presencia de los participantes apropiados, conviene centrarse en esta cuestión principalmente, estableciendo, además, una guía para la moderación y otra para la realización de informes.

3. No hay que prejuzgar a los participantes basándonos en su aspecto físico.

Idealmente, es deseable poder contar con gente correcta y educada como participantes en los Grupos Orientados, pero tal circunstancia no garantiza la reunión de información útil.

4. Los mejores moderadores de Grupos Orientados aportan objetividad y

conocimientos en el camino hacia la realización del proyecto. El conocimiento específico de un producto no debería ser un importante criterio

para la selección del moderador, dado que un profesional bien entrenado se tomará el tiempo preciso para aprender lo suficiente como para conducirse cómodamente en su tarea. Un moderador eficaz debe ser capaz de dirigir a los participantes a los aspectos de interés, debe escuchar pacientemente y con atención, interpretar los resultados de las sesiones y comunicar esos resultados de forma efectiva a los clientes. 5. La consecución de los objetivos de la investigación no garantiza el éxito en los

proyectos de Grupos Orientados. Algunos clientes sólo entienden los Grupos Orientados como una eficaz

herramienta que educa y entretiene. Otros tienen diferentes objetivos de investigación que han de ser acomodados antes de que el proceso se entienda como exitoso. Un moderador eficaz debe tener en cuenta estos aspectos para encontrarse con un cliente satisfecho a su vuelta. 6. El moderador y el usuario deberían coordinar sus esfuerzos en todas las etapas

del proceso para que la investigación alcance sus objetivos.

39

Para el moderador, esta cuestión incluye la obtención de datos de los clientes para elaborar la guía de moderación y discusión, así como trabajar con organizaciones vinculadas al cliente para desarrollar estímulos externos más efectivos.

También habrá de darse una comunicación regular entre el moderador y los

observadores del cliente, que podrían estar presentes en el grupo al otro lado de un espejo unidireccional y a los que se les podría proporcionar notas y observaciones durante el transcurso del grupo a intervalos regulares. Los observadores del cliente necesitan ser informados sobre el modo de trabajo más efectivo en colaboración con el moderador, de modo que durante la sesión del grupo orientado se emplee un tiempo mínimo en la transmisión de una máxima cantidad de información. 7. La mayoría de las organizaciones de usuarios realizan más grupos orientados

de los precisos para conseguir los objetivos de la investigación No hay una forma segura de determinar cuántos grupos orientados pueden ser

precisos en un programa de investigación. Conviene plantearse en desarrollar el número mínimo asumiendo la posibilidad de llevar a cabo otros adicionales si fuera preciso. 8. Uno de los mayores servicios que puede proporcionar un moderador es la rápida

presentación de un informe sobre la sesión. Debido a la naturaleza subjetiva de los grupos orientados, es habitual que los

observadores de los clientes generen diferentes interpretaciones de la información más importante que ha surgido durante la sesión.

Proporcionando a la organización del cliente un informe completo en los tres o

cuatro días posteriores al desarrollo de la sesión, las personas que asistieron a las sesiones podrán contar con la perspectiva del moderador rápidamente, de modo que podrán identificar a aquello con lo que están o no de acuerdo.

De forma adicional, cada uno de los observadores puede hacer uso del informe

del moderador para determinar la áreas de acuerdo o desacuerdo. Esto es realmente importante, dado que los hallazgos y conclusiones más recientes serán distribuidos a través de toda la organización. 9. Los observadores de los usuarios deberían estar bien informados de los

objetivos de la investigación antes de que de comienzo la sesión. Aunque la mayoría de los individuos que observan los grupos orientados

entienden el proceso, conviene revisar los objetivos de la investigación antes de proceder para asegurar que los observadores están de acuerdo con los objetivos y la salida deseada. 10. El servicio más valioso que puede prestar un moderador lo constituyen

conclusiones objetivas basadas en la interpretación de la investigación, de forma independiente de lo que los demás quieran oir Lo más fácil es dar a los clientes buenas noticias que confirmen sus creencias,

pero es un error tratar de endulzar las conclusiones para que el cliente no se

40

preocupe de los resultados de los grupos. Una investigación cualitativa habrá de ofrecer a lo clientes un a objetividad y una honestidad total para proporcionar la calidad de servicio y profesionalidad esperadas. Esta es una de las cosas más importantes que un moderador puede hacer por el cliente. La responsabilidad del moderador_____________________________________

La responsabilidad del moderador se limita a dos aspectos tan evidentes como fundamentales: • Mantener su informe intacto

El informe de un moderador no debe sufrir cambios ningún concepto:

- La investigación cualitativa es de naturaleza subjetiva, y no hay nunca una auténtica respuesta correcta. Los clientes deberían esperar que las personas interpretaran la información de forma diferente, y darse cuenta de que los grupos orientados no son en absoluto procesos destructivos, sino que proporcionan un vehículo para buenas comunicaciones.

- Las organizaciones deberían contratar a un moderador externo, tanto por su profesionalidad como por su objetividad. Un moderador jamás deberá tener interés particular en el resultado de un grupo orientado, de modo que habrá de interpretar la información desde su propia perspectiva.

- Precisamente porque el cliente es quien la paga la factura, tal circunstancia no le hace más cualificado para interpretar los hallazgos en una sesión de grupos orientados. Algunos clientes tiene la sensación de que están pagando por un informe que se ajuste a lo que ellos piensan, en lugar de una evaluación independiente del asunto en cuestión.

• Establecer un compromiso adecuado

Los grupos orientados jamás generan una respuesta absolutamente correcta. Siempre habrá lugar para un desacuerdo razonable y saludable. Sin embargo, en vista de la responsabilidad del moderador respecto de la responsabilidad y la propiedad del informe, es preferible no solucionar estas diferencias introduciendo cambios en el resumen del documento. Cliente y moderador deben establecer un acuerdo al principio del proyecto en el que se establezca el modo en que se gestionarán las posibles diferencias entre las partes. Una variante de los Grupos Orientados: los Grupos de Debate (Group Discussion/Future Workshops)_______________________________________

Los grupos de debate se basan en la idea de la discusión entre los implicados en el proceso de diseño de nuevas ideas, opciones de diseño, costes y beneficios y otros aspectos relevantes al proceso de diseño. Los grupos de debate contribuyen al resumen y organización de las ideas e información manejada por cada individuo. La idea general es que cada participante pueda estimular y proponer ideas, en presencia de los demás, lo que mediante un proceso de discusión y debate, establece la visión colectiva, mucho más amplia que la de las partes individuales. El

41

moderador, básicamente, habrá de asegurarse de que la reunión se enfoca en los aspectos de interés.

Frecuentemente se hablará de forma indistinta de Grupos Orientados y de

Grupos de Debate, si bien en la variante la participación suele ser más amplia (más aspectos, más creatividad, generación de ideas) y el papel del moderador tiene un carácter más administrativo que de entrevistador (en tanto que busca una respuesta a través de un estímulo)

2.3.2 Brainstorming y otras técnicas utilizadas para la generación de ideas

El brainstorming es una de las muchas aproximaciones contextuales por grupos, probablemente la más antigua y la más conocida. La idea es establecer un grupo multidisciplinar en la fase de generación de ideas del proceso de resolución de problemas. El brainstorming se utiliza para generar nuevas ideas, liberando la mente para aceptar cualquier idea que se proponga, permitiendo, así, la libertad para la creatividad. Este método se ha utilizado con amplitud en los procesos de diseño. El resultado de una sesión será un conjunto de buenas ideas, y un sentimiento general de haber resuelto el problema La combinación con otros métodos de grupo servirá para destacar los logros obtenidos en estas sesiones. ¿Cuándo debería usarse esta técnica?

Esta etapa se aplica típicamente en las etapas tempranas del proceso de desarrollo, cuando se conoce poco acerca del diseño real y hay necesidad de nuevas ideas.

Beneficios

• El conjunto del proceso se va a percibir en general como gratificante, generando un sentimiento de propiedad sobre el resultado. En este proceso, cada uno en el grupo puede atribuirse el mérito de las buenas ideas.

• No se tarda mucho en obtener resultados positivos, siendo suficiente, en general, una hora de duración para la sesión.

Limitaciones • Existen una gran cantidad de estudios que analizan la eficiencia del método, y

la mayoría de tales estudios muestran que las personas que trabajan solas producen más y mejores ideas que cuando participan en un grupo.

Beneficios y limitaciones de la aplicación del Brainstorming

Los recursos humanos son el factor más importante para tener éxito con este método. Cuantas más personas creativas con diversas experiencias en la materia participen, mejor será el resultado. Se puede considerar un rango de entre cinco y doce personas. ¿Cómo se puede llevar a cabo esta técnica?

Podemos distinguir una serie de pasos básicos para la implementación de un proceso de estas características 1. Decidir los objetivos de la sesión y los participantes requeridos para la misma. 2. Al contactar con los participantes, es preciso explicarles claramente los aspectos

a considerar así como el formato de la reunión. Es preciso obtener también de

42

antemano un acuerdo acerca de las técnicas de registro o grabación a utilizar (audio, vídeo,...).

3. Desarrollar un horario de la sesión y conducir una prueba piloto para comprobar que tal horario es realista. 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.

4. Durante la sesión, el moderador deberá participar activamente fomentando la discusión 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.


prácticas • no permitir la crítica de ideas durante la sesión • fomentar la expresión de muchas ideas • aceptar cualquier idea por irrelevante que parezca • formular las ideas de forma corta y precisa • tratar de combinar y mejorar las ideas de otros

43

• Ejemplo: mejorar una grúa. ¿Cómo surgen las posibilidades? Perfeccionar grúa Cambiar características grúa Movimiento Alcance Alterar el brazo

Combinar brazo y torre

Alterar torre

Otras ideas

Movimiento En el lugar

Durante el levantamiento

Entre lugares

Velocidad y capacidad

Programación

Control Operador Posición

Automático Conexión por radio

Visión

Acceso

Estabilidad Viento

Equilibrio de pesos

Soporte en tierra

Torre + brazo

Cargas Uniones

Tipos e carga

Enganche

Coste Materiales

Otras ideas

Otras características

Sustituir la grúa Varios mecanismos

Helicóptero

Transportador

Aerodeslizador

Escalera móvil

Cambiar entorno de la grúa Cambiar método de construcción Elevar edificio con gato

Configuración de materiales

Cambiar diseño edificio Construir bajo suelo

Materiales más ligeros

Partes estandarizadas

Planta única

Otras ideas

Combinar grúa y otros mecanismo Con montacargas o ascensor

Con andamios

Con excavadora

Con otros mecanismos

44

Continuar lo precedente

Otras técnicas relacionadas con la generación de ideas____________________ • Técnica de "Los Cinco ¿Por qué?" (Five "Whys")

Se pregunta ¿Por qué?. Será esa la clave para encontrar la causa (o causas) raíz de un problema. Esta técnica puede ser utilizada para estimular la comprensión del modo en el que diferentes causas pueden estar relacionadas. Otra ventaja del uso de esta técnica es el enfoque en el proceso de interés en lugar de las personalidades implicadas en el mismo.

Se ha de describir, entonces, el problema en términos específicos y todos deben tener una oportunidad para contribuir con sus opiniones. Hay que ser específico en la elección de las palabras para contribuir a que todos se sientan integrados y formando parte del procedimiento.

Entonces se pregunta ¿Por qué? ¿por qué ocurrió el problema?. Previsiblemente, la pregunta habría de ser contestada más de una vez y se preguntará "¿Por qué?" hasta que las causas raíz hayan sido identificadas. Se entenderá que tal cosa ha sucedido en el momento en el que las respuestas no aporten ninguna información adicional

Los miembros de un equipo quieren determinar el motivo por el que no

consiguieron la capacidad de operación requerida antes de una determinada fecha y, para ello, siguen el planteamiento que explicado: "No somos operativos" ¿Por qué? "No se cumplió la fecha de llegada prevista de los sistemas contratados" ¿Por qué? "Hubo muchos cambios técnicos " ¿Por qué? "El proveedor no entendió nuestros requerimientos iniciales" ¿Por qué? "Tan solo empleamos una semana para prepararlos"

Los miembros del equipo descubrieron que una pobre planificación de

requerimientos fue la causa raíz del problema. Para mejorar su proceso, decidieron contemplar un tiempo adicional en el proceso de planificación para el análisis de requerimientos. • Imagen Mental (Mental Imaging)

Esta técnica se fundamenta en la idea de que para conseguir las metas deseadas, hay que visualizar su consecución. La imagen mental ayuda a describir el resultado deseado y las condiciones requeridas para que tenga lugar. Los atletas

45

profesionales hacen uso de esta técnica en los instantes previos al inicio de la competición. Este proceso se utiliza para visualizar relaciones clave y los obstáculos en el marco de una situación particular. Se da comienzo algo visualizando agradable y vaciando la mente de pensamientos negativos. Se procede entonces como sigue: - Relajación: es fundamental dar comienzo liberado de presiones, dado que,

de otra forma, el procedimiento fracasará. - Imaginar: ¿Qué ocurriría si existieran las condiciones ideales? ¿Cómo

afectaría tal circunstancia al resultado de los procesos? En este punto conviene empezar a anotar las ideas. Si se forma parte de un grupo, se puede hacer uso de las ideas individuales para generar una descripción combinada del proceso ideal.

- Evaluar las condiciones actuales: ¿Son las condiciones actuales diferentes de las condiciones ideales imaginadas?

- Definir los huecos: ¿Cuáles son las diferencias entre las condiciones actuales y las corrientes?

- Identificar los obstáculos: ¿Qué tenemos entre el estado actual y el estado ideal que ha sido imaginado?

• Técnica del Sitio Web Aleatorio (Random Website Technique)

Se trata de acudir a un sitio web elegido al azar del que se extraen todas las ideas posibles. No importa que el contenido o la intención del sitio sean diferentes a las que se pretenden para el diseño, cualquier novedad ha de servir como estímulo. Se han de generar, pues, nuevas ideas y soluciones. Se trata de reorientar y de reaplicar. • Técnica de la Regla Falsa (False Rule Technique)

Se aplica una regla de un contexto ajeno o extraño y se trata de aplicar a la situación o contexto de interés. Esto permitirá el planteamiento aspectos novedosos y se desarrollan perspectivas bien distintas a las habituales.

Se aplica la regla de forma directa y se formulan diversas preguntas: - ¿dónde nos lleva la aplicación de la regla? ¿qué ideas se pueden

extraer de la aplicación de la regla? - ¿por qué existe la regla en el contexto en que es válida? ¿existe

algún concepto o aspecto análogo en el contexto de interés? - ¿qué beneficios aporta cumplir la regla en el contexto de origen? ¿se

pueden efectuar planteamientos similares en el contexto actual? • Técnica de la Representación (Role Play Technique)

Se trata de buscar una perspectiva radicalmente distinta desde la que afrontar los problemas. Se trata de ponerse en el lugar de un determinado sujeto, con un determinado perfil y una determinada ocupación laboral. En tal actitud se puede disponer, incluso, un equipo, que se plantea:

- ¿Qué pensarían? - ¿Qué aspectos y objetos usarían?

46

- ¿Dónde lo harían? - ¿Cómo entenderían el problema? - ¿Qué acciones llevarían a cabo? - ¿Cómo explicarían el problema? - ¿Cómo resolverían el problema?

• Técnica de la Búsqueda y la Reaplicación (Search and Reapply Technique)

Hay que fijarse en áreas de conocimiento bien distintas a la del dominio de interés, buscando el modo en el que se ha resuelto un problema o cuestión de características similares, para extraer ideas que pueden ser de aplicación en el caso actual.

- ¿Quién más ha resuelto esta cuestión? - ¿Qué área de conocimiento afín ha resuelto esta cuestión? - ¿Hay alguien en el equipo que sepa cómo resolver este problema? - ¿Qué más cosas podemos tener en cuenta para resolver el

problema? - ¿En qué otros sitios se ha resuelto este problema? - ¿Qué otras compañías pueden resolver este problema? - ¿Qué otros problemas similares han sido resueltos y cómo? - ¿Qué otras industrias han afrontado los mismos problemas y qué han

hecho? • Técnica de los Retos (Challenge Facts Technique)

El estado de las cosas es cambiante. Se piensa de forma diferente a medida que se gana en conocimiento y en habilidad a la hora de pensar. ¿Cómo saber que lo que se ha considerado como una cuestión del pasado ya no es apropiada debido a los cambios que han sucedido desde entonces? ¿Sería posible mejorar ahora el sistema actual siguiendo un cambio de los valores humanos o los estilos de vida? • Técnica de la Palabra Aleatoria (Random Word Technique)

La idea es tratar de abordar el problema desde una dirección radicalmente diferente a la actual, sugerida por una palabra aleatoria • Técnica SCAMPER (Substitute, Combine, Adapt, Modify/distort, Put to other

purposes, Eliminate, Reverse) - Substitute (Sustituir)

- ¿Qué puedo sustituir para introducir mejoras? - ¿Cómo puedo sustituir locales, tiempo, materiales y personas?

- Combine (Combinar)

- ¿Qué materiales características, procesos, personas, productos o componentes puedo combinar?

- Adapt (Adaptar) - ¿Qué parte del producto podría cambiar?

47

- ¿Con qué la podría intercambiar? - ¿Qué ocurriría si modificara las características de un componente?

- Modify/Distort (Modificar/Distorsionar) - ¿Qué ocurrirá si modifico o distorsiono alguna característica o

componente? - ¿Qué ocurrirá si modifico el proceso de alguna otra forma?

- Put to other purposes (Plantear otras posibilidades) - ¿En qué otro mercado podría introducir el producto en cuestión? - ¿Qué o quién sería capaz de usarlo?

- Eliminate (Eliminar) - ¿Qué ocurriría si eliminara una componente o parte del producto? - ¿De qué otra forma conseguiría la solución sin seguir la forma

habitual de proceder? - Reverse (Invertir)

- ¿Qué ocurriría si procediera de forma opuesta? - ¿Qué ocurriría si invirtiera el orden en el que se procede o el modo en

que se usa? • Técnica de la Evasión (Escapism Technique)

Se proponen las ideas y los conceptos más extravagantes e increíbles sin límites legales, morales, de estándares o etiqueta,... Por ejemplo: >>Evitar asaltos a los hogares >>Utilizar plátanos >>> las pieles de plátano son resbaladizas y (en teoría) difíciles de coger >>> Se piensa en un cierre que gire libremente excepto cuando se hace uso de un dispositivo, único para cada puerta, que posibilita de forma exclusiva la apertura del mismo • Técnica de la Analogía (Analogy Technique)

Se efectúan planteamientos basados en la búsqueda de analogías: - ¿A qué otra situación, contexto, entorno,... nos recuerda la cuestión

que nos ocupa? - ¿Qué otros campos experimentan situaciones similares? - ¿Quién procede de forma similar en distintas áreas de conocimiento?

• Técnica del Dibujo Aleatorio (Random Picture Technique)

La idea es la misma que la asociada a la técnica de la palabra aleatoria 2.4 Aproximación al Individuo

La aproximación al individuo recoge un obvio interés por las actitudes, percepciones y motivaciones individuales de los usuarios. Se pretende ahora profundizar en matices y particularidades. La confrontación y generación de ideas que se buscaban con anterioridad han podido limitar la expresividad de algunos usuarios. Mediante una aproximación al individuo se busca un mejor entendimiento

48

del modelo mental de los usuarios y los implicados en general que con las aproximaciones anteriores ya se había comenzado a perfilar.

Son tres las técnicas fundamentales para afrontar esta nueva perspectiva:

- Encuestas (surveys) - Cuestionarios (questionnaires) - Entrevistas (interviews)

Las encuestas consisten en entrevistas con los usuarios en las que se formulan un conjunto de preguntas y se registran las respuestas. Las encuestas, por otra parte, 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.

En las entrevistas (one-to-one interviews) de forma similar a los Grupos

Orientados, rige la filosofía de estímulo y respuesta (Stimulus & Response). De hecho es frecuente ver unidas ambas técnicas en algunas recopilaciones de técnicas de usabilidad y diseño centrado en el usuario. Además los procedimientos de los entrevistadores son bien similares a los empleados por los moderadores en las aproximaciones a los grupos, por lo que no se profundizará en esta línea

Los cuestionarios, por otra parte, 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.

Cuestionarios y encuestas, entonces: • se llevarían a cabo de la misma forma

Se comienza formulando preguntas acerca del producto basadas en el tipo de información que se quiere conocer. Entonces, tan sólo hay que solicitar a los usuarios que respondan estas preguntas. • se utilizarían entonces con un mismo propósito:

Estas técnicas pueden ser utilizadas en cualquier etapa del proceso de desarrollo, dependiendo lógicamente, de las preguntas que se formulen. A menudo, cuestionarios y encuestas son utilizados una vez que el producto ha sido lanzado con el objetivo de mejorar la satisfacción el cliente respecto del mismo e identificarán a menudo determinadas cuestiones de usabilidad que deberían haber sido captadas con antelación antes de que el producto fuera lanzado al mercado. 2.4.1 Los cuestionarios

Los cuestionarios son esencialmente resúmenes de lo que los individuos han dicho, hecho o pensado. Con mayor rigor, podríamos decir también que: un cuestionario es un conjunto formalizado de preguntas para la obtención de información de quien responde al mismo. Son, entonces, tres los objetivos básicos:

49

- Traducir la información que se necesita en un conjunto de preguntas que los participantes pueden contestar y van a contestar.

- Motivar y animar a los participantes para que se involucren, cooperen y completen la entrevista.

- Minimizar los errores de respuesta Un cuestionario proporciona un mecanismo estructurado para la reunión de

información. Es posible hacer la misma pregunta de la misma forma a un número de informantes. Esto va a permitir el uso de análisis estadístico de los datos, lo que permite una organización y resumen conveniente de grandes cantidades de información. Un cuestionario puede ser construido para investigar la experiencia de un usuario con un producto, su necesidad de un nuevo producto, la relación del usuario con la tecnología que utiliza etc. un cuestionario típico consiste en un número limitado de preguntas con categorías de respuestas predefinidas enfocadas en el asunto de interés. También puede constar de algunas preguntas abiertas, donde los participantes contestan con sus propias palabras. los cuestionarios son habitualmente distribuidos entre una muestra de la población objetivo y las respuestas son reunidas y resumidas mediante análisis estadístico. Los cuestionarios también pueden ser utilizados en entrevistas, donde un entrevistador lee las preguntas y completa las respuestas por el sujeto participante

Los cuestionarios pueden variar en la medida en que están estructurados, resultando probablemente los cuestionarios estructurados a utilizar por correo postal los que pueden aportar una mayor cantidad de información útil en una fase de indagación. Los cuestionarios estructurados son útiles para la obtención de información simple, más que para captar opiniones complejas, pues a los participantes se les solicita que respondan de forma sencilla a las preguntas o bien elijan entre un conjunto de posibles respuestas.

Hay tres tipos básicos de cuestionarios:

• Cuestionarios de hecho Estos cuestionarios preguntan por información pública y observable que

resultaría de captación larga y tediosa mediante cualquier otro mecanismo. Por ejemplo, el tiempo, en años, que el participante ha estado trabajando con un determinado sistema, el tipo de educación que recibió, cuántas veces falla el sistema en una sesión de trabajo de dos horas o cuán rápido completa un usuario una determinada tarea. Se trata, pues, de simples registros del comportamiento. • Cuestionarios de opinión

Se trata de preguntar a los participantes qué es lo que piensan de algo o alguien. No hay , pues, respuestas correctas ni incorrectas, todo lo que ha de hacer el usuario es plasmar su sentir ¿me gusta o no?, ¿qué prefiero?, ¿votaré pos A o por B?. Una encuesta de opinión no busca sutilezas en los pensamientos del participante: lo que importa es la popularidad de alguien o algo. • Cuestionarios de actitud

Los cuestionarios de actitud manejan aspectos complejos a los que no hay habitualmente respuestas directas. Hay, por lo general, diversos condicionantes en torno a los cuales el pensamiento de las personas varía. Por ejemplo, en el estudio

50

sobre un sistema particular de computadoras, podrían detectarse diversas actitudes en el usuario en relación : - al sentimiento del usuario de sentirse eficiente - al grado en el que al usuario le gusta el sistema - las posibilidades de asistencia que el sistema le ofrece al usuario - al sentimiento de control de la situación - a las posibilidades de aprendizaje que ofrece el sistema

Los cuestionarios en general se enfocan en los pensamientos de los participantes acerca de un aspecto en particular (un producto, un concepto, una idea,...) y constituyen al mismo tiempo un mecanismo de aproximación al mismo.

¿Cómo se puede llevar a cabo esta técnica? Podemos distinguir una serie de pasos básicos para la implementación de un proceso de desarrollo de cuestionarios: 1. Determinar los objetivos, recursos y limitaciones de la encuesta

Son consideraciones preliminares básicas: - ¿Qué información se requiere? - ¿Qué contenidos van a ser cubiertos por el cuestionario? - Hay que plantearse ¿por qué quiero saber esto?, pero no sirve decir "sería

interesante conocer..." - ¿Quiénes son los usuarios/participantes objetivo? - ¿Qué método de reunión de datos será utilizado para encuestar a los

participantes? 2. Determinar el método de reunión de datos

En general se van a distinguir: - Cuestionarios escritos (por correo y autocumplimentable) - Entrevista Personal - Entrevista Telefónica

A modo de ilustración, se comparan estos métodos sobre la siguiente tabla

Aspecto a considerar Cuestionario escrito

Entrevista personal

Entrevista telefónica

Coste Bajo Alto Moderado

Calidad de los datos Bajo Alto Moderado/Alto

Tasa de respuestas Bajo Alto Moderado/Alto

Motivación participante Bajo Alto Alto

Influencia del entrevistador Ninguno Moderado Bajo

Calidad de la muestra Bajo Alto Moderado/Alto

Longitud de la entrevista Corta Muy larga Larga

Posibilidad de aclaraciones Ninguna Alta Alto

Posibilidad de ayudas visuales Alguna Alta Ninguno

Velocidad Baja Baja Alto

Supervisión del entrevistador Ninguna Baja Alto

Anonimato Alto Bajo Bajo

Asistencia por ordenador Ninguno Posible Alto

51

Depende capacidad participante Alta Ninguno Ninguno

Control del contexto y respuestas Ninguno Alto Alto

3. Determinar el formato de las respuestas: • Abiertas: el participante puede responder de una forma relativamente ilimitada,

bien escribiendo una respuesta, en el caso de un cuestionario escrito o hablándole al entrevistador, a quien se instruye para registrar la respuesta con la mayor precisión posible. (indagar o no)

• Cerradas: las respuestas presentan dos o mas alternativas y los participantes optan por la posibilidad más próxima a su posición. (dicotómicas frente a opción múltiple)

• Escaladas: el investigador establece una escala para la medición de determinados aspectos bajo estudio (etiquetadas y sin etiquetar)

Abierta no indagatoria Permite a los participantes Difícil de interpretar y codificar

expresarse con sus propias Los participantes podrían no

palabras dar respuestas completas

Ejemplo: "¿Cuál fue su reacción ante el último anuncio televisivo de Josta?"

Abierta indagatoria Obtención de respuestas completas Difícil de interpretar y codificar

Ejemplo: "¿Tuvo algún otro tipo de reacción o pensamiento en relación al anuncio?"

Cerrada dicotómica Sencilla de gestionar y Puede simplificar en exceso

codificar las opciones de respuesta

Ejemplo: ¿Está de acuerdo o en desacuerdo con la frase "Josta sabe mejor que Fruitopía"?

Cerrada elección múltiple Admite un amplio rango de Los participantes ven una

posibles respuestas variedad de opciones que los

Desconcierta

Sencilla de gestionar y Hay que distinguir entre

codificar "escoger una" y "escoger las

que correspondan"

Ejemplo: Si fuera hoy a comprar un refresco, ¿qué marca le gustaría más adquirir?. Sería

(1) Fruitopía (2) Snapple (3) Josta (4) Surge (5) Otro

Respuesta escalada Permite la expresión de Los participantes podrían no

no etiquetada intensidades y sensaciones acomodarse a la escala

según una graduación apropiadamente

Sencilla de gestionar y codificar

Ejemplo: En escala del 1 al 7 ¿cómo calificaría el sabor de Josta?

Respuesta escalada Permite la expresión de intensidad La escala puede resultar

Etiquetada y sensaciones según una graduación forzada o exageradamente

Sencilla de gestionar y codificar detallada

Los participantes se acomodan

a la escala

Ejemplo: ¿Está en completo desacuerdo, en desacuerdo, de acuerdo o completamente

de acuerdo con la afirmación : "Josta sabe mejor que Fruitopía"?

4. Determinar el planteamiento y formulación de las preguntas Es conveniente plantearse

• En cuanto al contenido de las preguntas:

52

- ¿Es la pregunta útil y necesaria? - ¿Se requieren varias cuestiones? - ¿Tienen los que responden la información requerida? - ¿Debe ser la pregunta más específica? - ¿Es la pregunta lo suficientemente general? - ¿Está la pregunta polarizada? - ¿Se obtendrá una respuesta sincera? • En cuanto a la redacción de las preguntas: - ¿Puede ser la pregunta mal interpretada? - ¿Hace la pregunta alguna suposición? - ¿Se especifica el marco temporal en la pregunta? - ¿Hasta qué punto puede resultar intrusiva la pregunta? - ¿Es demasiado directa la formulación de la pregunta? 5. Establecer el flujo y disposición del cuestionario

En cuanto a la apariencia del cuestionario conviene: - Evitar un aspecto desordenado - Utilizar un tipo de letra la suficientemente grande y claro para que no hay que

hacer ningún esfuerzo en la lectura - Proporcionar suficiente espacio para las respuestas abiertas - Considerar una codificación por colores - La fecha, título del estudio, y el nombre de la organización que lleva el

estudio debe aparecer en la primera página del cuestionario - Las instrucciones impresas en el cuestionario deben ir en letras mayúsculas - Cada pregunta debe ir numerada y cada parte (en caso de haberla) de cada

pregunta debe ir identificada mediante una letra para evitar la omisión de las correspondientes contestaciones

- No es recomendable cortar las preguntas o las categorías de respuestas de una página a la siguiente

6. Evaluar el cuestionario 7. Obtener la aprobación de todas las partes implicadas 8. Efectuar un test previo del mismo

Será de utilidad plantearse: - ¿Es necesaria esta pregunta? - ¿Por qué estoy haciendo esta pregunta? - ¿Son necesarias varias cuestiones en lugar de una sola? - ¿Es la pregunta demasiado larga? - ¿Proporcionarán las preguntas la información deseada para los objetivos de

la investigación? - ¿Es preciso algún tipo de consideración sobre la capacidad del participante

para responder a las preguntas? - ¿Es preciso algún tipo de consideración sobre la voluntad del participante

para responder las preguntas? 9. Efectuar un revisión en la medida en que se requiera

53

10. Preparar una copia del cuestionario final 11. Administrar el cuestionario 12. Registrar y codificar los datos para su análisis

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

Los cuestionarios se suelen utilizar cuando hay un elevado número de usuarios potenciales y un desarrollador quiere obtener información de una muestra poblacional lo más grande posible. Los cuestionarios pueden ser una forma efectiva de obtener información de fondo (los cuestionarios por correo no requieren el despliegue de recursos que exige organizar un gran número de entrevistas personales) y resulta especialmente útil cuando los usuarios participantes viven lejos unos de otros. Los cuestionarios por correo postal pueden ser utilizados para reunir una amplia variedad de información, acerca de las propias personas, por ejemplo, y sobre sus opiniones acerca del producto, opciones futuras de diseño.

Una ventaja de los cuestionarios es que el participante puede emplear todo

el tiempo que desee en completarlo sin ningún tipo de presión externa. para usuarios con discapacidades, esto puede suponer obtener respuestas que no se obtendrían en una entrevista o en un grupo de debate.

Los cuestionarios que no requieren la identificación de quien contesta pueden igualmente facilitar la contestación de preguntas y cuestiones personales prácticamente inaccesibles por cualquier otro método. Ejemplo: Cuestionario para la evaluación de un sitio web como un conjunto software

Reacciones globales al software Terrible Maravilloso 0 1 2 3 4 5 6 7 8 9 Difícil Fácil 0 1 2 3 4 5 6 7 8 9 Frustrante Satisfactorio 0 1 2 3 4 5 6 7 8 9 Potencia Inadecuada Potencia Adecuada 0 1 2 3 4 5 6 7 8 9 Aburrido Estimulante 0 1 2 3 4 5 6 7 8 9 Rígido Flexible 0 1 2 3 4 5 6 7 8 9

Caracteres en la pantalla de la computadora Difícil de leer Fácil de leer 0 1 2 3 4 5 6 7 8 9 Los realces en los detalles simplifican la tarea En absoluto Totalmente 0 1 2 3 4 5 6 7 8 9

54

Organización de la información en la pantalla Confuso Muy Claro 0 1 2 3 4 5 6 7 8 9 Secuencia de Pantallas Confuso Muy Claro 0 1 2 3 4 5 6 7 8 9

Terminología e información en el sistema Uso de terminología por el sistema Inconsistente Consistente 0 1 2 3 4 5 6 7 8 9 La terminología utilizada se relaciona con la tarea Nunca En todo momento 0 1 2 3 4 5 6 7 8 9 Posición de los mensajes en la pantalla Inconsistente Consistente 0 1 2 3 4 5 6 7 8 9 Mensajes en pantalla que indican al usuario que introduzcan datos Confuso Muy Claro 0 1 2 3 4 5 6 7 8 9 El sistema mantiene informado al usuario de lo que está sucediendo Nunca En todo momento 0 1 2 3 4 5 6 7 8 9 Mensajes de error No ayudan Son de gran ayuda 0 1 2 3 4 5 6 7 8 9 Aprendiendo a operar con el sistema Difícil Fácil 0 1 2 3 4 5 6 7 8 9 Exploración de nuevos aspectos por ensayo y error Difícil Fácil 0 1 2 3 4 5 6 7 8 9 Memorización de nombres y uso de comandos Difícil Fácil 0 1 2 3 4 5 6 7 8 9 Tareas que pueden realizarse de forma directa Nunca Siempre 0 1 2 3 4 5 6 7 8 9 Mensajes de ayuda en la pantalla No ayudan Son de gran ayuda 0 1 2 3 4 5 6 7 8 9 Materiales de referencia suplementarios Confuso Claro 0 1 2 3 4 5 6 7 8 9

Capacidades del sistema Velocidad del sistema Demasiado lento Muy rápido 0 1 2 3 4 5 6 7 8 9 Fiabilidad del sistema No es fiable Muy fiable 0 1 2 3 4 5 6 7 8 9 Tendencias del sistema Ruidoso Silencioso 0 1 2 3 4 5 6 7 8 9 Corrección de errores propios Difícil Fácil 0 1 2 3 4 5 6 7 8 9 Medida en que se tiene en cuenta a los usuarios con o sin experiencia Nunca Siempre

55

0 1 2 3 4 5 6 7 8 9

Ejemplo: Cuestionario WAMMI WAMMI Cuestionario de Usabilidad para la Web Sitio Web: CID, Centre for User Oriented IT Design

Gracias por su ayuda en la evaluación de este sitio

• Si aún no ha utilizado este sitio, vuelva, por favor, al mismo haciendo uso de la función BACK de su navegador y haga uso del mismo antes de contestar este cuestionario.

• La parte principal de este cuestionario consiste en 20 puntos. Considérelos, por favor, de forma cuidadosa y evalúe su acuerdo con cada uno de los mismos haciendo uso de la escala de cinco puntos desde completamente de acuerdo hasta en completo desacuerdo.

• Tras completar el cuestionario, pulse el botón ENVIAR que se encuentra al final de esta página, para hacernos llegar sus respuestas. La información que usted nos proporciona se mantiene de forma completamente confidencial.

Primero, ¿cuáles fueron sus principales razones para hacer uso de este sitio web?:

Puntos 1 - 10 de 20

Completamente de acuerdo �

En completo desacuerdo

Este sitio web tiene muchas cosas de interés para mí

Es difícil moverse por este sitio web

Puede encontrar rápidamente lo que quiero en este sitio web

Este sitio web me parece bastante lógico

Este sitio web necesita más explicaciones introductorias

Las páginas de este sitio web son muy atractivas

Tengo el control cuando me muevo por este sitio web

Este sitio web es demasiado lento

Este sitio web me ayuda a encontrar lo que busco

Situarme en este sitio web es un auténtico problema

Puntos 11 - 20 de 20

Completamente de acuerdo �


No me gusta utilizar este sitio web

Es fácil contactar con la gente que quiero en este sitio web

Me siento eficiente al utilizar este sitio web

Es difícil decir si este sitio web tiene lo que quiero

Es fácil utilizar este sitio web por primera vez

56

Este sitio web tiene algunas características molestas

Es difícil tratar de recordar donde estoy en este sitio web

Es una pérdida de tiempo usar este sitio web

Sale lo que espero cuando sigo los vínculos en este sitio web

En este sitio web, todo es fácil de entender

Por favor, compruebe que ha dado una respuesta a cada punto. Caso de no estar seguro acerca de la evaluación de alguno de los mismos, elija, por favor, la columna intermedia ¿Tiene algún comentario adicional acerca de la facilidad de uso de este sitio web? Si ha terminado, pulse, por favor, el botón ENVIAR, para hacernos llegar sus respuestas WAMMI - Q - 2.5 EN (c) Copyright HFRG Ireland & Nomos Management AB Sweden, 1998.

Ejemplo: Cuestionario SUS

El cuestionario SUS fue desarrollado en 1986 como parte de la

introducción de la ingeniería de usabilidad a los sistemas de oficina de Digital Equipment Co. Ltd. Su propósito era proporcionar un test fácil de completar (número mínimo de cuestiones), fácil de puntuar y que permitiera establecer comparaciones cruzadas entre productos. Ha sido usado extensivamente en evaluaciones de proyectos en Digital Equipment Co. Ltd (sistemas de oficina, dirección de sistemas, herramientas técnicas y sistemas de hardware), resultando como simple y fiable. Utilización de la escala SUS_____________________________________

La escala SUS se utiliza generalmente después de que un usuario ha tenido la oportunidad de utilizar un sistema pero antes de que cualquier informe o discusión tenga lugar. Se solicitará a los usuarios el registro inmediato de su respuesta a cada punto, en lugar de pensar largamente en los mismos. Todos los puntos han de ser comprobados. Si el usuario no se siente capaz de responder a alguna cuestión en particular, habrá de señalar el valor central de la escala.

57

Puntuación de la escala SUS___________________________________

La escala SUS es una escala de estilo Likert que genera un único número, representando una medida compuesta de la usabilidad del sistema global sometido a estudio. Hay que advertir que las puntuaciones independientes no son significativas por sí mismas

Para calcular la puntuación del SUS, hay que sumar primero las contribuciones de cada punto. La contribución de cada punto valdrá entre 0 y 4. Para los puntos 1, 3, 5, 7 y 9, la contribución será la posición de la escala menos 1. Para los puntos 2, 4, 6, 8 y 10, la contribución será 5 menos la posición en la escala. Se multiplica la suma de los resultados por 2.5 para obtener el valor global del SUS. El resultado estará entre 0 y 100. Reconocimiento de la fuente de la escala________________________

La escala podrá ser utilizada siempre que se haga un reconocimiento

apropiado de su origen Notas sobre la construcción de la escala________________________

La escala SUS se construyó sobre un conjunto original de 50 puntos.

Las ponderaciones se efectuaron para 20 usuarios sobre los 50 puntos para dos sistemas, uno diseñado para su uso por el usuario final y otro diseñado para el uso de los programadores de sistemas. Estos dos sistemas fueron elegidos para representar los extremos de la usabilidad.

Los 10 puntos seleccionados eran aquellos que aglutinaban las

respuestas más consistentes y polarizadas. Los puntos seleccionados tienen todos una intercorrelación de entre 0.7 y 0.9. Creo que me gustaría utilizar este sistema frecuentemente

1 2 3 4 5

Encuentro este sistema innecesariamente complejo 1 2 3 4 5

Pienso que el sistema es fácil de usar

1 2 3 4 5

Creo que necesitaría soporte técnico para hacer uso del sistema

1 2 3 4 5

Encuentro las diversas funciones del sistema bastante bien integradas

1 2 3 4 5

He encontrado demasiada inconsistencia en este sistema

1 2 3 4 5

Creo que la mayoría de la gente aprendería a hacer uso del sistema rápidamente

1 2 3 4 5

He encontrado el sistema bastante incómodo para usar

1 2 3 4 5

Me he sentido muy seguro haciendo uso del sistema 1 2 3 4 5

Necesitaría aprender un montón de cosas antes de poder manejar el sistema

1 2 3 4 5

58

Escala para la Usabilidad de los Sistemas (System Usability Scale). Sustituyo "sistema" por "website" 1. Creo que me gustará visitar con frecuencia este website En completo Desacuerdo

Completamente de acuerdo

1 2 3 4 5

2. Encontré el website innecesariamente complejo En completo Desacuerdo


1 2 3 4 5

3. Pensé que era fácil utilizar el website En completo Desacuerdo


1 2 3 4 5

4. Creo que necesitaría del apoyo de un experto para recorrer el website En completo Desacuerdo


1 2 3 4 5

5. Encontré las diversas posibilidades del website bastante bien integradas

En completo Desacuerdo


1 2 3 4 5

6. Pensé que había demasiada inconsistencia en el website



1 2 3 4 5

7. Imagino que la mayoría de las personas aprenderían muy rápidamente a utilizar el website



1 2 3 4 5

8. Encontré el website muy grande al recorrerlo



1 2 3 4 5

9. Me sentí muy confiado en el manejo del website



1 2 3 4 5

10. Necesito aprender muchas cosas antes de manejarme en el website



1 2 3 4 5

(C) Digital Equipment Corporation

Para las contestaciones indicadas a las preguntas, se obtiene la siguiente tabla: 1. Creo que me gustará visitar con frecuencia este website: 5 La puntuación dará 5-1=4 2. Encontré el website innecesariamente complejo: 4 La puntuación dará 5-4=1

59

3. Pensé que era fácil utilizar el website: 2 La puntuación dará 2-1=1 4. Creo que necesitaría del apoyo de un experto para recorrer el website: 1 La puntuación dará 5-1=4 5. Encontré las diversas posibilidades del website bastante bien integradas: 2 La puntuación dará 2-1=1 6. Pensé que había demasiada inconsistencia en el website: 3 La puntuación dará 5-3=2 7. Imagino que la mayoría de las personas aprenderían muy rápidamente a utilizar el website: 2 La puntuación dará 2-1=1 8. Encontré el website muy grande al recorrerlo: 4 La puntuación dará 5-4=1 9. Me sentí muy confiado en el manejo del website: 5 La puntuación dará 5-1=4 10. Necesito aprender muchas cosas antes de manejarme en el website: 2 La puntuación dará 5-2=3 Los resultados totales: 4+1+1+4+1+2+1+1+4+3= 22 La puntuación SUS: 22 * 2.5 = 55

Ejemplo: Cuestionario para la Evaluación de la Usabilidad (Shneiderman, 98) Número de Identificación: __________ Edad: ____ Sexo: ____ Mujer ____ Hombre

Parte 1. Tipo de sistema a evaluar 1.1. Nombre del hardware 1.2. Nombre del software 1.3. ¿Durante cuánto tiempo ha trabajado con este sistema?

Menos de 1 hora Entre 1 hora y menos de 1 día Entre 1 día y menos de 1 semana Entre 1 día y menos de 1 mes Entre 1 mes y menos de 6 meses Entre 6 meses y menos de 1 año Entre 1 año y menos de 2 años Entre 2 años y menos de 3 años Tres años o más 1.4. En promedio, ¿cuánto tiempo emplea semanalmente con este sistema?

Menos de 1 hora Entre 1 y 4 horas Entre 4 y 10 horas Más de 10 horas

Parte 2. Experiencia previa 2.1. ¿Con cuántos tipos distintos de sistemas de computadoras ha trabajado?

Ninguno 1 2 3-4 5-6 Más de 6 2.2. De los siguientes dispositivos, software y sistemas, señalar los que haya utilizado y aquellos

60

con los que esté familiarizado. Teclado Teclado numérico Ratón Lápiz óptico Pantalla táctil Track ball Joy Stick Editor de texto Procesador de texto Gestor de ficheros Hoja de cálculo Correo electrónico Software para gráficos Juegos de ordenador Monitor en color Sistemas de tiempo compartido Estaciones de trabajo Ordenador personal Diskettes Discos duros Discos compactos

Parte 3. Reacciones globales del usuario Rodee, por favor, los números que reflejan de forma más apropiada sus impresiones sobre el uso de este sistema. NA= No Aplicable. Hay espacio disponible en la última página para sus comentarios escritos. 3.1 Reacciones globales al sistema Terrible Maravilloso 1 2 3 4 5 6 7 8 9 NA Frustrante Satisfactorio 1 2 3 4 5 6 7 8 9 NA Aburrido Estimulante 1 2 3 4 5 6 7 8 9 NA Difícil Fácil 1 2 3 4 5 6 7 8 9 NA Potencia inadecuada Potencia adecuada 1 2 3 4 5 6 7 8 9 NA Rígido Flexible 1 2 3 4 5 6 7 8 9 NA

Parte 4. Pantalla 4.1. Caracteres sobre la pantalla Difícil de leer Fácil de leer 1 2 3 4 5 6 7 8 9 NA 4.2. ¿Resultaron de ayuda los aspectos que se destacaban sobre la pantalla? En absoluto Mucho 1 2 3 4 5 6 7 8 9 NA 4.3. ¿Resultó de ayuda la disposición de las pantallas? En absoluto Mucho 1 2 3 4 5 6 7 8 9 NA 4.4. Secuencia de pantallas Confuso Claro 1 2 3 4 5 6 7 8 9 NA

Parte 5. Terminología e Información del Sistema 5.1. Uso de términos a través del sistema Inconsistente Consistente 1 2 3 4 5 6 7 8 9 NA 5.2. ¿Se relaciona la terminología de forma apropiada con el trabajo que se realiza? No relacionado Muy bien relacionado 1 2 3 4 5 6 7 8 9 NA

61

5.3. Mensajes que aparecen en pantalla Inconsistente Consistente 1 2 3 4 5 6 7 8 9 NA 5.4. Mensajes que aparecen en pantalla Confuso Claro 1 2 3 4 5 6 7 8 9 NA 5.5 ¿Le mantiene informado el sistema sobre lo que está ocurriendo? Nunca Siempre 1 2 3 4 5 6 7 8 9 NA 5.6 Mensajes de error No son de ayuda Son de ayuda 1 2 3 4 5 6 7 8 9 NA

Parte 6. Aprendizaje 6.1 Uso de términos a través del sistema Difícil Sencillo 1 2 3 4 5 6 7 8 9 NA 6.2. ¿Se relaciona la terminología de forma apropiada con el trabajo que se realiza? De forma desalentadora De forma alentadora 1 2 3 4 5 6 7 8 9 NA 6.3. Mensajes que aparecen en pantalla Difícil Sencillo 1 2 3 4 5 6 7 8 9 NA 6.4. Mensajes que aparecen en pantalla Nunca Siempre 1 2 3 4 5 6 7 8 9 NA 6.5 ¿Le mantiene informado el sistema sobre lo que está ocurriendo? Confuso Claro 1 2 3 4 5 6 7 8 9 NA 6.6 Mensajes de error Confuso Claro 1 2 3 4 5 6 7 8 9 NA

Parte 7. Capacidad del sistema 7.1. Velocidad del sistema Demasiado lento Demasiado rápido 1 2 3 4 5 6 7 8 9 NA 7.2 ¿En qué medida es fiable el sistema? Nada fiable Muy fiable 1 2 3 4 5 6 7 8 9 NA 7.3. El sistema tiende a ser Ruidoso Silencioso 1 2 3 4 5 6 7 8 9 NA 7.4. Corrección de errores Difícil Sencillo 1 2 3 4 5 6 7 8 9 NA 7.5. ¿Se tienen en cuenta las necesidades tanto de usuario experimentados como inexperimentados? Nunca Siempre 1 2 3 4 5 6 7 8 9 NA

Parte 8. Comentarios de los usuarios

62

III. Desarrollo del Concepto y de las Especificaciones del Sistema

63

3.1 Introducción De los métodos de indagación en los procesos de desarrollo centrado

en el hombre se ha obtenido la suficiente información en cuanto a los requerimientos de usuario, producto y organizacionales como para abordar la materialización de esa información en un prototipo del sistema a desarrollar. Sin embargo, diseñadores y usuarios tienen distintos modelos mentales del sistema o producto, pues hablan un lenguaje distinto. Hablar del desarrollo del concepto y de las especificaciones del sistema significa hablar de la puesta en común de esos lenguajes bien distintos para unificarlos posteriormente en un prototipo a partir del cual va a evolucionar el diseño, siempre con la participación del usuario

El concepto de producto es esencialmente una descripción preliminar del producto futuro para ser evaluada como tal y para ser usada como la base de las siguientes fases del desarrollo el producto. Sus especificaciones tiene el mismo significado en lo que a funcionalidad se refiere. Las funcionalidades, en tanto que han de derivar en la realización de una tarea, van a ser motivo de satisfacción para el usuario. El uso y la posesión de ese producto o sistema también. Una aproximación a los sistemas

Mientras algunos autores indican, tan solo, que es aconsejable considerar el modo en el que humanos y sistemas interactúan, tal aspecto es fundamental. Idealmente, el sistema habría de ser una prolongación del usuario en la realización de una tarea, y esto sólo es posible diseñando para el usuario. La interfaz de usuario es la parte del sistema donde se localiza el flujo de entradas y salidas a dicho sistema.

Conviene, por tanto, plantear una aproximación a los sistemas. El

fundamento de una aproximación de estas características radicaría en una teoría general de sistemas, que describe al sistema en términos dinámicos: - La actividad resulta de la continua adaptación entre componentes del

sistema - Los cambios en un componente afectan a los demás componentes y al

sistema completo - Los componentes de los sistemas están vinculados a través de

intercambios (entradas y salidas o ,en la terminología habitual, inputs y outputs)

- Dentro de cada componente tiene lugar una conversión interna - Cada tipo de entrada tiene un tipo de salida correspondiente - Los errores aparecen en las fronteras entre componentes

64

En su interacción con el sistema, el usuario va recorriendo diversos estados del mismo. Tales transiciones tendrán lugar en base a la acción de unos operadores: es la base del diseño lógico

El usuario, a través de procesos sensoriales y de percepción, recibe la información que indica el estado del sistema y la convierte en una actividad física en forma de entrada al mismo. La entrada modifica el estado interno del sistema, generándose una retroalimentación hacia el humano en forma de salida. Resulta de especial, interés, por tanto, la frontera entre usuario y sistema, interfaz de usuario, que es donde los errores se vuelven aparentes, siendo preciso conocer bien la naturaleza de la interacción (bidireccional) que tiene lugar.

Aquí se aboga ante todo por abordar el diseño de forma lógica. Se

comentarán someramente las características de algunas técnicas, pero todas tiene el mismo fundamento y se considera que puede resultar mucho más efectivo un diseño muy modular en base a estos principios de diseño lógico que la aplicación de estas técnicas de forma directa.

3.2 Algunas técnicas para la composición de interfaces

En este punto se van a comentar brevemente algunas de las técnicas

más características para la composición de interfaces de usuario. Análisis de Vínculos (Link Analysis)_______________ _____________

El análisis de vínculos representa la secuencia en la que los elementos de un sistema son utilizados en una tarea o escenario dados. La secuencia proporciona los vínculos entre los elementos de la interfaz del sistema en cuestión. Este método se suele utilizar para comprobar si la

65

relación existente entre los elementos del sistema sometido a análisis es óptima en términos del carácter secuencial de la tarea.

En ocasiones se toman medidas de los tiempos en que el usuario

mantiene sus ojos atentos sobre los elementos de la interfaz, con el objetivo de comprobar si tales elementos se han dispuesto de la forma más eficiente. Esta técnica queda íntimamente relacionada con la de Seguimiento del Ojo (Eye Tracking), a pesar de que inicialmente se planteó el dilema de si se trataba de estudiar el movimiento de las manos o el de los ojos, resultando lo primero más simple.

Los datos obtenidos en el análisis de vínculos suelen ser utilizados para evaluar un rango de alternativas antes de que la disposición más apropiada sea aceptada.

Una revisión cognitiva básica es suficiente para la reunión de los datos

apropiados, aunque es aconsejable optar por una o dos tareas bien definidas, representativas y características, que limiten una serie de enlaces virtualmente infinitos. Análisis de disposición (Layout Analysis)________________________

El análisis de disposición se basa en el análisis de vínculos para considerar grupos funcionales de elementos del sistema. Dentro de tales agrupaciones funcionales, los elementos entran en categorías de acuerdo a la optimización conjunta de tres criterios: frecuencia de uso, secuencia de uso e importancia del elemento.

Resulta más sencillo de utilizar que el análisis de vínculos dado que

las cuestiones anteriores resultan relativamente fáciles de determinar y los grupos funcionales van a ser, en general, más obvios. El análisis también mantiene algo de la estructura jerárquica, al plantearse una progresión desde las categorías generales hasta las funciones específicas. Se trata de una técnica efectiva que en combinación con la anterior conduce a destacadas mejoras en la disposición de las interfaces. Análisis jerárquico de tareas, AJT (Hierarchical Task Analysis, HTA)__

Ha sido una técnica fundamental en la disciplina de la Ergonomía en el Reino Unido durante años. la aplicación de esta técnica descompone las tareas en metas, planes y operaciones según una estructura jerárquica. Este método tiene por tanto un carácter descriptivo, sirviendo de entrada a otros métodos como el SHERPA (Systematic Human Error Reduction and Prediction Approach o Aproximación para la predicción y reducción

66

sistemática de los errores humanos). Tiene una fuerte componente de iteración, debido a la lógica involucrada en las decisiones y los planes. SHERPA_____________________________________________________

Se trata de una técnica semiestructurada para la identificación del error humano, basada en el análisis jerárquico de tareas y una clasificación de errores. Cada tarea, desde el nivel inferior del análisis jerárquico de tareas se van situando en modos de errores potenciales asociados con aquella actividad con que son identificados. En este punto, las consecuencias de esos errores serán determinados. Esta técnica se caracteriza por la particularidad de cada caso sobre el que se aplica, aunque se considera que las predicciones que genera son precisas y fiables., si bien los aspectos cognitivos de lo errores no suelen estar considerados Análisis de tareas para la identificación de errores (Task analysis for Error Identification, TAFEI)______________________________ El análisis de tareas para la identificación de errores es una aproximación para el modelado de la interacción entre sistema y usuario. Está basado en el análisis jerárquico de tareas y en los diagramas de espacio/estados. Mapeando el análisis jerárquico de tareas sobre los diagramas de estados y haciendo uso de la matriz de transición, es posible considerar qué va mal en la interacción. En esencia, se trata de un método de identificación del error humano como SHERPA. De hecho, el TAFEI consiste en tres partes fundamentales: - análisis jerárquico de tareas, que proporciona una descripción de la

actividad humana - diagramas de estado, que proporcionan una descripción de la actividad

del sistema - matrices de transición, que proporcionan un mecanismo para determinar

una potencial actividad errónea a través de la interacción entre hombre y sistema

Evidentemente se trata de diseño lógico, de pensar en estados del

sistema y transiciones, de controlar dichas transiciones, de planear las acciones ante las de carácter espúreo. Lo único que se hace es varia el tradicional formato de los diagramas de estados. Podría entenderse cada tarea incluso como una máquina de estados y analizarla de esa forma.

67

3.3 Diseño paralelo (Parallel Design)

A menudo va a ser de gran ayuda el desarrollo de conceptos de sistema en un proceso paralelo en el que un grupo de diseñadores trabajan sobre diversas posibilidades. El objetivo será desarrollar y evaluar diversas ideas antes de escoger una única aproximación como base para el sistema y constituyendo un primer prototipo (Nielsen, 93).

En el diseño paralelo es importante tener a los diseñadores trabajando independientemente, dado que el objetivo es generar la mayor diversidad posible. Así pues, los diseñadores no deberían hablar ni discutir sus diseños entre sí hasta haber creado un borrador de sus conceptos de diseño.

Cuando los diseñadores han completado su trabajo, es probable que hayan realizado desde perspectivas radicalmente diferentes una aproximación al problema, lo que dará lugar a una variedad de sistemas de usuario. Será entonces posible combinar diseños, adoptando las mejores características de cada uno de ellos.

Es importante emplear el diseño paralelo para nuevos sistemas, cuando no se han establecido guías acerca de cuál va a ser el mejor funcionamiento posible para el sistema.

Aunque, a primera vista, el diseño paralelo podría parecer una aproximación costosa, al generarse una gran cantidad de ideas sin implementarlas, resulta una forma barata de explorar el rango de conceptos de sistema factibles, seleccionando los probablemente óptimos. Téngase en cuenta, además, que tal aproximación sólo tiene sentido para tiempos pequeños, en general, entre horas y unos pocos días. Por otra parte, el material generado, pasa a formar parte de la historia del diseño, lo que va a facilitar posteriores revisiones y tratamientos.

Convendrá aclarar que se pueden disponer en paralelo tanto equipos completos como diseñadores individuales, resultando más apropiada, y rentable, esta última posibilidad, no sólo a efectos de costes, sino también en lo que se refiere a la productividad en la generación de ideas, no tan sujeta a los protocolos que exigen la coordinación de los grupos.

El diseño paralelo va a resultar muy apropiado en sistemas novedosos donde hay escasas o ninguna referencia acerca de la aproximación a la interfaz que va a funcionar mejor (Nielsen, 93). Igualmente, para productos ya existentes, el análisis de los productos de la competencia puede servir como diseños paralelos iniciales.

68

Una variante de esta aproximación es lo que se conoce como Diseño Paralelo Diversificado, que se va a caracterizar por solicitar de los diseñadores que se concentren en diferentes aspectos del problema de diseño. En general, las ideas que surjan, habrán de ser modificadas para trabajar en un proceso de diseño único e integrado, lo cual puede exigir un tiempo extra.

Beneficios

• Permite generar de forma rentable y rápida una gran variedad de ideas • La naturaleza paralela de la aproximación permite la evaluación de diversos

conceptos al mismo tiempo, reduciendo el tiempo a dedicar al desarrollo de los mismos

• Los conceptos generados pueden ser combinados de forma que el sistema final se beneficie de todas las ideas propuestas

• Se requieren materiales y recursos mínimos para lograr una sensación de producto

• Esta técnica puede ser utilizada por aquellos con poca o ninguna experiencia en factores humanos

Limitaciones

• Requiere un número a determinar de miembros del equipo de diseño disponibles en el mismo momento para generar conceptos de sistema

• Requiere mucho tiempo durante un corto período de tiempo para que se desarrolle el trabajo de diseño; esto es, se trata de un trabajo corto pero muy intensivo

• Se requiere de tiempo adicional para comparar las salidas del diseño paralelo de forma apropiada para aprovechar los beneficios que aporte cada aproximación

Beneficios y Limitaciones de la aplicación de la técnica del Diseño Paralelo

Este método requiere de la disponibilidad concurrente de los

miembros del equipo para desarrollar el trabajo de diseño en paralelo. Es preciso asegurar, por otra parte, que los diseñadores disponen de la misma información y comienzan el diseño desde el mismo punto.


Es posible distinguir una serie de pasos básicos para la implementación de un proceso de estas características:

1. Definir claramente los límites para el diseño paralelo: objetivo del sistema,

tareas que debería soportar, características de usuario,... 2. Si es posible, establecer un acuerdo sobre el formato en el que se

plasmará el diseño: papel, software,... 3. Si se trabaja con equipos en lugar de con individuos, se seleccionarán los

grupos de la forma más homogénea posible. 4. Establecer claramente un tiempo límite sobre la fase de diseño. 5. Acordar el criterio de valoración de los diseños. 6. Hay que permitir un tiempo suficiente para llevar a cabo una comparación

justa de los diseños producidos. 7. Discutir cada diseño de forma separada y, después, la forma en la que los

aspectos diferentes serán combinados De forma adicional, conviene tener en consideración las siguientes guías

prácticas:

69

• Asegurar que todos los equipos de diseño disponen de la misma información antes de iniciar la actividad de diseño.

• Decidir con antelación el tiempo a dedicar al trabajo de diseño. Caso de que uno de los equipos, o individuos, completara primero su trabajo, se habrá de permitir a los demás que lleguen a sus conclusiones

• Permitir a los equipos de diseño el vehículo de presentación que prefieran para presentar sus diseños

3.4 Secuencias de Escenarios (Storyboarding / Presentation Scenarios)

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. una presentación de escenarios típica contendría un cierto número de imágenes mostrando características, como menús, cajas de diálogo y ventanas. La constitución de estas representaciones en una secuencia proporciona mucha información, mostrando las posibles estructuras, funcionalidad, opciones de navegación, funcionalidades disponibles.

La presentación de escenarios se puede mostrar a los miembros del

equipo de diseño así como a los usuarios potenciales, permitiendo a los demás visualizar la composición y la amplitud de las posibles interfaces y ofrecer una información crítica. En general, se requieren pocos recursos técnicos. Es suficiente con herramientas de dibujo, ya estén basadas en ordenador o no.

Beneficios

• Se pueden obtener respuestas sobre la funcionalidad del sistema, así como sobre el estilo y opciones de navegación, en etapas tempranas del proceso de desarrollo, cuando los cambios pueden ser más fácilmente implementados.

• El método fomenta la comunicación entre diseñadores y usuarios. • La presentación de escenarios puede desarrollarse de forma rápida y sencilla. • Los recursos y materiales requeridos son mínimos. • La técnica puede ser utilizada incluso por aquellos que tienen poca o ninguna

experiencia en factores humanos.

Limitaciones

• La presentación de escenarios puede carecer del carácter interactivo de otros métodos de prototipado.

• Debido a su simplicidad, la presentación de escenarios no admite la evaluación de los detalles del diseño

• La presentación de escenarios no contempla los tiempos de respuesta del sistema

Beneficios y Limitaciones de la aplicación de la técnica de Secuencias de Escenarios

Los recursos técnicos requeridos para la presentación de escenarios son mínimos e incluyen las herramientas de dibujo (tanto basadas en

70

ordenador como no), papel, tarjetas, bolígrafos y adhesivos. los recursos humanos y temporales son, por tanto, pequeños. ¿Cómo se puede llevar a cabo esta técnica?

Es posible distinguir una serie de pasos básicos para la implementación de un proceso de estas características: 1. Considerar los escenarios de uso que reflejará la presentación. Una

presentación de escenarios pude representar diversas actividades, como la introducción, copia o impresión de una información. De forma alternativa, se puede representar cada tema distinto en una presentación.

2. 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 ítems del menú, las barras de herramientas, los iconos,...

3. Los elementos de la presentación pueden ser complementados con notas explicativas para facilitar la comprensión de la audiencia y la correspondiente evaluación.

4. 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. Se pueden crear y mostrar también varias presentaciones a una audiencia seleccionada para explorar las diferentes opciones de los requerimientos.

5. Puede resultar de utilidad el registro en audio o vídeo de las sesiones para posterior revisión y difusión.


prácticas: • Generar esquemas de alto nivel para representar el sistema. Los detalles

en la representación pueden distraer a los usuarios o desviar el tema de la discusión.

• Puede no ser necesario desarrollar muchos esquemas para cubrir las diferentes etapas de la interacción. Utilizando una única representación como base, es posible discutir los eventos que puedan tener lugar antes o después.

• Hay que tratar de incluir aspectos organizacionales de alto nivel en los esquemas (por ejemplo, la interacción entre las personas) además de mostrar las interacciones de usuario con la interfaz del sistema. Esto proporcionará a los usuarios una imagen más completa del concepto de sistema.


La presentación de escenarios constituye una plataforma para la exploración de las opciones para los requerimientos de usuario mediante una

71

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.

3.5 Construcción de Escenarios (Scenario Building)

Los escenarios son caracterizaciones de los usuarios y sus tareas en un contexto específico. Ofrecen representaciones concretas de un usuario trabajando con un sistema para conseguir un objetivo específico. El objetivo primario 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.

Los escenarios son creados por miembros del equipo de desarrollo,

quienes, entonces, adoptan el papel de usuarios para elaborar un modelo amplio de usuario basado en un consenso. También se pueden discutir los escenarios con los usuarios para establecer como les gustaría o no interaccionar con el sistema (cuanto menos, en términos generales).

Beneficios

• Fomenta el interés de los diseñadores por las características de los usuarios objetivo, sus tareas y su entorno.

• Es posible explorar los aspectos de usabilidad en etapas tempranas del proceso de diseño, antes de definir cuestiones inamovibles

• Los escenarios pueden contribuir a identificar los objetivos de usabilidad así como los tiempos de finalización de tareas

• El método promueve una aproximación centrada en el hombre • Los escenarios pueden ser utilizados para generar contextos para

estudios de evaluación • Se requieren recursos mínimos para generar escenarios • La técnica puede ser utilizada por desarrolladores con poco o ninguna

experiencia en factores humanos

Limitaciones • Los escenarios no son apropiados para considerar los detalles del diseño de interfaz y su disposición

Beneficios y Limitaciones de la aplicación de la técnica de Construcción de Escenarios


Es posible distinguir una serie de pasos básicos para la implementación de un proceso de estas características: 1. Reunir al equipo de desarrollo con otros individuos de relevancia

implicados bajo la dirección de un experto. 2. Identificar a los usuarios objetivo, sus tareas y el contexto general. Esta

información proporcionará la base para la creación de escenarios por el equipo de desarrollo.

3. Descomponer funcionalmente los objetivos de usuario en las operaciones precisas para conseguirlo.

4. Asignar tiempos de tarea y criterios de finalización como objetivos de usabilidad.

72

5. La sesión puede ser grabada en vídeo para posterior revisión o transcrita para ampliar su difusión.

6. Los resultados de la sesión de construcción de escenarios pueden ser utilizados para planificar evaluaciones basadas en usuario. En términos de salidas , el método fomenta un entendimiento más profundo de los requerimientos de usuario, pudiendo ser específicamente utilizado para planificar posteriores evaluaciones basadas en usuario.


prácticas: • Hay que intentar generar escenarios para un amplio rango de situaciones,

y no sólo las más comunes o aquellas de mayor interés para el equipo de diseño

• Hay que tratar de incluir las situaciones problemáticas, que testarán el concepto de sistema además de los escenarios

• Hay que trabajar a través de los escenarios y juzgar el sistema sobre esa base, en lugar de pretender modificar el sistema a mitad del camino

3.6 Cuadros de Asignación de Tareas (Task

Allocation Charts)

Un sistema exitoso va a depender de una reparto efectivo de tareas entre dicho sistema y los usuarios del mismo. Se necesitará considerar diferentes opciones en la asignación de tareas antes de especificar una frontera bien definida del sistema. Se han de establecer 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. La aproximación es más útil para sistemas que afectan procesos de trabajo completo y no solo productos individuales o productos monotarea. Ni que decir tiene que será preciso un buen entendimiento de las papeles desempeñados en los distintos puestos de trabajo

Beneficios • Se contrarresta la tendencia a intentar computerizar la totalidad del sistema

dejando a los usuarios a cargo de las tareas restantes sin reparar en el tipo de trabajos que esto genera

Limitaciones • Son precisos para los usuarios conceptos del nuevo sistema para contribuir al proceso y generar nuevas alternativas.

Beneficios y Limitaciones de la aplicación de la técnica de los Cuadros de Reparto de Tareas


Podemos distinguir una serie de pasos básicos para la implementación de un proceso de estas características: 1. Se identifica cada tarea o proceso de trabajo.

73

2. Identificar aquellos para los que sería posible plantear una asignación de tareas distinta.

3. Se dibuja 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.

4. Generar al menos dos opciones para el reparto de tareas para mostrar el reparto de las mismas entre el usuario y el nuevo sistema.

5. Comentar las implicaciones de la satisfacción en el trabajo y la eficiencia en el mismo para cada opción.

6. Seleccionar la alternativa que resulte más aceptable para el cliente o generar nuevas opciones si es preciso.


prácticas: • Considerar todas las tareas e identificar aquellas para las que se plantea

alguna posibilidad de un reparto distinto • hay que intentar desarrollar más de una opción para estimular la

discusión dentro del equipo de diseño o entre los usuarios

• No conviene emplear demasiado tiempo generando diagramas. Simples esquemas sobre las posibles asignaciones es más que suficiente.

3.7 Análisis de tareas (Task Analysis) 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. Se puede llevar a cabo un análisis detallado de tareas 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 y deben ser incorporados o substituidos en cualquier nuevo sistema. Fracasar en el reparto de recursos suficientes apara 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. Evidentemente, es importante conseguir acceso a los usuarios reales para discutir las tareas presentes o futuras, así como a usuarios representativos.

Beneficios • Proporciona información sobre las tareas que el usuario desea realizar.

Así, constituye una referencia contra cuyo valor pueden ser testadas las funciones y características del sistema.

Limitaciones • El análisis formal de tareas puede llevar mucho tiempo y generar muchos datos, requiriendo un considerable esfuerzo de análisis.

Beneficios y Limitaciones de la aplicación de la técnica del Análisis de Tareas

74

¿Cómo se puede llevar a cabo esta técnica? El proceso se divide aquí en dos partes: 1. Descomposición de tareas a alto nivel, donde las mayores tareas se

dividen en subtareas. Este paso proporciona una buena perspectiva de las tareas que están siendo analizadas.

2. Diagrama del flujo de tareas, donde las tareas específicas se dividen en pasos básicos de tarea.

Descomposición de tareas___________________________________

El objetivo de la descomposición de tareas a alto nivel es el de 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.

El proceso de descomposición de tareas se representa como un

cuadro estructurado . 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: 1. Identificar la tarea a analizar a partir de la lista de tareas. 2. Descomponer 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.

3. Dibujar las subtareas como un diagrama en capas, asegurando que está completo.

4. Decidir sobre el nivel de detalle de la descomposición. Una decisión concienzuda en esta etapa asegurará un tratamiento consistente en la descomposición de tareas. Podría decidirse que la descomposición de tareas continuara hasta que los flujos fueran representados con mayor facilidad en un diagrama de flujo de tareas.

5. Continuar el proceso de descomposición, asegurando que las descomposiciones y la numeración son consistentes. Es normalmente de ayuda el desarrollo escrito de estos procesos.

6. Presentar el análisis a alguien más que no haya estado involucrado en la descomposición pero que conozca las tareas los suficientemente bien como para comprobar la consistencia.

75

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 probables cambios deberán ser registrados en los propios diagramas de descomposición de tareas. Esto puede llevarse a cabo mediante el uso de comentarios en la base del diagrama con referencia a los números de caja de la descomposición de tareas. Diagramas de flujo de tareas__________________________________

El análisis del flujo de tareas documentará los detalles de las tareas

específicas. Puede incluir detalles de interacciones entre el usuario y el sistema actual así como cualquier problema relacionado con los mismos. Los flujos de tareas no mostrarán solamente los detalles específicos de los actuales procesos de trabajo, sino que 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.

De forma adicional, conviene tener en consideración las siguientes guías prácticas: • Generar un mapa de usuarios relevantes e intentar entender inicialmente

sus principales tareas y funciones. • Identificar a los individuos que pueden proporcionar información

apropiada sobre las tareas que se están realizando. Establecer reuniones para asegurar que todos estos usuarios pueden ser incluidos en el análisis.

• Planificar sesiones de observación si es necesario para conseguir una perspectiva más rica de las tareas o de los problemas de las tareas.

• Reunir la mayor cantidad de información posible para tratar de estructurarla de inmediato

• Acudir de nuevo a los usuarios para aclarar las cuestiones precisas durante el proceso de estructuración

• Intentar proporcionar descripciones textuales de las tareas con diagramas como la descomposición de tareas o los diagramas de flujos de tareas.

76

3.8 Matriz de Funcionalidad (Functionality Matrix)

Este proceso especifica las funciones del sistema que cada usuario requerirá para las diferentes tareas que habrá de realizar. Se identifican 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. Seguidamente se puede ver la estructura de una matriz de funcionalidad. Es importante obtener información de diversos grupos de usuarios para completar la matriz.

Matriz de Funcionalidad Funciones Usuarios y Tareas

F1 F2 F3 F4 F5 O= Critico X= Ocasional

Usuario A

Notas

Tarea A O Tarea B X Tarea C X

Usuario B

Tarea A O Tarea B X Tarea C X Selección de función

Estructura de una matriz de funcionalidad

En general, son pocos los recursos requeridos. Lo que importará será la aportación de una amplia variedad de usuarios para conseguir completar la matriz.

¿Cómo se puede llevar a cabo esta técnica? Podemos distinguir una serie de pasos básicos para la

implementación de un proceso de estas características:

1. Identificar los grupos de usuarios y situarlos en las filas de la matriz. 2. Identificar las tareas por grupos de usuarios y situarlos por filas en la

matriz. 3. Hacer una lista de funciones y características potenciales y situarlas por

columnas en la matriz. 4. Identificar funciones que son críticas para la tarea. 5. Identificar funciones que se utilizan ocasionalmente.

77

6. Añadir nuevas funciones y características que cubran carencias en las tareas.

7. Eliminar las funciones superfluas. 8. Desarrollar prototipos para ayudar a crear una especificación de los

requerimientos de usuario más detallada.

Beneficios

• Se puede adaptar para ajustarse a una amplia variedad de procesos de diseño y filosofías de empresa.

• Permite la consideración de diversos tipos de usuarios en un único proceso • Se identifican las funciones superfluas • Representa una referencia en las etapas posteriores del ciclo de vida del

producto, pudiendo ser actualizada a la luz del prototipo.

Limitaciones • El enfoque primordial se lleva a cabo sobre funciones y características, más que

sobre el aspecto de la interfaz. • La matriz puede resultar demasiado grande para un gran número de funciones.

Beneficios y Limitaciones de la aplicación de la técnica de la Matriz de Funcionalidad

De forma adicional, conviene tener en consideración las siguientes guías prácticas: • Comenzar con una versión simple de alto nivel de la matriz, para obtener

una estimación de las tareas principales y los grupos de funciones relacionadas. Esto contribuirá a definir el alcance de la matriz y ayudará a mantenerla dentro de unas proporciones manejables.

• Utilizar una hoja de cálculo para manejar matrices de funcionalidad grandes. Una impresión de esta hoja servirá para posteriores discusiones de grupo.


Este método es ú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. En esta situación, la matriz de funcionalidad se puede utilizar para intercambiar funciones, añadirlas o quitarlas, dependiendo de su valor en la asistencia para diferentes tareas. También será útil para sistemas multiusuario en los que se haya de asistir las tareas de cada tipo de usuario.

78

IV. Métodos de Categorización y Prototipado en los procesos DCH

79

4.1 Introducción

El quinto proceso para el Desarrollo Centrado en el Hombre es el de generar potenciales soluciones de diseño a partir de la experiencia, los conocimientos de los participantes y los resultados del análisis del contexto de uso. En concreto, las entradas a este proceso serían: - Especificación de los requerimientos del sistema - Especificación de los requerimientos de usuario y demás implicados - Especificación de los requerimientos de organización - Contexto de uso - Metas de usabilidad susceptibles de ser medidas - Requerimientos ergonómicos - Estándares y guías - Pautas de estilo - Experiencia previa - Retroalimentación procedente de evaluaciones

Las especificaciones de los requerimientos y el contexto de uso ya se

conocen de los procesos anteriores. Otros factores como requerimientos ergonómicos y estándares y guías vienen, en general, impuestos por las normativas. En próximos capítulos se hará referencia a los procesos que generan la retroalimentación de interés y la historia de diseño; esto es inspecciones y experimentos controlados o tests que pueden resolverse sobre las salidas generadas por este proceso que ya se indicaron en el primer capítulo al hacer referencia a este proceso.

En el siguiente capítulo se va a tratar la categorización y el prototipado

de los conceptos anteriormente listados. Diseñador y usuario hablan diferentes lenguajes, lo que conduce a diferentes modelos mentales sobre el sistema objeto de diseño que hay que unificar.

La utilización de simulaciones modelos, y maquetas y cualquier otra

forma de prototipo en general permite a los diseñadores una comunicación mucho más efectiva con los usuarios y reduce la necesidad y el coste del rediseño que puede ser preciso cundo los productos han de ser revisados con posterioridad, en algunos casos tras su lanzamiento y comercialización entre clientes reales. Mediante el prototipado, va a ser posible hacer las decisiones de diseño más explícitas (lo que capacita a los miembros del equipo a comunicarse entre ellos desde etapas tempranas en el proceso de diseño). Los diseñadores explorarán los diversos conceptos de diseño antes de optar por uno en particular, pero siempre posibilitando la incorporación de la retroalimentación del usuario en la etapas tempranas del proceso de

80

desarrollo así como la evaluación de diversas iteraciones de un diseño y de diseños alternativos. En general, mejorará la calidad y el carácter de conjunto de la especificación funcional del diseño que ya se había empezado a forjar con los conceptos introducidos en el capítulo anterior. Los beneficios generados por una implementación exitosa del proceso de generación de soluciones de diseño enfocada en el hombre serán muchos, pero resultarán especialmente interesantes los que implican de forma directa al usuario: - todos los componentes del sistema tienen en cuenta las características y

necesidades del usuario - las características y las necesidades del usuario serán tenidas en cuenta

en el diseño del sistema - se diseñará la interfaz entre el usuario y el sistema - se desarrollará el entrenamiento y la asistencia al usuario

4.2 Técnicas de Categorización La Categorización por Tarjetas y los Diagramas de Afinidad se encuentran a mitad de camino entre la generación de ideas y la necesidad de organizarlas y categorizarlas para hacer uso de las mismas. Puede decirse que estas técnicas se aplican cuando las ideas son de aparición más inmediata, o hay una cantidad de conceptos a organizar. Se trata de técnicas secundarias que aparecen, en general, en las recopilaciones de técnicas de usabilidad y de diseño centrado en el usuario en la bibliografía porque admiten la participación del usuario, lo que bajo el concepto de diseño participativo está altamente valorado y puede aportar información cualitativa adicional. Los Diagramas de Afinidad aparecen habitualmente en agrupaciones de técnicas para la Planificación y la Dirección o el Control de Calidad. 4.2.1 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. ¿Cómo se puede llevar a cabo esta técnica?

Se comenzaría con una lista de elementos a clasificar, cada uno de

los cuales se escribiría en una tarjeta. Uno o varios usuarios recibirían la pila de tarjetas que habrían de agrupar según el criterio que las relacionara de forma más apropiada.

81


Esta técnica se utilizaría preferentemente en las etapas tempranas del desarrollo. Por ejemplo, se podría querer determinar el modo en el que los usuarios agruparían diversas funciones. Esta información se utilizaría para ubicar la información en los diversos menús de una interfaz de usuario.

4.2.2 Diagramas de Afinidad (Affinity Diagram)

El diagrama de afinidad es un método de categorización en el que los usuarios clasifican varios conceptos en diversas categorías. Este método suele ser utilizado por un equipo para organizar una gran cantidad de datos de acuerdo con las relaciones naturales entre los mismos.

Básicamente, se trata de escribir cada concepto en una nota Post It y pegarla en una pared. Los miembros del equipo mueven y organizan las notas en grupos basándose en las relaciones y asociaciones que establecen entre los distintos conceptos. ¿Cómo se puede llevar a cabo esta técnica?

Hay que llevar a cabo los siguientes pasos: • Constituir un equipo

Se reúne a un equipo de entre cuatro y seis personas. Es conveniente la presencia de diversos niveles de experiencia y variedad de perspectivas, con el objetivo de afrontar la sesión con creatividad. • Describir el objetivo

Inicialmente, es preciso realizar una declaración del objetivo que se quiere alcanzar, o del resultado que se espera obtener. Dicha declaración ha de tener un carácter amplio y neutral, claramente entendido y acordado por todos los miembros del equipo. • Generar ideas en las tarjetas

Mediante la técnica del brainstorming se genera una lista de ideas, cada una de las cuales se registra en una nota Post It. Las tarjetas deberían describir conceptos completos, y no contar con una única palabra cada una. • Pegar las tarjetas en la pared

Seguidamente se pegan las notas en la pared sin seguir un orden en particular.

82

• Clasificar las tarjetas en grupos

Se mueven las tarjetas en grupos de forma intuitiva. Nadie debe hablar durante esta fase del proceso para asegurar que no existe ninguna forma de influencia entre las decisiones de unos y otros. Si a alguien no le gusta el lugar en el que otro ubicó una tarjeta, no tiene que hacer más que cogerla y cambiarla de grupo. No se debe perder el tiempo discutiendo acerca del lugar que debería ocupar una determinada tarjeta. • Crear cabeceras para cada grupo

Hay que crear cabeceras para cada uno de los grupos constituidos. Dichas cabeceras deberían describir concisamente lo que cada grupo representa. Una forma de pensar en ello es escribiendo una forma de titular periodístico para cada grupo. Las cabeceras no deberían ser, de hecho, palabras sueltas y el grupo debería resultar significativo independientemente del contenido de los demás grupos. Si es necesario, se utilizarán cabeceras para algunos subgrupos. • Dibujar el diagrama de afinidad

Se dibujan líneas conectando cabeceras primarias y secundarias, grupos, subgrupos... indicando la relación existente. El resultado final se asemejará bastante a un diagrama organizacional. ¿Cuándo debería usarse esta técnica?

Esta técnica se puede utilizar cuando es preciso generar un gran número de ideas o conceptos y se han de clasificar en categorías. Ejemplo

Un equipo de publicaciones tiene el propósito de reducir los errores tipográficos. Durante una sesión de Brainstorming, generan una lista de factores que afectan a la tasa de error. Ordenadores Ausencia de retroalimentación Capacidad probada de lectura

Impresoras Ruido Plazos cortos

Iluminación Máquinas de escribir Altura de la sillas

Confort Altura de las mesas La hora del día

Deletreado Interrupciones Manuscritos

Gramática Argot Jerga técnica

Borradores Puntuación Distribución

83

Fuentes Copias finales Edición

Manejo de aplicaciones Habilidades en mecanografía No hay medidas

El equipo desarrolló, a partir de esta lista, un diagrama de afinidad

para identificar áreas de interés en posteriores análisis:

Entorno Equipamiento

Ergonomía Ordenadores

Interrupciones Ruido Impresoras

Iluminación Máquinas de escribir

Plazos no razonables Altura de la mesa

Altura de las sillas Entrenamiento

La ora del día Confort Mecanografía

Edición

Documento Original Manejo de aplicaciones

El autor Requerimientos Capacidad de lectura

Manuscritos Borradores

Gramática Copia Final Sin definir la calidad

Puntuación Distribución No hay medidas

Deletreado Fuentes No hay retroalimentación

Jerga técnica Argot

4.3 ¿Qué es el Prototipado?

Un prototipo es un modelo (representación, demostración o simulación) fácilmente ampliable y modificable de un sistema planificado, probablemente incluyendo su interfaz y su funcionalidad de entradas y salidas.

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 testar haciendo uso del modelo. ¿Cómo se puede llevar a cabo esta técnica?

Consideraciones previas a la construcción de un prototipo

Profundidad de la funcionalidad requerida en el prototipo

Elección de la herramienta de prototipado y consideración de sus limitaciones

Criterios de conclusión para el ciclo de iteración

Composición del equipo (usuarios, desarrolladores y otros implicados)

Nivel de fidelidad requerido en el prototipado

84

Longitud máxima de un ciclo de iteración

Propósito del prototipo

Formas de manejar los conflictos entre miembros del equipo de diseño y establecimiento de consenso.

Tras una serie de consideraciones previas ineludibles que

condicionarán la marcha del proceso (Ver tabla superior), se comienza elaborando un prototipo del producto final: qué aspecto tendrá, cómo funcionará,...Para muchas interfaces de usuario, este modelo puede resultar tan simple como unos dibujos con lápiz y papel o tan complejo como el propio código operativo final. Para interfaces de hardware o estaciones de trabajo, el modelo puede consistir en maquetas de espuma, caucho, cartón o cartulina. Cuanto más próximo se encuentre el prototipo al producto real, mejor será la evaluación, si bien se pueden obtener magníficos resultados con prototipos de baja fidelidad. Variantes en la técnica del prototipado Se puede hablar de una amplia variedad de técnicas de prototipado en base a las características del prototipo a desarrollar: 1. Según la funcionalidad reproducida 2. Según la fidelidad de la reproducción de la interfaz 3. Según su propósito 4. Según la porción del sistema representado 5. Según su ejecutabilidad u operatividad 6. Otras variantes de especial relevancia 1. Según la funcionalidad

reproducida________________________________ � 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. 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.

85

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.

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.

� 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. Todas las funciones de un prototipo vertical imitan sus equivalente reales tanto como sea posible.

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 testadas, y no otras). En el caso de un coche, sería el asiento y el tablero de mandos lo que podría ser testado, mientras que el chasis, la carrocería y otros elementos aún no están disponibles.

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. � Prototipado Diagonal

86

Se trata de un prototipo horizontal hasta un cierto nivel, a partir del cual se puede considerar vertical 2. Según la fidelidad de la reproducción de la

interfaz___________________ � Prototipado de Alta Fidelidad (High-Fidelity Prototyping)

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).

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 testar 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 testados mediante maquetas de arcilla esculpida sobre marcos de madera y alambre.

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. � Prototipado de Baja Fidelidad (Low-Fidelity Prototyping)

87

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á testando, 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.

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.

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 de una serie de elementos dibujados con antelación y organizados, para disponer inmediatamente de un elemento cuando sea necesario.

88

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. 3. Según su propósito_________________________________ � Prototipado Exploratorio

Un prototipo no reutilizable es utilizado para clarificar las metas del proyecto, identificar requerimientos, examinar alternativas de diseño o investigar un sistema extenso y complejo. � Prototipado Experimental

Un prototipo utilizado para la validación de especificaciones de

sistema � Prototipado Operacional

Un prototipo iterativo es progresivamente refinado hasta que se

convierte en el sistema final. 4. Según la porción del sistema representado_________________ � Prototipo Global

Prototipo del sistema completo. Prototipo horizontal expandido que

modela una gran cantidad de características y cubre un amplio rango de funcionalidades. Va a resultar muy útil a lo largo de todo el proceso de diseño.

� Prototipo Local

Prototipo de un único componente o característica del sistema de usabilidad crítica. Va a resultar de utilidad en algunas etapas específicas del proceso de diseño. 5. Según su ejecutabilidad u operatividad__________________ � Prototipo Guiado

89

Prototipo lo suficientemente operativo como para lleva a cabo una revisión o paseo cognitivo.

� Prototipo de Animación

Prototipo lo suficientemente operativo como para ser ejecutado por

partes en modo de presentación en un ordenador.

� Prototipo del Mago de Oz

Prototipo que permite ser ejecutado en modo de presentación y la participación de un tercer sujeto que, oculto a la vista del usuario que interactúa, gestiona la evolución de la presentación en función de las entradas que el usuario proporciona al sistema. Nos referimos a esta variante con mayor extensión próximamente.

� Prototipo Interactivo

Prototipo operativo en sentido estricto, se ejecuta y responde a las

entradas que le proporciona el usuario participante en tiempo real.

� Prototipo Funcional Prototipo operativo en sentido estricto, se ejecuta, responde a las

entradas que le proporciona el usuario participante en tiempo real y efectúa alguna de las operaciones que se le solicitan. 6. Otras variantes de especial relevancia____________________ � Prototipado Rápido (Rapid Prototyping)

Metodología de diseño que desarrolla rápidamente nuevos diseños, los evalúa y prescinde del prototipo cuando el próximo diseño es desarrollado mediante un nuevo prototipo. Seguidamente se hará una referencia a esta variante con mayor extensión próximamente. � Prototipado Reutilizable (Reusable Protyping)

También conocido como Prototipado Evolutivo (Evolutionary Prototyping); no se pierde el esfuerzo efectuado en la construcción del prototipo pues sus partes o el conjunto pueden ser utilizados para construir el producto real. Mayormente es utilizado en el desarrollo de software, si bien determinados productos de hardware pueden hacer uso del prototipo como la base del

90

diseño de moldes en la fabricación con plásticos o en el diseño de carrocerías de automóviles.

Igualmente se habla de prototipos no reutilizables, que suelen definirse en

base a cuatro características típicas: • Ejecutabilidad: trabaja lo suficientemente bien con la entrada activa que le

procura el usuario para permitir un test de usabilidad. • Maduración: puede evolucionar, con el suficiente refinamiento, hasta el

producto final. • Representación: tiene el aspecto y las características de actuación del

sistema en planificación. • Perspectiva: como mínimo simula un 20% de las funciones que los

usuarios utilizarán el 80% del tiempo. � Prototipado Modular (Modular Prototyping)

También conocido como Prototipado Incremental (Incremental

Prototyping); se añaden nuevos elementos sobre el prototipo a medida que el ciclo de diseño progresa. Problemas asociados al prototipado

A pesar de la potencia del prototipado como técnica de asistencia al diseño centrado en el usuario, no hay que olvidar que puede albergar una serie de problemas en ciertos aspectos: - comunicación entre desarrolladores y clientes - aceptación por el cliente - lanzamiento de una prueba temprana del producto - poca definición en las etapas tempranas del diseño - reunión de requerimientos válidos - incremento de la participación constructiva del usuario - gestión de las peticiones de cambios - invisibilidad del producto - aseguramiento de la calidad y puede introducir una serie de problemas en otros: - decidir cuántas iteraciones son suficientes - calibrar la progresión sin los hitos tradicionales - gestión el conflicto entre desarrolladores y clientes - gestión de tiempos para el ciclo de desarrollo, que es esencialmente

abierto - procesado de las peticiones de cambios de los usuarios - inflar las perspectivas del usuario - el manejo de la situación con determinados problemas

91

En general, las cuestiones más críticas, y sus soluciones serán: • ¿Cómo evitar inflar las expectativas durante el prototipado?

- Introducir las realizaciones esperadas en el prototipo aunque ello implique retrasos

- Desarrollar especificaciones realistas - Distinguir entre los requerimientos primarios y secundarios

• ¿Cómo saber cuando se ha obtenido el prototipo? - Cuando se termina el tiempo o el dinero (criterio de defecto) - Cuando el prototipo alcanza los requerimientos del sistema final - Cuando el prototipo tiene un propósito limitado (p.e. reunión de

los requerimientos iniciales) y el propósito ha sido alcanzado - Cuando, en el prototipado horizontal se alcanza el nivel de

profundidad del sistema - Cuando desarrolladores y usuarios acuerdan proseguir con la

siguiente etapa.

Beneficios de la aplicación de la técnica de prototipado La aplicación de la técnica de prototipado puede generar una gran cantidad de beneficios en muchos sentidos: • Los prototipos son fácilmente modificables y prescindibles • El prototipado mejora la relación entre desarrolladores y usuarios • Los usuarios obtienen mayor satisfacción con los sistemas desarrollados

por prototipado • Un prototipo puede proporcionar la prueba conceptual necesaria para la

consolidación en el proceso • Un prototipo puede servir como herramienta de marketing • Un prototipo puede servir como base para especificaciones operacionales • La temprana disponibilidad del prototipo puede ayudar a la directiva a

evaluar el progreso • El prototipo exploratorio permite proceder con el trabajo productivo a

pesar de las posibles dudas iniciales • Los prototipos son indicador del progreso en las etapas tempranas del

desarrollo • Los prototipos pueden procurar una pronta preparación para los usuarios

futuros del sistema • El prototipado puede evitar sorpresas desagradables al destacar los

requerimientos incompletos o inconsistentes y la falta de funcionalidad. • El prototipado puede producir resultados con salida comercial incluso si

se exceden las previsiones temporales y de presupuesto en el proyecto

92

• El prototipado puede reducir los malos entendidos entre desarrolladores y clientes

• El prototipado puede reducir los costes de rediseño si los problemas se detectan pronto, cuando son fáciles de localizar

• El prototipado puede reducir el tiempo requerido para el test si los problemas se detectan pronto, cuando son fáciles de localizar

• El prototipado puede desembocar en un sentimiento de propiedad a partes iguales entre desarrolladores y usuarios

• El prototipado resultará en producto que se ajusta mejor a los requerimientos del usuario

• El prototipado puede resultar en un ahorro inicial en costes de mantenimiento, porque los usuarios están haciendo un test de aceptación a lo largo de todo el proceso

• El prototipado puede fortalecer la especificación de los requerimientos • Los sistemas generados por prototipado van a resultar más fáciles de

aprender a manejar y usar • El prototipado horizontal es un gran complemento del análisis

estructurado • El entorno en el proceso de prototipado está menos sujeto a intereses

creados por lo que se está más abierto al cambio y a la innovación • El uso de prototipos anticipa las peticiones de cambio, resultando más

económico su procesado • Los usuarios entienden mejor los prototipos que las especificaciones de

papel

Limitaciones de la aplicación de la técnica de prototipado La aplicación de la técnica del prototipado puede generar algunas situaciones problemáticas: • El prototipado puede estimular un número de petición de cambios

excesivo • Los prototipos operativos pueden inducir a pensar a la directiva y a los

clientes que el producto final está prácticamente dispuesto para su salida al mercado

• Las características del prototipo pueden conducir a interpretaciones erróneas del usuario - cliente

• Los clientes pueden no estar preparados para proporcionar la información con el nivel y frecuencia requeridos en un ciclo iterativo

• Los clientes podrían no estar dispuestos a participar en el ciclo de iteración durante largos períodos de tiempo

93

• Los desarrolladores pueden encontrar dificultades en la ultimación de detalles que han resultado de fácil desarrollo con una herramienta de prototipado

• Debido a las exigencias temporales y de mercado, las especificaciones del sistema podrían congelarse antes de que el proceso de prototipado haya alcanzado una etapa definitiva

• Durante el prototipado, la única especificación de diseño es el propio prototipo, habiendo de admitir cuantas modificaciones sean necesarias.

• Los prototipos en etapas tempranas han de ser de baja fidelidad • Los prototipos de alta fidelidad pueden ser confundidos con el producto

real • Se corre el riesgo de ignorar importantes características del sistema

(actuación, seguridad, robustez y fiabilidad, p.e.) durante el desarrollo del prototipo

• Puede resultar imposible implementar funciones críticas del sistema para la seguridad o la operación

• La directiva puede encontrar problemas en la planificación de la iteración del prototipado

• Los prototipos pueden albergar simplificaciones e imprecisiones • Los prototipos pueden encarecer el producto • Los prototipos de sistemas complejos pueden resultar excesivamente

complicados • El proceso de prototipado es un proceso continuo que no de debe

presentar fases bien definidas. • El proceso de prototipado se puede alargar en exceso si no se han

establecido criterios de conclusión • El prototipado puede llevar a los diseñadores a modificar su filosofía de

diseño y a la adopción de modelos distintos • El prototipado puede dar poca opción al test de requerimientos no

funcionales de sistema • El prototipado se puede estancar si los miembros del equipo de diseño no

disponen de autoridad para la toma de decisiones • El prototipado puede generar problemas de disciplina • Las especificaciones que surgen durante las últimas etapas del proceso

de prototipado pueden reducir la integridad estructural del sistema, aún parcialmente diseñado

• El contexto de uso del prototipo puede ser bien diferente del contexto de uso del sistema final

• No hay garantía de que las posiciones de desarrolladores y clientes converjan durante el ciclo de iteración

94

¿Cuándo se prototipa? Antes de comenzar... ...para mostrar el concepto a la directiva. Comenzando... ...para reunir los requerimientos iniciales de usuario. Después de empezar... ...para validar la evolución de los requerimientos de usuario. En las etapas intermedias... ...para validar las especificaciones del sistema. Entre las etapas intermedias y finales... ...para preparar usuarios o tratar con marketing. En las etapas finales... ...para explorar soluciones a problemas de diseño o usabilidad específicos.


Esta técnica puede ser utilizada en cualquier etapa del desarrollo (Ver tabla superior). A medida que el proceso progresa y el producto se completa, el prototipo ha de abarcar, cada vez más las características del producto final. Llegados a un punto, la construcción de prototipos adicionales resultará menos eficiente que usar las construcciones iniciales para el producto (Ver tabla "Cuándo funciona el prototipo y cuándo no lo hace").

El prototipado tendrá probablemente éxito cuando se utilice... � como un mecanismo para desarrollar un test de usabilidad temprano � para comparar alternativas de diseño � para crear una especificación activa en constante evolución � para evaluar las interfaces propuestas � para explorar los efectos de las peticiones de cambio � para mostrar nuevos o inesperados requerimientos � para identificar los requerimientos de mercado � para involucrar a los usuarios en el proceso de diseño � para modelar un sistema con una componente significativa de interfaz de usuario � para modelar un sistema relativamente grande y complejo � para establecer una base común para la buena comunicación entre desarrolladores y usuarios � para estimular las aportaciones del cliente durante la reunión de requerimientos � dentro de una herramienta de prototipado rápido El prototipado fracasará probablemente cuando... � no se haya establecido un claro criterio de conclusión del ciclo iterativo de desarrollo � se permita que las expectativas de los clientes vayan más allá de los límites de lo razonable � cuando la funcionalidad de un prototipo operacional no evolucione hacia la del sistema final � las opiniones de desarrolladores y usuarios divergen durante la fase de iteración � el proyecto es demasiado pequeño para justificar el prototipado � el prototipo es inapropiado para el producto objetivo � se utilice para modelar sistemas que no presentan interfaz externa

Cuándo funciona el prototipo y cuándo no lo hace

95

Escenarios

Los escenarios son la última reducción del nivel de funcionalidad y el número de características de un prototipo: sólo será posible simular la interfaz de usuario en la medida en que un test de usuario siga un camino previamente planificado.

Las dos dimensiones del prototipado: el prototipado horizontal mantiene las características, pero elimina la profundidad de la funcionalidad y el prototipado vertical da la funcionalidad total para unas pocas características (Nielsen, 93)

Siendo el escenario pequeño, es posible llevar a cabo modificaciones

frecuentes, y mediante pequeños estudios con protocolos de expresión bien simples (a los que se hace referencia en los próximos capítulos), va a ser posible testar las diferentes versiones. Así los escenarios se constituyen como un gran medio para obtener un feedback rápido y frecuente de los usuarios.

Los escenarios son el último prototipo minimalista en el que se

describe una sesión de interacción sin ninguna flexibilidad para el usuario. Se combinan las limitaciones del prototipado horizontal (los usuarios no pueden interactuar con datos reales) y del prototipado vertical (los usuarios no se pueden mover con libertad por el sistema)

Un escenario es, pues, una descripción encapsulada de: - un usuario individual - haciendo uso de un conjunto de servicios computerizados - para conseguir un resultado específico - bajo un conjunto de circunstancias específicas - durante un cierto intervalo de tiempo (se contempla una

dimensión temporal: ¿qué ocurre cuando...?)

96

Se puede decir que los escenarios tienen dos funciones básicas:

• Los escenarios pueden ser utilizados durante el diseño de una interfaz de

usuario como un modo de expresar y entender la forma en la que los usuarios interactuarán con el sistema futuro.

• Los escenarios pueden ser utilizados en evaluaciones tempranas del diseño de una interfaz de usuario para obtener feedback de usuario sin el gasto de construir un prototipo activo.}

4.3.1 Prototipado de Papel (Paper Prototyping)

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 requerimiento 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.

Beneficios

• Se fomenta la colaboración entre diseñadores y usuarios • Los prototipos de papel se construyen y refinan rápidamente • Se requieren materiales y recursos mínimos para lograr una sensación de producto • Esta técnica puede ser utilizada por aquellos con poca o ninguna experiencia en

factores humanos

Limitaciones

• Debido a su simplicidad, los prototipos de papel no son aptos para exploraciones detalladas

• Debido al uso del papel y al modo de operación, esta forma de prototipo no se puede utilizar para simular tiempos de respuesta

• El individuo que manipula el prototipo para simular su evolución debe ser consciente de la funcionalidad del sistema objetivo

Beneficios y Limitaciones de la técnica del Prototipado de Papel

Los materiales requeridos para crear los elementos del prototipo son

bien simples. Esto incluye papel, acetato, bolígrafos y adhesivos. También se suelen utilizar los "Post-its" para representar elementos de la interfaz, como mensajes del sistema, formularios de entrada y cajas de diálogo. También se podría trabajar con una cámara de vídeo para registrar las interacciones sobre el papel. También podría trabajarse con dos evaluadores, uno que actuaría como sistema, manipulando los elementos de papel de la interfaz y otro que controlaría la sesión. ¿Cómo se puede llevar a cabo esta técnica?

Podemos distinguir una serie de pasos básicos para la

implementación de un proceso de estas características

97

1. Es preciso disponer del tiempo suficiente para crear el prototipo, diseñar algunas tareas, reunir usuarios, conducir la evaluación del prototipo e informar de los resultados.

2. Hay que reunir los materiales necesarios. Se construye el prototipo de papel utilizando piezas separadas para los menús, cajas de diálogo y cualquier otro elemento que se mueva o cuya apariencia varíe.

3. Hay que seleccionar a los usuarios apropiados para el test del prototipo. Hay que tratar de cubrir una amplia variedad de usuarios dentro de la población objetivo.

4. Hay que preparar escenarios de tareas realistas para la evaluación. 5. Se han de realizar pruebas previas para practicar con el manejo del

prototipo. 6. Hay que asegurar que el equipo requerido para el registro está disponible

y funcionando. 7. Hay que conducir cada sesión manipulando el prototipo de papel a

medida que el usuario trabaja en las tareas determinadas. 8. Un miembro del equipo proporcionará instrucciones para la ejecución de

las tareas y explorará las impresiones e intenciones del usuario mediante cuestiones apropiadas.

9. Si hay observadores presentes, podrán tomar notas de determinados problemas, así como de soluciones potenciales durante la sesión para su posterior consideración.

10. Conducir las entrevistas con el usuario posteriores a la sesión basándose en preguntas preestablecidas así como otros aspectos que hayan surgido durante la evaluación.

11. Informar al usuario y agradecerle su colaboración. 12. Analizar la información obtenida, resumir las observaciones y las

evaluaciones de usuario. Considerar los temas y la severidad de los problemas identificados.

13. Resumir las implicaciones en los requerimientos de usuario e informar al equipo de diseño. Las grabaciones de vídeo pueden ser de ayuda.

14. Donde sea necesario, se refinará el prototipo de papel y se repetirá el proceso anterior.


prácticas: • Hay que trabajar a través de las interacciones sobre el papel de la forma

más completa posible, intentando cubrir todos los posibles caminos que el usuario podría querer seguir.

• Hay que disponer de papel, "post-it" y otros elementos de sobra disponibles para disponer de nuevos caminos para interacciones que el usuario podría esperar realizar.

• Hay que practicar con todas las posibles interacciones con un usuario piloto, para hacer el proceso interactivo lo más fluido posible.

98

La tercera dimensión en los prototipos de papel

Los prototipos de baja fidelidad deben ser baratos y sencillos para que su uso sea práctico. Uno de los métodos más característicos para el prototipado de baja fidelidad de interfaces de usuario es el prototipado de papel. Sin embargo, el prototipado de papel no puede representar de forma completa a aquellos productos o sistemas que impliquen una determinada manipulación física. El nivel de representación puede ser mejorado mediante el prototipado de papel tridimensional (3DPP). El diseño de productos inteligentes como teléfonos móviles, VCRs y ATMs se puede beneficiar del 3DPP dado que sus interfaces consisten en formas físicas, botones y pequeños displays cuyo uso implica, asimismo, el manejo de otros objetos físicos como dinero, recibos, cassettes...

Los productos elegantes son a menudo no muy usables. Las razones fundamentales que cita la bibliografía son tres:

1. un diseño dirigido por la tecnología 2. la problemática de operar todo el sistema con una interfaz muy

reducida (pocos botones y una pequeña pantalla) 3. la heterogeneidad de los grupos de usuarios: ya se conocen los

atributos de la aceptabilidad de un sistema que propone Nielsen.

Los productos inteligentes son, a menudo, productos de consumo, utilizados con un determinado objetivo, incluido el ocio, y han de ser de fácil uso en el contexto real de operación.

4.3.2 Prototipado Rápido (Rapid Prototyping)

Este método está asociado a la idea de desarrollar diferentes conceptos propuestos mediante prototipos de software o hardware, para su posterior evaluación. En general, al proceso se le denomina "prototipado rápido". El desarrollo de la simulación o prototipado del sistema futuro puede ser de gran ayuda, permitiendo a los usuarios visualizar el sistema e informar sobre el mismo. Así, se puede utilizar para aclarar opciones sobre los requerimientos de usuario. Más tarde, en el desarrollo, puede ser utilizado para especificar detalles de la interfaz de usuario a incluir en el sistema futuro.

Una dificultad mayor en el diseño del sistema es la consecución del

propio concepto a través de los usuarios. Mientras que un prototipo rápido puede mostrar el concepto del sistema apropiadamente, los métodos de prototipado en papel pueden resultar menos efectivos.

99

Características requeridas para una herramienta de prototipado rápido Se debería crear un prototipo operativo con el que los usuarios pudieran interaccionar Debería ser simple de crear, desarrollar y modificar Debería simular el aspecto y as impresiones que producirían la interfaz en planificación Otras cuestiones deseables (más explícitamente orientado a software) Debería permitir la llamada de programas y procedimientos externos Debería permitir la repetición de la participación de los usuarios Debería permitir la reunión y revisión científica de los datos de la interacción del usuario Debería simular las características de realización esperadas del sistema en planificación Debería presentar el aspecto del sistema objetivo en estado operativo Debería generar la mayor parte del código preciso para la implementación del diseño de la interfaz Debería importar componentes de software reutilizables de diversos tipos Debería importar texto, gráficas, sonido Debería soportar los estándares industriales y bibliotecas estándar Debería resultar fácil cambiar el orden de las tareas Debería resultar fácil cambiar el orden de las ventanas Debería resultar fácil crear animaciones simples Debería resultar simple modificar las tareas Debería resultar simple secuenciar o modificar la secuencia de ventanas Debería proporcionar una transición continua desde el diseño hasta la implementación

Tipos de Herramientas de Prototipado (de menor a mayor formalidad) Papel y lápiz Software de dibujo Aplicaciones para desarrollar demos Software de animación y presentaciones Perl + Motif + Tcl/Tk (UNIX) Herramientas visuales para RAD, como Visual Basic, Optima ++ y Borland Delphi 4GLs Sistemas de gestión de interfaz de usuario (UIM) Lenguajes de especificación ejecutable

Características requeridas para una herramienta de prototipado rápido y tipos de herramientas El prototipado rápido se describe como un método basado en

ordenador que pretende reducir el ciclo iterativo de desarrollo. Los prototipos iterativos desarrollados podrán ser rápidamente reemplazados o modificados según los informes de diversas procedencias, como experiencias previas de usuarios o de diseñadores veteranos, a medida que se evoluciona en el desarrollo de las tareas a realizar.

Dentro de los círculos de ingeniería de software, este método está

cercanamente asociado con sistemas de dirección de interfaz de usuario y diversas herramientas de diseño. las últimas herramientas ofrecen al diseñador librerías de procesos y elementos de la interfaz gráfica para la definición de la estructura lógica del software y su aspecto. Aquí, el título hace referencia a una aproximación adoptada por los desarrolladores de software en los que los prototipos exhiben una fidelidad muy alta respecto del producto final en comparación con aquellos creados mediante otros métodos como el prototipado de papel.

Existen muchas herramientas para la generación de prototipos

rápidos, desde una secuencia de imágenes en Microsoft PowerPoint, a sistemas basados en scripts como HyperCard, Toolbox y Visual Basic.. así,

100

el método requiere recursos técnicos más sofisticados, que los métodos de prototipado de baja fidelidad, que se basan en papel. un coste de uso adicional es el nivel de conocimientos requeridos para manejar las herramientas de apoyo durante el tiempo necesario para implementar un prototipo de software. También se requiere a un miembro del equipo para dirigir a los usuarios si el prototipo ha de ser evaluado formalmente.

Se requieren conocimientos de programación o modelado de sistemas para producir prototipos. habrán de tener lugar un cierto número de iteraciones con el prototipo o una aproximación de diseño paralelo donde dos o más diseñadores generen ideas que desemboquen en prototipos. El proceso de obtener datos del usuario también supondrá un cierto coste en términos de tiempo y esfuerzo.

Beneficios

• Proporcionar a los usuarios (y al público en general ) una demostración tangible de aquello en lo que consiste el sistema

• Permite el desarrollo rápido de prototipos de software interactivos • Los prototipos creados por este método presentan una alta fidelidad respecto del

producto final • Los prototipos creados por este método soportan evaluaciones basadas en métricas

Limitaciones

• El método requiere conocimientos en desarrollo de software • Aunque rápido, el método consume más tiempo que otras aproximaciones • los recursos requeridos son mayores debido a la necesidad de hardware y software en

lugar de papel y bolígrafos Beneficios y Limitaciones del Prototipado Rápido


Podemos distinguir una serie de pasos básicos para la implementación de un proceso de estas características:

1. Es preciso disponer del tiempo suficiente para crear el prototipo, diseñar

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

2. Hay que disponer del equipo necesario, incluyendo las herramientas de hardware y software necesarias para la construcción del prototipo iterativo.

3. Desarrollar el prototipo. 4. Seleccionar a los usuarios apropiados para el test del prototipo,

intentando cubrir un amplio rango de usuarios dentro de la población objetivo.

5. Preparar tareas realistas en las que se ocupará a los usuarios mientras trabajen con el prototipo.

6. Desarrollar un procedimiento de evaluación piloto y asegurar que el prototipo puede ser utilizado para la realización de las tareas.

7. Asegurar que el equipo para el registro está disponible y funcionando.

101

8. Conducir cada sesión. Se alecciona al usuario para trabajar a través de las tareas seleccionadas, interactuando y respondiendo al sistema de forma apropiada.

9. Si se requiere, se puede obtener información adicional entrevistando a los usuarios inmediatamente después a su interacción con el prototipo.

10. Informar y agradecer al usuario su colaboración. 11. Analizar la información obtenida y resumir las observaciones y las

evaluaciones de usuario. Determinar los temas y la severidad de los problemas identificados.

12. Resumir las implicaciones de diseño y las recomendaciones para las mejoras e informar al equipo de diseño. las grabaciones de vídeo pueden servir de gran ayuda.

13. Refinar el prototipo donde sea necesario y repetir el proceso anterior

De forma adicional, conviene tener en consideración las siguientes guías prácticas: • Evitar emplear demasiado tiempo en el desarrollo del primer prototipo

dado que el uso puede requerir cambios sustanciales en el mismo. De la misma forma, hay que intentar no esforzarse demasiado con determinadas características que no son requeridas.

• Hay que evitar desarrollar un prototipo demasiado pulido, pues esto puede forzar a los usuarios a entenderlo como producto terminado.

• Hay que evitar la inclusión de características que eleven las expectativas de los usuarios y que sean de improbable consideración en el sistema real (tiempos de respuesta demasiado rápidos, gráficos demasiado sofisticados,...)

4.3.3 Prototipado por Vídeo (Video Prototyping)

Este método permite a los diseñadores crear una simulación basada en vídeo de la funcionalidad de una interfaz utilizando material y equipo sencillo. Los elementos de la interfaz son creados a partir de papel, bolígrafos, acetatos,.... Así, por ejemplo, se registra mediante una cámara de vídeo un estado inicial para la interfaz. Entonces, los movimientos del puntero de un ratón pueden ser simulados mediante el apagado y encendido de la cámara a medida que los elementos de la interfaz se mueven, retiran o añaden. Los usuarios no interactúan directamente con el prototipo aunque pueden observar y comentar la simulación completa.

Una potencial aplicación muy amplia es la simulación de la funcionalidad de las interfaces. Sin embargo, debe ser posible simular los elementos de la interfaz con materiales básicos. Este método es útil en las etapas tempranas del proceso de desarrollo para mostrar opciones y conceptos de diseño.

102

Beneficios

• Los problemas de usabilidad pueden ser detectados en una etapa temprana del proceso de desarrollo (antes de que se haya tomado alguna decisión firme). Proporciona una simulación dinámica de los elementos de la interfaz que pueden ser revisados y comentados por el equipo de diseño y los usuarios. Son mínimos los materiales y recursos requeridos para proporcionar una sensación de producto final. Igualmente, esta técnica puede ser utilizada por aquellos con poca o ninguna experiencia en factores humanos

Limitaciones

• Se requiere personal familiarizado con la funcionalidad del sistema objetivo. Este método, por otra parte, no está registrando a un usuario interactuando con el prototipo. Debido al uso de materiales sencillos, los prototipos de vídeo no soportan la evaluación de detalles de diseño precisos.

Beneficios y Limitaciones del Prototipado por Vídeo

Como con el prototipado de papel, se requieren materiales sencillos

(papel, acetato, bolígrafos, adhesivos). Además, se requiere de una cámara de vídeo para capturar y reproducir la simulación. Este método requerirá a dos individuos, uno para manipular los elementos de la interfaz y operar el sistema y otro para controlar la cámara. Se requiere poca experiencia en producción de vídeo, si bien siempre supondría una mayor inversión en tiempo la creación de escenas más complejas. ¿Cómo se puede llevar a cabo esta técnica?

El procedimiento general para el desarrollo de este método, es paralelo al descrito para prototipos de papel en numerosos aspectos. Sin embargo, el énfasis en la creación de un prototipo basado en vídeo es una característica distinta, así como la ausencia de usuarios interactuando de forma directa con el prototipo.

De forma adicional, conviene tener en consideración las siguientes guías prácticas:

• No hay que realizar con mucho detalle el prototipo, dado que podría

distraer a los usuarios o desviar la discusión. • Se pueden utilizar paquetes de presentación para simular secuencias de

pantallas rápida y fácilmente. • Si es posible, conviene que aparezca el usuario en el vídeo, así como las

interacciones sobre el sistema. 4.3.4 Prototipado por Mago de Oz (Wizard of Oz Prototyping)

La técnica del prototipado del mago de Oz es utilizada para presentar conceptos avanzados de interacciones con los usuarios. En esencia, un experto (el mago), localizado tras una pantalla, procesa la entrada del usuario y emula la salida de un sistema. El objetivo es demostrar capacidades del sistema que por razones técnicas o por carencia de recursos no pueden ser realizados por el sistema.

103

Beneficios

• Este método permite la exploración de los requerimientos de usuario y de las cuestiones de usabilidad en etapas tempranas del proceso de desarrollo, de forma particular para sistemas que van más allá de la tecnología actualmente disponible.

• El miembro del equipo de diseño que desempeña el papel del mago puede adquirir valiosas perspectivas gracias a su proximidad con la actividad del usuario

Limitaciones

• El miembro del equipo de diseño que desempeña el papel de mago debe dominar la funcionalidad del sistema propuesto para llevar a cabo una representación convincente

• Este método requiere una consideración de recursos más amplia que otras aproximaciones de prototipado como aquellas que se basan simplemente en papel

Beneficios y limitaciones del prototipado por Mago de Oz

Se requerirían dos sistemas, uno para el usuario y otro para el "mago".

Se requieren dos equipos para llevar la evaluación: uno para desempeñar el papel del mago y otro para aleccionar al usuario y registrar la sesión. El mago debe ser un miembro experimentado del equipo de diseño para que las respuestas del sistema sean lógicas y no queden más allá de lo posible. El tiempo a emplear depende del dominio de la tarea y del número de usuarios expuestos al prototipo. ¿Cómo se puede llevar a cabo esta técnica?

Se pueden distinguir una serie de pasos básicos para la

implementación de un proceso de estas características:

1. Se ha de precisar de tiempo suficiente para fabricar el prototipo del Mago de Oz, diseñar algunas tareas, reclutar usuarios, conducir la evaluación del prototipo e informar de los resultados.

2. Asignar el papel del mago y el de moderador a miembros relevantes del equipo.

3. Disponer del equipamiento necesario. 4. Desarrollar el prototipo. 5. Seleccionar a los usuarios apropiados para testar el prototipo, intentando

cubrir un amplio rango de usuarios dentro de la población objetivo. 6. Preparar escenarios de tareas realistas para la evaluación. 7. Desarrollar un procedimiento de evaluación piloto y asegurar que el

"mago" ha practicado lo suficiente en el desempeño de su papel de sistema.

8. Asegurar que el equipo de registro está disponible y funcionando. 9. Conducir la sesión. el moderador alecciona al usuario en su trabajo a

través de las tareas seleccionadas interactuando y respondiendo al sistema de forma apropiada.

10. Realizar una sesión posterior de entrevistas con los usuarios, formulando preguntas y aspectos que hayan surgido durante el uso del prototipo.

11. Informar y agradecer al usuario su colaboración.

104

12. Analizar la información obtenida y resumir las observaciones y las evaluaciones de usuario. Determinar los temas y la severidad de los problemas identificados.

13. Resumir las implicaciones de diseño y las recomendaciones para las mejoras e informar al equipo de diseño. las grabaciones de vídeo pueden servir de gran ayuda.

14. Refinar el prototipo donde sea necesario y repetir el proceso anterior.

De forma adicional, conviene tener en consideración las siguientes guías prácticas: • Explicar de antemano a los usuarios la idea del Mago de Oz y que el

sistema está siendo manipulado por otra persona. Esto evitará el sentimiento entre los usuarios de estar siendo objeto de broma por parte de los evaluadores.

• Practicar con antelación para asegurar la sincronización con el usuario. • Conviene evitar alargar la sesión, pues el cansancio del "mago" puede

perjudicar la interacción.

105

V. Métodos de

Inspección de la Usabilidad en los procesos DCH

106

5.1 Introducción El sexto proceso para un Desarrollo Centrado en el Hombre consiste

en evaluar los diseños contra los requerimientos. El objetivo es el de reunir retroalimentación sobre el diseño en desarrollo de los usuarios finales y otras fuentes representativas. Esta retroalimentación contribuye a la mejora del proceso. Ahora se evaluará si los objetivos sobre la organización y los implicados han sido logrados o no y se monitorizará el uso a largo plazo del sistema.

En las etapas tempranas del proceso de desarrollo y el proceso de diseño, los cambios son relativamente baratos. Cuanto más haya progresado el proceso y cuanto más completamente está definido, más cara será la introducción de cambios. Así pues, es importante comenzar la evaluación lo más pronto posible.

Habitualmente se hablará de inspecciones en lugar de evaluaciones,

si bien la variante más conocida de las Inspecciones Formales de Usabilidad recibe el nombre de Evaluación Heurística y los análisis cognitivos de especificaciones, prototipos o sistemas se denominan habitualmente revisiones.

Como se verá seguidamente, las inspecciones pueden llevarse a

cabo, además, de forma específica sobre estándares o bien sobre las características específicas del sistema o la consistencia entre los distintos elementos o partes en caso de que las hubiera.

5.2 Inspecciones Formales de Usabilidad (Formal Usability Inspections) Las inspecciones formales de usabilidad toman la metodología de

inspección del software y la adaptan a la evaluación de usabilidad. Las inspecciones de software, más conocidas como inspecciones de código, comenzaron en IBM como una formalizar el registro y descubrimiento de los problemas de software (defectos, en la jerga de calidad y bugs en la vernácula). Esta técnica también proporcionó medidas cuantitativas que podía ser seguidas mediante métodos estadísticos para el control de procesos. La inspecciones de código fueron igualmente adaptadas para la comprobación y seguimiento de los defectos en la documentación, siendo los defectos de usabilidad el siguiente paso lógico.

107

Las inspecciones de usabilidad incluyen igualmente aspectos de otros métodos de inspección. Las heurísticas son utilizadas como una ayuda para los no profesionales de la usabilidad en la búsqueda de defectos. Los inspectores 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. ¿Cómo se puede llevar a cabo esta técnica?

Una inspección formal de usabilidad se completa en seis pasos lógicos. Estos pasos lógicos aseguran que la detección de defectos y la descripción del proceso se completan de forma eficiente y efectiva, quedando vinculada a un ciclo de vida centrado en el usuario más amplio. Paso 1. Planificación______________________________________

El moderador y el propietario trabajan juntos para asegurar que va a tomar parte de la inspección el personal apropiado, y que este tendrá el acceso a la información requerida para inspeccionar las tareas de usuarios de forma eficiente y efectiva. Para conseguir estos objetivos, el moderador y el propietario: 1. Definirán los Objetivos de la Inspección - Qué es lo que quieren

conseguir. 2. Elegirán los Miembros del Equipo - Moderador, propietario, inspectores

y encargado de registro. (Ver tabla " Los miembros del equipo deberían representar la mayoría de estas áreas de conocimiento")

Área de conocimiento Descripción Ingeniero de Diseño Ingenieros de hardware o software que han estado

involucrados en el desarrollo del producto. Conocen bien el producto y está capacitados para generar soluciones de diseño. Los diseñadores de alto nivel aportan un valor adicional en la revisión.

Ingeniero de Producto Un ingeniero de un producto ya existente o relacionado con aquel sometido a estudio sirve como reconocido inspector, no estando influenciado por el conocimiento de la evolución del producto. Este inspector reconocerá inconsistencias del producto frente a otros similares.

Ingeniero de Documentación Se trata de la persona que ha escrito o escribirá la documentación asociada al producto.

Ingeniero de Factores Humanos Se trata de una persona con amplia experiencia en la interacción con los usuarios, en la detección de defectos y en la generación de soluciones.

Ingeniero de Mantenimiento El ingeniero de mantenimiento tiene una amplia experiencia con productos similares al sometido a estudio, así como en la resolución de problemas en campo.

Los miembros del equipo deberían representar la mayoría de estas áreas de conocimiento

108

3. Desarrollarán el Paquete de Inspección, una colección de documentos de los que dispondrán y harán uso los inspectores, que incluirán:

• Instrucciones para la Inspección - Una descripción de cómo hacer uso de los componentes del paquete de inspección en la búsqueda de defectos.

• Descripción del Producto - Se trata de una explicación el producto mediante un prototipo, una presentación de escenarios,...

• Documentación de Apoyo - Información requerida por los inspectores, por ejemplo datos demográficos, estándares, datos relacionados con otros productos...

• Perfiles de Usuario - Una descripción sucinta para cada tipo de usuario.

• Escenarios de Tareas - Una descripción sucinta para cada tarea de usuario (las instrucciones pueden incluir indicaciones sobre qué perfiles de usuario son relevantes para qué escenarios)

• Modelo para la Realización de Tareas - Se trata de un modelo abstracto que resume el flujo de tareas (Ver tabla "Preguntas que se formula el inspector para la realización de las tareas")

Percepción ¿Ve el usuario la información que él o ella necesita?

¿Puede determinar el usuario si se ha conseguido la meta final? ¿Qué problema podría tener el usuario identificando:

• el estado actual del producto? • que la acción elegida sea realizada? • que la acción elegida sea correcta? • un error de estado? • acciones apropiadas para la recuperación de los errores?

Planificación

¿En qué plan o modelo se va a basar el usuario según la experiencia previa con tareas similares? ¿Cómo define el usuario su meta? ¿Qué apoyo tiene el usuario para seleccionar o crear el plan apropiado? ¿Se ajustan las metas requeridas para el producto con las metas de usuario o tiene que transformar el usuario sus metas en las del producto?

Selección ¿Qué problemas podría tener el usuario identificando las acciones disponibles? ¿Hay acciones en competencia que el usuario podría seleccionar por error? ¿Qué mecanismos de ayuda se han dispuesto para que el usuario elija la opción apropiada?

Actuación

¿Qué problemas podría tener el usuario en el momento de la realización física de la acción seleccionada? ¿Qué acciones accidentales podrían ocurrir? ¿Son estas acciones algo que podría hacer el usuario o serían cosa del producto? ¿Cuánto tiempo lleva la realización de la acción incluidos tiempos de espera? ¿Resulta razonable?

Preguntas que se formula el inspector para la realización de las tareas (Shneiderman 1987, Nielsen y Molich 1990, y otras fuentes)

• Heurísticas - Principios globales a los que se refieren los defectos de usabilidad más comunes. (Ver tabla "Heurísticas basadas en las tareas y heurísticas basadas en los usuarios")

109

Heurísticas basadas en tareas: Heurísticas basadas en usuario: Minimizar las acciones precisas para llevar a cabo una tarea Asistir el flujo natural de tareas No solicitar de los usuarios que hagan lo que el sistema puede hacer mejor Proporcionar mínimos (por defecto) Proporcionar atajos Facilitar las opciones de deshacer, rehacer, detenerse, reanudar Evitar la posibilidad de que el trabajo realizado sea dañado o destruido Hay que asegurar que los errores puedan ser solventados con poco trabajo extra (en particular, en lo que se refiere a “rehacer”) No hay que hacer perder tiempo al usuario Hay que proporcionar salidas claramente definidas

Hay que proporcionar un modelo mental que se ajuste sobre modelos mentales preestablecidos Hay que utilizar un diálogo simple y natural Hay que hablar el lenguaje del usuario Hay que ser consistente Hay que proporcionar una disposición visual intuitiva de la interfaz de usuario Cada característica debe estar bien diferenciada una de otra. Hay que hacer las funcionalidades obvias y accesibles Hay que proporcionar mecanismos de ayuda apropiados Hay que admitir diversos niveles de capacidad y uso Hay que contemplar la posibilidad de que el usuario quiera acomodar el sistema a sus características, preferencias,... El usuario ha de tener el control de la interfaz y de la tarea que lleva a cabo a través de la gestión de la misma El sistema ha de proporcionar “feedback”, indicando su estado en los diversos momentos para minimizar la incertidumbre del usuario Hay que minimizar la necesidad de memorizar y de procesar mentalmente Hay que minimizar los modos de funcionamiento Hay que diseñar para los errores de usuario Hay que aislar al usuario de los detalles de la implementación

Heurísticas basadas en las tareas y heurísticas basadas en los usuarios (Adaptado de Usability Inspection Methods. Nielsen, Mack, 94)

• Formulario para el Registro de Defectos - Formulario

utilizado por los Inspectores para el registro de defectos. • Horario y Localización de las Reuniones.

Paso 2. Reunión para la toma de contacto________________________

Durante una primera reunión para la toma de contacto, el moderador y el propietario van a proporcionar a los inspectores el paquete de inspección y van a discutir sus contenidos. El moderador indica cómo deberían proceder los inspectores en la búsqueda de defectos mediante la consideración de perfiles de usuario, escenarios de tareas, el modelo para la realización de tareas y las heurísticas. Asimismo, el moderador indica que la inspección representa un espacio de tiempo que se ha dispuesto para que los inspectores encuentren defectos de usabilidad. Paso 3. Preparación________________________________________

Durante la preparación, el inspector trabaja por su cuenta. Primero, cada inspector debería familiarizarse con el contenido del paquete de inspección. Entonces, el inspector asume el papel de un usuario específico y trabaja recorriendo los pasos de una tarea concreta para completar un escenario en particular. En todo paso de una tarea en que el inspector no pueda realizar la tarea sin confusión, se registra un defecto de usabilidad. Asimismo, el inspector aplica el modelo para la realización de tareas y las heurísticas para detectar defectos. Los defectos, por su parte, habrán de

110

describirse como centrados en el usuario. El proceso de detección de defectos se repetirá para cada combinación apropiada de perfil de usuario y escenario de tarea.

Para cada defecto, el inspector registra el número de tarea, la localización del defecto y una descripción del mismo. Opcionalmente, el inspector podría optar por registrar una solución. Paso 4. Reunión de Registro_________________________________

Una vez que los inspectores han procedido por su cuenta, se van a reunir para tratar los defectos encontrados y para buscar más. En la reunión de registro, el moderador va a recorrer las diversas combinaciones de perfiles de usuario y escenarios de tareas. El moderador guiará a lo inspectores ahora a través de cada escenario de tareas, formulando preguntas como "¿Qué es lo siguiente que hace el usuario?" y "¿Tendrá el usuario algún problema aquí?".

En cada paso, los inspectores informan de los efectos que registraron durante su preparación. A medida que el moderador revela la secuencia correcta de pasos de la tarea, el inspector puede darse cuenta de que quizás completó la tarea de forma incorrecta y que informó de este error como un defecto. La sinergia de la reunión ayudará a los inspectores a encontrar nuevos defectos de los que también se informará.

El moderador dirigirá la reunión de modo que esta se enfoque en el usuario y en la tarea, siempre de forma eficiente y constructiva. En ocasiones, el moderador ayudará a los inspectores a describir los defectos dentro e un estilo "centrado en el usuario". El papel del propietario, por su parte, es el de actuar como un inspector (de forma opcional) y el de entender cada defecto del que se informe. El encargado del registro va a proceder de forma pública; esto es, mediante un proyector, va a permitir ver a los inspectores qué es lo que se está registrando.

De forma opcional, se podrían aportar soluciones durante esta reunión, pero sería preferible limitarse, tan solo, al registro de ciertas ideas, dado que se corre el riesgo de caer en largas discusiones que hacen peligrar el atributo deseable de la rapidez. Al final de la sesión se puede proporcionar a cada inspector una lista de los defectos encontrados.

En estas sesiones los inspectores van a aprender, unos de otros, a

encontrar defectos. Un inspector poco experimentado encontrará pocos defectos durante su preparación. Durante la reunión e registro, este inspector comprobará cómo los demás han hecho uso de los perfiles de usuario, de los escenarios de tareas, del modelo para la realización de tareas y de las heurísticas para identificar defectos de usabilidad que pasó por alto.

111

Paso 5. Rediseño___________________________________________

Durante este paso, se encuentran soluciones y se implementan. Esto puede ser relativamente rápido si sólo hay un equipo de diseño y este se encuentra en una etapa temprana del proceso de desarrollo. Por otra parte, el moderador y el propietario podrían agrupar los defectos o proporcionar niveles de severidad.

Cuando sea necesario, los inspectores, y otro personal apropiado, s reunirá para generar ideas o identificar soluciones. El propietario y los responsables de los defectos encontrados seleccionarán e implementarán las soluciones apropiadas. El moderador, por su parte, proporcionará la retroalimentación apropiada a los inspectores.

En algunos casos, el moderador examina el producto o contacto con

ingenieros o técnicos para asegurarse de que las soluciones están siendo implementadas. Paso 6. Resultados y conclusiones_____________________________

Finalmente, el moderador va a reunir, evaluar e informar de los datos obtenidos del proceso de inspección. Diferentes equipos de inspección pueden evaluar los datos para diversos niveles de detalle. La mayoría de los equipos están interesados en el número de defectos verificados en el número de horas dedicadas (como medida de eficiencia) y en el número de defectos verificados frente a los que se han solucionado (como medida de efectividad)

Completar una inspección formal de usabilidad proporciona un número de beneficios:

• Beneficios específicos para el producto: - El equipo de diseño tiene una lista de defectos y de soluciones

implementadas. El producto es más usable. - El test de usuario será más eficiente y efectivo puesto que los usuarios

encontrarán menos problemas - El equipo de diseño está aplicando diseño centrado en el usuario - El equipo de diseño tiene perfiles de usuario y escenarios de tareas,

que van a poder ser reutilizados para futuras inspecciones y tests de usuario

• Beneficios en el entrenamiento de los ingenieros

- Los ingenieros aplican el diseño centrado en el usuarios, lo que va a influir en los siguientes diseños.

- Se desarrolla una librería de soluciones de diseño que se amplia, se genera una historia

- Los participantes se familiarizan con el proyecto y puede apoyar al equipo de otras formas en el futuro.

112


Al igual que otros métodos de inspección, esta técnica está diseñada para reducir el tiempo requerido para descubrir defectos en un ciclo de diseño rígido. Dado que los inspectores pueden trabajar con una mera especificación o maquetas de papel, la técnica resulta apropiada en etapas tempranas del desarrollo. 5.3 Evaluación Heurística (Heuristic Evaluation) 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. Este método forma parte del que se conoce como "discount usability engineering" o "ingeniería de la usabilidad rebajada". Evaluación heurística resulta casi un nombre estrafalario para significar que un grupo de expertos escudriñan la interfaz y evalúan cada uno de sus elementos ante una lista de principios, heurísticas, comúnmente aceptadas. Inicialmente, esta lista fue muy larga, dando lugar a tediosas sesiones de evaluación y expertos agotados que casi terminaron con el propósito inicial de ahorrar tiempo y dinero en el test. Nielsen redujo la lista a un número de diez, resultando suficiente y aceptable para cualquier evaluación de diseños. ¿Cómo se puede llevar a cabo esta técnica? Hay que conseguir a los expertos_____________________________ Es preciso reunir a un cierto número de expertos para realizar la evaluación. Desde luego, cuanto mayor sea el número de expertos ante la interfaz, mayor será el número de errores que se podrán encontrar, pero el coste se disparará. En un análisis sobre seis de sus estudios, Nielsen concluyó que se podría encontrar la mayoría de los problemas de usabilidad con un número de evaluadores entre tres y cinco. La experiencia demuestra que determinados problemas son encontrados sólo por unas pocas personas. Sin embargo, quien encuentra los problemas más difíciles no es, necesariamente, quien más problemas encuentra. Por otra parte, tampoco es necesariamente cierto que la misma persona resulte ser el mejor evaluador en cada ocasión, esto es, no se

113

puede confiar la evaluación a un único individuo ya que no existe el mejor evaluador. En principio, un evaluador individual puede llevar a cabo una evaluación heurística de una interfaz de usuario, pero los resultados tienden, en general, a ser pobres Son precisas algunas consideraciones acerca de la selección de los expertos. Lógicamente, se buscan expertos, gente que sepa lo que hace, con un amplio historial en la evaluación de la usabilidad y en el diseño de interfaces hombre - computadora (IHC). Además, el experto en cuestión habría de dominar todo lo referente al producto objeto del estudio. De conseguir a alguien así, habríamos avanzado muchísimo. Un ejemplo podría ser una aplicación del tipo "calcule usted mismo sus impuestos" (¿podría encontrar a un experto en HCI que domine la contabilidad?). Los expertos evalúan por su cuenta y después comparan sus hallazgos Una vez que se dispone de los especialistas, estos han de proceder a efectuar la evaluación individualmente. Necesitan fijarse en la interfaz ellos solos y que sus compañeros no influyan de ninguna forma en ellos. Asimismo, será preciso asignarles los papeles y los escenarios a utilizar de modo que puedan adquirir la disposición mental y la perspectiva apropiada cuando hayan de interactuar con el producto. Si los usuarios del producto van a disponer de elementos como manuales o ayudas en línea, los evaluadores también habrán de disponer de ellos. De hecho, se les requiere para evaluar el conjunto total de nuestro producto.

Hoja de evaluación de problemas

Número de problema:

Descripción del problema y por qué motivo lo considera como tal:

¿Cómo se encontró el problema?

¿A qué heurística afecta este problema?

Hoja de evaluación de problemas

El experto revisará la interfaz al menos dos veces, fijándose en cada elemento de la misma (cada menú, control, botón,...) y evaluando su diseño, localización e implementación de acuerdo con la lista de heurísticas.

114

Una escala de severidad apropiada para la clasificación de los

problemas de usabilidad_____________________________________

La escala de severidad de los problemas de usabilidad debería tener los mismos niveles que la escala de los errores y problemas en el sistema que se está desarrollando. Si se plantea una escala del 1 al 5 siendo 1 el problema más severo, la escala de severidad también habrá de ir de 1 a 5. A la hora de valorar la severidad de los problemas de usabilidad deberían ser considerados los siguientes atributos: - Realización - Probabilidad de pérdida de datos críticas - Probabilidad de error - Violación de estándares - Impacto en los beneficios, ingresos o gastos - Estética, legibilidad, desorden Los niveles pueden ser definidos de la siguiente manera:

• Nivel 1.- Error catastrófico causando pérdidas de datos irrevocables o daños al hardware o software del sistema. Fallos a gran escala que impiden la realización del trabajo de muchas personas. La realización es tan mala que el sistema no puede alcanzar las metas de negocio

• Nivel 2.- Problemas severos causando posibles pérdidas de datos. El usuario no encuentra forma de solucionar el problema por su cuenta y se requiere asistencia técnica para la resolución del problema.

• Nivel 3.- Problemas moderados que causan la pérdida no permanente de información, pero se pierde tiempo. Existen mecanismos para superar el problema por parte del usuario. las inconsistencias internas se traducen en un incremento del aprendizaje y las tasas de error. Una función o característica importantes no trabaja como se esperaba

• Nivel 4.- Problemas menores pero irritantes. En general no causa pérdidas de datos pero la sucesión de problemas ralentiza la actividad de los usuarios. Violaciones mínimas de las percepciones afectan a la apariencia o la percepción y errores que son recuperables

• Nivel 5.- Errores mínimos. Los problemas son extraños y no causan pérdidas de datos ni pérdidas de tiempo mayores. Aspectos menores de consistencia o cosmética.

115

Los expertos proporcionan la información obtenida_________________ Cuando los expertos llevan a cabo la evaluación, pasan a proporcionar la información obtenida de diversas formas. Estos son algunos de esos métodos: Un informe estructurado____________________________________ El experto escribe un informe formal con sus hallazgos, siendo probablemente esta la mejor forma de asimilarlos, dado que habrá recopilado todas las notas tomadas y las habrá resumido y organizado, lo que previsiblemente podría demorar su respuesta. Expresión oral de los hallazgos_______________________________ Mientras evalúa la interfaz, el experto dicta sus hallazgos a otra persona. Aunque esto incrementa el coste, va a ser posible descubrir una serie de problemas que hubieran sido pasados por alto si los expertos hubieran de anotar ellos mismo todas sus observaciones. Así, comentarios no estructurados como "¿En qué #{*&%+@$ estaba pensando el diseñador?" pueden ser captados de esta forma. Categorías_____________________________________________ Antes de que los expertos se dispongan a efectuar las evaluaciones, todo el mundo se pone de acuerdo en las categorías en las que se habrían de clasificar los problemas que van a registrar. Si bien el análisis posterior va a resultar más simple, podrían perderse ciertos detalles que otras metodologías podrían encontrar. Los expertos se reúnen entonces para discutir los hallazgos individuales. En la mayoría de las ocasiones se genera un resumen de los problemas de usabilidad encontrados tanto si los evaluadores discrepan como si un aspecto particular no constituye un auténtico problema. La mayoría de los informes indican la heurística o heurísticas no respetadas, proporcionando una orientación para su solución. ¿Cuándo debería usarse esta técnica? 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. Se puede proporcionar maquetas de papel o incluso especificaciones de diseño a los expertos y detectar una buena cantidad de problemas de usabilidad antes de que el trabajo real de producción de comienzo.

116

Lista de heurísticas de Usabilidad Seguidamente se presenta la lista original de heurísticas desarrolladas por Nielsen y Mölich en 1990 contemplando los diversos aspectos que caracterizan una interfaz de usuario. Esta lista debería ser seguida por todos los diseñadores de interfaces de usuario. Para cada heurística se indica a modo de ilustración alguna de las materializaciones de las mismas. Tras esta lista se presenta en una tabla la revisión por Nielsen de sus heurísticas en 1994. 1. Diálogo simple y natural Los diálogos no deben contener información irrelevante o de dudosa necesidad. Cada unidad extra de información compite con unidades relevantes de información disminuyendo su visibilidad relativa. Toda la información debe aparecer en un orden natural y lógico. - Ha de resultar obvio cómo interactuar con el sistema. - En la interfaz aparece suficiente información. - La interfaz proporciona al mismo tiempo perspectiva y detalle. - Se evitan las decoraciones confusas. 2. Hablar el lenguaje de los usuarios El diálogo debería expresarse claramente en palabras, frases y conceptos familiares al usuario, más que en base a términos orientados al sistema. - El lenguaje del ámbito de aplicación. - Se evita el lenguaje propio del sistema. - Se hacen uso de metáforas familiares a los usuarios. - Los iconos, gráficas, ... que se presentan son relevantes en el ámbito

de la aplicación. 3. Minimizar la carga de memoria de los usuarios Los usuarios no deberían tener que recordar nada de una parte a otra del diálogo. las instrucciones para el uso del sistema deberían estar siempre visibles o fácilmente accesibles siempre que sea apropiado - En la interfaz aparece información suficiente para que el usuario

pueda proceder. - El usuario reconoce y no tiene que volver atrás para identificar su

situación actual. - Se destaca la información importante. - Se muestra el estado de la información. - Se proporcionan valores por defecto allá donde sea apropiado. 4. Consistencia

117

Los usuarios no deberían tener que preguntarse se diferentes palabras, situaciones o acciones significan lo mismo. - Consistencia en la disposición de la interfaz. - Consistencia en la interacción. - Consistencia en el lenguaje. - Consistencia en la funcionalidad. 5. Feedback (Retroalimentación) El sistema debería mantener siempre informados a los usuarios sobre lo que está sucediendo, a través de un feedback apropiado, dentro de un período de tiempo razonable - Se muestran los tiempos de espera. - Retroalimentación para las acciones. - Retroalimentación relacionada con el trabajo en curso. - Fallo del sistema. 6. Salidas claramente señaladas Los usuarios eligen a menudo funciones del sistema por error y precisan de una "salida de emergencia" claramente referida para abandonar el estado no deseado sin tener que pasar por un extenso diálogo - Mostrar el camino que ha recorrido el usuario a través del sistema. - Cómo se puede avanzar y retroceder en un determinado momento. - El usuario ha de orientarse en el espacio de la información. 7. Cortocircuitos (Shortcuts) Los "aceleradores", desconocidos por el usuario novel, suelen incrementar la velocidad de interacción del usuario experto de modo que el sistema puede dar cobertura a ambos tipos de usuarios, experimentados o no. - Se puede hacer uso de "cortos" para llevar a cabo las acciones. - Es posible un salto directo a una localización deseada. - Se puede reutilizar la historia de la interacción con la interfaz. 8. Mensajes de error apropiados Deberían expresarse en un lenguaje sencillo (nada de códigos), indicando de forma precisa el problema y sugiriendo una solución de forma constructiva - Evitar los datos en formato propios del código interno de la máquina. - "Ha ocurrido un error Nº 13" - Hay que hacer uso del lenguaje del usuario. 9. Prevenir los errores Mucho mejor que unos buenos mensajes de error es un diseño cuidadoso que evite la ocurrencia de un problema. - Hay que generar diálogo para aquellas acciones que pueden llevar a

consecuencias serias.

118

- Hay que evitar los "modos de operación" - Hay que mostrar el estado actual del sistema. - Facilitar las opciones de "deshacer" y "rehacer". 10. Ayuda y documentación Aunque lo ideal sería que el sistema pudiera ser utilizado sin ningún tipo de documentación, puede ser necesario ayuda y documentación. Cualquiera de esta información debería ser fácil de encontrar, estar enfocada en la tarea del usuario, listar pasos concretos para llevarla a cabo y no ser demasiado extensa. - Los manuales no deberían ser necesarios. - Proporcionar ayuda en línea a los usuarios. - Si no hay otras soluciones posibles, se proporciona ayuda según la

iniciativa del sistema. • Visibilidad del estado del sistema El sistema debería mantener siempre informados a los usuarios sobre lo que está sucediendo a través de una retroalimentación apropiada dentro de un lapso de tiempo razonable. • Correspondencia entre el sistema y el mundo real El sistema debería hablar el lenguaje del usuario, con palabras, frases y conceptos familiares al usuario en lugar de términos orientados al sistema. Hay que seguir las convenciones del mundo real, haciendo aparecer la información en un orden natural y lógico. • Control y libertad por el usuario Los usuarios eligen a menudo funciones del sistema por error y necesitarán una "salida de emergencia" claramente diferenciada para abandonar el estado no deseado sin tener que recorrer un extenso diálogo. Hay que facilitar las opciones de "deshacer" y "rehacer". • Estándares y consistencia Los usuarios no deberían tener que preguntarse si diferentes palabras, situaciones o acciones significan lo mismo. Hay que seguir las convenciones de plataforma. • Prevención de errores Mucho mejor que elaborar buenos mensajes de error es llevar a cabo un cuidadoso diseño que evite que el problema ocurra en primer lugar. • Reconocer en lugar de retroceder Hay que hacer los objetos, las opciones y las acciones visibles. Los usuarios no deberían tener que recordar información de una parte del diálogo a otra. Las instrucciones para el uso del sistema deberían ser visibles o fácilmente accesibles siempre que fuera preciso. • Flexibilidad y eficiencia de uso Los "aceleradores", inadvertidos por los usuarios noveles, incrementan a menudo la velocidad de interacción para el usuario hasta tal punto que el sistema puede dar cobertura tanto a los usuarios expertos como a los inexpertos. Hay que permitir a los usuarios la posibilidad de acomodar diversas opciones. • Diseño estético y minimalista Los diálogos no deberían contener información irrelevante o raramente requerida. Cada unidad extra de información en un diálogo compite con unidades relevantes de información y disminuye su visibilidad relativa. • Ayudar a los usuarios a reconocer, diagnosticar y recuperarse de los errores Los mensajes de error deberían expresarse en un lenguaje sencillo (nada de códigos), indicando de forma precisa el problema y sugiriendo de forma constructiva una solución. • Ayuda y documentación Aunque lo ideal es que el sistema pudiera ser utilizado sin documentación, puede ser preciso proporcionar ayuda y documentación. Cualquier información debería ser fácil de buscar, enfocada en la tarea del usuario, con una lista de pasos concretos para desarrollar y no demasiado extensa. (Heurísticas de Usabilidad revisadas por Nielsen en 1994)

Ejemplo: Heurísticas de hardware Heurísticas de hardware- Testando un diseño hardware (Chauncey Wilson, WillDesign consulting and Dick Miller, Hewlett-Packard, Usability Interface, Vol 5, No. 1, July 1998)

119

1. ¿Son accesibles todos los controles e interruptores sin riesgo de ser activados de forma inadvertida? 2. ¿Se requiere algún tipo de herramienta especial para el mantenimiento? 3. ¿Se han codificado todas las conexiones de modo que no es posible llevar un elemento erróneo al enchufe erróneo? ¿Se hace uso de alguna codificación basada en color, texto o formas de los conectores? 4. ¿Son visibles todas la advertencias sobre riesgos y medidas de protección? 5. ¿Son visibles todos los controles en el rango de condiciones luminosas que se esperan? 6. ¿Existe una retroalimentación apropiada sobre cualquier funcionamiento erróneo del sistema? 7. ¿Tienen lugar movimientos repetitivos que pudieran causar lesiones como el síndrome del túnel carpal? ¿Qué formas de protección pueden plantearse a este respecto? 8. En caso de que el sistema funcione con baterías, ¿se advierte al usuario ante una potencial pérdida de datos? ¿Es sencillo el cambio de las baterías? ¿Es posible encontrar baterías con facilidad? 9. ¿Hay aristas o bordes que puedan causar heridas o daño de algún tipo? 10. ¿Puede sobrevivir el sistema a un razonable "test de tortura"? ¿sobreviviría el teléfono móvil a una caída desde una altura de dos metros, por ejemplo? 11. ¿Hay que tener en cuenta consideraciones de resistencia y robustez? ¿ Pueden los usuarios realizar las tareas de forma adecuada cuando están fatigados? 12. En caso de usar sonido como mecanismo de retroalimentación, es conveniente - evitar sonidos extremos - no sobrecargar el canal auditivo - hacer uso de sonidos que puedan ser distinguidos fácilmente sobre el ruido de fondo,. evitando conflictos con los sonidos previamente utilizados - hacer uso de sonidos que siempre signifiquen lo mismo - hacer uso de pistas redundantes siempre que sea posible par los controles 13. ¿Han sido diseñados los controles para su uso por personas con discapacidades físicas? 14. ¿Pueden ser encontrados rápidamente todos los controles, incluso para nuevos usuarios o usuarios bajo situaciones de estrés? 15. ¿Se hacen uso de patrones consistentes para la interacción? 16. ¿Se dispone de una relación control/respuesta óptima? ¿Es posible adaptarlo? 17. ¿Puede ser utilizado el sistema por múltiples usuarios bajo diferentes condiciones? 18. ¿Acomoda el hardware las dimensiones de individuos entre los perceptibles 5 y 95? 19. ¿Es compatible la disposición física de los controles y los displays? 20. ¿Se están siguiendo estereotipos poblacionales? 21. ¿Resulta el producto fácilmente ajustable en todas las dimensiones requeridas? 22. ¿Resulta fácil la alimentación física del sistema? 23. ¿Se protege al usuario ante errores catastróficos?

Ejemplo: Revisión de una pantalla en proceso de diseño Revisión heurística para retroalimentación rápida sobre una pantalla en proceso de diseño (Wendy Naughton , Usability & Technical Documentation, Xerox Corporation, 1995) Información en pantalla Nombre del sistema:__________________ Aplicación:_________________ Nombre de la pantalla:_________________ Diseñador:_________________ Descripción de la pantalla:_______________________________________________ _____________________________________________________________________ _______________________________________________________________________________________________________________________________________________________________________________________________________________ Lista de Comprobación Criticidad del requerimiento Bajo Medio Alto Diseño de la interfaz de diálogo Lenguajes y frases familiares para el usuario Organización de la información en pantalla de forma natural y lógica

Facilita la toma de decisiones y el procesamiento de tareas del usuario

Proporciona salidas obvias y rápidas para el usuario

Soporta las funcionalidades de "deshacer" y "rehacer"

120

Previene los errores de usuario Proporciona mensajes de error que indican los procesos de error y recuperación

Proporciona pistas visuales para facilitar el procesamiento de tareas

Permite un procesamiento rápido y fácil para los usuarios experimentados mientras que asiste a los usuarios noveles

Organiza la información que no se utiliza de forma habitual para promover la visibilidad de todos los elementos de diálogo importantes

Proporciona pistas visuales consistentes y fácilmente accesibles (botones de ayuda)

Es rápido y fácil de usar Proporcionan retroalimentación al usuario y el estado del sistema cuando es requerido

Es diseñado para ser visualmente atractivo al usuario permite un procesamiento de tareas rápido, preciso y completo

Proporciona características de seguridad para proteger la información personal y privada

Contempla los requerimientos de personas con discapacidades físicas

Es consistente con otros diálogos diseñados para este sistema

Trabaja bien dentro de las condiciones específicas del entorno de procesado

Se ajusta con los estándares de Xerox Internacional

Se ajusta con los estándares de Xerox Global Comentarios y sugerencias: _______________________________________________ _____________________________________________________________________ _____________________________________________________________________ __________________________________________________________________________________________________________________________________________ Evaluación proporcionada por:____________________ Contacto:_________________ Fecha de la evaluación:___________________________________________________

5.4 Otros tipos de Inspecciones

En ocasiones, no se evalúa la totalidad del sistema sino que se opta por un conjunto determinado de características, se inspecciona la consistencia entre los diversos integrantes del sistema en cuestión o se opta por comprobar si se cumplen los estándares de aplicación al producto. Se puede hablar entonces de: - Inspecciones de Características (Feature Inspections). - Inspecciones de Consistencia (Consistency Inspections) - Inspecciones de Estándares (Standard Inspections) 5.4.1 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

121

usuario para el resultado final a obtener del uso del producto. Por ejemplo, un escenario de usuario habitual para el uso de un procesador de textos es escribir una carta. Las características utilizadas incluirían la entrada de texto, su formato, la comprobación de su corrección, guardar el texto en un archivo e imprimir la carta. Cada conjunto de características requeridas para una determinada salida (una carta), se analiza sobre la base de su disponibilidad, entendimiento y utilidad general. ¿Cómo se puede llevar a cabo esta técnica?

Hay que disponer en una lista el conjunto de características en la secuencia que han de ser llevadas a cabo para la realización de diversas tareas. Hay que fijarse en la accesibilidad de cada característica en el contexto de cada tarea. ¿Puede acceder el usuario a cada una de ellas sin problemas? ¿Están dichas características apropiadamente nombradas, son fácilmente reconocibles?

Una forma de llevar a cabo una inspección de características de una sola vez es intentar que el equipo de documentación documente cada escenario como un procedimiento. Las características que resulten difícil de describir en la documentación resultarán con toda probabilidad de difícil identificación para el usuario en una primera aproximación. ¿Cuándo debería usarse esta técnica?

Esta técnica se utiliza con preferencia en las etapas intermedias del desarrollo. En este punto, las funciones del producto (para qué se va a utilizar) son conocidas. También se conocen los aspectos del producto que le interesan al usuario para obtener lo que desea del mismo. La pregunta que permanece es: ¿qué dificultad hay en el uso de dichos aspectos? 5.4.2 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. Por ejemplo, en una suite de ofimática, las funciones comunes deberían tener el mismo aspecto y trabajar de la misma forma tanto si el usuario está utilizando el procesador de texto, como si utiliza una hoja de cálculo, o una aplicación de presentaciones o de bases de datos.

Las inspecciones de consistencia parten del análisis por parte de un profesional de la usabilidad de las interfaces de todos los productos, advirtiendo las diversas formas en que cada producto implementa una determinada función o interacción por parte del usuario. Entonces se reúne

122

un equipo de evaluación y , a partir del análisis de usabilidad, negocia y decide una única implementación ideal para los atributos de usabilidad de cada producto. ¿Cómo se puede llevar a cabo esta técnica?

Se empieza constituyendo un equipo de inspección, disponiendo miembros de cada equipo de desarrollo para todos los productos cubiertos por la inspección. Estos miembros habrán de tener la autoridad para negociar a favor o en contra de los diferentes elementos de diseño, así como el poder de introducir cambios en su diseño del producto en una posterior reunión de revisión. Cada producto será analizado por un profesional de la usabilidad, al igual que la respectiva interfaz de usuario, con un especial cuidado en aquellos aspectos que difieran en mayor grado respecto de los demás productos. Este documento inicial servirá de base para las discusiones del equipo durante una reunión posterior.

Durante dicha reunión se habrá de llegar a un acuerdo para cada elemento acerca de su apariencia y modo de trabajo en todos los productos. Dicho acuerdo habrá de ser unánime y de forma previa a la reunión se habrá procurado su aceptación por parte de los equipos de desarrollo de los productos.

Es preciso mantener un registro dinámico de las decisiones tomadas y de los cambios a realizar. Cualquier aspecto que no pueda ser resuelto rápidamente habrá de ser apartado y tratado con posterioridad de una forma más concreta. ¿Cuándo debería usarse esta técnica?

Esta técnica se utiliza preferentemente en etapas tempranas del desarrollo, cuando el trabajo inicial de desarrollo no ha progresado de forma suficiente como para que los productos que requieran grandes cambios para asegurar su consistencia no exijan modificaciones totales. El momento ideal para las inspecciones de consistencia es aquel en el que los documentos de diseño para cada producto están prácticamente terminados, y antes de que cualquier tipo de proceso de fabricación del producto de comienzo. 5.4.3 Inspecciones de Estándares (Standard Inspections)

Las inspecciones de estándares garantizan el ajuste a los estándares industriales. En tales inspecciones, un profesional de la usabilidad con extenso conocimiento del estándar en cuestión

123

analiza los elementos del producto en cuestión para su uso y acondicionamiento al estándar industrial.

Por ejemplo, productos de software diseñados para un entorno determinado deberían disponer de elementos comunes , como las mismas opciones en el menú Archivo, un menú de Ayuda, etc. O, también, 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. Muchos monitores o teclados tiene su uso restringido en ciertos países europeos debido a los estándares de seguridad e higiene de dichos países ¿Cómo se puede llevar a cabo esta técnica?

En la mayoría de los casos, la inspección debe llevarse cabo por un experto en el estándar. En un determinado entorno, podría se preciso que la inspección la llevara a cabo alguien representativo de la compañía productora, del mismo modo que, considerando los estándares nacionales de seguridad e higiene, podría ser preciso que la inspección fuera realizada por un miembro de la organización de estándares del país en cuestión. ¿Cuándo debería usarse esta técnica?

Esta técnica se utiliza preferentemente en etapas intermedias del proceso de desarrollo, teniéndose que el diseño real se estará llevando a cabo con la consideración de los estándares que correspondan. Para ciertos productos, la inspección de estándares puede ser el elemento que posibilite la transición del diseño inicial al análisis de fabricación y demás trabajo de ingeniería. Algunos estándares característicos en la Usabilidad y en el Diseño Centrado en el Usuario___________________________________

ISO 13407 (1999) Human-centred design processes for interactive systems ISO 6385:1981 Ergonomic principles in the design of work systems ISO 9001:1994 Quality Systems - Model for quality assurance in design, development, production, installation and servicing

ISO IEC 9126:1991 Information Technology - Software product evaluation - Quality characteristics and guidelines for their use

ISO 9241-1:1997 Ergonomic requirements for office work with visual display terminals (VDTs) - Part 1: General Introduction ISO 9241-2:1992 Ergonomic requirements for office work with visual display terminals (VDTs) - Part 2: Guidance on task requirements

ISO 9241-3:1992 Ergonomic requirements for office work with visual display terminals (VDTs) - Part 3: Visual display requirements

ISO 9241-4:1998 Ergonomic requirements for office work with visual display terminals (VDTs) - Part 4: Keyboard requirements

124

ISO 9241-5:1998 Ergonomic requirements for office work with visual display terminals (VDTs) - Part 5: Workstation layout and postural requirements

ISO 9241-6:- 2) Ergonomic requirements for office work with visual display terminals (VDTs) - Part 6: Guidance on the work enviroment

ISO 9241-7:1998 Ergonomic requirements for office work with visual display terminals (VDTs) - Part 7: Requirements for display with reflections

ISO 9241-8:1997 Ergonomic requirements for office work with visual display terminals (VDTs) - Part 8: Requirements for displayed colours

ISO 9241-9:- 2) Ergonomic requirements for office work with visual display terminals (VDTs) - Part 9: Requirements for non-keyboard input devices

ISO 9241-10:1996 Ergonomic requirements for office work with visual display terminals (VDTs) - Part 10: Dialogue principles

ISO 9241-11:1998 Ergonomic requirements for office work with visual display terminals (VDTs) - Part 11: Guidance on usability

ISO 9241-12:1998 Ergonomic requirements for office work with visual display terminals (VDTs) - Part 12: Presentation of information

ISO 9241-13:1998 Ergonomic requirements for office work with visual display terminals (VDTs) - Part 13: User guidance

ISO 9241-14:1997 Ergonomic requirements for office work with visual display terminals (VDTs) - Part 14: Menu dialogues

ISO 9241-15:1997 Ergonomic requirements for office work with visual display terminals (VDTs) - Part 15: Command dialogues

ISO 9241-16:- 2) Ergonomic requirements for office work with visual display terminals (VDTs) - Part 16: Direct-manipulation dialogues

ISO 9241-17:1998 Ergonomic requirements for office work with visual display terminals (VDTs) - Part 17: Form filling dialogues

ISO 9995:1994 Information Technology - Keyboard Layouts for text and office systems ISO 10075:1991 Ergonomic principles related to mental work-load - General Terms and Definitons ISO/IEC 10741-1:1995 Information technology - User System Interfaces - Dialogue interaction - Part 1: Cursor control for text editing

ISO/IEC 11581-1:- 2) Information technology - User System Interfaces - Icons symbols and functions - Part 1: Icons: General

ISO/IEC 11581-2:- 2) Information technology - User System Interfaces - Icons symbols and functions - Part 2: Object icons

ISO/IEC 11581-3:- 2) Information technology - User System Interfaces - Icons symbols and functions - Part 3: Pointers

ISO/IEC 14598-1:- 2) Information technology - Software product evaluation - Part 1: General Overview

5.5 Revisiones cognitivas (Walkthrough) El paseo cognitivo se plantea como una técnica de revisión donde los evaluadores expertos construyen escenarios para las tareas a partir de una especificación o de un prototipo temprano para captar después las reacciones de los usuarios trabajando con la interfaz en cuestión (paseando a través de la interfaz). Actuarán como si la interfaz estuviera completamente construida y si, como usuarios tipo estuvieran trabajando a través de las tareas que realizan. Se controla cada paso que ha de realizar el usuario: callejones sin salida en los que la interfaz bloquea al usuario y le impide completar su tarea indicarán que algo falta en la interfaz. Caminos complejos y sinuosos a través de las secuencias de funciones indicarán que la interfaz requiere de una nueva función que simplifique la tarea y evite el colapso.

Beneficios

• Se obtienen reacciones al diseño de modo informal • Los medios para obtener reacciones son flexibles, permitiendo que la

discusión entre los usuarios evolucione hacia aspectos que no se

125

habían considerado originalmente.

Limitaciones

• Requiere alguna forma de prototipo para la reacción de los usuarios • Los resultados son más opiniones que datos cuantitativos • Los usuarios pueden tender a reaccionar positivamente al ver un

prototipo operativo • Es difícil imaginar el modo en el que el sistema operará en el entorno

real Beneficios y limitaciones de la aplicación de las Revisiones Cognitivas

Se comienza evaluando el sistema en términos de las tareas que los usuarios realizarán con ese sistema. Ayudará identificar las metas de los usuarios y sus propósitos en cada tarea. Por ejemplo, la interfaz para operar con un automóvil comienza con los objetivos de abrir la puerta, sentarse en el asiento del conductor con todos los controles fácilmente accesibles y arrancar el coche. ¡Y eso que todavía no se está conduciendo!. Este método muestra la granularidad que en muchas ocasiones se requiere. Así el objetivo de abrir la puerta podría descomponerse en varias objetivos parciales, como encontrar la llave, orientarla, abrir la cerradura, abrir la puerta... Cada uno de estos objetivos requiere acciones de carácter físico y cognitivo. Para abrir la puerta, ¿se orienta la palma de la mano hacia arriba o hacia abajo?, ¿de cuántas formas se puede abrir la puerta?. Durante la aplicación de esta técnica hay que concentrarse en los objetivos. Por ejemplo, hay coches que sólo aceptan la llave si están orientadas de una forma. ¿Da lugar esto a un retraso inaceptable para el usuario? Dado que el objetivo parcial de abrir la puerta es un requisito previo para conducir el vehículo, se podría decir mucho al respecto.

Lógicamente, se requerirá de forma previa el desarrollo de un prototipo (aunque puede resultar de interés plantear una revisión de una versión anterior del producto de interés o del modelo actual de la competencia ). El tiempo invertido en las sesiones dependerá del dominio (ámbito) de la tarea y del número de usuarios expuestos al prototipo. ¿Cómo se puede llevar a cabo esta técnica? 1. Hay que decidir claramente los aspectos o escenarios de tareas que

deberían ser cubiertos durante la sesión (o lo que también se denomina como "definir las entradas a la revisión cognitiva") • ¿Quiénes serán los usuarios del sistema? ¿Se conoce cómo

describirían los usuarios las tareas a realizar? Los usuarios deben conocer qué efecto conseguir:

- porque es parte de su tarea original, o - porque tienen experiencia utilizando el sistema, o - porque el sistema lo solicita de ellos

Los usuarios deben saber que hay una acción disponible:

126

- por experiencia, o - porque advierten la presencia de algún dispositivo (como un botón), o - porque ven la representación de una acción (como la entrada de un

menú) Los usuarios deben saber que una acción es apropiada para el efecto que

están intentando conseguir: - por experiencia, o - porque la interfaz proporciona un aviso, advertencia,... que conecta la

acción con lo que están intentando hacer, o - porque todas las demás acciones parecen incorrectas

Los usuarios deben saber que las cosas van bien después de una acción: - por experiencia, o - reconociendo la conexión entre una respuesta del sistema y lo que

estaban intentando hacer

Algunos de los puntos anteriores enfatizan la importancia de conocer cómo describiría el usuario la tarea. Cuando el sistema hace uso de la misma terminología del usuario, el usuario escogerá las opciones correctas. A esto se le denomina a "estrategia del seguimiento de etiquetas". La retroalimentación será también significativa cuando se exprese en el vocabulario del usuario

• ¿Qué tarea o tareas serán analizadas? • ¿Cuál es la secuencia de acciones correctas para cada tarea y cómo

va a ser descrita? - Plantear una evolución creíble

Ejemplo: El cliente de un banco está utilizando un sistema telefónico para transferir fondos

entre dos cuentas. El sistema dice "introduzca su número de identificación de cliente" y el cliente lo teclea. - El usuario está intentando introducir un número porque el sistema lo solicitó. - El usuario procede con las teclas del teléfono porque están a la vista y no hay ningún

otro mecanismo disponible para introducir el número. - El usuario conoce su número de identificación de cliente porque lo memorizó cuando

el banco se lo asignó.

- El usuario considera que todo va bien cuando el sistema continúa y proporciona un menú de servicios

- ¿Intentará el usuario alcanzar el resultado correcto? - ¿Advertirá el usuario que está disponible la acción correcta? - ¿Asociará el usuario la acción correcta con el resultado que está

intentando conseguir? - Si se lleva a cabo la acción correcta, ¿entenderá el usuario que ha

progresado hacia la resolución de la tarea?

127

• ¿Cómo se define la interfaz? 2. Hay que establecer un buen mecanismo de registro: un individuo muestra

el sistema y formula preguntas y otro toma notas o graba en una cinta los comentarios para su posterior transcripción.

- Requerimientos sobre los conocimientos del usuario - Hipótesis sobre la población de usuarios - Notas sobre efectos colaterales y cambios en el diseño - El transcurso de una sesión con éxito 3. Seleccionar a los usuarios apropiados para participar en la sesión,

intentando cubrir un amplio rango de usuarios dentro de la población objetivo

4. Desarrollar una sesión piloto para estimar el tiempo requerido para cada

sesión 5. Asegurar que el equipamiento para el registro está disponible y

funcionando. 6. Conducir la sesión, asegurando que se van a cubrir todas las cuestiones

establecidas de antemano. 7. Analizar la información obtenida por los aspectos que hayan podido surgir

así como por los comentarios realizados. Conviene intentar determinar cuantos usuarios han podido realizar un mismo comentario. Considerar los temas y la severidad de los problemas identificados


prácticas: • Dar una introducción a los participantes de la sesión explicando los

objetivos de la misma • Describir con antelación el rango de tareas que se van a cubrir • Disponer el tiempo suficiente para discutir diferentes aspectos en

profundidad • Explicar a los participantes que no deben temer la formulación de críticas

al sistema • Instar a todos los participantes a expresar sus opiniones • Considerar el registro en audio de la sesión y la posterior transcripción

tras la sesión 1. Definir las entradas de la revisión cognitiva

Identificación de los usuarios

128

Tareas de muestra para la evaluación Secuencias de acciones para completar las tareas Descripción o implementación de la interfaz

2. Reunirse con los analistas 3. Revisar las secuencias de acciones para cada tarea

Plantear una evolución creíble ¿Intentará el usuario alcanzar el resultado correcto? ¿Advertirá el usuario que está disponible la acción correcta? ¿Asociará el usuario la acción correcta con el resultado que está intentando conseguir? Si se lleva a cabo la acción correcta, ¿entenderá el usuario que ha progresado hacia la resolución de la tarea?

4. Registrar información crítica Requerimientos sobre los conocimientos del usuario Hipótesis sobre la población de usuarios Notas sobre efectos colaterales y cambios en el diseño El transcurso de una sesión con éxito

5. Revisar la interfaz para solucionar problemas Perspectiva general de la Revisión Cognitiva (Nielsen, Mack 94)

¿Cuándo debería usarse esta técnica? Esta técnica resulta magnífica para etapas tempranas del desarrollo dado que puede ser aplicada tan sólo con una especificación del sistema como punto de partida. Además, la concepción artística acerca de qué aspecto deberían tener las interfaces puede servir para dotar de mayor realismo a la metodología. Habitualmente entran en juego entre uno y cuatro evaluadores y hasta dos desarrolladores: no hacen falta usuarios. Se cubre la característica de efectividad de la usabilidad y no se obtienen datos cuantitativos 5.5.1 Revisión Cognitiva Conjunta (Pluralistic Walkthrough).

Entendido como una variante más amplia de las Revisiones Cognitivas, se trata de reuniones en las que usuarios, desarrolladores y profesionales de la usabilidad recorren un escenario de tareas, discutiendo y evaluando cada elemento de la interacción. Con este tipo de grupos se cuenta con la ventaja de un diverso rango de capacidades y perspectivas para abordar los problemas de usabilidad. Como con cualquier otro método de inspección, cuanto mayor sea el número de personas buscando problemas, mayor será la probabilidad de encontrarlos. Del mismo modo, la interacción entre los miembros del equipo durante el proceso puede servir para resolver más rápidamente determinados aspectos de usabilidad. ¿Cómo se puede llevar a cabo esta técnica?

La mayoría de estas evaluaciones involucran a un grupo grande, con un profesional de la usabilidad como director de la sesión. El grupo puede

129

constar de usuarios finales, diseñadores de productos, personal de documentación y profesionales de seguridad e higiene además del equipo de usabilidad.

Todos los participantes, como si fueran uno, discutirán acerca de los escenarios derivados de las entradas al sistema por el usuario final. Los problemas de usabilidad serán identificados y clasificados sobre la base de la experiencia de los usuarios finales o los conocimientos de los profesionales de usabilidad para acciones futuras. ¿Cuándo debería usarse esta técnica?

Esta técnica se utiliza preferentemente en las etapas tempranas del desarrollo, dado que la información que proporcionan estas sesiones aparecen en forma de preferencias y opiniones del usuario.

Es una variante más amplia de la Revisión Cognitiva. Se puede trabajar con un experto en usabilidad, uno o dos desarrolladores y dos o tres usuarios. Se cubren los aspectos de efectividad y satisfacción y no se obtienen datos cuantitativos 5.6 Guías de Comprobación (Guidelines Checklist)

Las guías y las listas de comprobación van a contribuir a asegurar que los principios de usabilidad sean considerados en un diseño. Normalmente, las listas de comprobación se utilizan en combinación con algún método de inspección de usabilidad, proporcionando al inspector una base con la que comparar el producto.

En cualquier proyecto (Nielsen, 93) deberían utilizarse diversos niveles de guías: - guías generales, aplicables a todas las interfaces de usuario - guías para categorías específicas, para el tipo de sistema que está

siendo desarrollado - guías específicas de producto ¿Cómo se puede llevar a cabo esta técnica?

Hay que comenzar decidiendo qué tipo de listas se van a utilizar para

juzgar los atributos y los métodos de interacción de la interfaz de usuario. Se han publicado muchas guías que pueden ser utilizadas como tales, si bien

130

puede resultar de interés ajustar dichas guías con mayor exactitud a los aspectos a los que se enfrenta el usuario de nuestro producto. Dichas guías son, habitualmente, largas y lleva mucho tiempo recorrerlas y, dado que la comparación de la interfaz con la lista se habrá de realizar para cada atributo o parte de aquella, tal circunstancia no es, en absoluto, deseable.

También es recomendable tener en cuenta que las guías: - ayudan a mejorar la usabilidad de un diseño pero no la aseguran - especialmente se concentra en asegurar a consistencia entre

aplicaciones y productos - los usuarios no tiene porqué conocer los estándares, no tienen porqué

seguir las especificaciones ¿Cuándo debería usarse esta técnica?

Las listas de comprobación se utilizarían en la realización de inspecciones de usabilidad, como la evaluación heurística o la inspección de consistencia.

Ejemplo: Lista de comprobación para el diseño de quioscos de información accesibles (Proyecto INCLUDE) Localización y acceso al terminal

¿Son fáciles de leer las señales de localización?

¿Son adecuados los niveles de iluminación?

¿Se define un camino para las sillas de ruedas?

¿Se define un sistema de localización para los usuarios ciegos?

Sistemas con tarjetas

¿Es fácil de usar por alguien con baja destreza manual ?

¿Contiene la tarjeta los requerimientos de usuario?

¿Hay algún mecanismo para orientar las tarjetas?

¿Se pueden identifican las tarjetas a partir de su relieve?

Características externas, etiquetas e instrucciones

¿Se han posicionado las etiquetas para que sea fácil leerlas ?

¿Son legibles las etiquetas?

¿Están numeradas las instrucciones?

¿Es posible alcanzar los controles desde una silla de ruedas?

¿Está dirigida la ranura para la entrada de la tarjeta ?

Pantallas e interacción

¿Evita la pantalla los reflejos de la luz del sol?

¿Es posible alcanzar la pantalla táctil desde una silla de ruedas?

131

¿Se han minimizado los problemas de paralaje?

¿Se consideran otros idiomas par las instrucciones en pantalla?

Instrucciones de operación

¿Es simple el vocabulario utilizado?

¿Hay una entrada para acceso por audio?

¿Se da una retroalimentación audible a la entradas proporcionadas?

¿Hay salidas en forma de voz?

¿Hay enlaces de vídeo?

Teclados

¿Se da la disposición telefónica para el teclado numérico?

¿Hay un punto elevado en el número 5?

¿Están las teclas claramente señaladas?

¿Se utilizan teclas elevadas o rebajadas?

¿Están las teclas apropiadamente espaciadas?

¿Están las teclas iluminadas por dentro?

¿Proporcionan las teclas algún tipo de retroalimentación táctil?

¿Se proporciona tiempo suficiente para realizar las entradas por teclado?

Pantallas táctiles

¿Se posibilita la opción de incrementar el tamaño de los caracteres?

¿Hay campos amplios de selección?

¿Se corresponde el texto con los símbolos gráficos?

¿Existe la opción de una salida en forma de voz?

Retirando dinero, cartas y recibos

¿Existe una seguridad adecuada?

¿Sobresalen los documentos al menos 3 cm?

¿Sobresalen las tarjetas al menos 2 cm?

¿Se requiere una fuerza mínima para retirar la tarjeta?

Tipos y legibilidad

¿Aparecen las instrucciones en un tipo de, al menos, 16 puntos?

¿Presenta el texto un contraste apropiado?

¿Se evitan los fondos con textura?

¿Se puede leer con facilidad los tipos?

¿Son cortas las longitudes de la línea?

¿Son legibles los recibos?

Entrenamiento

¿Se presentan los panfletos explicativos en una impresión clara y legible?

¿Se proporcionan instrucciones en formato de audio?

¿Hay algún tipo de asistencia para los usuarios que hacen uso del sistema por primera vez?

132

Ejemplo: Lista de comprobación sobre aspectos de uso a considerar en el diseño de un sitio Web

¿Quiénes son los usuarios de este sitio Web? ¿Cuáles son las tareas y las metas de estos usuarios? ¿Qué nivel de experiencia tienen los usuarios con sistemas informáticos? ¿Y con la Web? ¿Y con esta interfaz y otras interfaces similares? ¿Y con la materia que se trata en este sitio? ¿Cuáles son los entornos en los que el usuario trabaja o navega en la Web? ¿De qué hardware, software y navegadores dispone el usuario? ¿De qué forma puede facilitar los procesos cognitivos de los usuarios el diseño de la interfaz de este sitio web?. ¿De qué forma descubren y corrigen los errores los usuarios?

¿Cuáles son las estilos de aprendizaje preferidos por los usuarios? ¿Cuánto entrenamiento recibirán los usuarios en caso de que esto sea preciso?

¿Qué conocimientos y habilidades relevantes tiene ya el usuario? ¿Qué funciones necesitará el usuario de esta interfaz? ¿De qué forma llevan a cabo sus tareas? ¿Por qué llevan a cabo los usuarios sus tareas del modo en que lo hacen?

¿Qué información podrían necesitar los usuarios y en qué formato habría de presentarse la misma?

¿Qué esperan los usuarios de este sitio Web? ¿De qué forma esperan los usuarios que funcione eta interfaz?

Ejemplo: Guía de comprobación detallada para la revisión de un sito web 1. Visibilidad Hay que hacer que los elementos importantes, como las ayudas a la navegación, resulten visibles y explícitos, de modo que los usuarios puedan determinar de un vistazo qué es lo que pueden hacer y lo que no. La visibilidad ayuda a los usuarios a predecir los efectos de las acciones. 2. Carga de Memoria Hay que hacer que los elementos en pantalla resulten significativos y consistentes a lo largo del sitio para reducir la carga de memoria. De esta forma, los usuarios no tienen que recordar lo que significan los elementos de una página a otra. Hay que relacionar los nuevos aspectos y funciones con aquellos que el usuario ya conoce. 3. Retroalimentación Hay que proporcionar una retroalimentación inmediata cuando el usuario realiza una acción. Por ejemplo, cuando el usuario hace click sobre un botón, algo en la pantalla debe cambiar para que el usuario entienda que el sistema ha registrado la acción. 4. Accesibilidad El usuario ha de encontrar la información rápida y fácilmente • Ofrecer a los usuarios algunas formas de encontrar información, como elementos para la navegación,

funciones de búsqueda o un mapa del sitio. Sin embargo, corresponde ofrecer pocas opciones de una sola vez para evitar confusión.

• Hay que organizar la información en pequeños elementos mediante un esquema o jerarquía que resulte significativa al usuario

• Hay que facilitar a los usuarios la posibilidad de hojear la información, proporcionando mecanismos que permitan encontrar la información sin necesidad de leer todo lo que se presenta en pantalla

5. Orientación / Navegación Hay que ayudar a los usuarios a que se orienten, proporcionando las siguientes facilidades para la navegación: • Enlaces descriptivos • Un mapa del sitio • Formas obvias de salir de cada página

133

• Elementos claramente visibles en cada página que informen a los usuarios de donde se encuentran en relación a otras páginas y cómo desplazarse a ellas

6. Errores Los errores se minimizan evitando las situaciones en las que los usuarios cometen errores con mayor probabilidad. Igualmente hay que minimizar las acciones incorrectas de los usuarios para que se puedan recuperar rápidamente. 7. Satisfacción El sitio debe ser agradable de ver y de usar, dado que la satisfacción del usuario con la interfaz influye en su: • Percepción de la facilidad de uso • Motivación en el aprendizaje del uso del sitio • Confianza en la fiabilidad de la información del sitio 8. Legibilidad El texto ha de resultar fácil de leer. Cuando se desarrolla información en línea, conviene utilizar: • Fuentes Sans Serif en el cuerpo del texto • Fuentes no ornamentales • Caracteres romanos en lugar de cursivas • Fuentes de tamaño medio- entre 9 y 11 puntos para fuentes Sans Serify entre 11 y 12 puntos para fuentes serif • Longitudes de línea de entre 50 y 60 caracteres para facilitar rápidas inspecciones • Alto contraste entre el texto y los colores de fondo para incrementar la legibilidad. Texto oscuro contra un

fondo claro resulta la opción más legible. 9. Lenguaje Se puede mejorar la usabilidad incorporando los siguientes elementos estilísticos: • Lenguaje conciso • Vocabulario cotidiano, en lugar de jerga y terminología técnica • Voces y verbos activos • Estructuras sencillas en las oraciones 10. Diseño visual • La estética de la interfaz juega un papel importante en la comunicación efectiva de la información a los

usuarios. A lo largo del desarrollo de un sitio convendrá considerar las siguiente estrategias de diseño visual : • Las páginas han de resultar interesantes, pero siempre simples y ordenadas. • Hay que hacer uso de los gráficos para ilustrar e informar, incrementar la satisfacción del usuario, la motivación

y la ayuda a la navegación. Hay que evitar el uso de gráficos con fines exclusivamente decorativos. • Hay que hacer uso de gráficos de pequeño tamaño que puedan se descargados rápidamente • Los elementos más importantes son los que han de resultar más visibles • Hay que tratar el texto como a un elemento gráfico • Considerar diversas disposiciones de página • Hay que agrupar los elementos relacionados entre sí de manera que los usuarios puedan asociar los

elementos con tan solo mirar su ubicación • Hay que hacer uso del espacio en blanco para organizar la página, enfatizar los elementos importantes y

proporcionar zonas de descanso a los ojos de los usuarios • Aunque el color puede atraer a los usuarios, también puede distraerles o confundirles. Además hay usuarios

cuyo equipamiento sólo soporta el monocromo. Conviene diseñar primero en monocromo para después añadir unos pocos colores.

Ejemplo: Principios del Diseño Universal

USO EQUITATIVO El diseño ha de ser útil y comercial para personas con diversas capacidades, teniéndose que: Hay que proporcionar los mismos medios para todos los usuarios, idénticos, siempre que sea posible

y equivalente cuando no lo sean Hay que evitar estigmatizar o segregar a algún usuario las posibilidades de privacidad, seguridad y protección deben estar igualmente disponibles para todos

los usuarios el diseño se llevará a cabo teniendo en cuenta a todos los usuarios FLEXIBILIDAD EN EL USO El diseño acomoda un amplio rango de preferencias y capacidades individuales teniéndose que: hay que proporcionar opciones en los métodos de uso hay que acomodar los accesos y usos con ambas manos hay que facilitar la certeza y la precisión en el usuario

134

hay que procurar la adaptabilidad de acuerdo con el usuario USO SIMPLE E INTUITIVO El uso del diseño ha de ser fácil de entender de forma independiente a la experiencia del usuarios de sus conocimientos, de su capacidad de lenguaje o de su nivel de concentración, teniéndose que: hay que eliminar toda complejidad innecesaria hay que ser consciente con la intuición y las expectativas del usuario hay que acomodar un amplio rango de literatura y de capacidades del lenguaje hay que disponer la información de forma consistente con su importancia hay que proporcionar una retroalimentación (feedback) apropiado durante y después de la ejecución

de una determinada tarea por parte del usuario INFORMACIÓN PERCEPTIBLE El diseño ha de proporcionar al usuario la información que necesita de forma efectiva, independientemente de las condiciones ambientales, las capacidades sensoriales del usuarios, teniéndose que: hay que utilizar distintos modos de presentación redundante para la información esencial hay que proporcionar el adecuado contraste entre la información esencial y sus vínculos hay que maximizar la legibilidad de la información esencial hay que diferenciar elementos en las formas en que pueden ser descritos hay que proporcionar compatibilidad con una variedad de técnicas o dispositivos por personas con

limitaciones sensoriales TOLERANCIA AL ERROR El diseño ha de minimizar las aleatoriedades y las consecuencias adversas de las acciones accidentales o no intencionadas, teniéndose que: hay que disponer los elementos para minimizar las aleatoriedades y los errores: los elementos más

utilizados serán los más accesibles, los elementos sujetos al azar serán eliminados, aislados,... hay que proporcionar advertencias acerca de las aleatoriedades y los errores hay que proporcionar elementos a prueba de fallos hay que desaconsejar acciones inconscientes en tareas que requieren vigilancia BAJO ESFUERZO FÍSICO El diseño ha de ser utilizado de forma eficiente y confortable con un mínimo de fatiga, teniéndose que: hay que permitir al usuario mantener una posición neutral con su cuerpo hay que utilizar fuerzas operativas racionales hay que minimizar las acciones repetitivas hay que minimizar el esfuerzo físico sostenido TAMAÑO Y ESPACIO PARA ALCANCE Y USO Se han de proporcionar espacios y tamaños apropiados para alcance, manipulación operación y uso de forma independiente de las dimensiones del usuario, postura o movilidad, teniéndose que: hay que proporcionar una línea clara de visión a los elementos importante para cualquier usuario

sentado o de pie hay que hacer confortable el alcance a todos los componentes para todo usuario sentado o de pie hay que acomodar variaciones en las posiciones de mano y agarre hay que proporcionar el espacio adecuado para el uso de dispositivos asistivos o asistencia personal

Ejemplo: Veinte puntos a evitar en la realización de una página Web (Sullivan, 97): Marcos (frames) El abuso de tecnología puntera Texto en desplazamiento, marquesinas y animaciones URLs complejas Páginas huérfanas Páginas largas en las que se requerir de scroll para ser recorridas Ausencia de soporte para la navegación Colores no estándares para los enlaces Información no actualizada Grandes tiempos de descarga Imágenes animadas Tablas de anchura fija Intentar instalaciones o descargas Diseñar para navegadores específicos Contadores Mapas de imágenes gratuitos Vínculos rotos

135

Gráficos sobredimensionados, no optimizados Pantallas cuya única función es apuntar a otra Páginas que abren nuevas ventanas del explorador

5.6.1 Listas de Comprobación Basadas en Escenarios (Scenario-Based

Checklist)

Esta metodología de inspección, típica del ámbito del software, se lleva a cabo a lo largo de tres escenarios: usuario novel, usuario experto y manejo de errores. Para cada escenario se ha de proporcionar una lista de comprobación con una descripción de los aspectos a ser evaluados y un conjunto de instrucciones para el proceso de inspección.

Cada inspector va a trabajar en un solo escenario, de modo que habitualmente se requerirían tres, aunque se pueden plantear tres sesiones de inspección con un solo inspector. Es recomendable la presencia de un moderador que prepare los materiales de la inspección (perfiles de usuario, casos de tareas), disponga la inspección y la reunión de los resultados de la misma. ¿Cómo se puede llevar a cabo esta técnica? Preparación del perfil de usuario y de los casos de tareas__________

Un coordinador habrá de preparar el perfil de usuario y los casos de tareas, material que proporcionará a los evaluadores participantes en la sesión. Para el escenario de uso novel, cada tarea se sigue por los pasos que se aprenden de forma más fácil para la realización de la misma. Para el caso de uso experto y manejo de errores, cada tarea vendrá seguida también por el conjunto de pasos a seguir para llevar a cabo la tarea de la forma más eficiente posible, si existe alguna. Estos paso para la realización de tareas habrán de ser proporcionados por diseñadores y desarrolladores del sistema.

En el caso de que sea un solo evaluador el que haga uso de esta técnica para evaluar los tres escenarios referidos, deberá empezar por el de uso novel, para seguir con el de uso experto y el de manejo de errores para terminar. Instrucciones de la inspección del escenario para uso novel________________

1. Leer el perfil de usuario para entender las características del mismo. 2. Leer las instrucciones y entender la tarea de evaluación, eliminando los

aspectos que no sean aplicables al sistema objeto de la evaluación.

136

3. Dar comienzo la evaluación siguiendo los paso correspondientes y comprobando cada punto de aplicabilidad. Anotar el conocimiento del dominio de la tarea o el conocimiento del sistema requerido a los usuarios para entenderlo o usarlo y que no aparece en el perfil de usuario.

4. Si un usuario necesitara instalar el sistema, instalar el sistema y comprobar la pregunta P1.1 P1.1: ¿Resulta fácil instalar el software?

• Si hay un programa de instalación que requiere el menor esfuerzo posible del usuario.

5. Si el usuario no tuviera ninguna experiencia en el uso de dispositivos de

entrada, comprobar la pregunta P1.2 sobre la primera impresión del sistema P1.2: ¿Proporciona el sistema un soporte apropiado a los usuarios más noveles?

• Cuando el sistema se inicia, si hay información en la interfaz para ayudar a los usuarios más noveles a entender como usar el sistema.

6. Continuar con los casos de tareas. Para cada tarea, comprobar las

preguntas P1.4 y P1.5. Para cada nueva sesión o pantalla, compruebe la pregunta P1.3.

P1.3: ¿En qué medida se entienden la interfaz y su contenido?

• Si la interfaz presenta indicaciones significativas indicando lo que es algo y cómo se relaciona con los demás elementos presentes en la interfaz.

• Si la interfaz presenta los objetos o datos en los que el usuario está interesado mediante indicaciones visuales o una disposición espacial significativas para representar la información semántica de los objetos o datos.

• Si la relación entre los objetos de la interfaz es consistente con la relación que existe en el entendimiento del usuario.

P1.4: ¿En qué medida resulta fácil especificar un objeto o una acción?

• Información de carácter instructivo para usuarios noveles 1. No está disponible en línea. 2. En el tutorial en línea, pero inaccesible mediante función. 3. En el tutorial en línea y accesible mediante función.

137

4. Siempre mostrando de forma clara las necesidades del usuario sobre una cierta función del sistema

• Cuando sea requerido, si la información sobre las acciones, objetos, formato de los comandos y de los datos, son presentados directamente en la interfaz

P1.5: ¿En qué medida resulta fácil entender el resultado de una acción?

• Retroalimentación proporcionada por el sistema. 1. No hay retroalimentación. 2. Sólo hay retroalimentación cuando se ha completado la acción 3. Proporciona retroalimentación cuando se ha completado una

acción y da información de forma constante sobre el progreso cuando la acción dura más de cinco segundos.

• Si un usuario puede percibir la retroalimentación por el sistema sin modificar el objeto de su atención actual.

• Si la representación de un objeto cambia o no cuando el contenido representado asociado al mismo es modificado.

• Si la representación de un objeto desaparece o no de la interfaz cuando es borrado o eliminado.

Instrucciones de la inspección del escenario para uso experto________ 1. Leer las instrucciones (incluyendo preguntas y métricas) y entender la

tarea de evaluación, eliminando los aspectos que no sean aplicables al sistema objeto de la evaluación.

2. Si no se ha hecho uso del sistema con anterioridad, operar con el mismo libremente durante un cierto momento de tiempo para familiarizarse con el mismo.

3. Seguir los casos de tareas correspondientes y proceder de la forma siguiente.

4. Pensar en la forma más eficiente para llevarlas a cabo en un nivel conceptual y anotar los paso que se desprendan de tales consideraciones.

5. Leer las acciones proporcionadas con la tarea y contestar a la pregunta P2.1 P2.1: ¿Asiste el sistema al usuario de forma efectiva proporcionando el modo más efectivo de hacer las tareas en caso de que no haya una única forma de hacerlas?

• El modo en el que la información sobre las técnicas más eficientes es proporcionada por la interfaz:

1. No está disponible en línea. 2. Está en el tutorial en línea o en indicaciones ocasionales (tips)

138

3. Aparece de alguna forma cada momento que el usuario procede mediante la técnica menos eficiente

6. Completar la tarea llevando a cabo las tareas proporcionadas y

comprobar las caras P2.2, P2.3, P2.4 y P2.5 P2.2: ¿Está diseñada la interfaz para facilitar la realización eficiente de las tareas de la mejor forma posible? • Si el sistema no ha provocado que el usuario precise de trabajo

adicional con la tarea. • Si el sistema proporciona valores de defecto siempre que sea posible • Si "cortar y pegar " siempre funciona • Si el sistema está diseñado de modo que no se requiere pasar del

teclado al ratón y viceversa de forma frecuente en la realización de las tareas.

P2.3: ¿En qué medida es fácil de utilizar el sistema en la realización de tareas? • Si no hay acciones complejas involucradas en las tareas. Este tipo de

acciones incluye, sin limitarse a las mismas: ♦ Dificultades motoras:: doble click en los botones del ratón,

mantener pulsado un botón del ratón, combinaciones de teclas requeridas.

♦ Dificultades en la percepción: lectura de texto parpadeando, texto en fuente pequeña, texto en colores que dificulten la lectura,...

♦ Dificultades cognitivas: recordar y/o tratar de recuperar información que se presentó en etapas previas de una sesión de trabajo y que se requieren en el instante actual.

P2.4: ¿En qué medida facilita la interfaz de usuario un uso eficiente (para interfaces basadas en pantallas)? • Si la disposición en pantalla y el aprovechamiento del espacio son

efectivos de forma que el desplazamiento vertical y horizontal para acceder a los elementos sea minimizado.

• Si los diversos elementos en pantalla están dispuestos de tal forma que el movimiento del ratón para la realización de las tareas ha sido minimizado.

• Si, requiriéndose la presencia de múltiples ventanas para la realización de la tarea, estas se confunden entre sí.

139

• Si se minimiza el uso de ventanas o cajas de diálogo que no pueden moverse o modificar su tamaño.

P2.5: ¿En qué medida es apropiada la retroalimentación presentada por el sistema?

• Si no hay un mensaje trivial del sistema que requiere una acción del usuario innecesaria.

• Cuando se está trabajando con un amplio espacio de datos, la medida en la que el sistema proporciona información sobre la posición relativa actual respecto del conjunto del sistema 1. No se proporciona tal información 2. Tal información es proporcionada cuando el usuario inicia un

comando o función 3. Tal información se proporciona de forma constante y dinámica

Instrucciones de la inspección del escenario para manejo de errores___ 1. Leer las instrucciones (incluyendo preguntas y métricas) y entender la

tarea de evaluación, eliminando los aspectos que no sean aplicables al sistema objeto de la evaluación.

2. Si no se ha hecho uso del sistema con anterioridad, operar con el mismo libremente durante un cierto momento de tiempo para familiarizarse con el mismo.

3. Si el usuario va a utilizar el sistema para un trabajo constructivo, generar una terminación anormal del sistema mientras se realiza ese trabajo y comprobar:

P3.1 ¿En qué medida actúa el sistema como corrector de errores? • Si el sistema salvaguarda de forma periódica el trabajo del usuario de

forma periódica ante un potencial fallo general. • Cuando el sistema se reinicia tras un fallo grave, si el sistema informa

al usuario sobre la posibilidad de acceder a la copia de seguridad más reciente en caso de que exista

4. Seguir los casos de tareas. Intentar generar algunos errores de usuario, como proporcionar datos de entrada en formato o tipos incorrectos, tratar de acceder a los dispositivos cuando no están listos, etc. Comprobar las siguientes cuestiones y métricas

P3.2: ¿En qué medida actúa el sistema en la prevención de errores? • Si las operaciones o comandos inválidos son desactivados. • Si el sistema genera un mensaje ante las acciones destructivas de

cuyo efecto no es fácil la recuperación del sistema.

140

• Si los objetos y las acciones son presentados de forma no ambigua. • Si el sistema verifica los datos introducidos por el usuario en base a un

formato, rango, tipo,... • Si el sistema mantiene la consistencia de manera que los usuarios no

cometan errores inesperados siguiendo las convenciones de los sistemas.

• Si el sistema se ajusta a las convenciones en el conocimiento en el dominio de la tarea del usuario y su experiencia previa con el sistema.

P3.2: ¿En qué medida actúa el sistema en la información de los errores?

• Si el mensaje de error hace uso del lenguaje del usuario para explicar lo que está sucediendo

• Si el mensaje e error es sensible al contexto. • Si el mensaje de error informa al usuario del mecanismo de

recuperación del error. • Cuando la acción del usuario no da lugar a ningún efecto, si el sistema

genera un mensaje informando al usuario sobre el motivo por el que la acción no genera ningún efecto en esa circunstancia.

P3.4: ¿en qué medida actúa el sistema en la corrección de errores? • Si el sistema exhibe siempre una salida claramente señalizada. • Si las acciones son reversibles, siempre que tal cosa sea posible. • Si el sistema proporciona la opción de "deshacer " y esta es activa

sobre múltiples pasos de operaciones concretas. • Si cada operación para continuar puede ser cancelada por el usuario. • Cuando el usuario introduce datos no válidos, si el sistema presenta

entradas de datos válidos similares a las introducidas por el usuario y le permite confirmar.

5. Después de efectuar el recorrido por las tareas, anotar las inconsistencias

percibidas en la interfaz de usuario en la presentación de objetos y acciones.

5.7 Otras Variantes de Interés

Se ha considerado de interés la inclusión de las dos siguientes técnicas en la categoría de métodos de inspección. La primera de ellas, el método de diario, une la necesidad de la inspección con la imposibilidad de acceder a un determinado usuario o a su contexto. A partir de la información aportada por un usuario desde su contexto de trabajo será posible elaborar una forma de sistema que los especialistas en usabilidad habrán de revisar.

141

En los anexos de este documento se trata con más extensión lo que se ha venido a llamar "Evaluación Remota"

La segunda técnica, el modelado por empatía, es una compleja

variante de la revisión cognitiva orientada a los usuarios con discapacidades en la que el diseñador trata de ponerse en el lugar del usuario objetivo. 5.7.1 Método de Diario (Diary Keeping)

Los métodos de diario requieren del informante el registro de las actividades de interés a lo largo de un día normal. Los diarios pueden ser abiertos, expresándose el informante con sus propias palabras, o, también, altamente estructurados, disponiendo el usuarios 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 administrados por una aplicación. Esta técnica es especialmente útil para conocer el comportamiento del usuario durante un determinado período de tiempo.

Beneficios • Permite la reunión de datos a través de las tareas diarias, sin la intrusión del investigador.

Limitaciones • Los usuarios pueden olvidar completar el diario o hacerlo incorrectamente si no se han proporcionado suficientes instrucciones.

Beneficios y limitaciones de la aplicación de los Métodos de Diario

Para proceder en la práctica de esta técnica es preciso desarrollar los diarios y realizar visitas para mantener el interés del usuario. Para capturas de datos más compleja, se hace uso de formatos controlados por aplicaciones informáticas y registro por videocasete. ¿Cómo se puede llevar a cabo esta técnica?

Se pueden distinguir los siguiente pasos en la implementación de esta

técnica: - 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 más sencillo.

- Si se utiliza un método estructurado, se habrá de desarrollar una cuidadosa selección de preguntas y categorías para las respuestas

- Decidir la frecuencia con la que los usuarios habrán de completar el diario (cada hora, diariamente, semanalmente,...). Esto vendrá determinado por la naturaleza de los datos que se pretendan obtener y las tareas que hayan de llevarse a cabo. De forma alternativa, el usuario podría tener que completar el diario inmediatamente después de que ha tenido lugar un suceso particular.

142

- Hacer copias del diario y desarrollar instrucciones claras para completarlo

- Proporcionar medios (como un número de teléfono) para que el participante pueda comprobar el procedimiento a seguir en el registro.

5.7.2 Modelado por Empatía (Empathic Modelling)

El método de modelado por empatía fue desarrollado básicamente para su uso con usuarios con discapacidades. Con el modelado por empatía, el diseñador / desarrollador trata de ponerse en el lugar del usuario con la discapacidad. Este método se lleva a cabo simulando la discapacidad mediante una variedad de técnicas. Se usan métodos similares en otras áreas, pero raramente se refieren a ellos como modelado por empatía.

Este método puede ser aplicado a una gran variedad de aplicaciones e interfaces en general. Las limitaciones que presenta son bien claras: una discapacidad simulada presenta muchas diferencias con una discapacidad real, hay grandes diferencias entre una situación artificial en la que se sumerge el investigador y las situación real en la que se desenvuelve el usuario. Se va a requerir una gran inversión en tiempo y dinero para investigar las características de los grupos de usuarios.

Una de las ventajas fundamentales de este método es que aquellos que necesitan información, pueden obtenerla de forma directa sin la mediación de un usuario. El método puede aportar información muy útil cuando resulta difícil conseguir la participación de usuarios reales.

143

VI. Métodos de Test en

los procesos DCH

144

6.1 Test de Usabilidad

Frecuentemente el término test de usabilidad, se utiliza de forma indiscriminada para referirse a cualquier técnica utilizada para evaluar un producto o sistema. Rubin (94) llama test de usabilidad al proceso que emplea a participantes representativos de la población objetivo para evaluar el grado en el que un producto se encuentra con los criterios de usabilidad. La inclusión de usuarios representativos, entonces, permite eliminar la etiqueta de evaluación experta, revisiones cognitivas y demás, que no requieren, aunque pueden considerar, la participación del usuario en el desarrollo de las metodologías en cuestión.

La meta global del test de usabilidad es la identificación y resolución de deficiencias de usabilidad existentes en un sistema. Se tiene la intención de crear productos: - que sean fáciles de aprender y de usar - cuyo uso sea satisfactorio - proporcionen utilidad y funcionalidad, factores altamente valorados por la

población objetivo

Otras metas más específicas o beneficios del test son: - Crear un registro o historial de referencias de usabilidad para futuros

lanzamientos del producto. Se trata de garantizar el mantenimiento, como mínimo, de los actuales estándares de usabilidad o, incluso, de mejorarlos.

- Minimizar el coste del servicio y las llamadas en las "líneas calientes". El servicio de mantenimiento requerido es menor, en general.

- Incremento en las ventas y la posibilidad de volver a realizarlas. Los productos usables crean usuarios felices que habla con usuarios o compradores potenciales. Los clientes contentos tienden a seguir los futuros lanzamientos del producto, en lugar de pasarse a la compra de productos de la competencia.

- Adquisición de una ventaja competitiva, puesto que la usabilidad se perfila como un claro separador (diferenciador) de productos. La usabilidad se perfila como un parámetro diferenciador de productos en la mente del usuario consumidor. Uno tan solo necesita echar un vistazo a los anuncios publicitarios más recientes que hacen uso de frases como "fácil de usar", "incluso un niño podría hacerlo", y demás. Desafortunadamente, esta información es habitualmente poco fidedigna una vez que se somete a test.

145

- Minimiza riesgos. En realidad, casi todas las compañías y organizaciones han llevado a cabo tests de usabilidad, que no es otra cosa que el "lanzamiento del producto" y la "prueba" que se lleva a cabo probando el producto en el punto de venta. Obviamente tal cosa es una estrategia muy arriesgada, pudiendo minimizar un test de usabilidad previo al lanzamiento los riesgos asociados a un producto con problemas de usabilidad serios.

Pero no hay que confundirse: un test de usabilidad no es, por sí mismo,

garantía de nada. Un test no garantiza el éxito, ni prueba que un producto sea usable, aun cuando este test fuera conducido del modo más riguroso. ¿Qué razones pueden llevar a decir esto? - Un test de usabilidad es siempre una situación artificial, ya sea llevado a

cabo en laboratorio o en campo, representa una variante, una desviación de la situación real de uso, pero no la situación misma. El mismo hecho de conducir el estudio ya afecta a los resultados.

- Los resultados de test no prueban que un producto funcione. Aun cuando se conduce un tipo de test que proporciona resultados estadísticamente significativos, esto tampoco probará que el producto funcione. ocurre que la significancia estadística es simplemente una medida de la probabilidad de que una serie de resultados no se deben a la casualidad. no es una garantía y hay una elevada dependencia del modo en el que el test ha sido conducido.

- Los participantes raramente son representativos de la población objetivo. Los participantes serán representativos en la medida en que seamos capaces de entender y clasificar la audiencia objetivo. La investigación de mercado no es una ciencia infalible y el usuario final real es a menudo de compleja identificación y descripción.

- El test no es siempre la mejor técnica a utilizar. Se han desarrollado multitud de técnicas con el objetivo de evaluar y mejorar productos. En algunos caso, de hecho, va a ser mucho más efectivo en coste, tiempo y precisión la realización de una evaluación experta de un producto en lugar de un test de la misma. Esto resulta especialmente indicado en las etapas tempranas del producto donde las violaciones de los principios más elementales de la usabilidad son frecuentes. Es simplemente innecesario reunir a un montón de participantes para que revelen lo obvio.

6.1.1 Cuatro tipos de Test de Usabilidad

Se pueden considerar cuatro tipos de test: exploratorio, de valoración, de validación y de comparación.

146

Test Exploratorio________________________________________

El test exploratorio se conduce en etapas muy tempranas del ciclo de desarrollo, cuando el producto se encuentra aún en las etapas preliminares a su definición y diseño. En este punto del ciclo de desarrollo, el perfil de usuario y el patrón de uso (o análisis de tareas) del producto que será o debería ser definido. En este momento el equipo del proyecto está lidiando con las especificaciones funcionales y desarrolla modelos tempranos del producto, o quizás ha terminado con la fase de especificación.

El objetivo es examinar o explorar la efectividad de los conceptos de diseño preliminares (modelo mental o conceptual que tiene el usuario del producto). Si alguien piensa en la interfaz de usuario o en un documento como divididos en una serie de aspectos de alto nivel y otros de bajo nivel, el test exploratorio iría vinculado al primer conjunto de aspectos

Los diseñadores podrían querer saber en qué medida la interfaz: - Representa las clases de objetos - Comunica las relaciones entre estos objetos - Permite a los usuarios manipular estos objetos - Permite a los usuarios navegar entre pantallas o desplazarse en una

pantalla

Haciendo uso de una guía de usuario orientada a las tareas para un producto software, los escritores técnicos podrían querer explorar algunos aspectos de alto nivel: - Organización global de la materia - Aproximación gráfica o escrita al tratamiento de la materia - Accesibilidad del formato propuesto - Anticipación de puntos para el acceso a la ayuda - Direccionamiento a la información de referencia

Un test exploratorio podría contestar a las siguientes preguntas: - ¿Qué piensan, qué imaginan, los usuarios sobre el uso del producto? - ¿Tiene valor para el usuario la funcionalidad básica del producto? - ¿Son las operaciones y la navegación intuitivas desde la interfaz de

usuario? - ¿Qué tipo de información previa requiere un individuo para hacer uso del

producto? - ¿Qué funciones del producto resultan de aplicación inmediata y cuáles

requerirán probablemente algún tipo de ayuda o documentación escrita? - ¿Cómo debería organizarse la tala de contenidos para acomodar tanto a

os usuarios niveles como a los expertos?

147

Los tests exploratorios dan lugar, en general, a una amplia interacción entre el participante y el director del test para establecer la eficacia de los conceptos de diseño preliminares. un mecanismo para contestar las preguntas más básicas es el desarrollo de una versión preliminar de la interfaz del producto y/o su material de asistencia para su evaluación por usuarios representativos.

En general, esto implicará la consideración de alguna forma de prototipo

o maqueta que represente su disposición básica, la organización de las funciones y las operaciones de alto nivel. Se van a utilizar, básicamente, prototipos horizontales Test de Valoración____________________________________

El test de valoración es, probablemente, el más habitual entre los tests de usabilidad. De entre todos ellos, es el que resulta más simple y directo par los profesionales noveles de la usabilidad en cuanto a dirección y procedimiento. Los tests de valoración se conducen en etapas tempranas o medias del proceso de desarrollo en el ciclo de desarrollo del producto, normalmente tras establecer el diseño de alto nivel del producto.

El propósito de este tipo de test es el de expandir los hallazgos mediante la evaluación de operaciones de bajo nivel y aspectos del producto. Si la pretensión del test exploratorio es trabajar en el esqueleto del producto, el test de valoración empieza a trabajar en todo aquello que envuelve ese esqueleto. Más que explorar el carácter intuitivo del producto, lo que interesa es comprobar el modo en el que los usuarios pueden llevar a cabo tareas realistas e identificar las deficiencias específicas de usabilidad que se presenten.

Este tipo de test se entiende como un mecanismo más para la reunión de información, de modo que la metodología habitual se sitúa entre la de una exploración informal y un control de medidas como puede suceder en los tests de validación. Al contrario de lo que ocurre en los tests exploratorios: - El usuario siempre realizará tareas en lugar de limitarse a recorrer y

comentar pantallas, páginas, escenarios,... - El monitor del test limitará su interacción con el participante al haber

menos énfasis en los procesos cognitivos y más en los comportamientos reales

- Se tomarán medidas cuantitativas

148

Test de Validación____________________________________

El test de validación o verificación se suele llevar a cabo en etapas finales del proceso de diseño con el propósito de certificar la usabilidad del producto. Al contrario que los tests anteriores, este test es muy próximo al lanzamiento del producto.

El objetivo del test de validación es el de evaluar la medida en que el producto e comparable con algunos estándares o referencias predeterminadas de usabilidad, ya sea una referencia interna de la compañía referida en un registro de la historia de diseño o, también, un estándar d realización de la competencia.

El propósito es el de establecer que el producto alcanza tal estándar

de forma previa a su lanzamiento y, en caso de no hacerlo, establecer las razones por las que no lo hace. las referencias se originan habitualmente de los objetivos de usabilidad desarrollados en las etapas tempranas del proceso, que, a su vez, se fundamentan en encuestas de mercado, entrevistas con usuarios o simples estimaciones llevadas a cabo por un equipo de desarrollo.

Los objetivos de usabilidad se establecen de forma típica en términos de criterios de realización, tales como velocidad y precisión; lo bien y lo rápido que el usuario puede realizar diversas tareas y operaciones. Los objetivos también pueden ser planteados en términos de criterios de preferencias, tales como conseguir una valoración o consideración particular por los usuarios.

Otro objetivo importante del test de validación es el de evaluar, en ocasiones por primera vez, el modo en el que el conjunto de los componentes trabajan juntos; esto es, el modo en el que documentación, ayuda, asistencia, mantenimiento, hardware y software se integran entre sí. Es un factor importante al que se hace referencia dado que es habitual que de forma habitual estos componentes se desarrollen en un relativo aislamiento, no siendo extraño que no trabajen juntos de forma apropiada.

Otro objetivo de cualquier test en etapas finales del proceso de desarrollo es lo que se está empezando a conocer como "aseguramiento contra el desastre o la catástrofe". Será preferible demorar la fecha de lanzamiento o, cuanto menos, contar con una posición de ventaja en el reconocimiento del problema antes que exponerse a un aluvión de solicitudes de asistencia, devoluciones, quejas, y un evidente desprestigio...

149

El procedimiento va a ser similar al que se plantea para el test de valoración con tres diferencias básicas: - De forma previa al test, las referencia y los estándares para las tareas de

test han de ser identificados y/o desarrollados - Se proporcionan a los participantes las tareas a realizar con poca o

ninguna interacción por parte del director de test - La reunión de datos cuantitativos es el objetivo básico, aunque las

razones para las realizaciones por debajo de los estándares han de ser identificados

Al estar realizándose medidas contra estándares, también es preciso

determinar de antemano el modo en el que se medirá la conformidad con el estándar así como las acciones que se llevarán a cabo en caso de que el producto no se ajuste a los estándares. Test de Comparación____________________________________

El test de comparación no está asociado con ningún punto específico del ciclo de desarrollo. En las etapas tempranas, puede ser utilizado para comparar estilos de interfaz radicalmente distintos a través de un test exploratorio para ver cuál tiene un mayor potencial con la población objetivo. hacia las etapas medias del proceso de desarrollo, el test de comparación puede ser utilizado para medir la efectividad de un elemento individual en la interfaz (un formato, una disposición, una presentación, una denominación,...). Hacia el final del ciclo de vida, el test de comparación puede ser utilizado para comprobar cómo se presenta el producto a lanzar frente al de la competencia.

Este tipo de test puede ser utilizado en conjunción con cualquiera de los anteriores. El propósito puede ser compara dos o más alternativas de diseño, tales como dos estilos de interfaz diferentes, el diseño del manual actual con el nuevo diseño propuesto, o dos productos, el propio y el de la competencia. El test de comparación se utiliza típicamente para establecer qué diseño es más fácil de utilizar o aprender o para entender con mayor profundidad las ventajas y desventajas de los diferentes diseños.

Se trata, pues, de comparar dos o más alternativas de diseño. Se reúnen los datos de preferencias y realización para cada alternativa. Entonces se comparan los resultados. Este test puede conducirse de modo informal, como el test exploratorio., o de una forma más controlada, a la manera clásica, con un conjunto de participantes actuando como grupo de control y otro actuando como grupo experimental. La fórmula utilizada depende de las metas en el test.

150

Para tests exploratorios con propósito de comparación, se va a tener que los mejores resultados y las soluciones más creativas van a surgir de la consideración de alternativas muy diferentes, más que de la comparación entre opciones muy parecidas: - El equipo de diseño evitará seguir un patrón previsible y tratará de

ampliar miras en su concepción de las cosas. - Durante el test, el participante se concentra en considerar y

contemplar la mejor alternativa de diseño, así como el conjunto de aspectos que lo hacen así. Es más difícil comparar alternativas radicalmente distintas porque los marcos de trabajo, los modelos conceptuales y las operaciones de bajo nivel serán, en general, radicalmente diferentes.

6.1.2 Cómo llevar a cabo un Test de Usabilidad

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. Se van a considerar los siguientes pasos:

1 Determinar qué es lo que se está buscando 2 Diseñar el test 3 Disponer de algunos usuarios 4 Establecer el test 5 Conducir el test 6 Hacer dar parte al usuario 7 Analizar los datos

1. 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

151

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?

2. 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 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

152

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 a formular 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. 3. Disponer de algunos usuarios_________________________ Establecer una lista de usuarios de la que se obtendrá una muestra poblacional de sujetos de test

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.

153

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 testar un sistema de información ejecutiva, por ejemplo. 4. 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

154

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 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. Cuestionarios de exploración (screening questionnaire)

Los cuestionarios de exploración son un medio para la calificación y selección de participantes para formar parte de un test. Su contenido se obtiene, típicamente, de los perfiles de usuario y los planes de test y su complejidad va a depender de la variabilidad de los antecedentes de los potenciales participantes. En cualquier caso, representa un procedimiento útil para revelar ciertas imprecisiones y áreas oscuras en el entendimiento sobre los usuarios finales.

Guías para el desarrollo del cuestionario de exploración: 1. Revisión el perfil del usuario final o del perfil de mercado esperado con

el propósito de entender los antecedentes de las personas que se necesitan para llevar a cabo el test.

2. Enfocarse y sacar aquellas características que son únicas para el producto y no simples categorías generales para la población.

3. Una vez que se han aislado los diferentes factores para los que se está llevando a cabo la exploración, formular las preguntas apropiadas para descubrir si una persona goza de una determinada habilidad o destreza con el producto en cuestión.

4. Organizar las preguntas en un orden específico. 5. Desarrollar un formato que permita un movimiento fácil a través del

cuestionario mientras se está al teléfono. 6. Testar el cuestionario con los demás miembros del equipo y someterlo

a revisión. 7. De no resultar obvio en el formato planteado, desarrollar una hoja de

respuestas de forma separada al cuestionario que proporcione las

155

respuestas que cualifiquen al participante, así como el número de cada categoría que sean requeridos

Guías para su procedimiento por teléfono:

1. Informar al potencial participante sobre quién es su interlocutor 2. Explicar porqué se está haciendo la llamada 3. Basándose en los perfiles de usuario final de los planes de test, se

interrogará al individuo en cuestión sobre sus cualificaciones, como su experiencia en el uso de un determinado sistema, responsabilidades laborales y equipamiento utilizado

4. A medida que se aceptan o descartan participantes, se procede a registrarlo en una lista para tal ocasión

5. Si se está haciendo uso de los servicios de una consultora externa, se solicitará del equipo que pruebe el cuestionario como si uno fuera el potencial participante

5. 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á testando es el producto y, en ningún caso, el usuario, que no ha de sentirse presionado en ningún sentido por el test.

Profesionales de la Usabilidad como "testers" Ventajas

- Saben planificar y conducir tests. Se enfocan en las tareas y los usuarios. - Saben en que han de concentrar su atención. Están entrenados en la revisión de

productos - y en la observación de usuarios. - Saben analizar los datos, encontrar problemas subyacentes y sugerir soluciones.

- Son expertos en el manejo del equipo del laboratorio y el software Desventajas

- No son expertos en cada uno de los productos sometidos a test.

- No son expertos en los modos en que los usuarios desarrollan su trabajo con cada producto.

Ventajas y desventajas de los profesionales de la usabilidad como directores de test

Desarrolladores de producto como "testers" Ventajas

- Los desarrolladores ven a los usuarios probando sus productos. - Los desarrolladores se ven forzados a pensar en términos de usabilidad, usuarios,

tareas, medidas. - Los desarrolladores ya conocen el producto y probablemente conocerán el modo en el

que los usuarios hacen uso del producto en las tareas de trabajo u ocio que realizan.

156

- La compañía, de esta forma, no tiene que contratar a más personas. Desventajas

- Los desarrolladores deben aprender a manejar nuevas herramientas, tales como el software para el registro de datos.

- Nadie se convierte en experto y la compañía no tiene beneficio alguno en el aprendizaje de una ocasión a la siguiente.

Ventajas y desventajas de los desarrolladores de producto como directores de 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 cumplimentado 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. Directrices de Orientación (Orientation Script)

Las directrices de orientación (también directrices de test) es una herramienta destinada a la comunicación para ser leída de forma textual a los participantes. Describe qué es lo que va a ocurrir durante una sesión de test, establece el tono para cada sesión en las mentes de los participantes, y pretende facilitarles su situación. Se conseguirá esto informando a los participantes sobre lo que harán, y se insistirá en el hecho de que es el producto y no el participante lo que está siendo testado. Frecuentemente, los participantes tan solo tienen una vaga idea de lo que tienen que hacer ("participar en una investigación de mercado") y es deseable conseguir que el participante se sienta la persona adecuada en el lugar adecuado.

Guías para el desarrollo de las directrices de test: 1. Hay que mantener el tono de las directrices de forma profesional pero

amigable. 2. A menos que se trate de un test extremadamente complejo, hay que

limitar las directrices de test a una o dos páginas. 3. Plantearse la lectura textual de las directrices para cada participante: - El propósito es presentar la misma información a cada participante y

en idénticas condiciones, evitando una influencia inconsciente por parte del director del test (quizás los test previos podrían haber resultado un desastre,...)

- Podría ser precisa la participación de más de un director de test, por lo que hay que evitar de nuevo la introducción de variaciones

- Los miembros del equipo de desarrollo no presentes en las sesiones querrán saber qué es lo que se les ha dicho a los participantes.

- Son muchas las cosas que el directo de test ha de tener presentes como para tratar de memorizar otra

157

Contenidos típicos de las directrices: - Hacer las correspondientes presentaciones - Ofrecer un refresco - Explicar porqué se va a realizar el test - Describir el estado de las cosas - Explicar qué es lo que se espera de los participantes - Asegurar a los participante que no son ellos los que están siendo

testados - Explicar cualquier requerimiento no habitual así como las diversas

convenciones en el desarrollo de los test (como cualquier protocolo de pensamiento manifestado)

- Mencionar que se aceptan preguntas en cualquier momento - Preguntar al participante si tiene alguna duda - Hacer referencia a cualquier documento que haya de ser

cumplimentado Cuestionario sobre antecedentes (Background questionnaire)

El objetivo es proporcionar una información histórica sobre los participantes que ayude a entender su comportamiento y actuaciones durante el test. Se compondrá de preguntas que informen de su experiencia, actitudes y preferencias en todas las áreas que podrían afectar a aquello que va a llevar a cabo. Hay que considerar dos aspectos adicionales a los conceptos que se presentaban en el cuestionario de exploración: 1. Confirmar que son las personas apropiadas las que se han presentado a

la sesión 2. Proporcionar una sinopsis de cada participante para el director de test así

como para los desarrolladores de productos que observan el test Guías para el desarrollo del cuestionario sobre antecedentes: 1. Descubrir todos la información que se considere que pueda afectar a

la realización de los participantes. 2. Diseñar el cuestionario para que facilite la labor tanto del director del

test (en el análisis de las respuestas)como de los participantes (en un intento de recordar su historia), evitando preguntas abiertas.

3. Probar el cuestionario con alguien que se ajuste al perfil de usuario final o incluso con un compañero del equipo de desarrollo.

4. Si el cuestionario es breve (una o dos páginas), se permitirá a los participantes cumplimentarlo de forma previa al test.

CUESTIONARIO DE ANTECEDENTES- Ejemplo Nombre: Compañía: Puesto: Conteste, por favor, en orden a las siguientes preguntas para ayudarnos a entender sus antecedentes y

158

experiencia EDUCACIÓN EXPERIENCIA CON ORDENADORES 1. ¿Cuánto tiempo lleva utilizando ordenadores personales? 2. En un día normal, ¿con qué frecuencia hace uso de un ordenador para realizar su trabajo? 3. Por favor, rodee con un circulo los tipos de aplicaciones que ha utilizado con anterioridad, seguidos del número de meses de experiencia con cada uno de ellos: Aplicación Meses de Experiencia Bases de Datos ___________________ Hoja de Cálculo ___________________ Procesador de Textos ___________________ Diseño (CAD/CAM) ___________________ Fabricación ___________________ Ingeniería ___________________ Otros: ___________________ ___________________ ___________________ ___________________ ___________________ ___________________ ___________________ EXPERIENCIA CON EL PRODUCTO 1. ¿Durante cuánto tiempo ha trabajado con el analizadores de dispositivos hardware? 2. ¿Ha trabajado alguna vez con un analizador de hardware XYZ? _____Sí ____ No 3. ¿ha utilziado igualmetne algún otro tipo de analizadores de hardware?____ Sí ____ No Si lo ha hecho, especifique por favor el tipo y la marca comercial________________________ 4. ¿Qué tipo de análisis de dispositivos lleva típicamente a cabo cuando está realizando su trabajo?_____________________________________________________________________ 5. Describir, por favor, la configuración de análisis habitual con la que trabaja, como el número de dispositivos analizados de una vez y el tipo de análisis realizado_______________________ 6. ¿Desarrolla alguna nueva técnica de análisis como parte de su trabajo? ____ Sí____ No En caso de hacerlo, ¿cuántas horas a la semana emplea desarrollando nuevas técnicas?____________________________________________________________________ 7. Si hace uso de un programa basado en PC para el análisis de dispositivos, ¿de qué tipo es este?________________________________________________________________________ ¿Durante cuánto tiempo ha hecho uso 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 manifestado (de la que se hablará más adelante), podría resultar de interés

159

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.

Son aconsejables seguir las siguientes guías para la monitorización de un test: • Monitorizar la sesión de forma imparcial • Vigilar los posibles efectos de la voz o del lenguaje corporal • Tratar a cada nuevo participante con la unicidad que merece • No hay que rescatar a los participantes cuando se están esforzando • Si se comete un error, hay que continuar • Hay que asegurar que el participante ha terminado realmente con una

tarea antes de pasar a la siguiente • Hay que hacer uso del sentido del humor para mantener la sesión en

una línea distendida, indicando a los participantes que no hay una pregunta correcta o incorrecta

• Si resulta apropiado, hacer uso de la técnica del protocolo del pensamiento manifestado

• Interactuar con el participante siempre que sea apropiado - no mostrar sorpresa - enfocarse en lo que los participantes esperan que ocurra - actuar como un espejo para reflejar lo que los participantes dicen para

ayudarles a expresar sus pensamientos de una forma útil - no hay que formular siempre preguntas directas

- ¿En qué piensa ahora? - Parecía sorprendido/confuso/frustrado, ¿era así? - ¿En qué difiere exactamente respecto de lo que esperaba?

• Durante la sesión hay que limitar las interrupciones a breves discusiones

• Hay que atender a las pistas verbales y no verbales procedentes de la actividad de los participantes

• Hay que buscar todas las oportunidades posibles para racionalizar los comportamientos particulares y las preferencias

• Hay que manejar un aspecto en cada momento • No hay que hacer uso del tiempo de test para resolver problemas • Hay que asistir al participante sólo como último recurso... - Cuando un participante está muy perdido o muy confundido - Cuando en la realización de una de las tareas requeridas el

participante se siente incómodo - Cuando uno de los participante se ha frustrado de forma excepcional y

debe abandonar el intento - Cuando el producto se encuentra en una etapa inmediata a su

conclusión y es preciso proporcionar información a los participantes

160

- Cuando ocurre algún tipo de error del sistema o las acciones del participante han originado un funcionamiento erróneo del mismo que exige reparación

• ... y al hacerlo - Nunca jamás culpar a los participantes, ni tan siquiera indirectamente,

por la ocurrencia de un determinado problema - Evitar, a toda costa, informar a los participantes acerca de cómo hacer

algo - Incrementar de forma gradual las pistas reveladoras a proporcionar a

los participantes para que superen un obstáculo, en lugar de revelar el procedimiento de una sola vez

- Hay que ser consciente del efecto que podrían producir los comentarios en la realización de las tareas por los participantes

6. 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

161

validez. ¿Se advierte alguna tendencia de los datos? ¿Son más complejas determinadas partes del producto?

EJEMPLOS DE DATOS DE REALIZACIÓN Tiempos - Tiempo para completar una tarea - Tiempo para alcanzar un nivel con criterio competitivo - Tiempo de entrenamiento para alcanzar una realización de referencia - Tiempo para recuperarse de un error - Tiempo empleado en leer frente al tiempo empleado en trabajar Conteos y tasas - Número de errores - Porcentaje de tareas completadas de forma exitosa - Frecuencia de valoración de la ayuda en línea - Número de pasos o procedimientos omitidos - Resultados de los tests de comprensión

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.

EJEMPLOS DE DATOS PREFERENCIALES Comentarios del participante y sus opiniones - Preferencias de la versión A frente a la versión B - Sugerencias para la mejora del producto - Número de referencias negativas al producto - Fundamentos para la realización - Tasas o valoraciones del producto Cuestiones previas a la reunión de datos - ¿Qué datos direccionarán los estamentos del problema en el plan de test? - ¿Cómo se van a reunir los datos? - ¿Cómo se van a registrar los datos? - ¿Cómo se planifica la reunión y análisis de datos? - ¿Cómo y a quién se informará de los resultados obtenidos? - ¿De qué recursos se dispone para asistir el proceso global?


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 los objetivos del diseño.

162

6.1.3 Algunas variantes del Test de Usabilidad

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 participantes en el test de usabilidad del sistema. Otra variante del método incluye a un usuario experto que actúa como tutor mientras que el director de test observa la interacción entre participante y sistema y entre participante y tutor.

El método resulta útil ante el planteamiento de proporcionar

entrenamiento o ayudas más adecuadas. La participación de un usuario experto aporta, además, un modelo mental que puede ser de interés para el observador. Adicionalmente, a través de sucesivas sesiones, se pueden plantear distintas respuestas por el tutor a las mismas preguntas, para después evaluar las más apropiadas.

Método de Seguimiento (Shadowing Method)__________________

Un usuario experto en el dominio de la tarea explicará al evaluador los problemas y reacciones del usuario de test. El usuario experto se sitúa, habitualmente, ligeramente por detrás del evaluador "como si fuera su sombra". El observador asume con mayor facilidad el modelo mental del usuario experto y se concentra en la interacción entre usuario y sistema.

Método de Instrucción previa (Teaching Method)_____________

En una fase previa se permite a los participantes interaccionar con el sistema para adquirir cierta soltura en su manejo. Después, habrán de ayudar a un usuario inexperto a realizar las tareas que se le encomienden. Sin embargo, la actuación de este participante queda limitada, pues no entrará en la dinámica de resolver problemas. Ha este método se le denomina también Entrenamiento de Usuarios Noveles (Train Novice Users).

Aprendizaje por Descubrimiento Conjunto (Co-discovery Learning)____

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. Este punto va a ser tratado con mayor amplitud próximamente.

Test Retrospectivo (Retrospective Testing)______________________

Este método, que adopta su nombre del mundo de la psicología y el psicoanálisis, consiste en la revisión de los registros realizados durante el Test. Frecuentemente, dicho test se habrá grabado en vídeo y se revisará la

163

cinta, preferiblemente en compañía de los usuarios participantes. Así, esta técnica aparece en combinación con otras, especialmente en aquellas en las que la interacción entre usuarios y conductores de test es limitada.

Se trata de hacer una revisión del registro en vídeo de la sesión de test. El usuario ha de participar en esa revisión posterior. Los comentarios del usuario durante la revisión de la cinta suelen resultar mucho más extensos e intensos que los comentarios que generó durante la realización de las tareas durante la sesión de test. Además, el experimentador puede detener la cinta y preguntar al usuario con mayor detalle sin preocuparse por interferir en el test, que esencialmente, en ese momento, ya ha sido completado.

El Test Retrospectivo resulta de especial interés en aquellos casos donde los usuarios de test representativos son difíciles de conseguir, dado que se presenta la oportunidad de obtener una mayor cantidad de información adicional de cada usuario. ¿cuál es el problema? que cada test puede tener una duración doble, por lo que el método no es apto cuando los usuarios participantes van a recibir elevados incentivos.

6.2 Protocolo del Pensamiento Manifestado

(Thinking Aloud Protocol)

El protocolo del pensamiento manifestado es una técnica popular utilizada durante el test de usabilidad. 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. ¿Cómo se puede llevar a cabo esta técnica?

Se comienza proporcionando al participante del test el producto en

cuestión o un prototipo de su interfaz, así como un escenario de tares a realizar. Se solicita de los participantes que lleven a cabo las tareas con el producto mientras explican lo que piensan cuando trabajan con su interfaz.

El pensamiento en voz alta va a permitir entender la aproximación del usuario a la interfaz y las consideraciones que mantiene en mente mientras hace uso de ella. Si el usuario manifiesta, o expresa, que la secuencia de pasos que impone el producto para llevar a cabo su tarea objetivo es diferente a la que había imaginado, quizás ocurre que la interfaz es un tanto enrevesada.

164

Aunque el principal beneficio que aporta este método es un mejor entendimiento del modelo mental del usuario y de su interacción con el producto, se pueden conseguir otras ventajas. Por ejemplo, la terminología utilizada por el usuario para expresar una idea o función puede ser susceptible de ser incorporada en el diseño del producto o, cuanto menos, en la documentación asociada.

Se habla de dos variantes de la técnica del pensamiento manifestado (o verbalización del pensamiento): - Respuesta crítica: Se requiere del usuario que hable tan solo durante

la ejecución de un conjunto predeterminado de subtareas. - Informe periódico: Cuando la tarea es compleja y resulta difícil a los

usuarios manifestar sus pensamientos mientras la llevan a cabo. Así pues, el usuarios se expresa en voz alta a determinados intervalos de tiempo y descubre qué es lo que hace y qué es lo que está tratando conseguir

En ocasiones se hablará, también, de "Protocolo Simplificado de

Pensamiento Manifestado". ¿Qué significa esto?. Simplificar en la medida de lo posible todos los procedimientos referentes a: - la selección de personal especializado - el entrenamiento previo de los usuarios y de los desarrolladores - el desarrollo del análisis de datos (esto es, que se puede basar en notas

en lugar de hacerlo en cintas de vídeo, lo que es caro y lleva mucho tiempo, que se empleará mejor en concentrarse en más usuarios y más iteraciones). Los protocolos de vídeo es preferible dejarlos para investigación.

6.2.1 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. La capacidad del usuario (o su ausencia) para contestar dichas preguntas sirven de ayuda para detectar qué partes de la interfaz resultan obvias y qué otras resultan oscuras.

Se trata de un planteamiento más natural pues las preguntas a

formular facilitan la expresión del usuario al servir de punto de partida de la misma. ¿Cómo se puede llevar a cabo esta técnica?

165

Se proporciona a los participantes el producto que va a ser sometido a

test (o bien un prototipo de su interfaz) y un escenario de tareas a realizar. Se solicita de los participantes que realicen las tareas haciendo uso del producto y explicando lo que piensan mientras trabajan con la interfaz del producto. De igual manera, se les formula preguntas puntuales y directas; por ejemplo "¿Cómo enviaría este correo electrónico?". La respuesta, tanto si se basa en el producto que está siendo testado como si se basa en la experiencia pasada, proporcionará elementos suficientes para empezar a vislumbrar el modelo mental que ha elaborado el usuario. ¿Cuándo debería usarse esta técnica?

Esta técnica puede ser utilizada en cualquier fase del proceso de desarrollo.

6.3 Realización de Medidas (Performance Measurement)

Algunos test de usabilidad tiene como objetivo la determinación de

datos cuantitativos. En la mayoría de las ocasiones estos datos aparecen en forma de métricas de actuación(¿Cuánto cuesta seleccionar un bloque de texto con un ratón, un "touchpad" o un "trackball"? ¿Cómo influye la colocación de la tecla de retroceso en la tasa de errores?)

A menudo estas métricas se utilizan como objetivos durante el diseño de un producto. Los objetivos pueden plantearse como algo que se estipula, por ejemplo, "los usuarios deben ser capaces de conectarse a Internet sin errores o con la ayuda que se proporciona en un teléfono gratuito", o bien, "el 75% de los usuarios debe ser capaz una tarea básica en menos de una hora". Estas referencias se conciben durante un primer test de usabilidad, bien sobre una versión previa, bien sobre un producto de la competencia. ¿Cómo se puede llevar a cabo esta técnica?

Se comienza siguiendo los conceptos básicos del test de usabilidad para determinar el propósito, identificar los objetivos del test, diseñar los experimentos y llevarlos a cabo. Para la realización de medidas, sin embargo hay que considerar ls siguientes aspectos:

166

Los objetivos deben ser cuantificables_________________________ Como antes, los objetivos del test han de plantearse en términos

testeables, pero a la hora de realizar medidas han de resultar cuantificables. Por ejemplo, podría formularse la pregunta "¿Qué resulta más eficiente, los atajos por teclado o los botones en la barra de herramientas?". Una pregunta formulada así puede ser testada con dos interfaces, una de ellas utilizando atajos de teclado y la otra utilizando botones. Se registraría la actuación de cada usuario, cronometrando cuánto les ha costado ejecutar un número de ordenes y registrando sus errores.

Medidas típicas cuantificables de usabilidad (Nielsen,93)

� El tiempo que los usuarios se toman para completar una tarea específica � El número de tareas (o la proporción de una tarea mayor) de diversos tipos que pueden ser

completadas dentro de un tiempo límite dado � La relación entre las interacciones exitosas y los errores � El tiempo empleado en la recuperación de los errores � El número de errores de usuario � Porcentaje de competidores que consiguen una mejor marca � El número de acciones erróneas inmediatamente posteriores � El número de comandos u otras características que fueron utilizadas por el usuario (tanto el número

absoluto de comandos como el número de diferentes comandos y características utilizadas) � El número de comandos y otras características que en ningún momento fueron utilizadas por el usuario � El número de características del sistema que el usuario puede recordar durante una sesión informativa

después del test � La frecuencia del uso de manuales y/o ayuda del sistema y el tiempo empleado en el uso de estos

elementos del sistema. � La frecuencia con la que el manual y/o la ayuda del sistema resolvieron el problema del usuario � La proporción de aseveraciones del usuario de carácter positivo durante el test frente a aquellas críticas

hacia el sistema � El número de ocasiones en que el usuario presenta una frustración (o contento) evidentes. � La proporción de usuarios que dicen preferir el sistema antes que otro de la competencia � El número de ocasiones en que tuvo que volver el usuario sobre un problema irresoluble. � la proporción de usuarios haciendo uso de estrategias de trabajo eficientes en comparación con los

usuarios que utilizan estrategias ineficientes (en el supuesto de que haya diversas formas de llevar a cabo las tareas)

� La cantidad de "tiempo muerto" durante el cual el usuario no interactúa con el sistema. El sistema puede estar instrumentado para distinguir entre dos tipos de tiempo muerto: los retrasos asociados a los tiempos de respuesta donde es el usuario el que espera al sistema y los tiempos de reflexión en los que el sistema espera al usuario. la aproximación a estos tiempos a de hacerse de distintas formas

� El número de ocasiones en que el usuario se desvía de la tarea real Medidas típicas cuantificables de usabilidad (Nielsen,93) El diseño experimental es realmente importante_______________

Dado que el objetivo de la realización de medidas es la reunión de datos cuantitativos válidos, el diseño experimental debe ser igualmente válido. Los test cuantitativos asumen que nuestro cambio en la variable independiente (por ejemplo, la presencia de atajos de teclado o de botones en la barra de herramientas) influye en la variable dependiente (el tiempo que cuesta la ejecución de los comandos haciendo uso de una de las dos opciones). Esta forma de influencia se conoce como efecto experimental. Sin embargo, si se introducen otros factores en el diseño, el efecto se confunde, esto es, no es estadísticamente válido al ser contaminado por los demás

167

factores. Nuestro diseño debe considerar estos factores y eliminar las posibles fuentes de contaminación. Los datos no lo dicen todo_________________________________

La realización de test para la mera obtención de datos y a no es tan habitual como lo era tiempo atrás por diversas razones. La realización de test requiere diseños de test muy rigurosos y grandes recursos. La mayoría de las empresas no cuentan con tiempo o dinero suficiente para la investigación de estas características. Además, el test se realiza a menudo a un nivel muy granular. ¿Importa realmente si resulta medio segundo más rápido el uso de un atajo de teclado frente al uso de un botó en la barra de herramientas? Podría ser, si estuviéramos diseñando un sistema de comunicaciones con miles de operadoras en todo el país, quienes ahorrando medio segundo por llamada, ahorrarían millones de dólares anualmente. Pero para la mayoría de las aplicaciones de oficina, medio segundo no tienen tanta relevancia. ¿Cuándo debería usarse esta técnica?

La realización de medidas se utiliza en las etapas iniciales de diseño para proporcionar referencias de utilidad al proceso de diseño. También se utiliza a lo largo del ciclo para comparar el trabajo realizado frente a las referencias inicialmente establecidas.

6.4 Protocolo del Descubrimiento Conjunto (Co-discovery Protocol)

El descubrimiento conjunto es una variante del test de usabilidad en la

que dos participantes intentan realizar las tareas juntos mientras están siendo observados. La ventaja de este método sobre el del pensamiento manifestado se refleja por partida doble: - En el lugar de trabajo, la mayoría de las personas cuenta con alguien

que pueda ayudarles. - La interacción entre los dos participantes puede revelar más

información que un único participante expresando en voz alta sus pensamientos

Beneficios

• Buenos resultados en etapas tempranas de diseño • Fomenta una forma de interacción natural • Genera más comentarios que los protocolos de pensamiento

manifestado • El test es mucho más rápido • Resulta más fácil para el experimentador • Magníficos resultados para aplicaciones y situaciones donde las

168

personas trabajan juntas • Resulta mucho más ameno para los dos participantes

Limitaciones

• Los resultados obtenidos van a depender de cuestiones de aprendizaje, nivel cultural, jerarquía,...

• La selección de candidatos ha de ser muy cuidadosa • Sensación de incomodidad entre los participantes si las metas y las

reglas no quedan bien definidas • Es preciso decidir sobre el método de test apropiado sobre la tarea

a estudiar • Se requiere de un mayor número de participantes • El análisis de los datos es más complicado

Beneficios y Limitaciones de la técnica del Descubrimiento Conjunto


Se proporciona a los participantes el producto que va a ser sometido a test (o bien un prototipo de su interfaz) y un escenario de tareas a realizar. Se solicita de los participantes que realicen las tareas haciendo uso del producto y explicando lo que piensan mientras trabajan con la interfaz del producto. Se les permite ayudarse entre ellos de la misma forma que si estuvieran trabajando juntos para conseguir un objetivo común mediante el uso del producto. ¿Cuándo debería usarse esta técnica? Esta técnica puede ser utilizada durante cualquier fase del proceso de desarrollo de productos utilizados por trabajadores en entornos de trabajo en equipo.

Beneficios y limitaciones de la técnica del Descubrimiento Conjunto

Se va a realizar un pequeño análisis de los beneficios y las limitaciones de la técnica del Descubrimiento (o Aprendizaje) conjunto. Se da comienzo por los beneficios: • Buenos resultados en etapas tempranas de diseño Esta técnica va a permitir al diseñador reunir los requerimientos de usabilidad en una etapa temprana del proceso de diseño así como efectuar una comparación entre las posibles alternativas de diseño, obtener una variedad de respuestas a la interfaz,... esto es, una serie de conclusiones más bien cualitativas. • Fomenta una forma de interacción natural Se va a establecer un flujo de comunicación natural entre ambos participantes (incluso cuando estos son perfectos desconocidos) y entre estos y el moderador de la sesión, lo cual no siempre ocurre cuando se trabaja con un único usuario ("ansiedad de test"). La comunicación, en forma

169

de ayuda o asistencia, anula en buena parte la tensión y la frustración y puede llegar un momento en el que la conversación tiene lugar sin apenas esfuerzo cognitivo. • Genera más comentarios que los protocolos de pensamiento

manifestado Los participantes presentan ahora una mayor tendencia a formular preguntas al moderador o director del experimento. En el proceso de resolución del problema, cada usuario siente la necesidad, por otra parte, de alcanzar el consenso, lo que estimula el diálogo. Se comunican lo que hacen y lo que piensan, así como cuál creen que puede ser el próximo paso en el desarrollo de la tarea, o para que creen que sirve un determinado mando, accionamiento, menú,... (algunos autores afirman incluso que una sesión de descubrimiento es comparable, en resultados, a dos protocolos de pensamiento manifestado) • El test es mucho más rápido Básicamente, esto es atribuible al mayor éxito en el desarrollo de tareas. Un ejemplo bien conocido es el emparejamiento en las actividades de laboratorio. No se puede negar que es un intento de economizar la logística de hardware, pero también se está ahorrando tiempo, la generación de resultados es más rápida y se obtienen datos adicionales como tasas de éxito, tiempos medios de conclusión, tasa de uso de manuales,... • Resulta más fácil para el experimentador Los experimentadores van a permanecer más alejados de lo participantes pues van a precisar de un esfuerzo menor para estimular su expresión. Ello reducirá, además, las posibilidades de polarización de los resultados del test por la influencia del experimentador. • Magníficos resultados para aplicaciones y situaciones donde las

personas trabajan juntas El co-descubrimiento, o coparticipación, refleja un entorno de trabajo real, especialmente en aplicaciones o situaciones que requieren de cooperación, consenso, o simplemente, de que haya un flujo de comunicación en forma de ayuda entre las personas. • Resulta mucho más ameno para participantes y observadores Efectivamente, las sesiones resultan mucho más interesantes para todos, lo que puede resultar muy útil para promover la usabilidad y el diseño centrado en el usuario cuando desarrolladores y directivos se encuentran entre los observadores. En cuanto a las limitaciones en la aplicación de esta técnica:

170

• Los resultados obtenidos van a depender de cuestiones de aprendizaje, nivel cultural, jerarquía,...

El experimentador va a tener que establecer reglas bien claras para minimizar el efecto de las diferencias entre los participantes y que estos se sientan cómodos durante la sesión. Puede ser un error emparejar a una persona locuaz con otra introvertida, que probablemente quedará anulada por la primera (El moderador ha de impedir que un único usuario domine la sesión: se puede solicitar de la persona introvertida que sea quien lea las instrucciones y escenarios). Distintos estilos de aprendizaje pueden, por otra parte, truncar el flujo de comunicación. Y lo mismo ocurre con la expresión de opiniones condicionadas por motivos culturales. • La selección de candidatos ha de ser muy cuidadosa En un intento de incrementar las posibilidades de que dos personas participen juntas de forma natural y cómoda es seleccionándolas ya como pareja. Después de encontrar a la primera persona, se le puede solicitar que sugiera a alguien con las características del perfil requerido con quien quisiera trabajar. Esto puede ser de gran utilidad, dado que ya están asentadas las bases del flujo de comunicación y los participantes disponen de un amplio repertorio de experiencias pasada en común. También se puede plantear un tándem veterano/novel, interesando el modo en el que el primero instruye y guía al segundo. Esta situación es interesante cuando se analizan los requerimientos de información acompañando al producto, ayudas en línea, mecanismos para la expresión de conceptos, metáforas más apropiadas. La cuestión más compleja se plantearía, precisamente, en una definición apropiada del sujeto "veterano" y el sujeto "novel" • Sensación de incomodidad entre los participantes si las metas y las

reglas no quedan bien definidas Los participantes sólo trabajarán bien juntos cuando entiendan que la coparticipación es una meta del test (esta cuestión ha de ser especialmente bien destacada) y asuman las reglas para trabajar juntos. Aparece otro problema en el modo en el que ambos participantes trabajan. Si se encuentran ante un ordenador, un electrodoméstico , inevitablemente habrán de turnarse, lo que puede provocar la impaciencia del usuario inactivo. Y sin embargo, la idea de actuar por turnos ya es artificial, tal cosa no ocurre en un entorno de trabajo real, donde alguien solicita ayuda a un compañero.

Lo que parece funcionar mejor es decir a los participantes que ambos

deben entender lo que está sucediendo. Esto lleva a una actitud más pausada, y los usuarios se refieren el uno al otro cuando efectúan una elección o dudan acerca de algún aspecto. Esto facilitará que el individuo menos activo se sienta capaz de interrumpir al otro

171

• Es preciso decidir sobre el método de test apropiado sobre la tarea a

estudiar Hay que tener bien claro cuáles son los objetivos del test para decidir si el método de co-descubrimiento es el apropiado para la tarea o la situación que se está testando. ¿Tiene la tarea un carácter colaborativo?, ¿requiere la situación de trabajo la cooperación entre miembros de un equipo?, ¿se corresponde la filosofía de la sesión con el mundo real? ,y , finalmente, ¿pretendo obtener datos cualitativos a cuantitativos?, ¿pueden ser aplicados al diseño? • Se requiere de un mayor número de participantes Muchos experimentadores opinan que es la forma de recoger una mayor cantidad de datos, pero, en general, el número de personas requeridas en el equipo de observación va a depender de la tarea a testar. • El análisis de los datos es más complicado La auténtica virtud del método radica en la norme cantidad de datos cualitativos que se obtienen de la sesión. Va a ser difícil efectuar un análisis detallado de errores: en general, se generarán largas listas de cuestiones generales, problemas y observaciones. Si no se consigue que los usuarios discutan los problemas entre ellos, se habrán de plantear posteriores entrevistas y resolución de cuestionarios por separado o se habrá de establecer una especie de acuerdo para obtener una respuesta común (lo que, resultará, de nuevo, un tanto artificial)

BIBLIOGRAFÍA

• Nielsen, J "Usability Engineering". Academic Press, 1993 • Dumas, J and Redish, J "A Practical Guide to usability Testing". Ablex,

1993 • Rubin, J "Handbook of Usability Testing: How to Plan, Design, and

Conduct Effective Tests". Wiley & Sons, 1994 • Stanton, N. "Human Factors in Consumer Products", Taylor and

Francis, 1998 • "Human-Centred Design Processes for Interactive Systems" ISO

13407 First Edition 1999-06-01

172

SITIOS DE INTERNET

• Centre for User Oriented IT Design. Dept. Computing Science. KTH, Royal Institute of Technology. Stockhom, Sweden http://cid.nada.kth.se/en/default.lasso

• The Usability Methods Toolbox http://www.best.com/~jthom/usability/

• Jakob's Nielsen site (Usable Information Technology) http://www.useit.com/

• World Wide Web Consortium http://www.w3c.org/ • Trace Research and Development Center. College of

Engineering. University of Wisconsin-Madison http://www.trace.wisc.edu/

• European Usability Support Centres-RESPECT project home page http://www.lboro.ac.uk/research/husat/respect/

o "Usability Maturity Model: Human Centredness Scale". J. Earthy Version 1.2. Date 1998/12/27 INUSE Information Engineering Usability Support Centres

o "Usability Maturity Model: Processes". J. Earthy. Version 2.2 Date 1999/08/19. INUSE Information Engineering Usability Support Centres

o "Proposed Usability Engineering Assurance Scheme". Bevan, Claridge, Earthy, Kirakowsky. Version 2 Date 31/1/98 INUSE Information Engineering Usability Support Centres

o "Design Guide for Multimedia". Vossen, Maguire, Graham, Heim Version 2.1. Julio 1997. INUSE Information Engineering Usability Support Centres

o "Requirements specification and evaluation for user groups with special needs". Nigel Bevan. Version 2.0. Agosto 1998. INUSE Information Engineering Usability Support Centres

• INCLUDE-INCLUsion of Disabled and Elderly people in telematics. TELEMATICS project 1109. Information for designers and others about Design for All of telematic devices and services http://www.stakes.fi/include/

• USINACTS-USability IN ACTS. The How To of Usability Evaluation & User-Centred Design http://atwww.hhi.de/USINACTS/usinacts.html

173

• Usable Web -1110 links about web usability http://usableweb.com/

• Usabilidad y Diseño Centrado en el Usuario. Recopilación de Métodos de Usabilidad http://www.area.com.mx/usabilidad/Herramientas.htm

Manual de T cnicas para el Dise o Participativo-usabilidad ... · I. Usabilidad y Diseño Centrado...

Documents

Transcript of Manual de T cnicas para el Dise o Participativo-usabilidad ... · I. Usabilidad y Diseño Centrado...