El principio de Visibilidad y el de Guiar en lugar de controlar: ¿son incompatibles?

El principio de visibilidad desarrollado por Donald Norman en su ya clásico libro La Psicología de los objetos cotidianos (1990) y el de guiar en lugar de controlar analizado por Alistair Sutcliffe en su obra Human-Computer Interface Design (1988) parecen contradecirse en algunos casos. Empezaré por definir ambos conceptos para después describir casos frecuentes y reconocibles por cualquier persona interesada en la usabilidad, casos en los que la aplicación estricta del segundo principio, guiar en lugar de controlar, influye negativamente sobre el principio de visibilidad.

Visibilidad

La visibilidad consiste en hacer que la interfaz de usuario muestre los componentes del modelo mental sobre el que se ha construido el sistema, es decir, que estimule los sentidos del usuario. Una interfaz puede construirse de muchas formas, pero es necesario que sus objetos se vean, se oigan o que presenten cualquier característica que los haga perceptibles para que el usuario no sólo pueda interactuar con el sistema sino que también se vaya formando un modelo mental correcto del mismo.

La visibilidad constituye un principio tan sensato que parece difícil que pueda incumplirse. Desgraciadamente, la realidad nos demuestra más a menudo de lo deseable lo fácil que resulta quebrantarlo. Por ejemplo, cada vez que no comprendemos un icono y dejamos reposar el puntero de nuestro ratón sobre él para que aparezca el milagroso tooltip informándonos sobre qué pasará cuando lo cliquemos estamos ante una clara vulneración del principio de visibilidad.

Vincent Flanders en su website explica con humor y claridad este tipo de infracción contra la visibilidad que se da con frecuencia en la navegación en la web. Incluso ha creado un término para designarlo: "Mystery Meat Navigation" . Una sugerencia, no dejes de ver el ejemplo del cartel de autopista que allí aparece: su absurdidad lo hace muy convincente.

Guiar en lugar de controlar

Guiar consiste en prevenir al usuario antes de que inicie una acción que le pueda perjudicar o que le deje el sistema en un estado que le impida al usuario alcanzar su objetivo. Controlar, en cambio, es impedir que el usuario termine un proceso a pesar de que el sistema sí le ha permitido no sólo iniciarlo sino también avanzar en él sin haberle advertido previamente de esta contingencia. Controlar es lo que todo informático que se precie hace bien.

Sutcliffe afirma que el principio de guiar en lugar de controlar tiene dos componentes:

� Predictibilidad: que consiste en que el usuario pueda suponer qué tiene que hacer a partir de un estado del sistema, y

� Reversibilidad: que consiste en que el usuario pueda dar marcha atrás cuando obtiene un resultado no deseado

Veamos un ejemplo para dejar bien clara la diferencia entre guiar y controlar. Imagina que necesitas comprar un teclado para tu ordenador. Ya tienes decidido qué teclado adquirir y vas a realizar la compra en un website dedicado a la venta de material informático. Supongamos también que en ese momento no hay existencias del teclado que deseas, por lo que el sistema impide que la compra se lleve a cabo, dado que el programador correspondiente se cuidó bien de controlar esa situación.

Otra cosa muy distinta es decidir en qué momento del proceso de compra conviene comunicar al comprador la imposibilidad de realizar la compra. El aviso se puede comunicar en diversas fases del proceso de compra dentro del rango delimitado por los dos siguientes momentos:

1.Tan pronto como el comprador realice la primera acción que identifique el modelo de teclado, con lo que el sistema ya dispone de la información necesaria para â??saberâ? que no hay existencias de éste; o bien

2.Después de que el comprador haya informado al sistema sobre los siguientes datos: nombre, dirección, número de teléfono y dirección de email del comprador, fecha de recepción del teclado, número y fecha de caducidad de la tarjeta electrónica; y, finalmente, claro está, el modelo y la cantidad de unidades del teclado; en ese momento, cuando solo resta confirmar la transacción y, de hecho, se han invertido ya más de 5 minutos en el proceso de compra, el sistema avisa de la imposibilidad de finalizar la compra.

En ambos supuestos se está controlando al usuario porque en los dos se impide que el comprador adquiera un teclado del que no se dispone. Ahora bien, sólo en el primer supuesto el sistema está guiando al usuario ya que le avisa desde el inicio de que no hay existencias del producto solicitado, es decir, le impide continuar un proceso que no podrá concluirse de manera satisfactoria. Además, el sistema puede igualmente sugerir al comprador otros procesos que sí va a poder realizar, como, por ejemplo, reservar el teclado deseado para cuando se reciban nuevas unidades o bien adquirir un teclado de un modelo similar que sí esté disponible.

Aplicaciones prácticas características del principio de guiar en lugar de controlar son habilitar y/o deshabilitar campos y botones según el estado del sistema, de forma que el usuario ve guiada su interacción con el mismo; de este modo sólo se le muestran los recursos adecuados en cada momento. Mostrar únicamente los recursos convenientes constituye una práctica aconsejable dado que reduce la complejidad con la que tiene que lidiar un usuario cuando se â??peleaâ? con una interfaz.

Ejemplo de campos y botones habilitados y deshabilitados

Pues bien, en algunos casos la aplicación del principio de guiar en lugar de controlar entra en contradicción con el principio de visibilidad porque dificulta que el usuario se forme un modelo mental correcto o, cuando menos, completo del sistema.

Casos en los que guiar disminuye la visibilidad

Como ya he mencionado anteriormente, una aplicación frecuente del principio de guiar en lugar de controlar consiste en la ocultación de componentes específicos de una interfaz cuando, para una situación concreta del sistema, no tiene sentido emplearlos. Un ejemplo típico de esta aplicación consiste en la habilitación/deshabilitación de campos y botones llegando incluso a hacerlos visibles/invisibles. Diferenciar los campos obligatorios de los opcionales constituye otra aplicación práctica de este mismo principio.

El sistema alcanza situaciones en las que puede ser recomendable deshabilitar u ocultar componentes de la interfaz de usuario cuando:

�Las características del propio sistema hacen que sea imposible realizar una operación (por ejemplo, si el equipo no dispone de impresora, no se puede imprimir ningún documento).

�Las características del usuario le inhabilitan para realizar determinadas acciones (por ejemplo, un usuario que no tenga perfil de administrador no podrá crear una nueva cuenta de usuario).

�El estado del propio sistema hace que sea imposible realizar una operación en un momento determinado (por ejemplo, si el equipo pierde la conexión con el servidor no podrá realizarse ninguna acción que requiera acceder a la base de datos).

Cuando un componente se muestra deshabilitado, el sistema no está informando del motivo por el cual no se encuentra disponible. En cambio, si el componente está habilitado, cuando el usuario lo utilice, el sistema tendrá que validar, es decir, controlar, si es correcto usarlo y, en caso que no lo sea, mostrará un mensaje de error indicando que no puede usarse ese componente. Además, si el programador ha aplicado buenas prácticas de redacción de mensajes, informará también del motivo por el que no está disponible. Esta explicación ayudará al usuario a formarse un modelo mental correcto y más completo del sistema.

Por ejemplo, imagina una pantalla con un botón â??Crearâ? que se muestra habilitado. Si al accionarlo, te aparece un mensaje informándote de que no estás autorizado a realizar la acción de â??Crearâ? habrás enriquecido tu modelo mental del sistema, puesto que gracias a ello vas a saber que:

1.El sistema soporta la acción de â??Crearâ?.
2.Para realizar esa acción hace falta cierto nivel de autorización.
3.Tú no tienes el nivel de autorización necesario para realizarla.
4.Hay alguien que sí puede llevarla a cabo.

Por el contrario, si el botón â??Crearâ? se muestra deshabilitado, sólo habrás aprendido que el sistema soporta esa acción en algún caso, pero no sabrás en cual ni tampoco el motivo por el que tú no puedes realizarla.

En el peor de los casos, cuando el botón está oculto, no sólo no vas a aprender nada nuevo sobre el sistema sino que, además, vas a dudar de si el sistema soporta en algún caso la acción de â??Crearâ?.

Cuándo conviene guiar y cuándo es mejor controlar

El ejemplo anterior demuestra que en algunas ocasiones resulta mucho más informativo dejar que el usuario empiece una acción que no va a poder concluir que impedirle que inicie dicha acción. Es decir, resulta más adecuado controlar que guiar.

Esta afirmación no puede aplicarse en todas las situaciones. A continuación, intentaré establecer unos criterios que ayuden a decidir en qué casos es preferible guiar y en cuales controlar.

Cuándo es mejor guiar

A. Cuando el efecto de guiado (habilitar/deshabilitar, mostrar/ocultar, etc.) ocurre en el mismo contenedor (ventana, caja de diálogo, página web, etc.) de la interfaz de usuario donde se ha producido. En estos casos, el usuario puede experimentar con total libertad y observar directamente los efectos de guiado, dado que tales efectos constituyen la realimentación que el sistema genera como respuesta a las acciones del usuario.

Ejemplo de guiado dentro de una caja de diálogo
Obsérvese ahora el comportamiento de la caja de diálogo â??Imprimirâ? de Word que cambia su estado habilitando/deshabilitando campos según los valores de otros campos de la misma caja de diálogo.

Caja de diálogo â??Imprimir" en su estado inicial

Caja de diálogo â??Imprimir" cuando se escoge Página actual

Caja de diálogo â??Imprimir" cuando se escoge Resumen

B. También es mejor guiar cuando el control no aporta ninguna información al modelo mental que el usuario tiene del sistema. Un síntoma que permite identificar este tipo de casos es cuando el usuario percibe un mensaje de error como una molestia en lugar de como una ayuda.

Ejemplo de control que no mejora el modelo mental

En la aplicación de correo electrónico Lotus Notes (ver imagen arriba), cuando se inicia la acción de anexar un documento a un correo, el sistema valida que el cursor se encuentre en la zona de edición de texto del correo. Si el cursor está en cualquier otro campo (destinatario, asunto, etc) muestra el siguiente mensaje de error.

En este caso, sería deseable que el sistema iniciara directamente el diálogo para anexar un archivo al correo, tal como sí sucede en Outlook, porque, aunque resulta evidente que no tiene ningún sentido adjuntar un archivo sobre el campo destinatario, también es obvio que éste no era el objetivo del usuario. �l simplemente pretendía adjuntar un archivo al correo. Por consiguiente, en este caso el control no hace otra cosa más que entorpecer la tarea del usuario.

C. En general, también es recomendable guiar cuando los efectos de guiado no impiden que el usuario se forme un modelo mental correcto.

Cuándo es mejor controlar

A.Cuando la causa y el efecto de guiado no se encuentran en el mismo contenedor (ventana, caja de diálogo, página web, etc.) de la interfaz de usuario. En tal situación, el usuario no puede experimentar las relaciones de causa/efecto, lo que le impide establecer las normas del sistema que las rigen; y no puede, por tanto, deducir por qué no está disponible determinado componente. En casos como estos, controlar mediante un mensaje de error se convierte en un medio para explicitar el modelo mental.

B. Cuando los efectos de guiado ocultan información valiosa sobre el modelo mental del sistema.

Conclusión

El objetivo principal de este artículo es ayudar a tomar conciencia de que decidirse por un estilo orientado a controlar o bien a un estilo orientado a guiar en el diseño de una interfaz tiene consecuencias sobre la calidad del modelo mental del sistema que se va a formar el usuario. Como en tantos otros aspectos de la usabilidad, la decisión final que se aplique tiene que regirse por el sentido común. Eso sí, para que un diseño de estilo â??Controlarâ? tenga éxito en la formación de un modelo mental correcto, es imprescindible un buen diseño de los mensajes de error. Pero este es un tema con suficiente entidad como para abordarlo en otro artículo.