interfaces

Y tu web, ¿es de chocolate o de fruta?

Un experimento psicológico nos ayuda a entender por qué es tan importante que nuestras interfaces sean sencillas y “no hagan pensar” al usuario.

Ocurre a veces. Después de estudiar en detalle una aplicación o un sitio web para entender bien cómo funciona y cuál es su propósito, pasas a proponer un prototipo o un rediseño de las páginas o pantallas con el loable objetivo de que sea más inteligible y fácil de usar para sus usuarios. Y entonces, alguien (habitualmente responsable del producto) dice algo parecido a esto:

  • “Bueno… Tampoco hace falta que sea tan sencillo”.
  • “Nuestros usuarios no son tontos; ya saben algo del tema”.
  • “Es que hacen falta unos conocimientos mínimos para usar esto”.
  • “No pretendemos que cualquiera pueda usar nuestro producto”.

Ante lo cual tú, que eres el “experto” en estas cosas, puedes reaccionar de dos modos: o te agarras a tu autoridad y a la máxima de hacer las cosas lo más sencillas posibles, e intentas que se tengan en cuenta tus sugerencias; o bien sufres una crisis de fe y te preguntas si realmente es necesario hacerlo todo tan sencillo, o hasta dónde tenemos que llevar aquello de “No me hagas pensar” del libro de Steve Krug.

Pues bien: en esos momentos de duda existencial viene al rescate un experimento realizado a finales de los 90 por los psicólogos de la Universidad de Iowa, Baba Shiv y Alexander Fedorikhin. (more…)

Ship-boarding usability

Applying usability techniques during a development process that is already underway and little known may be really hard. Below I suggest a few techniques so as to “board the boat” in an effective way.

Disponible también en español

Board the ship (detail)

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… (more…)

Diseño: las guías de estilo no sirven

Un resumen y algunas conclusiones extraídas de una charla de un conocido experto en interfaces de usuario.

No lo digo yo, sino Jared Spool, una de las autoridades mundialmente reconocidas en diseño de interfaces en una charla titulada “Anatomía de una decisión de diseño” celebrada en 2010 en el marco del congreso User Interface 15.

Y esa no fue la única afirmación interesante que se puede extraer de esa charla; entre otras, también sostiene que:

  • El diseño sin involucrar a los usuarios (ya sea para uno mismo o aplicando los conocimientos y la experiencia de expertos) puede ser perfectamente válido en determinados proyectos y circunstancias.
  • Diseñar la “experiencia de usuario” consiste, ni más ni menos, en llenar los “huecos” entre las actividades del usuario.

Todo ello dentro de una sesión que resumo a continuación.

(more…)

“The Emotion Machine” y algunas reflexiones

Una revisión y algunas ideas surgidas a partir del último libro de Marvin Minsky.

The Emotion Machine (by Marvin Minsky)Recientemente he terminado de leer “The Emotion Machine“, la última obra de Marvin Minsky; Minsky es considerado uno de los pioneros de la Inteligencia Artificial, y entre sus múltiples logros está, por ejemplo, haber creado el primer simulador de red neuronal. Es un auténtico gurú en la materia (si es que esa palabra puede utilizarse todavía sin connotaciones negativas).

En este libro, Minsky profundiza en un modelo de mente humana que ya había empezado a describir en su obra anterior. Resulta algo paradójico que algunos de los resultados de la Inteligencia Artificial más novedosos hayan sido descripciones de la mente humana y, especialmente, de su funcionamiento. La Inteligencia Artificial necesita y define los procesos mentales para reproducirlos en un ordenador; por tanto su nivel de descripción de esos procesos está en un interesante nivel funcional intermedio entre el nivel de detalle de la neurología y de las estructuras cerebrales, y algunas clasificaciones muy genéricas (y excesivamente simplistas) de la psicología clásica.

No es la primera vez que leo sobre la idea de que la informática consigue resultados verdaderamente importantes en campos a priori ajenos a los ordenadores. Minsky menciona que la informática nos ha dotado de conceptos que permiten describir mejor nuestra mente. Por ejemplo, para él los procesos mentales se pueden clasificar, de modo similar a los lenguajes de programación, en “interpretados” y “compilados”; los primeros se corresponden con habilidades que no tenemos automatizadas y que debemos realizar “paso a paso” (el nivel que tenemos como aprendices), y los segundos podemos realizarlos de un modo automático (como los realiza un experto, de manera casi inconsciente). Como decía Dijkstra, “la informática no trata más sobre ordenadores de lo que la astronomía trata sobre telescopios”.

Un modelo de la mente

Para Minsky, los modelos de mente humana que consisten en estados y procesos individuales son demasiado simples. Cree que es mejor considerar la mente como un conjunto de recursos o capacidades (una “nube”) que pueden activarse en diferentes momentos. Así, los “estados mentales” estarían definidos por el conjunto concreto de recursos que estarían activos en ese momento.

La mente como un conjunto (o nube) de recursos

(more…)

Usabilidad de abordaje

Aplicar criterios de usabilidad en un desarrollo que ya está en marcha y que no se conoce a fondo puede ser muy complejo. A continuación se proponen unas pocas técnicas básicas que permitirán “subirse al barco” de un modo efectivo.

English version of this post

La usabilidad al abordaje(detalle)Jakob Nielsen acuño el término usabilidad (o interacción persona-ordenador) de “guerrilla” para referirse a las técnicas de usabilidad que pueden aplicarse en proyectos de desarrollo de una manera informal, rápida y con pocos recursos consiguiendo resultados aceptables y evitando la barrera que supone introducir ese tipo de técnicas.

Esa usabilidad de guerrilla tiene como ventaja que puede realizarse con (relativamente) poca implicación del equipo de desarrollo, y es por tanto aplicable en el caso de desarrollos de sitios web tradicionales. Por su naturaleza, los sitios web tienen que ser autoexplicativos y tener un funcionamiento que siga los estándares existentes, ya que su público potencial es habitualmente muy variado y no puede confiarse en conocimientos avanzados o una formación previa.

Por ejemplo, puede aplicarse perfectamente la usabilidad de guerrilla en la evaluación de un sitio web de comercio electrónico, o en el de una universidad, ya que (en principio) no necesitan mayores conocimientos previos.

Sin embargo, existen situaciones en las que no es tan sencillo… (more…)

Un email para gente mayor

Una interfaz ultra-sencilla para los programas de correo electrónico facilitaría que personas de edad avanzada utilizaran ese sistema de comunicación. ¿Existe algo así?

Scott Adams es conocido por ser el autor de las tiras de Dilbert; pero además es una de las mentes más brillantes de las que he leído en Internet, como demuestra a menudo en su blog.

Precisamente en su blog publicaba hace ya algún tiempo el artículo E-mail for Senior Citizens (“E-mail para ciudadanos mayores”) en el que proponía un software que actuara como una capa de interfaz sobre los sistemas habituales de correo (como Gmail), ocultando los innumerables detalles y funcionalidades de esos sitios, ofreciendo a los usuarios de edad avanzada una interfaz muy, muy simple. Estas son las características que proponía:

  • Tres grandes botones: “LEER”, “ESCRIBIR” y “OTROS”.
  • No necesitar doble-click para ninguna acción.
  • Recibir únicamente correos desde direcciones existentes en su agenda, evitando así el spam.
  • Abrir automáticamente los anexos.

Por supuesto, otros usuarios podrían realizar tareas de soporte, como por ejemplo incluir nuevas direcciones en su agenda.

Scott Adams no es ningún experto en accesibilidad, pero vemos que, con un poco de sentido común y buenas intenciones, es posible idear un sistema que facilitaría que gente de edad avanzada pudiera comunicarse con sus allegados mediante el correo electrónico. Estoy seguro de que casi todos podemos pensar en alguien que conocemos que no utiliza actualmente el e-mail, pero que posiblemente lo hiciera si pudiera utilizar un sistema como el descrito más arriba.

La cuestión es: no parece que un sistema de ese tipo fuera excesivamente complicado de implementar. Entonces, ¿por qué no existe todavía? Y si existe, ¿por qué no es más popular? A veces las ideas más sencillas son las más poderosas.

Una de las tiras de Dilbert, protagonizada por su madre

La relación amor-odio entre las interfaces y los modelos mentales

Una tira cómica pone de relieve que diseñar interfaces sencillas es, en realidad, un proceso complejo.

Si diseñar interfaces fuera algo trivial, no existirían entonces las inconsistencias de las que hablaba (o, mejor dicho, dibujaba) Mauro Entrialgo en su blog hace ya algunos meses:

Tira de Mauro Entrialgo Tira de Mauro Entrialgo

Ya véis: diseñar una interfaz no es simplemente poner botones para todas las funcionalidades del aparato, sino que debe tenerse en cuenta el modelo mental del usuario de ese sistema.

¿Y qué es el modelo mental? Pues no, no consiste en imaginarse a Adriana Lima, sino que es la imagen del sistema que tiene el usuario en su cabeza; o, dicho de otro modo, cómo cree que funciona; los problemas vienen cuando el modelo mental no se ajusta al funcionamiento real. Y todo eso teniendo en cuenta que ese modelo no depende únicamente del diseño de la interfaz, sino también de experiencias anteriores.

Por eso, el modelo mental en el caso de la televisión es sencillo y se ajusta a su funcionamiento: “quiero que el volumen esté más alto [o más bajo]: si pulso el botón ‘subir’, subirá el volumen [si pulso el botón ‘bajar’, bajará el volumen]“. Cuando el modelo mental se corresponde con el funcionamiento del sistema, no hay problemas.

En el caso del ascensor la cosa se complica un poco: “quiero ir al piso X: si está por encima, pulso el botón ‘subir’; si está por debajo, pulso el botón ‘bajar’“. Esto obliga al usuario a hacer el (pequeño) esfuerzo mental de traducir el piso al que quiere ir (su verdadera intención) a la acción de subir o bajar. El modelo mental se ajusta bastante bien al funcionamiento del ascensor, en este caso muy reforzado por experiencias anteriores. Pero si nos encontráramos por primera vez ante un panel de botones de un ascensor, ¿tendríamos claro que el botón “bajar” es para ir hacia abajo, y no para que el ascensor baje?

El caso de la calefacción es el más complejo y estoy seguro de que muchos de nosotros nos encontraríamos con problemas ante un mando así. A no ser que tengas experiencias anteriores con sistemas parecidos, el usuario podría aplicar un modelo mental similar al caso de la televisión: “quiero que suba [baje] la temperatura: si activo el sol=calor [nieve=frío], subirá [bajará] la temperatura“. Una interpretación incorrecta que, encima, será difícil de detectar debido a que la respuesta del sistema subiendo o bajando la temperatura no es inmediata.

Lo más llamativo de muchas interfaces poco usables, como esta última, es que detectarlas puede ser más o menos difícil, pero corregirlas puede ser muy sencillo. En la calefacción, como decía el dibujante de Dilbert, sería mucho más sencillo que el usuario simplemente indicara la temperatura que desea, y fuera el sistema el que decidiera si necesita subir o bajar la temperatura.

Lo que diseñadores y desarrolladores deberíamos aprender de Supernanny

Parecería que el popular programa de TV tiene poco que ver con el desarrollo de software y el diseño de interfaces… pero algo sí que podemos aprender de él (y no es que los desarrolladores seamos como niños).

Seguro que recuerdas Supernanny, ese programa de TV en el que una psicóloga aconsejaba a diferentes padres (habitualmente al borde de la desesperación) en cuanto a la educación de sus hijos.

Quizás te sorprenda, pero podemos extraer algunas lecciones de su modo de actuar aplicables al desarrollo de software. Y si no, veamos cuál es la estrategia de Supernanny:

  • Observar el funcionamiento actual, sin intervenir en él.
  • Anotar los problemas detectados y su posible solución.
  • Exponer y aplicar esas soluciones al caso real.
  • Comprobar la efectividad de las soluciones.

¿Creéis que Supernanny sería tan efectiva si, en vez de proceder así, esperara a que los padres acudieran a su despacho, le expusieran el problema, y ella les diera una solución sin ni siquiera conocer a sus hijos? Parece obvio que no.

Entonces ¿por qué no seguimos el mismo esquema en el desarrollo de software? Habitualmente esperamos que el cliente nos cuente sus problemas, y nosotros desarrollamos la solución, muchas veces sin conocer en entorno de trabajo ni a los usuarios.

La técnica equivalente a lo que hace Supernanny en el ámbito del Diseño Centrado en el Usuario (y en otras muchas disciplinas) suele ser conocida como estudio de campo“.

Y es que, si bien es cierto que no hay dos niños iguales, lo mismo ocurre con los usuarios y sus situaciones. Y sí, seguro que Supernanny nos ayudaría con muchos clientes. 🙂

Google y sus patentes: ¿malas noticias para la usabilidad?

Las patentes de diseño en la web, como la conseguida por Google en los últimos días, pueden ser negativas no sólo para los responsables de sitios web sino también para todos los usuarios que las utilizamos.

Leía la semana pasada en Menéame que Google ha conseguido la patente del diseño de su home (página inicial). Mucho se ha escrito ya sobre las patentes (los casos del software y los medicamentos son, valga la expresión, “sangrantes”), aunque podríamos decir como resumen que, si bien en teoría existen para proteger las ideas originales y a sus creadores, en la práctica se convierten en un obstáculo a la innovación:

La creencia que sustenta la necesidad de las patentes y los derechos de autor es que, si no se les da una protección, el creador no va a innovar. “Pero debería ser algo obvio que es la competencia, y no el monopolio de ideas, lo que sustenta la creación”, añade el economista.

El problema añadido es que, en este tipo de patentes, existe un factor negativo más, y es el que afecta a la usabilidad de las aplicaciones web.

 Esquema de la página inicial de Google

Es innegable que muchos de los estándares de facto en Internet provienen de ciertos portales representativos como son Amazon, Ebay y, sobre todo, Google; si un diseñador tiene que crear un sitio web de comercio electrónico, de subastas, o un buscador esas son sus referencias, y antes de crear una interfaz totalmente nueva seguramente se inspirará (cuando no copie directamente) esas otras páginas.

Esto tiene como efecto positivo (si no es la causa) que los usuarios ya saben cómo utilizarlas, y no necesitan aprender cómo funciona cada una de ellas, para lo cual probablemente no tengan suficiente tiempo y/o interés.

Pero ¿qué ocurre si Google y otros sitios web empiezan a patentar y a hacer valer sus derechos sobre esos diseños? Los responsables de sitios web similares podrán optar por pagar los correspondientes derechos por utilizarlos, o bien tendrán que crear una interfaz totalmente distinta. Y esas son las malas noticias: cada sitio web tendrá entonces un aspecto y/o funcionamiento diferentes, y los usuarios tendrán que aprender cómo funciona cada uno de ellos.

Teóricamente esas nuevas interfaces podrían ser mejores que las existentes, pero pocas veces las mejoras se consiguen a través de una ruptura radical con lo existente sino que habitualmente provienen de mejorar lo que ya funciona.

Parece, pues, que en este caso los efectos negativos de las patentes no serían únicamente para los desarrolladores sino también para los usuarios, es decir, todos nosotros.

¿Cómo nos afectarán en la práctica esas patentes?

Lo que la usabilidad no es

Un extracto de diferentes textos en los que se ha utilizado el término “usabilidad” de un modo incorrecto.

El término “usabilidad” se ha convertido (no hace falta decir que por desgracia) en uno de esos que, sin conocer exactamente su significado, se le cuelga a cualquier producto tecnológico para que parezca lo suficientemente sofisticado; otros que le han precedido ya no nos dicen nada: alta fidelidad, modular, multimedia, 2.0, … Casi forman parte de eso que algunos llaman economía de la cancamusa.

Tira cómica sobre 2.0 

Por eso es importante no perder de vista cuál es su verdadero significado. Es fácil encontrar definiciones más o menos oficiales de usabilidad, pero podemos quedarnos con que se trata, básicamente, de que los productos sean fáciles de usar. Aunque quizás sea más ilustrativo señalar algunos casos en los que el término no se utiliza con propiedad.

Usability logo

(more…)