Proximidad: Las funciones básicas deben aparecer de inmediato, mientras que las funciones avanzadas deben estar en un lugar menos para los usuarios nuevos. Los usuarios deben beneficiarse de tener más próximas las funcionalidades más utilizadas, al igual que un carpintero siempre quiere tener a mano las herramientas que más utiliza.

Familiaridad: Una de las características de una buena interfaz es que en su mayor parte no requiere un aprendizaje específico, sino que es utilizable inmediatamente porque se basa en conocimientos previos de la vida real de los usuarios. Utilizar conceptos, mecanismos e imaginería del mundo real como metáforas permite a los nuevos usuarios empezar a utilizar la aplicación casi de inmediato, porque intuyen su funcionamiento al encontrarse con conceptos conocidos. Además, emplear las convenciones típicas de las aplicaciones facilita también el aprendizaje, puesto que se aprovecha una parte del conocimiento previo en la utilización de otras aplicaciones.

Simplicidad: Una interfaz repleta de funciones avanzadas sólo distrae a los usuarios y les impide realizar las tareas comunes del día a día. Por el contrario, una interfaz que sustenta las acciones del usuario acaba desapareciendo como interfaz y se convierte en tapiz. Además, los objetos de la interfaz tienen que parecer lo que son. Los controles, los elementos y sus relaciones tienen que tener un significado obvio, claro y comprensible, de modo que de un vistazo el usuario pueda entender, sin llegar a tocar el ratón, cómo funciona la aplicación.

Transparencia: A diferencia de muchos otros sistemas como motores o máquinas de tabaco, las aplicaciones son sistemas interactivos que no hacen ruido mecánico por sí mismos. Por tanto, toda la comunicación debe vehicularse a través de la vista (ignoramos aquí aquellas que generan efectos sonoros, como aplicaciones de escritorio). Las mejores interfaces dialogan con el usuario de modo visual (y más que textual): estas pistas visuales evidencian qué está haciendo la aplicación, cuánto queda, y qué se espera del usuario. Con barras de estado, barras de progreso y técnicas como el empleo de focus y highlights, la interfaz comunica visualmente al usuario la actividad de la aplicación, que si no sería completamente silenciosa. La interfaz debe ser transparente y mostrar visualmente la acción que el usuario realiza, de modo que trabajar con la aplicación sea obvio, y que los efectos de utilizarla sean inmediatos.

Diálogo: Aparte de ser transparente en su funcionamiento, la aplicación debe comunicarse con mensajes de texto con el usuario. Mediante estos mensajes, que pueden ser de error, de alerta o de confirmación, la interfaz debe expresar lo que está ocurriendo “under the hood”, detrás de la pantalla. Estos mensajes deben estar bien redactados y ser precisos sobre el tipo de error que ha habido, sobre la acción que se ha completado o sobre el aviso que quiere darse al usuario. No deben ser genéricos sino específicos. Deben dar siempre la oportunidad de cancelar la acción, si no está hecha, o deshacerla, si ya está hecha.

Seguridad: El usuario debe tener la seguridad de que usar la aplicación no es ni peligroso ni arriesgado. Es decir, que no es posible equivocarse sin haber sido advertido previamente, ni que no es posible cometer un error sin poder restaurar el estado de las cosas antes de cometerlo, es decir, deshacerlo. Eso pasa por no situar ningún botón fatal en un sitio de paso cualquiera sino en un sitio protegido, dar el aspecto pertinente a los botones de acción fatal, pedir confirmación antes de realizar la acción, etc. El usuario debe tener la seguridad de que si va a realizar alguna acción crítica, la aplicación estará a la altura y sabrá advertirle de modo oportuno (en el momento adecuado) y pertinente (avisando con claridad las consecuencias de esa acción crítica).

Consistencia: Una interfaz consistente logra una de las mayores virtudes de las interfaces: la predictividad. La aplicación debe comportarse de una manera predecible. El usuario debe poder predecir y acertar sobre lo que pasará cuando haga click aquí o allí, porque antes ha visto a la aplicación responder de ese modo en una situación parecida. Eso se logra cuando elementos de la interfaz parecidos se comportan de manera parecida, y cuando ese comportamiento se mantiene de modo consistente a través de toda la aplicación. Los mismos objetos de la interfaz deben comportarse de la misma manera en cualquier lugar. Si van a comportarse diferente, su aspecto también debe ser diferente.

1. Las tipografías con serif deben medir siempre algo más que las sin serif; por ejemplo si una sans serif tiene entre 9 y 11 puntos; si la cambiáramos por una serif ésta debería tener entre 11 y 12 puntos.
2. Es bueno evitar columnas de texto con más de 80 carácteres por línea. Las líneas más largas de 80 cpl pueden llevar a que los usuarios lectores lean la misma línea dos veces; sin embargo, las más cortas de 80 cpl rompen tan a menudo que es difícil seguirlas.
3. No abusar de letras todas mayúsculas, especialmente cuando se trata de composiciones con un uso intensivo de textos. Las mayúsculas reducen la velocidad de lectura un 30% y en cambio requieren un 30% más de espacio que las minúsculas.
4. En diseño de revistas y periódicos, pero también en la web, el ancho de la columna debería ser tan largo como lo que ocupara una vez y media el alfabeto entero en la tipografía que quieres usar y en minúscula.
5. En diseño de vallas exteriores, un buen anuncio no tendrá más de 7 palabras y no más de 2 cosas a las que mirar.
6. En las tipografías en cursiva, el cuerpo de letra perfecto es aquel que su altura es 5 veces el ancho.
7. Para saber la legibilidad de un texto a distancia, hay que que coger la mitad de la altura de la letra en pulgadas y multiplicarla por 100, para tener la distancia de la que es legible en pies

Bueno, pues eso eran 7 principios básicos en el uso de tipografías que siempre va bien tener a mano.

• Arquitectura de Información – Empieza decidiendo o planificando qué información está disponible, y dónde, cuando y bajo qué condiciones.
• Comportamientos de interfaz – A veces se requieren o son aconsejables comportamientos de interfaz específicos. Estos comportamientos suelen afectar el diseño tanto desde el punto de vista funcional como desde el visual.
• Jerarquía visual del contenido – Suele ser beneficioso para aportar pistas sobre lo que es más importante del sitio web, qué es lo siguiente en importancia, y así con el resto de elementos.
• Layout – La parrilla visual fundamental en la que se alojan los elementos mencionados anteriormente.
• Estilo – El look&feel del sitio web debe soportar y dar un aspecto a todo lo anterior y relacionar todos los elementos anteriores de una manera limpia y armónica

Cada capa es importante y, cuando se trabaja bien, contribuye a la totalidad del diseño. Olvida una de las capas y el diseño se resentirá y no alcanzará su potencial. En general, los diseños que ignoran alguna de estas capas son, simplemente, diseños pobres.

Como la usabilidad es por naturaleza algo subjetivo y dificilmente medible, hay que recurrir a técnicas que, aunque aproximadas, son al menos más objetivas, para poder evaluar la usabilidad de un sitio o sistema web.

Una de estas técnicas es la medición de varias propiedades relacionadas con la facilidad de uso. Estas propiedades que hay que medir son las siguientes:

• Satisfacción – Mediante un cuestionario anónimo
• Eficiencia – Midiendo el tiempo que se tarda para realizar una(s) tarea(s) determinada(s)
• Aprendabilidad – Midiendo el tiempo que se tarda en alcanzar un cierto nivel de conocimiento
• Errores – Contando el número de errores que ocurren mientras se usa la web para completar una tarea determinada
• Memorabilidad – Contando el número de respuestas correctas en un test de memoria del funcionamiento de la web

Algunas de estas propiedades son un poco subjetivas, como por ejemplo la satisfacción, pero aún así se puede evaluar especificando unos niveles-objetivo. Por otro lado, la eficiencia, la aprendabilidad, el cómputo de errores y la memorabilidad son propiedades más fáciles de medir matemáticamente.

Con esta técnica planteada, podemos estar seguros de que mediremos la usabilidad de un website de un modo bastante certero. De todos modos, hay otras variantes en este tipo de mediciones relativas a la usabilidad, como por ejemplo aquella en la que se miden sólo 3 factores: la eficacia (el usuario logra lo que quiere), la eficiencia (lo logra rápidamente y sin obstáculos) y la satisfacción (después de completar la tarea).

Con la técnica de las 5 propiedades, debemos asignar diferentes niveles -objetivo requeridos de usabilidad para cada propiedad que evaluamos. Por ejemplo, si la satisfacción la medimos en una escala de 1 a 5, en la que una satisfacción óptima es 5, podemos fijarnos como meta llegar al nivel 4, que ya es suficientemente difícil de conseguir, y podemos establecer que no daremos por buena una web cuya satisfacción en el uso esté por debajo de 3. Lo mismo con las otras propiedades.

A priori, otros atributos, como el número de errores, son más fáciles de evaluar, porque consiste en contar las veces que un usuario se equivoca al querer realizar una tarea. Pero ojo, no nos llevemos a engaño: identificar y comprender por qué suceden los errores requiere tanto experticia como experiencia.

Habitualmente, los requisitos de usabilidad que se quieren para un website se definen después de que se han establecido los requisitos técnicos, sin que ello suponga ningún problema. Pero si los requisitos de usabilidad se definen demasiado tarde en un proyecto web, entonces implementarlos puede ser terriblemente caro. Por tanto, idealmente los requisitos deben establecerse después del diseño y antes de la programación.

De todos modos, no está de más tampoco ir comprobando que la web cumple con los requisitos de usabilidad establecidos a medida que la vamos construyendo, es decir, en diferentes estadios del ciclo de desarrollo del proyecto. Ello nos ayudará a ir evaluando la usabilidad del sitio para que, cuando tengamos que realizar una medición de usuabilidad, logremos una buena calificación.

After reading this post I wanted to post a comment, but as I began writing it sort of grew into a post by itself, so here is my response:

I think web designers should know how to build with (X)HTML/CSS but no more than an architect knows how to build with formworks and concrete. Designers think websites while coders build those websites just like architects think buildings while masons construct those buildings.

In circumstances, it is an advantage to know little of the tech details because that innocence allows for greater revolutionary thinking. Many designers who also code themselves restrict unconsciously their designs to what they can code – or to that which won’t mean a hard work to get it coded. I speak for my own experience.

At the same time, I think that knowing to code does not make a designer, just like knowing how to use concrete or formworks does not make you an architect. There are coders out there who call themselves “web designers”, but have no clue about design, about web principles, about proportion, space, hierarchy, order, balance, contrast, usability, consistency and all which makes great design great.

So while it is true that a designer who does not know HTML/CSS cannot call himself a web designer, the contrary is also true: a person who knows HTML/CSS cannot call himself a web designer if he has no formation whatsoever in design. And, by the way, print design formation helps much because much of the best principles and practices in design are universal and apply to both the offline and online spheres.

By the way, where is Flash in this debate? Or a Flash web designer is not a web designer?

“Las migas de pan no son exactamente las migas de pan sobre las que Pulgarcito podía desandar el camino recorrido, para ello están ya el botón de atrás o adelante del navegador, son más bien el “Usted está aquí” de un mapa, donde se muestra la situación exacta dentro de la estructura del sitio.”

Bueno, yo no estoy de acuerdo. Para mi las migas de pan sí deben ser migas de pan, es decir el rastro de páginas por las que has pasado. Lo otro, que es ubicarte dentro de la estructura del site, no son auténticas migas de pan sino un recurso de señalética.

No es la primera vez que oigo que los menús del tipo “Estás aquí: Inicio > Productos > Relojes para regalar > Rolex Quasar 2″ son “menús de migas de pan”. No, para nada; eso es señalética en diseño web o, si lo prefieres, rotulación en web. Es como el típico mapa que nos encontramos en las ciudades turísticas de “Usted está aquí”.

Lo que sería un menú de migas de pan sería “Su rastro: Búsqueda en Google > Relojes para regalar > Rolex Quasar 2″. Eso sí es un menú de migas de pan, porque son las huellas que ha dejado el navegante en el sendero que ha recorrido, no el sitio donde se encuentra ahora.

Lo que más me sorprende es que incluso en el reconocido sitio especializado en usabilidad, Usalo.es, cometen el mismo error de confundir una cosa con la otra, como puede verse en esta entrada, de la que he sacado la imagen anterior.

La programación, ya sea en PHP o ASP, es diferente según sea un migas de pan o una rotulación de dónde estás. Es más, si se trata de ésto último, incluso se puede hacer directamente con marcado HTML, porque no es dinámico.

Estudio de diseño del año:
1. Preloaded
2. Fortune Cookie
3. Wefail
4. Less Rain
5. Hi-RES!

Rediseño del año:
1. Apple
2. Manchester United
3. NY Times
4. Waterstones
5. Guardian Unlimited

Campaña de marketing viral del año:
1. Will it Blend?
2. Simpsons Movie
3. Get the Glass
4. Cadbury
5. X Factor

Mención especial al peor diseño (y con razón): MySpace.com