Cómo integrar la experiencia de usuario ágil en proyectos de desarrollo: lecciones aprendidas y consejos prácticos

Este artículo fue publicado originalmente en 2014 en experience.sap.com

En parte 1 de este artículo, resumí el trasfondo y los conceptos básicos de la experiencia de usuario ágil (UX). En este artículo de seguimiento, me gustaría alejarme de la teoría y contarte más sobre mis experiencias prácticas y personales trabajando con estos métodos.

Con el auge de enfoques ágiles y lean en nuestra industria, los profesionales de UX son más propensos que nunca a encontrarse apoyando proyectos ágiles. Sin embargo, muchos de nosotros parecemos frustrados por el desafío de integrar efectivamente UX dentro de un marco de desarrollo ágil. Como me sucedió a mí.

Las razones son multifacéticas, pero fáciles de rastrear: Mientras que los equipos de desarrollo recibían formación en desarrollo de software lean y en ingeniería de software ágil con métodos scrum, los diseñadores de UX no eran vistos como una parte integral del proceso de desarrollo de software. El pensamiento "cascada" en los equipos de desarrollo aún no ha sido completamente erradicado. En este pensamiento, los diseñadores de UX crean diseños pixel-perfect al principio de un proyecto de desarrollo, los "lanzan por encima de la valla" al equipo de desarrollo y luego pasan al siguiente proyecto.

En el último equipo con el que trabajé, intentamos utilizar estos métodos en nuestro equipo de producto y en nuestro equipo de desarrollo. Esto es lo que sucedió.

Nuestro primer paso fue formar un equipo de producto multidisciplinario. En la primera fase del proyecto, el equipo de producto tuvo 4 semanas para realizar actividades de pensamiento de diseño e investigación de usuarios, mientras que el equipo de desarrollo estaba ocupado con el mantenimiento de sistemas existentes y evaluando tecnologías para nuestro nuevo producto. Después de estas 4 semanas, teníamos un prototipo validado por el usuario final y un producto mínimo viable (MVP) listo para nuestro primer lanzamiento del producto. Dado que en SAP utilizamos scrum como un marco de desarrollo de software ágil iterativo e incremental, nuestro equipo de desarrollo ya estaba familiarizado con este método y lo había estado utilizando durante algún tiempo. Por lo tanto, comenzamos con una duración de sprint de 4 semanas, que resultó no ser suficiente para la forma en que queríamos trabajar. Así que lo acortamos a 2 semanas. Seis semanas antes del primer lanzamiento, cuando nuestro equipo estaba bajo una gran presión de tiempo y necesitaba trabajar de manera muy eficiente, acortamos la duración del sprint a 1 semana y ajustamos nuestras reuniones de sprint en consecuencia.

Durante el proceso de desarrollo, me sentaba al lado de los desarrolladores y los ayudaba con las iteraciones de diseño en el código a nivel pixel-perfect. También tenía discusiones con el equipo de producto sobre cómo proceder en futuros sprints y creaba wireframes para los elementos en los que decidíamos. Así que estaba al mismo tiempo con el equipo de desarrollo y por delante de ellos.

Tuvimos la suerte de tener la oportunidad de hablar continuamente con nuestros usuarios finales cada semana durante todo el proceso de desarrollo y siempre tuvimos la oportunidad de incorporar de inmediato sus comentarios y descubrir necesidades.

Trabajé durante más de un año con el equipo y lo encontré muy inspirador y educativo.



Algunas de las cosas que aprendí:

Dificultades – Los cambios culturales son difíciles de superar al principio:

• A los diseñadores de UX les encantaría tener mucho más tiempo para investigaciones detalladas, iteraciones y pruebas de usabilidad


• La gestión de productos y el desarrollo están acostumbrados a especificaciones, y a algunos les encantaría tener todas las pantallas pixel perfect de antemano


• Fue un desafío para todos cuando los diseñadores tenían que hacer trabajo just-in-time y trabajo para futuros sprints simultáneamente

Lo aterrador para el diseñador:

• No sabes qué obtendrás al final


• Puede que no sea lo que te propusiste construir originalmente


• Tus diseños preciosos no están grabados en piedra; podrían ser revisados en un sprint posterior y tal vez descartados por completo


• Debes aceptar que, aunque eres el experto en UX, no lo sabes todo, tendrás que seguir aprendiendo constantemente

¡Pero finalmente: lo grandioso!

• Construyes un producto con el efecto de "realmente quiero esto"


• Nuestro éxito compartido y los excelentes comentarios de todas las partes interesadas y clientes fueron una gran experiencia de