Acabo de superar mi enésima conversación sobre cómo encajar UX en un modelo de trabajo ágil, así, resumidamente, que si… ¿Design-Driven o Agile-Driven? (entendiendo Design en el contexto relacionado con UX, que, por el tipo de lector del blog, aviso, aquí la palabra Diseño está en el contexto más UX). Quizá, seguramente, sería aconsejable, más que que si uno u otro… que intentemos descubrir cómo pueden trabajar los dos juntos, pero bueno.
Probablemente, los puntos de más debate aquí están en, por un lado, cuándo trabaja UX, ¿antes de la creación del producto?, ¿o más cercano a la creación?, ¿más en paralelo?, o que si mucho antes, o que si poco antes. Y otro debate potente es si alguien de UX… es parte del equipo ágil o no.
En lo que refiere a cuándo, un modelo de trabajo ágil no promueve mucho investigaciones largas previas a la creación de proptotipos potencialmente entregables (en tecnología esto es terminar en pre o producción). Esto no sólo se mira con cuidado en lo que referiría a una gran fase previa de UX, sino que también ocurre con grandes Inceptions, con los criticados Sprint 0 y similares, que huelen a predictibilidad (que ya suena al temido cascada).
En agilidad la recomendación es más el “continuous discovery”, más que “descubrimiento inicial”, aquello del aprendizaje a través de la experimentación continua (el enfoque pragmático), no olvidemos que mucho de este pensamiento viene de las malas experiencias que trajo el modelo en cascada y sus grandes fases previas a la creación, que, en demasiadas ocasiones, venían cargadas de desperdicio, de especificaciones que luego no tenían sentido, o que nadie quería o que cuando estaban listas ya era demasiado tarde, después de “tanto papel”.
El diseño, el UX, el más clásico, por el contrario, tiene su preferencia por la investigación previa, estableciendo una comprensión básica de usuarios, del mercado objetivo, de la estrategia del producto, etc.
Y en este punto vas a tener que decidir tú dónde está el equilibrio, la solución más óptima, porque nadie te puede dar una regla inamovible. Fases previas muy grandes (de UX u otros) tienen peligro, ya lo vivimos (esto ya lo he vivido), ya lo advierte la agilidad, aunque nadie puede decir que no debe haber nada de trabajo previo… el Lado Oscuro puede estar cerca.
Yo te recomiendo minimizar el trabajo previo al producto potencialmente entregable, salvo que sea imprescindible o corres el riesgo de generar desperdicios, trabajos que no aportarán valor alguno. Piénsalo tú mismo, no te dejes engañar por el Maligno, piensa si realmente tienes que esperar tanto para tener un MVP.
Quizá el enfoque que más promueve lo de integrar el Diseño en el ciclo de vida ágil sea el Lean UX, un enfoque de Diseño es más Ágil, más Lean Startup (que también es muy Ágil).
La idea de un Diseño más Ágil es centrarse en verificar las hipótesis rápidamente, más que en entregar papel, perseguir el Producto Mínimo Viable (MVP).
Un enfoque más Lean UX va a llevar a un trabajo más colaborativo entre todos los perfiles necesarios para obtener ese MVP.
Lo dicho, esto es más complicado que tirar de una definición universal sobre qué es lo correcto, pero, no te dejes llevar por el Lado Oscuro.
Un antiguo post que puede completar a este: ¿Cuándo se hace el diseño de interfaces (UI) y el UX en Scrum?
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- OKRs sin Lado Oscuro, IA para OKRs y alternativas para evaluarlos - 25 julio, 2024
- Por qué seguimos usando técnicas ágiles anticuadas: Efecto Einstellung - 18 julio, 2024
- Cómo crear una IA personalizada (me llevó meses, pero te lo enseño en 2 min) - 11 julio, 2024
Hola Javier,
Sólo te escribo para una sugerencia. ¿No has planteado cambiar el estilo de la web? sobre todo en lo que respecta al fondo y tipo de fuente de los posts ya que creo que su legibilidad es alta (es inversamente proporcional a la calidad de su contenido.)
Gracias
Sí, lo he pensado, pero necesito tiempo, a ver si saco un rato. Gracias
Javier, muy interesante tu post. Coincido contigo que integrar UX por ejemplo con Scrum como marco de trabajo es un reto que lleva a experimentar de a pocos para entregar valor. Lo que me gustó mucho de usar un Lean Ux Canvas para trabajar con hipótesis es increible y como técnica para obtener los PBIs del Backlog, un abrazo, Carlos