Investigar con los usuarios en Lean UX

José María Berenguer

El ciclo Lean UX, con sus cuatro fases Suponer-Prototipar-Experimentar-Validar (SPEV) es un primer intento, por parte de Jeff Gothelf (Lean UX. Cómo aplicar los principios Lean a la mejora de la experiencia de usuario, UNIR, 2014) de crear una metodología de diseño de la experiencia de usuario que se alinea con los principios del pensamiento lean y del movimiento agilista y, consecuentemente, con el postulado básico del método científico: la experimentación.

El ciclo Lean UX, con sus cuatro fases Suponer-Prototipar-Experimentar-Validar (SPEV) es un primer intento, por parte de Jeff Gothelf (Lean UX. Cómo aplicar los principios Lean a la mejora de la experiencia de usuario, UNIR, 2014) de crear una metodología de diseño de la experiencia de usuario que se alinea con los principios del pensamiento lean y del movimiento agilista y, consecuentemente, con el postulado básico del método científico: la experimentación.

Como la característica clave de esta experimentación, en la que los usuarios son protagonistas destacados, es iterar,… e iterar lo más posible; lo ideal es concentrar las energías, como en el caso del bucle de Ries, en minimizar el tiempo que se tarda en realizar el ciclo, de ahí la importancia de sistematizarlo al máximo.

En dos post anteriores, “Hacer hipótesis en el diseño UX y poner el foco en resultados” y “Experimentar con prototipos en Lean UX” se han analizado las dos primeras fases del ciclo con ayuda de dos procesos: “Declarar hipótesis en Lean UX” (correspondiente a “Suponer”) y “Crear el PMV y experimentar en Lean UX” (correspondiente a “Prototipar”) En este post se analiza un tercer proceso: “Investigar (colaborativa y continuamente) en Lean UX” que se corresponde con la fases de “Experimentar” y “Validar”. Con esta última fase se cierra el ciclo.

Según Gothelf (2013) “ investigar con los usuarios está en la entraña de la mayoría de los enfoques de UX”; y ese “investigar con”, además de hacer de los usuarios un “cocreador” de la experiencia, implica adoptar una forma de trabajo que haga de la investigación no algo ocasional (y realizada por equipos subcontratados que entregan voluminosos deliverables) al comienzo o al final del proyecto, sino un descubrimiento continuo y colaborativo a base de sprints, en la que participe el equipo UX y todos los grupos o individuos interesados en el diseño (stakeholders). Don Norman en The Design of Everyday Things (2013) añade una interesante matización: que siendo uno de los retos del Human-Centered Design (HCD) mantener un foco intenso sobre los usuarios, asegurando que los productos o servicios respondan a problemas reales; sin embargo, acomodarse a los mercados globales (con la diversidad de usuarios y culturas que esto presupone) exige un activity-centered design frente al HCD clásico, en dónde las actividades de los usuarios –que tienden a ser similares con independencia de la multiculturalidad de estos– son las que definen el producto y sus funcionalidades y no estos. Ratcliffe y McNeill en Agile Experience Design. A Digital Designer’s Guide to Agile, Lean and Continuous (2012), añaden tres ideas más; las dos primeras relacionadas con la eliminación del despilfarro (de tiempo, de funcionalidades,…) y la tercera con la experimentación a base de mínimos que progresivamente se aproximan al producto/servicio final: “Hacerlo, si marca una diferencia”, “justo lo suficiente y no más”, y luego… “Iterar, iterar, iterar” la investigación, porque no se acertará a la primera.

Gothelf en su libro Lean UX. Cómo aplicar los principios Lean a la mejora de la experiencia de usuario (2014), propone un proceso de investigar o de descubrimiento colaborativo y continuo (como se apuntaba más arriba), que se presenta en la figura, en el que se distinguen unas actividades primarias o alineadas con el flujo de valor principal del proceso y otras soporte.

Las actividades primarias explican los elementos básicos de la acción de validación o refutación de las hipótesis: revisar las suposiciones de las hipótesis, concretar o estipular, previamente, lo que hay que aprender en la prueba, definir el artefacto que se va a usar como PMV en la validación y, así mismo, definir quienes van a ser los que participarán en la prueba.

También se incluye como actividad la de “afinar” el PMV hasta que sea “probable”, porque hay que recordar que el MVP debe ser realmente un producto, algo que los clientes puedan usar, aunque sea mínimamente en plan de prueba; y además, debe también ser viable, porque desde la primera iteración, al resolver desde el dia 1 los problemas principales de los earlyevangelists, facilite el aprendizaje que previamente se ha estipulado.

La cadena de actividades primarias termina con las referentes a la realización de las pruebas y a la utilización del conocimiento adquirido para validar o falsar la hipótesis. De estas últimas actividades se obtiene el aprendizaje validado que constituye una de las características diferenciales de la metodología Lean Startup. Con esto se cierra el bucle de la metodología Lean UX y se empieza de nuevo el ciclo.

Las actividades soporte se centran en aspectos instrumentales como: crear una guía de entrevistas, organizar los equipos de entrevistadores y estimular a los equipos para que hagan el GOOB (Get Out of the Building).

Cuando se habla de descubrimiento colaborativo se hace referencia a la necesidad de trabajar como un equipo (que incorpora expertos externos pero no recurre a subcontrataciones) para validar las ideas en el mercado haciendo GOOB y posteriormente, intercambiando sus conclusiones en un clima que fomente la participación. En el equipo se integran todos los implicados en el diseño UX: directores de producto, diseñadores gráficos, expertos en contenidos, ingenieros de software y un largo etcétera que incluye también especialistas en control de calidad. Todos ellos trabajan coordinadamente, evitando los silos y en un ambiente de camaradería creativa.Y todo, porque la experiencia social (o multifuncional) y compartida es inherente a cualquier proceso de desarrollo de software.

Ratcliffe y McNeill (2012) insisten en la interfuncionalidad de este descubrimiento colaborativo que en ocasiones no es valorada por los diseñadores cuando, con mentalidad de silo, enfatizan el punto de vista de los usuarios, descuidando poner su foco en el negocio y entender la estrecha relación de su proyecto con la tecnología (dos áreas de la empresa importantes y muy vinculadas al proyecto).

El descubrimiento continuo se consigue creando una cadencia regular de implicación del cliente en la investigación, totalmente opuesta a la forma de proceder habitual en los desarrollos de producto en cascada (del tipo big-bang) o a la de los modelos Stage-Gate. Don Reinertsen, en The Principles of Product Development Flow Second Generation Lean Product Development (2009) señala que la cadencia – el uso de un ritmo regular, predecible en un proceso – juega un papel importante en la prevención de la acumulación de variabilidad en dicho proceso. Llevado al caso del equipo de diseño UX, con reuniones cortas, predecibles y frecuentes la coordinación interna y externa (con el cliente) se reforzaría y sería muy difícil desviarse de las metas trazadas. Además, se minimizaría el tiempo entre la declaración de hipótesis, la experimentación y el feedback del cliente.

Una consecuencia del descubrimiento continuo es la política de “aquí se prueba todo”, que es lo que permite mantener la cadencia regular (Gothelf, 2013). El artefacto que el equipo haya desarrollado al día de las pruebas sea un boceto, un wireframe, un mockup o un prototipo, es lo que se presenta, en cuanto esté disponible, al cliente. Sólo hay que alinear las expectativas de este con la realidad de aquel y valorar adecuadamente la capacidad de feedback del artefacto. En el cuadro adjunto se presenta la capacidad de feedback para el diseño de los tipos de PMV más utilizados (Gothelf, 2013; Treder, 2013).

Una vez lanzado el producto la investigación cualitativa debe seguir siendo colaborativa y continua y en esto juegan un papel muy importante un amplio abanico de roles, como los contact centre managers, los customer service representatives o los call center agents, así como las feedback surveys realizadas en el propio sitio web. Respecto al grupo de los primeros cabe decir que, son una fuente de conocimiento valiosísima que es necesario explotar a base de contactos personales, de reuniones mensuales, de incluirlos en sesiones de diseño como otro más de los stakeholders, o haciendo que incorporen las hipótesis de diseño a sus contestaciones a los clientes. Los canales y técnicas utilizados en las segundas son muy variados: formularios por e-mail, enlaces a foros, descriptores de búsqueda, estadísticas de uso de páginas o A/B testing.