Diseño de Interfaces de Usuario Usables: Una Guía Rápida para Desarrolladores de Software Libre y de Código Abierto

Por Benjamin Roe.

Traducido al castellano por Raúl González Duque
el día 8 de Diciembre de 2004

Introducción

El mundo del software de código abierto está lleno de software muy bueno. Existe software libre y de código abierto disponible para virtualmente cualquier tarea que un usuario pueda querer realizar, desde usar un procesador de textos a montar un servidor web. Pero hay un pequeño problema con la mayor parte de este software: a menudo es mucho más difícil de utilizar de lo que podría serlo. Los diseñadores de interfaces de usuario profesionales siempre dicen que la interfaz de usuario debería ser la primera cosa a diseñar a la hora de desarrollar una aplicación, y que los programadores son incapaces de llevar a cabo este tipo de diseño. Dicen que sólo puede hacerse por profesionales expertos en interfaces de usuario; los proyectos de software de código abierto no tienen acceso a este tipo de gente, y por lo tanto no pueden ser verdaderamente usables.

Esto no significa que simplemente deberíamos darlo todo por perdido en el terreno de las interfaces de usuario. Viendo la calidad de las interfaces de muchas aplicaciones comerciales, el tener expertos en usabilidad en la nómina tampoco garantiza una buena interfaz. El esfuerzo, el conocimiento y pensar en la interfaz puede mejorar la usabilidad de una aplicación de manera radical. Puede que solo encontremos un máximo local en lugar del global, pero incluso si solo conseguimos eso ya es un paso en la dirección correcta.

Después de pasar años luchando con estos problemas, pensé que debía escribir una pequeña lista de las cinco cosas que los desarrolladores de software de código abierto deberíamos considerar a la hora de diseñar la interfaz de nuestra aplicación. Esta lista deriva de mi experiencia en el uso y desarrollo de software de código abierto y de la lectura de unos cuantos libros y sitios webs sobre el tema muy interesantes. Podéis encontrar una lista de estos libros y webs en las referencias — son una lectura excelente para cualquier desarrollador interesado en temas de usabilidad.

De forma intencionada solo he mencionado puntos que no requieren una gran cantidad de trabajo para ser implementados, y sobre los que hay poca controversia. Otros temas relativos a la “aplicación en su conjunto” se salen del ámbito de este artículo. Ninguna de estas ideas es nueva o particularmente compleja, pero su efecto puede ser impresionante. Debería mencionar también que en algunos de los ejemplos que utilizo, es posible arreglar el problema cambiando las opciones de la aplicación. He decidido considerar solo las opciones por defecto ya que podemos suponer que las opciones por defecto representan la idea que tiene el desarrollador del diseño más usable para su aplicación.

Antes de empezar, probablemente debería comentar una última cosa para al menos poder mitigar las críticas que voy a recibir: aunque pueda sonar bastante áspero algunas veces, todo esto no es más que crítica constructiva. Utilizo la mayoría de estas aplicaciones cada día y han hecho un trabajo fantástico con ellas, son el producto de años de duro trabajo por parte de desarrolladores muy dedicados. Simplemente estoy haciendo sugerencias sobre mejoras potenciales; no pretendo ofender a nadie.

Los Puntos

0) El usuario no está utilizando tu aplicación

La cuestión más básica a considerar en el diseño de interfaces de usuario es que el usuario no quiere utilizar tu aplicación. Quieren hacer su trabajo de la forma más sencilla y rápida posible, y la aplicación no es más que otra herramienta para ayudarles a lograrlo. Cuanto menos estorbe tu aplicación al usuario, mejor. El esfuerzo utilizado en usar tu aplicación es esfuerzo que no pueden utilizar en la tarea que están intentando realizar. Hay un par de citas del segundo libro de Alan Cooper, About Face 2.0 (Acerca de Face 2.0), que lo resumen bastante bien:

1. “Imagina usuarios muy inteligentes pero muy ocupados”
2. “No importa lo genial que sea tu interfaz, menos es más siempre”

Los puntos 1 a 4 en este artículo son sólo casos especiales de esta regla.

1) La Ley de Fitt

Esta es la ley más básica y más conocida de entre las leyes del diseño de interfaces de usuario. Esta ley dice que cuanto más grande y más cercano al puntero del ratón es un objeto, más sencillo es el hacer click sobre él. Esto es de sentido común, pero muchas veces es ignorado completamente en el diseño de interfaces.

Consideremos, por ejemplo, la barra de botones por defecto de Firefox (Figura 1). Cuando navegamos por la web, el botón que más utiliza la gente es el botón Anterior. El botón Anterior debería entonces ser el más sencillo de pulsar: de esa forma, minimizas el esfuerzo requerido por parte del usuario para utilizar tu aplicación, y les permites concentrarse en la navegación web. Pero en la barra de botones, los cinco botones tienen el mismo tamaño. ¿De verdad es el botón Parar tan importante como el botón Anterior? No, por supuesto que no. Un diseño mejor habría tenido un aspecto similar al de la Figura 2. Esto hace que el botón Anterior sea más sencillo de pulsar según la ley de Fitt, y también más sencillo de distinguir de los otros botones.

El tamaño de un elemento de la interfaz puede parecer mayor si lo colocamos en el borde de la pantalla. Cuando el cursor del ratón llega al borde de la pantalla, va a pararse exactamente en el borde, independientemente de lo rápido que se estuviera moviendo el ratón. Esto significa que para el usuario del ratón los objetos que están en el borde de la pantalla a todos los efectos tienen tamaño infinito. Sería muy sencillo el hacer click sobre un control de un pixel que se encuentre en la esquina superior derecha de la pantalla; simplemente tienes que ‘lanzar’ el ratón hacia la derecha y arriba tanto como quieras. Si movemos ese pixel al centro de la pantalla, necesitaríamos mucho más tiempo para hacer click sobre él. Partiendo de esto podemos concluir que los controles sobre los que queremos que sea más sencillo el hacer click deberían colocarse en los bordes o esquinas de la pantalla.

El ejemplo más simple es el de los botones de cerrar, maximizar etc. en una ventana. Debería ser sencillo el hacer click sobre ellos, para que sea fácil manejar las ventanas. Estos son los candidatos ideales para ser colocados en las esquinas. Pero hay muy pocos gestores de ventanas que hagan esto: la mayor parte de los temas para Metacity no lo hacen, XFCE4 tampoco. Solo es necesario mover los botones un pixel hacia arriba y a la derecha y el usuario podría cerrar la ventana sin siquiera tener que mirar.

Otro ejemplo son las barras de desplazamiento. En la mayor parte de las aplicaciones de mi escritorio el borde derecho de la barra de desplazamiento se encuentra a un pixel del borde de la pantalla cuando la ventana está maximizada, haciendo que el tamaño del control decrezca de una zona sencilla de pulsar de tamaño virtualmente infinito a una pequeña zona de 10 pixels de ancho con la que se necesitan unos pocos segundos extras para hacer click cada vez que quiero desplazar el contenido de la ventana.

Para resumir este punto:

1. Los controles más utilizados deben ser más grandes y ser distinguibles fácilmente
2. Utiliza los bordes y esquinas de la pantalla para hacer que tus controles sean virtualmente infinitos
3. Nunca, nunca coloques los controles a un pixel de distancia del borde de la pantalla o de una esquina

2) Interferencias Innecesarias

Cuando un usuario está trabajando, su atención está centrada en el trabajo que está realizando. Cada vez que tienen que concentrarse en la aplicación, les lleva tiempo el volver a centrarse en el trabajo. Por lo tanto, deberías minimizar la cantidad de distracción y de interferencias por parte de tu aplicación. Cada aplicación tiene un elemento clave en la que centrarse — en un editor de texto, es el texto; en un navegador web, es la página web — así que deberías hacer de este elemento clave el centro de la interfaz.

Un ejemplo son los diálogos de confirmación y de progreso. Evolution, por ejemplo, lanza una ventana de diálogo cada vez que se pulsa sobre “Enviar/Recibir” para informarme del progreso en el proceso de comprobación del correo. Este diálogo se encuentra justo encima del área de la pantalla donde se muestra el correo que se está recibiendo y bloquea el acceso al resto de la aplicación. ¿Cuál es el propósito de este diálogo? Todo lo que hace es molestar al usuario. Sería mucho mejor eliminarlo y reemplazarlo con una barra de progreso.

Un ejemplo mucho peor es el comportamiento por defecto de la papelera de KDE. El enviar un archivo a la Papelera es una acción que se puede deshacer de manera sencilla y que el usuario puede querer hacer varias veces en poco tiempo: ¿por qué obligar al usuario a hacer click sobre “Aceptar” cada vez, cuando la acción se puede deshacer de manera sencilla?. Si quieres alertar al usuario del hecho de que el archivo se ha enviado a la papelera, puedes reproducir algún tipo de animación. No coloques una barrera cada vez que quieran llevar a cabo una acción tan sencilla. Todo lo que consigues es molestar a los usuarios, ralentizarlos y condicionarlos para que hagan click sobre Aceptar sin molestarse en leer los diálogos.

Otro ejemplo es el siempre presente diálogo de “Texto no encontrado” en la característica de búsqueda de todos los editores de texto. Si no se ha encontrado el texto que he introducido en el diálogo de búsqueda, es más que probable que me confundiera al escribir la cadena con lo que solo quiero editarla y volver a repetir la búsqueda. Pero ahora tengo una ventana de diálogo con un botón “OK” por encima, así que tengo que pulsar sobre el OK para hacer que se vaya antes de poder hacer cualquier otra cosa. Más molestias y más trabajo por parte del usuario. Una forma mejor de hacerlo sería el diálogo de búsqueda de Firefox, que cambia el color de la caja de texto a rojo cuando el término de búsqueda no se ha encontrado.

3) Utiliza la potencia de la computadora

Los computadores actuales son bastante potentes, con billones de ciclos de procesador por segundo y cientos de gigabytes de espacio de almacenamiento disponible. Los humanos, por otra parte, no hemos cambiado tanto en cientos de años. Aún nos cansamos, nos aburrimos o nos distraemos y tenemos una cantidad limitada de energía mental disponible. Parece una buena idea, por lo tanto, liberar de cuanto trabajo podamos al pobre humano y encargárselo a la computadora que es super rápida y no se cansa.

En el diseño de interfaces para el usuario, las implicaciones que tiene esta idea son claras: cada vez que halla una decisión que tomar o trabajo que hacer, intentaremos que la interfaz lo haga por el usuario. Por ejemplo, en mi barra de herramientas en este momento tengo abiertas dos ventanas de xterm (Figura 7). Una está abierta en el directorio en el que tengo el código fuente de SiEd, y la otra en un directorio con código LaTeX para un artículo. ¿Puedes decirme cual es cual? Yo no puedo, asi que para seleccionar la correcta tengo que realizar un trabajo, bien pulsar sobre la barra de tareas o bien mover el cursor sobre una tarea y leyendo los tooltips. Pero la computadora si sabe cual es cual: ¿por qué no puede hacer el trabajo por mi?

La solución es simple: para las entradas de la misma aplicación en la barra de tareas, debería comprobar el nombre de la tarea y mostrar suficiente información para poder distinguirlas. De esa forma, puedo seleccionar entre multitud de aplicaciones diferentes sin tener que pensar demasiado. La computadora hace el trabajo para que no lo tenga que hacer yo.

Si las computadoras tienen tanto espacio de almacenamiento disponible, ¿por qué hay tantas aplicaciones que olvidan mis preferencias cuando las cierro? Por ejemplo, nunca utilizo el IDE Anjuta mas que en ventanas maximizadas. Por defecto Anjuta se abre una ventana de un tamaño casi igual al de mi pantalla, con la esquina superior izquierda a unos tres pixels de la esquina de la pantalla. Asi que hago click sobre maximizar, escribo alguna línea de código y cierro la aplicación. La siguiente vez que abro Anjuta, vuelve a estar sin maximizar. Asi que tengo que dejar lo que esté haciendo y pulsar sobre maximizar cada vez que abro el programa. Almacenar el tamaño previo de la ventana, la posición y el estado no llevaría mas de unos 20 bytes, un pequeño precio a pagar por salvar al usuario de miles de pulsaciones.

El administrador de archivos Nautilus de GNOME lo hace de forma correcta: cualquier cosa desde el tamaño de la ventana a la posición de la barra de desplazamiento se recuerda para cada ventana, de forma que cuando halla decidido la forma en la que quiero que se muestre una determinada ventana, no tendré que preocuparme por ella de nuevo.

Para resumir este punto:

1. Las computadoras son muy potentes: utiliza su potencia para ayudar al usuario
2. Haz que se pueda distinguir fácilmente entre elementos similares
3. Recuerda las opciones de la aplicación

4) Haz que sea fácil distinguir los elementos y buscarlos

Este punto es bastante simple: los elementos de la pantalla que hacen cosas distintas deberían ser fácilmente distinguibles unos de otros. Veamos un ejemplo extremo de como intentar hacer las cosas accesibles y fallar en el intento, echemos un vistazo a la barra de tareas de Konqueror:

El elemento que se encuentra más a la izquierda es el que posiblemente sea el comando menos utilizado en el navegador web. Este elemento es el más sencillo de encontrar y de pulsar, asi que la acción más utilizada debería ocupar esa posición. Todos los demás navegadores que conozco colocan en esta posición el botón Anterior por esta misma razón.

El botón Buscar y los dos botones de zoom son muy similares; los botones Siguiente, Anterior, Arriba, Inicio y Recargar tienen todos el mismo color, haciendo más difícil la identificación en un simple golpe de vista. Pero lo que es más importante, ¡hay quince botones! Los humanos son buenos distinguiendo entre unos cinco elementos: podemos hacerlo instantáneamente, sin pensar. Esa es la razón principal por la que las partituras de música tienen cinco líneas. Si hay más de cinco elementos tenemos que parar un momento y utilizar el cerebro para pensar qué es cada cosa. En un diseño mucho mejor sólo se habrían añadido a la barra los elementos más utilizados, minimizando el trabajo que el usuario tiene que realizar en los casos más comunes. Muchas aplicaciones tienen un número similar a este en la barra de herramientas, pero para una tarea tan simple como es la navegación web, quince elementos es una exageración. He observado a usuarios nóveles intentado utilizar Konqueror y he podido comprobar de primera mano cómo esta distribución les confunde; también me pasa a mí, un usuario de computadoras experimentado.

Otro ejemplo de elementos difíciles de distinguir entre sí lo podemos encontrar en el tema por defecto de GNOME. Fíjate en el texto seleccionado en la Figura 9.

Cuando el usuario selecciona un texto, su atención se centra en el texto seleccionado. Podemos suponer que lo ha seleccionado para poder hacer algo con él. Asi que, ¿por qué en este tema se cambia el color de fondo de la selección a un color oscuro, que hace que resulte más difícil de leer exactamente el texto en el que el usuario está interesado? ¿No sería mejor hacer que ese texto resalte del resto del texto haciéndolo sencillo de leer?

Para resumir este punto:

1. Elementos que hacen cosas distintas deben ser fácilmente distinguibles entre sí
2. No abrumes a tu usuario con demasiadas opciones
3. Haz que el elemento seleccionado sea sencillo de distinguir y leer

Conclusiones

Estos cinco puntos representan una parte pequeña pero importante del diseño de interfaces de usuario. En ningún caso son mandamientos o curas milagrosas para los problemas de las interfaces, pero en mi opinión si se siguen estos principios en el diseño, la usabilidad de la aplicación mejorará enormemente. Me encantaría recibir cualquier comentario, corrección o cualquier cosa que pensáis que debería añadir (mi dirección de correo la podéis encontrar más abajo, borrad el nospam).

Estas ideas son solo un breve resumen: para cualquiera que esté interesado en el diseño de interfaces le recomendaría echar un vistazo a las referencias que nombro más abajo. El libro de Alan Cooper es excelente; el de Jef Raskin es una referencia muy útil, con algunas ideas interesantes sobre cosas que quedan fuera del ámbito del diseño de interfaces ‘estándar’.

He leído bastantes comentarios sobre este artículo y he escrito un FAQ como respuesta para algunos de ellos

---

Referencias

1. About Face 2.0: The Essentials of Interaction Design (Sobre Face 2.0: Lo Esencial sobre el Diseño de Interacción), Alan Cooper y Robert Reimann, 2003, Wiley
2. The Humane Interface (La Interfaz Humana), Jef Raskin, 2000, Addison-Wesley Professional
3. La Sala de la Vergüenza de las Interfaces
4. Guía de Interfaz Humana de Apple
5. Guía de Interfaz Humana de KDE
6. Guía de Interfaz Humana de GNOME

Historial de cambios

• 2004-11-19 : Reemplazado el ejemplo sobre el maximizado en OpenOffice con un ejemplo sobre Anjuta después de arreglar la instalación de mi OpenOffice y darme cuenta de que OpenOffice si recuerda el estado después de todo
• 2004-11-21 : Añadidos enlaces a las guías de interfaz humana de KDE y GNOME
• 2004-11-21 : Añadido enlace al FAQ

Sobre el autor

Soy un defensor del Software Libre y el desarrollador principal de SiEd, un editor de texto bajo licencia GPL para dispositivos Palm OS. En mi vida real, estoy haciendo un doctorado en Planificación de Procesos en el Centro de Ingeniería de Sistemas de Procesos del Imperial College.

Benjamin Roe

Este trabajo está licenciado bajo una Licencia Creative Commons. Copyright Benjamin Roe 2004.