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)
6 respuestas
Yo por llevar la contraria (más que nada) te diría que no son enfoques contrapuestos, sino complementarios (o incluso que uno es parte del otro) y que dependen mucho del conocimiento de la tarea que como diseñadores podamos tener.
Cuando vas a diseñar una cocina (por seguir tu ejemplo) sabes que diseñas para una actividad pero muy probablemente no estés diseñando para ti sino para otro. Por eso te interesa saber más del contexto de uso y del usuario
No es lo mismo diseñar una cocina doméstica (amos/amas de casa, platos poco elaborados) que una cocina industrial (grandes perolos, pocas jerarquías) o la de un restaurante (muchos tipos de platos, personal muy especializado, ritmos muy rápidos). Te hará falta saber qué tipo de ollas, por dónde saldrán los platos, si trabajará más de una persona o no (para diseñar los espacios), etc, etc.
Tendrás que entender las tareas y diseñar para maximizar su eficiencia, pero tendrás que entender también el contexto de uso.
Y hablando de diseñar cocinas, muy recomendable «La Cocina para Cocinar» de Otl Aicher y «Kitchen Stories», película sueca de cuando en los 50 se hacía observación para mejorar las cocinas de los solteros.
Totalmente de acuerdo: Me parecen enfoques complementarios, sin duda. (¿He dicho que fueran contrapuestos? 🙂
Pero veo difícil que dentro de un proyecto te dé tiempo a abordar ambos enfoques. Para conocer en qué consiste la actividad la observación es más importante, mientras que para conocer al usuario tienes que dedicarle más recursos tipo cuestionarios/preguntas abiertas.
Lo que trato de poner en tela de juicio es que el enfoque «Escucha a tus usuarios. Ellos lo saben todo». Muchas veces los usuarios, aunque parezca mentira, no saben lo que quieren.
Por un momento me he quedado totalmente descentrado 🙂
¿Centrarse en la actividad abstrayéndose del usuario no es lo mismo que diseñar de espaldas al usuario?
Sé que no quieres decir eso, así que la verdad es que no entiendo el matiz. De hecho no entiendo donde haces la división. Cuando hablas de diseño centrado en la actividad te refieres a la observación, ¿te refieres a la observación de los usuarios realizando la actividad? Entonces estamos hablando de diseño centrado en el usuario ¿no? :-S Me leeré esos enlaces a ver si veo la luz 🙂
Por otro lado, estoy completamente de acuerdo con el planteamiento de Nielsen de que no escuchar a los usuarios, sí observarlos, estudiarlos. Como dices, los usuarios no tienen ni idea de lo que quieren. En ese sentido son como niños, te pueden pedir el juguete más sofisticado del mundo, que luego acaban jugando con la caja.
no parece mentira, es que muchas veces no saben lo que quieren y como uno se tome como guía sagrada y única lo que opinan… vamos apañados. Creo que Bernardo Hernández en un laboratorio de hace bastante de Cadius habló sobre el tema. Comentaba que en Google escuchaban a los usuarios en su justa medida.
Lo gracioso es que cuando les muestras a los usuarios una posible interfaz, o arquitectura que dé respuesta a sus necesidades entonces sí lo saben. Pienso que nuestra labor es la de hacer emerger las necesidades implícitas en usuarios y en la interfaz a rediseñar, y para ello, combinar ambas aproximaciones sería lo mejor. Ahora bien, aunque todos somos más papistas que el Papa, que me enseñen un proyecto en el que se aplique una metodología estricta de AI y DCU de la «a» a la «z» 🙂 coincido contigo Juan, ni tiempo, ni recursos, ni dinero suficiente suele ser lo más habitual en cualquier proyecto. Como para ponernos a hacer filigranas en nuestro día a día.
Por otro lado es algo que me llevo planteando mucho tiempo, hasta qué punto merece la pena acometer determinadas metodologías de diseño para los retornos que se obtienen. O lo que es lo mismo, dónde está el punto en el que Retorno a obtener no merece la pena la Inversión.
Buen post Juan.
Paco, Julio, gracias por vuestros comentarios.
Paco, con tanta escasez de tiempo asignado a los proyectos pensar en este tipo de cosas es un pasito que hay que dar. A ver si nos aplicamos el cuento 😀
Julio, das en clavo: La conclusión es diseñar «de espaldas al usuario» pero pensando en la actividad que desempeña. La frase puede incluso sonar transgresora, pero al fin y al cabo el objetivo es el mismo, no crees?
Gracias (: Me ha gustado he estado traduciendo el articulo completo de Don Norman… Esta pagina me ayudo a comprender mejor (: