10 errores principales en el diseño de aplicaciones

Por Jacob Nilsen.

Es difícil hacer una lista de errores tan general, ya que los peores problemas son específicos de cada ámbito; no obstante, suelen caer en alguna de estas tres categorías:

* la aplicación resuelve un problema equivocado;
* la aplicación tiene funcionalidades inadecuadas para el problema correcto;
* la aplicación tiene funcionalidades adecuadas para el problema correcto, pero son demasiado complicadas para que el usuario las entienda

El único consejo general es basar el diseño, no en las intuiciones o suposiciones del desarrollador, sino en la investigación usando estudios de comportamientos y tareas, prototipado en papel, diseño iterativo y testeo con usuarios, etc. Las especificaciones de requerimientos están siempre equivocadas o son incompletas; por eso hay que basarse en lo que los usuarios hacen, más que en lo que dicen.

Estos son (para Nielsen) 10 errores de usabilidad frecuentes y especialmente escandalosos en una amplia variedad de aplicaciones.

1. Controles GUI no estándar

Los controles GUI básicos, como enlaces, botones, casillas de verificación, barras de scroll, etc., son las unidades léxicas que forman el vocabulario para el diseño de diálogos; cambiar su apariencia o comportamiento es como introducir en una conversación palabras de un idioma extranjero desconocido.

Sin embargo, muchos diseños continúan violando ese principio, siendo las barras de scroll la víctimas más habituales. Si los mejores expertos en diseño de interacción han refinado esos controles durante casi 30 años, es poco probable que un diseñador invente un botón mejor en un fin de semana. Y aunque lo hiciera, los usuarios están mucho más habituados a los controles estándar.

Barras de scroll no estándar: una mala idea

1.a. Parecer un control GUI sin serlo

Un elemento que parezca un control pero no lo sea puede ser un problema todavía peor, ya que pueden dar la impresión de que "algo no funciona". Puede ser, por ejemplo, un texto que parezca un enlace (por su color o por estar subrayado); o un elemento que parece un botón pero no lo es, como en este caso, donde los títulos 'NEW CUSTOMER' y 'EXISTING CUSTOMER' parecen botones, pero no tienen ninguna acción asociada:

Ejemplo de elementos que parecen botones, pero no lo son

2. Inconsistencia

Una aplicación que utiliza diferentes palabras o comandos para la misma acción, o que usa la misma palabra para diferentes conceptos en diferentes momentos provoca confusión; lo mismo ocurre cuando los mismos elementos aparecen en diferentes puntos de la pantalla. Lo diferente es difícil.

Vemos en este ejemplo la selección de las fechas de ida y vuelta de un viaje, pudiendo elegir la fecha entre dos meses consecutivos. Un usuario que quisiera viajar del 10 de marzo al 15 de marzo podría, equivocadamente, hacer esta selección:

Selección de fechas de viaje, en dos meses consecutivos

El error es debido a que la selección de la fecha de vuelta no muestra el mismo funcionamiento que la de ida: el mes de marzo se ha movido a la parte izquierda del calendario. Podría parecer un comportamiento útil, ya que permite que se pueda seleccionar la fecha de regreso en marzo o en abril (en febrero ya no tiene sentido una vez seleccionada la fecha inicial en marzo); pero la diferencia entre ambos calendarios puede motivar el error del usuario que entiende que ambos calendarios tienen el mismo contenido. Es más; aunque el usuario no llegue a equivocarse, pierde más tiempo entendiendo el contenido del calendario del que se pueda ahorrar por mostrar directamente el siguiente mes.

3. No mostrar claramente su funcionamiento ("no perceived affordance")

"Affordance" significa lo que se puede hacer con un objeto: por ejemplo, una casilla de verificación se puede activar o desactivar; un "slider" puede moverse arriba o abajo; "perceived affordances" son funcionamientos que se entienden simplemente viendo el objeto, antes de utilizarlo. Es importante que los diseños posean esa característica, ya que los usuarios (con la posible excepción de los niños) normalmente no tienen tiempo ni les gusta tener que jugar una partida de buscaminas, probando diferentes acciones para ver cómo funciona cada elemento.

Los diseños arrastrar-y-soltar ("drag-and-drop") son especialmente problemáticos, ya que es difícil mostrar cuándo un elemento puede ser arrastrado, o dónde puede ser soltado, o qué pasará en tales casos. En general, los siguientes síntomas revelan un problema de falta de "perceived affordance":

* Los usuarios se preguntan "¿qué hago ahora?".
* Los usuarios no utilizan una funcionalidad que les habría ayudado.
* Hay una parrafada de texto que intenta solucionar los dos problemas anteriores.

3.a. Zonas de click diminutas

Un problema asociado al anterior es el de las zonas de click tan pequeñas que los usuarios fallan y hacen click fuera de ella. Aunque inicialmente hayan comprendido su funcionamiento, el no obtener una acción por haber fallado en su objetivo puede hacerles creer que no se trata de una zona activable. El problema es especialmente importante en los usuarios de edad avanzada y aquellos con discapacidades motoras.

4. Sin retroalimentación ("feedback")

Uno de los principios de diseño más básicos en un diálogo es proporcionar retroalimentación para evitar que el usuario tenga que adivinar (y se equivoque) en cuanto a lo que está pasando. Para ello el sistema debe:

* Mostrar al usuario el estado actual del sistema.
* Informar sobre qué comandos han sido interpretados.
* Decirle al usuario qué está pasando.

En la siguiente captura de pantalla de ejemplo, el usuario puede elegir entre dos modelos de rueda; pero la rueda seleccionada se muestra con un tono gris, lo que confunde al usuario ya que es un color que se utiliza por convención para opciones que no están disponibles. El usuario no está correctamente informado de cuál es el estado del sistema ni qué opciones tiene disponibles.

Captura de pantalla del área 'build-your-own-car' en el sitio web de VolksWagen, mostrando el paso de selección de ruedas.

4.a. "He salido a comer" sin un indicador de progreso

Una variante de la falta de retroalimentación es no avisar al usuario cuando una determinada acción va a llevar un tiempo especialmente largo. Los usuarios pueden pensar que la aplicación se ha "colgado", o empezar a hacer clicks y lanzar nuevas acciones. Si no se pueden respetar los tiempos de respuesta límites , es necesario mantener informado al usuario:

* Si la acción dura más de 1 segundo, mostrar el cursor "ocupado" (reloj de arena).
* Si la acción dura más de 10 segundos, mostrar una barra de progreso indicando, si es posible calcularlo, el porcentaje realizado.

5. Malos mensajes de error

Los mensajes de error son un tipo especial de retroalimentación que indican al usuario que algo ha ido mal. A pesar de tener directrices sobre mensajes de error desde hace casi 30 años, todavía muchas aplicaciones las violan.

La violación más habitual es cuando el mensaje de error simplemente indica que algo ha ido mal, sin explicar por qué y cómo el usuario puede solucionarlo. Esos momentos pueden aprovecharse para enseñar al usuario el funcionamiento del sistema, ya que estará más dispuesto de lo habitual para solucionar el problema.

En la web, existe un segundo problema con los mensajes de error: en muchas ocasiones los usuarios los pasan por alto ya que están rodeados por grandes cantidades de información. Se puede aliviar haciendo páginas más simples, pero aun así los mensajes de error tienen que ser más prominentes en interfaces web.

Página 404 (not found) del sitio Dilbert.com

6. Pedir la misma información varias veces

Los usuarios no deberían verse obligados a introducir la misma información más de una vez. Después de todo, los ordenadores son especialmente buenos recordando datos. El único motivo de que los usuarios tengan que hacerlo es que los programadores no se han tomado la molestia de transferir la información de una parte de la aplicación a otra.

7. Sin valores por defecto

Los valores por defecto ayudan a los usuarios de muchos modos. Por ejemplo, pueden:

* hacer más rápida la interacción, ya que los usuarios no tienen que introducir un valor si el que está por defecto es aceptable;
* enseñando, mediante un ejemplo, el tipo de respuesta que es apropiada para la pregunta; y
* dirigiendo a los usuarios novatos hacia un resultado común o seguro, dejándoles aceptar el valor por defecto si no saben qué otro elegir.

En este ejemplo, la aplicación permite configurar una camisa al gusto del usuario, con multitud de opciones pero dejando seleccionada por defecto la más común en cada caso (en concreto, la selección del cuello tiene 15 posibilidades diferentes).

Caputra de pantalla parcial la aplicación de configuración de camisa en www.listerouge-paris.com

8. Usuarios "lanzados" contra la aplicación

Muchas aplicaciones web son aplicaciones efímeras con las que los usuarios se encuentran como resultado secundario de su navegación, de cuyo funcionamiento no tienen un modelo conceptual. En otro tipo de aplicaciones esto menos problemático: las aplicaciones tradicionales son más o menos conocidas (muchos usuarios saben cómo funciona un editor de textos o una presentación), y para las aplicaciones críticas para su trabajo se supone que el usuario tendrá el tiempo, la motivación o la formación necesarias para aprender a manejarlas.

Pero en las aplicaciones basadas en web (incluso las que pertenecen a una intranet), muchas veces los usuarios se ven "lanzados" contra la aplicación sin tener idea de qué va a ocurrir. Desgraciadamente, la mayoría de usuarios no leerán un largo texto con instrucciones, por lo que necesitarán una lista corta o una imagen que les permita tener, en un vistazo, una idea general del funcionamiento de la aplicación.

En el siguiente ejemplo, la aplicación no consigue ese objetivo ya que mezcla dos metáforas: el configurador de producto y el detalle de un producto prediseñado en un sitio de comercio electrónico. El usuario no consigue tener por tanto una idea clara del objetivo de la aplicación.

Captura de pantalla de la aplicación de configuración de camisas en Hamilton

9. No indicar cómo se usará la información

En general, obligar a los usuarios a seguir un proceso sin mostrar claramente el resultado es un problema importante; pero el peor caso es cuando se pide a los usuarios que introduzcan información sin indicarles para qué se va a utilizar.

Un ejemplo clásico es el campo "alias" en un proceso de registro de un foro; muchos usuarios no se dan cuenta de que ese alias será utilizado para identificarlos en el foro para siempre, así que a menudo introducen algo inapropiado.

Otro ejemplo es el de sitios de comercio electrónico que piden el código postal del usuario antes de poder ver páginas de productos; muchos usuarios abandonan el sitio preocupados por su privacidad. Esto se evita con un diseño en el que se explica a los usuarios que el código postal es necesario para calcular los gastos de envío en caso de productos pesados.

10. Funcionalidades centradas en el sistema

Demasiadas aplicaciones muestran su "ropa sucia", ofreciendo funcionalidades que reflejan su punto de vista interno de los datos, en vez de la visión que tienen los usuarios del problema.

Por ejemplo, un usuario puede querer recolocar los fondos de su plan de pensiones (actuales y futuros), moviéndolos de un tipo de inversión a otro (bonos a acciones, por ejemplo). Pero en la práctica, puede ocurrir que la aplicación únicamente cambie el destino de sus aportaciones futuras, mientras que las anteriores quedarán donde estaban.

¿Por qué este funcionamiento incorrecto? Porque desde el punto de vista del gestor del plan, las aportaciones anteriores y las futuras se tratan de modo diferente: recolocar nuevas aportaciones implica invertirlas en un mercado u otro, mientras que recolocar los fondos anteriores puede que implique vender las inversiones anteriores para adquirir otras diferentes.

Pero los usuarios probablemente no hacen esa distinción entre aportaciones nuevas y viejas; para ellos sus ahorros forman una misma unidad, y como tal quieren operar con ellos. Probablemente sería más adecuado ofrecer una funcionalidad destacada para recolocar la totalidad de los fondos, y ofrecer una funcionalidad más avanzada (mediante revelación progresiva ) para los usuarios expertos que quieran hacer una distinción más detallada entre ambos tipos de aportaciones.

Error extra: botones de reset en formularios web

Este error se refiere a formularios web: es casi siempre una equivocación tener un botón de Reset en un formulario web.

El botón Reset borra toda la información insertada por el usuario y deja el formulario en su estado inicial. Sólo sería útil para usuarios que introducen datos de modo repetido con el mismo formulario pero con datos totalmente diferentes cada vez, que es una situación que no se da prácticamente nunca.

Poner tan fácil que los usuarios puedan perder su trabajo con un simple click viola uno de los principios de usabilidad más básicos, que es respetar y proteger el trabajo del usuario casi a cualquier coste; por eso se utilizan diálogos de confirmación para las acciones más destructivas.