Partituras de Interacción: Su utilización en un contexto de desarrollo ágil.
Las partituras de interacción surgieron como un lenguaje visual para modelar la interacción en proyectos digitales, buscando articular la relación entre el usuario, la interfaz gráfica y el sistema que responderá a las acciones ejecutadas por el usuario.[1]
Las partituras de interacción nos ayudan a modelar procesos donde interactúan personas y sistemas. Para eso cada partitura funciona bajo una estructura de tres capas u horizontes:
- Acciones del usuario: Intención u objetivo último del usuario que da inicio a cada flujo
- Contacto directo: Elementos concretos de la interfaz con los que el usuario interactúa para cumplir su objetivo
- Proceso: Funciones y comportamiento del sistema para responder al diálogo iniciado por el usuario
La idea de este post no es hablarles de las partituras en si, mas bien de tomar como caso de uso mi experiencia usándolas como una herramienta de desarrollo ágil en mi paso por agencias digitales, y particularmen te en Digitaria.
Contexto ágil
Durante el 2012 yo me encontraba trabajando como Diseñador UX en Digitaria y tuve la suerte de que Sofía Savoy — actualmente en IDA y que también tuvo la suerte de ser alumna de título con Herbert Spencer — ingresara a la agencia y trajera consigo las partituras de interacción bajo el brazo. Con su llegada pudimos tener otra persona con la cual poder compartir visiones sobre UX y convencer al resto de los diseñadores (y el resto de la agencia) de que convenía adoptar metodologías disruptivas como ésta.
En un contexto dónde las campañas de marketing digital se tienen que desarrollar en tiempo acotados, y esas campañas de marketing son acciones relativamente estandarizadas, sobre todo cuando se pensaba en mecánicas con acciones en redes sociales se nos hacía urgente saltar ciertos procesos del desarrollo — waterfall de UX — y agilizar el proceso en busca de acortar las brechas de tiempos entre la creación de una campaña y el desarrollo de la misma.
El Proceso
El proceso partía con una reunión creativa dónde se decidía la mecánica a desarrollar, el encargado UX que tenía relación con la marca/cliente al cual se le está entregando el producto entonces debía ser lo mas ágil posible para implementar un flujo de interacción que permitiera al equipo de desarrollo conocer la mecánica e impacto que tendría en tiempos para la agencia y el cliente. En esa época contábamos con equipos creativos de trabajo en el cuál existía una persona con cualidades de UX (sin llamarse necesariamente diseñador UX) y que era el encargado de ser el puente entre el concepto creativo y el desarrollo (Natalia, Sebastián, Alfonso, Pato) [2].
En resumen el proceso se conformaba de la siguiente manera:
- Concepto creativo campaña.
- Partitura de Interacción.
- Revisión del flujo con desarrollo.
- Iteración de los cambios a la partitura de interacción.
- Diseño campaña.
- Implementación.
Como ven los pasos 2,3 y 4 eran fundamentales para poder iterar de manera acotada y rápida la mecánica de la campaña junto al nivel de desarrollo que esta podía involucrar.
Partituras a la medida
Al empezar a trabajar y por necesidad del trabajo diario, descubrimos que el flujo de interacción era eficiente desarrollarlo con una versión “light” de las partituras. Como saben las partituras tienen un lenguaje visual específico que permite desarrollar en un canvas un flujo de interacción, esto para nosotros suponía un tiempo involucrado para crear una partitura “pulcra” que no teníamos, por lo que muchas veces dibujábamos en un papel la partitura la validábamos con desarrollo y luego llevábamos al “limpio” esos cambios para afinar y agilizar el proceso.
En este proceso hicimos unas pequeñas variaciones a las capas de las partituras, de partida dejando el contacto directo sobre las acciones de usuario, como una manera de identificar directamente en la zona superior las pantallas que deberían de diseñarse para la campaña. En ocasiones esta capa era reemplazada directamente por la capa de la plataforma en la cual estaba inserto el desarrollo, por ejemplo en facebook.
Quedando de esta forma:
- Interfaz: Elementos concretos de la interfaz con los que el usuario interactúa para cumplir su objetivo. En ocasiones se reemplaza directamente por la capa de la plataforma en la cual se hace el desarrollo.
- Usuario (acciones): Intención u objetivo último del usuario que da inicio a cada flujo.
- Sistema: Funciones y comportamiento del sistema para responder al diálogo iniciado por el usuario.
Sin dudas fue un tiempo en el cual la partitura como herramienta nos permitió reaccionar a las necesidades del mercado de una manera ágil pudiendo también insertar una metodología nueva (c.2008) y testearla in situ en una organización que desarrolla soluciones digitales de marketing.
Actualmente trabajo en otro lugar (Chilexpress) pero siempre recuerdo con cariño ese momento en que pudimos implementar las partituras de interacción en un escenario real de demanda diaria.
Partituras de Interacción como Software
Durante el 2014 se produjeron una serie de modificaciones y actualizaciones en las partituras de interacción, en donde fue importante el proceso de conversatorios acerca de la herramienta, en la cual Kathe y Herbert invitaron a personas involucrados al uso de las mismas a discutir sobre su uso y posible mejoras de cara al futuro. Luego de esas reuniones las partituras volvieron ahora llamadas PiX trayendo consigo también una nueva familia iconográfica (pixograms)[3].
Si quieres saber mas de ellas y su versión online con su nuevo lenguaje visual puedes revisar: http://eadpucv.github.io/pix/
Referencias
[1]Partituras de interacción: articulando armoniosamente la interacción en servicios digitales — http://www.ida.cl/blog/diseno/partituras-interaccion-armonia-plataformas-digitales/
[2] Nota: Natalia, Sebastián, Alfons
[3]PiX: Partituras de Interacción como lenguaje y software — http://www.ida.cl/blog/diseno/pix-partituras-de-interaccion-como-lenguaje-y-software/
