Documento usabilidad

INTRODUCCIÓN

Este trabajo nace como una inquietud sobre el problema de la usabilidad en el diseño
industrial, en el marco de la materia: Diseño de interfaces, nuevos escenarios.

Queriendo profundizar en esta dimensión desde el diseño, se inició un levantamiento de
información asociada al tema, encontrando como elemento característico que el concepto
de usabilidad se está direccionando en la mayoría de los casos al medio informático.

La desmaterialización del objeto y la tendencia a la miniaturización han hecho que la
interfaz en los productos por los avances tecnológicos asociados a la electrónica, hayan
hecho posible que la discusión en torno a la usabilidad se asocie solamente al sistema de
relación que se está construyendo en la interfaz hombre-medio informático.

En algunos casos se encontraron observaciones asociadas a la ergonomía (sistema de
relación hombre- máquina) y el papel que desempeña en la configuración de nuevos
productos.

Profundizando y especializando aún más la búsqueda en temas asociados al desarrollo
de producto, apareció la visión desde la ingeniería, que se condensa en el método QFD
empleado desde la ingeniería concurrente al interior de las organizaciones productivas.

De esta amalgama de visiones entorno a la usabilidad, es de donde se parte en este
trabajo, para tratar de caracterizar la usabilidad desde un punto de vista más genérico y
que permita a su vez estructurar una visión más centrada en el problema del uso y en la
interacción entre el hombre y el objeto-producto, pues en síntesis es ahí donde debe
concentrarse la discusión.

En la estructura del trabajo encontraremos estos apartes, y en cada uno de ellos se hará
una reflexión desde la visión del Diseño Industrial. Se debe tener en cuenta que dichas
reflexiones parten de la visión como diseñador industrial latinoamericano, la cual se
distancia de la visión española que se direcciona más hacia la ingeniería de diseño.

PRINCIPIOS DEL DISEÑO
CENTRADO EN EL USUARIO

El diseño, sea cual sea el objeto del mismo, tiene que basarse
en el usuario, y el usuario puede ser cualquier individuo
(Diseño para Todos).

Vamos a ver que los principios del diseño centrado en el
usuario no son más que una reformulación de los principios
más elementales de la Ergonomía Clásica y de aquellos se
derivan, en general, las guías de accesibilidad.

Lamentablemente, no son pocos los diseñadores que no
advierten tal circunstancia, resultando conveniente explicitar
ciertos aspectos que proporcionarán una perspectiva más
amplia, sin duda, a estos principios.

Otros, simplemente, considerarán inviable el planteamiento.
No hay que confundirse: nadie puede hacer un producto
absolutamente accesible. Podrá hacerse, en todo caso, más
accesible, pero siempre habrá personas que no puedan hacer uso del mismo. Estos
principios, pues, deberían servir para incrementar el cuidado y la comprensión de los
diseñadores a la hora de plantearse determinadas preguntas. Los diseñadores deben
llevar en mente estos principios de forma continua.

Es interesante ver como de nuevo se pone en boga la usabilidad, por el mismo mercado,
el cuál se direcciona en estos momentos sobre la plataforma del marketing....

FACTORES QUE DETERMINAN LA USABILIDAD

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

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

El usuario ha de tener la oportunidad de
personalizar la interfaz.

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

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

2

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

2. Es preciso un planteamiento directo:

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

La accesibilidad de la información y de las
opciones van a reducir la carga mental de trabajo
del usuario.

Las metáforas familiares proporcionan una
interfaz intuitiva.

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

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

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

Consistencia y estabilidad se van
a traducir en facilidad de uso.

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

NOTA: El concepto de metáfora está asociado al conocimiento previo adquirido por el
usuario en el proceso de aprendizaje, tanto formal (escolarizado), como no formal
(experiencias de la vida cotidiana). Esto es lo que permite afirmar que lo que yo no
conozco, no existe para mí.

4. Hay que posibilitar la recuperación de los errores:

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

3

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

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

Hay que contemplar los potenciales errores de los usuarios.

Esto es válido para cualquier tipo de producto, pues es el proceso de aprendizaje que
tiene el usuario cuando se ve enfrentado a un nuevo producto.

5. Retroalimentación apropiada por el sistema:

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

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

El estado de un sistema
(esperando entrada,
comprobando, transfiriendo
datos,...) debería estar siempre
disponible para el usuario.

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

6. No se puede descuidar la estética:

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

Es preciso proporcionar un entorno agradable que contribuya al entendimiento por
parte del usuario de la información presentada.

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

4

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

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

El uso del diseño ha de ser fácil de
entender, independientemente de la
experiencia, conocimiento, capacidades
lingüísticas o nivel de concentración del
usuario.

Hay que controlar la información
explicitada, que se ha de reducir al mínimo
necesario.

El diseño ha de comunicar la información
necesaria al usuario de forma efectiva,
independientemente de las condiciones
ambientales o de las capacidades
sensoriales del mismo.

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

8. Es fundamental seguir una rigurosa metodología de diseño:

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

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

9. El equipo de diseño debe ser equilibrado:

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

El trabajo en equipo ha de caracterizarse por la posibilidad de una comunicación e
interacción rápida y efectiva.

5

FASES EN EL PROCESO DE DISEÑO
DESDE LA USABILIDAD

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

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

Comunicación del diseño mediante el prototipado y establecimiento de un flujo de
tareas. Se puede tratar de incluir más aspectos y comprobar la reacción a los
mismos de los usuarios objetivo o tratar de centrarse en los detalles de dichos
aspectos, en su funcionalidad.

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

Después del test va a ser preciso el rediseño en mayor o menor medida, tras el
cual inevitablemente, es preciso de nuevo el test, volviendo así a iniciar el ciclo.

Observaciones:

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

Las diferencias en los modos de aprendizaje reflejan múltiples variantes que se
manifiestan en un continuo desde ligeras preferencias hasta profundas
necesidades. Así, es preciso acomodar esta diversidad mediante representaciones
alternativas de la información clave. A partir de diferentes preferencias y
necesidades (originadas por el propósito de la actividad de trabajo o aprendizaje y,
por supuesto, de la naturaleza de los propios usuarios) se puede seleccionar el
medio de representación o forma más apropiado.
Siempre habrá consideraciones de marketing que afectan a la forma del producto
y que pueden condicionar, en un determinado momento, un rediseño a mayor o
menor escala.

6

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

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

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

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

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

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

7

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

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

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

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

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

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

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

1. Importancia de la usabilidad

El establecimiento de unos principios de diseño en ingeniería de usabilidad han tenido
como consecuencia probada:

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

Reducción de los costes de mantenimiento y apoyo: los sistemas que son
fáciles de usar requieren menos entrenamiento, menos soporte para el usuario y
menos mantenimiento.

8

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

Mejora en la calidad del producto: el diseño centrado en el usuario resulta en
productos de mayor calidad de uso, más competitivos en un mercado que
demanda productos de fácil uso.

2. Cuando se ha de considerar la usabilidad

La usabilidad debería ser considerada en todo momento, desde el mismo comienzo del
proceso de desarrollo hasta las últimas acciones antes de hacer el sistema, producto o
servicio disponible al público.

Antes de iniciar el proyecto es esencial tener una idea acerca de las características de los
usuarios y de los aspectos del producto de mayor interés y necesidad. Teniendo en
cuenta estas consideraciones de forma temprana se ahorra tiempo y dinero, dado que la
posterior implementación de nuevos aspectos o nuevas interfaces de usuario implican un
enorme esfuerzo adicional. Incluso una vez que el producto está en el mercado se
debería preguntar a los usuarios acerca de sus necesidades y actitud respecto del mismo.

DISEÑO CENTRADO EN EL USUARIO

Podemos ceñirnos al significado literal de la expresión y pensar que el Diseño Centrado
en el Usuario consiste en diseñar por y para el usuario.

La aparición del término "Diseño Participativo", por otra parte, va a plantear la
necesidad de efectuar una serie de consideraciones acerca de la figura del diseñador en
el proceso de desarrollo

Frente a esta discusión, que hago la aclaración se centra en la interfaz informática y su
desarrollo en términos de diseño, se puede extrapolar de una manera más amplia al
campo del diseño de cualquier tipo de producto, se convierte en la conceptualización que
han realizado diferentes equipos de trabajo e investigación frente al tema. Para poder
caracterizar la diferencia de conceptos podemos evidenciarlos de acuerdo a quien y como
los definieron, pues no solo es una cuestión de semántica:

David Travis, de System-Concepts (http://www.system-concepts.com/), indica que la
idea de "diseño centrado en el usuario" propone que los diseñadores comprenden el
contexto de uso: esto significa un profundo entendimiento del usuario, del entorno en el
que se desarrolla el trabajo y las tareas de usuario. En contraste, la expresión "diseño
centrado en el uso" sugiere que el diseñador sólo necesita concentrarse en las tareas de
usuario, lo que parece que hace entender al usuario y al contexto como algo menos

9

importante. Sin embargo Travis indica que en la práctica, se plantean muy pocas
diferencias entre ambas aproximaciones, y entiende el término "centrado en el uso" como
una cuestión de marketing.

Jan Gulliksen, de la Universidad de Uppsala (Departamento de Interacción Hombre-
Computadora), presenta una opción casi opuesta, pues alega que el diseño centrado en
el uso no involucra al usuario en el proceso de diseño, mientras que el diseño centrado en
el usuario apunta a una presencia activa directa de este en el proceso de desarrollo del
mismo, entendiendo el concepto de la misma forma que los norteamericanos entienden el
de "diseño participativo". Además lleva por delante la importante distinción entre
comprador y usuario final (un administrativo en una corporación no elige la aplicación
informática mediante la cual realizará su trabajo).

Gulliksen propone cuatro principios básicos en la aproximación al Diseño Centrado en el
Usuario:
Un reparto apropiado de funciones entre usuarios y sistema
Una participación activa de los usuarios
Iteraciones en las soluciones de diseño
Equipos de Diseño Multidisciplinares

Heimrich Kanis, de la Delft University Technology (Departamento de Ergonomía), asume
otro significado de la expresión "centrado en el uso" y habla de modos o posibilidades de
uso. Así, en el estudio de una interacción particular producto-usuario se requerirán de dos
fuentes de datos básicas: las procedentes de los estudios ergonómicos (antropometría,
funciones fisiológicas,...) y las de las actividades de los individuos en su uso del producto
como gran condicionante de la funcionalidad del mismo. Al igual que Gulliksen, conviene
que lo verdaderamente importante es, pues, el modo en el que el usuario interacciona con
un producto y, en particular, con un prototipo, durante los diversos experimentos en el
proceso de desarrollo.

1. Diseño centrado en el usuario – diseño participativo

Se diferencia el Diseño Participativo del Diseño Centrado en el Usuario en que mientras
éste considera al usuario tan sólo al comienzo y al final del proceso de diseño, aquel lo
integra por completo en el proceso de desarrollo. La distinción es importante porque las
gestiones de los respectivos procesos de desarrollo son completamente diferentes y
especialmente más complejos en el caso del diseño participativo.

Sin embargo, esta diferencia que se está estableciendo sólo es válida en el ámbito
norteamericano, dado que en Europa se habla de Diseño Centrado en el Usuario (más
bien se está empezando a hablar) con el mismo significado que el Diseño Participativo en
Estados Unidos. Allí, el Diseño Participativo es más que desarrollar sistemas, quedando
íntimamente relacionado con una perspectiva de democratización del lugar de trabajo que
potencia al trabajador.

En este sentido podríamos decir no solamente trabajador sino usuario, pues la dimensión
puede ser aplicada a cualquier tipo de producto.

Una vez establecida la distinción entre Diseño Centrado en el Usuario y Diseño
Participativo, resulta conceptualmente sencillo asumir que este último no sólo involucra a
diseñadores y usuarios sino también a expertos en factores humanos e integrantes de la

10

dirección. Tal variedad se va a traducir inevitablemente en conflictos de objetivos,
competencias e incluso valores que conviene tener presentes.

En síntesis el concepto de diseño centrado en el usuario puede ser sinónimo del diseño
participativo para poder generalizar las visiones tanto norteamericana como europea. El
diseño centrado en el uso , podría considerarse como una visión menos integral en el
proceso de diseño, puesto que deja al usuario fuera del proceso y solo lo atiende en la
información de entrada de este y en la retroalimentación que se genera al final cuando se
pretende comprobar que lo realizado si cumple con los objetivos iniciales. Siendo un poco
fuertes en la percepción, esto es lo que permite el QFD, con la visión desde la ingeniería,
en donde el usuario se convierte en una serie de datos que alimentan el modelo y que
permiten en “teoría” llegar a una respuesta óptima en el desarrollo del producto.

En este punto quisiera aclarar una concepción que se tiene desde la formación de
diseñadores industriales alejados de la concepción de la ingeniería:

La razón de ser del diseñador no es el objeto, es el usuario, por lo tanto los objetos se
deben a los usuarios y en esta medida su existencia depende de ellos, no de su
fabricación, rentabilidad, o puesta en escena en el mercado. Suena un poco romántica la
posición, pero en esencia esa es la razón de la existencia del diseñador, pues es el canal
dentro de los sistemas de producción y del mercado, que le permiten participar al usuario
en lo que realmente quieren.... Esta visión dista mucho de la acuñada desde la ingeniería
en donde sucede todo lo contrario, pues el objeto es un fin y no un medio para la
satisfacción de las necesidades, expectativas y deseos de los “usuarios”, “demandantes”
o como se les quiera denominar a las personas a las que van dirigidos los objetos-
producto.

EL DISEÑADOR EN EL PROCESO DE DESARROLLO

Vamos a revisar rápidamente una serie de cuestiones a las que se tiene que enfrentar el
diseñador en el proceso de desarrollo y que revelan la necesidad de participación e
integración para una evolución apropiada del diseño.

Un primer, y sorprendente, problema va a aparecer en la elección del investigador o del
equipo encargado del trabajo de campo, de la búsqueda de requerimientos del usuario y
del análisis del contexto. No abundan los especialistas en factores humanos y usabilidad,
siendo frecuente que diseñadores y técnicos hayan de asumir ciertas funciones ampliando
su formación.

La noción de investigar un contexto o un espacio de diseño, de contemplar y combinar
variadas soluciones no les resulta sencilla a los diseñadores, acostumbrados a que se les
planteen problemas bien definidos para los que buscan una solución directa. La
comunicación con el usuario y, lo más importante, el entendimiento del mismo, peligran en
estas situaciones.

También puede ocurrir que usuarios experimentados y veteranos sean destinados a la
dirección de proyectos con el propósito de superar más rápidamente una etapa de
captación de requerimientos. Se busca, además, partir con cierta ventaja sobre

11

experiencias previas, pero supone un riesgo importante la adopción de un actitud
inmovilista respecto de las experiencias propias.

Hemos oído muchas veces eso de que los usuarios no son diseñadores y los diseñadores
no son usuarios. Efectivamente, es frecuente que a la hora de llevar a la práctica
determinadas metodologías de participación, los diseñadores partan con ideas
preconcebidas acerca de los usuarios.

Los diseñadores piensan en ocasiones que los usuarios no entienden de cuestiones
técnicas o tecnológicas, que no saben lo que necesitan o que son incapaces de generar
ideas de diseño. Tal circunstancia se puede traducir en la contaminación de las sesiones
de participación, pues el diseñador, en caso de intervenir, no potencia al máximo, e
incluso rehuye, el diálogo y la interacción.

El diseñador, por otra parte, trata, a menudo, de expresarse a través de su diseño, lo que,
dada, en general, la complejidad y amplitud de su formación, puede reflejarse en sistemas
excesivamente complejos que el usuario, inevitablemente, rechaza en el momento que se
le solicita para trabajar con los correspondientes prototipos

También se plantean conflictos de objetivos entre diseñadores y expertos en factores
humanos. Los especialistas en ergonomía cognitiva no tienen una especial predilección
por el diseño, que, explícitamente, asocian con tecnología. En muchas ocasiones, su
trabajo se relega a fases finales del proyecto; es, a posteriori, cuando han de asesorar al
usuario y evalúan el impacto del diseño. Sin embargo, su actividad es fundamental en las
etapas iniciales al desarrollo.

No faltan conflictos entre desarrolladores y dirección. La dirección soporta presiones con
una continua exigencia de resultados y los directivos acuden a los diseñadores: necesitan
algo que enseñar. Probablemente el diseño no estará terminado o requerirá
modificaciones, ensayos, inspecciones, pero pasará a tener un carácter de compromiso
hacia los altos ejecutivos.

FACTORES HUMANOS Y MARKETING

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

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

12

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

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

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

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

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

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

13

COSTE Y BENEFICIO DE LA INGENIERÍA DE "USABILIDAD"

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

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

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

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

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

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

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

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

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

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

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

14

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

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

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

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

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

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

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

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

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

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

Beneficios para el equipo de desarrollo:
Reducción de los costes del desarrollo y del control de calidad, y salida al
mercado más rápida.

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

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

15

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

Posible aumento de ventas del producto.

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

Reducción de los costes del soporte al usuario.

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

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

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

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

Reducción de la tasa de errores del usuario.

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

Aumento de la satisfacción.

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

Reducción del coste de mantenimiento.

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

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

16

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

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

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

• Un estudio demostró que el ahorro conseguido como consecuencia del desarrollo
de una buena interfaz de usuario fue de 41.700 dólares en una aplicación sencilla
utilizada por 23.000 empleados, y de 6.800.000 dólares para una aplicación
compleja utilizada por 240.000 empleados.
• Otros estudios han estimado que la relación entre el beneficio obtenido y el coste
de desarrollar una buena interfaz puede ser más de 5.000 a 1.
• Se han desarrollado incluso modelos matemáticos que estiman el ahorro en
39.000 dólares para un proyecto pequeño, 613.000 dólares para un proyecto
mediano, y 8.200.000 dólares para un proyecto grande.

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

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

• Un estudio de la compañía NCR mostró un incremento en la producción del 25% y
una reducción adicional del número de errores también del 25%, como resultado
del nuevo diseño de la interfaces de usuario.
• En otra compañía, el resultado de un análisis fue que una buena interfaz de
usuario reducía el entrenamiento necesario en un 35% y reducía el tiempo de
supervisión en un 30%.
• Un estudio similar en IBM mostró que el tiempo de entrenamiento para un sistema
era de una hora, frente a una semana en un sistema equivalente sin una buena
interfaz de usuario.

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

S. Dray refiere también [DRAY95]:

• Una compañía de seguros invirtió 3 millones de dólares en una aplicación para sus
agentes; sin embargo, estos se negaron a utilizarla porque era "imposible de usar
y de aprender".
• En otra empresa el entrenamiento en su sistema duraba normalmente 6 meses,
pero sus empleados trabajaban sólo durante 18 meses.
• En un sistema de soporte a la gestión una de las funcionalidades más relevante y
cara no fue utilizada nunca porque los usuarios olvidaron como acceder a ella una
semana después del entrenamiento.

17

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

• La complicada interfaz de usuario del sistema de seguimiento Aegis contribuyó al
derribo erróneo del avión de pasajeros Iraní.
• La incapacidad del barco estadounidense Stark para repeler los misiles Exocet fue
debida en parte a una interfaz de usuario.
• Un error en la implementación del manejo del cursor contribuyó a la muerte de
varios pacientes por exceso de radiación en su tratamiento.

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

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

Primer estudio

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

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

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

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

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

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

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

18

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

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

Segundo estudio

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

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

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

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

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

19

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

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

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

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

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

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

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

3. Modelo coste-beneficio

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

20

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

3.1 Modelo simplificado de coste

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

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

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

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

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

3.2 Modelo simplificado de beneficio

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

Sistemas internos:

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

Sistemas comerciales:

¿Incremento de ventas o del precio?.

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

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

21

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

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

La Ecuación 1 representa dicho modelo.

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

3.3 Número óptimo de usuarios

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

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

Para ello Nielsen parte de dos premisas:

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

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

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

22

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

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

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

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

3.4 Número óptimo de iteraciones

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

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

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

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

23

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

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

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

Discusión

Hay varios comentarios que matizan las conclusiones de Nielsen.

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

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

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

24

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

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

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

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

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

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

Conclusiones

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

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

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

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

25

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

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

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

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

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

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

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

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

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

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

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

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

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

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

26

ANEXOS

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

27

ANEXO 1
COMPILACIÓN DE MÉTODOS
DE USABILIDAD

El siguiente documento consiste en una recopilación de herramientas de usabilidad y
Diseño centrado en el usuario. En la misma, se han establecido cuatro categorías
(Indagación, Inspección, Test y Técnicas Relacionadas), proporcionándose una breve
descripción de cada una de ellas, al igual que de los métodos que comprenden.

La traducción de los nombres de dichos métodos al castellano (la práctica totalidad de la
bibliografía disponible está en lengua inglesa) se ha llevado a cabo con la intención de
reproducir con la mayor fidelidad posible el significado de la herramienta. Sin embargo, el
autor espera, y desea, que surjan opiniones, comentarios, propuestas alternativas y
correcciones.

Este documento es la recopilación de herramientas de usabilidad de James Hom (The
Usability Methods Toolbox) mientras que los demás están vinculados con lo que podría
entenderse como la referencia básica. Es objetivo a corto plazo efectuar un tratamiento de
estos últimos métodos en castellano con indicaciones y bibliografía adicional. Mientras
tanto, esta página pretende tener más un carácter bibliográfico, dando la oportunidad al
lector, al mismo tiempo, de adquirir una perspectiva sobre las técnicas de Diseño
Centrado en el Usuario.

Métodos de Indagación

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

Prototipado y categorización

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

28

MÉTODOS DE INDAGACIÓN

APROXIMACIÓN CONTEXTUAL

Dentro de la aproximación contextual es posible distinguir dos variantes claramente
diferenciadas:

Una aproximación contextual propiamente dicha, para la cual el método característico es
el de Indagación en el Contexto (Contextual Inquiry). Se trata, básicamente, de un método
estructurado de entrevista de campo caracterizado por la necesidad de comprender el
contexto, de asimilar al usuario en el proceso de diseño y de plantear un objetivo (focus)
en su aplicación.

Una aproximación etnográfica, para la cual la bibliografía ofrece muchas denominaciones.
Una de las más comunes es el de Estudio etnográfico u Observación de Campo
(Etnographic study/Field Observation). Consiste en la observación del usuario y su
interacción con el producto en su entorno habitual, prescindiendo de las ventajas del
laboratorio a la hora de captar y registrar datos.

También se habla de la "Observación al Natural" (Naturalistic Observation), como una
variante, menos "agresiva", de la Indagación en el Contexto. Se tiene mayor interés en
tareas y en procesos, y se desmarca ligeramente del carácter antropológico del Estudio
Etnográfico. De la misma forma, el Estudio de Campo Orientado a la Actividad (Proactive
Field Study), contempla, además de la observación de las características de los usuarios,
el análisis de tareas, el análisis de objetivos y la evolución del usuario con el sistema
sometido a estudio.

Una variante de interés es la denominada Etnografía Rápida (Rapid Ethnography), que
cuestiona la necesidad de precisión ante la velocidad de obtención de resultados
aceptables generados por aproximaciones razonables.

También se habla de la Video-Etnografía (Video ethnography) y de la Observación Directa
(Direct Observation) como sistemas de Observación Experta, que se caracterizan por ser
llevados a cabo por grupos expertos cuyos servicios se alquilan.

Indagación
(Inquiry)

Una primera categoría para la clasificación de los métodos de usabilidad es la de
indagación. La identificación de requerimientos, tanto los del usuario como los de nuestro
producto, son indispensables en una etapa temprana de un proceso de desarrollo que
culmina en la satisfacción de una necesidad del usuario, quien con eficiencia y efectividad
habrá de realizar las funciones que ese producto le ofrece. Por tanto, inicialmente, hay
que descubrir, y va a resultar de especial interés que las metodologías a aplicar en una
primera fase proporcionen información acerca de la usabilidad de un producto que aún no
se ha empezado a fabricar.

29

Indagación en el Contexto
(Contextual Inquiry)

¿En qué consiste?
La indagación en el contexto es básicamente un método estructurado de entrevista de
campo, basado en unos pocos principios fundamentales que diferencian este método de
la simple entrevista periodística. Así, es más un proceso de descubrimiento que un
proceso de evaluación; es más parecido a aprender que a evaluar.

Este método se basa en tres principios fundamentales: que entender el contexto en el que
un producto es utilizado (el trabajo que está siendo realizado) es esencial para un diseño
elegante, que el usuario es parte del proceso de diseño y que el proceso de diseño para
la usabilidad, incluyendo los métodos para su mejora como la indagación en el contexto y
test de usabilidad, deben tener un objeto o focus.

Supongamos, por ejemplo, que se necesita mejorar la usabilidad de una herramienta, una
llave, para la reparación de vehículos. Utilizando esta técnica se empezará visitando a los
mecánicos al taller de reparaciones, y no sólo habría de fijarse uno en las disposiciones
físicas, como pueda ser la localización de las herramientas o las condiciones dentro de los
compartimentos del motor, sino también en las cuestiones ambientales, tales como la
limpieza de las manos, el nivel de ruido en el taller, o la rigidez de los horarios impuestos
por los jefes. Todo esto ayudaría a definir el contexto de su trabajo así como el contexto
de uso del producto, la llave.

También se oirían quejas sobre la herramienta; cómo se les escapa de las manos si han
estado trabajando con sustancias grasas, cómo roe las esquinas de los pernos. Habría
que preguntar a los mecánicos qué facilitaría su trabajo, que cambios en el diseño les
ayudarían. Forman parte del proceso de diseño.

Desde luego, toda esta búsqueda se conduciría sobre la cuestión que se está analizando,
esto es, la herramienta. Este enfoque es importante, puesto que establece las metas para
la visita (por ejemplo, se necesita saber cómo se guardan las llaves). Una vez que se ha
realizado la visita, se podrá comprobar de las notas tomadas si se encontró lo que se
necesitaba saber.

¿Cómo lo llevo a cabo?
La indagación en el contexto sigue muchos de los pasos de las observaciones de campo
y las entrevistas. Sin embargo, es preciso mantener diversas consideraciones en mente
con algunas partes del proceso.

Por ejemplo, entrevistar durante un estudio basado en este método no contempla la
formulación de preguntas completas ni elaboradas. Sin embargo , la relación establecida
entre entrevistador y entrevistado desembocará en un diálogo en el que es posible
determinar tanto las opiniones y experiencias del usuario como sus motivaciones y
contexto.

En muchas ocasiones, la presencia del entrevistador va a incomodar al entrevistado.
Como entrevistador, es realmente preciso ser parte del mundo del usuario para conseguir
la efectividad deseada, lo que puede llevar tiempo hasta que el usuario se acostumbra a

30

su presencia. En ese punto, el trabajo se vuelve mucho más fácil, dado que al usuario le
resulta mucho más fácil expresar lo que realmente piensa del producto.

Esta circunstancia se traduce en un estudio de larga duración; se establece una relación
con la organización que se está estudiando, y se determinan las visitas, su frecuencia y su
duración. Se puede establecer un similitud con los estudios etnográficos, en los que el
etnógrafo vive durante uno o dos años con una determinada cultura.

Es muy importante determinar a quién se va a entrevistar. En muchas ocasiones el
usuario final que tenemos en mente no es la persona que más se va a ver afectada por
nuestro diseño o rediseño. Por ejemplo, cuando se cambian o actualizan las aplicaciones
informáticas de una corporación, la persona más afectada es la encargada de la dirección
de los sistemas de información que tiene que instalar la aplicación en cuestión en cada
ordenador del edificio. Trabajar con esta persona durante un día nos puede dar una
aproximación de lo bien diseñado que está el proceso de instalación y la interfaz.

Tras cada visita es preciso determinar si se alcanzaron los objetivos planteados así como
las preguntas a efectuar en la próxima visita.

¿Cuándo debería usar esta técnica?
La indagación en el contexto es uno de los mejores métodos a utilizar cuando es
realmente preciso entender el contexto de trabajo del usuario. El entorno en el que las
personas trabajan influye realmente en el modo en el que se hace uso de un producto
(¡hay personas que imprimen su correo e indican sus comentarios sobre el mismo antes
de contestar!).

¿Quién me puede decir más acerca de ella?
Beyer, Hugh, "Getting Started with Contextual Techniques".

Beyer, Hugh, and Holtzblatt, Karen, "Apprenticing with the Customer: A Collaborative
Approach to Requirements Definition," Communications of the ACM, May 1995.

Beyer, Hugh, and Holtzblatt, Karen, Contextual Design : A Customer-Centered Approach
to Systems Designs, 1997, Morgan Kaufman Publishers, ISBN: 1558604111

Holtzblatt, Karen, and Beyer, Hugh, "Making Customer-Centered Design Work for Teams,"
Communications of the ACM, October 1993.

Holtzblatt, K., and Jones, S. "Contextual Inquiry: A Participatory Technique for System
Design.'' in Schuler, D., and Namioka, A. (eds.) Participatory Design: Principles and
Practice. Lawrence Earlbaum, Hillsdale, NJ. 1993: 180-193.
Aproximación Contextual
Copyright James Hom (1996).
Traducido por Alejandro Floría (Enero 2000)
alejandrofc00@hotmail.com
Área de Ingeniería de Proyectos.
Departamento de Ingeniería de Diseño y Fabricación.
Centro Politécnico Superior | Universidad de Zaragoza.
María de Luna, 3, 50.015, Zaragoza, España.
Estudio

31

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

¿En qué consiste?
La observación de los usuarios en su entorno habitual es, a menudo, la mejor forma de
determinar sus requerimientos de usabilidad. Mientras que el test de usabilidad tradicional
proporciona un entorno de laboratorio que facilita la captación y registro de datos, al
mismo tiempo saca al usuario y al producto del contexto del lugar de trabajo. En
ocasiones es preferible ver cómo se hacen las cosas en el mundo real.

Se comienza disponiendo la visita de campo con los usuarios. Hay que elegir una amplia
variedad de usuarios para el producto, procedentes de diversos lugares de trabajo,
industrias y contextos, con los que se podría establecer contacto a través de
organizaciones de consumidores.

Hay que utilizar el tiempo con inteligencia. Por lo general se dispondrán de unas pocas
horas en el lugar en cuestión, por lo que se habrá de captar la mayor cantidad de
información posible mientras se está allí, relegando cualquier tipo de análisis de la misma,
con posterioridad, a nuestro lugar de trabajo.

Una parte de la observación de campo consiste en indagar; esto es, entrevistar a los
usuarios acerca de sus trabajos y la forma en que hacen uso del producto. La otra parte
consiste en la observación propiamente dicha, la del modo en el que las personas harían
uso del producto en el curso de un día de su vida cotidiana.

Una manera de asegurar una captación de datos apropiada es la de identificar el mayor
número de artefactos (artifacts) y "afloramientos" (outcroppings) posibles:
los artefactos son objetos físicos utilizados en un determinado lugar (cuadernos,
formularios, informes, tablones,...)

con "afloramientos" se hace referencia a los rasgos físicos que caracterizan al
lugar en cuestión (el tamaño de los despachos, de las pizarras, lo que hay escrito
en ellas, los uniformes de determinados miembros del personal).

Ambos términos provienen de la Antropología, en relación a la observación etnográfica, lo
que viene a significar "observar a las personas".

Así, las notas Post-It pueden entenderse tanto como artefactos como "afloramientos".

La disposición de los despachos, la localización del personal (quién se sienta cerca del
jefe, quién se sienta cerca del muelle de carga, etc) pueden resultar también de interés.

Alguien de quien se solicite consejo o información no entrará dentro de ninguna de las dos
categorías, pero puede ser caracterizado como parte de una relación.

Cómo reunir artefactos y datos de los "afloramientos"
Lo cierto es que suena cómo si se participara en una excavación arqueológica, pero
realmente es bastante parecido. De la misma forma que un arqueólogo se fija en el
cuenco de una civilización antigua para determinar aspectos acerca de su nutrición, es

32

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

identificar los artefactos y "afloramientos" durante la entrevista u observación
reunirlos y marcarlos en el propio lugar
tomar fotos, guardar archivos en discos, solicitar planos o disposiciones de los
objetos
es posible realizar una observación remota mediante la ubicación de una cámara
en el lugar en cuestión, discutiendo con posterioridad las imágenes por teléfono
con los sujetos de interés del lugar

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

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

Las relaciones de grupo pueden ayudar a identificar el flujo de proceso y de información.
Estas incluyen la organización, jerarquía, relaciones y vínculos formales e informales
entre grupos, relaciones de carácter informativo,...

Patrones de Comunicación
Los patrones de comunicación muestran quién habla con quién y con qué frecuencia.
Para productos asociados a una comunicación intensiva, como telefonía, correo
electrónico o publicidad, esta información es vital.

Indagación
Cuando se pregunta cómo se hacen las cosas o cómo se supone que deben hacerse,
conviene utilizar fórmulas como "¿funciona?", "¿lo hace alguien de forma diferente?",
"¿por qué?".

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.


Kane, Kate, "Anthropologists Go Native In The Corporate Village," October/November
1996, Fast Company magazine.

Artículo sobre la búsqueda de trabajo de los etnógrafos en corporaciones.

33

Macht, Joshua, "The New Market Research," July 1998, Inc. magazine.

Artículo sobre los estudios de campo con bajo componente tecnológico frente a los
costosos "focus groups" para investigación de mercado y usuario.

Tamakoshi, Laura, 1996, Field Methods, and Field Notes.
Páginas Web en línea en http://www.truman.edu/academics/ss/faculty/tamakoshil/. Se
describen los métodos de Tamakoshi empleados durante su investigación antropológica
en Papua Nueva Guinea. Orientado hacia los antropólogos, pero de utilidad.

Wixon, D. , and Ramey, Judith (Eds.), 1996, Field Methods Casebook for Software
Design, John Wiley & Sons, Inc., New York, NY. ISBN: 0-471-14967-5
Un agradable vistazo a las técnicas etnográficas aplicadas en el diseño de software; de
hecho, el único libro encontrado por el autor en este sentido. Similar al Wiklund book en el
que se discuten las experiencias de quien ha practicado esta técnica.

APROXIMACIÓN POR GRUPOS

Se ha escogido la denominación de aproximación por grupos porque, si bien los
integrantes de los mismos han de ser usuarios representativos del producto sometido a
estudio, y por tanto integrantes de un contexto, durante la sesión no se encuentran en
dicho contexto, aunque van a ser sus experiencias e impresiones en el mismo, y sus
propias relaciones personales, las que conducidas por un moderador de manera formal y
estructurada van a proporcionar datos y generar ideas.

El de los Grupos Orientados (Focus Groups) es probablemente uno de los métodos más
conocidos y característicos, en los que la figura del moderador es fundamental y su
proceder es determinante para el éxito de la sesión. La bibliografía es abundante y muy
interesante.

En los Grupos de Debate (Group Discussion / Future Workshops), sin embargo, el
moderador ya no tiene la misión de estimular y guiar la discusión sino que conduce,
establece y propone los temas a tratar en las sesiones. Los usuarios debaten ideas y
opciones de diseño según tres etapas básicas: crítica a la situación presente, fantasía en
la generación de ideas e implementación de las mismas.

Es frecuente la combinación de estas sesiones con técnicas de generación de ideas tan
conocidas como el Brainstorming y el Mental Imaging.

Entrevistas y Grupos Orientados
(Interviews and Focus Groups)

¿En qué consiste?
Las entrevistas y los Grupos Orientados nos permiten preguntar a los usuarios acerca de
sus experiencias y preferencias respecto de un producto. Ambos son eventos formales y
estructurados en los que se interactúa directamente con los usuarios, a quienes se les
solicita que expresen sus opiniones acerca del producto.

34

Se comienza formulando preguntas acerca del producto basadas en el tipo de información
que se quiere conocer. Las fuentes mostradas al final de esta página proporcionan mayor
información acerca del diseño de preguntas efectivas. Entonces, tan sólo hay que solicitar
a los usuarios que respondan estas preguntas.
En las entrevistas y los Grupos Orientados, de forma opuesta a las encuestas y los
cuestionarios, uno ha de estar presente para interactuar y facilitar la discusón acerca de
los aspectos que surjan de las preguntas realizadas. Cuando participan varios usuarios,
tal y como sucede con los Grupos Orientados, la interaccón entre los mismos dará lugar a
la consideracón de interesantes aspectos adicionales o identificará problemas comunes
experimentados por muchas personas.

Esta técnica puede ser utilizada en cualquier etapa del proceso de desarrollo,
dependiendo de las preguntas que sean formuladas. A menudo, las entrevistas y los
Grupos Orientados; son utilizados una vez que el producto ha sido lanzado con el objetivo
de mejorar la satisfacción el cliente respecto del mismo. Será más frecuente, sin embargo,
que estos métodos se pongan en práctica a etapas muy tempranas del desarrollo, cuando
los requerimientos del productos no son firmes o no están completamente definidos. Es
entonces cuando se utilizan los Grupos Orientados; para captar los requerimientos del
usuario de forma previa al diseño inicial.


Greenbaum, Thomas L.,"Focus Groups: A Help or a Waste of Time?" de los página con
los artículos de Tom en http://www.groupsplus.com/ . Hay muchos más.

Greenbaum tiene también un par de articulos sobre los Grupos Orientados por vídeo:
"Focus Group By Video - Next Trend Of The 90's" y "Is Your Moderator Ready for
Videoconferencing?" en su sitio web.

Greenbaum, Thomas L., The Handbook for Focus Group Research, 1997, Sage Pubns;
ISBN: 0761912533

Nielsen, Jakob, "The Use and Misuse of Focus Groups" Templeton, Jane F., The Focus
Group : A Strategic Guide to Organizing, Conducting and Analyzing the Focus Group
Interview, 1994, Probus Pub Co; ISBN: 1557385300

Maya Design y W3Focus hacen Grupos Orientados on-line: FAQ

Maya Design también lleva a cabo telephone focus groups (Grupos Orientados por vía
telefónica)

Silverman, George, "How to Get Beneath the Surface in Focus Groups" de los artículos de
George en http://www.mnav.com/index.html.

35

Grupos de Debate
(Group Discussion)

¿En qué consiste?

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


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

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

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

Conducir la sesión

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


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


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

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

36

Brainstorming

¿En qué consiste?

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



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

Conducir la sesión

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


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


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

Brainstorming Techniques: http://www.kanten.com/RBWV/bstechs.html

Braistorming Training http://www.brainstorming.co.uk/tutorials/tutorialcontents.html

37

APROXIMACIÓN INDIVIDUAL

Aunque presentan diferentes estructuras y procedimientos, el factor común, y el más
importante, es la formulación de preguntas efectivas. Las metodologías más habituales
son:
Las Encuestas (Surveys) son interactivas, pero ni poseen un carácter estructurado ni se
establecen ni organizan formalmente.

Por otra parte, en los Cuestionarios (Questionnaires), es característico el formato de lista
de las preguntas, así como el requerimiento de un esfuerzo adicional por parte del
usuario, quien contesta y envía de vuelta el cuestionario al evaluador. Hay algunos
cuestionarios muy conocidos.

En la Entrevistas (One-to-one Interviews) de forma similar a los Grupos Orientados, rige la
filosofía estímulo-respuesta (Stimulus & Response). De hecho, es frecuente ver unidas a
ambas técnicas en algunas recopilaciones de herramientas por este motivo.

Aunque no se deja de proponer mecanismos para desarrollar preguntas efectivas y aplicar
las técnicas de forma apropiada, las aplicaciones de estos métodos son frecuentemente
alquiladas a profesionales expertos (Proffesional Trackers). Así se habla también de
Entrevistas Expertas (Expert Interviews).

Encuestas
(Surveys)

¿En qué consiste?
Las encuestas consisten en entrevistas con los usuarios en las que se formulan un
conjunto de preguntas y se registran las respuestas. Las encuestas difieren de los
cuestionarios en el carácter interactivo de las primeras, aunque no son estructuradas de la
forma que los son las indagaciones en el contexto ni formalmente establecidas ni
organizadas como lo pueden ser los Grupos Orientados.

información acerca del diseño de preguntas efectivas. Entonces, tan sólo hay que solicitar
a los usuarios que respondan estas preguntas.

dependiendo de las preguntas formuladas en la encuesta. A menudo, las encuestas son
utilizadas una vez que el producto ha sido lanzado con el objetivo de mejorar la
satisfacción el cliente respecto del mismo. Tales encuestas identifican a menudo
determinadas cuestiones de usabilidad que deberían haber sido captadas con antelación
antes de que el producto fuera lanzado al mercado.

Alreck, Pamela L., and Settle, Robert B., The Survey Research Handbook, 1994, Irwin
Professional Publishing, Chicago, IL, ISBN: 0-256-10321-6 (ISBN is for cheaper
paperbound 1995 version)

38

Salant, Priscilla, and Dillman, Don A., How to Conduct Your Own Survey, 1994, John
Wiley & Sons, New York, NY, ISBN: 0471012734

Cuestionarios
(Questionnaires)

¿En qué consiste?
Los cuestionarios son listas escritas de preguntas que se distribuyen entre los usuarios.
Los cuestionarios difieren de las encuestas en que se tratan de listas escritas y no de
entrevistas como tales, de modo que requieren un esfuerzo adicional por parte de los
usuarios, quienes habrán de rellenarlo y enviarlo de vuelta.

información acerca del diseño de preguntas efectivas.

dependiendo de las preguntas formuladas en el cuestionario. A menudo, los cuestionarios
son utilizados una vez que el producto ha sido lanzado con el objetivo de mejorar la
satisfacción el cliente respecto del mismo. Tales cuestionarios identifican a menudo
determinados aspectos de usabilidad que deberían haber sido captados con antelación
antes de que el producto fuera lanzado al mercado.

Foddy, William, Constructing Questions for Interviews and Questionnaires: Theory and
Practice in Social Research, Cambridge Univ Pr (Pap Txt); ISBN: 0521467330.

Lessler, Judith L., Questionnaire Design in the Cognitive Research Laboratory, ISBN
0840604122.

Oppenheim, A. N., Questionnaire Design, Interviewing and Attitude Measurement, 1992,
Pinter Pub Ltd; ISBN: 1855670445

PARTICIPACIÓN REMOTA

En muchas ocasiones nos encontraremos con que el objetivo de un experimento remoto
es evaluar o testear un producto, o al menos así lo manifestará la bibliografía, pero la
distancia no debe suponer un obstáculo, por otra parte, a una primera fase de
investigación e indagación contextual.

Hay dos fuentes básicas de referencia:

• "Remote Usability Evaluation at a Glance "
• "The User-Reported Critical Incident Method at a Glance"

39

El Cuestionario o Encuesta Remota es la versión a distancia de las aproximaciones
individuales, con la misma dificultad que presenta la formulación de preguntas efectivas
pero con la ventaja que puede suponer el retorno de la información a través de la red.

También se habla de sistemas automatizados de captación y reunión de datos. Las
técnicas más habituales son las Sesiones Guiadas (Journaled Sessions) y las Fotografías
de Pantalla (Screen Snapshots) y, por lo general, están destinadas a la evaluación o test
de software. En ambos casos se proporciona un prototipo del producto a testear y un
mecanismo para el registro de datos. Un posible punto de partida en el proceso de diseño
es una nueva evaluación o test de una versión previa del producto objetivo. El paso del
tiempo trae, a menudo, y especialmente en lo que se refiere a productos con un
importante componente tecnológico, nuevas consideraciones y perspectivas que aportan
nuevos datos e impresiones.

El Registro por parte del Usuario (Self-reporting Logs) es una variante en lápiz y papel de
los procedimientos automatizados descubiertos con anterioridad que. Lógicamente,
requerirá un mayor esfuerzo por parte del usuario (otra posibilidad en este sentido es el
Método del Diario). En la misma línea, se tienen las Sesiones de Registro del Uso Real
(Logging Actual Use Sessions), una variante de las anteriores, más propia de la
bibliografía del software, automatizada, que conserva la posibilidad de realización remota
pero se plantea como interesante como trabajo de campo.

El Informe por el Usuario de Incidencias Críticas (User-Reported Critical Incident Report)
es propio de la bibliografía de la evaluación remota. Los usuarios son entrenados para
identificar incidencias críticas e informar de manera específica mientras realizan las tareas
habituales en su contexto de trabajo.

Los procedimientos mediante servicios comerciales de usabilidad (Third-Party) agrupan
los casos de la evaluación en laboratorio (Laboratory Evaluation) o inspección de
usabilidad (Usability Inspection). Posteriormente se recibe un informe del laboratorio o
consultora que llevó a cabo la investigación. También se plantea dentro de esta
posibilidad la Evaluación basada en Videoconferencia (Video-Conferencing supported
Evaluation).

Evaluación Remota
(Remote Evaluation)

Servicios comerciales de usabilidad

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

Evaluación en laboratorio por terceros

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

40

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

Inspección de usabilidad por terceros

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

Encuesta o Cuestionario Remoto

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

Evaluación basada en Videoconferencia

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

Captación de datos instrumentada o automatizada

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

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

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

41

Evaluación Remota Colaborativa

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

Sesiones Guiadas
(Journaled Sessions)

¿En qué consiste?

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

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

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


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

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

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

42

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

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

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


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


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

Clickometer es un contador shareware de "clicks" .

Invisible Key Logger cuenta las pulsaciones sobre cada tecla.

Otros productos de software que cuentan "clicks": RSI prevention software, Mercury
Interactive, Segue, Rational, etc.

Registro por el Usuario
(Self-reporting Logs)

¿En qué consiste?

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

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

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

43

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



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


en un predesarrollo, cuando la información que se pretende obtener es más preferencial
que empírica.





Método del Diario
(Diary Keeping)

¿En qué consiste?

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

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


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

44

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

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


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


Proyecto RESPECT

GENERACIÓN DE IDEAS

La generación de ideas es también una forma de descubrir, aprender y refinar
determinados conceptos de diseño. La participación de los usuarios en estos
procedimientos contribuye a ampliar perspectivas y a profundizar en una variedad de
consideraciones que, en ocasiones, pasan inadvertidas para el diseñador. Ya se ha
mencionado la combinación del Brainstorming y el Mental Imaging con los Grupos
Orientados. Se presentan varias posibilidades:

Generación de estímulos e impresiones mediante escenarios
• Secuencias de Escenarios (Storyboarding/Presentation Scenarios)
• Creación de Escenarios (Scenario Building)

Distintas formas de análisis cognitivos
• Cuadros de Organización de Tareas (Task Allocation Charts)
• Análisis de Tareas (Task Analysis)
• Matriz de Funcionalidad (Functionality Matrix)

Perspectivas de carácter etnográfico
• Análisis de Usabilidad del Contexto (Usability Context Analysis)
• Test No Directivo: test de diferentes prototipos por diferentes grupos de usuarios
con el objetivo de obtener fuentes no influenciadas.
• Test de Preferencias: sobre una variedad de prototipos del mismo producto, el
usuario muestra sus preferencias, bien sobre algún partes de los mismos

45

Secuencia de Escenarios
(Storyboarding)

¿En qué consiste?

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

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


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

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

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

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


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

46


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

Construcción de Escenarios
(Scenario Building)

¿En qué consiste?

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



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

Conducir la sesión

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


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


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

47

Asignación de Tareas
(Task Allocation)

¿En qué consiste?

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


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

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

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


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


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

Análisis de Tareas
(Task Analysis)

¿En qué consiste?

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

48

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

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

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

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


El proceso se divide aquí en dos partes:

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

Descomposición de tareas

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

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

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

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

49

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

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

Diagramas de flujo de tareas

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


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


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

Matriz de Funcionalidad
(Functionality Matrix)

¿En qué consiste?

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


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

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

50

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


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


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

Métodos de Observación Experta

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

Algunas técnicas novedosas

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

51

Expertos en captación de datos

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

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

Información del Consumidor Actual

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

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

Sesiones Guiadas
(Journaled Sessions)

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

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

52

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

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

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



en un pre-desarrollo, cuando la información que se pretende obtener es más preferencial
que empírica.


Clickometer es un contador shareware de "clicks" .

Invisible Key Logger cuenta las pulsaciones sobre cada tecla.

Otros productos de software que cuentan "clicks": RSI prevention software, Mercury
Interactive, Segue, Rational, etc.

Registro por el Usuario
(Self-reporting Logs)

¿En qué consiste?
Los Registros por el Usuario consisten en sesiones de lápiz y papel en las que se solicita
de los usuarios que registren sus acciones y observaciones mientras están interactuando
con un determinado producto. Al igual que en las Sesiones Guiadas, se podrá llevar a

53

cabo una evaluación de usuario a distancia. Sin embargo, esta técnica requiere mucho
más trabajo por parte de los sujetos participantes.

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

Así pues, los Registros por el Usuario se utilizan con preferencia cuando no hay tiempo o
recursos para proporcionar el paquete interactivo requerido para las Sesiones Guiadas, o
cuando no se requiere el nivel de detalle asociado a estas. Podría buscarse, simplemente,
impresiones generales y observaciones de un conjunto amplio de usuarios.


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

en un predesarrollo, cuando la información que se pretende obtener es más preferencial
que empírica.




Inspección
(Inspection)

El proceso de diseño tiene, necesariamente, carácter iterativo y su planificación ha de
contemplar tal circunstancia. A pesar de que los métodos que se están mostrando son
específicamente recomendados para una etapa concreta de dicho proceso se puede
comprobar que su flexibilidad admite su utilización en prácticamente cualquier momento.
Así, los métodos de inspección pueden parecer pensados como una revisión del producto
próximo a sus etapas finales de fabricación, pero se trata más de una madurez conceptual
que física. De esta forma, indagación, inspección y test se presentan casi como procesos
concurrentes con una introducción en el proceso productivo muy compleja, que nos
llevaría a establecer, incluso, una escala de madurez respecto de la usabilidad y el diseño

54

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

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

¿En qué consiste?
El test de usabilidad desarrolla experimentos para obtener información específica acerca
de un diseño. Los test tienen su raíz en la psicología experimental, lo que viene a
significar la confianza en el tratamiento estadístico de los datos. Hoy, con más interés en
la interpretación de los resultados que en las cifras a las que conducen los datos, se da
menos importancia a los números y más o otras cuestiones que surgen o se descubren en
el test. Por ejemplo, en la actualidad, muchos tests hacen uso del protocolo del
pensamiento manifestado en conjunción con alguna forma de realización de medidas.
Mientras la realización de medidas es todavía de utilidad, la información obtenida de las
manifestaciones en voz alta se abre camino hacia el producto más rápidamente, sin ser
precisa su consideración o análisis de forma previa a cualquier actuación sobre el mismo.

El proceso global es simple; hay que conseguir un cierto número de usuarios y descubrir
cómo trabajan con el producto objeto del test. Normalmente se va a observar a usuarios
operando de forma individual con el producto y se recogen datos acerca de cómo lo
hacen (por ejemplo, cuánto tardan en realizar las tareas, cuantos errores cometen).
Entonces se analizan los errores detectados en todos los experimentos de forma conjunta
para detectar tendencias. Esta sección, basada en el libro de Rubin "Handbook of
Usability Testing", entra en estas fases con mayor detalle:

Determinar qué es lo que se está buscando
¿Qué se quiere conocer del producto?
Se comienza estableciendo un propósito global para la investigación; podría querer
determinarse, por ejemplo, el motivo por el que se han disparado las llamadas al servicio
técnico después de la última salida al mercado o si, tras haber perdido parte de la cuota
del mercado, los productos de la competencia se venden mejor porque son más usables.

Manifestar este propósito en unos pocos objetivos para el test
No es un objetivo apropiado plantearse la medida en la que el producto es usable. El
objetivo es algo para lo que se pueda desarrollar un test. Por ejemplo, ¿es el retraso en la
carga de la aplicación Java lo que lleva a los usuarios a abandonar la página?, ¿cuánto le
cuesta a alguien sin conocimientos previos hacer su declaración de la renta con este
software?, ¿proporciona suficiente información el sistema de ayuda en línea?, ¿es fácil de
entender esa información o se basa en jerga burocrática?

Diseñar el test
Identificar a los usuarios a participar
Es fundamental determinar el tipo de usuario que va a participar: hombres, mujeres o
ambos, expertos en el uso del producto o novatos, jóvenes o ancianos... ¿Quiénes son los
usuarios objetivo para nuestro producto?. Si lo que se pretende es realizar un test sobre
los mandos de un avión de combate, no interesará una horda de escolares corriendo
entre nuestros escenarios de test; de la misma forma, si se somete a test una máquina de
refrescos incluiremos a los escolares en la población de usuarios, además de a los pilotos

55

de combate. El perfil de usuario del producto es fundamental a la hora de desarrollar el
diseño del test y elegir a la muestra de sujetos.

Determinación del diseño experimental
El diseño experimental hace referencia a la forma en que se ordenarán y conducirán los
experimentos para eliminar las variables carentes de interés de nuestro análisis. Por
ejemplo, supongamos que estamos comprobando un software para el cálculo de
impuestos. ¿Buscaremos usuarios que hayan hecho la declaración de la renta mediante
este software y ya tengan un cierto conocimiento del producto?. Podría resultar
interesante dirigir dos grupos, uno que agrupara a los novatos y otro que agrupara a
usuarios con un cierto nivel de experiencia.

Desarrollar las tareas que los usuarios llevarán a cabo durante cada experimento
Lógicamente, estas deberían derivarse de las que los usuarios normalmente realizan
cuando están haciendo uso del producto. Hay que especificar qué es lo que se necesita
para establecer el escenario: los estados de la máquina o del sistema en cuestión,
pantallas, documentación y cualquier otro tipo de ayudas en el trabajo que deban estar
presentes. Igualmente hay que determinar qué es lo que se va a entender por tarea
completada (esto es, si el usuario guarda con éxito el documento editado, o completa una
determinada operación de manufactura)

Especificar la aparamenta del test
En la experimentación científica tradicional, por ejemplo, en la investigación química o
biológica, de las que derivan últimamente las metodologías de test de usabilidad, la
aparamenta de test haría referencia al típico material de laboratorio, como los mecheros
Bunsen, las probetas y pipetas y demás dispositivos utilizados en el transcurso de un
experimento. En el caso del test de usabilidad, se tratará del ordenador y del software, o
de la maqueta de un puesto de trabajo de manufactura, o del prototipo del cuadro de
mandos de un coche.

La aparamenta de test también incluye otros dispositivos presentes en el desarrollo del
test, como las cámaras de vídeo para registrar las acciones del usuario, los dispositivos
para registrar las acciones en la pantalla, grabadoras de audio para registrar comentarios,
preguntas formuladas y respuestas, espejos unidireccionales, que mantendrán al
experimentador fuera de la línea de acción del sujeto, y demás. Habitualmente se le da
mucha importancia a estas cuestiones pero no tiene porqué ser así. Tanto si se utiliza un
simple cámara portátil como si no existe en absoluto registro en vídeo, es posible obtener
una gran cantidad de información de gran utilidad.

Identificar al personal requerido
Será preciso como mínimo un experimentador para conducir el test, desde dar la
bienvenida al usuario hasta explicarle la secuencia de test y trabajar con el mismo durante
cada tarea. Podría resultar conveniente la presencia de uno o dos observadores que
contribuyeran a reducir la carga de trabajo del experimentador encargándose de parte del
registro de datos.

Disponer de algunos usuarios
Establecer una lista de usuarios de la que se obtendrá una muestra poblacional de sujetos
de test.

56

Se ha escrito tanto sobre la elección de sujetos de test que resultaría muy difícil entrar a
considerar todos los aspectos, pero vamos a proporcionar algunas indicaciones. Se va a
precisar del suficiente número de sujetos para completar la muestra de la población en
tanto que ha de contemplar una variedad de capacidades, experiencias y características
demográficas y teniendo en cuenta que otros factores pueden perjudicar el diseño
experimental e influir en los datos. El perfil de usuario determinado durante el diseño
experimental ayudará a determinar al tipo de usuario de nuestro producto. Por ejemplo,
los mandos de un avión de combate podrían ser utilizados no sólo por los propios pilotos
sino también por el equipo de mantenimiento, los instaladores, el equipo de diagnóstico y
los instructores. Sin embargo, para el propósito de lo que se pretende descubrir (¿Permite
al usuario el sistema de detección de tráfico aéreo evitar una colisión durante el vuelo
invertido?), el interés prevalecerá sobre un único segmento de la población de usuarios,
los pilotos.

Incluso si se ha reducido la población de usuarios a un único perfil (por ejemplo, piloto de
combate, hombre o mujer, con una visión 20/20 y edades entre los 22 y los 35 años, con,
al menos, un nivel de diplomatura o equivalente), aún será preciso recabar más
información. ¿Qué experiencia tiene cada usuario con este mando? ¿Están
acostumbrados a los antiguos accionamientos mecánicos o prefieren dispositivos
digitalizados de alta tecnología? ¿Alguno tiene ceguera de color? ¿Cuál de sus ojos es el
dominante?. Y así se podría seguir y seguir, pero cuanto más conocimiento se tenga
acerca de los usuarios de test, menor será la posibilidad de que algún factor extraño nos
sorprenda de entre los datos experimentales.

¿Y cómo se encuentra a estos usuarios?. Por cualquier medio disponible, como puedan
ser empleados y familiares de los mismos, agencias de trabajo temporal, empresas
analistas de mercado. Indudablemente esto supone un gasto pero se consigue un
importante ahorro en tiempo a la hora de establecer categorías y analizar características.
También se puede acudir a los registro de los servicios técnicos y de los equipos de
ventas, asociaciones de consumidores y organizaciones industriales. Dependiendo del
tipo de población que se requiera se puede solicitar la ayuda de asociaciones de
jubilados, que van a disponer de más tiempo libre, u ofrecer visitas escolares a los
colegios, por ejemplo. Indudablemente, surgirán problemas al buscar una población entre
pilotos de combate, como en el ejemplo utilizado anteriormente, o ejecutivos de alto nivel,
si se pretendiera testear un sistema de información ejecutiva (Executive Information
System, EIS), por ejemplo.

Establecer el test
Preparar la aparamenta del test
La aparamenta requerida para un test de usabilidad incluye el ordenador y el software
para un test de software, o una máquina o una maqueta para un test de hardware.
Algunos test se desarrollan con prototipos; en tal caso, es preciso asegurarse de que los
estados a los que se haya de acceder en cada escenario de tareas se encuentren
disponibles en el prototipo. Del mismo modo, habrá de considerarse el material que haya
que proporcionar al sujeto del test y al experimentador durante el transcurso del mismo. El
sujeto contará con una lista de las tareas a realizar. Los pasos a través de los cuales se
realizará la tarea se omitirán intencionalmente si lo que se pretende es descubrir la
accesibilidad de ciertas secuencias de comandos. El experimentador dispondrá
habitualmente de un esquema básico que reflejará el modo en el que presentará las
tareas al sujeto usuario, así como un formulario para registrar observaciones durante el

57

test. En ocasiones, se puede acordar el uso de un cuaderno de taquigrafía, que resulta útil
cuando se pretende captar absolutamente todo lo que está sucediendo.

Preparar la muestra del test
La muestra del test es el conjunto de sujetos a los que se conducirá a través del test.
¿Cuántos se necesitan?. La mayoría de las recomendaciones indican que al menos
cuatro o cinco participantes son precisos para encontrar la mayoría de los problemas de
usabilidad. La muestra se habrá de escoger en base a los objetivos y los perfiles de
usuario, así como en la disponibilidad en las fechas de realización del test.

Conducir el test
Preparar a los sujetos para el test

Dado que la mayoría de las personas se sienten incómodas cuando se les mete en un
laboratorio y se les solicita que realicen una serie de tareas, mientras están siendo
cronometrados y sus errores están siendo registrados para ser analizados, es
fundamental ponerle las cosas fáciles al sujeto de test. Hay que explicarle que puede
detener el test en cualquier momento, que puede salir al baño, o realizar un descanso si
es preciso. Hay que recalcar que lo que se está testeando es el producto y, en ningún
caso, el usuario, que no ha de sentirse presionado en ningún sentido por el test. Y, por
supuesto, hay que agradecer al usuario su participación. En la mayoría de los tests se
firman, con antelación al mismo, acuerdos acerca del respeto de la confidencialidad de las
partes, así como los medios consentidos para el registro de los datos. Como parte de este
papeleo previo, se puede solicitar del participante la cumplimentación de un cuestionario
para identificar sus áreas de conocimiento o su actitud o simplemente para tener más
información acerca de las características del mismo.

Conducir al sujeto a través de las tareas y reunir los datos
Un test típico consiste en un individuo ante una estación de trabajo realizando tareas
escritas mientas un experimentador observa al usuario y le formula preguntas o
proporciona indicaciones si es necesario.

Los test que buscan datos preferenciales o conceptuales (a través del pensamiento
manifestado, por ejemplo) pueden dar lugar a una extensa interacción entre
experimentador y sujeto. Los tests en los que se tratan de descubrir datos empíricos,
como tasas de error, exigen, por otra parte, la reducción a la mínima expresión de tal
interacción.

Hay que permitir trabajar al sujeto a través de las tareas sin demasiadas interferencias.
Resultará difícil verlo esforzarse en momentos complicados, pero es preferible aprender
de su esfuerzo en el laboratorio antes de que sufra esa situación tras haber pagado por el
producto y habérselo llevado a casa. Desde luego, si el sujeto llegara a las lágrimas o
pretendiera marcharse del laboratorio (lo que, efectivamente, puede ocurrir),
correspondería solucionar de forma inmediata el problema o, simplemente, dar paso a
otra tarea.

Incluso si no se está haciendo uso del protocolo del pensamiento manifiesto, podría
resultar de interés formular al sujeto ciertas preguntas durante el test si se considera de
mayor interés descubrir el motivo por el que el usuario hizo algo de una forma
determinada.

58

Hacer dar parte al usuario
Discutir el test con el usuario

Una vez que se han completado las tareas, y el test ha finalizado, se pasa a charlar con el
usuario acerca del mismo. Conviene volver sobre los sucesos que pudieron tener lugar
durante el test para reunir más información a partir de lo que el usuario estaba pensando
en ese momento. Una forma de revisar estos momentos es volviendo a los mismos y
discutirlos con el sujeto, o, simplemente, preguntarle qué momentos del test considera
más notables.

Hay que agradecer al usuario su participación. No se puede olvidar que nos están
haciendo un gran favor, y es fundamental mostrarles nuestro aprecio. La mayoría de los
laboratorios realizan algún regalo después del test. Además, manteniendo al usuario
contento, se mantiene la posibilidad de su colaboración en experimentos futuros.

Analizar los datos
Encontrar primero los problemas más graves
La identificación de los problemas más graves es la más sencilla en tanto que estos se
van a evidenciar de las notas tomadas durante la sesión. Si cada usuario tuvo algún
problema con el mismo elemento de un menú, evidentemente dicho elemento requerirá un
revisión.

Resumir los datos de realización recopilados
Los datos de realización, como tasas de error y duraciones de las tareas, se evalúan
mediante un análisis estadístico sobre el conjunto de los datos. La mayoría de los análisis
consisten en el cálculo de una media y una desviación estándar así como de una
comprobación de los datos para su validez. ¿Se advierte alguna tendencia de los datos?
¿Son más complejas determinadas partes del producto?

Resumir los datos sobre preferencias recopilados
Mediante la observación de las acciones de los usuarios, registrando sus opiniones,
durante el test, formulando preguntas o registrando sus manifestaciones y antes o
después del mismo, mediante el uso de cuestionarios, surgen una enorme cantidad de
datos preferenciales. La mayoría de los diseños de los cuestionarios permiten cuantificar
opiniones mediante el uso de escalas numéricas, y los datos cuantitativos encontrados
pueden ser analizados mediante análisis estadístico.

El test de usabilidad se utiliza a través del ciclo de vida del desarrollo del producto. En las
etapas tempranas del proceso de desarrollo, el test de una versión previa o del producto
de un competidor proporciona referencias muy útiles al equipo de diseño. En las etapas
medias, el test valida el diseño e informa sobre las posibilidades de refinamiento del
mismo. En etapas posteriores, el test asegura que el producto alcanza ls objetivos del
diseño.

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

Lindgaard, G., Usability Testing and System Evaluation: A Guide for Designing Useful

59

Computer Systems, 1994, Chapman and Hall, London, U.K. ISBN 0-412-46100-5

Rubin, Jeffrey, Handbook of Usability Testing, 1994, John Wiley and Sons, New York, NY
ISBN 0-471-59403-2 (papel)
Información adicional
Bell, Brigham, Rieman, John, and Lewis, Clayton. "Usability Testing of a Graphical
Programming System: Things We Missed in a Programming Walkthrough.''
Communications of the ACM volume/number unknown (1991): 7-12

Chartier, Donald A. "Usability Labs: The Trojan Technology.''

Cline, June A., Omanson, Richard C., and Marcotte, Donald A. "ThinkLink: An Evaluation
of a Multimedia Interactive Learning Project.''

Haigh, Ruth, and Rogers, Andrew. "Usability Solutions for a Personal Alarm Device.''
Ergonomics In Design (July 1994): 12-21

Heller, Hagan, and Ruberg, Alan. "Usability Studies on a Tight Budget.'' Design+Software:
Newsletter of the ASD (1994)

Jordan, Patrick W., Thomas, Bruce, Weerdmeester, Bernard, (Eds.), Usability Evaluation
in Industry, 1996, Taylor & Francis, Inc., London, UK. ISBN: 0-74-840460-0

Lund, Arnold M. "Ameritech's Usability Laboratory: From Prototype to Final Design.''

Whiteside, John, Bennett, John, and Holtzblatt, Karen. "Usability Engineering: Our
Experience and Evolution'' from Handbook of Human-Computer Interaction, M. Helander
(ed.). Elsevier Science Publishers B.V. (North Holland), 1988: 791-804.

Wiklund, Michael E., Usability in Practice, 1994, AP Professional, Cambridge, MA ISBN 0-
12-751250-0

Yuschick, Matt, Schwab, Eileen, and Griffith, Laura. "ACNA--The Ameritech Customer
Name and Address Service.''

Técnicas y aspectos del test de usabilidad
Bailey, R. W., et. al. "Usability Testing versus Heuristic Evaluation: A Head-to-Head
Comparison.'' Proceedings of the Human Factors Society 36th Annual Meeting, (1992):
409-413. Dayton, Tom, et. al. "Skills Needed By User-Centered Design Practitioners in
Real Software Development Enironments: Report on the CHI `92 Workshop.'' SIGCHI
Bulletin v25 n3, (July 1993): 16-31.

Jeffries, R., et. al., "User Interface Evaluation in the Real World: A Comparison of Four
Techniques.'' Reaching through Technology: Proceedings of the 1991 CHI Conference,
New Orleans, April-May 1991, NY: Association for Computing Machinery (ACM), 119-124.
Virzi, Robert A. "Refining the Test Phase of Usability Evaluation: How Many Subjects is
Enough?'' Human Factors, v34, n4 (1992): 457-468.

60

Métodos de Test

Se puede conseguir una aproximación apropiada a las necesidades del usuario, se
pueden contemplar la existencia de múltiples contextos de trabajo, se puede, también,
hacer del usuario parte del proceso de diseño en una fase de evaluación o inspección,
pero ¿existe algún método para detectar el origen de los problemas de usabilidad?, ¿es
posible plantear un experimento con un objetivo particular (y no la medida en que un
determinado producto sea usable)?.

El test de usabilidad va a desarrollar experimentos para obtener información específica
acerca de un diseño. Así, antes de pasar a las técnicas, conviene hacer primero un
recorrido por los Conceptos Generales acerca del Test de Usabilidad.
• Protocolos de Expresión del Usuario
• Realización de medidas
• Variantes del Test de Usabilidad clásico

Protocolos de Expresión del Usuario
En la mayoría de las técnicas de Test aplicadas se va a contemplar la captación de las
impresiones y sensaciones que el usuario manifiesta oralmente, diciéndose entonces que
se están aplicando Protocolos de Expresión de Usuario, donde se distinguen:

• Protocolo del Pensamiento Manifestado (Thinking Aloud Protocol). Durante el
transcurso del test, donde el participante está realizando una tarea como parte de un
escenario de usuario, se solicita de este que exprese en voz alta sus pensamientos,
sensaciones y opiniones mientras interactúa con el producto.
•
• Protocolo de Preguntas (Question-Asking Protocol). Este método lleva un paso
más allá al protocolo del pensamiento manifestado al provocar las manifestaciones del
usuario respecto del producto mediante la formulación de preguntas directas acerca del
mismo.

Realización de Medidas
Los objetivos de test han de ser, además de testeables (¡un error frecuente es que esto
no sea así!) cuantificables y pronto se revela como importante la Realización de medidas
(Performance Measurement), aunque esta técnica decae en los últimos tiempos con su
aplicación a productos hardware, cobrando importancia los modos de uso (y los contextos
en que suceden). La importancia de los datos, junto con el modo en que los usuarios
interaccionan con el prototipo, es una de las cuestiones más estudiadas, objeto de
discusiones y amplios estudios.

Variantes del Test de Usabilidad clásico

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

• Método de Seguimiento (Shadowing Method).

61

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

PROTOTIPADO Y CATEGORIZACIÓN

La aplicación de la técnica de prototipado va a ser fundamental en el desarrollo e
implementación de los métodos para la inspección y test de un producto, dado que,
habitualmente, no será el producto final lo que se someta a los diversos experimentos,
sino un prototipo del mismo con unas determinadas características, en virtud de las cuales
se enfocarán los métodos en una dirección concreta. En definitiva, se trata de una
cuestión indispensable, presente incluso en ciertos métodos contextuales (¡la versión
previa de un producto puede constituir una forma de prototipo para la nueva generación!).
Por otra parte, los métodos de categorización que se citan, y después su conexión con el
amplio y complejo mundo de la Calidad, tan sólo recuerdan la necesidad de una
planificación meticulosa que nos ha obligado a hablar muchas veces de etapas de
prediseño. Más concretamente, la Categorización por Tarjetas, sugerirá casi de inmediato
al lector cómo establecer el contenido de los menús de una aplicación informática.

• Prototipado
• Según la funcionalidad reproducida
• Según la fidelidad de la reproducción de la interfaz
• Otras técnicas de prototipado
• Prototipado Rápido
• Prototipado por Vídeo
• Métodos de Categorización

Prototipado

El prototipado modela el producto final y permite efectuar un test sobre determinados
atributos del mismo sin necesidad de que está disponible. Se trata, simplemente, de
testear haciendo uso del modelo. De acuerdo con las características del prototipo en
cuanto a interfaz, funcionalidad, posibilidades de ampliación,... tenemos variadas
posibilidades. En muchas ocasiones se dirá que Cuanto más próximo se encuentre el
prototipo al producto real, mejor será la evaluación, pero veremos que esto no tiene por
qué ser así.

62

Según la funcionalidad reproducida

Podemos distinguir dos tipos:

• Prototipado Horizontal (Horizontal Prototyping): los prototipos horizontales exhiben
un amplio espectro de las características del producto, pero sin el respaldo de una
funcionalidad relativamente amplia.

• Prototipado Vertical (Vertical Prototyping): los prototipos verticales muestran la
funcionalidad exacta de un producto para una pequeña parte del conjunto completo. Por
ejemplo, un prototipo vertical de un procesador de textos podría mostrar todas las
funciones de comprobación de ortografía y gramática, pero ninguna función relacionada
con la entrada de texto o su formato.

Prototipado Horizontal
(Horizontal prototyping)

¿En qué consiste?

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


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.



63

Prototipado Vertical
(Vertical Prototyping)

¿En qué consiste?

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


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


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.



Según la fidelidad de la reproducción de la interfaz

Podemos distinguir dos tipos:

• Prototipado de Alta Fidelidad (High-Fidelity Prototyping): el prototipo será
prácticamente idéntico al producto final.

• Prototipado de Baja Fidelidad (Low-Fidelity Prototyping): el aspecto del prototipo
no se corresponderá con el del producto final, si bien reproducirá la disposición de sus
características, dimensiones y otros aspectos (de hecho, se trata de prototipos
horizontales, habitualmente). Frecuentemente se hablará de Prototipado de Papel (Paper
prototyping) como uno de los mecanismos más económicos, en tiempo y dinero, para
desarrollar prototipos. Ha sido una herramienta tradicionalmente destinada a software,

64

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

Prototipado de Alta Fidelidad
(High-Fidelity prototyping)

¿En qué consiste?

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


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

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

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


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.



65

ISBN 0-471-59403-2 (papel

Prototipado de Baja Fidelidad
(Low-Fidelity prototyping)

¿En qué consiste?

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

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


Preparando el prototipo

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

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

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

El prototipado de baja fidelidad en acción

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

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

66

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


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.



Nielsen, Jakob, "Paper versus Computer Implementations as Mockup Scenarios for
Heuristic Evaluation'', Human-Computer Interaction-Interact `90, D. Diaper et. al. (ed.)
Elsevier Science Publishers B.V. (North Holland), 1990: 315-320

Rettig, Marc, "Prototyping for Tiny Fingers (Everything I Need to Know About Prototyping,
I Learned In Kindergarten)'', Communications of the ACM, April 1994.

ISBN 0-471-59403-2 (papel)

Snyder, Carolyn, "Using Paper Prototypes to Manage Risk," October 1996, Software
Design and Publisher Magazine

Virzi, Robert A, Sokolov, Jeff, and Karis, Demetrios. "Usability Problem Identification Using
Both Low- and High-Fidelity Prototypes,'' 1995: Obtenido directamente de los autores.

Prototipado de Papel
(Paper Prototyping)

¿En qué consiste?

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


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

67

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

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

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

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


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


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

En cuanto al prototipado en papel de sitios Web, son una interesante fuente de
información los artículos de Jakob Nielsen.

Otras técnicas de prototipado

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

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

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

68

requiere más medios) y la participación del usuario se relega al test del prototipo. Dos
casos particulares son:
• RAD (Rapid Application Development o Desarrollo Rápido de Aplicaciones)
• JAD (Joint Application Development o Desarrollo Conjunto de Aplicaciones)

Prototipado por Vídeo

Como se verá, el nombre de la técnica no debe inducir a confusión (¡nada que ver con la
etnografía!): el prototipo consiste en una simulación por vídeo de la funcionalidad de una
interfaz. Ver más información.

Métodos de Categorización

Hay dos métodos característicos
• Categorización por Tarjetas (Card Sorting). Se trata de un método de
categorización donde los usuarios clasifican tarjetas, en las que se representan varios
conceptos, en diversas categorías.
• Diagramas de Afinidad (Affinity Diagram). Es un método de categorización en el
que los usuarios clasifican varios conceptos, que escriben en notas Post It, en diversas
categorías. Este método suele ser utilizado por un equipo para organizar una gran
cantidad de datos, organizando las notas en grupos basándose en las relaciones y
asociaciones que establecen entre los distintos conceptos.
Estos dos métodos provienen realmente del mundo de la calidad. Así, conviene echar un
vistazo a:
• Las Siete Herramientas para el Control de la Calidad (The Seven Quality Control
Tools )
• Las Siete Herramientas para la Planifición y la Dirección (The Seven Management
and Planning Tools)

Pensar en términos de calidad nos lleva a considerar otro método de activa participación
del usuario: el Despliegue de la Función de Calidad (QFD: Quality Function Deployment).
El objetivo que se plantea este método es conseguir un producto con las propiedades
deseadas por el cliente o usuario, en lugar de tratar de asignarle todas las
tecnológicamente posibles. Son esas expectativas del cliente las que drigen el proceso de
desarrollo, dándose aquí uno de los casos de participación más destacados. En la red hay
una gran cantidad de información al respecto (se obtienen más de 4000 salidas con el
buscador Google), pero con el propósito de adentrarse de lleno en el mundo de la calidad
y entender la amplitud de conceptos que contempla, se recomienda el "Manual de Gestión
e Ingeniería de la Calidad" de Tilo Pfeifer y Fernando Torres (Mira Editores).

Métodos de Inspección

Se van a establecer cinco aproximaciones básicas:
• Inspecciones
• Evaluación Heurística
• Paseos Cognitivos
• Listas de Comprobación
• Otras perspectivas

69

Inspecciones
Vamos a que ver que tenemos varios tipos de técnicas que podemos catalogar como
Inspecciones. Sin embargo, son las denominadas Inspecciones Formales de Usabilidad
las que, procediendo de la metodología de las Inspecciones de Código, se llevan a la
práctica con más frecuencia y contemplan con mayor amplitud los conceptos que
manejamos.
• Inspecciones Formales de Usabilidad (Formal Usability Inspections). Los
inspectores van a recorren meticulosamente las tareas con los propósitos y objetivos de
los usuarios en mente, de forma similar a los paseos cognitivos , si bien el énfasis radica
menos en la teoría cognitiva y más en el hallazgo de errores. Las heurísticas van a ser
utilizadas como una ayuda para los no profesionales de la usabilidad en la búsqueda de
defectos.
• Inspecciones de Características (Feature Inspections). La inspección de
características analiza únicamente un conjunto de características determinadas del
producto, proporcionándose escenarios de usuario para el resultado final a obtener del
uso del producto. Así, se trabajará frecuentemente con prototipos verticales.
• Inspecciones de Consistencia (Consistency Inspections). El objetivo de las
inspecciones de consistencia es asegurar la misma a través de múltiples productos
procedentes del mismo esfuerzo de desarrollo, como pueda ser una suite de ofimática o
un sitio web.
• Inspecciones de Estándares (Standard Inspections). Las inspecciones de
estándares garantizan el ajuste a los estándares industriales. No hay que olvidar que
productos diseñados para ser comercializados en un país en particular deben poseer la
conformidad con los estándares de ergonomía del país en cuestión.

Evaluación Heurística
La Evaluación Heurística es una variante de la Inspección de Usabilidad donde los
especialistas en usabilidad juzgan si cada elemento de la interfaz de usuario sigue los
principios de usabilidad establecidos. La Evaluación Heurística puede ser utilizada en,
prácticamente, cualquier momento del ciclo de desarrollo, aunque probablemente se
adapta mejor en etapas tempranas, cuando no hay material lo suficientemente firme para
efectuar un test. No requiere, pues, gran despliegue de medios y puede ser llevado a
cabo por personal no especializado e incluso por usuarios tipo. Ya son un clásico en la
materia las heurísticas de Jakob Nielsen.

Paseos Cognitivos (Walkthroughs)
Los Paseos Cognitivos derivan de los análisis cognitivos y reciben este nombre porque el
especialista que realiza la sesión recorre un escenario de tareas determinado como
habría de hacerlo un usuario tipo. Según se plantee la sesión de forma individual o en
grupo (usuarios, desarrolladores y profesionales de la usabilidad):
• Paseo Cognitivo (Cognitive Walkthrough).
• Paseo Cognitivo Conjunto (Pluralistic Walkthrough)

Listas de Comprobación
Las técnicas más características son:
• Guías de Comprobación (Guidelines Checklist). Las guías y las listas de
comprobación ayudan a asegurar que los principios de usabilidad sean considerados en

70

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

OTRAS PERSPECTIVAS
Una perspectiva más participativa se plantea con la Evaluación Cooperativa (Co-operative
Evaluation), siendo la participación del usuario más manifiesta, ya sea como usuario
experto, usuario convencional o usuario LCU (Least Competent User o Usuario menos
Competente). De nuevo, estamos hablando aquí de "evaluación" pero la técnica tiene ya
connotaciones de test.
Dentro de los métodos de inspección, otros que presentan, también, una orientación al
Test
• Métodos de Diario (Diary methods). Se requiere de los usuarios que registren las
actividades que desarrollan en su entorno de trabajo durante un día normal. El registro
puede tener o no carácter estructurado.
• Modelado por Empatía (Empathic Modelling). Se trata de un método desarrollado
para aplicar con usuarios con discapacidades, de modo que el dseñador/desarrollador
trata de ponerse en la situación del usuario simulando tal discapacidad. Tal circunstancia
es muy compleja, requiriendo amplios estudios e investigaciones.

Evaluación de Usabilidad Formativa
Índice
• Definición
• Cuestiones a las que puede dar respuesta la evaluación formativa
• Beneficios de la evaluación formativa
• PASO 1. DISEÑO DE LA EVALUACIÓN.
• PASO 2. DESARROLLO DE UN PROTOCOLO PARA LAS SESIONES DE TEST.
• PASO 3. EFECTUAR UN TEST PILOTO DE LOS PROTOCOLOS DE LA SESIÓN.
• PASO 4. CONDUCIR LAS SESIONES DE EVALUACIÓN REALES.
• PASO 5. INTERPRETAR LOS DATOS REUNIDOS.
• PASO 6. PREPARAR UN INFORME.

Definición
Se trata de la evaluación de un interfaz de usuario sin terminar, varias veces realizada
durante cada ciclo, que tiene como objetivo averiguar los problemas de usabilidad que
existen en la iteración actual.

Cuestiones a las que puede dar respuesta la evaluación formativa
• ¿Hay partes de la interfaz propensas a los errores?
• ¿Precisan algunas tareas más tiempo del esperado?
• ¿Encuentran los usuarios algunas tareas especialmente difíciles?
• ¿Viola la interfaz las guías comunes de la usabilidad?

71

• ¿Hay suficiente ayuda disponible?
• ¿Qué cambios les gustaría ver a los usuarios?
• ¿Qué quejas tienen los usuarios?
• ¿Qué errores cometen los usuarios?
• ¿Dónde es más probable que los usuarios se queden bloqueados
• ¿Necesitarán los usuarios algún tipo de asistencia que les guíe en el desarrollo de
las tareas más complejas?

Beneficios de la evaluación formativa
• Debe realizarse en las etapas tempranas del proceso de diseño, cuando se han
empleado aproximadamente un 10% de los recursos del proyecto disponibles.
• Proporciona las primeras medidas sólidas de la realización de tareas
• Facilita a los diseñadores ponerse en el lugar de las personas que hacen uso del
sistema en el mundo real
• Ayuda a decidir a los diseñadores el paso a la siguiente fase del proceso
• Puede incrementar el interés del usuario y una aceptación eventual del producto
final
• Puede descubrir problemas que no se advirtieron durante el prototipado iterativo

PASO 1. DISEÑO DE LA EVALUACIÓN.

Establecimiento de metas
• Diagnóstico: determinar si existen problemas de usabilidad
• Verificación: determinar si el diseño se ajusta a las referencias establecidas y
satisface los requerimientos de usabilidad especificados
• Validación: determinar si el diseño será usable en la práctica por los usuarios

Identificar las entradas y salidas deseadas
1. Posibles entradas (inputs)
• prototipo de la interfaz
• lista de preguntas, si se plantea una entrevista estructurada
• lista de comprobación, si se va a realizar una evaluación heurística
• Referencias para los requerimientos de usabilidad
• Instrucciones y directrices para el test derivados de los escenarios de tareas
2. Posibles salidas (outputs)
• Informes de test individuales
• Datos adicionales, agregados o tabulados, del conjunto de los informes de test
• Análisis de los problemas encontrados
• Lista de peticiones de cambios según prioridad

Elegir una estrategia de evaluación, que puede ser una o más de las siguientes:
1. Reunión y análisis estadístico de los datos de forma automatizada mediante software
apropiado
2. Revisión por personal especializado
3. Evaluación Heurística basada en guías de comprobación apropiadas
4. Encuesta de usuarios
• Cuestionario de preferencias de usuario
• Entrevista estructurada
• Focus Groups
5. Test basado en Escenarios
• Entradas

72

o Instrucciones orales o escritas para el participante, paso a paso, subtarea a
subtarea
o Instrucciones escritas para el evaluador, paso a paso, subtarea a subtarea
• Salidas
o El participante tiene que completar tareas con una serie de parámetros
como referencia o participa según un protocolo de expresión
o Registro de los errores cometidos
o Pistas proporcionadas por el Evaluador al Participante en cada subtarea
o Datos temporales sobre la realización de las tareas
o Comentarios del participante
o Comentarios del Evaluador

Elegir un evaluador
• Para reducir la polarización, el evaluador no debería ser miembro del equipo de
desarrollo
• Los evaluadores deberían ser personas receptivas y de mentalidad abierta, listos
para recibir tanta información negativa como los participantes quieran proporcionar.

Elegir a participantes para el test
• Identificar a los participantes potenciales sobre un perfil de la población objetivo
• Dividir a los participantes en "clases de usabilidad" según factores como "posee
experiencia con sistemas similares", "posee experiencia con este sistema",...

Si todavía no se ha llevado a cabo, desarrollar un análisis de tareas y, a partir de
aquí, desarrollar un modelo de tareas jerárquico.
Si todavía no se ha llevado a cabo, construir un escenario de tareas representativo
para cada tipo de tarea de usuario de alto nivel. Las tareas obvias no deben ser
excluidas
Utilizar los escenarios de tareas representativos como una guía y establecer un
conjunto de instrucciones y directrices

PASO 2. DESARROLLO DE UN PROTOCOLO PARA LAS SESIONES DE TEST.
Decidir el modo en el que se seguirán instrucciones y directrices
1. El evaluador proporciona el total del conjunto de instrucciones al participante:
• No recomendado
• Puede crear una sensación de presión sobre el participante
2. El evaluador proporciona las instrucciones escritas para cada tarea a medida que el
participante progresa:
• Recomendado
• Preferible para tareas más complejas
3. El evaluador proporciona las instrucciones orales para cada tarea a medida que el
participante progresa:
• Recomendado
• preferible para tareas más simples
Determinar si la sesión será conducida en laboratorio o en campo
• El test en laboratorio es preferible para etapas tempranas-medias
• El test de campo es preferible para las últimas etapas
Determinar si el test se llevará a cabo en una etapa temprana o en una etapa final
• Protocolo en etapa temprana de aproximadamente una hora de duración
o Establecer el entorno de Test
o Establecer un ambiente de colaboración con el participante

73

o Si no se ha realizado, proceder a la firma por el participante del formulario
de consentimiento
o Proporcionar instrucciones al participante y establecer el papel del
coevaluador
o Proceder y estimular la expresión por el participante de sus impresiones y
acciones
o Entrevistar al participante según una serie de preguntas predeterminada
o Discutir y revisar los resultados con el participante
• Protocolo en etapa media de aproximadamente una hora de duración
o Establecer el entorno de Test
o Establecer un ambiente de colaboración con el participante
o Si no se ha realizado, proceder a la firma por el participante del formulario
de consentimiento
o Proporcionar instrucciones al participante y establecer el papel del
observador
o Conducir dos o tres tareas según el procedimiento y efectuar el registro de
datos
o Mantener un tiempo de conversación con el participante
o Conducir, de nuevo, dos o tres tareas según el procedimiento y efectuar el
registro de datos
o Entrevistar al participante según una serie de preguntas predeterminada
o Discutir y revisar los resultados con el participante
• NOTAS
a. Se requiere una hoja de instrucciones por cuestiones de consistencia y reutilizabilidad
o se indica que es el producto el que se somete a test, y no el participante
o se explican la duración del test y el procedimiento básico
o se explican los derechos del participante
o se explica qué es lo que se está midiendo y el motivo
b. Se requiere una hoja de consentimiento por cuestiones legales y éticas
o para el consentimiento explícito y por firmado del participante
o para el compromiso explícito y por firmado del participante
o para que el participante ceda ciertos derechos en el proceso de test
c. Se pueden requerir otros papeles, dependiendo de la situación
o encuestas
o cuestionarios para antes y después del test
o listas de comprobación para la evaluación heurística

Determinar si se enfatizarán los datos cuantitativos o cualitativos
Identificar las herramientas que se utilizarán durante el test
Diseñar los formularios que se utilizarán durante el test

• formularios para mostrar el consentimiento del participante
• hojas de instrucciones
• formularios para el registro

PASO 3. EFECTUAR UN TEST PILOTO DE LOS PROTOCOLOS DE LA SESIÓN.
Seguir el protocolo para etapas tempranas descrito con anterioridad
Localizar los problemas descubiertos
• problemas en el protocolo
• problemas en las instrucciones y directrices
• problemas en los formularios

74

PASO 4. CONDUCIR LAS SESIONES DE EVALUACIÓN REALES.
Empezar registrando la sesión con una videocámara, orientándola de modo que se
capturen las manos del usuario interactuando con el sistema
Seguir el protocolo para la sesión
Observar al participante a medida que evoluciona en sus tareas
Registrar cualquier incidente crítico que tenga lugar y considerar proseguir, cuando
ello ocurra, con una o dos preguntas abiertas
Tras los incidentes de carácter negativo
• ¿tiene algún problema?
• ¿está bloqueado?
• ¿necesita una pista?
• ¿es ese el resultado que buscaba?
• ¿resulta más difícil de lo que debería?
• ¿qué piensa llegando a este punto?
• ¿qué intenta hacer?
• ¿qué cree que ocurriría?
Tras los incidentes de carácter positivo
• ¿se siente ahora más confiado?
• ¿encontró alguna pista específica que le ayudara a resolver el problema?
• ¿qué le hizo pensar que funcionaría esta aproximación?

Tomar notas de forma cuidadosa en tiempo real, pues va a resultar más eficiente
que haciéndolo de forma retrospectiva
Agradecer y gratificar al participante.

PASO 5. INTERPRETAR LOS DATOS REUNIDOS.
Usar todos los datos reunidos para identificar los problemas de la interfaz.
• Tasas de fallos en tareas en particular
• Tiempos requeridos para determinadas tareas
• Referencias no alcanzadas
• Aspectos no verificados en las listas de comprobación para la usabilidad

Caracterización de los problemas
De acuerdo con la causa (si se conoce)

De acuerdo con la frecuencia de ocurrencia

De acuerdo con la severidad
• Crítico. Los problemas críticos son aquellos que hacen imposible la conclusión de
la tarea por el participante. El producto no puede ser distribuido, ni siquiera para un test
beta.
• Serio. Un mejor diseño hubiera evitado que el participante tuviera que sufrir serios
problemas debido a algún error. El producto sólo puede ser distribuido para un test beta
• Menor. Los problemas menores son los que llevan al participante a momentos de
distracción, confusión o desorientación. El producto podría distribuirse entre los clientes si
fuera necesario

PASO 6. PREPARAR UN INFORME
Proporcionar un resumen de los hallazgos, subtarea a subtarea, en una tabla bajo
los siguientes encabezados:

75

• descripción de la tarea
• estado de realización de la tarea
a. tarea abandonada en ___ ocasiones después de ___ segundos (medio) y ___ errores
(medio)
b. tarea completada con éxito en ___ ocasiones después de ___ segundos (medio) y tras
___ errores (medio)
c. si hay sospecha de desviaciones estadísticas, se habrán de calcular media y desviación
estándar

Efectuar un resumen en una tabla de los hallazgos relevantes si había
requerimientos de usabilidad (para tareas y subtareas específicas), bajo los
siguientes encabezados:

• descripción general de la tarea o subtarea
• referencia específica aplicada
• peor realización aceptable para la referencia dada (en número de errores o
tiempos máximos)
• objetivos de realización planificados para la referencia dada (en número de errores
o tiempos aceptables)
• mejor realización posible para la referencia dada (en número de errores o tiempos
mínimos)
• realización observada para la referencia dada (en número de errores o tiempos
reales)

Si se hizo uso de la evaluación heurística, hacer un listado de las áreas del sistema
donde el diseño no cumpla con las guías a aplicar.
Efectuar un listado de los problemas expuestos durante el test en una tabla bajo los
encabezados:

• descripción del problema
• severidad del problema
• frecuencia del problema
• posible remedio para el problema

Listar los cambios requeridos por la interfaz en orden de prioridad, considerando
que hay que dar una prioridad alta:

• a los problemas más severos
• a los problemas más comunes
• a los problemas cuya localización resulta económica
• a los problemas que pueden ser localizados rápidamente

Cambios recomendados
Revisar las grabaciones en vídeo de las sesiones y prepara una colección de
secuencias para apoyar la solicitud o recomendación de cambios

76

ANEXO 2
¿QUÉ ES ESO LLAMADO USABILIDAD?.

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

Resumen

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

¿Qué es eso llamado Usabilidad?

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

Factores de usabilidad

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

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

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

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

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

77

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

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

Medida de la usabilidad

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

A) MEDIDAS OBJETIVAS

A.1 MEDIDAS DE EJECUCION DE LA TAREA:

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

* Tiempo empleado en acabar la tarea

* Tasa de errores

A.2 MEDIDAS PSICO-FISIOLOGICAS

* Tasa cardíaca

* Secreción de adrenalina

* Potenciales evocados

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

B) MEDIDAS SUBJETIVAS

B.1 MEDIDAS ACTITUDINALES Y DE OPINION:

* Satisfacción subjetiva del uso

* Confort

* Aceptación del sistema

78

* Estética del producto

* Esfuerzo empleado en la realización de las tareas

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

79

CONCLUSIONES GENERALES

Después de haber profundizado en el tema, descubro que es mucho lo que se ha
desarrollado, y que el problema es buscar las fuentes, lo cual realmente no es nada fácil.

Otro elemento a tener en cuenta dentro de las conclusiones, es la facilidad con la cuál te
puedes perder en el tema investigado, en donde pueden haber muchas cosas pertinentes,
pero en algún momento se debe parar.... por lo cual muchas cosas no se encontrarán en
este documento, pero dejo los hipervínculos para quien quiera profundizar, más aún
cuando, parte de la información se encuentra en inglés, y el proceso de traducción es
realmente dispendioso.

Dentro de este acercamiento a los procesos de investigación, lo cual es solo un primer
paso, como tantos otros precedentes, especialmente el de:

Alejandro Floría Cortés (Febrero 2000).
Centro Politécnico Superior | Universidad de Zaragoza

que inicia un camino hacia la traducción de material bibliográfico pertinente al
tema, y lo más importante lo pone a disposición en la red, con lo cual el trabajo se
puede socializar y convertirse en plataforma, para nuevas aproximaciones como la
de este trabajo, que pretende mirar bajo este conocimiento como se puede
traducir de una manera más generalizada hacia la investigación de la usabilidad
en los objetos-producto, no solamente como herramientas asociadas al mundo del
medio informático y como se pueden construir sistemas más coherentes de
comunicación y de interfaz con las necesidades del usuario.

Ya para terminar, referido al tema específicamente podemos concluir que tanto las
metodologías como la teoría básica de aproximación a la usabilidad puede
ampliarse a cualquier tipo de producto, dado que en últimas se actúa sobre el
mismo problema: como caracterizar sistemas de comunicación y de interfaz para
satisfacer a los usuarios o consumidores de productos, aprovechando al máximo
tanto la tecnología como los medios que se tienen para lograrlo.

80

BIBLIOGRAFIA

Bibliografía

]
Alejandro Floría Cortés (Febrero 2000).
Centro Politécnico Superior | Universidad de Zaragoza.

Bibliografía
"User Centered Design in Practice - Problems and Possibilities" Jan Gulliksen, Ann Lantz
and Inger Boivie. Technical report TRITA-NA-D9813, CID-40.
http://www.nada.kth.se/cid/pdf/cid_40.pdf Royal Institute of Technology, Numeric Analysis
and Computing Science. Centre for User Oriented IT Design.

Participatory Design in Work Context: Why is it so hard to involve users? Anne-Laure
Fayard. Artículo en "User Centered Design in Practice - Problems and Possibilities",
perteneciente al informe anterior.

Páginas de IDEO Product Development donde encontramos una amplia variedad de
ejemplos de "smart products"
[Servicio de certificación de la W3C] [Página de Bobby]

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

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

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

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

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

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

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

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

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

81

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

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

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

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

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

[XBUS94] X Business Group, Inc. "Interface Development Technology". 3155 Keraney
Street, Suite 160, Fremont, CA 94538, (510) 226-1975, 1994.

Observación: esta bibliografía es la encontrada en las Fuentes de la web.

OTROS:

PAGE, Alvaro y otros. “Nuevas técnicas para el desarrollo de productos innovadores
orientados al usuario”. IBV y ADCV. 2001. Valencia España.

CAPUZ R., Salvador.” Introducción al proyecto de producción” Ingeniería concurrente para
el diseño de producto. Universidad Politécnica de Valencia.1999. Valencia España.

82

Documento usabilidad

Más contenido relacionado

La actualidad más candente (20)

Destacado (10)

Similar a Documento usabilidad (20)

Más de danamato (20)

Documento usabilidad