índica. océanos de contenido

La conocida expresión “escucha a tus usuarios”, pilar central del diseño centrado en el usuario, puede llegar a tener su vertiente negativa, sobre todo en aplicaciones muy específicas.
Los tests con usuarios, una de las principales técnicas de este enfoque, se desarrollan en escenarios ad hoc, donde tus usuarios se ven “forzados” a comentar en voz alta y la necesidad no es real, sino figurada. De estas pruebas surgen opiniones, muchas veces condicionadas y, a veces, contradictorias. Cuanto más bases tus decisiones en los gustos de una determinada población menos apropiada será la solución adoptada para el resto.

¿Diseño centrado en el usuario o diseño centrado en la actividad?
Dependiendo del tipo de aplicación que estés definiendo, con el diseño centrado en la actividad podrás sacar conclusiones más interesantes a la hora de definir una interfaz.

Estudiar al detalle para qué actividad sirve la interfaz que estás desarrollando y cuáles son las tareas implícitas de dicha actividad es casi más importante que conocer a los usuarios que van a utilizarla. Conociendo en profundidad lo primero tienes prácticamente ganado lo segundo: Qué usuarios van a usar lo que estás definiendo.

Pero… ¿Qué es la actividad?
La actividad es muchas veces confundida con el término tarea. En realidad tarea es una subdivisión de la actividad. Podríamos decir que la actividad está compuesta por un conjunto de tareas. A su vez, estas tareas agrupan un conjunto de acciones y estas acciones están formadas por un conjunto de operaciones. La unión de tareas + acciones + operaciones da como resultado final la actividad desarrollada por el individuo.

En otras ocasiones ya hemos hablado de que no es lo mismo la tarea prescrita (la que se supone que tiene que desempeñar el usuario) que la tarea real (aquella que realmente desempeña, basada en la experiencia individual, con sus atajos, trucos, etc…) y este detalle también es necesario tenerlo muy en cuenta a la hora de abordar un diseño centrado en la actividad.

Un ejemplo.
Conducir un coche (actividad) engloba un conjunto de tareas (girar el volante, meter las marchas, frenar…). A su vez, cada una de estas tareas llevan implícitas un conjunto de acciones y operaciones (para frenar hay que levantar el pie del acelerador, apretar poco a poco el embrague, meter marchas más cortas… ).

Lo más curioso del ejemplo anterior es que la fabricación de estos coche no se basa en test con usuarios (Crash test dummies aparte). Es algo que ha ido evolucionando y mejorando a lo largo de los años, generación tras generación. Sin embargo, gracias al profundo conocimiento adquirido de la actividad los coches evolucionan y mejoran constantemente. Este tipo de diseño evolutivo, que va a pasando de generación en generación Norman lo denomina Folk Design.

Conclusiones.
En aplicaciones muy específicas tu interfaz no puede ser estática y simplemente adaptarse al “Libro de Estilo”. Tiene que ser una aplicación dinámica, vital, muy adaptada al conjunto de tareas que tus usuarios desarrollan en un entorno muy específico. Además de estar frente a una pantalla tus usuarios también realizan tareas paralelas, muchas veces apartados de dicha pantalla, de las que depende el éxito final de la actividad.

Christine Frederick en su libro “The Labor-Saving Kitchen” (1919) observó lo siguiente: “We find that work in the kitchen does not consist of independent, separate acts, but of a series of inter-related processes”.

Simplemente eliminando las palabras “in the kitchen” que Christine menciona en el texto anterior el enfoque es, si cabe, más potente, consolidando aún más su observación.

Quien quiera indagar más sobre el tema recomiendo una pausada lectura de los siguientes artículos, fuentes de inspiración de este post:

Human-Centered Design Considered Harmful (Don Norman)
HCD harmful? A Clarification (Don Norman)

A raíz de un artículo en Smashing Magazine sobre la divina proporción me ha surgido un planteamiento sobre la forma de trabajar a la hora de generar propuestas de interfaz.

Por un lado me da la sensación de que hay gente que trabaja primero generando el boceto y luego adaptándolo a una retícula, pero estoy seguro de que lo contrario también se da: Ir incluyendo los distintos elementos en la retícula hasta generar el boceto final.

No sé cuál de las formas de trabajo es mejor. Creo que depende un poco del proyecto: Si estás trabajando sobre un concepto nuevo seguramente trabajaría primero sobre un boceto, para después adaptarlo a la retícula elegida. Por otro lado, si el proyecto ya tiene una estructura sobre la que se basan el resto de pantallas, tiene más sentido trabajar directamente sobre la retícula.

En cualquier caso les presento a 960 Grid System, sencillo framework basado en un ancho de 960px para dividir tu interfaz en 12 o 16 columnas (Vía Gti).

La primera llamada de teléfono realizada desde un teléfono considerado “móvil” la realizó Martin Cooper la mañana del 3 de abril de 1973 en Manhattan, frente a un concurrido número de reporteros que querían retratar el histórico momento. El modelo en cuestión era un DynaTAC 8000X (Dynamic Adaptive Total Area Coverage) desarrollado por la compañía Motorola, que hasta entonces su principal nicho era fabricar radios de coche.

La idea no era nueva, algo parecido al teléfono móvil ya existía integrado en algunos coches de aquella década, aunque cada modelo necesitaba su propio género de transistores, cables, filtros, etc… Además, tenían que estar vinculados al vehículo para poder funcionar.

Pero el objetivo de esta presentación multitudinaria era otro. La idea era llamar la atención de la Federal Communications Commission (FCC) para que que ésta autorizase un aumento de las frecuencias de ondas que hasta entonces se utilizaban. Los car-phones funcionaban en frecuencias bastante bajas, pero de largo alcance. Baja frecuencia implicaba también menos canales, lo cual limitaba el aumento de potenciales usuarios para adquirir estos teléfonos para sus coches (a pesar de su disparatado precio).

Diez años más tarde, en septiembre de 1983, Motorola hizo historia cuando la FCC aprovó el DynaTAC 8000X. El primer teléfono móvil entraba en el mercado.

Mucho ha llovido desde entonces. Ahora Cooper tiene 80 años, aunque sigue muy involucrado en temas tecnológicos (es cofundador de la compañía ArrayComm). Aparte de haber creado uno de los gadgets más importantes de los últimos tiempos, lo que más me gusta de este hombre es su visión sobre la tecnología: “La tecnología sólo es tecnología si sirve para algo útil a la sociedad“.

Tener la suerte de crear un producto, ver su increíble evolución y encima estar vivo para poder contarlo creo debe ser una experiencia de lo más gratificante. Otros no han tenido tanta suerte. Si Graham Bell levantara la cabeza y viera esto (vídeo de 03:41 min.):

Hace unos días Economist.com lanzaba el rediseño de su nueva home.

Lo que más me llamó la atención fue el aumento del tamaño de la tipografía y una notable reducción a nivel de contenidos en portada. Ahora todo está mucho más claro, sin tanto contenido luchando por ser leído en primer lugar.

Sin embargo, vuelvo a detectar el mismo problema que ya existía en la versión anterior: Un pobre criterio a la hora de definir el código de clicabilidad. Sin contar con los banners, he contado unas siete formas distintas de navegar por los contenidos de la home, como se puede apreciar en la siguiente imagen:

Este escenario provoca un aumento del nivel de incertidumbre, ya que no existe una criterio unificado de comportamiento (o affordances) de los elementos de navegación y se generan dudas sobre qué texto es clicable, cuál tiene rollover…

Tener un criterio sencillo y sólido sobre cómo deben comportarse los enlaces y botones aporta más confianza a los usuarios. Conocen desde el primer momento qué elementos llevan a más información y cuales no.

En cualquier caso, soy de los que opinan que tener bien definidas las secciones interiores, las que más se visitan, ayuda a ir visualizando cómo será la que quizá sea la sección menos importante: La home.

No hace falta ser muy listos para darse cuenta de que la gente prefiere ser recompensada a ser castigada por hacer algo. A nadie le gusta el castigo y, sin embargo, recibimos con agrado un premio, por muy insignificante que sea.

El caso es que si te das una vuelta por ahí encuentras grandes ideas que tratan de aplicar el mantra “mejor recompensar, pero penalizar también funciona”. La recompensa, bien definida y pensada, puede incluso ofrecer beneficios para quienes ofrecen el premio.

Sirva el siguiente ejemplo: Muchas ciudades, debido a su ubicación geográfica, se ven obligadas a construir puentes para que vehículos y medios de transporte puedan entrar y salir de ella sin tener que dar largos rodeos para poder acceder a la urbe: Lisboa o San Francisco son claros ejemplos.
El acceso a estas ciudades está condicionado por sus puentes. El paso de estos puentes conlleva siempre el pago de una tasa, pero con “truco”: Los usuarios que salen en coche de la ciudad (y que ayudan a descongestionarla a nivel de tráfico) no pagan nada, los usuarios que entran en ella (la congestionan) tienen que pagar su correspondiente tarifa en función del tamaño del vehículo. Muchos usuarios se quejan cuando entran en la ciudad preguntándose por qué diablos tienen que pagar para cruzar un simple puente. De lo que no nos damos cuenta es de que, saliendo de la ciudad estamos ayudando a minimizar el tráfico.

Este ejemplo de la vida real lo podemos aplicar en la web. Recompensar a los usuarios que, por ejemplo, ofrecen más contenido a la web y “penalizar” (o no premiar simplemente) a los que son menos proactivos puede llegar a ser una buena estrategia si se plantea como es debido.

Venere es un portal de reservas de alojamientos por internet, muy recomendado, por cierto. Cada vez que hago una reserva a través de ellos, días más tarde recibo un email donde me piden la opinión sobre el hotel que reservé a través de ellos. A veces sí, estoy con ganas de escribir y dedico algunas líneas para opinar sobre dicho hotel, pero otras veces simplemente no me apetece.

Un buen incentivo sería ofrecer a aquellos usuarios que escriban una reseña un pequeño descuento en su próxima reserva. Este gesto por parte de Venere ayudaría muchísimo a aumentar lo más interesante de la web: Las opiniones de los usuarios. Y, de paso, te aseguraría una próxima visita a la web, pues a todo el mundo le gusta usar un descuento que nos han regalado, ¿no? Rizando el rizo, y a riesgo de equivocarme, se me ocurre que, si el comentario es negativo, los costes del descuento los podría asumir el propio hotel donde el usuario se ha hospedado, al fin y al cabo el responsable final de un mal servicio es el hotel. Si el comentario es positivo dicho descuento lo podría asumir Venere. Este dinámica también se podría aplicar a portales como los amigos de TopRural, donde los comentarios son claves a la hora de tomar la decisión final.

El criterio a seguir es sencillo: Por un lado, a mejor contenido, mejor premio, en forma de descuentos, regalos, etc. Por otro lado, a peor (o menor) contenido, penalizar, pero sin que ésto se vea como un castigo realmente. De esta forma recompensas a los usuarios más proactivos, los que más esfuerzo hacen por generar buen contenido y de alguna forma animas a los más perezosos a generar contenido decente. Lo más importante es hilar muy fino. Si los usuarios se ven en la obligación de hacer algo sencillamente no lo harán, y al final puede perjudicarte, pero exprimiendo interfaz y usuarios/clientes se pueden conseguir beneficios interesantes.

Al final se trata de pequeñas vueltas de tuerca que no sólo ayudan a obtener mejor contenido, sino que encima recompensan a los usuarios que más te utilizan.