Una de las disciplinas que están en auge en los últimos años es la de User eXperience (UX). Esto se ha traducido en que muchas empresas hayan querido crear productos que fueran lo más útiles posibles a sus clientes o potenciales usuarios y, de ello, versa el UX. Scrum también busca ser efectivos, acertar con el producto correcto, por tanto, ¿cómo podemos combinar ambos? Analizamos diferentes aspectos de Scrum y UX.
¿Qué es UX?
Hace unos años, creamos una especie de red social entre unos amigos. La idea era crear un portal de comparación de productos, de muchas marcas, en el que encontrar opiniones y asesoramiento. Durante el desarrollo, teníamos que hacer la parte visual y no contábamos con ningún diseñador ni UX. Por tanto, teníamos que hacerlo nosotros. Un amigo decidió hacerlo él y se esforzó muchísimo. Cuando la parte visual se resolvió, me dijo “para haberlo hecho yo, no está mal”. Sin embargo, eso al mercado le tiene sin cuidado, nos da igual quién haga las cosas, quieren que funcionen bien.
Seguramente, haya una definición más formal y con matices, sin embargo, para entender cómo funcionan Scrum y UX nos puede valer con la siguiente: Podemos ver el UX como una evolución de lo que, originalmente, era diseño de aplicaciones a nivel visual o del UI (User Interface). No se trata de que tengamos “pantallas bonitas”, sino de que pensemos en la propia experiencia que el usuario recibirá. ¿Qué sentirá al entrar en la aplicación? ¿Se desesperará y la desinstalará o participará y convencerá a sus amigos para que se suscriban?
Por tanto, no solo nos importa entregar, sino el impacto que la entrega tenga. Esto significa que un UX es Scrum puro, porque piensa en el resultado que provoca el trabajo, no en el trabajo en sí. ¡Vamos por el buen camino!
Scrum y UX, cuando se convierte en una fase “inicial”
Muchas veces, hemos visto a equipos “Scrum” tener una “fase de UX inicial” en la que se valida la solución visual con el cliente que les contrata. Esta manera de trabajar, de pensar en Scrum como un método de desarrollo, es quizás uno de los grandes males de Scrum y de UX. Está bien hacer prototipos, diseños preliminares y estar trabajando codo con codo con tu cliente, sin embargo, es muy pronto dar por buena una solución que es de “cartón-piedra”.
Imaginemos un UX que pacta con su cliente una serie de pantallas que mostrarán muchos datos y que servirán para hacer operaciones sobre ellos. El cliente ve el prototipo inicial, le parece interesante y “aprueba el desarrollo”. Meses más tarde, se entrega todo el proyecto terminado tal y como se validó y, de pronto, el usuario se frustra porque al mostrar tantos datos los tiempos de carga de cada pantalla se elevan demasiado. La experiencia de usuario real es pésima, a pesar de que las pantallas eran preciosas. Por desgracia, hemos visto esto demasiadas veces.
Dual Track para hacer Scrum con UX
Dado que tenemos que hacer trabajo de descubrimiento y trabajo de desarrollo, muchos equipos deciden utilizar la práctica Dual Track para poder dividirlo.
Con el Dual track, conseguimos que una parte del equipo alimente al resto. ¡Y ese es el problema! que dividimos al equipo en dos, lo que puede provocar que las personas pierdan perspectiva y responsabilidad. El Discovery y el Development son partes unidas, porque están relacionadas con la entrega de valor. Por tanto, es una mala idea dividir el equipo en dos.
Ahora bien, sí que podemos dividir el trabajo entre aquellas tareas relacionadas con el descubrimiento y aquellas del desarrollo. Se divide el trabajo, no las personas. En el fondo, Scrum ya lo contempla con una figura como el Product Owner, que pasa la mitad de su tiempo con el mercado testeando y proponiendo nuevas ideas para desarrollar. De hecho, el refinamiento es el momento en el que los Developers se sientan con el Product Owner para pensar en futuros pasos del producto para generar valor.
Sin embargo, debemos involucrar a todos en todos los aspectos, es verdad que todos los miembros del equipo no programaran software (puede que un especialista UX no sepa) pero tampoco es bueno que salga de la dinámica del equipo. Además, es positivo que las personas que codifican también se involucren con los usuarios, visitándolos y conociendo su realidad (aunque lo hagan menos veces que un UX).
Trabajo se divide entre Discovery y Development, pero no la responsabilidad
Como hemos dicho, podemos dividir el trabajo pero teniendo en cuenta que la responsabilidad de la entrega de valor es colectiva. Hemos creado empresas con etiquetas donde las personas tienen sus propias carreras individuales, lo que después acaba degenerando en dificultades para trabajar en equipo. En muchas organizaciones, delegamos esa responsabilidad en el manager para que gestione las tareas de todos y ponga cabeza. Sin embargo, en un mundo complejo, donde el trabajo no es lineal y debemos convivir con muchas posibles interrupciones e impedimentos, es mejor trabajar una buena relación dentro del equipo.
Por eso, en Scrum hablamos de eliminar etiquetas dentro de los “Developers”, de hecho, un UX dentro de un equipo Scrum sería considerado Developer, al ser parte de la construcción del producto.
Por tanto, si queremos integrar UX con Scrum, pensemos que estamos añadiendo una nueva disciplina al grupo. Eso significa que ahora el equipo será más eficaz, ahora será capaz de hacer algo más que antes no sabía. Ahora bien, no podemos añadir UX como una capa previa ni como algo “paralelo”, alejado de la entrega de valor en la que todos nos involucramos en Scrum.
Y tú, ¿cómo integras UX con Scrum? 🙂
