Además, la logística de la organización ha rozado la perfección: horarios, atención a los participantes y ponentes, material, etc. Ya tuve ocasión de felicitar a los organizadores por conseguir arrancar un congreso sobre un tema que, como se pudo comprobar, ni siquiera sabemos exactamente a qué se refiere.

En cuanto a las ponencias, como en cualquier congreso, ha habido de todo; pero yo diría que, dada la gran variedad tanto de los perfiles de los asistentes como de los temas tratados, el resultado ha sido más que aceptable. Por poner alguna pega, he tenido cierta sensación de que parecíamos descubrir como nuevos asuntos que ya llevan tiempo tratándose en otros países; quizá he echado en falta algo más de autocrítica; y, para próximas ediciones, sería interesante tener otras voces, ajenas a la comunidad: usuarios, clientes, etc.

En cuanto a mi charla, a pesar de que tenía algunas dudas en cuanto a cómo encajaría entre el resto, he quedado más que satisfecho por el feedback que he recibido tanto en vivo como a través de Twitter; espero no haberme encasillado como "el que no encuentra trabajo de UX"

Imagen de mi charla, cortesía de @jruizjunquera     

La polémica sobre los tests de usuario

Especialmente entretenida fue la sesión del sábado por la tarde, con la polémica sobre la mayor o menor importancia de los tests de usuarios. ¿Mi posición? Creo que es una polémica que se resuelve en un artículo de Jared Spool (ya lo comenté aquí hace un tiempo) en el que habla de 5 posibles estilos de diseño, entre ellos dos estilos que podían funcionar sin participación de usuarios:

• El "diseño para uno mismo", en el que diseñador es usuario al mismo tiempo: crea una solución que satisface sus propias necesidades, que resultan ser también las necesidades de otros usuarios. Muchas de las empresas que han triunfado en Internet empezaron así.
• El "diseño de genio", cuando los diseñadores tienen experiencia en proyectos similares y consiguen realizar un diseño que funciona. Eso sí, tienen que se basarse en mucha experiencia y mucha investigación previa.

En el resto de casos, y que para mí son la inmensa mayoría, tenemos que estar de acuerdo con Nassim Taleb y decir que los humanos somos buenos probando, pero no diseñando; así que los tests con usuarios (de laboratorio, de guerrilla, informales o medio-pensionistas) siguen siendo imprescindibles.

Por cierto, es obvio que nadie defiende que los tests de usuario sirven para diseñar, sino para evaluar. Que se hagan tests con usuarios no significa que no se necesiten buenos diseños.

Confirmado: no sabemos qué es UX

Y llego a la que yo creo que es la principal conclusión que saco del congreso y que confirma la sensación previa que tenía: la disciplina de UX sufre de un grave caso de indefinición. Hemos estado varios días hablando de User eXperience sin que, en el fondo, nadie tenga demasiado claro a qué nos estamos refiriendo.

Puede que sea muy difícil definir algo así, pero mi impresión es que las definiciones que se dan habitualmente son cada vez más amplias; demasiado amplias. Tanto, que no creo que la UX pueda considerarse como una disciplina única; decir que te dedicas a la UX es como decir que te dedicas a la informática: dice muy poco de qué haces exactamente. Sinceramente, necesitamos una definición más precisa de qué es la UX y qué perfiles la componen; a priori, se me ocurren al menos estos:

• análisis / investigación
• diseño
• evaluación

Sobre el debate UX vs. usabilidad ya escribí hace algún tiempo: si tomamos la definición de usabilidad que incluye la satisfacción del usuario, para mí UX y usabilidad son prácticamente equivalentes. Quizás al hablar de UX se suele poner más énfasis en el proceso de diseño, pero no olvidemos que las técnicas de usabilidad no son sólo de evaluación.

¿De dónde viene entonces el debate? Ahí va una hipótesis: da la impresión de que la usabilidad se ocupa poco de la satisfacción de los usuarios porque es algo mucho más difícil de medir que otros aspectos como eficacia o eficiencia; sí, hay técnicas como cuestionarios y entrevistas, pero están lejos de ser totalmente fiables. De ahí que se haya hecho popular la UX como modo de recalcar la importancia de tener en cuenta la experiencia del usuario; sin embargo, no tengo la sensación de que esa popularidad haya contribuido a mejorar cómo podemos medir esa satisfacción.

En definitiva, creo que sería un gran resultado del congreso conseguir que empecemos a cerrar los debates puramente semánticos (o metafísicos) sobre qué es usabilidad o UX, y empecemos a hablar de cómo conseguir que los usuarios queden satisfechos con nuestros productos. Y para eso quizás necesitemos más voces afirmando que el emperador está desnudo.

Ojalá haya más UX Spain, o como queramos llamarlos

Sin embargo, la parte más interesante del nuevo diseño ha sido la posibilidad de utilizardos técnicas que facilitan que la página sea usable y accesible para el máximo número posible de usuarios: 'responsive design' y 'unobtrusive JavaScript'.

'Responsive design'

El concepto detrás del 'responsive design' (que podría traducirse de manera forzada por "diseño sensible" o "diseño que responde") no es nada novedoso: se trata, básicamente, de que el diseño de un sitio web no sea único y monolítico, sino que se adapte de manera adecuada a diferentes dispositivos y contexto. Ese acceso universal es algo que está en la propia esencia de la web; pero en los últimos tiempos ha adquirido especial importancia debido, básicamente, a que dispositivos "no tradicionales" de características muy diferentes al típico equipo de escritorio, como son tablets o smartphones, se han convertido en una parte muy importante (en ocasiones, la más importante) de los accesos a los sitios web.

Así que, en la actualidad, ya no basta con crear un diseño web que funcione perfectamente en los navegadores de escritorio y que "más o menos" se puede utilizar desde otros entornos, sino que se hace necesario que ese diseño se adapte y aproveche las características específicas de cada dispositivo. Todo eso ha provocado y se ha basado, de manera retroalimentada, en tecnologías como CSS media queries.

En el caso de la página inicial de este sitio web, he introducido pequeños cambios de diseño en función, básicamente, del ancho de pantalla del dispositivo con el que se accede; en los siguientes vídeos se observa cómo el diseño se adapta a diferentes situaciones.

http://www.youtube.com/watch?v=5UbiAyukeiA 

http://www.youtube.com/watch?v=c93St0dtYEw 

'Unobtrusive Javascript'

'Unobtrusive Javascript' es otra expresión de difícil traducción (podría ser "JavaScript no intrusivo" o "JavaScript discreto"), que consigue separar totalmente el contenido del comportamiento de la interfaz, evitando que el código HTML contenga no sólo el código JavaScript, sino eliminando incluso las llamadas a funciones. Como resultado, se consigue que la funcionalidad extra que aporta el JavaScript esté disponible en los navegadores que la soportan, pero que el contenido y la funcionalidad del sitio web siga estando accesible para los navegadores que no pueden implementar esa funcionalidad añadida.

De ese modo, el sitio web no requiere que el navegador sea compatible con determinada versión o característica de JavaScript; pero si lo es, tendrá acceso a una versión "más rica". En este caso, esto es posible gracias al uso de estándares y librerías de propósito general.

En el diseño de la nueva home, hay dos funcionalidades que están soportadas por JavaScript: la presentación por diapositivas del portfolio, y las pestañas de diferentes artículos del blog. Un navegador que no soporte JavaScript (o que lo tenga deshabilitado) perderá las posibilidades de navegación por diapositivas y por pestañas, pero seguirá permitiendo que toda la información esté accesible, usando las barras de scroll en el primer caso o simplemente viendo todo el contenido en pantalla en el segundo.

Conclusiones y mejoras pendientes

Por supuesto, el diseño es mejorable y podría extenderse al resto de páginas del sitio web, aunque eso requerirá un esfuerzo adicional; lo mismo sucede con la implementación de las técnicas que he descrito, pero creo que sirven como muestra de lo que se puede hacer con ellas.

En cambio, un tema que, a mi entender, no queda resuelto satisfactoriamente es el del idioma; he preferido incorporar textos en inglés, partiendo de la suposición de que la mayor parte de usuarios interesados en esos contenidos no van a tener problemas en entenderlos, y evitar así el mantenimiento de versiones de los textos en diferentes idiomas. Sin embargo, y a pesar de que los idiomas están identificados mediante los atributos HTML 'lang' correspondientes, albergo mis dudas sobre el resultado. En cualquier caso, tengo la impresión de que la navegación por páginas que incluyen contenidos en diferentes idiomas es un asunto que todavía no está satisfactoriamente resuelto.

Mientras tanto, seguiremos cambiando cosas para no aburrirnos …

Estas son las secciones de la presentación:

• Introducción
• Estructura y funcionalidades
• Interacción
• Puntos fuertes
• Puntos débiles
• Posibles mejoras
• Líneas de trabajo propuestas
• Conclusiones

Lo más interesante no es tanto la aplicación en sí, sino comprobar que una evaluación de usabilidad puede aplicarse perfectamente a cualquier interfaz, no solo a sitios web. Y que lo mismo ocurre con las técnicas de Diseño Centrado en el Usuario.

Con todo eso, ¿qué problemas puede tener el diseño de un formulario de contacto? Se incluyen los campos para la información que se desea, un botón de enviar, y ¡listos! ¿No es así? Desgraciadamente (o por fortuna), el diablo está en los detalles, algo que es muy cierto en el diseño de interfaces.

Como ejemplo, veamos el formulario de contacto ("hogar") en la web de Jazztel:

Un formulario en principio tan sencillo ya ofrece diversos problemas relativamente importantes de usabilidad:

1. La división del formulario utilizando pestañas parece indicar que se puede navegar entre ellas de manera libre; sin embargo, en realidad se trata de la secuencia de pasos a rellenar, que deben seguirse de manera secuencial. Las pestañas no deberían utilizarse para ese fin.
2. Los valores seleccionados en las casillas de verificación (checkboxes) y botones de opción (radio buttons) se distinguen únicamente mediante un color diferente. Puede considerarse un problema de usabilidad o de accesibilidad, pero en general es mala idea codificar información únicamente mediante el color, especialmente cuando solo hay uno o dos valores posibles ("¿cuál es el color del seleccionado?"). Este tipo de errores resultan un poco más graves cuando el mal diseño requiere, además, de un esfuerzo extra por ocultar la apariencia predeterminada de los controles, que es mucho más clara.
3. El texto "He leído y acepto…" debería funcionar como etiqueta de la casilla de verificación, permitiendo activar/desactivar la casilla haciendo click sobre él. Sin embargo, en este caso el texto funciona como enlace a la política de privacidad a la que hace referencia. Peor aún es que el texto no tiene el formato de enlace (subrayado y/o de un color diferente).
4. El mensaje de error aparece en un lugar poco visible de la página, con un formato que hará que posiblemente pase desapercibido. Además, no se destaca visualmente el campo que está provocando el error (el número de teléfono).
5. Los botones de acción tienen un formato que los hace parecer como deshabilitados; uno podría pensar que se habilitan cuando se rellenan correctamente los campos, pero no es así. Además, ¿por qué hay un botón "Paso Anterior" en el primer paso?

Esos serían los problemas más importantes; una inspección más detallada permite observar otros aspectos mejorables: la navegación global del sitio es innecesaria en un formulario; las etiquetas "Documento" o "Texto de la imagen" podrían ser más explicativos; etc. En cualquier caso, es un buen ejemplo de que los detalles son importantes en la interacción y que, en muchas ocasiones, resolver los problemas de usabilidad puede resultar muy sencillo; la parte difícil es detectarlos y conseguir que el responsable se decida a resolverlos.

En principio no parece de recibo que un Gobierno en funciones adopte esta decisión en su último o uno de sus últimos Consejos de Ministros. Sería doblemente grave que se confirmaran las presiones ejercidas por EEUU, a través de su embajada en Madrid, como revelaron los cables de Wikileaks.

En todo caso insistimos en estos razonamientos:

1. Los derechos de autor no pueden situarse por encima de los derechos fundamentales de los ciudadanos, como el derecho a la privacidad, a la seguridad, a la presunción de inocencia, a la tutela judicial efectiva y a la libertad de expresión.
2. La suspensión de derechos fundamentales es y debe seguir siendo competencia exclusiva del poder judicial. Ni un cierre sin sentencia. Este anteproyecto, en contra de lo establecido en el artículo 20.5 de la Constitución, pone en manos de un órgano no judicial -un organismo dependiente del ministerio de Cultura-, la potestad de impedir a los ciudadanos españoles el acceso a cualquier página web.
3. La nueva legislación creará inseguridad jurídica en todo el sector tecnológico español, perjudicando uno de los pocos campos de desarrollo y futuro de nuestra economía, entorpeciendo la creación de empresas, introduciendo trabas a la libre competencia y ralentizando su proyección internacional.
4. La nueva legislación propuesta amenaza a los nuevos creadores y entorpece la creación cultural. Con Internet y los sucesivos avances tecnológicos se ha democratizado extraordinariamente la creación y emisión de contenidos de todo tipo, que ya no provienen prevalentemente de las industrias culturales tradicionales, sino de multitud de fuentes diferentes.
5. Los autores, como todos los trabajadores, tienen derecho a vivir de su trabajo con nuevas ideas creativas, modelos de negocio y actividades asociadas a sus creaciones. Intentar sostener con cambios legislativos a una industria obsoleta que no sabe adaptarse a este nuevo entorno no es ni justo ni realista. Si su modelo de negocio se basaba en el control de las copias de las obras y en Internet no es posible sin vulnerar derechos fundamentales, deberían buscar otro modelo.
6. Consideramos que las industrias culturales necesitan para sobrevivir alternativas modernas, eficaces, creíbles y asequibles y que se adecuen a los nuevos usos sociales, en lugar de limitaciones tan desproporcionadas como ineficaces para el fin que dicen perseguir.
7. Internet debe funcionar de forma libre y sin interferencias políticas auspiciadas por sectores que pretenden perpetuar obsoletos modelos de negocio e imposibilitar que el saber humano siga siendo libre.
8. Exigimos que el Gobierno garantice por ley la neutralidad de la Red en España, ante cualquier presión que pueda producirse, como marco para el desarrollo de una economía sostenible y realista de cara al futuro.
9. Proponemos una verdadera reforma del derecho de propiedad intelectual orientada a su fin: devolver a la sociedad el conocimiento, promover el dominio público y limitar los abusos de las entidades gestoras.
10. En democracia las leyes y sus modificaciones deben aprobarse tras el oportuno debate público y habiendo consultado previamente a todas las partes implicadas. No es de recibo que se realicen cambios legislativos que afectan a derechos fundamentales en una ley no orgánica y que versa sobre otra materia.

That's why I have compiled a list of RIA-specific usability heuristics (or best practices) that may help when it comes time to develop or to evaluate a rich web application. They are not intended to fully cover all the aspects of the application, but to address issues specific of rich web interfaces; these heuristics should be a complement of more general ones.

As with the psychological usability heuristics, they are in the form of a Google Docs spreadsheet to make it easy to download or clone it for your own work.

RIA Usability Heuristics spreadsheet (Google Docs)

These are some of the sources I have used to compile the heuristics (thanks to them!):

• Usability for Rich Internet Applications (Digital Web Magazine)
• Minimizing Usability Risks in Web Applications (Blink UX)
• Staff Picks: 10 Usability Favorites for 2006 (Blink UX)
• Usability Heuristics for Rich Internet Applications (Boxes and Arrows)

What do you think of those heuristics? Do you know any other?

La charla toma el título de un artículo de Jared Spool en el que explica el caso de un pequeño rediseño en un formulario de pago (básicamente, modificando un botón) que supuso un beneficio extra de 300 millones de dólares anuales para la empresa. Tomando eso como referencia, la presentación empieza por una pequeña introducción a lo que es la usabilidad, para después mostrar algunas cifras y casos concretos que sirven de ejemplo de la rentabilidad de invertir en usabilidad, y dar un par de consejos sobre cómo conseguirla; se incluye también una pequeña referencia a la accesibilidad web y una breve reflexión final.

Esta intervención contrastó en cierta medida con las del resto de la jornada, dedicada en su mayor parte a las técnicas de pruebas de software y a la gestión de ese tipo de tareas. Es curioso que todo el mundo de la usabilidad (y sus pruebas) sea tan ajeno e independiente al resto de pruebas de software, cuando tienen mucho más en común de lo que pudiera parecer en un principio, y podrían beneficiarse mutuamente si se gestionaran de manear conjunta. Espero escribir sobre eso en algún momento…

"The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context of use."

QED

Let's take a look at two of the buttons; isn't this your first guess when you see them?

Wrong. The real functions of those buttons are:

Using fancy original self-designed icons is a common mistake made by novice interface designers; icons are hard to memorize, and users usually recognize just a few of the most common. Many times, the best way to describe a function is simply a text label.

I'm surprised Google has fallen into that error; maybe they have been paying too much attention to people complaining about their ugly interfaces. Anyway, Google, please, give me back my text labels for actions!

Sistemas de Autenticación y Autorización en Internet (PDF; 1,30MB)

Este estudio fue realizado para el Máster en Interacción Persona-Ordenador de la Universitat de Lleida.

Para empezar, se distingue entre autenticación y autorización:

Autenticación: consiste en un sistema para certificar que el usuario es quien dice ser.

Autorización: consiste en dar acceso a una serie de recursos a un usuario o sistema […] la autorización que un usuario proporciona sobre sus recursos en un determinado sistema para que un tercer sistema tenga acceso a ellos.

El trabajo incluye una tabla-resumen de los diferentes sistemas estudiados:

Y estas son las conclusiones del trabajo:

La principal motivación para el desarrollo de protocolos abiertos de autenticación y autorización en Internet es el desarrollo espectacular de redes sociales en Internet; ya no es una alternativa práctica que cada aplicación de ese tipo construya y mantenga su propia base de datos de usuarios, datos personales, relaciones, etc.

Protocolos y APIs de redes sociales como Open Graph y OpenSocial han surgido como propuestas para permitir que Internet se convierta en una verdadera red social global, donde las aplicaciones no son “jardines privados” sino que enlazan e intercambian datos y funcionalidades entre ellos. Este tipo de protocolos requieren, sin embargo, de un paso básico: el usuario debe autenticar quién es, y qué permite hacer a los demás con sus datos. Esa es la problemática en la que se ha centrado este trabajo.

En la actualidad parecen existir dos tendencias a la hora de dar soluciones a ese problema. Por un lado, los grandes servidores de redes sociales (como Facebook, Twitter o Google) pretenden convertirse en los elegidos por los usuarios como su gestor principal de identidad; eso les convierte en el repositorio donde los usuarios almacenan sus datos personales (además actualizados), lo que constituye un gran valor para las compañías. En ese sentido, es beneficioso para ellas convertirse en proveedores de autorización y autenticación, principalmente a través del protocolo OAuth 2.0, que a pesar de ser todavía un borrador, está siendo ampliamente aceptado por muchos proveedores; la lucha no es tanto por el uso de un protocolo u otro, sino por convertirse en el proveedor elegido por los usuarios. Eso significa que existe un fuerte incentivo para que los servidores se conviertan en proveedores y que terceros consuman sus datos y servicios, pero el incentivo para convertirse en consumidores de datos de terceros es menor.

Por otro lado, protocolos como OpenID y OpenID Connect representan un esfuerzo no sólo hacia la definición de protocolos abiertos, sino hacia la descentralización de la gestión de identidad y de datos personales. Si el interés de los proveedores de redes sociales es convertirse en el punto donde los usuarios tienen su identidad principal para atraer y gestionar sus datos, la propuesta de OpenID y OpenID Connect es que se pueda elegir entre diferentes servidores para ser utilizados como proveedores de identidad, y evitar esa centralización que puede provocar problemas de privacidad.

¿Hacia dónde evolucionará la situación en un futuro? Es difícil decirlo, aunque podría aventurarse que evolucionará hacia la típica situación de long tail tan habitual en Internet, en la que unos pocos sitios webs populares se conviertan en los gestores centrales de identidad de un gran número de usuarios, mientras que exista una larga cola de proveedores minoritarios pero que, en conjunto, administren la identidad de un número importante de usuarios, quizás los más preocupados por cuestiones de privacidad.

When you enter the academic world, you realize of one surprising thing: it's a rather opaque world. In fact, many of the most prestigious journals make their publications only available to subscripters, so the only part that is available on the web for free are their abstracts.

So in the era of Internet and free access to information, scientific knowledge obtained through research (which should be the paradigm of free access to knowledge) depends mostly on an previous outlay.

At least until now. The Research Without Walls movement allows the research community to pledge to assist in the peer review process only for conferences and journals that make their accepted publications available to the public for free via the web.

Right now, the number of subscribers is not very large, but the list of institutions they belong to is pretty impressive: Google, Microsoft, Berkeley University, etc. And their prestige is important, since the reputation of conferences and journals is mostly determined by the researches that assist in them. The fact that they refuse to collaborate with closed-access publications may be a great boost to the free access to academic contents on the web.

Una de las cosas que sorprende al introducirse en el mundo de la investigación académica es que se trata de un mundo bastante opaco; de hecho, la mayoría de las publicaciones más prestigiosas (journals) publican sus artículos bajo subscripción, de modo que lo único que está disponible en Internet de manera gratuita suele ser el resumen (abstract) de los artículos.

Así es; en la época de Internet y del acceso libre a la información, el conocimiento científico obtenido mediante investigación, que debería ser el paradigma del libre acceso al conocimiento, está en gran parte condicionado a un desembolso económico.

Al menos hasta ahora; una iniciativa que tiene el nombre de Research Without Walls ("investigación sin paredes") permite a los miembros de la comunidad académica comprometerse a participar en el proceso de revisión única y exclusivamente en los congresos, journals y otras publicaciones académicas que ofrezcan sus artículos de modo gratuito en la red.

El compromiso dice algo así:

A fecha 1/20/2012, participaré en el proceso de revisión (como revisor, miembro del comité, responsable, editor, etc.) únicamente en las conferencias, journals y otras publicaciones que publiquen gratuitamente en la web todos los artículos aceptados.

De momento el número de afiliados no es muy grande, pero la lista de instituciones a la que pertenecen es para tener en cuenta: Google, Microsoft, la Universidad de Berkeley, etc. Y su prestigio es importante, ya que la reputación de las conferencias y los journals viene, en gran medida, de los investigadores que colaboran con ellas. El hecho de que estos se nieguen a colaborar en publicaciones de acceso restringido puede suponer un impulso muy importante para la publicación libre de contenidos académicos en la red.

Seguir leyendo en METAeuFORiAS…

• Requirements are defined by another team (business analysts) and the UX team is not involved in this phase; they usually don't take part until the design phase.
• The UX team is involved when the project is almost finished (and the interface problems are already pretty severe).

Yes, we know that the UX team should participate since the early stages of the development, but… what can we do when we are faced to given requirements, which are usually incomplete, long lists of technical features, and which have nothing to do with UCD techniques like use cases or user stories?

UX Interpretations

Last June, Greg Lauger explained in his article 'Matching Requirements with User Experience' on Johnny Holland Magazine some techniques used in that kind of situations, and I think that the 'UX Interpretation' approach (he calls it a "collaborative clarification") is a great idea and could be used as a UCD technique on its own.

For every single requirement (or every important requirement, or every unclear requirement), the UX team would develop the corresponding 'UX Interpretation', following this simple structure:

1. Reference to the original requirement.
2. UX interpretation of the requirement.

The UX interpretation could be a use case, a storyboard, a prototype… any technique which described the implications on the interaction of that requirement. After that, the interpretation would be reviewed by other members of the development team.

What would be the purpose and benefits of these interpretations?

• The UX team would work with a more familiar way of describing requirements.
• The interpretations would be the equivalent of "this is what we have understood from the UX point of view". Consequently, they would be a better reference for discussions with the analysts team than the original requirement. The analysts could then give feedback about the correctness of the interpretation.
• The UX team would show that the requirements are a fundamental aspect of the development, and that the team uses them and cares about them.
• The analysts would have contact with the "UX way" of describing requirements, and they could use that knowledge for following projects.

So… do you think you could have used this technique in some past situation? Or better… Do you think this could be useful in future projects?

Psychological Usability Heuristics (UX Magazine)

Sobre el artículo

Para los que no hayan leído el artículo (o tengan alguna dificultad con el inglés), en él se propone tomar como referencia una lista de hallazgos psicológicos relacionados con el diseño de interfaces recopilados por Susan Weinschenk, y convertirlos en principios que pueden ser utilizados a la hora de realizar evaluaciones heurísticas de usabilidad. Se incluye también una hoja de cálculo que facilitaría su uso en evaluaciones reales.

So… why don't we use those psychological facts as heuristic principles when evaluating interfaces, instead of the typical technical ones? To that end, I have translated Susan's points into heuristic principles and checkpoints that may be used to evaluate interfaces, creating a spreadsheet to make evaluations easier. Here you have it:

Psychological Usability Heuristics spreadsheet (Google Docs)

Of course, the translation of facts into heuristics is subjective, and this work may be updated and/or expanded at any time; anyway, I think this may be a good approach to usability from a more human perspective.

Feel free to use this spreadsheet for your own work (you may have to download or make a copy before). Any feedback about this work will be welcome!

Update 19-sep-2011

I have contacted Susan Weinschenk explaining her this idea, and this is her kind reply:

Hi Jordi,
Thanks for writing.
It's a very interesting idea. I'm surprised I didn't think of it myself!
Have you read my book: 100 Things Every Designer Needs To Know About People? Probably more ideas in there too.
Susan

I haven't read '100 Things' (yet), but I have read her previous book and multiple articles in her blog. I wonder if 100 things may lead to 100 heuristic principles. It seems like a lot of work for me alone; maybe if this first idea achieves some success…

Las comparaciones son odiosas, pero en este caso, además, son aplastantes:

 http://www.youtube.com/watch?v=dwvaMK2HTs4

El artículo trata, básicamente, de exponer las definiciones más habituales de Diseño Centrado en el Usuario (DCU) para concluir que no existe un consenso sobre qué es exactamente el DCU (o, como ya escribía en este blog, ¿existe el DCU?). Habitualmente se considera el DCU, bien como una filosofía de diseño, bien como un conjunto de técnicas o herramientas; pero tampoco existe un acuerdo sobre cuáles son esas técnicas. Eso hace difícil aplicarlo en la realidad.

Si bien hemos visto que las definiciones de DCU son bastante diversas, puede decirse que son compatibles entre sí, y de ellas podemos extraer algunas características comunes que deberían formar parte de una definición canónica del DCU:

• Está orientado a los usuarios del producto, que participan durante todo el proceso.
• A pesar de denominarse “diseño”, en realidad se aplica durante todas las fases del desarrollo (planificación, diseño, desarrollo, evaluación), desde las primeras etapas.
• Es iterativo.
• Es multidisciplinar.
• Su objetivo es obtener productos usables y satisfactorios para los usuarios.
  

 A partir de ahí, se realiza una propuesta concreta (apartado 4 del artículo) para acercarnos a un verdadero DCU, en tres fases:

1. Seleccionar un conjunto de técnicas básicas de DCU.
2. Seleccionar o definir una implementación para cada una de esas técnicas.
3. Identificar los elementos comunes entre ellas.

El propósito es definir con más claridad qué es el DCU, y facilitar así tanto su aplicación en proyectos reales como la implementación de herramientas de documentación y/o gestión. Por último, el artículo finaliza con el primer paso de esa propuesta: una selección de técnicas de DCU básicas.

A partir de ahí, en un futuro cercano espero poder dedicar esfuerzos a las siguientes fases de la propuesta. Por supuesto, el conjunto de técnicas seleccionadas es subjetivo, mejorable y discutible; cualquier comentario que queráis hacer con respecto a la selección de técnicas o a cualquier otro contenido del artículo podéis dejarlos aquí mismo.

Tomemos, por ejemplo, la página de descarga del antivirus avast!:

La página cumple bien sus objetivos, destacando la opción más importante ("Descargar") y ofreciendo información adicional que puede resultar útil al usuario interesado; sin embargo, estas son algunas posibles debilidades de la página:

Debilidades

1. Publicidad poco diferenciada

La publicidad, situada en diferentes puntos de la página, no tiene un diseño visual suficientemente diferenciado que la distinga claramente de los contenidos propios de la página. En este caso es todavía más serio, ya que el programa que se ofrece en la publicidad es la competencia directa del que se ofrece en descarga; un usuario poco experimentado y/o poco atento, con tantas opciones "Descargar", es posible que se pierda o descargue el programa equivocado.

Si bien puede no parecer un problema excesivamente grave, hay que tener en cuenta que la confianza es un aspecto crítico en una página de descargas: si los usuarios dudan de que se están descargando el programa deseado, es probable que dejen de usar esta página y acudan directamente a la página del propio programa para descargarlo.

2. Enlace de descarga desaparece

Cuando se accede a alguna de las pestañas secundarias ("Extras"; "Imágenes"; "Vídeos"), el enlace principal de la descarga del programa desaparece, ya que está dentro de la pestaña "Datos básicos". Es cierto que aparece un enlace alternativo en la columna derecha, pero es probable que los usuarios que se decidan por la descarga vuelvan a buscar el enlace original. En todo caso, se obliga a un esfuerzo extra, bien sea para identificar el enlace en su nueva ubicación, bien sea para recuperar el enlace original.

3. Información detallada poco accesible

El enlace a la información detallada del programa aparece como un enlace poco destacado, no como una pestaña (donde sería lógico buscarla). Sí encontramos una pestaña "4 Extras" cuyos contenidos resultan poco previsibles; resultan ser enlaces con información auxiliar: documentación, soporte, etc.

Además, la información detallada se abre en una ventana tipo modal, lo que produce diferentes problemas de usabilidad: imposibilidad de enlazarla directamente, dificultades para imprimirla, etc. 

Sugerencias

Teniendo en cuenta los puntos anteriores, esta sería una sugerencia de rediseño con unos pequeños cambios respecto a la versión original:

1.  Diferenciar visualmente la publicidad

Utilizar un formato visual suficientemente diferenciado para toda la publicidad, que permita distinguirla claramente de los contenidos propios de la página. Un fondo diferente podría ser una posibilidad, aunque cabría estudiar otras como bordes, cambiar la ubicación de los anuncios, tipografía, etc. Lo importante es que el usuario sepa diferenciar cuál es el enlace de descarga del programa de los enlaces de publicidad.

2. Enlace de descarga siempre visible

Colocando el enlace de descarga por encima de la zona de pestañas se conseguiría que estuviera siempre visible en la misma ubicación, de modo que los usuarios que quieran iniciar la descarga lo ubiquen rápidamente.

3. Pestaña para la información detallada

La nueva pestaña "Detalles" incluiría la información detallada del programa, y la información se mostraría dentro de la propia pestaña (no como ventana modal). La información actual de la pestaña "Extras" podría colocarse a continuación de la información detallada, o mantenerse como pestaña con un nombre más claro (por ejemplo, "Enlaces adicionales").

En conclusión

Las recomendaciones anteriores se han realizado por iniciativa propia, sin tener en cuenta aspectos internos que habría que considerar en un rediseño real: objetivos, políticas de la organización, estadísticas web, etc. Además, antes de darlos por buenos sería necesario validar la efectividad de estos cambios mediante técnicas como los tests A/B o pruebas de usabilidad con usuarios. Pero, en todo caso, estas modificaciones podrían ser un punto de partida, por lo menos para empezar a discutir posibles mejoras de diseño.

Algunas de las críticas destacan de ella sus efectos especiales, pero el mérito de la película es que estos se integran naturalmente dentro de la historia y la complementan; es decir, la tecnología está al servicio de la historia o, casi podríamos decir, de la experiencia del usuario, y no al revés como ocurre con algunos títulos que seguramente todos tenemos en mente; deberían tomar nota muchos desarrolladores de interfaces de usuario, y especialmente, de páginas web.

De hecho, la primera mitad de la película resulta más interesante que la segunda, en la que toman mayor protagonismo las escenas de acción; con todo, esa segunda mitad más comercial no consigue estropear el conjunto, cosa que sí ocurre en otros remakes como La Guerra de los Mundos o Soy Leyenda.

Desde que empezaron a tomar protagonismo los efectos digitales en el cine y, especialmente, los actores virtuales, nos hemos preguntado en qué momento estos superarían a sus homólogos de carne y hueso. Pues bien, parece que el momento ha llegado, si bien es cierto que en este caso el protagonista digital no es humano sino un chimpancé (de nombre César) que, gracias a una tecnología bien utilizada, consigue una interpretación emocionante que destaca por encima de la de los protagonistas humanos.

Además, los guiños a la película a la que preceden son sutiles: el protagonista jugando con una pequeña réplica de la Estatua de la Libertad; una televisión en segundo plano que está mostrando el lanzamiento de la misión espacial en la que viajan los protagonistas de la primera película; etc. Es posible incluso que los responsables del título de la película (y de los tráilers) le haya hecho un flaco favor al querer "vender" algo que la película no es: el que resulte ser el origen del Planeta de los Simios no es el interés principal de la historia, sino un detalle casi anecdótico.

Así que, independientemente de que seas un fan o no de la película original, o de los efectos digitales, te recomiendo que la veas porque es una historia que merece la pena por sí misma. Ahora sólo cabe preguntarse: ¿veremos algún día a un actor digital nominado para un Oscar? 

Haciendo un resumen muy breve, ambos métodos son realizados por expertos, sin la intervención de usuarios, y están orientados a encontrar problemas de usabilidad; en la evaluación heurística el experto se basa en una serie de principios y buenas prácticas (las heurísticas) mientras que en el recorrido cognitivo el experto detecta los problemas a medida que hace una simulación de la ejecución de las tareas como si fuera un usuario.

En la práctica creo que el recorrido cognitivo tiene importantes ventajas:

• está basado y obliga a definir las tareas más importantes de la aplicación;

• la situación del experto suele ser similar a la del usuario enfrentándose a la interfaz.

Eso hace que los problemas detectados sean habitualmente problemas realmente relevantes. En cambio, en una evaluación heurística, al estar basada de hecho en un checklist, puede que no se siga el mismo flujo de interacción que el usuario (el comportamiento del experto es menos real), y se corre el riesgo de reportar problemas menores y pasar por alto los realmente importantes.

De manera similar a Jeff Sauro, creo que los principios heurísticos pueden complementar al recorrido cognitivo para detectar problemas adicionales después de haber realizado el recorrido, y también para clasificar los problemas detectados.

Evaluación heurística, ¿técnica objetiva?

¿Por qué entonces es mucho más popular la evaluación heurística que el recorrido cognitivo como técnica de usabilidad? Quizás porque está basada, al menos en teoría, en unos principios generales y objetivos, lo que debería reducir la subjetividad de la técnica. Sin embargo, en la práctica esos principios generales no suelen funcionar, y el resultado de cualquier técnica de revisión de usabilidad (incluida la evaluación heurística) va a depender en gran medida de la pericia y conocimientos del experto evaluador.

De hecho, tengo la impresión de que muchos expertos y empresas que, por costumbre o imitación, afirman realizar evaluaciones heurísticas, llevan a cabo realmente recorridos cognitivos. Quizás una de las primeras cosas que debiéramos hacer para mejorar la popularidad de los recorridos cognitivos como técnica de usabilidad debiera ser encontrarle un nombre que "venda más".

Para empezar, son dos conceptos que no tienen una definición única; podemos empezar por la definición de "usabilidad" de ISO 9241:

Usability: the effectiveness, efficiency and satisfaction with which specified users achieve specified goals in particular environments. 

(las negritas son mías; luego veremos por qué). Por supuesto, hay muchas otras definiciones de usabilidad, pero probablemente esa es la más extendida.

Todavía menos clara está la definición de "user experience"; tomemos también la de ISO 9241:

User experience: a person's perceptions and responses that result from the use or anticipated use of a product, system or service

Es un concepto difuso que hace referencia a la percepción del usuario del uso de un producto, sus emociones, sus sensaciones usándolo… Nadie puede discutir que eso es lo realmente importante, porque no solo queremos que nuestros productos sean efectivos y eficientes, sino también que nuestros usuarios los adoren. Pero, un momento… ¿no es eso prácticamente lo mismo que hablar de su satisfacción? ¿Precisamente esa satisfacción que ya está incluida en la definición de usabilidad?

¿Poca usabilidad o mala UX? ¿Importa?

Por eso mismo creo que es un debate vacío: que la experiencia de usuario es algo fundamental es algo que difícilmente se puede discutir (otra cosa es si la experiencia de usuario es algo que se puede diseñar). Ahora… ¿eso es o no "usabilidad"? Pues depende: si se piensa únicamente en efectividad, eficiencia o facilidad de uso, como hacen algunas definiciones, entonces no. Pero si incluimos la satisfacción del usuario, entonces usabilidad y UX son equivalentes.

Puede resultar divertido intentar pensar en un producto cuya "experiencia de usuario" consista en dejar insatisfecho al usuario, pero probablemente eso requiera retorcer demasiado el significado de las palabras.

A efectos prácticos, parece que el perfil de "experto en usabilidad" está bastante más definido que el de "diseñador de UX"; probablemente, un experto en usabilidad está más orientado a resolver problemas en diseños existentes, y un experto en UX trabaje con diseños nuevos. Pero nuevamente, todo depende de la definición que tomemos.

En conclusión, el debate sobre si usabilidad y UX son lo mismo creo que no aporta nada interesante más allá de una cuestión puramente semántica; no parece que vayamos a conseguir mejores diseños ni técnicas gracias a esa dicotomía, que es lo que suele ocurrir en todos los debates en los que ni siquiera están bien definidos los conceptos de los que se está hablando.

Una definición alternativa de UX  bastante más concreta y, por lo que yo sé, bastante original, es la de Jared Spool, que considera la experiencia de usuario a lo que ocurre entre las actividades o tareas (los huecos). Es bastante restrictiva, pero lo suficientemente novedosa como para que permita hablar de la UX desde un punto de vista diferente.

"Más allá del cuchillo de palo: hacia una herramienta integrada para un verdadero diseño centrado en el usuario"

artículo (PDF, 525 KB)

presentación (PDF, 845 KB)

 Y algunas capturas de la presentación:

http://www.youtube.com/watch?v=JYqUVuyYSt8

En su libro más popular, "El Cisne Negro" (nada que ver con la reciente película), Taleb expone que muchas disciplinas supuestamente científicas como la sociología, la meteorología, la política y, especialmente, la economía, son tan complejas y se ven tan tremendamente afectadas por acontecimientos puntuales imposibles de prever (los "cisnes negros"), que pretender hacer predicciones válidas en la mayoría de casos es totalmente inútil. Y lo peor es que ni siquiera somos conscientes de lo malos que somos haciendo predicciones.

Por supuesto, Taleb no se refiere específicamente al mundo del diseño de interfaces, pero es inevitable llegar a la misma conclusión. También es cierto; no somos buenos diseñando interfaces. Por eso todos los enfoques de Diseño Centrado en el Usuario son iterativos: sabemos que no vamos a encontrar una buena solución a la primera, y por eso vamos probando y refinando hasta encontrar un diseño válido ("somos buenos descubriendo cosas").

¿Y cuáles son nuestros cisnes negros? Los usuarios: es imposible prever exactamente cómo van a responder los usuarios ante una interfaz (cualquier que haya realizado o presenciado un test de usabilidad lo ha comprobado).

¿De qué nos sirven entonces cosas como principios de diseño, guías de estilo, principios heurísticos, etc.? Taleb afirma que a posteriori es fácil ser experto, por ejemplo, para explicar cuáles fueron las causas de la Primera Guerra Mundial o de la actual crisis económica, que ahora parecen eventos inevitables y totalmente explicables. Pero la realidad es que, en sistemas tan complejos, nadie puede aplicar principios económicos o teorías políticas para predecir ese tipo de acontecimientos.

Representación de leyes de la Gestalt sobre percepción. ¿Sirven para crear un diseño?

Así, es posible que en el diseño de interfaces suframos una versión reducida del mismo fenómeno; esos principios de diseño, esas guías de estilo, esas leyes de la percepción (como la de Fitts o las de la Gestalt) y esos principios heurísticos nos sirven de apoyo para explicar, a posteriori, por qué un determinado diseño funciona o no funciona. Pero deberíamos plantearnos si, como afirma Jared Spool, a la hora de diseñar, simplemente no sirven. 

Jakob Nielsen defined guerrilla HCI as a collection of usability techniques that may be performed along development projects in an informal and fast way, requiring few resources, getting acceptable results and avoiding the intimidation barrier of using that kind of techniques.

One advantage of guerrilla HCI is that it can be performed without great involvement of the development team, and consequently, it is useful in traditional website development.

According to their own nature, websites must be self-explanatory and their interface must follow existing standards in order to make possible that anyone can use it without advanced skills neither previous training.

For example, guerrilla HCI could be perfectly applied in the evaluation of an e-commerce website or one belonging to a university since, in principle, they don't require special knowledge.

Nevertheless, there are cases where it's not that simple…

Board the ship

Sometimes, usability experts have to deal with development projects where they know little or nothing about the system being developed; it may be a desktop application, an intranet or a specialized web application. In those cases, it's difficult to apply straight guerrilla HCI since the expert doesn't know basic characteristics of the system, like user roles, which are the most important tasks, or the use context.

In those situations, it's necessary to apply something we can call "ship-boarding usability": the expert has to "reach" the development team and "board the ship" to get to know the objectives and the project status so to improve the system's usability, "changing the course" when necessary.

To that end, I suggest selecting a collection of basic and simple techniques between those usually included in User Centered Design methodologies:

1. User roles (and personas).
2. (Essential) use cases.
3. User interface prototyping.

1. User roles (and personas):
who will use the application?

In many development processes, user profiles or roles are implicit in developers' knowledge, but there isn't any explicit documentation about them. In such situations, I suggest first to develop documents describing basic characteristics of users who will use the system; in this phase, they will usually uncover that user roles are not as clear as it seemed, or even new roles are discovered.

One of the templates that may be used for that purpose is this one developed by Constantine & Lockwood:

User Role Model (PDF, 145 KB)

It's not indispensable to follow strictly that structure; the important point is to identify, at least, user roles and their main characteristics.

Ideally, that documentation (and any other described in this article) should be based on a platform allowing the developers to read and update it quickly and easily.

Once those roles are identified, it's possible to use "personas" technique to have a more realistic reference of the users; however, I think it's a technique that requires the developers/designers to have a good attitude to be effective.

2. (Essential) use cases:
how will be the interaction with the system?

System requirements, when defined, are many times written as a list of functionalities ("the application should …") , but without any instruction of how the interaction between the system and the user should be. That forces designers (who sometimes are also the programmers) to make assumptions when implementing the interface; that leads frequently to usability problems.

Through use cases, it's possible to describe system functionalities  in a more structured way. There are many descriptions of how use cases should be structured; I specifically suggest using what they call "essential use cases", also defined by Constantine & Lockwood. They propose a high-level semi-structured description (as a dialog) of the user-system interaction. This is the template:

Essential Use Case (PDF, 146 KB)

Identifying and defining the most important and/or problematic use cases first help to get an idea of the purpose of the system and allows to concentrate the efforts where the results will be more effective.

Moreover, this kind of use cases has the following advantages:

• They allow to refine the requirements specification, detecting problems, inconsistencies and lack of definitions in an early stage of development.
• They are a reference for the interface designer; the high-level specifications give freedom to the designer when choosing technologies and concrete solutions.
• They will be the starting point for later usability techniques.

3. User interfaces prototyping:
what will the screens be like?

User interface prototyping is a well-known and very used technique. However, launching into prototyping without a clear definition of the users and the details of the interaction may be really difficult. Using the previously mentioned techniques, prototype creation (of new interfaces or redesigns of existing ones) would be much more effective.

In the ship-boarding usability case, prototypes would be useful to design the most critic interfaces (from the most important use cases), or the modification of existing interfaces (to fix usability problems).

From there…

With the help of the previous techniques, the approach to the application will be less traumatic and the specific usability methods will become more productive and easier to apply: for example, heuristic evaluations will be centered on the most important aspects of the application, taking into account the characteristics of its users; and user testing will have a starting point for user recruitment in user roles, and for scenarios and tasks in use cases.

Anyway, the documents and knowledge generated by those techniques will work out useful through the entire development process, and not just for interface design or usability methods. In general, one of the benefits of applying usability techniques during a development process is that they help to increase the quality of the processes themselves and of their documentation.

[…] Y así la ciudad nuestra y vuestra vivirá a la luz del día y no entre sueños, como viven ahora la mayor parte de ellas por obra de quienes luchan unos con otros por vanas sombras o se disputan el mando como si éste fuera algún gran bien. Mas la verdad es, creo yo, lo siguiente: la ciudad en que estén menos ansiosos por ser gobernantes quienes hayan de serlo, ésa ha de ser forzosamente la que viva mejor y con menos disensiones que ninguna; y la que tenga otra clase de gobernantes, de modo distinto.

Platón, La República (siglo IV a.C.)

#nolesvotes (consulta las preguntas frecuentes sobre #nolesvotes si tienes dudas)