Un impostor entre dos aguas

Algunas cosas que podrían aprender diseñadores y desarrolladores, unos de otros.

Un impostor entre dos aguas

Soy un impostor por partida doble.

Si el síndrome del impostor hace que dudes de tu competencia profesional a pesar de la experiencia o los logros que acumules, yo tengo el dudoso mérito de poder ser un fraude en, al menos, dos disciplinas: el diseño de interfaces (vamos a llamarlo así por ahora) y el desarrollo de software.

Me cuesta considerarme un diseñador porque, a pesar de tener un máster en diseño de interfaces cuyo trabajo final fue una herramienta de soporte al diseño, publicar algún artículo sobre el tema o haber desarrollado varios proyectos de prototipado y evaluación, no me emociono con los diagramas de UX, ni creo que el design thinking sea la solución a todos los problemas de la humanidad, ni considero que cosas como el diseño colaborativo sean tan positivas, ni tengo una obsesión compulsiva hacia los post-its.

Aunque tampoco debo de ser un desarrollador como Dios manda porque no soy un enamorado de la línea de comandos, ni proclamo a gritos lo maravilloso que es Git, y supongo que voy camino de la ceguera porque no he memorizado la combinación de teclas para poner cualquier editor con el fondo oscuro. Y eso que, cuando peina canas, uno ya tiene en la mochila casi de todo: desde el diseño de modelos de datos, SQL y stored procedures, hasta algunas experiencias con los últimos frameworks JavaScript, pasando por Java, .NET o PHP.

Pero… veamos el lado positivo: tener un pie a cada lado de la frontera hace que veas las cosas con cierta perspectiva, que puedas comparar hábitos y maneras de trabajar, e incluso que puedas proponer cómo unos y otros pueden beneficiarse mutuamente de buenas prácticas y aprender de errores ajenos (que siempre es más práctico que hacerlo de los propios).

(more…)

Experiencia de usuario (UX) en sitios de viajes

Algunos problemas comunes y recomendaciones para mejorar la experiencia de los usuarios de sitios web de viajes y vacaciones.

User Experience (UX) in travel sites, in English

Buscando un viajeHay temporadas en las que parece que no se puede poner la TV sin que aparezca anunciado algún sitio web sobre viajes. Además, últimamente se insiste especialmente en la facilidad de uso, y es lógico: con tanta oferta, que los usuarios consigan sus objetivos de manera sencilla puede ser un factor determinante a la hora de elegir uno u otro. Pero entonces, ¿qué factores hay que tener en cuenta a la hora de conseguir una buena experiencia?

Los sitios web de viajes no son una excepción a la regla de que no hay trucos mágicos a la hora de conseguir una buena experiencia. Los resultados se consiguen aplicando las técnicas habituales de usabilidad y UX, siguiendo estándares y buenas reglas, desarrollando múltiples alternativas y, sobre todo, conociendo bien a los usuarios, testeando y midiendo.

Aún así, sí que podemos identificar aspectos que merecen especial atención en este tipo de sitios web. A continuación tenéis algunos de ellos. (more…)

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. 🙂