Análisis orientado a la tarea

Este post forma parte de una serie que actualicé y consolidé. Recomiendo leer el ensayo completo.

«If I’d asked people what they wanted, they would have asked for a better horse»

– Henry Ford

Una de las cosas que uno hace cuando participa en una empresa es preparar ofertas para clientes. En ocasiones, la tarea es sencilla porque el dominio o el problema es muy acotado o ya has hecho cosas similares anteriormente. En otras, sin embargo, es necesario aterrizar una marabunta de ideas inconexas, deseos más allá de la realidad o que el usuario no sabe lo que quiere (simplemente necesita resolver un problema).

De un problema a una solución

Hace años, participé en un proyecto donde el cliente tenía un problema: para compartir información de un proceso de la empresa, los usuarios participantes tenían en su ordenador una jerarquía de carpetas propia, con distintos documentos cada uno que ligaban mediante un código compartido (que tenía, sin embargo, matices para cada usuario). Cuando necesitaban alguna información concreta, se enviaban e-mails entre ellos para preguntar quién tenía un documento específico.
Esto era un horror además de poco efectivo. Nos pidieron opinión para diseñar un sistema centralizado para compartir información: la idea inicial era construir un FTP que enviase mails automáticamente cuando alguien añadía un documento a una u otra carpeta, según una jerarquía que estaba siendo definida. Luego de algunas vueltas y no pocas conversaciones llegamos a algo diferente a lo que pedían inicialmente. ¿Por qué no crear un sistema de gestión de expedientes que se integre con otras herramientas que ya tenéis? No un FTP más organizado o e-mails automáticos. No un caballo más rápido, sino un coche.
La diferencia puede parecer sutil, pero conceptualmente es un salto importantísimo: las conversaciones con el cliente pasaron de pivotar sobre los nombres de las carpetas que debería tener el FTP centralizado a centrarse en cómo hacían las cosas, los fundamentos de sus procesos internos. En este caso, el resultado fue que no hicimos nada de lo que inicialmente se había pensado (FTP centralizado, envío de mails, etc) y, sin embargo, el proyecto es ahora fundamental en su día a día.

Análisis orientado a tarea

job

¿Qué es lo que nos llevó a determinar que existía una mejor solución? Creo que simplemente poner la mirada en cómo trabajaban y escuchar, no sólo dejar que el sonido entrase en las orejas. A partir de ahí, pensar un proceso para compartir información sobre la base de cómo hacían ellos las tareas y orientar la construcción de herramientas al soporte de ese proceso.
En ese momento no fuimos conscientes de que estábamos haciendo análisis orientado a la tarea. Supongo que llegamos a esa idea simplemente por ponerlos en la piel de los usuarios, por dedicarle un poco de cariño al proyecto. Desde luego no conocíamos «Understanding the job» de Christensen:

Ni todavía habíamos llegado a Ryan Singer y sus interfaces orientadas a la tarea, aunque poco después empezamos a escuchar lo que estaba diciendo este chico:

El análisis de la tarea en diseño de interacción

IxDesign_Matrix

A lo largo de mi carrera, creo que esta técnica ha sido uno de los aprendizajes que más impacto ha tenido en cómo enfoco mi trabajo y en las soluciones que propongo.
Es en este marco en que el estudio de las ideas de Bill Verplank cobran muchísima relevancia. Se me hace ahora más claro cómo encaja el análisis orientado a la tarea en el marco general y las distintas fases del proceso creativo, los outputs que debemos esperar de cada una de ellas.

Su librito sobre diseño de interacción ha resultado fabuloso como integrador de muchos conceptos que tenía sueltos. Entre otras cosas, me ha permitido clarificar también dónde encaja la metáfora de mapa VS ruta, que es un buen heurístico para ayudarte a pensar cómo el usuario va a interactuar con el producto.
La verdad es que sienta muy bien dedicar un tiempo a reflexionar sobre lo que uno hace y pararse a estudiar cómo lo hacen otros. Ayuda a clarificar ideas y eliminar lo superficial. Es como dedicar un tiempo a afilar el hacha antes de empezar a cortar árboles. Eres más productivo con un hacha afilada y te cuesta menos esfuerzo. Supongo que es también ahora, cuando uno pasa a ser consciente de cómo hace las cosas, en que empieza lo divertido. ¡Abróchense los cinturones!


Comments

7 responses to “Análisis orientado a la tarea”

  1. Gracias por este artículo con tantas referencias interesantes. Me interesa mucho la interacción humano máquina porque creo que es una manera inmejorable de introducir a los arquitectos y diseñadores tradicionales en todas las metodologías y maravillosos avances en metodologías de diseño que se han conseguido con el software. Yo hice un cursito online que no estuvo mal, pero estas referencias parecen muchos más serias. ¿Cuál estás haciendo tú?

  2. Estoy con la especialización de coursera, que bebe principalmente de la estructura de contenidos que Scott Klemler daba en Stanford; es decir, no es un experimento, está testeada con usuarios y tiene cierta lógica. Los contenidos me parecen muy bien organizados y con referencias útiles.
    Me gustaría un poco más de revisión histórica; tengo pendiente agenciarme algo que me oriente. De momento, exploro por mi cuenta las referencias que voy encontrando y me paro bastante a ver cosas paralelas (por ej: el linaje del diseño de interacción en estados unidos a partir de pioneros como Engelbart, Alan Kay o Bill Verplank, etc).

    1. Ei, el curso online que hice es precisamente el de Klemer en Stanford, al principio de Coursera. He visto que ahora lo han ampliado pero veo que eres tú el que encuentra estas joyas y les da sentido 🙂
      Es una idea genial ir escribiendo posts conforme avanzas para fijar aprendizaje, te tomaré como ejemplo 😉

  3. […] para lo que es necesario conocer el dominio en el que trabajas: ¿qué datos se recogen? ¿qué tareas necesitan resolver con esos datos? ¿cuáles son los roles de la gente que participa? El objetivo […]

  4. […] The dangerous “UI team”, de Havoc Pennington. Nos recuerda que, para hacer productos, necesitamos equipos que resuelvan problemas. […]

  5. […] decir, trabajaron con conceptos como análisis orientado a la tarea, design personas, prototipos como herramienta de selección de conceptos, […]

Leave a Reply

Your email address will not be published. Required fields are marked *

%d