Enfoques para Incorporar El Diseño Centrado en El Usuario en El Desarrollo de CAI

Machine Translated by Google
Enfoques para incorporar el diseño centrado en el usuario en el desarrollo de CAI
Bill Mockovak y Jean Fox
Centro de Investigación de Ciencias del Comportamiento
Oficina de Investigación de Métodos de Encuesta
Oficina de estadísticas laborales
Resumen
Casi todas las entrevistas de encuestas ahora se realizan utilizando algún tipo de software de entrevista asistida por
computadora (CAI). Sin embargo, a menos que se consideren el diseño y la usabilidad del instrumento CAI, incluso las
preguntas redactadas con más cuidado pueden arrojar datos cuestionables.
Existe amplia evidencia de que la usabilidad mejora cuando las necesidades del usuario se consideran de manera
temprana y continua durante todo el proceso de desarrollo de software. En el desarrollo de instrumentos de entrevista
asistidos por computadora complejos, esto significa involucrar a los entrevistadores en el proceso de desarrollo lo antes
posible. Pero el desarrollo de aplicaciones CAI complejas plantea demandas especiales, porque los entrevistadores a
menudo tienen habilidades informáticas muy diversas y se encuentran dispersos geográficamente, lo que hace que
obtener sus aportes sea más desafiante. Este documento analiza diferentes enfoques que se han utilizado para abordar
el diseño de instrumentos y para incorporar principios de diseño centrados en el usuario en el desarrollo de instrumentos
complejos de entrevistas personales asistidas por computadora (CAPI).
Se citarán ejemplos de la entrevista trimestral de gastos del consumidor y la encuesta de precios de productos básicos
y servicios. Además de describir posibles enfoques que podrían utilizarse para fomentar el diseño centrado en el usuario,
este documento también presentará instrumentos y métodos de evaluación que se han utilizado para cuantificar el éxito
de los esfuerzos de diseño de usabilidad.
Introducción
El uso rutinario de entrevistas asistidas por computadora (CAI) ha llevado a instrumentos de recopilación
de datos cada vez más complejos, ya que los diseñadores de cuestionarios han aprendido a aprovechar la
tecnología que cambia rápidamente. Al mismo tiempo, esta tendencia ha dado lugar a una variedad de
nuevos desafíos para los metodólogos de encuestas que van desde la programación, prueba y depuración
de instrumentos de recopilación de datos hasta el diseño de interfaces de usuario para entrevistadores y
encuestados (para cuestionarios autocompletados).
En el transcurso de trasladar las encuestas a CAI, algunos patrocinadores y administradores de encuestas
se sorprendieron al saber que el proceso de desarrollo, prueba e implementación de instrumentos
complejos1 es mucho más difícil, lento, laborioso y costoso de lo previsto. Estos gerentes esperaban que
la eliminación de las encuestas en papel ahorraría tiempo y dinero, pero no reconocieron los costos de
desarrollo iniciales necesarios para lograr estos ahorros. Como resultado, los gerentes y metodólogos de
la encuesta han buscado otros campos de especialización para ayudar a resolver estos problemas de una
manera más oportuna y rentable. Por ejemplo, ha habido algunos intentos de aprovechar más la experiencia
disponible en el campo de las ciencias de la computación como guía para abordar problemas asociados
con el diseño, el desarrollo y las pruebas de instrumentos.2 De manera similar, los diseñadores de
encuestas han recurrido al campo de la interacción informática para la dirección en la construcción de
interfaces de usuario (Schneiderman, 1992). Aunque el desarrollo y las pruebas de instrumentos son tareas
de importancia crítica, el enfoque de este documento está en un aspecto del proceso de desarrollo que a
menudo recibe menos atención: el diseño de la interfaz de usuario y su funcionalidad asociada.
Algo de contexto histórico
Para proporcionar un contexto histórico, en un entorno DOS, el diseño de la pantalla y la
funcionalidad del usuario en CAI estaban muy limitados por el paquete de software utilizado. De hecho,
una analogía adecuada podría ser que pasar de DOS a CAI basado en Windows es comparable, en
términos de mayor funcionalidad y capacidad, a la transición de máquinas de escribir a procesadores de
texto.
Aunque al principio no había mucha flexibilidad en DOS, lo poco que existía a menudo se sacrificaba
en aras de simplificar la programación y tratar de obtener un instrumento funcional en el campo lo
antes posible. En el lado positivo, la inflexibilidad inherente de los instrumentos basados en DOS simplificó
las decisiones sobre el diseño y la funcionalidad de la pantalla (simplemente porque muchas opciones no
estaban disponibles). Pero los cuestionarios largos y complejos aún presentaban importantes desafíos de
usabilidad para los entrevistadores, especialmente cuando el entrevistador quería moverse entre las
secciones para cambiar las respuestas o retroceder para verificar las entradas anteriores (este tipo de
acciones generalmente se denominan "navegación" del entrevistador).
1
Un “instrumento” se refiere al cuestionario de encuesta automatizado.
2
Comité de Estadísticas Nacionales, Las Academias Nacionales. “Taller sobre automatización de encuestas”, 15 y
16 de abril de 2002, Washington, DC
2
Además de los serios problemas con la navegación, la entrada de datos a menudo se limitaba en los instrumentos DOS
a un elemento de entrada de datos (pregunta de encuesta) por pantalla.3 Para cuestionarios cortos y simples, esto no
era un problema, pero para cuestionarios más largos y complejos, la El enfoque de una pregunta por pantalla condujo a
una severa segmentación del contenido del cuestionario.
También dificultó enormemente a los entrevistadores familiarizarse con el contenido o desarrollar un mapa conceptual de
la estructura general del cuestionario. Debido a tales limitaciones (y los problemas asociados con el software), hubo una
renuencia general entre los entrevistadores a intentar incluso acciones simples como hacer una copia de seguridad de algunos
elementos para verificar o cambiar una respuesta anterior. De hecho, para evitar posibles problemas y confusiones, algunas
capacitaciones sobre encuestas en realidad indicaron a los entrevistadores que no retrocedieran.
Algunos instrumentos CAI complejos fueron incluso más allá. De hecho, prohibían hacer copias de seguridad una vez que se
había completado un módulo o una sección.
También surgieron otras quejas asociadas con las limitaciones de diseño de los instrumentos DOS. Uno común se
denominaba generalmente "dependencia del entrevistador", que ocurría cuando los entrevistadores hacían preguntas a
ciegas, incluso si eran totalmente inapropiadas para un encuestado (esto solía ocurrir después de que un error de entrada de
teclado pusiera al entrevistador en el camino equivocado en el cuestionario). instrumento). En estas situaciones, los
observadores de la encuesta se quejaron de que parecía que los entrevistadores habían dejado de pensar y estaban leyendo
robóticamente las preguntas de la encuesta.
Teniendo en cuenta estas limitaciones, los instrumentos basados en DOS para cuestionarios complejos no eran herramientas
que mejoraran la capacidad del entrevistador para hacer el trabajo. En lugar de ello, restringieron la flexibilidad, a veces
aumentaron la duración de la entrevista (Fuchs et al., 2000) y dificultaron la tarea de la entrevista. Como señaló Woods
(2002), "... en el diseño, cojeamos o apoyamos la capacidad natural de las personas para expresar formas de experiencia".
Además de preocuparse por obtener datos de calidad de los encuestados, los entrevistadores ahora tenían la carga adicional
de manipular un instrumento de recopilación de datos engorroso y esperar que la computadora no funcionara mal antes del final
de la entrevista (por ejemplo, debido a una falla en la batería).
A pesar de los problemas potenciales, los entrevistadores todavía reaccionaron positivamente a la introducción de computadoras
en su trabajo (Couper y Burt, 1993). Sin embargo, sus reacciones positivas no significaron necesariamente que estuvieran
contentos o satisfechos con CAI como herramienta de recopilación de datos.
En cambio, los comentarios de los entrevistadores indicaron claramente que estaban dispuestos a vivir con las deficiencias
actuales si pensaban que los administradores de encuestas estaban trabajando activamente para abordar sus preocupaciones
y mejorar las deficiencias conocidas.
Factores que afectan la complejidad desde la perspectiva de un entrevistador
¿Qué hace que un cuestionario sea inherentemente complejo? Desde la perspectiva del entrevistador, los siguientes factores
son importantes:
• Contenido de la encuesta.
3
En algunos paquetes CAI, por ejemplo, CASES 4.3, era posible mostrar e ingresar respuestas a varios
elementos en una sola pantalla en DOS.
3
• Un gran número de posibles preguntas (posiblemente cientos), por lo que se necesitan muchas
entrevistas para familiarizarse con el contenido y la secuencia de las preguntas. O, secuencias
de preguntas que conducen a datos recopilados con poca frecuencia. • La presencia de múltiples
secciones o módulos (lo que aumenta la dificultad
navegando).
• El requisito de adaptar las preguntas a diferentes situaciones “sobre la marcha”. •
Tareas de entrada de datos complejas, difíciles o largas. • El uso de listas de preguntas
o secuencias de preguntas que implican hacer una selección en una pantalla, salir de esa pantalla
para hacer preguntas adicionales sobre la selección y luego regresar a esa pantalla.
• Variaciones (inconsistencias) en el diseño de la pantalla, la entrada de datos o la funcionalidad
del usuario como resultado del uso de varios programadores o de la falta de cumplimiento
de las normas y convenciones establecidas.
• El uso de tablas, cuadrículas o pantallas que se desplazan vertical u horizontalmente. •
Un uso excesivo de ediciones que requieren la intervención del entrevistador. • Existen
múltiples formas de hacer algo (por ejemplo, navegar, ingresar datos faltantes, etc.) • Submuestreo de
encuestados. • Presencia de datos dependientes. • Habilidad para “generar” casos (crear nuevos casos
sobre la marcha)
Irónicamente, como se señaló anteriormente, la complejidad del cuestionario se ha incrementado
deliberadamente en ocasiones para simplificar las exigencias de la programación de instrumentos. Si bien
esto simplifica el diseño y la programación del instrumento de recolección de datos, lo hace a expensas
del entrevistador, quien luego tiene que lidiar con los encuestados y su frustración resultante.
Además, además de imponer mayores exigencias al entrevistador, estas decisiones de diseño a menudo
dan como resultado enfoques que le piden al encuestado que proporcione datos de una manera rígida y
no conversacional.
Un ejemplo de este tipo de compensación ocurre cuando se decide cómo obtener información
demográfica. Por ejemplo, si se utilizan dos diseños de instrumentos diferentes (enfoques de
programación), las preguntas demográficas podrían formularse de forma individual o por temas. Para el
enfoque “basado en la persona”, resultaría algo así como la siguiente línea de preguntas para dos personas
llamadas Robert y Suzanne. Para Robert, la secuencia de preguntas sería: ¿Cuál es la edad de Robert?
¿Cuál es la raza de Robert? ¿Cuál es el grado escolar más alto que ha completado Robert? etc., para
todos los elementos demográficos. Para Suzanne, la secuencia idéntica resultaría: ¿Cuál es la edad de
Suzanne? ¿Cuál es la raza de Suzanne? ¿Cuál es el grado escolar más alto que ha completado Suzanne?
etc., y así sucesivamente, para cada miembro del hogar.
Como alternativa, estas preguntas podrían formularse utilizando un enfoque "basado en temas" que
podría formular preguntas demográficas de la siguiente manera: ¿Cuáles son las edades de las personas
de su familia? ¿Cuál es la raza de cada persona? ¿Cuál es el grado escolar más alto que ha completado
cada uno? O, una ligera variante sería "¿Se ha divorciado John alguna vez?" ¿Qué hay de María? "¿Y
qué hay de Tom?", etc. Esta versión es claramente más conversacional que el enfoque basado en la
persona.
4
Con un diseño basado en la persona, a menos que los entrevistadores puedan retener la información en la
memoria, el encuestado no puede proporcionar información para más de una persona a la vez, algo que podría
hacerse fácilmente en un cuestionario en papel. De hecho, en un cuestionario en papel, el entrevistador podría
usar uno o ambos enfoques. Debido a que algunos enfoques de monitoreo (p. ej., en los centros CATI) requieren
que los entrevistadores hagan cada pregunta tal como aparece en la computadora, resulta un estilo de entrevista
muy rígido, repetitivo y no conversacional para el enfoque basado en la persona. ¿Puede un cambio tan simple
tener un impacto? Algunas investigaciones sugieren que un enfoque basado en temas puede aumentar la
eficiencia de la entrevista, es el preferido tanto por los entrevistadores como por los encuestados, reduce la falta
de respuesta de las unidades y, con las partidas de ingresos como excepción, reduce la falta de respuesta de
las preguntas (Moore y Loomis, 2001).
Además de las características generales del instrumento que afectan la complejidad, otros tipos de software
o deficiencias de diseño también pueden causar problemas o confusión. Una lista parcial incluye:
• Falta de robustez en el ingreso de datos. Por ejemplo, mantener presionada la tecla Intro durante
demasiado tiempo (o alguna otra tecla) puede generar entradas no intencionales para más de una
pregunta/elemento y llevar al entrevistador a una pregunta inesperada. • Cambios inesperados en el
diseño o disposición de la pantalla. Este tipo de cambios hacen que la
entrevistador a “reorientarse” para evaluar la situación con el fin de determinar qué hacer a continuación,
añadiendo así un retraso a la entrevista. • Codificaciones previas inconsistentes. Por ejemplo, 88, 888 u 888
podrían significar "no sé".
entrada, dependiendo de la pregunta. •
Uso de mensajes de error o edición confusos. Los mensajes de edición predeterminados en algunos
paquetes de CAI son tan confusos que los entrevistadores suelen pedir ayuda al supervisor cuando los
ven.4
• Funciones de navegación inconsistentes. Por ejemplo, presionar la tecla Re Pág puede llevarlo al primer
elemento en una pantalla, pero al medio de los elementos en una pantalla similar.
• Instrucciones para el entrevistador demasiado complejas, confusas o superfluas. • Errores
de instrumentos o idiosincrasias. En lugar de arreglar 'todo', los problemas que van desde errores tipográficos
menores hasta 'soluciones alternativas' de ingreso de datos pueden dejarse en un instrumento y
abordarse en la capacitación.
Importancia de la Usabilidad
Como ha demostrado claramente un creciente cuerpo de investigación, la usabilidad afecta la facilidad de
aprendizaje, la eficiencia de uso (incluida la frecuencia y la gravedad de los errores), la recordación (lo fácil
que es usar el software después de un período de desuso) y la satisfacción subjetiva.
No obstante, en muchos esfuerzos de desarrollo de CAI, los problemas que se consideran menores o
intrascendentes a veces no se solucionan o se dejan para "revisiones futuras". Desafortunadamente, aunque
este tipo de arreglos menores pueden parecer intrascendentes y no ser considerados "obstáculos", la
acumulación de estos problemas puede afectar la actitud del entrevistador.
4
Basado en una observación de una prueba de usabilidad del entrevistador de 2002 para la Encuesta estadounidense de uso del tiempo,
que utilizó mensajes de error emergentes predeterminados de Blaise 4 Windows (ediciones suaves y duras) en el instrumento.
5
hacia el instrumento e introducir ineficiencias generales en la recopilación de datos.
Los estudios de laboratorio han demostrado que los usuarios prefieren los diseños de pantalla mejorados
(por ejemplo, el uso de diferentes fuentes, resaltado, color, características gráficas, formato especial, etc.),
y los resultados experimentales sugieren que los instrumentos diseñados con estas mejoras son más fáciles de
usar. y requieren menos tiempo para completarse (Beatty et al. 2000).
Además, se ha demostrado que incluso pequeñas variaciones en el diseño de la pantalla afectan la cantidad
de tiempo requerida para diferentes acciones (Gray y BoehmDavis, 2000).
Las variaciones aparentemente menores en el diseño de las preguntas también pueden tener efectos
significativos en los datos obtenidos (Frazis y Stewart, 1998). La siguiente ilustración muestra una pregunta
que apareció en la Encuesta de Población Actual (CPS), que se usa para producir estimaciones mensuales
de empleo y desempleo para los EE. UU.
¿Alguna vez obtuvo un diploma de escuela secundaria al completar
la escuela secundaria O a través de un GED u otro equivalente?
(1) Sí, bachillerato completo
(2) Sí, GED u otro equivalente
(3) Sí
En las preguntas anteriores de este instrumento se usaba habitualmente 1 = sí y 2 = no como opciones de
respuesta, por lo que los entrevistadores se acostumbraron a ingresar un 1 para sí y un 2 para no.
De los encuestados a los que se les hizo esta pregunta, alrededor del 12 por ciento supuestamente
respondió con la Opción 2, pero al usar fuentes de datos externas, Frazis y Stewart concluyeron que casi todas
estas respuestas se debieron a la entrada de datos falsos por parte de los entrevistadores. El formato de
pregunta que se muestra en la ilustración resultó en una estimación de 4,8 millones de GED adicionales en los
EE. UU., cuando la población estimada real estaba más cerca de 400.000. Por lo tanto, un ligero cambio en el
diseño de la pregunta, pero una grave violación de un principio básico de usabilidad (mantener la consistencia)
tuvo un impacto significativo en los datos resultantes.
Con el cambio a los sistemas operativos Windows y la llegada de paquetes CAI y lenguajes de
programación que ofrecen el uso de herramientas gráficas, el diseño de pantallas e instrumentos se ha
vuelto mucho más flexible. Estas innovaciones han tenido un gran impacto en el diseño de la pantalla y en las
decisiones sobre la usabilidad. Por ejemplo, con el uso de sistemas operativos más modernos, las siguientes
mejoras (esta no es una lista completa) ahora son posibles con el uso de elementos de diseño gráfico:
• El tipo y el tamaño de la fuente se pueden variar fácilmente en la misma pantalla y entre pantallas. • Se
puede utilizar una variedad de colores. • Se pueden usar sombreados y negritas (las negritas también se
hacían fácilmente en DOS). • Los menús y las listas desplegables están disponibles. • Hay pestañas
disponibles para identificar secciones de instrumentos y para navegar.
6
• Se pueden utilizar diferentes tipos de encabezados de sección.
• Los íconos se pueden usar fácilmente con fines de representación (p. ej., para instrucciones, para
indicar que hay ayuda o información adicional disponible). • Se pueden
usar “ventanas”, ventanas emergentes o paneles para presentar información adicional y hacer que haya más
espacio en la pantalla (bienes raíces) disponible. • Se pueden utilizar fácilmente formatos de entrada de
datos más complejos (p. ej., cuadrículas o tablas).5 • Se puede disponer de más espacio en la pantalla mediante
el desplazamiento. • La entrada de datos se puede realizar con el ratón o el teclado (o incluso con la voz). • Las
aplicaciones multimedia están fácilmente disponibles.
Sin embargo, con esta flexibilidad adicional se ha incrementado la responsabilidad de una variedad de
decisiones relacionadas con el diseño básico de la pantalla y la funcionalidad del entrevistador. Algunas
organizaciones ya han codificado sus estándares de pantalla para instrumentos "basados en Windows".6 No
obstante, a pesar de los avances recientes realizados en paquetes CAI bien conocidos como Blaise y CASES,
algunos patrocinadores de encuestas han optado por no utilizar estos paquetes porque todavía consideran
demasiado restrictivos e inflexibles a la hora de satisfacer las demandas de sus recolectores de datos. Por
ejemplo, dos iniciativas separadas de recopilación de datos de CAI para el Índice de Precios al Consumidor de
la Oficina de Estadísticas Laborales utilizan interfaces gráficas diseñadas con Visual Basic.7
Implementación del diseño centrado en el usuario para instrumentos complejos
La usabilidad se puede evaluar utilizando una variedad de técnicas, pero existen tres enfoques generales
(Armstrong et al., 2002):
1. Técnicas de encuesta incluido el uso de cuestionarios, entrevistas y entrevistas directas
observación.
2. Técnicas de inspección, incluidas revisiones estandarizadas, comparación de prototipos y
evaluaciones heurísticas.
3. Técnicas de prueba, que incluyen modelado y simulación, pensamiento en voz alta y pruebas
experimentales.
El usuario clave en la mayoría de las entrevistas asistidas por computadora es el entrevistador
(la autoadministración de encuestas plantea otros desafíos únicos). Por lo tanto, el objetivo a largo plazo debe ser
el desarrollo de una herramienta de recopilación de datos que haga que el trabajo del entrevistador sea más fácil,
no más difícil. Desafortunadamente, como se señaló anteriormente, los esfuerzos de desarrollo de instrumentos a
menudo no han logrado este objetivo.
Para garantizar que un instrumento ayude, en lugar de obstaculizar, a un entrevistador, se debe implementar
un proceso llamado diseño centrado en el usuario para que sea paralelo al proceso de desarrollo de
instrumentos para instrumentos complejos.
5
Algunos paquetes de DOS permiten el uso de cuadrículas pero con limitaciones.
6
“Especificaciones para la creación de estándares CE/Blaise”. Documento del Negociado del Censo Interno, 10 de febrero de 2000. 7
Los instrumentos de la Encuesta de Productos y Servicios y la Encuesta de Vivienda.
7
¿Cuáles son los requisitos previos y los pasos básicos para implementar el diseño centrado en el usuario?
El proceso de diseño centrado en el usuario supone el uso de un proceso de equipo para el desarrollo de
instrumentos y la presencia de al menos un miembro del equipo que esté familiarizado con el diseño de la
interfaz de usuario. Aunque, idealmente, esta persona habría recibido una formación especial en el campo de la
usabilidad, a menudo otros profesionales con suficiente formación pueden ocupar el puesto. El proceso de diseño
centrado en el usuario (UCD) consta de los siguientes pasos básicos:
1. Recopilar datos. Acerca de los usuarios, sus tareas y sus procesos de trabajo actuales para determinar los
requisitos del entrevistador.
2. Analizar los datos. Determinar cómo diseñar el instrumento de recolección de datos para cumplir con los requisitos
de usabilidad del entrevistador. Identificar la funcionalidad clave que se requiere.
3. Diseño y desarrollo. Desarrollar prototipos del instrumento de recopilación de datos, o
módulos separados y obtenga retroalimentación temprana de los entrevistadores. Algunas secciones difíciles
pueden requerir el desarrollo de múltiples prototipos. Para mantener los costos bajos, se puede comenzar
con prototipos en papel de baja fidelidad, de modo que pueda obtener retroalimentación antes de realizar
inversiones significativas en programación.
4. Pruebe y obtenga comentarios. Desarrolle escenarios de prueba basados en los datos recopilados en el Paso 1.
Diseñar y realizar iteraciones de evaluaciones y pruebas de usabilidad.
5. Seguimiento. Realizar estudios de seguimiento que midan la usabilidad y la satisfacción de los usuarios.
En el desarrollo de instrumentos de encuesta, las claves del éxito de este enfoque son la participación temprana de
los entrevistadores en el proceso de diseño, los mecanismos que permiten una retroalimentación continua durante el
ciclo de desarrollo del instrumento y la participación activa del programador del instrumento (autor). ) en el proceso.
Recopilación y análisis de los datos
Existe una variedad de métodos para recopilar datos sobre los requisitos del usuario. Si ya existe un
cuestionario en papel o una entrevista asistida por computadora, los recolectores de datos serán una buena fuente
de sugerencias para los requisitos críticos y los peligros potenciales. También se pueden utilizar otros métodos,
como la observación directa de la recopilación de datos y las entrevistas personales o grupales, para proporcionar
información complementaria.
Al obtener esta información, es importante tratar de obtener aportes de una muestra representativa
de entrevistadores, especialmente entrevistadores que varían en trabajo y experiencia informática. Además,
cualquier recomendación hecha por los entrevistadores debe revisarse cuidadosamente. Es probable que
haya casos en los que los entrevistadores proporcionen recomendaciones contradictorias o en los que no tengan
experiencia en la que basar sus sugerencias.
Para ilustrar por qué la aceptación general de todas las solicitudes no debería ser la regla, en un proyecto, los
entrevistadores que habían estado usando cuestionarios en papel indicaron claramente, cuando se les preguntó, que
querían que solo se mostrara una pregunta de la encuesta en una pantalla y tantos espacios en blanco como fuera posible.
8
posible. Con base en esta información, se desarrolló un primer sistema CAI que cumplía con este requisito
básico solo para descubrir que a medida que los entrevistadores ganaban más experiencia con la herramienta
de recopilación de datos, pronto pedían que se colocaran tantas preguntas como fuera posible en una pantalla.
Desafortunadamente, debido a las limitaciones de tiempo y la disminución de los recursos, este sistema basado en
DOS no pudo modificarse para lograr este objetivo. En retrospectiva, debería haber quedado claro que se pedía a
los entrevistadores que dieran su opinión sobre algo que afectaría la diferencia en la cantidad de experiencia. Por lo
tanto, se deberían haber tomado medidas para obtener retroalimentación adicional después de que los entrevistadores
hayan ganado más experiencia y antes de que la funcionalidad del software se haya bloqueado.
Uso de prototipos
Como se señaló anteriormente, los instrumentos complejos se dividen con frecuencia en secciones o
módulos, pero estos módulos a menudo difieren significativamente en sus desafíos de diseño y usabilidad.
En los instrumentos CAI más antiguos, no era raro desarrollar todo el instrumento y luego comenzar un
extenso proceso de prueba y depuración. Sin embargo, con paquetes CAI más modernos, las secciones del
instrumento se pueden desarrollar y probar por separado y, si es necesario, se pueden desarrollar múltiples
iteraciones de prototipos (aunque en los instrumentos modulares, la integración y prueba del instrumento completo
sigue siendo un paso crítico).
¿Por qué el desarrollo iterativo y las pruebas son tan importantes en el proceso de desarrollo?
• Un proyecto grande, posiblemente difícil de manejar, se puede dividir en pasos que son más
manejable.
• Los problemas críticos de diseño pueden identificarse temprano y, por lo tanto, abordarse temprano en el
proceso de desarrollo. • Es
más probable que se realicen cambios si se incluye el tiempo adecuado en el cronograma para el desarrollo y
las pruebas adecuadas de los módulos del instrumento. A medida que aumentan las presiones de tiempo
y producción, es menos probable que se produzca un cambio significativo.
• Los enfoques de diseño que funcionan en una sección o módulo pueden usarse en otros (es decir,
código compartido). De manera similar, los enfoques de diseño que no funcionan no se utilizan en todo el
instrumento.
• Si no se puede lograr la funcionalidad deseada, hay tiempo para desarrollar alternativas viables que no
comprometan la calidad de los datos.
• La identificación temprana de los problemas y su solución significa menos reelaboración y nuevas pruebas más adelante.
Además, es mucho más económico solucionar los problemas antes de la producción, en lugar de tratar de
solucionar los problemas una vez que el instrumento ha entrado en producción (CNSTAT, 2002). • La prueba
es generalmente más fácil para los módulos.
Prototipo de Pantalla de Recogida de Datos Diarios
La siguiente ilustración muestra un prototipo inicial8 desarrollado para una sección clave de la Encuesta
estadounidense sobre el uso del tiempo. En esta encuesta, se pide a los encuestados que informen sobre su
8
Este es un prototipo de Blaise 4 Windows.
9
actividades por un período de 24 horas: desde las 4 am del día anterior hasta las 4 am del día de la entrevista.
El prototipo ilustra algunas de las características gráficas que se pueden usar fácilmente en los
instrumentos basados en Windows. Estos incluyen el uso de pestañas para identificar diferentes secciones, menús
para funciones adicionales, sombreado para designar información de solo lectura (por ejemplo, las horas de inicio
de las actividades), el uso de un formato de cuadrícula o tabla que permite múltiples preguntas y entradas en un
pantalla única, desplazamiento horizontal y vertical de la tabla, ingreso de datos muy flexible (se puede ingresar
la duración de una actividad escribiendo un valor en la columna de horas, la columna de minutos, las columnas de
horas y minutos, o la columna Detener), encabezados de secciones especiales y la entrada de datos se puede
lograr usando un teclado o un mouse.
9
Una vez que se ha desarrollado un prototipo, se puede obtener la retroalimentación del entrevistador utilizando uno
de los tres enfoques básicos:
9
Se usaron colores, pero es posible que no aparezcan según el método de reproducción de este papel.
10
1. Los entrevistadores pueden ser llevados a una ubicación central.
2. Los investigadores de usabilidad pueden viajar a los entrevistadores.
3. Se puede enviar el software a los entrevistadores para que lo evalúen.
Los beneficios de realizar pruebas de usabilidad son variados. Si se hace correctamente, incluir a los usuarios
en el proceso de diseño mejora la comunicación y conduce a una mejor aceptación por parte de los
entrevistadores del producto final. Por lo tanto, incluso si no se puede proporcionar toda la funcionalidad deseada,
se pueden dar razones a los entrevistadores que expliquen por qué, y a medida que se incluya la funcionalidad
deseada o se realicen cambios en función de sus aportes, la moral del entrevistador se beneficiará. Además de
los beneficios para los entrevistadores, las pruebas de usabilidad también brindan a los diseñadores o
programadores de instrumentos (autores) la oportunidad de ver su instrumento en uso. Por lo tanto, los informes
resumidos de la prueba de usabilidad tendrán más impacto si los desarrolladores pudieron observar algunas de
las dificultades informadas.
Ejemplo de prueba de usabilidad en el desarrollo de instrumentos de encuesta
Las pruebas regulares de usabilidad han sido parte del esfuerzo de desarrollo de varios instrumentos
BLS. Los procedimientos utilizados y los beneficios obtenidos se discutirán a continuación para dos encuestas
de BLS: la encuesta de Entrevista Trimestral de Gastos del Consumidor (CEIS) y la encuesta de Productos
Básicos y Servicios (C&S), las cuales se realizan para el Índice de Precios al Consumidor (CPI).
Desarrollo de instrumentos CEIS
En el CEIS, se realizaron tres pruebas de usabilidad separadas con aproximadamente 6 meses de diferencia
e involucraron traer 12 representantes de campo (entrevistadores), uno de cada una de las 12 oficinas
regionales de la Oficina del Censo, durante varios días a la vez.10 Además, una prueba previa ( 300 casos) y
un ensayo general (3000 casos) también se realizaron y presentaron dos oportunidades más para obtener
datos de usabilidad y reacciones del entrevistador.
Debido a que se estaba utilizando un paquete CAI completamente nuevo (Blaise 4 Windows), la prueba inicial
incluyó las secciones más simples del instrumento y se centró en obtener retroalimentación del entrevistador
sobre las decisiones tomadas sobre el diseño y el diseño de la pantalla. La prueba 2 incluyó las secciones
más difíciles del instrumento y se centró más en la entrada de datos y los problemas de navegación. La prueba
3 incluía todas las secciones del instrumento, además de un sistema rudimentario de gestión de casos. En cada
paso de la prueba, el instrumento incluía todas las secciones (módulos) de la prueba anterior, además de varias
secciones nuevas y funciones nuevas o mejoradas añadidas en respuesta a la retroalimentación del entrevistador
obtenida en la prueba anterior.
Para los lectores interesados, el Anexo 3 presenta los pasos sugeridos que podrían seguirse para realizar
una prueba de usabilidad de un instrumento de encuesta asistido por computadora para entrevistas.
Aunque el propósito principal de las pruebas internas era la prueba de usabilidad, implicaron tantas pruebas
prácticas que los problemas del instrumento (errores) también se descubrieron inevitablemente, por lo que las
pruebas exhaustivas fueron un beneficio secundario importante. Las pruebas internas solían durar
10
Ver Reed (2000) para una descripción detallada del protocolo de prueba de usabilidad, instrumentos de evaluación y
resultados. La Oficina del Censo recopila los datos para esta encuesta BLS.
11
en cualquier lugar de 3 a 5 días e implicó una interacción extensa del entrevistador con el instrumento que
se controló mediante el uso de entrevistas guionadas u hojas informativas, aunque también se permitió
tiempo para cantidades significativas de pruebas no estructuradas y exploración del instrumento.
Aparte, este extenso esfuerzo de prueba probablemente no sería necesario para la mayoría de las encuestas,
incluso si se tratara de instrumentos largos y complejos. Sin embargo, al comienzo de este proyecto, varios expertos
en encuestas advirtieron que pensaban que la Entrevista Trimestral de Gastos del Consumidor sería imposible de
realizar en una computadora, y un intento inicial de convertir la encuesta utilizando un paquete CAI basado en DOS
confirmó este escepticismo como insuperable. Se encontraron problemas de diseño, programación y usabilidad.
Esta experiencia, junto con el deseo de obtener la aceptación del instrumento CAPI por parte de los usuarios,
condujo a la decisión de implementar un extenso esfuerzo de prueba de usabilidad.
Para obtener comentarios de los representantes de campo (FR), se utilizaron dos documentos, "Informes de
pruebas independientes" y "Formularios de evaluación", en cada una de las pruebas internas. Los formularios de
prueba independientes eran informes simples y abiertos que permitían a los representantes de campo informar
problemas con el diseño de la pantalla, la usabilidad y los problemas de instrumentos a medida que los encontraban
mientras trabajaban con guiones o pruebas no estructuradas. Estos formularios se resumieron después de cada
prueba y se identificaron problemas de usabilidad (también se resumieron los errores de prueba). Los formularios
de evaluación se utilizaron tanto en las pruebas internas como en las de campo y variaron según los objetivos de
la prueba. Se describen a continuación.
Como parte de cada una de las pruebas, cada participante completó un formulario de evaluación resumida.
Además de una variedad de elementos de actitud tipo Likert y preguntas abiertas para obtener retroalimentación
sobre la capacitación, el estado general del instrumento y una variedad de otros temas, también se completó una
escala de calificación de usabilidad separada (consulte el Anexo 1) y mantuvo bastante consistente entre las
pruebas. El análisis de la escala de calificación de usabilidad condujo a una clasificación de las características de
usabilidad (consulte el Anexo 2), que luego podría compararse con otros comentarios evaluativos obtenidos
utilizando otros medios (p. ej., informes grupales, observaciones individuales, etc.). Por lo tanto, se utilizaron una
variedad de métodos para obtener retroalimentación y una evaluación cualitativa nos dijo si estábamos escuchando
los mismos problemas. Sin embargo, una ventaja de usar las clasificaciones de puntuación de usabilidad fue que
eran fáciles de interpretar, algunas cambiaron drásticamente entre las pruebas, y estos resultados podrían mostrarse
a los gerentes de programas de encuestas para aclarar problemas y respaldar la necesidad de cambios adicionales
en el instrumento.
Como ejemplo del tipo de retroalimentación que se podría proporcionar, el problema más serio en la Prueba 1
involucraba la facilidad con la que se podían corregir los errores (ver Anexo 2). Por otro lado, la velocidad del
instrumento fue calificada como una de las mejores características en esta misma prueba.
Sin embargo, en pruebas posteriores, a medida que se agregaron módulos adicionales (y más complejos) y el
tamaño y la complejidad del instrumento aumentaron drásticamente, la velocidad del instrumento se convirtió en la
principal preocupación de usabilidad (aunque la "corrección de errores" siguió siendo una tarea generalmente difícil
en todos los casos). pruebas). El siguiente gráfico muestra más dramáticamente cómo las calificaciones
12
Velocidad general entre pantallas
0.8
0.7
0,6
0,5
Prueba 1
Proporción
respuestas
de
0,4
prueba 2
0.3
0.2
0.1
0
123456
Rápido a Lento
acerca de la velocidad del instrumento cambió entre las Pruebas 1 y 2, donde una calificación de escala más
alta indica un problema.11
Observar las desviaciones estándar de las calificaciones individuales en la escala también puede proporcionar
información útil. Las desviaciones estándar pequeñas indican una mayor consistencia en las reacciones de los
participantes y, junto con las calificaciones positivas, sugieren que una característica no es un problema, mientras
que las desviaciones estándar pequeñas y las calificaciones negativas indican lo contrario.
Como consecuencia de estos hallazgos, se aclararon las prioridades para la mejora de los instrumentos, y
datos como estos jugaron un papel importante para convencer a los administradores de encuestas de la urgencia
y la importancia de los cambios deseados. Además, las calificaciones de la escala proporcionaron evidencia de
que la usabilidad general era aceptable. Sin embargo, dado que el mismo grupo de entrevistadores había
participado en las tres pruebas de usabilidad y existía la posibilidad de un efecto de tipo Hawthorne, las escalas
12
de calificación de con
usabilidad
se usaron
entrevistadores nuevamente
adicionales en
que una
no prueba
habían de
ecvaluados.
sido ampo de p
seguimiento y un ednsayo
arte del proceso general
e prueba
interno.
Como se muestra en la columna Media de la prueba de campo de la tabla del Anexo 2, algunos de los
problemas clave de usabilidad (p. ej., la velocidad del instrumento y la corrección de errores) que se identificaron
en las pruebas internas también encabezaron la lista de problemas en el campo. prueba. Pero los resultados
también sugirieron que la navegación era más un problema en un entorno de producción. Este mismo patrón de
resultados ocurrió en el ensayo general.
Es interesante notar que en casi todos los elementos comparables, las calificaciones de usabilidad fueron
más bajas en las pruebas de campo que en las pruebas internas. Las calificaciones menos positivas en las
pruebas de campo pueden deberse a las mayores demandas de las entrevistas de producción, pero también a
la inclusión de entrevistadores (y supervisores) a quienes no se les había brindado atención especializada
durante un período de tiempo relativamente largo. Además, las calificaciones más altas de los internos
11 Una prueba t de muestras independientes indicó que las calificaciones medias diferían significativamente; t= 13.916, p<.000.
12
Cabe esperar que la atención especializada prestada a los entrevistadores durante un período de tiempo relativamente largo
influir en sus informes y calificaciones.
13
los participantes de la prueba podrían haber resultado de su participación prolongada, lo que llevó a un
sentimiento de propiedad del diseño.
Propiedades psicométricas de la escala de calificación de usabilidad
En cuanto a las propiedades psicométricas de la escala de valoración de la usabilidad, en la Prueba 2 se
calculó un coeficiente de fiabilidad interna (coeficiente alfa) de 0,91 (N = 12) y un valor de 0,89 (alfa estandarizada
= 0,90, N = 119). calculado para el ensayo general. Para su uso propuesto, este cumple con los estándares
mínimos propuestos por Nunnally (1967, página 226).
Aunque el número de casos fue limitado en el ensayo general, se realizó un análisis factorial exploratorio para
investigar la estructura interna de la escala. Al principio, se utilizó una variedad de métodos de prueba
(componentes principales, eje principal, etc.) para determinar el número óptimo de factores subyacentes. La
solución final usó la factorización del eje principal y la rotación oblimin directa (para esta solución, los valores
faltantes se reemplazaron con valores medios, lo que resultó en N = 147), porque resultó en la máxima
interpretabilidad de la estructura interna de la escala.
Cuatro factores explicaron alrededor del 67 por ciento de la variabilidad total en las calificaciones. La matriz
de patrón se muestra en el Anexo 4. Con base en estos resultados, los cuatro factores se nombraron de la
siguiente manera:
Factor 1 Usabilidad general
factor 2 Velocidad del instrumento
Factor 3 Claridad/usabilidad de la pantalla
factor 4 Introducción y corrección de datos.
Otras medidas posibles para evaluar la usabilidad
Otra herramienta potencialmente útil para descubrir problemas de usabilidad son los archivos de auditoría o
rastreo producidos como subproducto de la recopilación de datos asistida por computadora. Estos tipos de
archivos registran los comportamientos (acciones) del entrevistador durante una entrevista. Al revisar estos
archivos, comienzan a surgir patrones de comportamiento. Por ejemplo, Hansen y Marvin (2001) revisaron los
registros de auditoría de Blaise y descubrieron lo siguiente (este tipo de retroalimentación enfocada condujo a un
rediseño de ciertas secciones).
• Los ítems seleccionados de la prueba previa tuvieron altas tasas de abandono (los entrevistadores abandonaron el instrumento de ese
pregunta en particular) o un gran número de terminaciones anormales. • Ciertos
artículos generaron un alto número de errores. Un solo bloque de ítems (preguntas sobre el historial de control
de la natalidad) representó aproximadamente el 29 por ciento de 4525 verificaciones de consistencia en
todos los ítems en todas las entrevistas.
• Algunos entrevistadores tenían conteos medios mucho más altos o más bajos de controles de consistencia
(cuando aparece un mensaje de error) por caso.
• Algunos artículos tardaron mucho más que el promedio o la duración esperada.
14
• Algunos entrevistadores fueron muy eficientes en completar la entrevista, mientras que otros tardaron mucho
más de lo esperado.
Desarrollo de productos básicos y servicios (C&S)
El desarrollo del instrumento de recopilación de datos de C&S también adoptó un enfoque centrado en el
usuario. Consideramos las necesidades y habilidades de los usuarios en el diseño de la interfaz. Adoptamos un
enfoque de diseño iterativo, por lo que incorporamos varias rondas de pruebas de usuarios y sistemas en el plan
de desarrollo.
Durante las pruebas de usuario, las limitaciones de recursos impedían llevar a los usuarios a una ubicación central.
Debido a que los usuarios trabajaban en ubicaciones remotas, se tuvo que encontrar un enfoque alternativo para
obtener comentarios sobre la usabilidad. La sabiduría convencional en el campo de la usabilidad argumenta que
debe observar a los usuarios para saber realmente dónde están los problemas. Los usuarios tienden a culparse a
sí mismos por los problemas y minimizan sus informes de problemas. Desafortunadamente, carecíamos de recursos
para permitir que los participantes viajaran a Washington, DC o, alternativamente, para que los diseñadores de la
interfaz de usuario viajaran a los participantes. Por lo tanto, exploramos opciones para realizar observaciones de
forma remota.
La literatura describe métodos como los siguientes para observar a los usuarios remotos:
• Proporcionar un botón para que los usuarios hagan clic (para almacenar videoclips) siempre que
experimentan un incidente crítico mientras utilizan un prototipo de software (Hartson, Castillo, Kelso y
Neale, 1996). • Usar una herramienta de ventana compartida y el teléfono para realizar sesiones de
forma remota
(Hammontree, Weiler y Nayak, 1994).
Aunque esperábamos realizar algún tipo de observaciones directas, ninguno de estos métodos fue práctico
para nosotros. En consecuencia, decidimos utilizar cuestionarios especialmente diseñados13 para solicitar
la retroalimentación de los usuarios.
Primero, proporcionamos a los usuarios una computadora cargada con el instrumento. Les dimos instrucciones
para usar el instrumento, realizar la prueba y completar el cuestionario. Luego, los usuarios recopilaron datos
en el campo y luego regresaron a sus hogares para completar el cuestionario. Aproximadamente 10 personas
participaron en cada etapa de prueba, con más involucradas a medida que nos acercábamos a la implementación.
El cuestionario se elaboró cuidadosamente para solicitar la opinión de los usuarios. Las preguntas eran muy
específicas, por lo que los usuarios informarían sobre temas clave (Fox, 2000; Fox, 2001). Cada pantalla del
instrumento tenía una página correspondiente en el cuestionario. En la parte superior de la página, apareció una
imagen de la pantalla. Debajo de eso, varias preguntas solicitando a los usuarios calificaciones sobre diferentes
aspectos de la pantalla. En la parte inferior de la página, varias preguntas abiertas permitieron a los usuarios agregar
cualquier idea adicional que tuvieran.
13
Consulte Charlton, 2002 para conocer las pautas sobre el desarrollo de tales cuestionarios.
15
El cuestionario fue bastante exitoso en descubrir problemas de usabilidad. Las calificaciones identificaron áreas
generales de preocupación y las preguntas abiertas permitieron a los usuarios identificar problemas específicos o
sugerir alternativas. Varios factores pueden haber influido en el éxito del cuestionario:
• Los participantes estaban extremadamente motivados para responder. Sabían que tendrían que usar el instrumento
casi a diario y querían estar seguros de que funcionaría para ellos.
• Las preguntas específicas y las capturas de pantalla adjuntas ayudaron a los participantes a concentrarse
sobre los problemas
• Después de la primera iteración, los usuarios pudieron ver que realmente los escuchamos, por lo que
continuó proporcionando información.
Por lo tanto, el proyecto de desarrollo de C&S utilizó los recursos disponibles para realizar una evaluación de la usabilidad
del instrumento. El cuestionario que utilizamos tomó algo de tiempo para armarse, pero no requirió los extensos costos de
viaje o hardware asociados con otros métodos de prueba remota.
Otras consideraciones en la implementación del diseño centrado en el usuario
Vale la pena enfatizar que el éxito del diseño centrado en el usuario se basa en la implementación exitosa de un proceso
de equipo, lo que significa que se deben enfrentar los obstáculos de comunicación y organización. Para la mayoría de las
aplicaciones CAI, los siguientes roles suelen estar representados en los equipos:
• Gerente de encuestas •
Especialista en la materia de encuestas • Experto
en usabilidad o equivalente • Metodología de
encuestas: incluida la persona que prepara las especificaciones del instrumento • Gerente de campo (para representar al
personal de recolección de datos) • Autores/programadores
Existen numerosos recursos disponibles para ayudar a estructurar y guiar el proceso del equipo (Quick, 1992;
Katzenbach y Smith, 1993; Koehler y Pankowski, 1996; USDE, 1997). Sin embargo, como se señaló, los equipos
existen dentro de las organizaciones y, además de los desafíos de utilizar equipos exitosos, existen numerosos
obstáculos organizacionales que pueden interponerse en el camino de un proceso exitoso de diseño centrado en el
usuario. Una lista parcial de Anderson (2002) incluye lo siguiente:
• Ignorancia, malentendidos o una comprensión diferente del diseño centrado en el usuario
persiste
• Se cuestiona la credibilidad del mensajero o de los especialistas. • El proceso
en sí mismo es cuestionado (es demasiado “ligero”, “no probado”, “no técnico”).
suficiente”, etc.)
dieciséis
• Existen poderosas preferencias y sesgos personales; por ejemplo, los usuarios son vistos como parte
del problema, no de la solución. • No se
otorgan recompensas por atender las necesidades de los usuarios.
• Existe fragmentación de la organización y de responsabilidades. • Hay incomodidad
con el proceso de diseño (no hacerlo bien la primera vez; con la flexibilidad, la incertidumbre, la imprecisión). •
Hay frecuentes cambios organizacionales y de personal. • Los desarrolladores están aislados o aislados. •
Los usuarios son inaccesibles. • Los cronogramas de desarrollo cortos son la norma. • El personal y/o el
presupuesto son inadecuados. • La experiencia del usuario no se percibe como un problema.
A pesar de los posibles obstáculos, se ha demostrado que el diseño centrado en el usuario funciona en
muchas organizaciones. Sin embargo, para aumentar la probabilidad de éxito en el desarrollo de
instrumentos de encuesta, se requiere atención y supervisión activa de la administración.
Como se muestra en este documento, incluso cuando no existen recursos para el uso de métodos más
tradicionales de pruebas de usabilidad, se pueden utilizar otros métodos menos costosos, como los cuestionarios,
como sustituto. A menudo, los métodos muy simples y económicos pueden proporcionar una retroalimentación
muy útil. Las claves del éxito son hacer el esfuerzo de obtener comentarios de los usuarios, especialmente
después de cambios importantes en el diseño, y mostrarles a los usuarios que sus aportes han tenido un impacto
en futuros rediseños.
17
Referencias
Anderson, Richard I. “Abordar los obstáculos organizacionales y lograr (mayor)
Beneficios comerciales del diseño 'centrado en el usuario' (o 'centrado en el ser humano' o 'dirigido
por objetivos' o...) investigación etnográfica, colaboración multidisciplinaria, ingeniería de usabilidad...” (documento
de posición en evolución, última actualización, mayo de 2002), http ://www.well.com/user/riander/obstáculos.html
Armstrong, SD; cervecero, WC; y Steinberg, RK “Pruebas de usabilidad”, en Charlton, Samuel G. y O'Brien, Thomas G.
(Editores); 2002. Manual de pruebas y evaluación de factores humanos (2ª ed.). Mahwah, NJ, EE. UU.:
Lawrence Erlbaum Associates, Publishers. págs. 403432.
Beatty, P.; Couper, M; Hansen, SE; Lamias, M; y Marvin, T., "El efecto del diseño de pantalla CAI en el rendimiento
del usuario: resultados de un experimento". Informe presentado a la Oficina de Estadísticas Laborales,
julio de 2000.
Charlton, Samuel G. “Técnicas de cuestionarios para prueba y evaluación”, en Charlton, Samuel G. y O'Brien, Thomas
G. (Editores); 2002. Manual de pruebas y evaluación de factores humanos (2ª ed.). Mahwah, NJ, EE. UU.:
Lawrence Erlbaum Associates, Publishers. págs. 225246.
Couper, MP y Burt, G. “Reacciones de los entrevistadores ante la interacción personal asistida por computadora”.
Entrevistas (CAPI)”, Actas de la Conferencia Anual de Investigación de la Oficina del Censo de EE. UU. de 1993.
Comité de Estadísticas Nacionales, Las Academias Nacionales. “Taller sobre automatización de encuestas”, 15 y
16 de abril de 2002, Washington, DC
Dumas, JS y Redish, JC Una guía práctica para las pruebas de usabilidad. Intellect Books, Portland, Oregón, 1999.
Fox, JE "Recopilación de datos de recopiladores de datos: uso de cuestionarios para recopilar comentarios de usuarios
remotos". Documento complementario del póster presentado en la Conferencia de la Asociación de
Profesionales de la Usabilidad, Asheville, NC, 2000.
Fox, JE "Métodos de usabilidad para diseñar un instrumento de recopilación de datos asistido por computadora para el
CPI", Actas de la Conferencia FCSM, Washington, DC, noviembre de 2001.
Frazis, H. y Stewart, J. “Errores de teclado causados por códigos inusuales de perforación:
Evidencia de una prueba de encuesta de población actual”. Actas de la Sección sobre Métodos de Investigación
de Encuestas, Asociación Estadounidense de Estadística, 1998, 13134.
18
Fuchs, M.; Couper, M.; y Hansen, SE “Efectos de la tecnología: hacer CAPI o PAPI
¿Las entrevistas toman más tiempo? Diario de Estadísticas Oficiales, vol. 16, núm. 3, 2000, págs. 273286.
Gray, WD y BoehmDavis, DA "Los milisegundos importan: una introducción a las microestrategias y su uso
para describir y predecir el comportamiento interactivo". Revista de Psicología Experimental:
Aplicada, vol. 6, No.4, 2000, págs. 322335.
Hammontree, M., Weiler, P. y Nayak, N. (1994). "Métodos y herramientas: pruebas de usabilidad remotas".
Interacciones, 1(3) 2125.
Hansen, SE y Marvin, T. “Informes sobre tiempos de elementos y pulsaciones de teclas de Blaise
Pistas de auditoría." Documento presentado en la 7ª Conferencia Internacional de Usuarios de Blaise,
Washington, DC, del 12 al 14 de septiembre de 2001.
Hartson, HR, Castillo, JC, Kelso, J. y Neale, WC (1996). “Evaluación remota: La red como extensión del laboratorio
de usabilidad”. Actas de la Conferencia ACM CHI 96 sobre factores humanos en sistemas informáticos,
v.1, 228235.
Katzenbach, Jon R. and Smith, Douglas K. La sabiduría de los equipos: creación de una organización de alto
rendimiento. Boston: Prensa de la Escuela de Negocios de Harvard, 1993.
Koehler, Jerry W. and Pankowski, Joseph M. Equipos en el gobierno: un manual para
Organizaciones basadas en equipos. Hampton, Nueva Hampshire: St. Lucie Press; 1996
Moore, JC y Loomis, LS, “Reducción de la falta de respuesta de ingresos en un
Entrevista." 56ª Conferencia Anual de la Asociación Estadounidense para la Investigación de la
Opinión Pública, 2001.
Nielsen, J. "Por qué solo necesita probar con 5 usuarios", Alertbox, 19 de marzo de 2000, http://www.useit.com/
alertbox/20000319.html
Nunnally, JC Teoría Psicométrica. Nueva York: McGrawHill, 1967.
Rápido, Thomas L. Construcción exitosa de equipos. Nueva York: AMACOM, 1992.
Red, María. “Documentación de actividades CE/Blaise Test 1”, Negociado Interno del Censo
informe, septiembre de 2000.
Rosson, MB y Carroll, J. Ingeniería de usabilidad: desarrollo basado en escenarios de interacción humano
computadora. Editores Morgan Kaufmann, octubre de 2001.
Shneiderman, B., Diseño de la interfaz de usuario: estrategias para una interacción humana eficaz
Interacción informática, segunda edición, AddisonWesley Publishing Company, Reading, MA, 1992.
19
Departamento de Educación de EE.UU. Manual del equipo. Washington: Departamento de Educación,
1997.
Virzi, R. 1992, "Refinando la fase de prueba de la evaluación de la usabilidad: ¿Cuántos sujetos hay
¿Suficiente?" Factores humanos, 34, págs. 457468.
Woods, David D. “Dirigir las repercusiones del cambio tecnológico en los campos de
Práctica: Leyes que rigen el trabajo cognitivo”. Discurso Plenario: Reunión Anual de la Sociedad
de Ciencias Cognitivas, agosto de 2002.
20
Anexo 1
Ejemplo de escala de calificación de usabilidad
Instrucciones: utilice la siguiente escala para calificar las características generales del instrumento CAPI.
Ingrese solo una "X" en cada fila. Tenga en cuenta que una calificación de "1" es buena y un "6" es mala.
“Bueno” <<>> “Malo”
1 2 3 4 5 6
1. Saber qué pregunta leer al encuestado. Claro Confuso
2. Claridad de las instrucciones FR (texto Claro Confuso

azul)
3. Claridad de los mensajes "emergentes" (ediciones Claro Confuso
blandas y duras)
4. Determinar respuestas válidas para las Fácil Duro
preguntas.
5. Ubicar el cursor en cada pantalla. Fácil Duro
6. Corrección de errores en la misma pantalla. Fácil Duro
7. Copia de seguridad para corregir errores en otro Fácil Duro

pantalla.
8. Uso de las teclas de función. Cómodo Incómodo
9. Usando las teclas de flecha. Cómodo Incómodo
10. Diseño general de la pantalla. Claro Confuso
11. Entrada de datos generales. Fácil Duro
12. Velocidad general entre pantallas. Rápido Lento
13. Velocidad general entre espacios de Rápido Lento

respuesta en la misma pantalla.
14. Navegación general a lo largo del Fácil Duro
instrumento.
15. Capacidad general para usar el Cómodo Incómodo
instrumento.
16. Aprender a utilizar este instrumento. Fácil Duro
21
Anexo 2
Resumen de las calificaciones de la escala de usabilidad para 3 pruebas internas y 2 de campo
1 6
“Bueno” <<>> “Malo”
Medio
Artículo clasificado
Vestido
Prueba 1 Prueba 2 Prueba 3 Prueba de campo Ensayo
Velocidad general entre pantallas 1,6 5,5 4,5 4,9 3.8

Corrección de errores Navegación 3,2 3,6 2,7 3,7 3.7
general a través del instrumento Capacidad general 2,3 3,1 2,1 3,4 3.0
2,2 3,1 2,1 2,9 *
para controlar el instrumento Diseño general de la
pantalla Encontrar categorías de respuesta para una 2,1 2,4 1,9 2,8 2,1
pregunta Uso general del instrumento Ingreso general 2,5 2,0 1,9 2,3 2,3
de datos Uso de teclas de función Saber qué leer al 1,7 2,8 1,8 2,9 2,4
encuestado Aprender Windows/Blaise Claridad de FR 2,0 2,6 1,7 2,7 2,4
instrucciones Capacitación de Windows/Blaise para esta 2,5 2,3 1,7 2,7 2,7
prueba Ubicación del cursor en cada pantalla Uso de 2,0 2,2 1,6 2,0 1,7
1,7 2,2 1,6 2,7 *
las teclas de flecha Ediciones Utilidad de las pantallas
de ayuda Facilidad de uso de CE instr. Comparado con 2,2 2,1 1,6 2,7 1.9
1,7 1,9 1,6 2,8 *
DOS Uso de las teclas de avance y retroceso de página
Número de repeticiones de campo Media general 2,8 2,4 1,5 2,5 2,0
1,8 1,9 1,4 2,2 2,1
* * * 3,5 2,8
* * * 3,5 *
* * * 3,2 *
* * * 2,4 *
12 12 12 47 147
2.2 2.7 2.0 2,9 2.5
* Pregunta no hecha en la prueba.
Anexo 3: Pasos sugeridos en una prueba de usabilidad.
Al usar las dos primeras opciones, se puede realizar una prueba de usabilidad implementando los siguientes
pasos sugeridos (para obtener una descripción más completa de las pruebas de usabilidad, consulte
Dumas y Redish, 1999):
1. Planifique la prueba.
• Determinar los objetivos de usabilidad para la prueba. ¿Qué es el comportamiento esperado o deseado?
Por ejemplo, en una entrevista de diario realizada por teléfono, un comportamiento deseado sería
que el entrevistador pudiera ingresar información a un ritmo de conversación normal. • Determinar
cuántos y cuáles entrevistadores participarán en la prueba. • Determine dónde se realizará la prueba
14
y cuánto costará. • Determinar cuántas pruebas se requerirán durante el ciclo de desarrollo y cuánto
tiempo debe pasar entre las pruebas.
• Determinar qué funcionalidad se probará en cada prueba. • Desarrolle
un protocolo de información (lista de preguntas a discutir y reglas básicas para la participación). •
Desarrollar escalas de evaluación/calificación para obtener retroalimentación estructurada y
comparar calificaciones a lo largo del ciclo de desarrollo.
2. Desarrolle escenarios de prueba.15
• Use recorridos de entrevistas simuladas realizadas por el capacitador para explicar
funcionalidad y proporcionar formación básica.
• Use entrevistas con guión completo con entrevistas en pares16 para controlar datos específicos
caminos de entrada.
• Utilice entrevistas semiestructuradas con entrevistas en parejas para guiar al entrevistador a través
de ciertas secciones y situaciones del instrumento.
• Use entrevistas no estructuradas para permitir que el entrevistador explore los problemas
de usabilidad individualmente. • Pruebe los escenarios con anticipación para determinar
el tiempo y descubrir problemas imprevistos.
3. Realice la prueba de usabilidad. •
Desarrollar la agenda. • Haga
que un facilitador capacitado dirija la prueba. •
Haga que observadores capacitados observen, escuchen y tomen notas.
14
Algunos investigadores argumentan que 5 son suficientes para cada población de usuarios (Virzi, 1992; Nielsen, 2000).
Idealmente, los participantes deberían tener experiencia en la encuesta, o una encuesta de naturaleza similar. Se pueden utilizar
más participantes para garantizar la representación de diferentes regiones del país.
15
Véase Rosson y Carroll (2001).
En una entrevista por parejas, un entrevistador desempeña el papel de entrevistador. Otros entrevistadores o participantes son
dieciséis
proporcionado con guiones u hojas informativas y desempeñar el papel de encuestado.
• Empareje a los entrevistadores. Haga que un entrevistador desempeñe el papel de "entrevistador",
mientras que el otro miembro de la pareja actúa como demandado.
• Refuerce el punto de que se está probando el software, no el entrevistador.
4. Lleve a cabo un informe.
• Pida a los participantes que completen los formularios de evaluación antes de la discusión (el
la discusión subsiguiente puede hacer que los entrevistadores cambien sus impresiones o
cuestionen sus reacciones). • Dé a los participantes la oportunidad de expresar sus reacciones.
• Es importante que el facilitador dirija y se mantenga neutral en palabras y lenguaje corporal.
5. Preparar un informe resumido. •
Haga una lista de los problemas que tuvieron los
entrevistadores. • Ordenar los problemas por prioridad y
frecuencia. • Desarrollar soluciones. • Si no se pueden
realizar cambios en futuros prototipos, asegúrese de explicar por qué a los entrevistadores.
24
Anexo 4
Matriz de patrones para el análisis factorial de la escala de usabilidad
Factor 1 Factor 2 Factor 3 Factor 4

Saber qué pregunta leer al encuestado. .099 .035 .826 .062
Claridad de las instrucciones FR (texto azul) .003 .016 .658 .016

Claridad de los mensajes "emergentes" (ediciones .009 .064 .456 .306
blandas y duras)
Determinar respuestas válidas para las .076 .004 .246 .544
preguntas.
Ubicar el cursor en cada pantalla. .280 .069 .421 .046
Corrección de errores en la misma pantalla. .224 .213 .088 .466
Copia de seguridad para corregir errores en otro .315 .160 .015 .645
pantalla.
Uso de las teclas de función. .484 .093 .026 .279

Usando las teclas de flecha. .414 .021 .252 .112
Diseño general de la pantalla. .601 .064 .436 .263
Entrada de datos generales. .559 .269 .338 .293
Velocidad general entre pantallas. .089 .871 .017 .005
Velocidad general entre espacios de respuesta en la .042 .992 .089 .008
misma pantalla.
Navegación general por todo el instrumento. .573 .088 .068 .228
Capacidad general para utilizar el instrumento. .840 .025 .107 .078

Aprendiendo a utilizar este instrumento. .800 .084 .069 .036
25

Enfoques para Incorporar El Diseño Centrado en El Usuario en El Desarrollo de CAI

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Enfoques para Incorporar El Diseño Centrado en El Usuario en El Desarrollo de CAI

Cargado por

Copyright:

Formatos disponibles

Machine Translated by Google

2. Claridad de las instrucciones FR (texto Claro Confuso

6. Corrección de errores en la misma pantalla. Fácil Duro

7. Copia de seguridad para corregir errores en otro Fácil Duro

8. Uso de las teclas de función. Cómodo Incómodo

9. Usando las teclas de flecha. Cómodo Incómodo

10. Diseño general de la pantalla. Claro Confuso

11. Entrada de datos generales. Fácil Duro

12. Velocidad general entre pantallas. Rápido Lento

13. Velocidad general entre espacios de Rápido Lento

Velocidad general entre pantallas 1,6 5,5 4,5 4,9 3.8

Factor 1 Factor 2 Factor 3 Factor 4

Claridad de las instrucciones FR (texto azul) .003 .016 .658 .016

Uso de las teclas de función. .484 .093 .026 .279

Navegación general por todo el instrumento. .573 .088 .068 .228

Capacidad general para utilizar el instrumento. .840 .025 .107 .078

También podría gustarte

Enfoques para Incorporar El Diseño Centrado en El Usuario en El Desarrollo de CAI

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Enfoques para Incorporar El Diseño Centrado en El Usuario en El Desarrollo de CAI

Cargado por

Copyright:

Formatos disponibles

Machine Translated by Google

2. Claridad de las instrucciones FR (texto Claro Confuso

6. Corrección de errores en la misma pantalla. Fácil Duro

7. Copia de seguridad para corregir errores en otro Fácil Duro

8. Uso de las teclas de función. Cómodo Incómodo

9. Usando las teclas de flecha. Cómodo Incómodo

10. Diseño general de la pantalla. Claro Confuso

11. Entrada de datos generales. Fácil Duro

12. Velocidad general entre pantallas. Rápido Lento

13. Velocidad general entre espacios de Rápido Lento

Velocidad general entre pantallas 1,6 5,5 4,5 4,9 3.8

Factor 1 Factor 2 Factor 3 Factor 4

Claridad de las instrucciones FR (texto azul) .003 ­.016 .658 ­.016

Uso de las teclas de función. .484 .093 ­.026 .279

Navegación general por todo el instrumento. .573 .088 .068 .228

Capacidad general para utilizar el instrumento. .840 ­.025 ­.107 .078

También podría gustarte

Claridad de las instrucciones FR (texto azul) .003 .016 .658 .016

Uso de las teclas de función. .484 .093 .026 .279

Capacidad general para utilizar el instrumento. .840 .025 .107 .078