Reseña del libro "Lean UX. Cómo aplicar los principios Lean a la mejora de la experiencia de usuario"

Portada del libro Lean UX de Jeff Gothelf y Josh Seiden

Autor: Jeff Gothelf y Josh Seiden

Nº páginas: 164

Idioma: español (originalmente en inglés)

Formato: impreso y digital

Fecha de publicación: 2014 en español (2013 en inglés)

Podéis consultar más reseñas de libros en: "Libros y reseñas"

Lean UX es una metodología que se asienta en la colaboración multifuncional y en la gestión basada en los resultados. Supone un cambio de procesos, una nueva manera de pensar la gestión del software, centrada en las soluciones, en iterar una y otra vez perfeccionando el producto en cada nueva iteración. Es una metodología que permite dejar de hablar de funciones y documentos, para pasar a hablar de lo que funciona y lo que no funciona, y que nos permite armonizar un entorno de desarrollo ágil con el diseño UX.

Los autores se lo dedican a todos los diseñadores UX que siguen esperando la fase II, a la que relegaron parte de sus propuestas. El objetivo ahora es que las ideas más valiosas obtengan la mayoría de los recursos, mediante un método basado en la experimentación, la rápida iteración de ideas y el uso de procesos incrementales, donde el concepto de fase II ya no tiene cabida.

El libro está organizado en tres partes.

Parte I. Introducción y principios

Lean UX se asienta en tres pilares:

Design Thinking, enfoque centrado en las soluciones que, a través del trabajo colaborativo, itera una y otra vez perfeccionando el producto en cada iteración. Es una manera de trabajar que alienta la colaboración en el equipo y considera el producto desde una perspectiva holística y abarcadora.
Metodologías de desarrollo ágil de software, que tratan de entregar de forma rápida y regular software funcional a los clientes y aprovechar el aprendizaje que se obtiene de estas entregas para ajustar el proyecto. Aplican cuatro principios básicos:
- Los individuos y las interacciones son más importantes que los procesos y las herramientas.
- El software funcional es más importante que la documentación exhaustiva.
- La colaboración con los clientes es más importante que la negociación de contratos con ellos.
- La respuesta a los cambios es más importante que la planificación.
Método Lean Startup de Eric Ries que utiliza un ciclo de feedback denominado "crear-medir-aprender" y una filosofía que se aplica directamente al diseño de productos en Lean UX. Los principios que subyacen son:
- cambiar documentos por artefactos de diseño;
- colaboración funcional entre todos los implicados;
- y un modelo basado en la experimentación.

Los principios en los que se basa Lean UX son:

Equipos multifuncionales para evitar el desarrollo en cascada.
Equipos pequeños, dedicados, coubicados, para fomentar la comunicación, concentración y camaradería; pero como no siempre es posible, a lo largo del libro se dan propuestas para trabajar con equipos localizados en diferentes lugares.
Progreso igual a resultados, no a entregas de documentación.
Equipos centrados en los problemas.
Eliminación del despilfarro, es decir, de todo aquello que no contribuye a conseguir el objetivo final.
Lotes pequeños, evitar crear muchas ideas de diseño sin probar ni implementar.
Descubrimiento continuo de lo que los usuarios están haciendo con nuestro producto y por qué lo están haciendo.
GOOB (Getting Out Of the Building), porque el éxito o el fracaso de nuestros productos no depende de las decisiones del equipo de desarrollo, sino de los usuarios.
Entendimiento común, es decir, el conocimiento colectivo del equipo sobre el producto y los usuarios.
Evitar las estrellas, gurús y ninjas que rompen la cohesión del grupo y reducen la colaboración.
Exteriorización del trabajo, es decir, exponer el trabajo a compañeros, colegas y clientes.
Hacer en lugar de analizar.
Aprendizaje en lugar de crecimiento: asegurarnos de que una idea funciona antes de hacerla crecer.
Permiso para equivocarse, porque los fallos conducen al perfeccionamiento (ver vídeo Why You Need to Fail, Derek Sivers, YouTube)
Escapar de los negocios basados en entregables.

Parte II. Proceso

¿Cómo conseguir un equipo que trabaja de forma colaborativa, iterativamente y en paralelo, que reduce al mínimo los entregables, y se centra en el software funcional y en el feedback del mercado?

Proceso Lean UX. Cuatro recuadros dispuestos en círculos unidos por flechas de doble dirección. En el sentido de las agujas del reloj: 1. Declarar suposiciones 2. Crear PMV 3. Poner en marcha un experimento 4.Feedback e investigación

Proceso Lean UX. Fuente: Lean UX, Jeff Gothelf, 2013

Visión, marco y resultados

En este capítulo explica cómo reorganizar el trabajo del equipo para que se centre en obtener resultados (no en desarrollar funciones), y en el proceso de declaración de resultados.

Se sustituyen los requerimientos por suposiciones, y a partir de ellas creamos y probamos hipótesis. La herramienta básica es por tanto la declaración de hipótesis, que tiene como elementos básicos: las suposiciones, las hipótesis, los resultados, los personajes y las funciones.

Comenzamos con la declaración del problema, después examinamos las suposiciones implícitas en él y las transformamos en hipótesis. Explica cómo escribir las declaraciones de hipótesis para que capten las funciones, la audiencia y los objetivos previstos, suficientemente específicos para poder probarlos; y proporciona ejemplos y plantillas.

Por ejemplo, la creación de Personas se realiza al revés de como posiblemente te han enseñado. En vez de dedicar mucho tiempo a un trabajo de campo para su creación, se crean unos protopersonajes en pocas horas, en una sesión de brainstorming en la que participa todo el equipo. Los protopersonajes son un modelo muy esquemático, y a medida que la investigación avanza y se aprende más sobre los usuarios, se va ajustando la definición de las Personas y nuestro diseño.

Una hipótesis a bajo nivel tendría un formato como este:

Creemos que [haciendo esto/desarrollando esta función/creando esta experiencia de usuario]
para [estas/os personas/personajes]
conseguiremos [este resultado].

Sabremos que esto es correcto cuando obtengamos
[este feedback del mercado, esta medida cuantitativa, o este conocimiento cualitativo]

Diseño colaborativo

Lean UX es un proceso colaborativo que reúne a todos los implicados en un trabajo de creación continua. El diseño colaborativo, dirigido por un diseñador de UX, permite a todo el equipo:

crear juntos los conceptos del producto,
construir un entendimiento común sobre el problema y las soluciones, con menos necesidades de documentar,
decidir qué funcionalidad y elementos de la interfaz implementan mejor las funciones recogidas en las hipótesis.

Lean UX promueve la conversación como método principal de comunicación entre los miembros del equipo.

La documentación de salida de las sesiones consta normalmente de esquemas de baja fidelidad y wireframes, no muy elaborados para que pueda cambiarse de dirección fácilmente.

Se dedica parte del capítulo a una técnica, el Estudio de Diseño, que es una sesión más formal de trabajo para conseguir que un equipo multifuncional visualice de forma conjunta las soluciones potenciales a un problema de diseño.

En resumen, se reparte una hoja dividida en seis cuadros y en cada uno se indica el personaje y el punto de conflicto que se desea resolver (de las suposiciones declaradas y las hipótesis que han generado). En 5 minutos cada uno genera 6 borradores de baja fidelidad para cada una de sus combinaciones de personaje-punto de conflicto. Después de ponerse en común, cada uno elige su mejor idea y desarrolla una versión de ella más elaborada. Finalmente, todos se ponen de acuerdo en una única idea, la que tiene más probabilidades de éxito y que servirá de base para el PMV.

El capítulo termina abordando una herramienta que se considera básica, la Guía de estilo, entendida como una biblioteca de patrones, un repositorio con los elementos de la interfaz aprobados y listos para funcionar. De este modo, no debatiremos sobre dónde poner, por ejemplo, la etiqueta de un campo de formulario, puesto que esto ya está definido de antemano. El trabajo se agiliza sin tener que volver a diseñar o prototipar estos elementos, nos centramos en la interacción y la extensión del sistema visual existente.

Si se trabaja desde cero, o en un producto simple, puede crearse la Guía de estilo completa antes de comenzar el proyecto, pero en proyectos complejos y actualizaciones de productos ya desarrollados, funciona mejor crearla a medida que el equipo crea o modifica un elemento de la interfaz.

En la Guía de estilo se incluyen:

todos los elementos gráficos de diseño: paleta de colores, tipografías...
los elementos de interacción: con su aspecto en todos sus estados, y con información sobre dónde se colocan en pantalla habitualmente y cuándo se utilizan;
el vocabulario: palabras que se utilizan en la interfaz, elecciones gramaticales, lenguaje en los botones...
incluso los fragmentos de código, para que los desarrolladores tengan una ventanilla única donde obtener las directrices de diseño y el código básico.

Puede elaborarse mediante una wiki o desarrollarse una guía dinámica, es decir, un repositorio de diseño y de código front-end que no solo define el aspecto y el comportamiento del producto, sino también el lenguaje necesario y las hojas de estilo para la interfaz, de tal manera que modificando la guía se modifica el producto.

La Guía debe estar accesible para todos los miembros de la organización, debe ser un elemento vivo que se mejora y actualiza, y debe ser aplicable para que no acabe convirtiéndose en un museo.

PMV y experimentos

El PMV (Minimun Viable Product) permite, partiendo de la hipótesis priorizada en la fase anterior, comprobar las suposiciones. Creamos los mínimos elementos posibles para probarla y saber si la hipótesis es cierta y hay que perfeccionarla, o si por el contrario hay que abandonarla.

En este contexto, hay que entender el PMV como el "producto" más pequeño que se puede crear para comprobar si una hipótesis es válida. El PMV puede adoptar muchas formas, a menudo un prototipo, y de hecho, repasa los diferentes tipos de prototipos, sus ventajas e inconvenientes, y cuál elegir en cada caso.

Pero no siempre es necesario crear un prototipo para averiguar algo, ni todos los PMV tienen que ser prototipos: puede ser el envío de un email, una landing, un botón para medir cuánta gente lo pulsa y estaría interesada, etc. Al final depende de nuestra hipótesis y lo que queremos averiguar (si resuelve un problema real, si hay suficiente demanda...)

Feedback e investigación

En la metodología es fundamental que el equipo consiga el feedback necesario que le sirva de guía en el proceso de diseño. Por ello, este capítulo se centra en qué técnicas usar para conseguir este feedback de forma continua y desde una etapa temprana, para incorporarlo a las siguientes iteraciones. Se trata de probar el PMV mediante técnicas de investigación ligeras, continuas y colaborativas.

La propuesta se basa en que la investigación la realice el propio equipo mediante descubrimiento colaborativo, con la ayuda de un especialista que ayude al equipo a planificar y ejecutar las actividades, para después dar sentido a los datos obtenidos y buscar patrones.

Por ejemplo, se propone la creación de equipos de perfiles mixtos para hacer entrevistas o enseñar el prototipo; la planificación semanal de test con 3 usuarios cada jueves; aprovechar el conocimiento del servicio de atención al cliente; diferentes formas de recoger feedback en la página; estudiar los registros de búsqueda y las estadísticas de acceso; realizar test A/B, etc.

Parte III. Cómo hacerlo funcionar

En esta última parte se aborda cómo integrar Lean UX en desarrollos ágiles, explicando cómo encajar las técnicas expuestas en un proceso Scrum típico y cómo hacerlas más efectivas, para pasar después a hablar de los cambios organizativos necesarios para apoyar esta manera de trabajar.

En 2007, Desirée Sy (Adapting Usability Investigations for Agile User-centered Design (PDF, 380 KB)) proponía integrar UX en desarrollos ágiles con la técnica "Ciclo 0" o "Sprint por etapas", en el que el diseño va un sprint por delante del desarrollo.

Ciclo 0 Planificar y recopilar datos de clientes, a partir de este, en cada ciclo siguiente, por ejemplo en el ciclo 2, los desarrolladores implementan el diseño del ciclo 1, y los diseñadores UX diseñan para el ciclo 2 y recopilan datos del cliente para el ciclo 3.

Fuente: Adapting Usability Investigations for Agile User-centered Design (PDF, 380 KB), Desirée Sy, 2007, Journal of Usability Studies.

Jeff Gothelf lo considera un modelo de transición, no una solución final a la que aspirar, porque acaba generando un proceso en cascada a pequeña escala, y para que Lean UX funcione, el equipo completo debe participar en todas las actividades.

El modelo que él propone se esquematiza de la siguiente manera.

El tema abarca varios sprint de 2 semanas. En cada tema hay reunión de planificación de la iteración (presente antes de cada sprint); generación de ideas y esquemas previos (antes de cada sprint, más antes del primero); y pruebas de usabilidad y valor (dos dentro de cada sprint)

Fuente: Lean UX, Jeff Gothelf, 2013.

Añado Lean UX a la biblioteca de reseñas, porque es ya un clásico y un libro de lectura obligatoria. Aporta muchas ideas que podemos llevar a la práctica, pero también es cierto que implantar la metodología hasta sus últimas consecuencias, con todos los cambios organizativos y culturales que hay que abordar, es difícil para muchas empresas y clientes, como reconoce el autor, y puede llegar a ser en algunos de ellos incluso una utopía.