Investigación Ágil: tensiones y recomendaciones

Autores: Darío Reyes y María Teresa González

Imagen generada con IA: DALL-E 2

Un desafío que enfrentamos en la cotidianidad los UX Researchers es la articulación (o no) de nuestros trabajo con metodologías ágiles. Lo que en un inicio tenía como foco a los equipos y roles de desarrollo (Fronts, Backs, full-stacks, arquitectos, etc.) tiende a permear de manera creciente a roles de diseño de producto como UX Designers, UX writers, estrategas, y claro, UX researchers.

En este artículo pretendemos esbozar algunas potencialidades y limitaciones de las investigación en experiencia de usuario enmarcada dentro de metodologías ágiles, lo que denominamos “investigación ágil”. Estas reflexiones se nutren de tres fuentes:

1. 7 entrevistas realizadas durante el 2021 e inicios de 2022 a expertos y/o líderes de áreas de UX o UX research, con quienes dialogamos sobre su experiencia en la articulación de la investigación de experiencia de usuario con metodologías ágiles y sobre buenas y malas prácticas en el marco de la “investigación ágil” (2 personas residentes en Chile, 1 en Perú, 1 en Brasil, 1 en Estados Unidos, 1 en México y 1 en Colombia).
2. Nuestra experiencia propia en diversas iniciativas de desarrollo de software en el sector retail, financiero y educativo en los últimos 2 años.
3. Los diálogos que establecimos con algunos asistentes del XIV Congreso Latinoamericano — Ágiles 2021, en el que presentamos una versión preliminar de este trabajo.

Las tensiones entre UX Research y los métodos ágiles

Por “tensión” se entiende el estado generado en un cuerpo u objeto en el que actúan fuerzas opuestas, por ejemplo, cuando los extremos de una cadena son jalados en direcciones opuestas. La tensión por si sola no es buena o mala, si usamos una cuerda para atar dos objetos tendremos que “calibrar la tensión adecuada” para nuestro propósito: una baja tensión hará que los objetos se “escurran”, no se mantengan unidos, pero una alta tensión causará que se dañen los objetos o que incluso se rompa la cuerda.

Argumentamos que las interacciones entre el UX Research y los métodos ágiles están marcados por tensiones, y que parte fundamental del trabajo de los investigadores es aprender a convivir con estas, aflojando algunas veces la tensión y apretando en otras tantas.

Las tensiones se deben, principalmente, a las diferentes trayectorias y lógicas de los UX Researchers y los desarrolladores, así cómo los diferentes lugares que ocupan en las organizaciones. Mientras que muchos de los UX Researchers estudiaron pregrados en ciencias sociales (psicología, antropología, sociología, etc.), con un importante foco en el desarrollo de investigaciones que ayudan a generar conocimiento científico y modelos teóricos para comprender el mundo; los desarrolladores, generalmente formados en ingenierías, sistemas y desarrollo software, tienen una mayor orientación a la práctica y al trabajo aplicado en la empresa.

Estas diferencias disciplinarias generan tensiones en la creación de productos digitales, pues los objetivos, las metodologías, e incluso, el lenguaje usado por investigadores y desarrolladores, es distinto. Una dificultad que se agrava, por lo menos en el caso latinoamericano que nos es más cercano, a la muy reciente masificación del rol de UX Research (incluso del UX) en las organizaciones, que ha generado que los investigadores deben acoplarse a rutinas y formas de trabajo ya establecidas, y a liderazgos ocupados por ingenieros y personas del mundo de los negocios poco familiarizados con las lógicas de las ciencias sociales y los procesos de investigación.

A continuación, las 3 tensiones que identificamos y algunas recomendaciones para convivir con ellas. Más allá de una fórmula mágica que podamos aplicar en todos los casos, esperamos generar reflexiones que ayuden a nuestros colegas investigadores a calcular el “nivel de tensión adecuado”.

1er Tensión: Integración y sincronía con el agilismo Vs. Lógica propia de la investigación

Un cuestionamiento central tiene que ver con los motivos por los cuales la investigación en experiencia de usuario se debería articular con metodologías ágiles ¿Por qué? ¿Qué ganamos o perdemos?

Consideramos que hay dos principales beneficios al encuadrar la investigación en metodología ágiles, primero, la entrega constante de hallazgos de valor por medio de investigación continua, y segundo, una mejor comunicación y articulación con los equipos de desarrollo.

Comencemos con el primer punto. Cuando la función del UX Research se limita a realizar un proceso de Discovery inicial (a veces llamado Sprint Cero) o cuando sólo interviene para responder preguntas puntuales en iniciativas que durán entre 3 hasta 6–9 semanas no recomendamos el uso de metodologías ágiles. En estos contextos, seguir un proceso en cascada con una serie de actividades, entregables y un cronograma bien definidos sigue siendo una óptima alternativa. La articulación con metodologías ágiles suele ser mucho más fluida y fácil cuando las investigaciones que realizamos son evaluativas, mientras que en investigaciones generativas, por su profundidad e incertidumbre, suele tener un mayor nivel de dificultad.

El escenario cambia cuando se trata de iniciativas con duración larga o que tienen un tiempo de ejecución indefinido. En estas situaciones, la planeación del trabajo de investigación por sucesivos sprints (generalmente de 2 o 3 semanas) permite la generación recurrente de hallazgos de valor, por lo que podríamos hablar de un proceso de investigación continua. Nótese que hablamos de “continua” más que “rápida”, de hecho, cuando se asume a la investigación ágil como sinónimo de investigación rápida, empezamos con el pie izquierdo. En el gráfico 1, procuramos ilustrar las diferencias entre la investigación en “cascada” y la investigación ágil por sprints.

En los ejemplos hipotéticos, la investigación en cascada duró 9 semanas y como resultado se generaron 10 hallazgos. En la investigación ágil se realizaron 3 sprints cada uno de 3 semanas, logrando al final los mismos 10 hallazgos, pero con la gran diferencia que desde la semana 3 (al finalizar el primer sprint) ya se han generado y compartido hallazgos con el equipo. Esta organización también permite que en el sprint 2 o 3 (y en los sucesivos), el foco de la investigación se cambie o se refine partiendo de los aprendizajes de sprints previos. De nuevo, una importante acotación tiene que ver con el tipo de investigación, pues como ya mencionamos, esta lógica de investigaciones cortas y continuas es mucho más fácil de aplicar cuando realizamos investigación evaluativa, no generativa.

El segundo beneficio de hacer investigación con marcos ágiles es una mejor comunicación y articulación con los equipos de desarrollo. Aunque hay algunas diferencias según el marco usado (scrum, Kanban, etc.) estos equipos suelen organizarse por medio de una lista de tareas y/o Product Backlog que tiene un conjunto de historias de usuario (HU) priorizadas e incluso con un “peso” para dimensionar el esfuerzo que requiere su desarrollo. Para monitorear los avances se realizan algunas ceremonias (planning, review, retrospectivas, dailys) y se actualizan tableros visibles de control. Este proceso da lugar a la pregunta del millón ¿el trabajo de UX Research debería integrarse con el resto del equipo siguiendo está lógica de Backlog, Historias de usuarios, ceremonias, tableros de control o debería seguir una lógica propia?

Contamos con dos aproximaciones opuestas:

En un extremo tenemos la primera aproximación, generalmente defendida por algunos agile coaches y scrum masters con poca trayectoria en UX y UX Research, según la cual las actividades de investigación deberían ser totalmente integradas al mismo Backlog del resto del equipo, se deberían usar las historias de usuario como unidad de trabajo, y los UX researchers deberían participar de todas la ceremonias. Sin embargo, este escenario resulta forzado para los investigadores y la investigación misma, puesto que la cadencia de trabajo no siempre es la misma del resto del equipo; es muy extraño encuadrar las actividades que realizan los UX Researchers en historias de usuarios, de hecho se articulan mejor con unidades de trabajo mayores (ejem: el desarrollo de una gran funcionalidad o conjunto de funcionalidades, lo que en algunas marcos de trabajo llaman “épicas”), por lo que la participación en todas las ceremonias puede llevar a la pérdida de tiempo valioso.

Del otro extremo, tenemos la concepción bajo la cual las actividades de investigación se realizan de forma totalmente independiente al resto del equipo, como una caja negra que recibe una solicitud y luego de unas semanas entrega los resultados en forma de “informe y presentación”. Al igual que en el extremo anterior, este escenario tiene importantes limitaciones, pues no hay una socialización de los hallazgos parciales que podrían ser valiosos para el resto del equipo, se limitan las opciones de colaboración y retroalimentación con otros roles (ux, estrategas, desarrolladores, etc.) y hay un mayor riesgo desalineación entre el entregable y las expectativas sobre el resultado.

Aunque en nuestra experiencia no hay una receta mágica, el nivel de tensión adecuado suele estar en un punto medio que permite a la investigación seguir una lógica propia con algunos puntos claves de interacción con el resto del equipo que sigue al pie de la letra un marco ágil. Más allá del debate sobre si las actividades investigación deben ser integradas a un mismo Backlog, a uno independiente, o incluso desechar la lógica del backlog, lo fundamental es que:

• Las labores de UX research sean visibles para el resto del equipo
• Se establezca claridad respecto del esfuerzo (tiempo y recursos) que requiere cada actividad (ejem: el reclutamiento)
• Se haga evidente la concatenación de actividades (ejemplo: primero se diseñan las guías de entrevistas y luego sí se realizan las entrevistas)

Respecto a la participación en ceremonias, consideramos relevante la presencia de UX researchers en los sprints planning y las retrospectivas. En los primeros discutiendo los objetivos de investigación, el alcance, la metodología, las posibles colaboraciones con otros roles y los requerimientos para avanzar (ejem: tener acceso a una base de datos, tener un prototipo, etc.), y en los segundos como parte general de las reflexiones del equipo, haciendo un énfasis en el análisis crítico de la pertinencia e impacto de los resultados de investigación. En cuanto a los dailys, la experiencia nos dice que los avances en investigación no suelen ser tan significativos de un día para otro, así que recomendamos la participación en reuniones semanales o dos veces por semana. En el caso de un impedimento, este podría ser solucionado con una comunicación “bajo demanda” con el líder y/o resto de equipo.

2da tensión: Rigurosidad metodológica vs. Restricciones en tiempo y recursos

La segunda tensión tiene que ver con la rigurosidad metodológica de la investigación. Por un lado, se tiene el concepto de que una investigación rigurosa suele tomar varios meses o incluso semestres en los que pasa por un proceso de maduración, comenzando por una revisión de literatura, análisis de experiencias previas, definición de posicionamiento teórico y aplicación de un abordaje metodológico y analítico congruente. Este escenario difícilmente se puede dar en el diseño y desarrollo de productos digitales, pues los entornos actuales, tan competitivos, hacen que los equipos y organizaciones tengan como mantra disminuir el “time to market”, estrechando los tiempos y recursos necesarios antes de lanzar un producto digital. Por otro lado, tomarse el proceso de investigación muy a la ligera, sin garantizar unos estándares de calidad, hace que se pierda la validez de los resultados, o incluso peor, que confiadamente se tomen decisiones sin el sustento adecuado.

¿Cómo jugar con esta tensión optimizando los esfuerzos en investigación sin sacrificar la rigurosidad de la misma?, recomendamos tener en cuenta 4 elementos:

Lo primero es adaptar el alcance de la investigación según el grado de incertidumbre. Entre mayor sea el desconocimiento de los usuarios, la tecnología y el comportamiento del mercado el alcance de la investigación también deberá ser mayor. Siguiendo la lógica de investigación continua que ya describimos en el gráfico 1, sugerimos definir objetivos muy acotados por sprint, menos ambiciosos, y darle prioridad en los primeros sprint a aquellas dudas que son más apremiantes y que tocan temas estratégicos, como el análisis de la propuesta de valor, el entendimiento de posibles early users, etc.

Lo segundo es involucrar otros roles como UX designers, UI designers, estrategas y devs en el proceso de investigación. Si bien los UX Researchers deben liderar la realización de las investigaciones, encontramos muy beneficioso el involucramiento de otros roles, pues el contacto directo con los usuarios genera una mayor sensibilidad en todo el equipo sobre sus necesidades y expectativas, ayudando a eliminar sesgos o preconcepciones que pueden existir desde negocio o en el equipo de producto, sumado a que contar con manos adicionales agiliza la realización de algunas tareas como la toma de nota, transcripciones, pre-análisis, etc; además, los diferentes conocimientos y experiencias de cada rol enriquecen el trabajo de campo y la generación de resultados.

Lo tercero es la realización de actividades en paralelo o el “no dejes el análisis y la graficación para el final”. Una de las maneras de aportar agilidad en los procesos de investigación es la ejecución de algunas tareas en paralelo, reduciendo los tiempos muertos. Hay dos momentos en particular que sugerimos intervenir:

- Durante el reclutamiento de participantes y la elaboración de instrumentos y guías los UX Researchers generalmente no están ocupados al 100%, por lo que este tiempo podría ocuparse realizando benchmarks o consultando otras fuentes secundarias que nutran el análisis.

- Es frecuente que los investigadores dejen el análisis y la graficación de resultados para cuando hayan acabado la recolección de datos, nosotros recomendamos cambiar este abordaje y desde el momento en el que se está llevando a cabo el trabajo de campo avanzar en la síntesis y graficación de resultados. Por ejemplo: si se definieron realizar 10 entrevistas, probablemente desde la cuarta o quinta tenemos algunos hallazgos interesantes o incluso una tendencia. Con este conocimiento podemos ir avanzando en la creación del “esqueleto” de la historia que vamos a contar, la estructuración de los resultados, e ir planeando y diseñando la mejor forma para comunicarlos.

Lo cuarto y último, es la optimización del reclutamiento con paneles de usuario. Uno de los principales desafíos de la investigación es la consecución de los participantes con las características necesarias en un periodo de tiempo adecuado. Para atacar este reto recomendamos el uso de paneles de usuario, que es un conjunto de personas que ya pasaron por un proceso de screener (por ejemplo sabemos edad, género, residencia, consumo de productos, etc.) y que de manera semi-estable colaboran con las investigaciones, por lo que podemos contactarlas de forma muy rápida. Eso sí, para evitar sesgos, el panel de usuario debe garantizar cierta diversidad de participantes y se debe esperar un tiempo prudencial para permitir a un mismo participante hacer parte de las distintas investigaciones. Por ejemplo: si tenemos un panel de 70 personas, en cada sprint podemos contactar a 10 de ellas para entrevistas o test de usabilidad moderados y las vamos rotando, de tal forma que solo las contactaríamos cada 7 sprints (aprox. cada 4 o 5 meses).

3ra tensión: Software funcionando vs. Software de valor funcionando

Es frecuente que los equipos encargados del diseño y desarrollo de productos digitales se enfrenten con clientes, externos o internos, que tiene una larga lista de deseos con funcionalidades, componentes y/o servicios que les gustaría que fueran implementadas.

Cuando estas situaciones se presentan los UX Researchers se enfrentan a una significativa tensión, por un lado, algunos equipos ágiles caen en el juego y se enfocan en generar rápidamente resultados o outputs, “software funcionando”, sin tener una visión crítica del valor que están entregando a los usuarios con sus funcionalidades, actuando bajo lo que fue simplemente un “requerimiento que hizo negocio”, lo que muchas veces está basado en una wish list de funcionalidades en lugar de tener un fundamento de viabilidad y match con la propuesta de valor o lo que los usuarios realmente necesitan y van a usar. En este contexto, la investigación suele ser vista como una barrera o una carga que demora el proceso de entrega de software.

Por otro lado, aún en equipos y organizaciones maduras en las que hay una alta credibilidad en los aportes de UX Research, por más que sean aplicados diferentes abordajes y técnicas de investigación para reducir la incertidumbre sobre la posible adopción y usabilidad de alguna solución digital o funcionalidad, nunca vamos a estar 100% seguros. Una prueba de fuego única de la que se puede aprender muchísimo es utilizar “software funcionando” y realizar estudios de con beta-testers, o incluso hacer lanzamientos semi-controlados en mercados pequeños monitoreando detalladamente la recepción del público.

Para lidiar con esta tensión, entre ir a ciegas entregando software o tener la ilusión de control de que es posible investigar y analizar absolutamente todo antes de lanzar, recomendamos un mayor involucramiento de los UX researchers en dos actividades.

1. Ejercicios de priorización: un error en el diseño de productos digitales es la desconexión entre el conocimiento sobre las necesidades y expectativas de las personas, generado por UX Research, y el software final entregado por los equipos de desarrollo. Para minimizar este problema recomendamos una participación activa de los UX Researchers en los ejercicios de priorización de funcionalidades dando insumos que ayuden a la toma de decisiones. Una buena forma de hacerlo es empleando métodos mixtos de investigación, con el abordaje cualitativo podemos comprender las motivaciones, las barreras y los posibles escenarios de uso de las funcionalidades; mientras que con la aproximación cuantitativa, podemos tener métricas exactas para ordenar funcionalidades según su importancia, y comunicarnos mejor con los equipos de desarrollo más familiarizados y crédulos con las cifras. Particularmente, hemos tenido buenas experiencias aplicando desde una mirada cuantitativa el Modelo Kano de priorización (https://sapioresearch.com/kano-analysis/), complementándolo con entrevistas y/o talleres de co-creación con usuarios para tener un zoom cualitativo.
2. Definición de estrategias y tácticas de growth: por medio de modelos experimentales de trabajo como el “growth hacking” y “growth product management” se procuran la evolución constante de productos y servicios digitales. Recomendamos que UX Researcher trabaje en dupla con los roles que lideran estos ejercicios (growth hackers, planners, estrategas, business analyst, etc.), acompañando el diseño, ejecución y análisis de experimentos y otros tipos de investigaciones orientados a 1) implementar mejoras en el diseño del producto digital, como ir comparando entre dos flujos de registro cuál tiene mejor usabilidad y conversión, y 2) refinar el modelo de negocio y las estrategias de monetización, por ejemplo, evaluando la preferencia de clientes entre un modelo de suscripción y uno de pago por uso de servicio. Así, se avanza en una lógica de toma de decisiones basado en conocimiento en lugar de una basada en suposiciones, de tal forma que el software entregado no solo sea funcional, sino que también sea de valor.

Consideraciones finales

Esperamos que hayan encontrado interesante el texto y que algunas de las reflexiones y recomendaciones puedan ser usadas y/o adaptadas a las realidades de sus trabajos. Al igual que toda investigación, el análisis aquí expuesto tiene ciertas limitaciones. Más que una “fórmula mágica” para hacer investigación ágil quisimos, por una parte, exponer algunas tensiones claves, y por otra, dar un conjunto de recomendaciones, entre muchas otras posibles, para lidiar con éstas. Los argumentos aquí defendidos deben usarse con mesura y matizarse dependiendo del sector, el grado de madurez en UX de las organizaciones y el seniority de los investigadores.