Agile y Diseño: ¿son incompatibles?
Agile y Diseño tienen orígenes y enfoques muy diferentes. Las prácticas ágiles minimizan el diseño previo y su velocidad de iteración deja poco tiempo para la investigación de clientes y la experimentación de nuevos modelos de interacción con el producto. Pero la necesaria confluencia entre ambos está imponiendo nuevas condiciones a los profesionales de uno y otro lado.
(IMPORTANTE: cuando en este post hablamos de Diseño nos referimos al diseño de experiencias de usuario o UX, no al diseño técnico.)
A primera vista, Agile y Diseño tienen muchos aspectos en común: aplicados al desarrollo de productos ambos ponen su foco en el usuario y aplican un proceso iterativo de refinamiento del producto guiado por el feedback del mercado, que se captura mediante artefactos “provisionales” (mockups, prototipos, versiones preliminares y limitadas del producto…). Los dos enfoques comparten el objetivo último de proporcionar productos dotados de significado y que aporten valor para sus clientes.
Agile y Diseño son fundamentalmente diferentes
Pero esas similitudes no nos deben impedir ver las diferencias –en algunos puntos antagónicas– entre ambos enfoques. Especialmente en el desarrollo de productos para un mercado (no de proyectos a medida para un cliente) estamos hablando de filosofías, ámbitos de aplicación y resultados muy diferentes:
- El diseño de experiencias de usuario consiste en realizar investigación de clientes y en conceptualizar o representar el comportamiento del producto que se va a construir. Y el diseño de experiencias no es algo que se pueda hacer completamente por piezas: hay que considerar la experiencia de usuario holísticamente (si no en profundidad al menos sí en sus líneas generales y su filosofía). Por eso sus partidarios defienden que, análogamente a los planos de un edificio, el diseño de un producto debe realizarse antes de empezar a construirlo.
- Agile es principalmente implementación (es decir, entrega de versiones funcionales del producto) y generalmente entra en acción cuando hemos decidido que vamos a construir la “unidad 0” de algo. Agile hace énfasis en la entrega rápida e iterativa de productos operativos, lo que en el caso de algunos enfoques anticuados o extremos se consigue a costa de prescindir de una planificación y diseño elaborados.
No olvidemos que Agile proviene del mundo del desarrollo de proyectos a medida (y no tanto en desarrollo de productos replicables), un escenario donde tradicionalmente no se ha concedido una gran importancia a la experiencia de usuario. Cuando el objetivo prioritario es proporcionar una serie de features, la experiencia de usuario suele ser un “subproducto” no muy logrado. Por el contrario, en productos para un mercado la experiencia del usuario es primordial y el Diseño nació para esos escenarios.
A principios de la pasada década, cuando Agile y Diseño empezaron a pasar al primer plano, las diferencias entre ambos eran más patentes. En un debate clásico que tuvo lugar en 2002, Alan Cooper (pionero del diseño de interacción) y Kent Beck (creador de XP) no sólo fueron incapaces de ponerse de acuerdo, sino que ninguno de los dos parecía entender al otro. Reconozcamos que era la “prehistoria” y que desde entonces ambos metodologías han evolucionado, pero la conversación nos da idea de sus diferencias en origen.
Para reducir el riesgo y mejorar la calidad del producto, en Agile una release se divide en varias iteraciones, en cada una de las cuales se implementa un conjunto de “historias de usuario” (u otro artefacto para especificar funcionalidad). Este foco en las features nos puede hacer olvidar que la experiencia del usuario no se puede diseñar por partes: debe tener sentido para ese usuario en cada release. Si en Agile renunciamos a modelar con antelación lo que se va a implementar podemos acabar con un producto fiable y bien construido pero que carezca de un significado, una integridad y una interacción coherente. Y es que algunas cosas a las que se deja que “emerjan” terminan resultando criaturas muy feas.
Condenados a entenderse
Tal vez el principal beneficio del diseño de UX es la capacidad para imaginar y representar cómo un conjunto desordenado de funciones y significados se puede sintetizar armoniosamente. Por desgracia, algunas prácticas ágiles extremas relegan su papel al de esfuerzos a corto plazo para diseñar y rediseñar elementos pequeños y aislados. Y aunque en este campo Agile puede mejorar la usabilidad del producto, los resultados tienen a menudo un carácter incremental.
La velocidad de ciclo y la cadencia que impone Agile ha sido uno de los aspectos más difíciles de reconciliar con el Diseño. ¿Con unos ciclos tan cortos tenemos realmente tiempo para entender completamente las necesidades de nuestros usuarios? La respuesta corta es “no”. Pero la respuesta correcta es que si estamos descubriendo las necesidades de los usuarios durante la implementación estamos haciendo algo rematadamente mal. La urgencia por alimentar los ciclos de Agile y por dedicarnos a los “árboles” de la actual iteración nos puede impedir ver el “bosque” de la experiencia holística de usuario y descubrir nuevos y rompedores modelos de interacción que diferencien a nuestro producto de sus rivales.
Además, la falta de un diseño inicial validado con los usuarios puede llevar en fase de construcción a un rediseño o un refactoring excesivo que incremente los costes y retrase la salida al mercado; algo que, paradójicamente, impide alcanzar los objetivos de Agile. Hay que buscar un equilibrio: combinando un esfuerzo inicial con pasos pequeños y constantes que avanzan hacia un producto coherente, el Diseño tiene que abrirse paso. De lo contrario Agile se acaba convirtiendo en una serie de experimentos de diseño de muy alta fidelidad y coste.
Como no podía ser de otra forma, en los últimos años hemos asistido a un acercamiento entre UX y Agile, con prácticas de uno que pasan al otro (y, curiosamente, con primeras figuras de cada una de las corrientes participando en los eventos de la otra). Las prácticas del nuevo Agile Product Management recogen el uso de mockups y prototipos para generar lo que se conoce como “visión” del producto, y que recoge los resultados del análisis de la oportunidad de mercado y de la definición y especificación general del producto. Esta visión se traduce en “épicas” y “temas”, que son los artefactos con los que Agile especifica la funcionalidad a alto nivel. Aún así, queda mucho camino por recorrer en cuanto a la integración del Diseño en Agile.
La adopción de Agile está obligando a cambiar la forma de trabajar de los diseñadores, pero la combinación de Agile y UX abre nuevas oportunidades tanto para los profesionales como de proporcionar mejores productos a los clientes. Y al diseño ágil de experiencias de usuario (lo que se conoce como Agile UX) dedicaremos un próximo post.
Este post en “Marketing & Innovación”.
[El diseño de producto es mucho más que un barniz estético a posteriori y especialmente en áreas como la experiencia de usuario constituye un gran eje de diferenciación. Descubre en este documento el papel del diseño en el desarrollo de productos.]
5 Respuestas a “Agile y Diseño: ¿son incompatibles?”
[…] se trata a menudo de una mejora incremental. Las metodologías ágiles se están extendiendo para conjugar un diseño holístico con una implementación incremental, hasta el punto de que el “Agile UX” es uno de los temas de actividad en la comunidad (al que […]
[…] Antes de la construcción del producto: descubrimiento de problemas de mercado, análisis y cuantificación de la oportunidad de mercado, definición de segmentos (necesidades, personas, escenarios) e identificación de los más interesantes, elaboración de concepto, visión y roadmap del producto, diseños iniciales. […]
[…] urgencia por implementar y validar tiende a minimizar las actividades de definición y diseño. Y conjugar un diseño holístico con una implementación incremental puede resultar muy complicado. Por otra parte, la iteración y la validación con los clientes debe […]
[…] Como hemos visto por aquí, todas estas filosofías tienen muchos puntos en común -aunque también algunas contradicciones, que se van superando paulatinamente. Pero lo más importante es que en conjunto renuevan y aportan […]
Nosotros para solventar esa cuestión integramos dentro de nuestra metodología Scrum y en la pila de operaciones/tareas una que hace referencia al diseño de la experiencia de usuario y que se ejecuta de manera iterativa en cada sprint.
Finalmente introducimos en la pila de producto uno o varios elementos que hacen referencia al diseño de UX.
Al final, de todos modos, es el product owner el que decide el orden en el que se ejecuta cada elemento de la pila de producto y que tareas son las necesarias.
Si alguien conoce otra forma, se agradecería 🙂