0

¿Cómo se trabaja la UX en un entorno ágil?

En un principio, unir dos puntos de vista tan distintos como el de un diseñador y un desarrollador era poco menos que imposible. Cada perfil tenía en mente objetivos diferentes como la misma visión del proyecto a realizar y si incluimos al componente de negocio o marketing la cosa iba de mal en peor. La culpa la tenían ambos tipos profesionales, uno por creerse artista y olvidar el dicho “no porque sepas hacerlo, lo debes hacer” y el otro por creer que sin desarrolladores el mundo como lo conocemos dejaría de existir.

Pero esto llega a su fin cuando el equipo de trabajo se compromete a reinventarse. Por ello, quiero narrar mi propia experiencia de trabajo en un entorno ágil de desarrollo.

La situación comienza cuando nos reunimos para definir una nueva funcionalidad que el equipo de I+D ha ideado. Previamente a todo lo que continúa tenemos ya en mente los perfiles de Personas creados que representan a la audiencia que utilizará nuestra herramienta de trabajo on line y los Escenarios en los cuales se hará efectiva la interacción. Usualmente es el director de negocio quien abre la sesión explicando el motivo por el que se va a llevar a producción la funcionalidad nueva a integrar en la herramienta o si esta es una verticalización solicitada por un cliente, el director de negocio se asegura que todos hayamos entendido el porqué y para qué se ha decidido llevar a producción esta nueva idea y pide las opiniones de los miembros del equipo (conformado casi siempre por el diseñador UX/UI, dos desarrolladores, el director de desarrollo y el director de negocio, de tanto en tanto aparece el CEO pero éste más en un rol consultivo -que indica el alto grado de madurez del equipo-) para cerciorarse que ya estamos empezando en nuestra mente a diseñar el producto.

Luego, el director de desarrollo explica el cómo es que se va a producir esta funcionalidad en una charla bastante técnica (que por fuerza el diseñador UX/UI debe ser capaz de comprender si bien es cierto que no va a ser el que lleve a cabo su desarrollo, sí debe conocer el lenguaje técnico de desarrollo en el entorno en el que se trabaja) donde expone las potencialidades y limitaciones del framework en el que se va a trabajar. Indica qué método ágil será utilizado (en nuestro caso utilizamos Kanban y Scrum, ambos previamente definidos para qué tipo de trabajo a realizar se utilizará uno u otro) y se asegura que el resto de desarrolladores (frecuentemente un senior en equipo con un junior y cuando no, el mismo director de desarrollo es quien guía dos junior) han comprendido la tarea y que el diseñador UX/UI sepa perfectamente qué posibilidades tiene al momento de crear la UI y realizar tareas de UX.

Después de lo mencionado líneas arriba, el diseñador UX/UI expone los puntos referentes a usabilidad que haya podido detectar en ambas exposiciones para poder resolver en ese momento las dudas que puedan surgir y llevar a situaciones límite las posibles interacciones exitosas pero sobre todo fallidas de los usuarios finales con el objetivo de perfilar mejor las capacidades de la nueva funcionalidad a llevar a producción. Seguidamente comienza la parte que más me gusta de estos procesos (que no son el backlog en sí pero bien podrían ser parte importante del mismo e incluso en ocasiones ser el todo) que es el UX sketching, donde el diseñador UX/UI con lápiz y papel y pizarra y rotuladores comienza a esbozar con colaboración con el equipo el diseño de UI, de interacción y allí mismo repensar las ideas para pulir los Escenarios y problemas de usabilidad que se puedan detectar en este estadio.

Una vez que todo el equipo tiene claro el diseño de la solución a desarrollar se pasa al prototipado operativo (pero sin dejar de ser un maqueta en sí a pesar de ser funcional, a veces la maqueta de renderizado en navegador la realiza el mismo UX/UI en HTML/CSS/JS) del requerimiento con los conceptos trabajados en la sesión anterior, aquí la participación del diseñador de UX/UI es constante pues va puliendo la solución en un continuo “prove and improve” en comunicación fluida con el o los desarrolladores hasta llegar a la primera prueba de usabilidad del prototipo donde se vuelve a repetir el bucle de prueba y mejora hasta llegar a la versión beta que se sustenta en presencia del director de negocio y desarrollo en donde se termina de afinar el producto y pasa a ser un módulo completamente funcional en espera de su integración con la herramienta y despligue final.

Puede parecer (o no) engorroso y lleno de vueltas pero en la práctica es sorprendentemente rápida la forma en la que UX y Ágil se integran produciendo soluciones “bullet proof”. Ésta integración se ha denominado LeanUX y está teniendo éxito sin precedentes en diversas compañías de desarrollo de software a una escala mucho mayor de lo que podríamos imaginar en un primer momento.

Recomiendo separara ya en Amazon el libro de Jeff Gothef “Lean UX” que trata mejor este tema y que está ya disponible en versión kindle.

¿Cómo cohesionas UX y Ágile en tu trabajo?


Foto por: rmlowe via Compfight cc

Fatal error: Uncaught Exception: 12: REST API is deprecated for versions v2.1 and higher (12) thrown in /web/htdocs/www.uxinperu.com/home/wp-content/plugins/seo-facebook-comments/facebook/base_facebook.php on line 1273