Sobre diseño, tareas y outcomes
Diferencias entre lo que diseñas y los entregables.
ed. 09/52
Hace unas semanas estuve pensando sobre mi proceso y sus alcances, al trabajar en un equipo de sistemas de diseño uno de los entregables es la documentación del componente diseñado.
Pero hace poco me detuve a reflexionar sobre ¿Cuál es el objetivo de mi proceso de diseño? ¿Un entregable como un documento?. Mis primeras ideas apuntaban a que este entregable funge como link que permite a la siguiente fase trabajar (desarrollo). El objeto diseñado es este documento. Pero, paso más tiempo pensando en la solución que documentándola, la documentación son solo instrucciones de mi solución, mi solución es la parte interesante; sin embargo, ¿Son lo mismo? O son cosas diferentes…
Entonces, como revelación, surgió la siguiente idea, mientras estaba en la regadera. En ese momento donde no piensas en nada, pero puedes pensar en todo…
Imagina que soy un diseñador, tengo un taller y he diseñado una silla, hagan de cuenta las Herman Miller pero en versión custom y más barata, con un toque de DIY para que los clientes la armen en su casa.
He pasado meses en fase de entendimiento, donde entiendo los problemas de las sillas actuales, he hablado con usuarios y entiendo las áreas de oportunidad que hay en el mercado. Además, tengo claro que la silla debe de ser cómoda, de un precio y manufactura relativamente accesibles (no somos para todos, pero tampoco para unos cuantos). Pero eso sí; lo mejor en cuanto a diseño y los materiales. Ahora llevo meses en ideación, validando ideas, entendiendo cuáles son más factibles de hacerse sin perder de vista las limitaciones y requerimientos que señalé con anterioridad.
¡Listo! Después de varias pruebas di con el diseño que necesito, y me gusta. Así que haré una producción inicial. Uno de los objetivos es permitir que los usuarios puedan armarla en su propia casa. Por ello, hay que incluir un instructivo sobre como hacerlo, la silla está diseñada para ser armada de forma sencilla por el propio cliente/usuario, así que necesito un instructivo, un papel impreso, incluso un PDF que le dirá al usuario como debe de armar su silla y le permita hacer uso de ella. Ese instructivo posibilita la tangibilidad de la silla, puesto que sin él, la silla no es más que una caja con piezas desarmadas.
Entonces ¿Qué es el instructivo? La silla es lo que permite al usuario sentarse, pero el instructivo es el link que permite al usuario armar la silla (implementar el diseño de cierta forma) y usarla, ¿Les suena familiar a la documentación que mencionaba al inicio?
Una "tarea" no es lo mismo que lo que "diseñas"
En mi analogía es fácil entender como se separa lo diseñado (la silla) y lo que es una tarea (el instructivo), en este caso, una tarea ayuda a que lo diseñado cumpla su función y objetivo. No hice un proceso de diseño para crear documentación, o para hacer un instructivo de como armar la silla. Hice un proceso de diseño para entender el problema a resolver: Un usuario necesita sentarse muchas horas y quiere una silla cómoda, que no sea de un precio elevado, y esto permita vender más sillas de manera masiva.
Entendiendo el problema, podemos buscar una solución, lo diseñado (para esto es mi proceso de diseño también). Esta solución solo es el medio, en lugar de una silla, piensa en una app, en una web, o en un servicio. Todo lo anterior se diseñó para lograr un objetivo, como que el usuario compre algo, que regrese por más, que use más tu servicio etc., esto es un Outcome
Outcome
Por ello es importante entender los diferentes niveles: las tareas nos ayudan a lo que vamos a diseñar, un wireframe no será parte de la app, ni un journey, esas son tareas que nos ayudarán a tomar decisiones, son link entre micro procesos, y esas decisiones se verán reflejadas en nuestro diseño, es decir: lo diseñado. Pero lo peor que puedes hacer es diseñar sin entender el otro nivel el Outcome.
NO es hacer la app, web o servicio más fancy, intuitivo, que toma en cuenta al usuario, que hará traer ROI a la empresa, no, no se trata de que eso. Se trata de que la app, web, servicio o... la silla permitan hacer algo al usuario/cliente/etc. y por consecuencia sea intuitiva, fácil de usar y memorable. (Cachan la diferencia).
Recapitulando
Tarea: aquello que nos permite realizar "lo diseñado", en mi analogía es “el instructivo”.
Lo diseñado: lo que resuelve un problema, la solución, en este caso “la silla”.
Outcome: el fin último que queremos lograr o impactar en los usuarios, en este caso es “que pueda sentarse de forma cómoda por muchas horas”.
Nunca debemos olvidar el Outcome que queremos lograr, esto hará que podamos tomar decisiones sobre el tiempo y el esfuerzo que sin querer a veces le ponemos a una tarea y que no lo ponemos en lo diseñado. La tarea ayuda, es necesaria, pero no te dediques tiempo de más, porque solo es un paso, lo que nos ayudará a conseguir el Outcome es lo diseñado, dedícale mucho tiempo a lo segundo sin perder de vista lo primero
El trabajo diario y el ver las cosas de forma fragmentada (somos parte de un equipo en muchos casos) nos hace enfocarnos demasiado en el detalle del proceso, siempre es bueno hacer zoom out para ver la foto completa y no olvidar el Outcome por el que estamos haciendo las cosas.
Disclaimer.
Más allá de Outcome que lo retomo de Joshua Seiden y su libro Outcomes over Ouptus, lo diseñado y tarea son conceptos que uso para lo que quiero explicar, no dudo que alguien más ya lo haya llamado de otra manera, si tienen referencias al respecto háganmelo saber.
Para Leer o ver 👀
Managers make organizations, not products
Publique hace unas semanas en LinkedIn este brillante post de Tanner Christensen que habla sobre la diferencia en impacto de un Mananger y Un Individual contributor con influencia. El primero impacta en el equipo y el segundo en el producto.
Para Escuchar… y un poco más 🎧
Max Cooper - Live at the Acropolis
imperdible concierto, hasta para dejarlo de fondo mientras trabajas