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)
