Una de las disciplinas más valoradas es UX (User experience o experiencia de usuario). Su función es proponer soluciones para que los usuarios tengan una experiencia tan buena que el producto garantice su valor. Sin embargo, hay gran controversia por la estrategia habitual de un UX que nos recuerda a un waterfall. ¿Ayuda UX o molesta?
UX como disciplina de moda
Hoy en día el rol del UX es clave en muchas empresas. Necesitamos convencer a un cliente de que nos contraté y un buen trabajo de UX puede ser una carta de presentación interesante.
Además de eso, en las primeras semanas o meses de trabajo, luce mucho estudiar el resultado final con un UX. De esta manera, el cliente se involucra y aprecia el trabajo que se está desarrollando.
Parte del éxito es la visualización. Las pantallas y cómo teóricamente se interrelacionan ayudan mucho a un cliente a entender el futuro de su producto. Esta estrategia ganadora de tener conversaciones iniciales con un cliente en base a pantallas visuales es bastante habitual en los equipos.
Sin embargo, por más que esta estrategia se usa, seguimos teniendo problemas similares en los equipos que desarrollan productos: problemas de tiempos, dificultades técnicas, errores o bugs, mal servicio, costes altos en mantenimiento y, lo peor de todo, productos qué aportan poco o nulo valor. ¿Para qué sirve entonces un UX?
El UX como nuevo waterfall
El problema de las disciplina UX es que se está convirtiendo en el antiguo waterfall pero disfrazado con post-its y con nuevas técnicas y dinámicas de trabajo. Durante muchos meses ideamos que producto queremos para después desarrollarlo durante un periodo de tiempo largo y finalmente estudiar el resultado.
Con esta estrategia mejoramos respecto al tradicional Waterfall porque trabajamos sobre pantallas visuales pero sigue adoleciendo del mismo problema de base: ¡el valor tarda mucho en llegar!
Sólo cuando se produce la entrega es cuando podemos validar que realmente hemos acertado. Se garantiza que un producto da valor cuando realmente se está utilizando. ¡Da igual las horas que el UX haya invertido con el cliente!
Resolviendo problemas complejos
Cuando hablamos de software hablamos de resolver problemas complejos. El objetivo del desarrollo software nunca es cumplir una fecha o desarrollar un determinado producto sino resolver problemas complejas por las que un cliente nos paga.
Esto ya supone un cambio de paradigma, porque tenemos que comenzar definiendo muy bien el problema que queremos resolver. Después, lo resolveremos a base de inspección y adaptación validando cada poco tiempo los resultados. Los problemas complejos no se pueden resolver planificando ya que hay demasiadas variables que se escapan a nuestro control. ¡Por eso son complejos!
La disciplina UX sigue tratando de resolver el problema a base de mucha planificación (en forma de pantallas o de experiencia). A pesar de que la disciplina UX se centra en el usuario y sus necesidades, adolece del hecho de que la mejor manera de conocer al usuario es entregarle valor y tantearle continuamente. Las necesidades que un cliente te transmite hoy cambiarán mañana.
Dual tracking
Una de las técnicas habituales usadas para incorporar UX con tecnología es el archiconocido Dual Tracking. Está práctica consiste en dividir el trabajo entre diseño y desarrollo siendo el primero realizado 1 o 2 Sprints por delante. La idea es hacer “Sprints paralelos” donde el diseño se adelanta al desarrollo.
A priori, tiene sentido, nos permite diseñar una solución que se implantará después. Podemos pensar que maximizamos el trabajo de ambas disciplinas. Sin embargo, hay varias trampas en este planteamiento. Por un lado, alejamos al desarrollo del usuario, algo muy alejado del concepto de historia se usuario que precisamente busca la colaboración de ambos para el éxito.
Otro problema es que reducimos el compromiso de las personas al convertirse en «meros implementadores». Realmente un buen desarrollo es aquel que se involucra de lleno en resolver problemas. Y por último, es más difícil el sentimiento de equipo y de pertenencia. ¡Hemos creado un waterfall en Sprints!
Sí a la disciplina, no a los especialistas dedicados
UX al igual que otras disciplinas como QA, DevOps o Analistas, son muy necesarias en cualquier equipo de software que quiera conseguir entregar valor. Lo que no debemos hacer es dejar que esta disciplina domine al resto y que trabaje por adelantado. Tenemos que tener equipos unidos orientados a valor donde cada uno de sus miembros aporte sus habilidades al bien común.
No pongo en duda la importancia de un buen UX ya que es una tarea indispensable que pone de relieve la importancia de que el usuario consiga una buena experiencia utilizando en su producto.
Pero soy bastante crítico con aislar a estas personas y darle la responsabilidad de definir la solución en vez de trabajar codo con codo con el resto del equipo. Las soluciones tienen que ser construidas desde el equipo y no desde una parte del mismo.
Y sí, podemos desarrollar la labor de UX dentro de un sprint a la vez que hacemos el código. Si todos nos centramos en resolver el problema, conseguiremos mejores soluciones sumando nuestras capacidades.
Y tú ¿qué opinas del UX?
Hola Javier,
he leido tu artículo y tiene ideas interesantes, como el beneficio de realizar un UX continuo (el dual track), en línea con lo que llaman en “producto” el “continuous product discovery”.
Pero no estoy de acuerdo con estereotipar al UX (ni en su disciplina ni en su rol) como promotor del “waterfall”.
Como resumen de mis objeciones, hay que distinguir entre las actividades de UX y UI. El diagrama “Elements of User Experience” de JJ Garrett (año 2000) aparecen las 5 capas de UX/UI. En la base las actividades de estrategia e investigación (qué problemas del usuario hay que resolver y cuales no, y cuales son las posibles soluciones a investigar), y en la cúspide el aspecto visual.
Después de hablar con bastantes diseñadores “estratégicos” como parte del curso Professional Scrum with UX (PSU) que he dado con Jeff Gothelf, aprendí que las actividades de entender los problemas a resolver y las posibles soluciones sí tiene sentido habitualmente hacerlas antes de un desarrollo (el waterfall no es siempre maligno) y las más tácticas (diseño, testeo, desarrollo y validación) hacerlas en dual-track.
Elements of UX: https://image.isu.pub/090215155403-6cd297eb80d5444c931eae8cda2c8740/jpg/page_1.jpg
Por lo demás, el artículo me gusta. El papel de la actividad y rol UX/UI dentro del equipo, con un backlog común de problemas a resolver, es lo que Jeff Gothelf y Josh Seiden defendían en su libro Lean UX (2013) y lo que enseñamos en el curso PSU (2018).
‘Saludos!
Gracias a ambos por vuestra reflexión. Muy interesante.
Después de leer el artículo, me parece que tiene una mirada muy cerrada. Armar un producto sin entender bien los problemas o enfocarse solo en lo que pide el cliente puede no funcionar. El desarrollo de un producto sin una comprensión clara de los problemas reales del usuario o al centrarse exclusivamente en los requerimientos de un cliente sesgado puede ser contraproducente. La inclusión del diseño de experiencia de usuario (UX) es esencial para abordar estas deficiencias y asegurar que el producto resuelva efectivamente las necesidades del usuario final.
Priorizar la velocidad sobre la técnica puede dar resultados flojos y poco satisfactorios. Es mejor hacer pocos experimentos de calidad que muchos con resultados poco claros.
Me atrevería a decir que el Agile está en declive, hasta las startups lo ven como poco aplicable ya que son entornos altamente cambiantes y muy rapidos que requieren buenos resultados, y aplicar un metodo que no asegura buenos resultados no es para nada efectivo y por fundamentalistas del Agile en un contexto actual que requiere más tomar decisiones async y rapidas, es por lo que muchas startups ya se fundieron, diria que el Agile es lo que está pasando de «moda» sobre todo despues del COVID, seguir una secuencia de pasos sacados de un libro, es más que inviable.