A la hora de crear productos digitales que finalmente sean adoptados y usados exitosamente, es clave que el equipo tenga un claro entendimiento y foco en resolver tanto las necesidades formales del negocio con sus limitantes tecnológicas, así como las necesidades humanas de los usuarios en relación a ese producto o servicio. Los roles dedicados a proveer esto son los analistas de negocio (BA) y diseñadores de experiencia de usuario (UX, UXD), que garantizan así una solución realizable, atractiva, fácil de usar y que permite tanto al negocio como a los usuarios alcanzar sus objetivos finales.
Por un lado, el analista de negocio se enfoca principalmente en analizar las necesidades que el negocio necesita satisfacer para con el producto en cuestión, así como las reglas de negocio que este debe respetar. Es responsable puntualmente de la construcción de criterios de aceptación claros e inequívocos. Usualmente suelen ser “dueños” del producto, así como investigadores o gestores de equipos.
Por otro lado, el diseñador de experiencia de usuario toma estas necesidades de negocio, investiga y adhiere las necesidades de los usuarios, y genera la solución a nivel conceptual de la experiencia final al usar este producto (usualmente, en forma de prototipo). La experiencia conlleva múltiples aristas que este rol debe considerar para lograr un producto exitoso: Arquitectura de la información, interacciones, visuales, contenido, entre otros.
Es importante entender que, si bien ambos son usualmente los que investigan, idean y evalúan el producto en conjunto, el enfoque que le ponen es muy diferente y posee un valor en sí mismo distintivo. Se puede esperar que ambos roles sean los que proveen la claridad al resto de los integrantes sobre los requerimientos, funcionalidades, y flujos que van a componer la aplicación. Vale aclarar también que la definición de la arista tecnológica del análisis es responsabilidad primariamente del Líder Técnico.
Estos roles actúan aportando claridad al equipo investigando y definiendo los puntos clave de mejora de producto que tendrán un mayor impacto positivo sobre los usuarios, lo que significa reducir los costos de desarrollo a únicamente lo que sí tiene sentido implementar. Algunas de los puntos más importantes donde ambos roles aportan valor al producto en conjunto:
Si estamos hablando de la creación de un producto enteramente nuevo, una de las tareas más relevantes en este punto del proceso es crear una estructura sólida que permita abarcar todas las necesidades de los usuarios y del negocio que se busquen cubrir, y que escale a futuro lo más que se pueda. Es aquí donde contar con al menos 1 BA y 1 UX previo a comenzar esta etapa, creo yo, es una decisión inteligente. Lamentablemente, suele ser algo recurrente de ver en los proyectos de IT que durante esta fase el presupuesto se destina a la contratación de equipos de desarrollo y estos roles no terminan siendo contratados, o contratados “a medias”, o dejando únicamente un referente que cubra ambas áreas. Esto después repercute en proyectos que no escalan, o que tienen una visión dispar en contraste con lo que necesitan los usuarios y/o el negocio.
Otro punto importante está en la sinergia de estos roles: Es importante que estos roles se complementen, aportando y haciéndose cargo de su área y alcance. BA y UX algunas veces pueden encontrarse mirando hacia lados opuestos, indiferentes el uno hacia el otro, no teniendo suficiente comunicación, ignorándose por completo o incluso compitiendo entre sí. Esto es muy ineficiente y supone un riesgo para la buena definición del producto. Idealmente ambos roles deben trabajar en conjunto, estar constantemente alineados en lo que están definiendo, y constantemente actualizados con los últimos descubrimientos. Empezar desde el día 1 fijando las reglas de juego que equilibren la balanza (y teniendo en cuenta que pueden afinarse a medida que avanza el proyecto) creo yo asegura no sólo la buena colaboración entre estas áreas, sino que es uno de los principales puntos que definen el éxito de todo el proyecto.
Construir una única fuente de la verdad para los elementos que forman la documentación del producto significa un gran esfuerzo pero ayuda mucho a la comunicación eficiente y clara. Soy gran partidario del uso de los modelos (user personas, journey maps, flow charts, api flows) como formatos flexibles y eficientes para bajar a tierra el conocimiento aprendido y compartido de una manera clara y fácilmente legible por todos los miembros del equipo.
Como punto aparte, las user stories (o job stories para JTBD) suelen ser el modelo más eficiente de comunicación de requerimientos, y es en donde UX y BA deben dejar en claro cómo ese requerimiento aborda las necesidades de los usuarios y del negocio. Acompañar este modelo con una definition of done/ready, criterios de aceptación y documentación y especificaciones detalladas de diseño son piezas fundamentales que aportan claridad a los equipos para entender cómo debe abordarse esa historia de usuario de manera que, una vez implementado, aporte el valor esperado al producto. Este trabajo siempre se debe entregar posterior a la etapa de implementación de la misma, de manera de evitar que se pise la implementación con la definición del producto (lo que genera mucha deuda de UX a futuro). Por ello se recomienda tener esto definido 2 semanas de antelación al sprint de desarrollo.