Este artículo se basa en más de una década de experiencia con las principales corporaciones globales en todos los dominios, países y niveles de madurez. Proporciona una visión del mundo real de los desafíos que enfrentan los profesionales de UX y los equipos de entrega ágil en el mundo del desarrollo de software/productos. Identifica y opera sobre la base de tres principios fundamentales:
Agile y UX tienen poco en común; la primera es una filosofía de desarrollo y la segunda es un dominio. La integración de UX en el proceso de entrega ágil era una necesidad, no una elección. Los líderes ágiles no suelen tener experiencia en UX (diseño o investigación).
Probablemente existan ejemplos de Agile y UX bien hechos, por lo que este artículo no es un estudio exhaustivo de la aplicación de Agile y UX ni una panacea. Utiliza el punto de vista del autor como líder de UX en el campo para identificar desafíos profundamente arraigados y, con cautela, ofrece algunas sugerencias que podrían ayudar a aprovechar mejor el potencial de los equipos de UX en organizaciones ágiles.
También quiero enfatizar que este artículo, en general, se centra en la implementación de modelos de desarrollo ágiles en organizaciones más grandes, tradicionales y lentas, especialmente aquellas que están experimentando transformaciones (y que a menudo han implementado sistemas complementarios como el capítulo modelo).
Es inútil intentar llegar a un consenso sobre lo que es Agile (o lo que debe ser). Una breve revisión de la gran cantidad de contenido sobre Agile sugiere que:
es un enfoque/filosofía para el desarrollo de software valora la entrega/velocidad por encima de la perfección acepta el cambio como una constante y busca responder a él propone equipos pequeños y empoderados liderados por un propietario de producto
Continúo con este artículo suponiendo que entiendes Agile tal como tiende a existir en las empresas modernas y que has participado o al menos has oído hablar del popular marco Scrum (a menudo utilizado como sinónimo de Agile), así como de las ceremonias típicas que constituyen Scrum (limpieza de trabajos pendientes, planificación de primavera, standups y retrospectivas). Si no está familiarizado con Agile o desea ampliar sus conocimientos sobre el tema, le sugerí algunas lecturas al final de este artículo.
La necesidad de agilidad
Creado por un grupo de desarrolladores de software. En 2001, la metodología ágil, que ayuda a los equipos de proyecto a alcanzar objetivos rápidamente en entornos que cambian rápidamente o son impredecibles, ahora se utiliza ampliamente en todas las organizaciones. Pero ser Agile y hacer Agile son dos cosas diferentes.
A estas alturas, la mayoría de las empresas, nuevas y antiguas, están familiarizadas con Agile. Mientras que los más nuevos, como Atlassian, Uber o Airbnb nacieron Agile, otros como Amazon, Telstra y los principales bancos han experimentado transformaciones Agile. El desafío de implementar Agile a escala, especialmente para empresas que no nacieron Agile, es peculiar, y recomiendo leer este artículo de HBR que presenta una visión equilibrada sobre cómo se puede lograr esa escala.
Sostengo que Agile nació de la frustración de los requisitos, el contexto y las tecnologías cambiantes. En el mundo anterior a Agile (se puede pensar en Waterfall, pero es un poco más amplio que solo Waterfall), las empresas intentaban comprender las cosas completamente antes de construirlas o invertir en ellas. Esto causó varios problemas y a menudo significó que cuando los “requisitos” estaban claros, ya era demasiado tarde. Es esta frustración constante de ponerse al día lo que resultó en un cambio de filosofía, que culminó en Agile. La forma en que lo veo es:
Ágil es una resignación al hecho de que nunca sabremos lo suficiente (para tomar decisiones acertadas).
A riesgo de autopromoción, sugiero leer mi artículo titulado The UX Pyramid, para comprender el campo de UX y diseño. Intenté proporcionar un marco que ayude a conceptualizar la UX como un dominio y ayudar a mantener unidas las diversas facetas de la UX. Un breve resumen no vendrá mal. UX, tal como existe hoy, es el dominio que se ocupa del diseño de interacciones entre los usuarios y la tecnología basándose en la comprensión de las necesidades, contextos, desafíos y, eventualmente, objetivos de los usuarios. Al mismo tiempo, permítanme enfatizar que me mantengo alejado de generalizaciones como “UX lo es todo” o “UX es la resolución de problemas”, etc., que si bien no son falsas, no son definiciones útiles. Entonces, a lo largo de este artículo, analizo la UX desde una perspectiva más estrecho más sentido del que algunas personas creen que tiene.
El campo de UX ha experimentado una rápida transformación. Han surgido muchas especializaciones, como el diseño de interfaz de usuario (UI), la investigación de UX, el diseño de interacción y el diseño de servicios. Incluso los profesionales experimentados de UX han luchado por mantenerse al día con estos cambios, hasta el punto de que se nos sigue escapando un entendimiento compartido. Este es uno de los principales desafíos en el matrimonio entre UX y Agile; Los propios profesionales de UX no pueden llegar a un consenso sobre qué significa UX; en consecuencia, es casi imposible para los líderes ágiles como Scrum Masters o Product Owners comprenderlo con claridad.
En la mayoría de los casos, el trabajo de un diseñador de UX (supongamos que es un investigador + diseñador de UX para simplificar las cosas por ahora) en una empresa estereotipada es recibir información del negocioagregarle una comprensión del usuario, los fundamentos del diseño e, idealmente, los sistemas/tecnología, y proponer cómo funcionará o será utilizado algo por el usuario final. Muy pocas empresas comienzan con un grupo de diseñadores de UX que diseñan el producto desde el principio; la mayoría de nosotros dedicamos tiempo a crear o mejorar funciones en productos existentes (a pesar de que muchos afirman ser diseñadores de productosque en mi experiencia es un seudónimo de un diseñador UI/UX).
Por ejemplo, cuando trabajé en Atlassian, un conocido gigante del software que fabrica el popular conjunto de productos Jira y Confluence, trabajé en experiencia de administrador para Confluencia. Básicamente, esto significaba que intentábamos, junto con el gerente de producto y el líder de tecnología, diseñar la interfaz de usuario para los administradores de Confluence a medida que se agregaban nuevas características al producto (y por lo tanto era necesario implementarlas). administrado). Tuvimos muy poco que decir sobre cuáles podrían ser esas características, una función que podemos llamar UX estratégica (que informa utilidad y no solo usabilidad). Rara vez los profesionales de UX diseñan algo desde cero y, cuando lo hacen, Agile dicta que un nuevo producto se desarrolle de forma incremental. Entonces, ¿se puede diseñar de forma incremental?
Agile promueve la idea ahora omnipresente de desarrollo incremental que limita el riesgo y maximiza la oportunidad de aprender y pivotar. Si bien esta idea parece conceptualmente sólida, la realidad suele ser muy diferente.
En la típica empresa moderna que sigue el modelo de desarrollo ágil, un programa de trabajo suele comenzar con ciertas temas que los líderes empresariales quieren perseguir. Piense en un tema como una idea amplia que, cuando se perfecciona, dará como resultado una serie de proyectos potenciales, o lo que se llama elementos de la hoja de ruta. Cómo se deciden y priorizan es una discusión separada y, nuevamente, en mi definición más estricta de UX, los UXers tienen un papel limitado que desempeñar en este proceso, aunque algunos quieran involucrarse más.
Usemos un ejemplo de una empresa de telecomunicaciones para continuar con esta discusión. Imagínate que eres el Product Manager responsable de la cartera de móviles pospago. Quiere ofrecer un nuevo servicio de roaming internacional a los clientes existentes que reemplace un sistema más antiguo y complicado que los clientes podrían usar para roaming internacional. Saltaremos las razones de por qué crees que es una buena idea; supongamos que es uno. Esto podría considerarse un tema. Se puede dividir en características, según cómo lo usarán los usuarios (es decir, comprar, usar y administrar pases de roaming internacional), así como varias características de back-end que impulsarán la nueva oferta. ¿Cómo pasamos de este tema de alto nivel a la experiencia de usuario detallada? Aquí es donde comienza a divergir lo que debería suceder versus lo que realmente sucede.
Qué debería pasar
Lo que debería suceder es que a partir de un proceso colaborativo se cree una visión del cliente final, generalmente producida por un diseñador de servicios o un diseñador UX estratégico. Un mapa del recorrido del cliente es una idea muy simple: un diagrama que ilustra los pasos que siguen sus clientes para interactuar con su empresa, ya sea un producto, una experiencia en línea, una experiencia minorista, un servicio o cualquier combinación. Estos mapas de viaje explican el tipo de experiencia potencial que un cliente podría tener en relación con el tema (itinerancia internacional). En el caso de su tema, un mapa de viaje (o un artefacto similar, como un plano de servicio) podría incluir las fases a través de las cuales el cliente interactuará con el roaming internacional, así como el conjunto de tareas (basadas en, digamos, las tareas a realizar). Be Done), que luego se traducirá en requisitos de funciones) que admitirá cada una de esas fases.
Requisitos, en esta etapa, deben ser de alto nivel, es decir, surgirá la definición/construcción del producto. Por ejemplo, algunos requisitos para el tema de roaming internacional podrían ser:
Posibilidad de uso en 70 países, divididos en 3 zonas, cada una de las cuales tiene una relación con una estructura de tarifas. Posibilidad de comprar por 7, 14 y 30 días con los paquetes de uso/datos correspondientes. Posibilidad de ejecutar promociones en ciertos paquetes. Posibilidad de cancele en cualquier momento, con reembolsos prorrateados.
Estos requisitos de alto nivel describen la qué, no la cómo. Destacaría que estos requisitos son no suficiente para que los equipos de tecnología estimen o creen las funciones. A partir de aquí se inicia el proceso de definición de la experiencia de usuario, siguiendo las
Proceso de diseño centrado en el usuario: empatizar con los usuarios, definir puntos débiles, idear soluciones, crear esquemas y prototipos, probar e iterar diseños. A través de este proceso, surgen requisitos más detallados.el tipo que define la experiencia del usuario, lo que les importa a los desarrolladores y al propietario del producto (PO) centrado en la técnica/entrega y, de hecho, determinan la viabilidad, como por ejemplo:
Los usuarios podrán buscar entre los países ya sea por nombre o por zona. La vista predeterminada será zonal. Los precios se mostrarán tanto por países como por zonas individuales. Podrás comprar varios paquetes si así lo deseas, pero en la mayoría de los casos tendrá más sentido financiero comprar por zona predefinida, sobre la cual informaremos a los usuarios. Los usuarios podrán ver sus paquetes de roaming activos en Mis servicios (imagine que esta es una vista existente). Los paquetes mostrarán la información de precio, uso y vencimiento. Los usuarios podrán renovar sus packs si a. su saldo de uso está casi terminado o b. Faltan dos días para que caduquen. Habrá una nueva sección para mostrar las promociones disponibles. Según el historial de compras de un usuario, ciertas promociones se pueden priorizar y mostrar primero.
Si bien estos son detalles imaginarios, puede ver cuántos detalles han surgido de los requisitos comerciales que son tanto funcionales como impulsados por la UX. Cuando los diseños de interacción se desarrollen, surgirán más detalles, que luego pasarán por pruebas de usabilidad para perfeccionarse.
No se priorizarán todos estos requisitos emergentes para determinar qué herramientas, como el mapeo de historias de usuario, se pueden utilizar, pero en principio, conviene trabajar hacia atrás desde la experiencia prevista antes de dividir el plan de entrega en una lista priorizada que conduzca a un producto mínimo viable (MVP).
lo que suele pasar
Utilizando el mismo ejemplo de la sección anterior, la empresa determina la necesidad de ofrecer roaming internacional a sus clientes. Quieren saber cuánto “costará” en términos de tiempo/energía. En el contexto de las corporaciones tecnológicas, los ejecutivos de negocios necesitan confiar en su personal técnico para ayudar a calcular el costo…