Guias_de_Interfaz_de_Usuario_v1_01

Vista previa del material en texto

Guías de Interfaz de Usuario - Diseño de Sistemas 
Autor: E. Porta Versión : 1.01 [11/05/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 1/30 11/05/2010 23:25:00 
Guías de Interfaz de Usuario 
Diseño de Sistemas 
 
 
 
 
1. Índice 
1. Índice .................................................................................................................................. 1 
2. Introducción ........................................................................................................................ 3 
2.1. Propósito del documento ................................................................................................ 3 
2.2. Alcance del documento................................................................................................... 3 
2.3. Definiciones, abreviaturas y acrónimos .......................................................................... 3 
2.4. Documentos relacionados .............................................................................................. 3 
2.5. Visión general del documento ........................................................................................ 4 
3. Concepto: Diseño centrado en el usuario .......................................................................... 5 
3.1. ¿Qué es el diseño centrado en el usuario? .................................................................... 5 
3.1.1. Atención en los usuarios ......................................................................................... 5 
3.1.2. Integrado con diseño ............................................................................................... 5 
3.1.3. Pruebas de usuario tempranas ............................................................................... 6 
3.1.4. Diseño iterativo ........................................................................................................ 6 
3.2. ¿Por qué un diseño centrado en el usuario?.................................................................. 6 
3.2.1. Satisfacción de las necesidades del usuario........................................................... 6 
3.2.2. Diseño de la interfaz de usuario .............................................................................. 7 
3.2.3. Legislación y estándares ......................................................................................... 8 
3.2.4. Diseño centrado en el usuario en RUP ................................................................... 9 
3.2.5. Contextos de uso................................................................................................... 10 
4. Artefacto: Prototipo de interfaz de usuario ....................................................................... 12 
4.1. Quién lo utiliza y para que se utiliza ............................................................................. 12 
4.2. Opciones de representación......................................................................................... 12 
5. Artefacto: Mapa de Navegación ....................................................................................... 13 
5.1. Objetivo ......................................................................................................................... 13 
5.2. Descripción ................................................................................................................... 13 
5.3. Opciones de representación......................................................................................... 13 
5.4. Ejemplo ......................................................................................................................... 13 
6. Directriz: Interfaz de usuario (General) ............................................................................ 15 
6.1. Fundamentos de las ventanas: Establecer el contexto ................................................ 15 
6.1.1. Ventana principal (Primary Windows) ................................................................... 15 
6.1.2. Compuestos........................................................................................................... 15 
6.1.3. Ventana secundaria (Secondary Windows) .......................................................... 15 
6.2. Dimensiones visuales ................................................................................................... 16 
6.2.1. Posición ................................................................................................................. 17 
6.2.2. Tamaño.................................................................................................................. 18 
6.2.3. Forma .................................................................................................................... 18 
6.2.4. Color ...................................................................................................................... 19 
6.2.5. Identificación.......................................................................................................... 20 
6.3. Buscar y Seleccionar .................................................................................................... 20 
6.4. Orden ............................................................................................................................ 21 
6.5. Jerarquías de navegación............................................................................................. 21 
6.6. Gestión de ventanas ..................................................................................................... 21 
6.7. Información de la sesión ............................................................................................... 22 
6.8. Ayuda en línea .............................................................................................................. 23 
6.9. Deshacer....................................................................................................................... 24 
6.10. Agente de macros ..................................................................................................... 24 
7. Directriz: Storyboard......................................................................................................... 25 
7.1. Introducción .................................................................................................................. 25 
7.2. Beneficios de los storyboards....................................................................................... 25 
7.3. Representación de storyboards.................................................................................... 25 
7.4. Herramientas para la creación de storyboards............................................................. 26 
 
Guías de Interfaz de Usuario - Diseño de Sistemas 
Autor: E. Porta Versión : 1.01 [11/05/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 2/30 11/05/2010 23:25:00 
7.5. Advertencias y comentarios.......................................................................................... 27 
7.6. Quienes utilizan los storyboards................................................................................... 27 
8. Concepto: Prueba de usabilidad ...................................................................................... 28 
8.1. Modos de exponer el diseño......................................................................................... 28 
8.2. Ventajas de exponer el diseño a varios interesados .................................................... 28 
8.2.1. Otros miembros del proyecto ................................................................................29 
8.2.2. Expertos en usabilidad .......................................................................................... 29 
8.2.3. Diseño para usuarios............................................................................................. 29 
8.3. Más información............................................................................................................ 29 
9. Historia de Versiones del documento............................................................................... 30 
 
 
Guías de Interfaz de Usuario - Diseño de Sistemas 
Autor: E. Porta Versión : 1.01 [11/05/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 3/30 11/05/2010 23:25:00 
2. Introducción 
2.1. Propósito del documento 
Describir las guías relacionadas con la interfaz de usuario dentro del proceso de 
desarrollo de software y ser utilizado como material de consulta en la asignatura Diseño de 
Sistemas. 
 
2.2. Alcance del documento 
Las consignas de este documento aplican a todos los alumnos de la asignatura Diseño 
de Sistemas de la carrera de Ingeniería en Sistemas de Información dictada en la Universidad 
Tecnológica Nacional - Facultad Regional Rosario. 
 
2.3. Definiciones, abreviaturas y acrónimos 
RUP � Rational Unified Process® (RUP®). Proporciona recomendaciones y sirve de 
guía para llevar a cabo un desarrollo de software correcto. RUP es un producto que esta 
incluido en la aplicación IBM® Rational® Method Composer (RMC). En este documento se 
utilizó Rational Unified Process® Versión 7.0.1. 
 
RMC � La aplicación IBM® Rational® Method Composer (RMC) es una herramienta 
de publicación y personalización de procesos. RMC le ayuda a personalizar RUP para los 
requisitos precisos de su empresa al optimizar su experiencia, prácticas y conocimiento interno. 
En este documento se utilizó Rational Method Composer Versión 7.2.0. 
 
Copyrights 
IBM, RUP(Rational Unified Process) y Rational son marcas registrada de IBM 
Corporation, en los EEUU, otros países o ambos. 
 
 
 
2.4. Documentos relacionados 
 
Documento Nombre / Ubicación del archivo Fuente 
Introducción al 
Proceso Unificado 
Nombre: 
Introduccion_al_Proceso_Unificado 
 
 
Ubicación: 
http://es.groups.yahoo.com/group/ds_utn_rosario/files/ 
Cátedra Diseño 
de Sistemas - 
UTN Regional 
Rosario 
Disciplina Análisis y 
Diseño 
Nombre: 
Disciplina_Analisis_y_Diseño 
 
 
Ubicación: 
http://es.groups.yahoo.com/group/ds_utn_rosario/files/ 
Cátedra Diseño 
de Sistemas - 
UTN Regional 
Rosario 
 
 
Guías de Interfaz de Usuario - Diseño de Sistemas 
Autor: E. Porta Versión : 1.01 [11/05/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 4/30 11/05/2010 23:25:00 
2.5. Visión general del documento 
 
El objetivo de este documento es definir los conceptos claves de Interfaz de Usuario. 
 
Se basó en la documentación técnica sobre las diversas prácticas recomendadas en 
Rational Unified Process®, pero se le hicieron adaptaciones para la asignatura Diseño de 
Sistemas. 
 
En el apartado 3 se define el concepto “Diseño centrado en el usuario”. El diseño 
centrado en el usuario es el diseño de aplicaciones que tiene en cuenta las necesidades y la 
efectividad del usuario final como prioridad. 
 
En el apartado 4 se define el artefacto “Prototipo de interfaz de usuario”. El prototipo de 
interfaz de usuario se utiliza para explorar y/o validar el diseño de la interfaz de usuario. 
 
En el apartado 5 se define el artefacto “Mapa de Navegación”. Este artefacto describe 
la estructura de los elementos de interfaz de usuario del sistema, junto con las vías de 
navegación potenciales. 
 
En el apartado 6 se define la directriz “Interfaz de usuario (General)”. En esta sección 
se proporciona una visión general de la anatomía de una interfaz de usuario basada en 
ventanas. Esta visión general es necesaria para comprender el resto de directrices. 
 
En el apartado 7 se define la directriz “Storyboard”. Un storyboard es una descripción 
lógica y conceptual de la funcionalidad del sistema, para un escenario o grupos de escenarios 
específicos. 
 
En el apartado 8 se define el concepto “Prueba de usabilidad”. La prueba de usabilidad 
es un método mediante el cual se le solicita a los usuarios representantes de un producto que 
realicen determinadas tareas en un esfuerzo por medir la facilidad de uso, el tiempo que 
necesita la tarea y la percepción que tiene el usuario de la experiencia de la interfaz de usuario. 
 
 
 
 
 
 
 
Guías de Interfaz de Usuario - Diseño de Sistemas 
Autor: E. Porta Versión : 1.01 [11/05/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 5/30 11/05/2010 23:25:00 
3. Concepto: Diseño centrado en el usuario 
 
El diseño centrado en el usuario es el diseño de aplicaciones que tiene en 
cuenta las necesidades y la efectividad del usuario final como prioridad. 
 
3.1. ¿Qué es el diseño centrado en el usuario? 
No existe un consenso claro sobre qué constituye el diseño centrado en el 
usuario. Sin embargo, John Gould y sus compañeros de IBM desarrollaron una 
propuesta en la década de 1980 llamada Diseño para la usabilidad que incluye las 
definiciones aceptadas más comúnmente. Lo desarrollaron a partir de una experiencia 
práctica en una serie de sistemas interactivos, más notablemente, el sistema de 
mensajería Olympic de IBM de 1984. La propuesta tiene cuatro componentes 
principales, como se describen a continuación. 
 
3.1.1. Atención en los usuarios 
Gould sugiere que los desarrolladores deberían decidir quiénes serán los 
usuarios e involucrarlos lo antes posible. También propone una serie de maneras de 
familiarizarse con los usuarios, sus tareas y requisitos: 
Hablar con los usuarios. 
Visitar las instalaciones de los clientes. 
Observar el trabajo de los usuarios. 
Grabar en vídeo el trabajo de los usuarios. 
Conocer la organización del trabajo. 
Probarlo uno mismo. 
Hacer que los usuarios piensen en voz alta mientras trabajan. 
Diseño participativo. 
Incluir usuarios expertos en el equipo de diseño. 
Realizar análisis de las tareas. 
Utilizar encuestas y cuestionarios. 
Desarrollar objetivos que se puedan probar. 
 
En RUP los talleres se utilizan en varios estadios clave, pero deben 
complementarse con los tipos de actividades que describe Gould para poder crear una 
imagen precisa. 
Parte del argumento que se esconde detrás de esto, es que las personas 
suelen describir lo que hacen de una forma bastante diferente a como lo hacen. Por lo 
general, se olvidan tareas realizadas comúnmente, y de detalles que no parecen 
importantes, como la localización del trabajo o la existencia de "misteriosos" trozos de 
papel, o se omiten porque, "oficialmente" no forman parte del proceso actual. 
 
3.1.2. Integrado con diseño 
Las tareas de usabilidad deben realizarse en paralelo desde el principio del desarrollo. 
Estas tareas incluyen los bocetos (sketching) de la interfaz de usuario y el borrador de 
las guías de usuario o la ayuda en línea. Gould también resalta que la usabilidad 
debería ser responsabilidad de un grupo. 
Una característica importante del diseño integrado es que el enfoque general (el 
Framework) del diseño detallado de la interfaz de usuario se desarrolla y se prueba en 
un estadio temprano. Esta es una diferencia importante entre el diseño centrado en el 
usuario y otras técnicas puramente incrementales. Garantiza que el diseñoincremental 
que se lleva a cabo en las fases posteriores encaje perfectamente en el Framework, y 
 
Guías de Interfaz de Usuario - Diseño de Sistemas 
Autor: E. Porta Versión : 1.01 [11/05/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 6/30 11/05/2010 23:25:00 
que la interfaz de usuario sea consistente en cuanto al aspecto, la terminología y el 
concepto. 
En RUP, este Framework se puede establecer utilizando un modelo de dominio para 
asegurar que toda la terminología y los conceptos que aparecen en la interfaz de 
usuario son conocidos y comprendidos en el negocio en general y para los usuarios en 
particular. (También habrá subconjuntos del modelo de dominio relevantes únicamente 
para grupos de usuarios específicos. Debería ponerse cuidado para que el modelo de 
dominio esté organizado de forma que estos subconjuntos se puedan identificar con 
facilidad). A medida que el diseño de la interfaz de usuario avanza, muchas clases del 
dominio se representarán como elementos de la interfaz de usuario. Los elementos de 
la interfaz de usuario, y las relaciones entre ellos, deberían ser consistentes con el 
modelo de dominio y representarse de forma consistente en todas las partes del 
sistema que se está diseñando. (Esto no ayuda únicamente a los usuarios, sino que 
mejora la reutilización de los componentes de la interfaz de usuario). 
3.1.3. Pruebas de usuario tempranas 
Las pruebas de usuario tempranas consisten en la creación de los primeros 
storyboards y el desarrollo temprano de prototipos de baja fidelidad (Un storyboard es 
una descripción lógica y conceptual de la funcionalidad del sistema, consulte directriz 
Storyboard). Los prototipos de alta fidelidad se crean cuando el proceso está más 
avanzado. 
Los storyboards se pueden utilizar en conjunción con casos de uso para escribir 
escenarios de utilización concretos para el sistema que se está diseñando. Los 
storyboards pueden ser narrativos, ilustrados (utilizando los bocetos de la interfaz de 
usuario para las ilustraciones); los guiones gráficos, los ensayos (con usuarios) y los 
grupos centrados en el usuario son propuestas poco familiares para muchos 
desarrolladores de software. Sin embargo, son más rentables que el descubrimiento de 
diseños inadecuados o requisitos comprendidos incorrectamente cuando la 
implementación está en curso. 
3.1.4. Diseño iterativo 
El desarrollo orientado a objetos se ha convertido en sinónimo de proceso iterativo. El 
diseño iterativo se adapta a los problemas que necesitan un perfeccionamiento de la 
comprensión y tienen requisitos cambiantes. No resulta sorprendente que el diseño 
iterativo sea un componente clave del diseño centrado en el usuario. Esto se debe, en 
parte, a las cambiantes necesidades de los usuarios en el tiempo, pero también a la 
complejidad inherente de la producción de soluciones de diseño que pueden satisfacer 
varias necesidades. 
3.2. ¿Por qué un diseño centrado en el usuario? 
 
3.2.1. Satisfacción de las necesidades del usuario 
Los sistemas repetitivos se basan en su capacidad para acomodar las necesidades de 
los usuarios. Esto no significa únicamente la identificación de varias comunidades de 
usuarios, sino también el reconocimiento del rango de habilidades, experiencia y 
preferencias de los usuarios individuales. 
Es frecuente que los desarrolladores y los gestores crean que comprenden las 
necesidades del usuario, pero este no suele ser cierto en la realidad. Normalmente, la 
atención se centra en cómo deberían realizar las tareas los usuarios, y no en cómo 
prefieren realizarlas. En muchos casos, las preferencias significan algo más que la 
 
Guías de Interfaz de Usuario - Diseño de Sistemas 
Autor: E. Porta Versión : 1.01 [11/05/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 7/30 11/05/2010 23:25:00 
sensación de tener el control, aunque este también es un tema importante. Las 
preferencias vienen determinadas por la experiencia, la capacidad y el contexto de 
utilización. Estos problemas se consideran lo suficientemente importantes en el 
proceso de diseño para garantizar un estándar internacional, [ISO 13407], llamado 
procesos de diseño centrado en el ser humano para sistemas interactivos. El estándar 
y los temas relacionados se tratan, de forma general, en el resto de este documento. 
3.2.2. Diseño de la interfaz de usuario 
Los usuarios conocen e interactúan con un sistema a través de la interfaz de usuario. 
Los conceptos, las imágenes y la terminología que se presenta en la interfaz deben ser 
adecuados a las necesidades del usuario. Por ejemplo, un sistema que permite a los 
clientes comprar sus entradas es muy diferente de un sistema que utiliza de forma 
profesional el personal de venta de entradas. Las principales diferencias no residen en 
los requisitos ni en los casos de uso detallados, sino en las características de los 
usuarios y el entorno en que funcionan los sistemas. 
La interfaz de usuario también debe proporcionar un amplio abanico potencial de 
experiencia en un mínimo de dos dimensiones, experiencia informática y en dominios, 
como se muestra en la Figura 1. La experiencia informática no sólo incluye una 
familiaridad general con los ordenadores, sino también experiencia en el sistema que 
se está desarrollando. Los usuarios que tienen poca experiencia en ordenadores o el 
dominio de problemas, en la esquina izquierda de la figura, requieren un enfoque 
sustancialmente diferente en la interfaz de usuario que los usuarios expertos, en la 
esquina derecha. 
 
 
 
Figura 1: Los efectos de la experiencia informática y en dominios en la facilidad 
de aprendizaje en oposición con la facilidad de uti lización 
 
Sea consciente de que el hecho de que los usuarios sin experiencia se conviertan en 
expertos con el tiempo no es una conclusión inevitable. Existen una serie de factores 
que pueden impedir esto, por ejemplo, una frecuencia de uso baja, una motivación baja 
o una elevada complejidad. En cambio, algunos sistemas pueden tener, 
predominantemente, usuarios expertos. En este caso, los factores pueden ser la 
formación, la frecuencia de uso elevada o la alta motivación (dependencia del trabajo). 
En la tabla 1 se muestran algunos de estos temas y sus efectos sobre la interfaz de 
usuario. 
 
 
Guías de Interfaz de Usuario - Diseño de Sistemas 
Autor: E. Porta Versión : 1.01 [11/05/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 8/30 11/05/2010 23:25:00 
 Baja Alta 
Experiencia en 
informática 
Esquema de preguntas y 
respuestas simples, llenado de 
formularios simples, estilo de 
interfaz de menú o Web (con 
hipervínculos) 
Llenado de formularios complejos, 
estilo de interfaz de menús o Web 
(con hipervínculos) (el esquema de 
preguntas y respuestas y el llenado 
de formularios simples sería muy 
frustrante para los usuarios con 
experiencia) 
Experiencia en 
dominios 
Conceptos y terminología común 
Conceptos y terminología 
específicos de dominios 
Formación 
Se centra en la facilidad de 
aprendizaje (coherente, 
previsible, memorable) 
Se centra en la facilidad de uso 
(directo, personalizable, no 
intrusivo) 
Frecuencia de uso Fácil de aprender y recordar, estilo de interfaz simple 
Fácil de utilizar, varios métodos 
abreviados y técnicas que permiten 
el control del usuario 
Motivación Uso gratificante, potente sin parecer complejo 
Sofisticadocon muchas funciones 
avanzadas y personalizables. 
 
Tabla 1. Algunos factores que afectan al diseño de la interfaz de usuario 
 
Los sistemas interactivos deben estar diseñados para adaptarse a un intervalo 
adecuado de circunstancias y niveles de experiencia de usuario, o bien deben 
emprenderse pasos para restringir el universo de diseño. Por ejemplo, se puede 
utilizar la formación para reducir el requisito de facilidad de aprendizaje en un sistema 
complejo. De manera alternativa, se puede reducir el alcance del sistema para que 
satisfaga mejor los requisitos principales de sus usuarios 
 
3.2.3. Legislación y estándares 
 
Como parte de un diseño centrado en el usuario, debemos tener en cuenta las 
habilidades y los atributos físicos de los usuarios. Estas cuestiones están siendo cada 
vez más consideradas por la legislación. Y mayormente apuntando a adaptarse a los 
usuarios con discapacidades. Sin embargo, el hecho de hacer que los sistemas sean 
accesibles para un mayor rango de usuarios suele verse como un beneficio para la 
comunidad de usuarios en su conjunto 
Aparte de la legislación, el diseño centrado en el usuario y el diseño de interfaz de 
usuario se tratan cada vez más como sujetos de estandarización, como se muestra 
abajo. 
Descripción Sitio Web / Estándares 
ANSI www.ansi.org 
ANSI ANSI y la Sociedad de ergonomía y factores 
humanos publicaron una serie de estándares 
 
Guías de Interfaz de Usuario - Diseño de Sistemas 
Autor: E. Porta Versión : 1.01 [11/05/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 9/30 11/05/2010 23:25:00 
ANSI-HFES 
ANSI-NSC 
conjuntos. ANSI también tiene ANSI-NSC Z365, 
que está relacionado con el control y la 
prevención de trastornos de estrés acumulativo 
(también conocidos como daños por tensión 
repetitiva o RSI). 
ANSI está esbozando estándares relacionados 
con la interacción entre la informática y el ser 
humano como parte del panel de estándares de 
infraestructura de la información (IISP). 
ISO www.iso.ch 
ISO 9241 
Gran cantidad de estándares que tratan, 
principalmente, la ergonomía de las estaciones de 
trabajo, pero también incluyen instrucciones de 
utilización (parte 11). También es la base de 
ANSI-HFES 200, que se está desarrollando. 
ISO 10075: 1991 
Principios ergonómicos relacionados con la carga 
de trabajo mental 
ISO 17041-1: 1995 Control del cursor para la edición de texto 
ISO 11581 
Varios en desarrollo relacionados con los iconos y 
los punteros. 
ISO 13407: 1999 
Estándar para procesos de diseño centrados en el 
ser humano para sistemas interactivos. 
 
Tabla 2b, Estándares de diseño centrado en el usuar io y la interfaz de usuario 
 
3.2.4. Diseño centrado en el usuario en RUP 
 
El desarrollo de sistemas adecuados para las necesidades del usuario significa un 
esfuerzo significativo en el análisis de requisitos. En el diseño centrado en el usuario, 
este esfuerzo se centra en los usuarios finales. 
La disciplina de modelado de negocio (o modelado empresarial) cubre el modelado de 
trabajadores que pertenecen al negocio y para los ajenos al negocio. 
Un punto de atención especial en el diseño centrado en el usuario es conocer los 
requisitos de las personas reales que desempeñarán los roles descritos en los 
productos de trabajado mencionados arriba. En particular, debemos evitar el diseño de 
seres humanos hipotéticos para los que es conveniente diseñar sistemas de software. 
Los productos de trabajo que describen usuarios sólo se deben escribir después de un 
contacto directo y sustancial con los usuarios. En el diseño centrado en el usuario, este 
contacto directo forma parte de un proceso que, a veces, se llama consulta contextual. 
Hugh Beyer y Karen Holtzblatt (en su libro Contextual Design, [BEY98]) describen la 
premisa de consulta contextual como: “Ir al lugar de trabajo del cliente, observarlo 
mientras trabaja y hablar con él sobre el trabajo” 
(En 5.1.1. Atención en los usuarios, ya se han listado algunos ejemplos concretos de 
esto). Este enfoque no se utiliza únicamente para comprender mejor los requisitos del 
sistema, sino también a los usuarios, sus tareas y su entorno. Cada uno tiene sus 
propios atributos y, en conjunto, se conocen como contexto de utilización. Los 
 
Guías de Interfaz de Usuario - Diseño de Sistemas 
Autor: E. Porta Versión : 1.01 [11/05/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 10/30 11/05/2010 23:25:00 
requisitos se detallan en el estándar ISO para el diseño centrado en el usuario, que se 
describen más abajo. 
 
3.2.5. Contextos de uso 
 
El estándar procesos de diseño centrado en humanos para sistemas interactivos 
(Human-centered design processes for interactive systems) de ISO [ISO13407] 
identifica el primer paso de diseño como el conocimiento y la especificación del 
contexto de utilización. Los atributos sugeridos son: 
Contexto Atributos 
Tareas Objetivos de utilización del sistema, frecuencia y 
duración de su ejecución, factores de salud y seguridad, 
asignación de actividades, pasos operativos entre los 
recursos tecnológicos y humanos. Las tareas no 
deberían describirse únicamente en términos de las 
funciones o características que proporciona un producto 
o sistema. 
Usuarios (para cada 
rol o tipo diferente) 
Conocimiento, habilidad, experiencia, educación, 
formación, atributos físicos, hábitos, preferencias, 
capacidades. 
Entornos Hardware, software, materiales; entornos físicos y 
sociales, estándares relevantes, entorno técnico, 
entorno ambiental, entorno legislativo, entorno social y 
cultural 
Tabla 3: Contexto de utilización del estándar ISO p ara el diseño centrado en el 
usuario 
Resulta útil dividir el contexto de usuario en las partes constituyentes (tipo y rol de 
usuario) y, después, considerar las relaciones entre los cuatro contextos: 
 
Figura 2: Relaciones entre contextos 
La figura 2 muestra que todas las tareas se realizan en un rol que desempeña un 
usuario en un entorno. Estos contextos se corresponden con los productos de trabajo 
de RUP, como se muestra en la Tabla 4. 
Contexto de 
ISO 13407 
Productos de trabajo de RUP 
Entornos Nivel alto: 
Solicitudes de los interesados 
Visión 
Usuarios Nivel alto: 
Solicitudes de los interesados 
Visión 
Roles Nivel alto: 
Actor empresarial (usuarios externos) 
Trabajador empresarial o Sistema empresarial (usuarios internos) 
Detalles: 
Actor 
 
Guías de Interfaz de Usuario - Diseño de Sistemas 
Autor: E. Porta Versión : 1.01 [11/05/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 11/30 11/05/2010 23:25:00 
Tareas Nivel alto: 
Solicitudes de los interesados 
Visión 
Detalles: 
Storyboard 
Caso de uso 
 
Tabla 4, contextos estándar de diseño centrado en e l usuario y productos de 
trabajo RUP 
Cada uno de estos contextos tiene un impacto significativo en el diseño de una interfaz 
de usuario apropiada. Consecuentemente, nos enfrentamos a una cantidad 
potencialmente grande de permutaciones. Incluso en un sistema pequeño, puede haber 
2 entornos (por ejemplo: sitio del cliente y oficina), 3 tipos de usuario (novato en ventas, 
experto en ventas y gerente) y 6 roles (ayudante de ventas por teléfono, representante 
de ventas externo, etc.). Esto supone hasta 36 variaciones potenciales por tarea, 
aunque el conjunto de combinaciones realistas suele ser mucho inferior.Obviamente, las tareas deben describirse individualmente, ya que es poco probable 
que una sola descripción sea adecuada para todas las permutaciones. Una posibilidad 
es factorizar los contextos de entorno y usuario en la descripción del rol. Esta es la 
solución que adoptaron Constantine y Lockwood en Software for Use – 1999 - Addison 
Wesley [CON99]. 
Esta propuesta implica proporcionar un "rol de usuario" independiente para cada 
permutación significativa de rol, usuario y entorno y, a continuación, nombrar el rol de 
usuario resultante con una frase descriptiva, en lugar de un simple nombre. Compare, 
por ejemplo, el rol "Cliente" con los roles de usuario "Cliente casual", "Cliente Web", 
"Cliente habitual" y "Cliente avanzado". 
Cada descripción de rol de usuario incluye detalles del rol, de los usuarios (conocidos 
como titulares del rol) y del entorno. Para adoptar este enfoque con RUP, seleccione 
los actores que se corresponden con los roles de usuario. 
 
 
Guías de Interfaz de Usuario - Diseño de Sistemas 
Autor: E. Porta Versión : 1.01 [11/05/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 12/30 11/05/2010 23:25:00 
4. Artefacto: Prototipo de interfaz de usuario 
 
El prototipo de interfaz de usuario se utiliza para explorar y/o validar el diseño de la 
interfaz de usuario. 
 
4.1. Quién lo utiliza y para que se utiliza 
Los roles siguientes utilizan el prototipo de interfaz de usuario: 
Diseñadores de interfaz de usuario , para explorar y/o validar el diseño de 
interfaz de usuario antes de que se invierta demasiado en este 
Especificadores de requisitos , para comprender la interfaz de usuario para 
un guión de uso 
Analistas de sistemas , para comprender cómo afecta la interfaz de usuario en 
el análisis del sistema 
Diseñadores , para comprender cómo afecta la interfaz de usuario y qué 
requiere del interior del sistema 
Administradores del proyecto , para planear las actividades de desarrollo y 
de prueba (testing) 
Los prototipos de interfaz de usuario se pueden utilizar para explorar un diseño de 
interfaz de usuario alcanzable y adecuado que cumpla los requisitos, ayudando a 
reducir las distancias entre lo que es necesario (expresado a través de la adquisición 
de requisitos) y lo que es factible. El objetivo principal de la creación de un prototipo de 
interfaz de usuario es poder probar el diseño de interfaz de usuario, incluyendo la 
capacidad de utilización antes de que empiece el desarrollo real. De este modo, puede 
garantizar que está construyendo el sistema correcto, antes de dedicar demasiado 
tiempo y recursos al desarrollo. 
4.2. Opciones de representación 
Los prototipos de interfaz de usuario pueden ser prototipos formales o informales, 
ejecutables o no ejecutables, de baja fidelidad o de alta fidelidad. Por ejemplo, un 
prototipo de interfaz de usuario puede variar desde una serie de imágenes 
representando capturas de pantalla de algunas páginas HTML interactivas. El formato 
que toma el prototipo de UI no es relevante. Lo que es importante recordar es el 
objetivo del prototipo de interfaz de usuario (para explorar o validar un diseño de 
interfaz de usuario) y qué habilidades son necesarias para producir el prototipo (un 
prototipo de interfaz de usuario requiere habilidades de diseño de interfaz de usuario). 
Decida si un prototipo es adecuado para su proyecto. Decida de qué parte de la interfaz 
de usuario desea hacer un prototipo y el nivel de profundidad y de realismo de 
cualquier interactividad. Decida si el prototipo es puramente una muestra o si se tiene 
intención de que algunos aspectos evolucionen para formar parte del producto final. 
Tenga en cuenta que, para alcanzar el objetivo de realizar pruebas tempranas de la 
interfaz de usuario, el desarrollo del prototipo debe ser significativamente más 
económico que el del sistema real, al mismo tiempo que tiene las suficientes funciones 
para poder realizar una prueba de uso significativa. 
 
Guías de Interfaz de Usuario - Diseño de Sistemas 
Autor: E. Porta Versión : 1.01 [11/05/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 13/30 11/05/2010 23:25:00 
5. Artefacto: Mapa de Navegación 
 
 Este artefacto describe la estructura de los elementos de interfaz de usuario del 
 sistema, junto con las vías de navegación potenciales. 
 
5.1. Objetivo 
 
El objetivo del mapa de navegación es expresar las vías de acceso de la 
interfaz del usuario principal a través del sistema. Estas son las principales vías de las 
pantallas del sistema y no son necesariamente todas las vías posibles. Se puede 
considerar como una hoja de ruta de la interfaz de usuario. 
El mapa de navegación sirve de telón de fondo y de enlace entre los 
storyboards individuales. Los storyboards describen cómo navega el usuario a través 
de los elementos de la interfaz de usuario para llevar a cabo las funciones del sistema y 
el mapa de navegación define cuáles son las vías de navegación válidas. El mapa de 
navegación transmite la estructura de la interfaz de usuario del sistema, y los 
storyboards transmiten la dinámica. 
5.2. Descripción 
 
El mapa de navegación debe incluir los principales elementos de la interfaz de 
usuario y sus vías de navegación. No es necesario que contenga todas las vías 
posibles entre los elementos de la interfaz de usuario, sólo las principales. El objetivo 
es que el mapa de navegación sirva como mapa de la interfaz de usuario del sistema. 
Un candidato más obvio para el elemento "superior" de la interfaz de usuario en 
el mapa de navegación es la ventana principal (donde el usuario pasa la mayor parte 
de su tiempo de uso). 
El mapa de navegación debe exponer claramente "cuántos clics" debe realizar 
un usuario para llegar a una ventana específica o a un determinado elemento de la 
funcionalidad. Generalmente, debe tener las áreas más importantes de la aplicación a 
"un clic de distancia" de la ventana principal. Además de añadir un gasto general 
innecesario de interacciones, las vías de navegación de ventanas que son demasiado 
largas aumentan la probabilidad de que el usuario "se pierda" en el sistema. 
Idealmente, todas las ventanas se deberían poder abrir desde una ventana principal, lo 
que da como resultado una longitud máxima de navegación de ventanas de dos. 
Intente evitar las longitudes de navegación de ventanas mayores que tres. 
5.3. Opciones de representación 
 
Se puede utilizar una gran variedad de representaciones para el mapa de navegación. 
Algunos ejemplos son: 
1. Un diagrama en "árbol" jerárquico, donde cada nivel del diagrama muestra el 
número de clics que hay que efectuar para llegar a un elemento específico de 
la interfaz de usuario. 
2. Gráficos de formato libre con iconos. 
3. Diagrama de estados UML donde los estados se utilizan para los elementos de 
la interfaz de usuario y las transiciones se utilizan para las vías de navegación. 
 
La selección de qué representación desea utilizar se especifica en las directrices 
concretas del proyecto. 
 
5.4. Ejemplo 
 
 
Guías de Interfaz de Usuario - Diseño de Sistemas 
Autor: E. Porta Versión : 1.01 [11/05/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 14/30 11/05/2010 23:25:00 
 
 
 
Guías de Interfaz de Usuario - Diseño de Sistemas 
Autor: E. Porta Versión : 1.01 [11/05/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.15/30 11/05/2010 23:25:00 
6. Directriz: Interfaz de usuario (General) 
6.1. Fundamentos de las ventanas: Establecer el 
contexto 
 
En esta sección se proporciona una visión general de la anatomía de una interfaz de 
usuario basada en ventanas. Esta visión general es necesaria para comprender el resto de 
directrices. 
Una interfaz de usuario basada en ventanas se divide en ventanas. Las ventanas se 
pueden mover alrededor de la pantalla, superponerse e iconizarse. Un sistema suele tener 
una ventana principal, y una serie de ventanas secundarias. La ventana principal gestiona 
las principales interacciones con el usuario, y suele contener un número de objetos 
arbitrario. Las ventanas secundarias se utilizan para proporcionar soporte en las 
interacciones con las ventanas principales proporcionando detalles sobre sus objetos y 
operaciones en estos objetos. 
6.1.1. Ventana principal (Primary Windows) 
La ventana principal suele contener un número arbitrario de objetos con qué el usuario 
interactúa. El usuario suele interactuar con el sistema seleccionando primero uno o 
varios objetos, por ejemplo pulsando sobre ellos, y escogiendo una operación (por 
ejemplo, con un menú) que se ejecuta en todos los objetos seleccionados. Las 
operaciones comunes son Cortar , Copiar , Pegar , Suprimir y Ver propiedades . 
La ventana principal normalmente contiene una barra de menús, desde la cual los 
usuarios pueden escoger las operaciones. Los usuarios también escogen operaciones 
a través de los menús emergentes (pulsando el botón derecho del ratón sobre el mismo 
objeto) y con la manipulación directa (pulsando y arrastrando el objeto). Como el 
número total de objetos puede no adecuarse dentro de la ventana principal, los 
usuarios pueden desplazarse a través de los objetos con la barra de desplazamiento, o 
cambiando el tamaño de la ventana. Además, la ventana principal puede dividirse en 
paneles (definiendo subáreas de la ventana), cuyo tamaño también puede cambiar el 
usuario. 
6.1.2. Compuestos 
Un objeto compuesto en una interfaz de usuario es un objeto que está compuesto 
visualmente de otros objetos. Por ejemplo, un párrafo es un compuesto de caracteres , 
o un objeto de dibujo complejo es un compuesto de más objetos de dibujo 
primitivos . 
6.1.3. Ventana secundaria (Secondary Windows) 
Las ventanas secundarias dan soporte a la ventana principal proporcionando detalles 
(como las propiedades) sobre sus objetos, y las operaciones sobre estos objetos. Sólo 
unas cuantas propiedades del objeto se muestran normalmente en la ventana principal. 
Las propiedades de un objeto se pueden visualizar abriendo una ventana de 
propiedades (que es una ventana secundaria) que muestra todos los atributos de un 
objeto. El usuario puede cambiar a menudo los atributos por controles como los 
botones conmutadores y de selección, escalas, cuadros combinados y campos de 
texto. 
 
Guías de Interfaz de Usuario - Diseño de Sistemas 
Autor: E. Porta Versión : 1.01 [11/05/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 16/30 11/05/2010 23:25:00 
Tenga en cuenta que existe una delgada línea, a veces bastante artificial, entre las 
ventanas principales y las secundarias - pueden mostrar los mismos niveles de 
complejidad. Sin embargo, dos diferencias esenciales entre la ventana principal y la 
secundaria son: 
Las ventanas principales se suelen considerar más importantes para la 
aplicación ya que deben proporcionar una utilización extensiva. Por lo tanto, los 
esfuerzos de desarrollo tienden a centrarse en las ventanas principales. 
Las ventanas secundarias suelen mostrarse navegando a través de ventanas 
principales, y no viceversa. 
Además de las ventanas de propiedades, existen otros tipos de ventanas secundarias, 
como los recuadros de diálogo (dialog boxes), recuadros de mensaje (message boxes), 
paletas y ventanas emergentes (pop-up windows). 
Muchas aplicaciones basadas en archivos. Los usuarios pueden iniciar estas 
aplicaciones con la operación Abrir en un objeto de archivo (por ejemplo, efectuando 
una doble pulsación en el icono de un archivo en una carpeta). La ventana principal 
muestra los objetos almacenados en ese archivo. Las operaciones comunes en los 
archivos son Guardar , Guardar como , Abrir y Nuevo , que habitualmente se 
seleccionan mediante el menú Archivo de la ventana principal. La ventana principal 
también puede mostrar múltiples documentos (también denominada Interfaz de 
documento múltiple, o MDI), permitiendo al usuario cambiar entre documentos. 
 
6.2. Dimensiones visuales 
 
La clave para las ventanas principales utilizables es usar las dimensiones visuales cuando 
se visualicen los objetos contenidos y sus atributos. Las ventajas de presentar más 
atributos de los necesarios para la identificación son: 
El usuario evita el coste general de navegación de ventanas ya que reduce el 
número de ventanas que se deben mostrar (cuando el usuario necesita ver un 
atributo que se presenta en la ventana principal). 
El usuario puede ver los diferentes aspectos (de diferentes objetos) al mismo 
tiempo, que suelen ser útiles para comparaciones y para empezar a reconocer 
patrones. Una buena utilización de la dimensión visual puede animar a los usuarios 
a desarrollar una sensación completamente nueva por su trabajo. 
Las dimensiones visuales son: 
Posición 
Tamaño 
Forma 
Color 
Estas dimensiones se presentan a continuación. Sin embargo, tenga en cuenta el área de 
pantalla disponible cuando diseñe la visualización de los objetos. Intente que los gastos 
generales al explotar el área de pantalla sean tan pequeños como sea posible, y considere 
si utilizar varias dimensiones visuales compensa el gasto extra del área de pantalla. Quizás 
el usuario estará mejor servido con sólo una lista de nombres, porque lo que el usuario 
realmente necesita es ver todos los objetos que sea posible. 
Tenga en cuenta que es importante utilizar estas dimensiones visuales, o ampliarlas, para 
poder identificar exclusivamente los objetos. A continuación también incluimos una 
discusión sobre este tema (consulte la sección siguiente, "Identificación"). 
 
Guías de Interfaz de Usuario - Diseño de Sistemas 
Autor: E. Porta Versión : 1.01 [11/05/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 17/30 11/05/2010 23:25:00 
Tenga en cuenta también que las dimensiones visuales se pueden utilizar en correlación 
con la dimensión de tiempo, por ejemplo desplazando objetos (su posición se cambia con 
el tiempo), o cambiando la forma o el color de los objetos (su estado se cambia con el 
tiempo); el último caso se discute en la sección siguiente "Forma". 
6.2.1. Posición 
Los aspectos más intuitivos que las posiciones pueden presentar son las posiciones de 
mundo real. Los ejemplos son: 
Los Sistemas de Información Geográfica (GIS) que muestran un mapa en el 
que usted presenta los objetos en la misma longitud y latitud en que se 
encuentran en el mundo real. 
Los programas de Diseño asistido por ordenador (CAD) que presentan los 
objetos y su entorno exactamente de acuerdo con sus coordinadas del mundo 
real. 
Los editores Lo que se ve es lo que se obtiene (WYSIWYG) que muestran los 
objetos (caracteres) en la misma ubicación de la ventana como aparecerán en 
una impresión en papel. 
A veces es relevante mostrar el tamaño real (ejemplos de editor del programa CAD y 
WYSIWYG), y a veces no lo es; por ejemplo, cuando el tamaño de los objetos es 
mucho menor que la distancia entre losobjetos. 
Por ejemplo, imagine que tiene un sistema de reserva de vuelos donde el usuario debe 
entrar las destinos. Una posible presentación de esto sería mostrar un mapa que 
contenga los diferentes aeropuertos (donde un aeropuerto es un objeto). Naturalmente, 
como los tamaños reales de los aeropuertos son irrelevantes (y demasiado pequeños 
para ser vistos) todos los aeropuertos se muestran como iconos del mismo tamaño. 
Este ejemplo también ilustra que las posiciones del mundo real se pueden utilizar 
incluso si no son relevantes, siempre que ayuden al usuario a identificar los objetos. En 
el ejemplo, el usuario no necesita conocer la ubicación de un aeropuerto. Pero, si el 
usuario está familiarizado con la geografía, será más sencillo encontrar las destinos en 
un mapa que en una lista. 
También puede utilizar una posición para representar posiciones reales "virtuales". Por 
ejemplo, imagine un sistema de compra desde el hogar donde los usuarios puedan 
comprar cosas de diferentes tiendas. Una posible presentación de esto sería mostrar 
una imagen esquemática de un almacén (virtual) donde se colocarían las diferentes 
tiendas (donde una tienda es un objeto). Esta imagen esquemática no tiene nada que 
ver con las ubicaciones reales de estos almacenes -sólo se explota la memoria 
espacial del usuario: es más sencillo recordar una posición x-y que un elemento en una 
lista o en una jerarquía. 
Otra utilización alternativa para la posición es mostrar asociaciones entre objetos: todos 
los objetos que tienen la misma posición vertical se asocian de un modo, y todos los 
objetos que tienen la misma posición horizontal se asocian de otro modo. Las hojas de 
cálculo son un ejemplo de esto. 
Una alternativa similar es permitir que un eje represente el rango de valor de algún 
atributo. Por ejemplo, en un sistema de reserva de vuelos, los vuelos reservados 
(donde un vuelo es un objeto) se podría presentar a lo largo del eje horizontal de 
tiempo mostrando su relación en el tiempo, cuánto durarán, y la duración de tiempo que 
el usuario permanecerá en cada destino. Todo esto son aspectos que el usuario no 
tiene que conocer, pero está bien verlos si se puede presentar de forma discreta. 
 
Guías de Interfaz de Usuario - Diseño de Sistemas 
Autor: E. Porta Versión : 1.01 [11/05/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 18/30 11/05/2010 23:25:00 
Si no desea utilizar tanta área de pantalla presentando todo el rango de valor, puede 
contraer las distancias entre los objetos. En el ejemplo de reserva de viajes, esto 
significaría que todos los vuelos reservados se disponen horizontalmente sin espacios 
entre ellos, pero el primer vuelo está a la izquierda, el segundo vuelo está 
inmediatamente a la derecha del primer vuelo, etc. Los usuarios no verán toda la 
duración de tiempo que permanecerán en cada destino, sino que verían la duración de 
los vuelos. 
6.2.2. Tamaño 
En muchos casos, el "tamaño" debe representar lo mismo que la posición. En un 
sistema CAD, por ejemplo, el tamaño debe representar naturalmente la extensión del 
mundo real. Algunas veces, sin embargo, podemos elegir con qué tamaño deben 
representarse, por ejemplo, los aeropuertos en el mapa que admiten la selección de 
destino. 
En estos casos, el tamaño debe representar lo que se perciba más intuitivamente como 
tamaño real del objeto. Para un archivo, el tamaño de un objeto debe representar la 
cantidad de espacio en disco que ocupa. Para una cuenta bancaria, el tamaño del 
objeto debe representar un balance. Para la mayoría de tamaños, la escala logarítmica 
es mejor que una escala proporcional, ya que una escala proporcional normalmente 
consume demasiada área de pantalla. 
El tamaño es, en realidad, tan intuitivo que puede considerar mostrarlo aunque no sea 
relevante. Después de todo, en el mundo real, varias cosas (objetos) ocupan diferentes 
proporciones de nuestro campo visual debido a sus diferentes tamaños. Y esto no es 
inoportuno; sólo ayuda a discriminar entre las cosas. Del mismo modo, la utilización de 
diferentes tamaños en la interfaz de usuario ayudará a los usuarios a discriminar entre 
diferentes objetos. 
El tamaño debería utilizarse para presentar sólo un atributo, aunque sería posible 
permitir que la extensión horizontal presente un atributo y que la extensión vertical 
presente otro (que no es intuitivo, y puede confundir al usuario). 
La extensión horizontal o vertical debe ser (logarítmicamente) proporcional al atributo 
cuyo tamaño tiene que ilustrar -la otra extensión debe fijarse (o debe depender de la 
longitud del nombre, por ejemplo). Si la extensión horizontal y vertical es proporcional al 
mismo atributo, prácticamente no añade ningún valor: parece molesta y sólo consume 
más área de pantalla. 
6.2.3. Forma 
Las formas normalmente se representan con iconos en una interfaz gráfica de usuario; 
la forma es más adecuada para representar el tipo porque es más intuitiva para 
correlacionar una diferencia de vistas que para correlacionar una diferencia de tipo. En 
el mundo real, diferentes objetos del mismo tipo de cosa normalmente son parecidos, 
mientras que los objetos de diferentes tipos son diferentes. Por ejemplo, diferentes 
objetos para sentarse son similares (todas las sillas tienen cuatro patas, un asiento y un 
respaldo), mientras que los coches sirven para sentarse pero son muy diferentes de 
una silla. 
Así pues, ¿cuáles son los criterios cuando diferentes objetos son de diferentes tipos? 
Bien, clases diferentes ciertamente deben considerarse como tipos diferentes. 
Asimismo, algunos atributos son parecidos al tipo. Estos atributos deben tener un 
conjunto limitado de posibles valores y su valor normalmente determina qué se puede 
hacer con los objetos (en términos de operaciones y posibles valores de otros 
atributos). Ocurre lo mismo en el mundo real -la diferencia más importante entre silla y 
 
Guías de Interfaz de Usuario - Diseño de Sistemas 
Autor: E. Porta Versión : 1.01 [11/05/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 19/30 11/05/2010 23:25:00 
coche es cómo se utilizan: una silla se utiliza para descansar y un coche para el 
transporte. 
Sin embargo, cuando analice lo que se deben considerar tipos diferentes, recuerde que 
lo más importante es: qué atributo percibirá más probablemente el usuario como tipo. 
Si no tiene múltiples clases o ningún atributo de tipo, puede utilizar iconos para 
representar los diferentes valores para otros atributos de valor limitado, pero sólo si 
este atributo es de interés fundamental para el usuario. 
Los iconos también se suelen utilizar para mostrar diferentes estados del objeto 
(además de mostrar el tipo). Cuando selecciona un objeto, se suele mostrar de dos 
modos: el color cambia a negro, o muestra un rectángulo alrededor de este. Otro 
posible estado es que ha abierto una ventana de propiedad para el objeto. 
Normalmente, tiene los otros estados específicos de la aplicación que se pueden 
mostrar como, por ejemplo, si se ha leído o no un mensaje de correo electrónico. 
Asegúrese de que la presentación del estado no dificulta la percepción del usuario del 
tipo y viceversa. 
6.2.4. Color 
El color se puede dividir en tres componentes, basándose en la percepción visual. 
Estos son: tono (es decir, rojo, azul, marrón, etc.), saturación y contraste. Sin embargo, 
no debe utilizar diferentes componentes para representar diferentes atributos, ya que 
será demasiado difícil para la percepción del usuario. 
El tono se puede utilizar para representar tipos o atributos con un conjuntolimitado de 
posibles valores. Sin embargo, es mejor utilizar un icono para esto, porque el icono se 
puede diseñar para que el usuario comprenda qué valor representa, mientras que no 
existe tal correlación intuitiva entre contenido de color y (la mayoría de tipos de) 
valores. El tono se puede utilizar, por lo tanto, en lugar de los iconos, si no se 
encuentran iconos intuitivos. Una alternativa si tiene muchos iconos de tipo es utilizar el 
tono para categorizar los iconos de tipo (para que algunos iconos con un significado 
similar sean rojos, los que tienen otro significado sean azules, etc.). 
La saturación se podría utilizar para representar un atributo con un rango de valor, pero 
esto generará una interfaz de usuario más bien fea y molesta, el uso de diferentes 
saturaciones inestabiliza el ojo y utilizar una saturación alta es bastante molesto. 
El contraste es el componente más utilizable del color. Se puede utilizar para 
representar un atributo con un rango de valor, y no resulta molesto de modo que 
también se puede utilizar para atributos de importancia secundaria. Para que el 
contraste no sea molesto, no debe ir de contraste cero (blanco) a contraste total 
(negro), sino de un contraste bajo (gris claro) a un contraste alto (gris oscuro). Para 
muchos sistemas en que los usuarios crean la mayoría de objetos, es muy útil 
presentar los objetos según la edad; por ejemplo, la cantidad de tiempo desde el último 
cambio. Esto ayuda a los usuarios a identificar el objeto con el que desean trabajar 
(que suele ser el objeto con el "tiempo desde el último cambio" más breve). Por lo 
tanto, si no dispone de un atributo de rango de valor que realmente necesite presentar 
al usuario, considere presentar la edad. 
A veces el color se utiliza para hacer los iconos más llamativos estéticamente y esto 
también ayuda al usuario a discriminar rápidamente entre los iconos. Si proporciona 
iconos de múltiples colores, probablemente no utilizará el color para otros objetivos. 
Como algunas personas son daltónicas, y como no todas las pantallas admiten color, 
no debe utilizar el color como el único medio de mostrar la información vital. Además, 
una utilización bien planificada y no molesta del color hace la interfaz de usuario más 
llamativa estéticamente. 
 
Guías de Interfaz de Usuario - Diseño de Sistemas 
Autor: E. Porta Versión : 1.01 [11/05/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 20/30 11/05/2010 23:25:00 
6.2.5. Identificación 
El usuario debe poder identificar de forma exclusiva cada objeto. A veces, las otras 
dimensiones visuales son suficientes para la identificación, pero en la mayoría de 
casos, no. Mostrar un nombre al lado o cerca de un icono es la técnica más popular 
para dar soporte a la identificación. La ventaja de los nombres es que un área de 
pantalla muy pequeña puede mostrar un gran número de nombres distintivamente 
diferentes. 
Es mejor si un nombre se puede generar a partir de un valor de atributo (que 
normalmente es textual). La alternativa es permitir que los usuarios especifiquen los 
nombres cuando crean los objetos, pero esto requiere tiempo, y por lo tanto reduce la 
utilización. 
A veces puede dar la forma al icono para que el nombre pueda estar contenido dentro 
del icono. Esto ahorra área de pantalla y proporciona una indicación más fuerte de la 
relación entre el icono y el nombre. Sin embargo, esto puede crear los problemas 
siguientes: 
El icono debe estar vacío en medio (donde aparece el nombre). 
Los nombres tienen longitudes variables, lo que significa que la extensión 
horizontal del icono debe depender de la longitud del nombre, o que algunos 
nombres se deben trucar. 
El icono debe ser mucho más ancho que alto, ya que todo texto de longitud 
razonable es más largo que ancha. 
Como resultado, a menudo tiene que mostrar el nombre debajo o a la derecha del 
icono, lo que tiene la ventaja de consumir menos área de pantalla pero el inconveniente 
que el objeto (icono + nombre) acaba siendo incluso más ancho que alto. Si no tiene 
espacio suficiente para mostrar el nombre (que es posible, porque puede identificar un 
icono sin nombrarlo), puede mostrar el nombre mediante ventanas emergentes que se 
muestran cuando el cursor está encima del icono. 
El font del nombre se puede utilizar para mostrar un atributo de opciones limitadas, si 
puede encontrar una correlación intuitiva entre los valores de font y atributo; por 
ejemplo, puede utilizar negrita o cursiva para distinguir el objeto, o para enfatizar su 
importancia. En muchos casos, sin embargo, no es apropiado utilizar el font, ya que es 
bastante molesto y poco intuitivo. 
Si muestra el nombre (o, para esta cuestión, cualquier otro texto que el usuario pueda 
cambiar) debe proporcionar soporte a la edición directa del nombre en la ventana 
principal. La alternativa del usuario sería solicitar una operación de cambio de nombre 
y, a continuación, entrar el nuevo nombre, o abrir la ventana de propiedades y editar allí 
el nombre. No sólo resulta más rápido editar directamente el nombre en la ventana 
principal, sino que también admite el principio "donde se ve es donde se cambia". 
 
6.3. Buscar y Seleccionar 
 
Si el grupo de objetos que se debería cambiar u operar está compuesto de modo que el 
usuario pueda expresar los criterios de selección identificándolos, la herramienta de 
búsqueda de la ventana principal puede solucionar el problema seleccionando siempre 
todas las coincidencias del criterio. 
Hay dos formas posibles de gestionar la búsqueda: 
 
Guías de Interfaz de Usuario - Diseño de Sistemas 
Autor: E. Porta Versión : 1.01 [11/05/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 21/30 11/05/2010 23:25:00 
1. Todos los objetos a los que se aplica el criterio de búsqueda se seleccionan en la 
ventana principal. Si no puede garantizar que todos los objetos encontrados se 
muestran simultáneamente en la ventana principal (porque pueden estar 
demasiado lejos), también puede mostrar una lista de coincidencias en la ventana 
de búsqueda. Después de una búsqueda, el usuario especifica criterios de 
búsqueda adicionales o realiza una operación en los objetos seleccionados. La 
ventaja de este enfoque es que permite que el usuario solicite algunas operaciones 
en todos los objetos de acuerdo con estos criterios de búsqueda. 
2. Proporcione un botón Búsqueda en la ventana de búsqueda que seleccione el 
objeto siguiente de acuerdo con los criterios de búsqueda y desplace el contenido 
de la ventana principal para que este objeto sea visible. Después de una búsqueda, 
el usuario puede realizar una operación en el objeto seleccionado y continuar para 
buscar secuencialmente a través de los objetos de acuerdo con los criterios de 
búsqueda. La ventaja de este enfoque es que el usuario puede ver todos los 
objetos encontrados en su entorno (en la ventana principal mejor que en una lista 
de coincidencias separada). 
 
6.4. Orden 
 
Un ejemplo de clasificación puede ser que el sistema organice todos los objetos 
verticalmente, en orden alfabético por nombre o según el valor de un atributo. El 
usuario entonces examina los objetos desplazándose. Este es el soporte más sencillo 
posible para examinar respecto a la implementación y respecto a la operación del 
usuario. Los trabajos se ordenan mejor cuando el usuario conoce siempre el nombre (o 
el atributo por el que hemos ordenado) del objeto que se desea. Un ejemplo de un 
sistema que se debería implementar de este modo es un libro de teléfonos. La ventana 
principal debe tener una operación con frecuenciapara cambiar el orden de 
clasificación y/o los criterios. 
 
6.5. Jerarquías de navegación 
 
Una jerarquía de navegación permite que el usuario (o posiblemente el sistema) 
categorice los objetos en ventanas principales o compuestas, que se organizan 
jerárquicamente. La navegación de las jerarquías garantiza que el usuario sólo tenga 
que buscar una (o unas cuantas) categorías. Esto reduce el número de objetos que se 
deben mostrar en un momento concreto. Un inconveniente es que el usuario 
(habitualmente) tiene que gestionar la categorización. Un ejemplo de esta técnica es el 
navegador de archivos: el motivo para tener directorios o carpetas es ayudar al usuario 
a encontrar archivos. 
6.6. Gestión de ventanas 
 
El tamaño de las ventanas y su posición está totalmente controlado para el usuario. 
Puede, sin embargo, considerar reducir el gasto en ventanas permitiendo que el 
sistema afecte el tamaño y la posición de las ventanas. 
Cuanto más grande sea la ventana principal, más objetos se pueden mostrar, pero más 
área de pantalla se consume. Una ventana principal debe mostrar, normalmente, 
cuantos más objeto sean posibles pero sin consumo innecesario de área de pantalla. 
 
Guías de Interfaz de Usuario - Diseño de Sistemas 
Autor: E. Porta Versión : 1.01 [11/05/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 22/30 11/05/2010 23:25:00 
La ventana principal debe ser suficientemente grande para que se puedan 
mostrar todos los objetos, pero no más grande que la pantalla. Haga que cada 
ventana principal sea suficientemente grande para mostrar los objetos 
completos pero evite las áreas que no muestran nada útil como los márgenes 
en un editor de escritorio. Aunque tenga espacio para mostrar estas áreas 
vacías, es posible que oculten otras aplicaciones. 
Recuerde que un usuario cambia de tamaño entre sesiones. Si el número de 
objetos aumenta, aumente el tamaño de ventana para que todos los objetos 
estén visibles, a menos que ya tenga la altura completa de ventana o si el 
usuario ha elegido un tamaño inferior al tamaño por omisión. Si el número de 
objetos disminuye, reduzca el tamaño, a menos que el usuario haya escogido 
un tamaño superior al tamaño por omisión. Esta regla garantiza que sigue la 
intención de las operaciones de cambio de tamaño de los usuarios. 
Una posible limitación posterior sobre el tamaño de la ventana principal es si necesita 
utilizar la aplicación en paralelo con otras aplicaciones. Puede maximizar el tamaño por 
omisión de la ventana a media ventana (en oposición a la pantalla completa). 
Haga que la posición por omisión de una ventana principal oculte lo mínimo posible de 
otras aplicaciones. Si tiene que ocultar algunas ventanas, escoja las que no se han 
utilizado durante más tiempo, e intente dejar como mínimo una parte de las ventanas 
visibles para que el usuario pueda activarlas fácilmente. 
Una desventaja de aplicar las reglas anteriores es que restará alguna cantidad de 
control al usuario (el sistema cambiará el tamaño sin preguntarlo, y no recordará los 
cambios de posición del usuario entre sesiones). Por lo tanto, si aplica estas reglas, 
debe permitir que el usuario las desactive (con un control). 
Para ventanas secundarias, el tamaño y la posición sería el que no oculte la ventana 
desde la que se llamaron y posiblemente para que no oculten a otras ventanas 
secundarias. Si tienen que ocultar la ventana desde la que se llamaron, intente 
asegurarse de que no ocultan objetos seleccionados. Ocultar cosas vitales, como 
objetos seleccionados, es un defecto de utilización común para las ventanas 
secundarias. 
Para las ventanas principales diferentes de la ventana principal primaria, también debe 
aplicar la norma del tamaño del último párrafo. 
Los recuadros de diálogo, sin embargo, deben colocarse para que bloqueen la visión 
de la ventana activa. Como suelen ser pequeños y temporales, el usuario no necesita 
ver la ventana activa mientras la ventana de diálogo está abierta. Colocar recuadros de 
diálogo en la ventana activa garantiza que el usuario las reconoce y reduce el 
movimiento de ratón necesario porque el cursor normalmente está listo sobre la 
ventana activa. 
Para ventanas de propiedades, el número de atributos determina el tamaño. Si el 
tamaño es demasiado grande (aproximadamente 1/4 de la pantalla), debe utilizar más 
pestañas (tabs). 
 
6.7. Información de la sesión 
 
Todas las configuraciones de la aplicación deben guardarse entre sesiones (sin que el 
usuario tenga que especificarlo). El tamaño y la posición de las ventanas, qué vista se 
selecciona y las posiciones de las barras de desplazamiento también deben guardarse. 
Cuando los usuarios reinicien la aplicación, debe ser exactamente igual que cuando se 
 
Guías de Interfaz de Usuario - Diseño de Sistemas 
Autor: E. Porta Versión : 1.01 [11/05/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 23/30 11/05/2010 23:25:00 
salió la última vez. El motivo de esto es que habitualmente lo primero que hacen los 
usuarios cuando inician la sesión es volver a trabajar donde salieron en la última 
sesión. 
 
6.8. Ayuda en línea 
 
La ayuda en línea es una parte muy importantes del sistema. Un sistema de ayuda bien 
diseñado también debería poder reemplazar los manuales de usuario de la mayoría de 
sistemas. La mayoría de proyectos gastan esfuerzos considerables en la construcción y 
la producción de manuales cuando es conocido que la mayoría de usuarios nunca los 
utiliza. Debe considerar invertir estos esfuerzos en un buen sistema de ayuda. 
Existe una serie de posibles herramientas de ayuda que debe tener en cuenta: 
Ayuda según tema es la herramienta de ayuda más importante. Permite que 
el usuario entre un tema o navegue en un tema existente y proporciona ayuda 
sobre estos temas. La clave es proporcionar un gran índice de ayuda con 
muchos sinónimos. Recuerde: es posible que el usuario no conozca el término 
correcto cuando lo necesite. 
Ayuda según objeto es una ayuda según contexto. Muestra el texto que 
explica la parte específica (objeto) de la interfaz de usuario. El usuario solicita 
ayuda según contexto y, a continuación, selecciona la parte de la interfaz de 
usuario donde es necesaria la ayuda. Este tipo de ayuda debe soportarse para 
cada parte de la interfaz de usuario, si también se puede utilizar. Otra 
alternativa es proporcionar una ayuda implícita en ventanas emergentes -una 
forma condensada de ayuda sensible al contexto que el sistema presenta 
adyacente al cursor cuando el usuario pasa el cursor por en encima unos 
segundos. La utilización de una ayuda implícita en ventanas emergentes tiene 
la ventaja de que no interfiere con la operación normal de la interfaz de usuario. 
Área de mensajes es un área (habitualmente en la ventana principal) donde el 
sistema imprime los "comentarios" no solicitados sobre las acciones de los 
usuarios. Debe ser opcional si se proporciona. 
Asistentes son una técnica popular que debe considerar cuando un usuario 
solicite ayuda sobre cómo hacer algo. Un asistente orienta al usuario a través 
de una tarea (no trivial) mediante la técnica de acompañamiento. Muestra texto 
descriptivo junto con las operaciones (botones) que permiten que el usuario 
desarrolle las partes de la tarea que se explican en el texto. De forma 
alternativa, un asistente realizará una pregunta y, basándose en las respuestas 
del usuario, desarrollará automáticamente la tarea. Los asistentes son 
excelentes para tareas que no son triviales y que se utilizan con poca 
frecuencia. 
La necesidad de ayudasegún contexto y asistentes es probable que se identifique 
durante las pruebas de utilización. Si, durante las pruebas de utilización, los usuarios 
no comprenden qué partes diferentes de la interfaz de usuario son, es una indicación 
de la necesidad de una ayuda según contexto. Si tienen dificultades para efectuar una 
cierta tarea, es una indicación de la necesidad de los asistentes. 
El problema con muchos sistemas de ayuda es que se escriben para usuarios noveles 
(gastando una enorme cantidad de texto para explicar lo que es obvio) o para expertos 
(manuales de consulta que presuponen que el usuario sabe casi tanto como el 
programador que hizo la aplicación). Para la mayoría de sistemas, muchos usuarios 
son intermedios. Escriba el texto de ayuda para ellos. 
 
Guías de Interfaz de Usuario - Diseño de Sistemas 
Autor: E. Porta Versión : 1.01 [11/05/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 24/30 11/05/2010 23:25:00 
 
6.9. Deshacer 
 
Deshacer es una función muy útil, aunque es difícil de lograr (implementar) en general. 
Permite que los usuarios aprendan más rápidamente, ya que no tendrán miedo de 
romper nada. También reduce el riesgo de perder información. Una solución alternativa 
para evitar la pérdida de información es requerir que el usuario confirme todas las 
operaciones que podrían provocar una pérdida de información. Esta es una mala 
solución, sin embargo, ya que añade un gasto de interacción considerable y los 
usuarios aprenderán pronto a confirmar inconscientemente, presentando esta solución 
inadecuadamente. 
Una opción ambiciosa también es proporcionar rehacer, y posiblemente múltiples 
niveles de deshacer y rehacer. No obstante, el primer nivel de deshacer logra el 
incremento de la usabilidad. 
 
6.10. Agente de macros 
 
Si proporciona macros, puede resultar muy útil emplear un agente que supervise 
continuamente las acciones del usuario, buscando secuencias de interacción repetidas. 
Cuando se detecta una secuencia de interacción repetida, el agente crea una macro 
para ella (después de solicitar permiso al usuario). Pongamos que el usuario ha 
solicitado "Subrayar" dos párrafos de texto y ambas veces el usuario también ha 
cambiado el color del texto a azul inmediatamente después de solicitar "Subrayado". El 
agente debería preguntar al usuario si desea una macro que "subraye" y "establezca el 
color en azul" el párrafo de texto seleccionado. Si lo desea, el agente debe crear esta 
macro y un pulsador (o elemento de menú) que ejecute la macro. 
 
 
 
Guías de Interfaz de Usuario - Diseño de Sistemas 
Autor: E. Porta Versión : 1.01 [11/05/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 25/30 11/05/2010 23:25:00 
7. Directriz: Storyboard 
 
Un storyboard es una descripción lógica y conceptual de la funcionalidad del sistema, 
para un escenario o grupos de escenarios específicos. 
 
7.1. Introducción 
Los storyboards se pueden utilizar para explorar, comprender y razonar sobre los 
requisitos de comportamiento del sistema, especialmente, cómo interactuarán los 
usuarios con el sistema. 
Puede definirse un storyboard para cada caso de uso, de esta manera se da soporte a 
un enfoque de la ingeniería de software guiada por casos de uso, además de 
proporcionar un medio excelente para validar las expectativas del usuario (actor) de 
estos casos de uso y su rol en los distintos escenarios de los casos de uso. 
Es importante recordar que el objetivo principal de los storyboards es comprender el 
flujo y las interacciones globales, no crear un prototipo ni probar el aspecto de la 
interfaz de usuario. 
Los storyboards se utilizan desde hace tiempo en el cine y la televisión, de ellos ha 
tomado prestada la técnica la comunidad de software. 
Los storyboards están destinados a representar más "realmente" a los escenarios 
textuales, utilizando medios gráficos para especificar los requisitos. 
En esta directriz describimos algunas recomendaciones para representar el storyboard. 
 
7.2. Beneficios de los storyboards 
Ayudan a recopilar y perfeccionar los requisitos del cliente de forma amigable para el 
usuario. 
Promueven soluciones de diseño más creativas e innovadoras. 
Promueven las revisiones de equipo y evita las características que nadie desea. 
Garantiza que las características se implementan de forma accesible e intuitiva. 
Facilita el proceso de entrevista evitando el síndrome de la página en blanco. 
 
7.3. Representación de storyboards 
 
Los storyboards pueden ser prototipos formales o informales, ejecutables o no 
ejecutables, de baja fidelidad (dibujados a mano) o de alta fidelidad (páginas HTML 
interactivas). El formato del storyboard no es relevante. Lo que es importante es 
recordar el objetivo del storyboard (comprender las expectativas del usuario respecto al 
comportamiento del sistema) y qué habilidades son necesarias para producir el 
storyboard. 
Los storyboards se pueden expresar con representaciones visuales o textuales, o una 
combinación de ambas. 
 
Guías de Interfaz de Usuario - Diseño de Sistemas 
Autor: E. Porta Versión : 1.01 [11/05/10]
Cátedra Diseño de Sistemas UTN – F.R.Ro.
 
 
 26/30 11/05/2010 23:25:00 
Algunos ejemplos de los modos en que se pueden visualizar los storyboards incluyen 
los siguientes: 
Esbozos o dibujos en papel 
Mapas de bits de una herramienta de dibujo 
Tarjetas de índice 
Diapositivas de PowerPoint 
Capturas de pantalla (si existe una interfaz de usuario, o un prototipo de la 
interfaz de usuario). Nota: los storyboards expresados en términos de capturas 
de pantalla reales pueden resultar una entrada útil para la documentación de 
usuario final. 
 
El storyboard sirve también para capturar los requerimientos de usabilidad significativos 
para el usuario 
No importa qué representación se seleccione, es importante tener en cuenta lo 
siguiente para cada elemento de la interfaz de usuario: 
Las acciones que el usuario puede desarrollar, o las solicitudes que puede 
efectuar al sistema. 
La información que se presenta al usuario, o la que ha entrado el usuario. 
Los storyboards significan utilizar una herramienta para ilustrar (y a veces animar) para 
los usuarios (actores) cómo se adecuará el sistema en la organización, e indicar como 
se comportará el sistema. Un moderador muestra un storyboard inicial al grupo y el 
grupo proporciona comentarios. El storyboard, entonces, evoluciona en "tiempo real" 
durante el taller. Por lo tanto, necesitará una herramienta gráfica de dibujo para 
cambiar fácilmente el storyboard. Para evitar distracciones, es aconsejable utilizar 
herramientas sencillas, como gráficos sobre caballetes, una pizarra o Microsoft® 
PowerPoint®. 
 
7.4. Herramientas para la creación de storyboards 
 
Existen dos grupos distintos a utilizar para la creación de storyboards: herramientas 
pasivas y herramientas activas. Pasivo significa que se muestran imágenes 
inanimadas, mientras que las herramientas activas tienen capacidades más 
sofisticadas incorporadas. 
Ejemplos de herramientas pasivas para la creación de storyboards: 
Papel y lápiz 
Notas Post-it® 
Constructores de GUI 
Diferentes tipos de gestores de presentaciones 
 
Nota: En la cátedra utilizaremos Visio y Word para realizar los storyboards 
 
Algunos ejemplos de herramientas activas para la creación de storyboards son: 
Apple HyperCard 
Solutions Etcetera