Para adentrarnos en este artículo es importante entender de qué hablamos cuando mencionamos #UX, acrónimo para user experience, que es la Experiencia de Usuario. A grandes rasgos podemos decir que el #diseño UX es un proceso iterativo interdisciplinario, que abarca: usabilidad, arquitectura de la información, diseño de interacción, entre otras, con el fin de proyectar soluciones útiles, innovadoras y rentables, permitiendo orientar los objetivos del negocio hacia las necesidades de los usuarios, generando así la creación de valor.
Se centra principalmente en investigar el mercado y las personas, empatizando y comprendiendo el comportamiento, las necesidades y motivaciones involucradas en el área a la que se esté aplicando. Para ello utiliza la observación, la empatía y el análisis, además de buscar la retroalimentación, o feedback, directamente de los usuarios y los interesados involucrados en el proyecto.
Gracias a los ciclos de #Lean UX, basados en 3 pilares fundamentales: #design #thinking, metodologías de desarrollo ágil de software y lean startup #crear - #medir - #aprender, se asegura la entrega de un producto acorde a las necesidades y requerimientos reales del cliente, a través de la interacción directa con este; también se levanta información sobre el producto y lo que busca el consumidor; se generan hipótesis y se ponen a prueba estas mismas, buscando la retroalimentación para medir la evolución y validar los avances que se vayan obteniendo en el desarrollo del producto, permitiendo aprender en cada nueva iteración para mejorar los resultados obtenidos, encaminando a los equipos colaborativos en la dirección correcta.
En resumen, centrarnos en la Experiencia de usuario (UX), unido a las metodologías ágiles nos ayudará a fomentar un entorno empírico, facilitando la divergencia y convergencia de ideas; generando impacto en el negocio y en los clientes a través de soluciones que resuelvan sus necesidades, planificando sobre lo inesperado, aceptando que los entornos pueden transformarse en cualquier momento, y justamente para manejar ese riesgo es que inspeccionamos y adaptamos continuamente.
Scrum
Por su lado, Scrum viene a ser un marco de trabajo, o framework, iterativo e incremental, en el cual se aplica un conjunto de buenas prácticas que nos permitirá trabajar colaborativamente en equipo para conseguir los mejores resultados de los proyectos en los que se aplique.
Para ello se dividirá el Objetivo de Producto en partes más pequeñas o eventos contenedores, llamados #sprints, que según la guía de Scrum, podemos considerar cada uno de estos como un proyecto corto. En cada sprint el equipo trabajará solo en el horizonte, o sprint goal, acordado para él, este horizonte se determinará de acuerdo con las tareas en el #product #backlog, que es una lista ordenada de lo que se necesita llevar a cabo para alcanzar una mejora del producto.
Al final de cada sprint se buscará alcanzar una entrega de valor, compuesta de uno o varios «incrementos», que serán una especie de peldaño, haciendo que cada «incremento» se pueda ver como un avance hacia la meta.
Para que podamos considerar un avance como un «incremento», este debe cumplir con la Definition of Done, o Definición de Terminado, que es cuando todos los criterios de aceptación han sido satisfechos, ya sea que estemos hablando de pequeños avances funcionales, o del proyecto en su totalidad. Esto significa que cuando un elemento del product backlog está listo para ser exhibido al cliente, según los criterios propios de la organización, se puede considerar como Terminado.
Lo anterior no quiere decir que siempre buscaremos lo que entendemos como «elemento finalizado», ya que la Definición de Terminado la podremos determinar acorde a cada producto en nuestro equipo de trabajo, por esta razón podríamos hablar perfectamente de algún tipo de progreso que implique una entrega de valor.
La entrega de valor no es necesariamente software funcional:
Estas entregas que exhibiremos al final de cada sprint, deben ser promotores de algún tipo de avance, por ejemplo entregándonos información sobre lo que funciona y lo que no, como resultado de las pruebas que hayamos ejecutado sobre las hipótesis que fueron planteadas, hayan sido estas validadas o refutadas. Estos resultados le permitirán al cliente y al equipo tomar decisiones, lo que se traduce como una entrega de valor temprana ya que nos habrá dado respuestas que nos permitirán progresar, ya sea modificando errores o validando el trabajo realizado por el equipo hasta este punto.
UX y Scrum
Ahora que ya tenemos una idea sobre estas disciplinas, seremos capaces de entender que trabajar con cada una de ellas por separado supondrá algunos riesgos que, dependiendo del contexto, incluso puedan llevarnos a gastar tiempo y esfuerzo en soluciones que eventualmente deban ser desechadas, o hacernos perder un cliente debido a un abordaje incompleto o deficiente de sus necesidades.
En su contraparte, como veremos más adelante, trabajar con una mezcla entre el diseño UX y Scrum puede acarrearnos ventajas importantes que deberemos tener en cuenta para mejorar la eficiencia de nuestro equipo de trabajo.
Desventajas de no contar con un enfoque integral
Utilizar Scrum sin UX
Los riesgos a los que podemos enfrentarnos por no contar con una visión cohesiva podrían ser por ejemplo:
Las altas probabilidades de no tener en consideración todas las necesidades del cliente: esto puede deberse a la distancia entre los equipos de trabajo dedicados al proyecto, y a la información limitada que se dispondrá del cliente a causa de la dificultad para interactuar con el mismo.
Tener que corregir errores tardíamente debido a este vacío de información, gastando tiempo en solucionar problemas que, en etapas más tempranas, hubiesen requerido de menos esfuerzo.
La posibilidad de acabar con un producto final que no posea un nivel óptimo de usabilidad, que no se adapte al usuario final, o que no cumpla a cabalidad las tareas que el cliente esperaba.
Eventualmente podríamos enfrentarnos a la pérdida del cliente que, insatisfecho, será capaz de encontrar fácilmente otro proveedor de servicios.
Que la escalabilidad de Scrum nos lleve a saltar pasos importantes que plantearía UX, por ejemplo no aplicar el ciclo de hipótesis - validación/revisión - aplicación.
Utilizar UX sin Scrum
En el caso inverso también podríamos encontrarnos con importantes dificultades, como lo son:
Trabajar muy bien el diseño UX pero no ser capaces de comunicarlo correctamente y a tiempo a los desarrolladores que estén involucrados en el proyecto.
Tiempos de desarrollo prolongados a causa de una organización deficiente en el desarrollo de cada objetivo del product backlog.
Dificultad para fragmentar los objetivos del Product Backlog, así como de priorizar, ordenar y refinar el mismo, debido a que no contaremos con la figura encargada de ello que nos entrega Scrum.
Trabajar en una definición de UX que no integre el contexto del negocio particular de cada proyecto.
UX + Scrum
Algunos de los beneficios de unir el diseño UX con Scrum son, entre otros:
Obtener un enfoque de Crear - Medir - Aprender.
Los ciclos iterativos de ambas disciplinas impedirán que avancemos al siguiente nivel sin haber hecho una revisión del trabajo que ya se ha llevado a cabo.
Tendremos una comunicación más rápida que permita una retroalimentación frecuente, tanto con el cliente como con el equipo de trabajo, evitando así tener que corregir errores complejos una vez que el desarrollo se encuentre en etapas avanzadas, o haya alcanzado el siguiente nivel.
Las soluciones que entreguemos estarán equilibradas en las necesidades a cubrir, evitando que solucionemos problemas irrelevantes o que nos desviemos de los realmente importantes.
Obtendremos resultados que integren soluciones para cada uno de los diversos ejes de las necesidades del cliente, ya sea en ámbitos de tiempos de entrega o en el producto en sí mismo.
Eficiencia en la planificación de las entregas de valor que equivaldrá a cada peldaño, así como de sus tiempos y sus revisiones.
Nos ayudará a fragmentar mejor las tareas dispuestas en nuestro product backlog.
Nos aseguraremos que la usabilidad del producto final sea óptima ya que habremos involucrado tanto al cliente como a los desarrolladores.
Como hemos visto las ventajas de utilizar este enfoque mixto pueden ser muchas; dependiendo de nuestro equipo de trabajo y de nuestro Objetivo de Producto, podremos sacar más o menos provecho de ellas, encontrando, en ocasiones, nuevos ámbitos en que la fusión de estas sea provechosa para nuestro proyecto.
Referencias:
La Guía de Scrum, Ken Schwaber & Jeff Sutherlan.