Todavía nos persigue la idea de que la investigación de usuarios debe ser grande y extensa al inicio de cada proyecto. Se usan frases como “Mucha investigación”, “Sprint 0”. Pero la “mucha investigación” normalmente termina guardada en un cajón, no ofrece valor a las sesiones de ideación, queda desvinculada de las sprints y no genera impacto.

¿Qué implica un abordaje iterativo?

El abordaje iterativo y de mejora continua propone abordar cada proyecto a través de pequeñas iteraciones progresivas donde se va experimentando y entendiendo qué funciona y qué no a partir de la retroalimentación de los usuarios.

Nos llama a comenzar a partir del mínimo producto viable (¡con la funcionalidad más relevante!) para progresivamente ir añadiendo más funcionalidades de a poco.

Pero ¿cómo entra en escena la investigación de usuarios en este paradigma? ¿Se hace al inicio del proyecto de forma “completa”? ¿Tiene sentido? ¿Genera realmente valor? ¿O es una pérdida de tiempo y dinero?

¿Qué requiere el abordaje iterativo?

Podríamos decir que necesita:

  • Que se refrenen los impulsos de hacer todo junto: no se hace todo junto. Se empieza desde lo más prioritario, se aprende y luego se decide qué es lo siguiente.
  • Muchísima humildad: aquí se viene a aprender de los usuarios y del mercado. Lo importante no es lo que nosotros proponemos sino qué les pasa a los usuarios con eso.
  • Y una clara jerarquización de qué es lo importante para los usuarios y para el negocio, porque por ello se va a empezar.

Las palabras clave aquí son: “minimizar el riesgo”, “aprender de los usuarios”, “aprender a equivocarse” y “equivocarse rápido”.

“El error es un regalo, porque te da la oportunidad de cambiar. Pero no solo te da la oportunidad de arreglar, sino siempre sería un quick fix. El error te da la posibilidad de renovarte. Así como el abordaje japonés que detiene toda la producción y corrige el error de raíz para que no vuelva a suceder” Juan Carlos Santana, Agile Coach en Multiplica

Esto implica un cambio profundo en la percepción del error dentro de la cultura del equipo y de la compañía. Queremos aprender de los usuarios y permitirnos equivocarnos (¡rápido!).

¿Esto implica definir el producto completo al principio y fraccionarlo?

Justamente no. Significa ir definiendo a partir de lo más relevante. Detener las ganas internas de definir el futuro y avanzar paso a paso y aprendiendo y viendo qué pasa para hacer rápidamente pivot en función de lo que vaya sucediendo.

Muchas empresas quieren involucrarse en el pensamiento moderno ¡pero!:

Hacen inicialmente toda la investigación ¡aunque sea generalista y luego quede desconectada del resto del proceso!

Planifican todos los flujos del proyecto completo, diseñan todas las interfaces de todos los flujo y desarrollan todo junto, lo cual claramente subirá a producción en mínimo un año.

Igual, para sentirse ágiles añaden frases del tipo:

“Hicimos una sprint 0, para justificar que hicieron una gran investigación inicial.

“Hicimos iteraciones” aunque en verdad lo que tuvieron son reuniones con el cliente para definir todas las funcionalidades completas y perfectas que tendrá el producto.

El mundo iterativo es todo lo contrario. Tiene otro paradigma.

Un abordaje iterativo requiere un equipo muy flexible (¡de mente!) que no esté muy seguro de nada, quiera cuidar su inversión y quiera ofrecer experiencias realmente memorables en sus usuarios.

La investigación de usuarios generalista y extensa termina en un cajón.

¿Cuál es el rol de la investigación de usuarios en cada sprint? El rol de la investigación dentro de cada sprint será:

  • Entender el desafío de negocio con respecto a esa sprint
  • Comprender las problemáticas de las personas, ya sea con sus circunstancias, con la interfaz o con ambos y darles sentido a los números que surjan en cada iteración.
  • Priorizar las problemáticas para el equipo de UX y Producto.
  • Acompañar en las sesiones de ideación siendo la voz de los usuarios ;)

Design Sprint

Design Sprint, el framework que planteó el equipo de Google Ventures (haciendo un mix entre Design Thinking y Scrum), plantea los siguientes pasos dentro de cada sprint:

  • Comprender la problemática
  • Definir qué es lo relevante
  • Idear una solución a la problemática
  • Decidir qué se hará
  • Prototipar la idea
  • Validar con usuarios

El rol de la investigación de usuarios es justamente comprender la problemática puntual para que se pueda definir, idear, decidir y prototipar en función de lo que se comprendió.

O sea, para que la investigación de usuarios sea verdaderamente útil debe dar valor en cada sprint. Y para esto, no sirve que sea generalista y al inicio del proyecto; porque de este modo va a quedar desarticulada.

La investigación generalista ¡que no responde ninguna pregunta puntual ni deriva en ningún accionable demasiado claro! se suele guardar en un cajón y básicamente no genera impacto: no ofrece valor para la ideación de la solución ni mucho menos para el prototipado.

¿Entonces no se hace una gran investigación al inicio de cada proyecto?

Es complejo, porque hacer una gran investigación al inicio corresponde más a un pensamiento en cascada que a un pensamiento de pequeños ciclos iterativos y experimentales.

En el pensamiento en cascada la investigación sí es extensa y al inicio. El problema es que es general y queda desconectada del avance de las sprints. No es útil.

En el pensamiento iterativo la investigación de usuarios es acotada y responder las preguntas puntuales de cada iteración. ¡O sea! Es cualitativamente profunda y puntual: responderá las inquietudes que se vayan a resolver en cada sprint ;)

O sea, no hace falta una gran investigación al inicio, porque lo “grande y perfecto” no es parte de esta filosofía. Aquí se aprende de a poco y progresivamente. Y cada investigación deviene en accionables que se tendrán en cuenta dentro de cada sprint.

¿Por dónde empezamos?

El abordaje Lean invita a empezar a partir del Mínimo Producto Viable o sea, comenzar con lo mínimo que se pueda desarrollar para recibir retroalimentación real por parte de los usuarios, porque esto disminuye el riesgo de inversión. Y a avanzar ¡de por vida bajo! este mismo paradigma.

El ejemplo metafórico es empezar construyendo una patineta, para luego ampliarla a una bicicleta, para luego seguir a una moto y luego mucho luego un automóvil. Aprovechando cada iteración para aprender y recalcular.

En el ejemplo de una aplicación móvil sería desarrollar con la funcionalidad más importante para ver cómo es recibida por los usuarios y a partir de allí seguir iterando de a poco y siempre bajo el mismo paradigma de desarrollar lo mínimo, subirlo, ver qué pasa, aprender y optimizar.

¿Entonces no hacemos una gran investigación al inicio?

“Se va a necesitar una sprint para definir cuál es la hipótesis inicial que se quiere validar. Pero esto no será una sprint 0, sino una sprint donde estén más implicados los investigadores, pero será una misión de todo equipo.” Juan Carlos Santana, Coach Agile en Multiplica

La investigación de principio a fin del proyecto ¡si es que termina! será siempre acotada y enfocada en resolver las problemáticas de cada sprint.

Entiendo que es complejo lanzarse al mundo experimental de las iteraciones y entiendo también que es difícil de abordar cuando se trabaja desde una agencia con un cliente que aún sigue pensando en cascada; pero los resultados serán infinitamente más enriquecedores para los usuarios, para la agencia y para el cliente.

Bienvenido sea animarnos a trabajar de forma iterativa con la humildad que implica ir construyendo de a poco e ir haciendo pivot en función de un aprendizaje colectivo y evolutivo.