El documento describe la importancia de conocer a los usuarios al diseñar un producto. Se debe estudiar las características individuales y diversidad de tareas de los usuarios mediante visitas al cliente, cuestionarios y observación. También es necesario analizar las tareas de los usuarios para comprender sus objetivos, flujos de trabajo y necesidades de información. El análisis funcional es clave para mejorar las tareas más allá de limitaciones tecnológicas previas y anticipar cómo los usuarios y sus necesidades pueden evolucionar con el tiempo.

1. Conocer al Usuario
El primer paso en el proceso de la usabilidad es el estudio de los usuarios y del uso del
producto. Como mínimo, los desarrolladores deben visitar al cliente para que tengan
una idea de cómo se usará el producto. Las características individuales de los usuarios
y la diversidad en las tareas son los dos factores con mayor impacto en la usabilidad,
por lo que necesitan ser estudiados cuidadosamente. Al considerar a los usuarios, se
debe tener en cuenta que a menudo incluye varios elementos que fungen como
personal de apoyo. El concepto de "usuario" debe ser definido para incluir a todo el
mundo cuyo trabajo se ve afectado por el producto de alguna manera, incluyendo los
usuarios del producto final, incluso si nunca ven una sola pantalla.
A pesar de que "conocer al usuario" es la más básica de todas las directrices de
usabilidad, a menudo es difícil para los desarrolladores obtener acceso a los usuarios.
Grudin [199Gb, 1991a yb] analiza los obstáculos a dicho acceso, incluyendo:
 La necesidad de la compañía de desarrollo de proteger a sus desarrolladores de
ser conocidos por los clientes, haciendo que estos últimos los contacten directamente
desviándolos de su trabajo principal.
 La renuencia de los representantes de ventas para permitir que alguien más
charle con "sus" clientes, por temor a que los desarrolladores puedan ofender al
cliente o crear insatisfacción con la actual generación de productos.
 Las organizaciones de usuarios solamente haciendo los usuarios disponibles por
poco tiempo, ya sea porque están muy bien pagados ejecutivos o porque están
sindicalizados y desagrado en estudio.
Todos estos problemas son reales y deben ser abordados cuando se trata de llegar a
"conocer al usuario." No hay soluciones universales disponibles, excepto recomendar
un esfuerzo explícito para tener acceso directo a los usuarios representativos y no
estar satisfecho con el acceso indirecto a estos y rumores. Es increíble la cantidad de
tiempo que se desperdicia en ciertos proyectos de desarrollo por discutiendo sobre lo
que los usuarios podría gustarles o lo que es posible que quieran hacer. En lugar de
discutir estas cuestiones, es mucho mejor (y en realidad toma menos tiempo) obtener
los datos de los propios usuarios.
Características Individuales de los Usuarios
Es necesario conocer el de personas que van a utilizar el sistema. En algunas
situaciones esto es fácil puesto que es posible identificar estos usuarios como
individuos concretos. Este es el caso cuando el producto se va a utilizar en un
departamento específico en una empresa en particular. Para otros productos, los
usuarios pueden estar tan dispersos que solo es posible visitar a pocos usuarios
representativos. Alternativamente, los productos podrían estar dirigidos hacia toda la
población o a un gran subconjunto.
Al conocer de los usuarios su experiencia laboral, nivel educativo, edad, experiencia
previa en el uso de computadoras, entre otros, es posible anticiparse a sus dificultades
de aprendizaje, para mejor establecer de mejor manera límites adecuados para la
complejidad de la interfaz de usuario.

2. Ciertamente uno también tiene que conocer las habilidades de lectura y lingüísticas de
los usuarios. Por ejemplo, los niños muy pequeños no tienen la capacidad de lectura,
por lo que se requiere una interfaz totalmente no – textual. Además, se debe saber la
cantidad de tiempo que los usuarios tendrán a su disposición para el aprendizaje y si
van a tener la oportunidad de asistir a cursos de formación: La interfaz se debe hacer
mucho más simple si se espera que los usuarios la utilicen con una formación mínima.
También tienen que ser conocidos de los usuarios su entorno de trabajo y contexto
social. Como un simple ejemplo, el uso de alarmas sonoras, "pitidos", o efectos de
sonido pueden no ser apropiado para los usuarios en entornos de oficina abiertos. En
una entrevista de campo una vez lo hice, una secretaria se quejó exigiendo la
capacidad de apagar el pitido porque ella no quería que los otros pensaran que ella era
estúpida porque su equipo sonaba todo el tiempo. Una gran parte de la información
necesaria para caracterizar los usuarios individuales puede provenir de análisis de
mercado o de los estudios de observación que se pueden llevar a cabo como parte del
análisis de tareas. También se puede recoger dicha información directamente a través
de cuestionarios o entrevistas. En cualquier caso, lo mejor es no depender totalmente
de la información escrita, y obtener nuevos puntos de vista observando y hablando
con los usuarios reales en su propio entorno de trabajo.
Análisis de Tareas
Un análisis de tareas es esencial, tan pronto se inicie el diseño del sistema. Las metas
de los usuarios deben ser estudiadas, así como el enfoque actual para ejecutar sus
tareas, sus necesidades de información, y cómo hacen frente a circunstancias
excepcionales o de emergencia. Por ejemplo, la observación sistemática de los
usuarios hablando con sus clientes puede revelar necesidades de entrada y salida de
un sistema de procesamiento de transacciones. A veces, las entrevistas o la
observación de los clientes de los usuarios o de otras personas que interactúan con
ellos pueden proporcionar información adicional para el análisis de las tareas
El modelo que tienen los usuarios sobre sus tareas también debe ser identificado, ya
que puede ser utilizado como una fuente de metáforas para la interfaz de usuario.
También, se debe buscar y observar especialmente a usuarios eficaces, sus estrategias
y "soluciones" como consejos de lo que un nuevo sistema podría apoyar. Tales
usuarios son a menudo una fuente importante de innovaciones.
Por último, se debe identificar las debilidades de la situación actual: los puntos donde
los usuarios no logran alcanzar las metas, pasan tiempo excesivo, o su trabajo se hace
incómodo. Estas debilidades presentan oportunidades para mejoras en el nuevo
producto. Un resultado típico de un análisis de tareas es una lista de todas las cosas
que los usuarios quieren lograr con el sistema (las metas), toda la información que se
necesita para lograr estos objetivos (las condiciones previas), los pasos que se deben
realizar y la interdependencias entre estos pasos, todos los diversos resultados e
informes que deben generarse, los criterios utilizados para determinar la calidad y
aceptabilidad de estos resultados, y finalmente las necesidades de comunicación de los
usuarios, mientras intercambian información con otras personas en el desempeño de
la tarea o cuando se preparan para hacerla.
Al entrevistar a los usuarios con el fin de recoger información sobre sus tareas,
siempre es una buena idea pedirles que muestren ejemplos concretos de lo que su

3. trabajo produce, en lugar de mantener una discusión en un nivel abstracto. Además, es
preferible que se complementen esas entrevistas con la observación de algunos
usuarios trabajando en problemas reales, ya que los usuarios a menudo suelen
racionalizar sus acciones o se olvidan de detalles importantes cuando son
entrevistados.
A menudo, un análisis de tareas se puede descomponer de forma jerárquica, a partir
de las tareas y los objetivos de la organización globales y dividir las en tareas
secundarias más pequeñas, que pueden subdividirse nuevamente. Por lo general, cada
vez que un usuario dice, "entonces, hago esto", un entrevistador podría hacer dos
preguntas: "¿Por qué lo haces?" (Relacionar la actividad con las metas más grandes) y
"¿Cómo lo haces?" (Para descomponer la actividad en tareas secundarias). Otras
buenas preguntas para hacer incluyen, "¿por qué no lo hace de tal manera?"
(Mencionando algunos enfoques alternativos), "Los errores siempre ocurren cuando se
hace esto?," y "¿Cómo se puede descubrir y corregir estos errores?".
Por último, los usuarios deben describir las anomalías o irregularidades en su flujo de
trabajo normal. A pesar de que es posible que estos recuerden todas las anomalías que
siempre ocurren y de que será imposible predecirlas, es muy significativo tener una
lista que refleje la gama de irregularidades que deben ser acomodadas. A los usuarios
también se les debe pedir información sobre los casos de éxitos y fracasos notables, lo
que más y menos les gusta, qué cambios les gustaría, qué ideas tienen para mejoras, y
lo que actualmente les molesta. A pesar de que no todas esas sugerencias pueden ser
seguidas en el diseño final, son una rica fuente de inspiración.
Análisis Funcional
Un nuevo sistema informático no debe ser diseñado simplemente para propagar
formas subóptimas de hacer las cosas que pueden haber sido instituidos por las
limitaciones de las tecnologías anteriores. Por lo tanto, no hay que analizar sólo la
forma en que los usuarios actualmente hacen la tarea, sino también la razón funcional
subyacente para la tarea: ¿Qué es lo que realmente hay que hacer, y cuales son los
procedimientos meramente superficiales que pueden, y tal vez deberían, ser
cambiados.
Por ejemplo, muchos proyectos en el campo de trabajo cooperativo asistido por
ordenador (CSCW) asumen que la interacción cara a cara es lo último en comunicación
y que las computadoras deberían emular la realidad física próxima (PPR) lo más cerca
posible. Por el contrario, el enfoque "más allá de estar ahí" [Hollan y Stornetta 1992;
Brothers et al. 1992] separa las necesidades de la comunicación humana desde los
medios de comunicación a través del cual se ha logrado hasta el momento.
Herramientas de comunicación computarizados pueden ser construidas para
aprovechar los puntos fuertes del soporte informático, como la asincronía, el
anonimato, archivos de búsqueda, y las respuestas automáticas y filtros, incluso si los
mecanismos de comunicación resultantes no se asemejan a la forma de hablar cuando
están en el misma habitación.
Como un ejemplo más mundano, las observaciones iniciales de la gente que lee los
manuales impresos muestran con frecuencia el pasar de las páginas para moverse por
el documento. Un diseño ingenuo de documentación en línea podría tomar esta
observación para implicar mecanismos de desplazamiento muy bueno y rápido. Un

4. análisis funcional mostraría que los usuarios manuales realmente pasan las páginas de
para encontrar información específica, pero tienen dificultades para localizar la página
correcta. Sobre la base de este análisis, se podría diseñar una interfaz de
documentación en línea que primero les permita especificar sus necesidades de
búsqueda, a continuación, utilizar un esquema del documento para que aparezcan las
partes con altos puntajes de búsqueda y que los usuarios finalmente salten
directamente a estas partes, destacando sus términos de búsqueda para que sea más
fácil juzgar la pertinencia de la información. Por supuesto, hay un límite para cambiar
drásticamente la forma en que los usuarios toman su tarea actualmente, por lo que el
análisis funcional debe ser coordinado con un análisis de tareas.
La Evolución del Usuario
Los usuarios no seguirán igual. El uso del sistema cambia a los usuarios, y a medida que
cambian utilizaran el sistema en nuevas formas. Carroll y Rosson [1991] se refieren a
este fenómeno dialéctico como la "co-evolución de las tareas y artefactos." Por
ejemplo, las hojas de cálculo se inventaron inicialmente como ayudas para el cálculo,
pero al tener al alcance una herramienta computarizada tan flexible, se animaron a
integrar otros tipos de datos en una hoja de cálculo. Los usuarios a menudo se han
caracterizado por utilizar hojas de cálculo para las bases de datos [Nielsen et al. 1986],
y estos y otros usos han llevado a los proveedores de hoja de cálculo a incluir
características extras en versiones posteriores.
Es imposible prever estos cambios por completo ya que los usuarios siempre podrán
descubrir nuevos usos para los sistemas informáticos tras un período de uso, pero un
diseño flexible tendrá una mejor oportunidad de apoyar a estos nuevos usos. Trate de
hacer una conjetura en base a su conocimiento acerca de cómo otros usuarios han
cambiado en el pasado. Una forma de obtener este conocimiento es a través de los
estudios de campo posteriores a la implementación discutidos en la página 109.
Un cambio típico sucede cuando los usuarios se convierten en expertos después de un
tiempo y quieren atajos de interacción (a veces llamados aceleradores). Por ejemplo,
un paquete de gráficos de negocios puede llevar a los usuarios novatos a través de una
serie de pantallas de pregunta – respuesta para especificar las principales
características de los tipos de gráficos, pero los usuarios expertos, probablemente
querrán ser capaces de cambiar las tablas por la manipulación directa y tal vez incluso
tener acceso a un tipo de lenguaje de programación especializado para la construcción
de gráficos. Es importante no sólo diseñar para ese espacio inicial y corto de tiempo
justo después del lanzamiento del producto.