Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Este tema describe el modelo de interfaz de usuario conocido como interfaz de usuario inductiva (IUI). También llamado navegación inductiva, el modelo IUI sugiere cómo simplificar las aplicaciones de software dividiendo las funciones en pantallas o páginas fáciles de explicar y comprender. Este modelo de IUI es evidente en varios proyectos de Microsoft, como Microsoft Money 2000, los applets del panel de control de Windows, varias pantallas y cuadros de diálogo en Microsoft Visual Studio 2010 y los paneles de tareas de Microsoft Office.
- Introducción
- IUI en acción: solución de un problema de diseño común
- Pasos para crear una interfaz de usuario inductiva
- Directrices adicionales
- Asistencia al usuario
- Apéndice: Diseño y prueba de Microsoft Money 2000
Introducción
IUI es un modelo de interfaz de usuario que sugiere cómo simplificar las aplicaciones de software dividiendo las funciones en pantallas o páginas fáciles de explicar y comprender. Microsoft ha implementado este modelo en Money 2000, una aplicación de software comercial grande. Las pruebas informales sugieren que los usuarios pueden realizar tareas con la misma rapidez en este modelo que en las interfaces tradicionales, y pueden encontrar cosas más fácilmente.
Muchas aplicaciones de software comerciales incluyen interfaces de usuario en las que una pantalla presenta un conjunto de controles, pero deja en manos del usuario deducir el propósito de la página y cómo usar los controles para lograr ese propósito.
Los principios descritos en este documento no requieren ni implican ningún conjunto rígido concreto de diseños, controles o elementos visuales. Al igual que las interfaces gráficas de usuario en general, los principios de este documento dejan mucho margen para la flexibilidad y la creatividad en el diseño.
Los principios generales de la interfaz de usuario inductiva se demuestran con ejemplos extraídos de Money 2000.
Importante
El concepto general de la IUI está en pañales. Los diseñadores que emplean estas técnicas van aprendiendo y descubriendo más sobre ellas a medida que las usan para su software. La información de este documento evolucionará con el tiempo a medida que aumenten la investigación y los conocimientos en este ámbito. Este tema ofrece una introducción a la IUI, más que un conjunto firme y exhaustivo de directrices.
IUI en acción: solución de un problema de diseño común
En esta sección se analiza un problema de diseño habitual en los productos de software actuales y se presenta la IUI como técnica para superarlo.
El problema: el software es difícil de usar
La mayoría del software es demasiado difícil de usar. Esta conclusión se extrae de pruebas de usabilidad, pruebas anecdóticas y experiencias personales de diseñadores de software. El concepto de IUI se creó investigando, haciendo conjeturas sobre lo que dificulta el uso del software actual y proponiendo soluciones. Los diseñadores que usan la IUI deben confiar en la satisfacción del cliente para determinar el éxito final del diseño.
La mayoría de los productos de software actuales son difíciles de usar por las siguientes razones generales:
Los usuarios no parecen construir un modelo mental adecuado del producto.
El diseño de la interfaz de la mayoría de los productos informáticos actuales parte de la base de que los usuarios entenderán un modelo conceptual que los diseñadores han elaborado cuidadosamente. Por desgracia, la mayoría de los usuarios no parecen adquirir nunca un modelo mental lo bastante completo y preciso como para guiar su navegación. Es probable que estos usuarios estén muy ocupados y sobrecargados con información. No tienen tiempo, energía ni ganas de estudiar un modelo conceptual para su software.
Incluso muchos usuarios veteranos nunca llegan a dominar los procedimientos habituales.
Los diseñadores saben que los nuevos usuarios pueden tener problemas al principio, pero esperan que estos desaparezcan a medida que los usuarios aprendan las tareas habituales. Los datos de usabilidad indican que esto no suele ocurrir. En un estudio, los investigadores instalaron equipos automatizados para grabar en vídeo a los usuarios en casa. Las cintas mostraron que los usuarios centrados en la tarea que están realizando no se dan cuenta necesariamente del procedimiento que están siguiendo y no aprenden de la experiencia. La próxima vez que los usuarios realicen la misma operación, pueden tropezar exactamente de la misma manera.
Los usuarios deben esforzarse mucho para descifrar cada característica o pantalla.
La mayoría de los productos de software están diseñados para (los pocos) usuarios que comprenden su modelo conceptual y dominan los procedimientos habituales. Para la mayoría de los clientes, cada característica o procedimiento es un rompecabezas frustrante e indeseado. Los usuarios pueden asumir que estos rompecabezas son un coste inevitable del uso de equipos, pero sin duda serían más felices sin esta carga.
La mejor solución a estos problemas es encontrar una estrategia general para que las características de los productos de software sean más evidentes y autoexplicativas. Los usuarios deben poder encontrar una característica cada vez que la necesiten, y deben poder usar esa característica cada vez que quieran usarla.
Interfaz de usuario deductiva
La mayoría de los elementos del software actual requieren que el usuario los estudie y deduzca su comportamiento, como demuestra la siguiente captura de pantalla.
Los usuarios experimentados de equipo, incluidos los diseñadores de software, reconocen rápidamente que este cuadro de diálogo les permite gestionar una lista de cosas. Comprenden que los botones situados debajo de la lista pueden agregar, eliminar y proporcionar información sobre los elementos de la lista. Sin embargo, observe que ninguno de estos comportamientos se indica explícitamente en el propio diálogo.
Ahora echemos otro vistazo al diálogo desde el punto de vista de un usuario ocasional. Muchos usuarios, al enfrentarse a este cuadro de diálogo, se preguntarán: "¿Qué se supone que debo hacer con esto?". Cuando aparece el cuadro de diálogo, el usuario debe detenerse y pensar qué hacer a continuación. En primer lugar, el usuario debe deducir que el rectángulo blanco grande es un cuadro de lista vacío que debe rellenarse con elementos. La pequeña etiqueta de texto de la caja, "Cosas", ofrece una vaga pista. Algunos usuarios intentarían escribir en el cuadro de lista, porque parece un cuadro de texto de edición.
A continuación, el usuario debe deducir que los botones situados debajo de la lista afectan a su contenido. Algunos de los botones están inicialmente deshabilitados, que es otro posible motivo de confusión del usuario. El usuario debe experimentar con los controles para aprender cómo funciona el diálogo.
El usuario también puede formular otras preguntas: "¿Cuántos elementos debo colocar en la lista? ¿Debo introducir los artículos en un orden específico? ¿Por qué he recibido este diálogo en primer lugar? ¿Para qué sirve?
Los usuarios se distraen de sus objetivos cada vez que deben averiguar el propósito de una pantalla y cómo usarla. En última instancia, esto representa un coste en tiempo y satisfacción del usuario. Y lo que es peor, los usuarios pagan este coste una y otra vez, ya que cada vez que usan una característica se preguntan cómo funciona la interfaz.
Una pantalla debe tener un título que explique claramente su propósito. Cuando los diseñadores crean una pantalla, rara vez exigen que tenga una finalidad claramente expresable. En cambio, puede ser simplemente parte de un modelo conceptual más amplio que el usuario debe deducir.
Los estudios demuestran que muchos usuarios se confunden incluso con las operaciones básicas de los programas de software. Les cuesta entender lo que el producto puede hacer por ellos, dónde dirigirse para realizar una operación y cómo realizarla una vez que la han encontrado. Simplificar el software introduciendo cambios fundamentales es una forma eficaz de satisfacer mejor a los clientes actuales y atraer a nuevos usuarios.
Una solución: interfaz de usuario inductiva
Como nueva forma de diseñar software, el objetivo de la IUI es reducir el tiempo de reflexión que los usuarios deben dedicar a moverse entre las partes de un producto y usar sus funciones. La palabra inductivo procede del verbo inducir, que significa conducir o mover por influencia o persuasión.
IUI es una extensión de la interfaz de estilo web común. En el entorno web, las páginas tienen que ser sencillas y estar basadas en tareas, porque cada dato tiene que enviarse a un servidor a través de una conexión relativamente lenta. A continuación, el servidor responde con el siguiente paso, y así sucesivamente. Un buen diseño web implica centrarse en una única tarea por página y facilitar la navegación a través de las páginas. Del mismo modo, la navegación inductiva comienza centrando la actividad de cada página en una única tarea principal.
Una interfaz inductiva bien diseñada ayuda a los usuarios a responder a dos preguntas fundamentales que se plantean al mirar una pantalla:
- ¿Qué debo hacer ahora?
- ¿Dónde voy desde aquí para realizar mi siguiente tarea?
Los programas informáticos diseñados según estos principios responden a estas preguntas partiendo de una premisa fundamental: una pantalla con un propósito único, claramente expuesto y explícito es más fácil de entender que una página sin tal propósito. Si la pantalla es más fácil de entender, al usuario le resultará más fácil saber qué hacer y adónde ir a continuación.
Esta premisa fundamental puede ampliarse en una serie de cuatro pasos para diseñar software que use la IUI:
- Centre cada pantalla en una única tarea.
- Enuncie la tarea.
- Haga que el contenido de la pantalla se ajuste a la tarea.
- Ofrezca vínculos a tareas secundarias.
Aunque este documento describe los principios generales de IUI, también demuestra esos principios en acción mostrando ejemplos de Money 2000 y otro software. Debe pensar en estos ejemplos como expresiones particulares de la IUI, no como un modelo estricto de implementación.
Además de los cuatro pasos anteriores, puede reforzar su interfaz siguiendo estas cinco pautas:
- Usar plantillas de pantalla coherentes.
- Proporcionar pantallas para iniciar tareas.
- Hacer evidente cómo realizar la tarea con los controles en pantalla.
- Proporcionar una manera sencilla de completar una tarea e iniciar una nueva.
- Hacer que el siguiente paso de navegación sea evidente.
Procesos
Muchas tareas requieren que los usuarios naveguen por una serie de pantallas. Un usuario que realiza una tarea puede hacer clic en un vínculo a una tarea secundaria que se aleja de la secuencia de pantallas que componen la tarea principal. Cuando el usuario completa la tarea secundaria, debe haber una manera fácil de devolverlo directamente al punto de ramificación en la tarea original. Es probable que los usuarios tengan problemas al usar controles de navegación convencionales, como los botones Atrás y Adelante para volver a donde comenzaron.
Para proporcionar esta capacidad, IUI define un concepto de navegación llamado proceso, una pantalla o serie de pantallas que realizan una tarea. Un proceso actúa como una especie de subrutina de navegación. Los usuarios pueden iniciar un proceso, recorrer una serie de pantallas y, en la última página, pulsar el botón "Listo" para volver rápidamente a la página en la que iniciaron el proceso.
Pasos para crear una interfaz de usuario inductiva
Esta sección describe en profundidad los cuatro pasos que puede usar para crear una IUI.
Paso uno: centrar cada página en una sola tarea
El primer paso en el diseño de una IUI es tomar una característica o conjunto de características y dividirla en pantallas separadas. Cada pantalla debe centrarse en una única tarea, denominada tarea principal de la pantalla.
Esta idea parece sencilla, pero pocas aplicaciones la siguen. La mayoría de las aplicaciones presentan una pantalla desde la que se realizan todas las funciones relacionadas. Este diseño requiere que los usuarios averigüen (deduzcan) qué se puede hacer y cómo hacerlo.
La tarea principal puede ser específica o abierta. Por ejemplo, en un programa de finanzas personales, una tarea específica podría ser "Seleccione la factura que desea pagar", mientras que una tarea abierta podría ser "Revise el rendimiento de sus inversiones".
La tarea principal debe ser algo que tenga sentido para el usuario, y no el reflejo de un detalle de implementación u otro concepto abstracto. La tarea debe ser algo que a los usuarios se les ocurra hacer, preferiblemente descrito con sus propias palabras.
Ejemplo
Esta sección compara dos versiones diferentes de Money. Los ejemplos muestran funciones muy similares que permiten a los usuarios ver y gestionar cuentas financieras.
El modelo IUI se desarrolló durante la creación de Money 2000, una aplicación para gestionar las finanzas personales. Money 2000 es la octava versión principal del producto. Money 2000 es un gran programa para Windows con más de un millón de líneas de código.
Money 2000 es una aplicación de tipo Web. No es un sitio web, pero comparte muchos atributos con los sitios web. Su interfaz de usuario consiste en páginas a pantalla completa mostradas en un marco compartido, con herramientas para avanzar y retroceder por una pila de navegación. Sobre esta base, Money 2000 añade un conjunto de nuevas convenciones de interfaz de usuario que crean una experiencia de usuario más estructurada.
Aunque la IUI se usó por primera vez en el diseño de estilo Web de Money 2000, también puede emplearse con elementos de interfaz tradicionales, como ventanas y cuadros de diálogo.
En Money 99, los usuarios solían realizar una gran variedad de tareas en una sola pantalla. Por ejemplo, la siguiente captura de pantalla muestra el Administrador de cuentas que presentó todas las características relacionadas con la cuenta en Money 99 en una sola pantalla.
Esta pantalla agrupa una tarea común, navegar a una cuenta, así como tareas poco frecuentes como crear y eliminar cuentas. Ninguna de estas tareas específicas se expresa directamente en el título de la pantalla, Administrador de cuentas. Muchos usuarios pueden encontrar esta pantalla tan desafiante como el diálogo de ejemplo de la Figura 1. En ambos casos, el usuario debe deducir la finalidad de la pantalla y cómo usarla.
Money 2000, que sigue a IUI, ofrece un conjunto casi idéntico de características relacionadas con la cuenta, pero las proporciona en dos pantallas independientes. La siguiente captura de pantalla muestra la primera de estas pantallas, que se centra por completo en conseguir que el usuario elija una cuenta.
La pantalla Money 2000 contiene aproximadamente el mismo número de elementos visuales que la anterior pantalla Money 99, pero la página se centra ahora por completo en conseguir que el usuario elija una cuenta. Por ejemplo, en la versión Money 99, un usuario tenía que hacer dos clics para abrir una cuenta: uno para seleccionarla y otro para seleccionar la operación de apertura. En la versión Money 2000, la única razón por la que un usuario hace clic en una cuenta es para abrirla, por lo que basta con un solo clic. De este modo, aunque aumente el número de pantallas, suele reducirse el número de clics necesarios para realizar una tarea común.
Ocasionalmente, los usuarios querrán agregar o quitar una cuenta. Para realizar esta tarea en Money 2000, los usuarios navegan a una segunda pantalla (mostrada en la siguiente captura de pantalla) que se centra en la configuración de cuentas.
El propósito de cada pantalla es más claro en la versión IUI de Money 2000. Además, cada pantalla dispone de más espacio para cumplir su función. Por ejemplo, el Administrador de cuentas de Money 99 podría dar muy poco espacio al botón Eliminar cuenta, ya que rara vez se usó en comparación con los demás comandos de la pantalla. En cambio, la pantalla de configuración de cuentas de Money 2000 puede mostrar este comando de forma más destacada, haciéndolo más fácil de descubrir y autoexplicativo.
¿Qué es una tarea única?
¿Cómo saber si una pantalla está realmente centrada en una sola tarea? Una pantalla que soporta muchas tareas puede explicarse como si solo tuviera un propósito si este es lo suficientemente abstracto. A continuación se proporciona una regla empírica: una pantalla se centra en un propósito si el diseñador puede expresar ese propósito con un título conciso, significativo y que suene natural.
Los diseñadores de Money 2000 consideraron dividir estas pantallas (Elegir una cuenta para usar y Configurar sus cuentas en Money)) en más pantallas. Sin embargo, como cada pantalla ya tiene un título conciso, significativo y que suena natural, los diseñadores creyeron que las pantallas estaban suficientemente centradas. A la hora de diseñar una pantalla, si no se le ocurre un título claro y sencillo, es probable que esté intentando abarcar demasiado en la pantalla.
Paso dos: enunciar la tarea
Cada pantalla debe titularse con una declaración concisa y explícita de su tarea principal. Puede ser una instrucción directa ("Seleccione la cuenta que desee equilibrar") o una pregunta que desea que el usuario responda ("¿Qué cuenta desea equilibrar?").
Este es otro principio aparentemente sencillo que a menudo no se pone en práctica. Por ejemplo, las versiones anteriores de Money tenían pantallas con títulos como Gestor de servicios financieros en línea y Cuenta de saldo. Los usuarios tenían que deducir la finalidad y el comportamiento de estas pantallas a partir de la disposición y las etiquetas de sus controles.
El título de la pantalla o página es muy importante. Tanto si el producto usa ventanas, páginas de estilo web, cuadros de diálogo u otro diseño, no debe permitirse que el título se desplace.
Las pantallas utilizables tienen títulos claros
Las pantallas que realizan muchas tareas requieren títulos abstractos o complejos. Por ejemplo, la pantalla de Money 99 que se muestra en la Figura 2 permitía al usuario tanto navegar hasta las cuentas como configurarlas. El título abstracto "Administrador de cuentas" se dio a esta página en un intento de capturar ambos propósitos. Aunque los usuarios pueden tener algunas ideas sobre lo que una página de "Gestor de cuentas" puede hacer, es muy posible que no se den cuenta de que la tarea más habitual para esta pantalla era simplemente elegir una cuenta.
Algunas pantallas o comandos tienen propósitos abstractos que no sugieren fácilmente títulos claros. Para estas pantallas, los diseñadores pueden elegir nombres deliberadamente imprecisos, como "Configuración"; palabras de moda acuñadas, como "QuickStep"; o jerga que revela detalles de implementación ("Compactación de base de datos"). Este tipo de nombres suelen confundir o inducir a error a los usuarios. Además, esos nombres suelen ser sustantivos que no expresan la acción que el usuario quiere realizar, lo que aumenta la confusión.
Los títulos de las pantallas y otros nombres no suelen determinarse hasta casi el final del proceso de diseño. Los diseñadores suelen pedir a los redactores que den un nombre adecuado a una pantalla después de haberla diseñado y codificado. En ese momento, no hay recurso si no se encuentra un buen nombre, por lo que el equipo puede tener que conformarse con nombres que no estén claros. La solución a este defecto es que los diseñadores piensen en la claridad de las funciones y los títulos de las pantallas en las primeras fases del proceso de diseño.
Las funciones y los títulos de las pantallas deben centrarse en las tareas más habituales que realizan los clientes. Los diseñadores suelen caer en la tentación de ofrecer enormes cantidades de funcionalidades en un intento de satisfacer al mayor número de clientes, además de los deseos del propio equipo de diseño. Sin embargo, las funciones adicionales siempre añaden complejidad y otros costes.
El título de la pantalla indica la claridad del diseño
En el modelo IUI, los diseñadores eligen los títulos de las pantallas en las primeras fases del proceso de diseño. En lugar de elegir un título para justificar el funcionamiento de la pantalla, el título se usa para determinar si la pantalla tiene sentido. Si no se encuentra ningún título adecuado, la característica se rediseña. Si el diseño no permite un título claro y conciso (es decir, si no hay forma de explicar la característica), los diseñadores podrían abandonar la característica. En las siguientes capturas de pantalla, compare la pantalla de pago de facturas de Money 99 de la izquierda, que proporciona una etiqueta estática para la página ("Próximas facturas y depósitos"), y la pantalla correspondiente de Money 2000 de la derecha, que tiene un título explícito ("Haga clic en la factura que desea pagar"):
Un título de pantalla, que por supuesto no es más que una frase u oración, es más fácil de cambiar que un diseño o un código. A pesar de este hecho, la experiencia con la IUI ha demostrado que insistir en un título de pantalla claro desde el principio produce mejores diseños. Los títulos deben elegirse con las aportaciones de los miembros del equipo de formación de usuarios y usabilidad, así como de los diseñadores del producto.
A veces, los miembros del equipo intentan aplazar esta decisión, dando por sentado que los clientes compartirán su interpretación de la finalidad de una pantalla. Sin embargo, cuando se les obliga a ofrecer una declaración clara y concisa de este propósito, a menudo se ponen de manifiesto diferencias de opinión. Si se resuelven estas diferencias y se elige un título en una fase temprana, las discusiones sobre el diseño pueden avanzar sin problemas.
Una vez elegido un título, no debe considerarlo inmutable. Es probable que los diseñadores perfeccionen los títulos de las pantallas con el tiempo, como ocurre con cualquier diseño. Sin embargo, el primer título elegido debe ser lo más sólido posible en esa fase de desarrollo.
Pautas para elegir los títulos de las pantallas
Esta sección describe una técnica sencilla para elegir buenos títulos de pantalla. Para usar esta técnica, los diseñadores imaginan que un amigo les pregunta: "¿Para qué sirve esta pantalla?", y luego se les ocurre una respuesta clara y útil que complete la frase: "Esta es la pantalla donde tú...". Las palabras que completan la frase se convierten en el título de la pantalla.
Durante el desarrollo de Money 2000, los redactores de documentación del equipo crearon unas directrices sobre títulos de pantalla para garantizar la calidad y la coherencia. Por ejemplo, estas directrices sugerían títulos con verbos y redactados como preguntas o instrucciones directas. Los diseñadores evitaban los nombres estáticos que permitían una mayor abstracción y podían resultar imprecisos.
Para simplificar los títulos, los diseñadores evitaron las frases compuestas e intentaron usar un lenguaje coloquial, evitando términos incómodos y jerga. Si los diseñadores no pueden describir la tarea sin recurrir a las conjunciones ("y", "o"), es probable que la pantalla intente realizar más de una tarea y es menos probable que el usuario pueda comprender inmediatamente qué hacer.
Incluso cuando se elige cuidadosamente un título, la región del título puede ser demasiado pequeña para explicar adecuadamente una tarea compleja. Para paliar este problema, puede incluir un breve párrafo descriptivo en la parte superior del área de contenido de la pantalla que detalle la tarea.
La siguiente tabla contiene algunos ejemplos de títulos de pantalla en Money 99 y títulos para las mismas pantallas o pantallas relacionadas en Money 2000.
| Títulos de pantalla en Money 99 | Nuevos títulos de pantalla en Money 2000 | Comentario |
|---|---|---|
| Administrador de cuentas |
Elegir una cuentaConfigurar las cuentas |
Título estático cambiado a títulos activos. |
| Detalles de la cuenta | Cambiar la configuración de la cuenta | Título estático cambiado a título activo y específico. |
| Calendario de pago | Pago de una factura | Título impreciso hecho descriptivo. |
| Administrador de servicios financieros en línea | La página no es necesaria después del rediseño. |
Resaltar el título de la pantalla
Una vez elegido un título de pantalla útil, es importante asegurarse de llamar la atención del usuario. Algunos estudios han demostrado que los usuarios rara vez leen textos instructivos. Para ayudar a superar este problema, los títulos de pantalla deben diseñarse de forma que sean prominentes y atractivos para llamar la atención del usuario. El diseño visual de la pantalla debe informar al usuario de que el título es lo más importante que debe leer.
Paso tres: hacer que el contenido de la página se adapte a la tarea
Cuando se crea software que sigue las directrices de la IUI, el trabajo de diseño más duro suele consistir en dividir las funciones en pantallas o páginas. El siguiente paso es determinar qué controles se utilizarán en cada pantalla para realizar su tarea principal. Estos controles conforman el contenido de la página, donde el usuario realiza su trabajo. El título y el contenido de la pantalla son dos mitades de un diálogo entre el programa y el usuario. El título plantea la pregunta del programa o da una instrucción y el usuario responde a través de la interfaz de la pantalla.
Si el título de la pantalla es claro y simple, el diseño de la pantalla suele ser sencillo. Por ejemplo, una de las pantallas de Money 2000 mostradas anteriormente se titula "Elegir una cuenta para usar". Dado este título, la pantalla obviamente debería contener una lista sencilla de cuentas entre las que el usuario puede elegir. Otra pantalla Money 2000 tiene el título "Comprobar los artículos que se van a incluir en sus impuestos". Naturalmente, esta pantalla contiene una lista de comprobación de elementos.
Los usuarios deben poder averiguar fácilmente cómo utilizar los controles para realizar la tarea principal de la pantalla. Cuando a los usuarios se les dice que seleccionen una cuenta y pueden buscar en la pantalla una lista de cuentas, confirman que han entendido la tarea. Esto aumenta la probabilidad de que los usuarios tengan éxito, lo que también aumenta su confianza a la hora de realizar otras tareas.
Áreas de contenido de pantalla
La ubicación exacta y la forma de las áreas de contenido de la pantalla dependen del diseño del software. En Money 2000, la región de contenido de la pantalla es todo lo que hay debajo del título de la pantalla y a la derecha de la lista de tareas. Esta región puede desplazarse en pantallas largas. Algunos contenidos no esenciales también pueden aparecer en el área de estado debajo de la lista de tareas.
Los diseñadores pueden optar por detallar la tarea principal de la pantalla en un párrafo situado en la parte superior de la región de contenido. Los usuarios nunca están obligados a leer este texto, pero puede resultarles útil. Muchos usuarios pueden omitirla y seguir usando la pantalla correctamente. A diferencia del título, esta descripción puede desplazarse si la pantalla es desplazable. Para obtener más información, consulte Directrices para elegir títulos de pantalla.
Si los diseñadores quieren que una página muestre recordatorios no esenciales, alertas u otra información de estado, se puede mostrar a la izquierda del área de contenido principal, bajo la lista de tareas en el lado izquierdo de la pantalla. Funcionalmente, esta área de estado es una región adicional para el contenido de la pantalla. Esta área no es lo suficientemente destacada como para contener controles esenciales.
Proporcionar una salida clara de la página
Después de completar correctamente una tarea, el usuario se enfrenta a otro problema: cuándo y cómo salir de la pantalla. En las pantallas cuya tarea principal es la navegación, la realización de la propia tarea desplaza al usuario a la pantalla siguiente. En otras pantallas, puede ser más difícil que el usuario sepa cómo continuar. Por ejemplo, en una pantalla en la que se pide al usuario que introduzca información en campos,el usuario puede necesitar ayuda para saber cuándo y cómo seguir adelante. En estas páginas, a menudo resulta útil ofrecer un botón claro Siguiente o Listo en una ubicación coherente.
Los estudios de usabilidad han demostrado que los usuarios prefieren usar estos botones incluso cuando los botones de navegación globales, como los botones Atrás o Inicio de una barra de herramientas, están disponibles. A menudo, los usuarios se sienten incómodos en pantallas sin una salida clara, incluso en pantallas cuyo único propósito es proporcionar información para ser leída.
Para obtener más información sobre este tema, consulte Proporcionar una manera sencilla de completar una tarea e iniciar una nueva en la sección Directrices adicionales.
Paso cuatro: ofrecer vínculos a tareas secundarias
El último paso en el diseño de una pantalla es proporcionar vínculos a tareas secundarias, que son funciones que no realizan directamente la tarea principal, pero que están relacionadas con la pantalla. Por ejemplo, si la tarea principal en una pantalla es escribir una carta, las tareas secundarias en esa pantalla pueden ser buscar una dirección postal o imprimir un sobre.
Las tareas secundarias pueden abrir cuadros de diálogo, cambiar la presentación visual del contenido de la pantalla o navegar al usuario a otra pantalla. Una tarea secundaria puede cumplir indirectamente la tarea principal o puede redirigir a los usuarios perdidos al lugar que están buscando.
Si una página es una conversación entre el equipo y el usuario, una tarea secundaria permite al usuario omitir la pregunta actual del equipo y hacer que haga algo más en su lugar. Por ejemplo, imagine este diálogo: Equipo: "¿Qué factura quiere pagar?" Usuario: "En realidad, lo que quiero es encontrar una factura que pagué hace tiempo".
Algunas pantallas del producto no tendrán tareas secundarias, mientras que otras tendrán varias. Debe evitar crear una larga lista de tareas que probablemente resulten difíciles de escanear para el usuario. Si una pantalla tiene una lista relativamente larga de tareas secundarias, las más comunes deben colocarse en primer lugar, agruparse en una sección separada o destacarse visualmente de otro modo.
La lista no debe incluir todas las tareas secundarias imaginables, siempre que haga evidente el siguiente paso de navegación. En lugar de ofrecer muchas tareas secundarias, una pantalla puede proporcionar tareas secundarias que navegan a páginas subsidiarias que enumeran más tareas.
Diseño visual de tareas secundarias
Las tareas secundarias deben figurar en una posición subordinada en la pantalla, donde sean accesibles en caso necesario pero no distraigan al usuario de la tarea principal. Colocar esta lista en una posición coherente en cada pantalla ayuda a los usuarios a encontrarla rápidamente cuando la necesitan.
Si muestra la lista de tareas secundarias en el lado izquierdo de la pantalla, la propia lista no debe ser desplazable, ni debe desplazarse nunca con la página, como se muestra en la siguiente captura de pantalla Pago de factura de Money 2000.
Directrices adicionales
En esta sección se describen cinco directrices útiles para crear una IUI según los cuatro pasos descritos en la sección anterior.
Uso de plantillas de pantalla coherentes
Cuando diseñe software que sigue al modelo de IUI, debe crear una plantilla para usarla como guía para cada pantalla. El modelo inductivo no dicta que use ninguna plantilla determinada. Hay muchas variaciones posibles que pueden satisfacer un diseño inductivo. Es posible que el producto solo necesite una plantilla para todas sus pantallas, o puede crear varias plantillas diferentes con varios fines.
Una buena plantilla permite a un nuevo usuario comprender rápidamente cómo funcionan las pantallas del producto. El uso coherente de la plantilla en las pantallas del producto proporciona un buen flujo de interfaz de usuario de la pantalla a la pantalla. A medida que los usuarios aprenden a esperar que aparezcan los mismos elementos en los mismos lugares, pueden examinar y empezar a usar cada nueva pantalla más rápidamente.
Proporcionar pantallas para iniciar tareas
Los productos diseñados con IUI suelen utilizar pantallas especiales diseñadas para iniciar a los usuarios en conjuntos de tareas. Estas pantallas se denominan páginas de actividades porque organizan grupos relacionados de tareas comunes. Las páginas de actividades constituyen un punto de partida para los usuarios. Normalmente, una página de actividad presenta vínculos a otras páginas en las que el usuario realmente realiza el trabajo. Las páginas de actividad preguntan al usuario "¿Qué desea hacer ahora?" y presentan una lista de posibles respuestas. Las páginas de actividad pueden seguir una plantilla especial para ayudar a los usuarios a reconocerlas.
Una página de actividades es una buena página de inicio predeterminada para un producto. Cuando los usuarios inician una aplicación, suelen tener una idea en mente sobre la tarea que quieren realizar. Por lo general, la razón para poner en marcha el producto es una de un pequeño número de tareas muy comunes. La página de inicio predeterminada del producto lo reconoce, haciendo evidente cómo empezar las tareas comunes.
La página Inicio de Money 2000 es un ejemplo de página de actividades. De manera predeterminada, los usuarios ven esta pantalla, donde se muestra el acceso a tareas financieras comunes como pagar una factura y cuadrar una cuenta, cuando inician la aplicación.
En la captura de pantalla siguiente se muestra la página Inicio de Money 2000.
Dado que Money proporciona muchas características financieras, solo las tareas financieras más comunes encajan en la página Inicio . Para todas las demás tareas, la página Inicio se vincula a un conjunto subsidiario de páginas de actividad denominadas centros financieros. Cada área importante de Money proporciona un centro financiero. Estas pantallas presentan el siguiente nivel de tareas y sirven de punto de partida para todas las funciones de cada área.
Por ejemplo, el área Impuestos contiene las características relacionadas con los impuestos del producto. El área Impuestos ofrece vínculos a estas características en una página del Centro de impuestos, como se muestra en la siguiente captura de pantalla.
Una página de actividades también puede ser mucho más sencilla si hay menos opciones disponibles. La siguiente captura de pantalla muestra cómo podría utilizarse una página de actividad para gestionar cuentas de usuario de Windows.
Hacer evidente cómo realizar la tarea con los controles en pantalla
La mejor manera de seguir esta pauta es elegir un título de pantalla apropiado y limitar el alcance de las tareas principales solo a las más comunes. Una vez que tenga claro el título y el propósito de la página, elegir el conjunto adecuado de controles será sencillo.
Proporcionar una manera sencilla de completar una tarea e iniciar una nueva
El último obstáculo al que se enfrenta un usuario en una pantalla es averiguar cuándo y cómo salir de ella. El usuario suele salir de la pantalla haciendo clic en un vínculo o ejecutando un comando que le lleva a otra pantalla. Estos vínculos pueden aparecer en el área de contenido de la pantalla, en la lista de tareas o en las barras de herramientas de navegación. Los usuarios también pueden salir de una pantalla cerrando el archivo actual o la propia aplicación.
En algunas pantallas, la tarea consiste en preparar una operación que el usuario debe confirmar o cancelar. Estas pantallas suelen ofrecer un vínculo que realiza y confirma la operación, y otro vínculo que la cancela. Si el usuario omite estas opciones y hace clic en otro vínculo, el programa debe realizar la opción menos destructiva. Las pantallas deben indicar lo que ocurrirá si el usuario toma esta ruta de acceso. Puede redactar los vínculos para que esto sea más evidente. Por ejemplo, un botón de confirmación etiquetado como "Guardar cambios" implica que los cambios realizados en la pantalla no surtirán efecto hasta que se haga clic en ese botón.
Aunque los usuarios puedan salir cuando quieran, puede ofrecer un vínculo que sugiera una salida evidente de la página. Lo mismo sucede con las páginas que simplemente muestran información estática. Para obtener más información sobre este asunto, consulte la sección Proporcionar una salida clara de la página.
Inicio y finalización de procesos
A efectos de este artículo, los procesos son técnicas para tratar tareas que llevan al usuario a más de una pantalla.
Supongamos que un usuario hace clic en un vínculo del contenido de una pantalla o de una lista de tareas y es conducido a otra pantalla. Esa página, a su vez, puede ser la primera de una serie de pantallas que logran algún resultado global. Al final de esta serie de pantallas, el usuario desea volver a la pantalla que precedió al proceso. Hay al menos dos maneras de que el usuario pueda volver. hacer clic en el botón Atrás repetidamente o volver a la página principal y navegar desde allí pero ninguno de estos métodos es evidente o natural. La mayoría de los usuarios esperan encontrar un botón en la pantalla final que les devuelva directamente a la pantalla original.
El modelo de IUI admite este escenario mediante el concepto de un proceso, una pantalla o una serie de pantallas tratadas como una unidad de navegación. Los usuarios pueden entrar en el proceso, recorrer sus pantallas y, en la última, encontrar un botón que les devuelve al punto de partida. Y lo que es más importante, el usuario puede iniciar el proceso desde varios puntos del producto. Los usuarios siempre vuelven al punto de partida, independientemente de dónde se encontraran al iniciar el proceso.
Nombre del proceso
Cada proceso debe tener un nombre y el nombre debe aparecer en algún lugar de cada pantalla del proceso. Money 2000 usa este enfoque. Cada pantalla que forma parte de un proceso global incluye el nombre de ese proceso en la parte superior. Este nombre de proceso se muestra de forma menos prominente que el título único de la pantalla porque es menos importante. El nombre del proceso recuerda a los usuarios qué proceso están llevando a cabo y refuerza la noción de que todas las pantallas del proceso forman parte de una única función. Por ejemplo, el área Impuestos sobre el dinero incluye un proceso Estimador de impuestos de impuestos que abarca varias pantallas. Cada pantalla de este proceso muestra el nombre del proceso colectivo y su título de pantalla único.
Implementación de procesos
El mismo proceso puede iniciarse desde varios vínculos en diferentes pantallas y los usuarios siempre volverán a la página de inicio correcta. Este comportamiento no se puede lograr a través de un vínculo codificado de forma rígida en la pantalla final del proceso, ya que el destino del vínculo variará. En su lugar, la aplicación puede implementar este comportamiento manteniendo una pila de procesos activos, independientemente de la pila de navegación normal que usan los comandos Atrás y Adelante. Cuando el usuario inicia un proceso, la pantalla de inicio se inserta en la pila de procesos. Cuando el usuario hace clic en el botón Listo en la pantalla final del proceso, la aplicación abre la pantalla de inicio más reciente de la pila y devuelve al usuario a esa pantalla.
Cuando los usuarios se alejan de una pantalla de un proceso, este permanece activo en la pila de procesos. Los usuarios pueden completar el proceso de copia de seguridad en la pantalla donde lo dejaron y, a continuación, continuar. Esto permite a los usuarios dar un rodeo, retroceder y continuar con el proceso. Para ver cómo funciona este comportamiento, inicie cualquier proceso de compra en línea en World Wide Web, salga del sitio y pulse el botón Atrás. Por lo general, podrá continuar donde lo dejó.
Botón Listo
Para finalizar una pantalla y pasar a la siguiente del proceso, las pantallas pueden mostrar un botón cerca de la parte inferior de la página. La etiqueta de este botón es "Siguiente", "Listo" o algo similar. Si el botón finaliza el proceso y se puede llamar al proceso desde varias ubicaciones, el subtítulo del botón Listo puede incluir el nombre de la ubicación de llamada.
Barra de navegación
En cualquier pantalla, los usuarios pueden decidir que han terminado con el área actual del producto y quieren empezar otra cosa. Es posible que no quieran completar explícitamente la pantalla actual antes de pasar a otra parte del producto. Una barra de navegación puede ofrecer al usuario un conjunto de vínculos para iniciar nuevas tareas. Al igual que ocurre con otras listas de vínculos de tareas, estas deben seguir el principio de hacer obvio el siguiente paso de navegación, que se analiza en detalle en la siguiente sección.
Hacer que el siguiente paso de navegación sea evidente
Algunos programas pueden hacer que todas sus características estén disponibles al mismo tiempo. Los usuarios generalmente deben navegar por un programa para encontrar una característica determinada. Los usuarios tienen más éxito en la navegación si pueden ver fácilmente cómo acercarse al menos un paso al resultado deseado. Las pantallas que usan la IUI se diseñan teniendo en cuenta este principio.
Por ejemplo, las páginas de actividades no muestran necesariamente todas las tareas o destinos imaginables que el usuario podría querer alcanzar desde ese punto. En su lugar, las páginas de actividades proporcionan una lista de tareas lo suficientemente completa como para que los usuarios puedan determinar fácilmente el vínculo adecuado en el que hacer clic, aunque solo les lleve a otra página de vínculos. Las tareas más frecuentes deben ser las más destacadas y requerir la menor cantidad de navegación. Las tareas menos frecuentes pueden requerir más pasos.
Este es un ejemplo de Money 2000. Supongamos que los usuarios desean realizar una operación que solo hacen ocasionalmente, como comprobar el importe estimado del pago del impuesto sobre la renta del próximo año. Los usuarios empiezan buscando esta característica en la página de inicio de Money 2000. Como la característica no aparece en la lista de tareas comunes, deben explorar la lista de áreas financieras. El área Impuestos parece prometedora, así que hacen clic en ella. La página Centro de impuestos contiene un vínculo a la característica de estimación fiscal que buscan, por lo que hacen clic en él y completan su tarea. Al aplicar los principios de la IUI, Money 2000 permite a los usuarios encontrar intuitivamente lo que buscan.
Asistencia al usuario
Esta sección describe un conjunto de directrices sugeridas para integrar el texto de asistencia al usuario en un producto que utiliza la IUI.
La asistencia primaria se refiere a todo el texto visible en la pantalla (como se muestra en la siguiente captura de pantalla). La asistencia primaria proporciona pistas textuales centradas en la tarea para que los usuarios puedan comprender fácilmente toda la información presentada en la pantalla. Comprenden la finalidad de la página y la forma en que los objetos se relacionan entre sí para ayudar a realizar las tareas. Como el texto está directamente en la pantalla, la información que responde a preguntas de principiante como "¿Qué debo hacer?" es de fácil acceso y muy visible sin que el usuario tenga que realizar ninguna acción.
La asistencia secundaria consiste en todo el texto que no es visible en la pantalla y que requiere alguna interacción del usuario para acceder a él, como hacer clic o pasar el ratón por encima de un elemento de la interfaz de usuario. Este contenido no es esencial para llevar a cabo la tarea en cuestión, pero sigue estando directamente relacionado.
Asistencia primaria
La asistencia primaria puede incluir algunos o todos los componentes siguientes:
Título de pantalla
Ejemplo: Cambiar la imagen
El título de la pantalla es lo primero y más importante que aparece en ella. Su objetivo es describir en el propio idioma del usuario la tarea que se puede completar en esta página. El título de la pantalla debe evitar describir los detalles de cómo completar la tarea. El texto del título de la pantalla solo debe hacer referencia a la tarea principal de la pantalla. Por regla general, cuanto más sencilla y breve sea la descripción de la tarea, mejor definida estará. Para obtener más información detallada sobre este tema, consulte Paso dos: Enunciar la tarea.
Subtítulo de pantalla
Ejemplo: también puede descargar una imagen nueva desde Internet.
Incluso con un esfuerzo cuidadoso, el título de la pantalla puede no ser suficiente para explicar adecuadamente una tarea compleja. El subtítulo permite explicar con más detalle el propósito de la pantalla. Puede usar un subtítulo para ayudar a aclarar el propósito de la página, proporcionar una descripción adicional de la tarea o ayudar a establecer expectativas. Los usuarios que no lean el subtítulo deberían poder utilizar la página correctamente. Al igual que el título, el subtítulo debe evitar describir detalles para completar la tarea.
Tareas
Ejemplo: Cambiar el protector de pantalla
Las tareas se pueden presentar como vínculos de texto o imágenes gráficas que requieren la interacción del usuario. Los comandos que se presentan como enlaces de texto deben estar basados en verbos y redactados como tareas claras y concisas.
Etiquetas para botones de comando
Ejemplo: Crear contraseña
Hay tres tipos de botones de comando:
- Cancelar
- Listo
- Commit
Los botones Cancelar y Listo simplemente usan "Cancelar" y "Listo" como etiquetas. Los botones de confirmación deben usar etiquetas de texto activo en lugar de "Aceptar". Por ejemplo, use "Crear contraseña" en lugar de "Aceptar".
Etiquetas para otros controles
Ejemplo: Escriba la contraseña
Las etiquetas de controles como los botones de opción, las casillas de verificación y los cuadros de texto deben redactarse de forma clara y concisa para que los usuarios sepan exactamente para qué sirven los controles, cuáles usar y qué información deben proporcionar para realizar su tarea.
Vínculos "Tareas relacionadas"
Ejemplo: Tareas relacionadas - Cambiar otra cuenta
Los vínculos "Tareas relacionadas" son puntos de entrada explícitos a otras tareas relacionadas con la característica actual. Deben escribirse como vínculos basados en tareas.
Vínculos "Consulte también"
Ejemplo: Consulte también - Cambiar tema
Los vínculos "Consulte también" son tareas secundarias. Están relacionadas con la tarea principal, pero sacan al usuario del contexto actual. Estos deben aparecer como vínculos de tareas normales. Para obtener más información sobre las tareas secundarias, consulte Diseño visual de tareas secundarias.
Asistencia secundaria
La asistencia secundaria puede incluir algunos o todos los componentes siguientes:
InfoTips
Puede utilizar un recuadro informativo para proporcionar al usuario información adicional sobre un enlace de tarea o un botón de comando. Por ejemplo, un recuadro informativo en un vínculo de tarea podría decir: "Muestra una página donde puede elegir una foto para usar con su cuenta". El recuadro informativo aparece cuando el usuario pasa el ratón por encima del objeto asociado. Debe crear recuadros informativos para todos los elementos de la interfaz de usuario en los que el usuario pueda hacer clic.
Temas de ayuda "Más información"
Ejemplo: Más información - Descarga de un archivo
Los vínculos "Más información" abren temas de ayuda como descripciones generales de características, información conceptual, información de soporte técnico e información de procedimiento. Para reducir el desorden, debe minimizar el número de temas de ayuda "Más información" en la pantalla.
Apéndice: Diseño y prueba de Microsoft Money 2000
Para reducir el desorden, debe minimizar el número de temas de ayuda "Más información" en la pantalla. Describe cómo el equipo de Money 2000 modificó el proceso de diseño y pruebas para adaptarlo al modelo de IUI.
Diseño y prueba de Money 2000
Diseñar Money 2000 usando el modelo de navegación inductiva llevó al equipo a cuestionar diseños que llevaban mucho tiempo en el producto. Como los principios del modelo son sencillos, fue fácil adoptarlo en el proceso de diseño y seguir con él. Al final, los diseñadores creen que el modelo les ayudó a hacer mejores diseños de los que podrían haber producido sin él.
Títulos y diseños más claros
Los diseñadores de Money 2000 se dieron cuenta de que a menudo se describían características usando palabras que en realidad no aparecían en la pantalla. En el modelo IUI, las pantallas deben explicarse por sí mismas. Por ejemplo, el equipo explicó que la pantalla con la etiqueta Calendario de pago estaba pensada para pagar facturas. En Money 2000, esa pantalla se denomina Pagar facturas. Todos los elementos no relacionados con ese propósito se han trasladado a pantallas subsidiarias, lo que ha dado lugar a un diseño más claro.
Otro ejemplo implica una pantalla denominada Administrador de servicios financieros en línea. Al equipo le costó encontrar una explicación sencilla del propósito de esta pantalla. Cuando no pudieron llegar a una, eliminaron esta pantalla y distribuyeron sus características entre páginas más lógicamente definidas.
Ayudar a los nuevos diseñadores
Al equipo le resultó fácil enseñar técnicas de diseño de IUI a diseñadores de software nuevos y sin experiencia. Las técnicas permitieron a diseñadores de todos los niveles de experiencia evaluar sus diseños utilizando títulos de pantalla como prueba de claridad. Cuando se vieron obligados a poner un título claro y conciso en una pantalla mal diseñada, los diseñadores reconocieron rápidamente que ningún título era suficientemente bueno para la página. Se dieron cuenta de que el problema no radicaba en la elección de palabras para un título, sino en un diseño defectuoso de la pantalla. De este modo, podían rediseñar la pantalla para que la interacción con el usuario fuera más clara y, por tanto, el título también.
Redactores incluidos
A medida que avanzaba el diseño, el equipo se dio cuenta de que los redactores y editores de documentación debían participar en la creación de los títulos de las pantallas. En ediciones anteriores, los redactores tenían una capacidad limitada para elegir buenos títulos porque solo participaban en una fase tardía. Los diseñadores o programadores solían poner títulos provisionales a las pantallas. Estos títulos se usaron hasta el final del ciclo del producto, cuando se pidió a los guionistas que propusieran los títulos definitivos para las pantallas. En ese momento, era demasiado tarde para rehacer pantallas mal diseñadas.
En cambio, el equipo de Money 2000 implicó a los escritores en las primeras fases del proceso de diseño. Esto aportó una valiosa información sobre los títulos de las pantallas cuando aún podía ayudar al diseño. Si una pantalla era demasiado compleja para permitir un título claro, los redactores podían sugerir que se rediseñara la página.
Al final del proyecto, los guionistas y diseñadores creían que los títulos de pantalla eran más claros y contundentes que en las versiones anteriores. A los redactores también les resultó más fácil explicar las nuevas páginas, lo que simplificó el trabajo de documentación del producto. Todos los miembros del equipo pensaban que implicar a todas las disciplinas en la fase de diseño mejoraba el producto y facilitaba su uso.
Pruebas de usabilidad
Durante el desarrollo de Money 2000, el equipo realizó varias pruebas de usabilidad para observar las diferencias entre la antigua estructura de navegación de Money 99 y los cambios realizados como resultado de la aplicación del modelo IUI.
Prueba de prototipos
En las primeras fases del proceso de desarrollo del producto, los diseñadores crearon un prototipo para explorar cómo reaccionarían los usuarios ante la IUI. Este trabajo se realizó en una fase muy temprana del proceso de desarrollo para dar tiempo a perfeccionar los principios del modelo antes de que los programadores empezaran a revisar el producto en sí.
El equipo creó un prototipo en Microsoft Visual Basic y HTML que simulaba actividades de finanzas personales realizadas normalmente en Money. En el prototipo, los usuarios podían navegar por más de 50 páginas que representaban las principales áreas del producto. En estas áreas, podían crear cuentas financieras, pagar facturas, consultar informes y trabajar con sus inversiones.
Once participantes realizaron el mismo conjunto de tareas tanto en Money 99 como en el prototipo IUI. Se les asignó aleatoriamente usar primero uno de los productos. Cuatro participantes eran usuarios actuales de Money, cuatro de un producto de la competencia y tres no habían usado nunca un producto de finanzas personales.
Las preferencias generales indicaron que los cuatro usuarios actuales de Money preferían Money 99 (la versión que venían utilizando en casa), mientras que los siete usuarios restantes preferían el nuevo prototipo a la versión actual. En todas las demás medidas, no hubo diferencias entre los usuarios de los tres grupos. En términos de rendimiento global, los usuarios se equivocaron de zona del producto el doble de veces con Money 99 (2,82 veces por tarea) que con el prototipo (1,45 veces por tarea). Otros datos sobre preferencias y medidas de rendimiento, aunque no significativos, parecían favorecer al prototipo. Basándose en estos datos y en otras pruebas, el equipo de producto de Money decidió incorporar los principios de IUI en Money 2000.
Prueba de productos
Una vez completada la mayor parte del código del producto, el equipo realizó otro estudio de usabilidad para examinar la implementación final de la IUI. En esta prueba, 10 participantes que nunca antes habían utilizado un producto de finanzas personales fueron seleccionados para utilizar Money 99 o Money 2000. Todos los usuarios realizaron las mismas tareas.
Los usuarios de Money 2000 completaron con éxito el 89 % de las tareas, mientras que los de Money 99 solo el 74 %. Al igual que en el prototipo, los usuarios también parecían ser más rápidos, aunque no significativamente diferentes, a la hora de navegar en Money 2000 en comparación con Money 99. Además, las medidas globales de satisfacción subjetiva de la navegación también tendieron a ser más altas para Money 2000 que para Money 99.
Pruebas controladas
Dado que Money 2000 es enorme y complejo, no se presta bien a la realización de experimentos controlados sobre los efectos de la aplicación de la IUI. En su lugar, el equipo creó un entorno más restringido para la prueba.
La prueba implicaba una aplicación "Visor de mercado de valores" que permitía a los usuarios modificar la visualización de un informe de mercado de valores mostrado en la pantalla. Los usuarios podían cambiar qué columnas de datos se incluían en el informe, el orden de las columnas del informe, su alineación y el número de decimales usados. Los diseñadores querían ver cómo funcionaría un enfoque de IUI para esta tarea en comparación con una interfaz gráfica de usuario convencional.
En la captura de pantalla siguiente se muestra la interfaz de usuario convencional que se usa en la prueba. Un único cuadro de diálogo realiza todas las tareas de personalización de informes. Muchas aplicaciones proporcionan un cuadro de diálogo similar para seleccionar un subconjunto de una lista de elementos. El cuadro de diálogo contiene dos listas: la de la izquierda muestra todas las columnas disponibles para el informe, y la de la derecha muestra el subconjunto de columnas que el usuario ha seleccionado para el informe. Los controles adicionales modifican el orden y los atributos de formato de las columnas del informe seleccionadas en la lista de la derecha.
Para la versión de IUI de esta tarea, el equipo creó una aplicación de estilo web. Cada tarea de personalización se ha colocado en una página independiente. La aplicación también incluía una página principal, mostrada en la siguiente captura de pantalla, que pregunta a los usuarios cómo quieren personalizar el informe.
Al hacer clic en los vínculos de esta página principal, el usuario accede a páginas adicionales para realizar tareas de personalización específicas. Por ejemplo, la captura de pantalla siguiente muestra la página que se usa para seleccionar columnas de informe.
En las pruebas de ambas versiones, se pidió a los sujetos que personalizaran los informes desde un estado inicial determinado (mostrado en la pantalla) hasta un estado objetivo especificado (mostrado en un documento). El equipo realizó un seguimiento de la cantidad de tiempo y del número de intentos realizados para personalizar el informe. El ordenador informaba a los usuarios cuando habían personalizado correctamente el informe.
La prueba incluía 88 participantes. Se pidió a cada participante que personalizara un conjunto de 11 informes con una de las dos versiones de la aplicación. Además, 72 de estos participantes volvieron una semana después para personalizar otra serie de 11 informes usando la misma versión de la primera sesión. Todos los sujetos se clasificaron como usuarios principiantes, que usaban el equipo principalmente para el correo electrónico, jugar al solitario y navegar por Internet.
No hubo diferencias significativas entre los usuarios de las dos versiones ni en ninguna de las demás variables de interés. Los usuarios realizaron las tareas a la misma velocidad, repitieron la tarea el mismo número de veces y obtuvieron los mismos índices de satisfacción subjetiva general con las dos versiones. Esta prueba, por tanto, no mostró ninguna medida en la que la IUI supusiera una mejora o degradación del rendimiento o de las valoraciones subjetivas.
Podría argumentarse que si el usuario tiene que navegar más para realizar la tarea, entonces la cantidad de tiempo para realizarla debería ser mayor. Aunque este experimento no sugiere este resultado, es importante señalar que los tiempos medios de rendimiento y sus desviaciones estándar asociadas para los dos enfoques diferentes de esta tarea fueron casi idénticos.
Será necesario seguir investigando para determinar si el uso de la IUI aporta mejoras cuantificables. Como mínimo, esta prueba no aportó ninguna prueba de que la IUI perjudique el rendimiento o el uso del producto.
Comparación con sitios web
Muchos sitios Web bien diseñados usan principios similares al modelo IUI descrito en este documento. Esto probablemente es un efecto secundario de la forma en que funciona web. Como es difícil implementar interacciones complejas entre controles en una sola página Web, los diseñadores suelen dividir las tareas en partes que implican más de un viaje al servidor para obtener una nueva página. Algunos sitios incluso incluyen títulos de página que indican claramente el propósito de la página.
Los diseñadores de aplicaciones tradicionales tienen un conjunto mucho más completo de herramientas disponibles. Esto les da más flexibilidad, pero también más oportunidad para crear páginas complejas y confusas. Al crear interfaces de usuario inductivas, los diseñadores deben usar este poder con discreción y recordar que hay que valorar la claridad y la sencillez.