En éste y los posteriores artículos se detallará con mas profundidad cada uno de los principios de interacción en diseño que expone Bruce Tognazzini.

Anticipación

Las aplicaciones deberían intentar anticiparse a las necesidades y deseos del usuario. No esperes que el usuario busque o recuerde información o herramientas. Muestra al usuario toda la información y herramientas necesarias para cada etapa en su trabajo.
Autonomía

El ordenador, la interfaz y el entorno de la tarea pertenecen al usuario, pero esto no significa que abandonemos todas las reglas.

Dale al usuario algo de “cancha”. Los usuarios aprenden rápido y ganan confianza cuando se sienten que tienen el control del sistema.

Pese a lo que pueda parecer, sin fronteras o restricciones el usuario no se siente libre (Yallum, 1980); es como un niño pequeño que llora cuando se le mantiene muy atado o se le deja en un edificio grande y vacío. Los adultos también se sienten más cómodos en un entorno ni muy restrictivo ni demasiado grande, un entorno explorable pero no peligroso.

Mantén informado al usuario del estado del sistema.

No existe autonomía en ausencia de control; y el control no se puede tener sin información suficiente. Comunicar el estado es fundamental para que el usuario responda apropiadamente con la información disponible.

Ejemplo: los trabajadores sin información del estado del sistema, tienden a mantenerse bajo presión durante cortos periodos de tiempo hasta que el trabajo se termina. Un estrés y fatiga innecesarios por lo que cuando venga la siguiente carga de trabajo, puede que los trabajadores no estén en las mejores condiciones físicas y mentales.

Mantén la información de estado fácilmente visible y actualizada.

Los usuarios no tienen que buscar la información de estado. De un vistazo deberían ser capaces de hacerse una idea aproximada del estado del sistema. La información de estado pude ser bastante sutil: el icono de la bandeja de entrada puede mostrarse vacía, medio llena o hasta los topes, por ejemplo. Sin embargo, no es conveniente abusar: el Macintosh utilizó durante años un icono de la papelera que parecía que iba a estallar en cualquier momento, aunque sólo tuviese un documento. Los usuarios adquirieron la costumbre de vaciar la papelera apenas contuviese un documento, convirtieron un proceso de un paso en uno de dos (primero llevamos el documento a la papelera, luego lo vaciamos). Esto tuvo el efecto negativo de reducir una de las funciones básicas de la papelera: la posibilidad de deshacer la acción.

Otro ejemplo posible de información de estado sería el de un una caja de búsquedas que cambiase de color para indicar si la búsqueda está todavía en marcha o si ya ha terminado, con demasiados resultados, con muy pocos o justos con lo necesario.

Daltonismo

Si utilizas el color para transmitir información debes utilizar otros elementos complementarios para la gente con daltonismo. Aproximadamente un 10% de los hombres adultos sufren daltonismo. Las pistas secundarias pueden consistir en distintos tonos de gris, gráficos complementarios o etiquetas de texto.

Consistencia

Los siguientes principios, vistos en su conjunto, dan al diseñador de interacción mucho margen para la evolución de un producto sin perjudicar los aspectos más importantes para el usuario.

Niveles de consistencia: mantener una consistencia estricta depende del caso. En la siguiente lista aparecen los elementos de la interfaz ordenados por su necesidad de consistencia, de mayor a menor. Mucha gente asume que el orden de los cinco primeros elementos es justo el contrario, dando lugar a aplicaciones que se parecen pero que se comportan de forma impredecible y totalmente distinta.

1. Interpretación del comportamiento del usuario. Ejemplo: los atajos de teclado deben funcionar siempre igual.
2. Estructuras invisibles.
3. Estructuras visibles pequeñas.
4. El aspecto general de una aplicación o servicio (presentación, elementos de diseño).
5. Una suite de productos.
6. Consistencia interna.
7. Consistencia con la plataforma.

Las estructuras invisibles se refieren a objetos como al botón izquierdo de Word, que tiene toda clase de propiedades y comportamientos, si es que alguna vez los descubres. A veces aparece y otras no, depende de tu versión de Windows; y si no aparece, nunca estarás seguro de si está o no, dado que es invisible. Por eso es tan importante la consistencia en los objetos invisibles.

Otros objetos en la interfaz se consideran visibles, pero muchas veces no parecen controles: es posible que el usuario nunca descubra que se pueden interactuar con ellos. Su significado, si decides utilizarlos, debería ser muy claro. “Por ejemplo, podemos hacer clic y arrastrar en una esquina de un ventana activa para cambiar su tamaño” pero no “a veces podemos hacer clic y arrastrar pero otras veces no”.

Las pequeñas estructuras visibles se refiere a iconos, flechas de desplazamiento, etc. Es necesario mantener su consistencia si no queremos que la gente se pase el día averiguando cómo se hace qué con estos objetos. Su posición en pantalla es ligeramente menos importante. Si tiene sentido estandarizar la posición, hazlo.

Inconsistencia: es tan importante ser visualmente incosistente con los objetos que se comportan de forma distinta, como ser consistente con los que se comportan de igual manera.

Evita la uniformidad. Haz que los objetos que se comportan distinto parezcan distintos.

La consistencia más importante es aquella que espera el usuario. La única manera de comprobar las expectativas del usuario es hacer pruebas con ellos.

Valores por defecto

Los valores por defecto deberían ser poder descartados con facilidad y rapidez. Los campos de texto con valores por defecto deben aparecer seleccionados, para que el usuario sólo tenga que teclear y no seleccionar todo, borrar y escribir.

Los valores por defecto deben tener sentido.

No uses la palabra “por defecto” en una aplicación o servicio. Utiliza “estándar”, “Usar valores habituales”, “Restablecer valores iniciales” o términos más específicos que describan lo que sucederá.