Una breve introducción a Agile, parte 1

El término Agile es cada vez más común en una gran cantidad de escenarios y contextos distintos a los del mundo de desarrollo de software donde tuvo su origen, incluido el de Experiencia de Usuario.

Contrario a lo que comúnmente se interpreta de primera instancia, Agile no se trata simplemente de cómo desarrollar productos de forma rápida. Agile busca, en esencia, transformar paradigmas y organizaciones para propiciar entornos de trabajo con personas felices, motivadas y comprometidas, logrando en consecuencia, productos exitosos y clientes satisfechos.

Contexto histórico sobre Agile

Actualmente, Scrum, Kanban y eXtreme Programming (XP) son los enfoques o frameworks más representativos de Agile; sin embargo, otros métodos relativamente emergentes que incorporan en su definición parte de los conceptos clave del Agilismo han ganado una creciente popularidad, sobre todo en el ecosistema del emprendimiento, como Lean Startup, Lean UX o Design Sprint.

Más allá de los frameworks, la verdadera naturaleza de Agile radica en la profunda transformación de la manera en la que pensamos y nos comportamos. Es decir, el Agilismo no sólo consiste en la adopción de procesos y herramientas, sino en un cambio de cultura, verdadero, profundo y significativo.

Para comprender los motivos por los cuales Agile hace un llamado al cambio de paradigmas, es necesario hacer un recuento de su origen y evolución porque, como decimos en UX, el contexto lo es todo.

El Modelo en Cascada y los antecedentes de Agile

Explicar qué es Agile implica ineludiblemente hablar primero de su némesis: el Modelo en Cascada. De la misma forma en que no es posible explicar La Fuerza sin el Lado Oscuro, para entender el surgimiento de Agile, es importante comprender las razones de su origen, aquello a lo que trataba de oponerse.

El Modelo Secuencial de Procesos o Modelo en Cascada (Waterfall Model) es un modelo metodológico de la industria de desarrollo de software que surgió en la década de los 70. Sin entrar demasiado en detalle (porque para eso está Wikipedia) el Modelo en Cascada propone una serie de pasos, rigurosamente en secuencia, para el desarrollo de software:

  • Especificación de requerimientos
  • Diseño
  • Implementación
  • Verificación
  • Mantenimiento
Modelo en Cascada
Modelo en Cascada

 

Lo que vale la pena destacar del Modelo en Cascada es que, de alguna u otra forma, surgió como una herencia del pensamiento Taylorista, que tuvo su máximo esplendor durante la Revolución Industrial, y que definía a los procesos como una división de tareas bajo un ambiente rígido. En el Taylorismo, las personas no tenían participación ni control en los procesos, “todo lo que queremos de ellos (los obreros) es que obedezcan las órdenes que les damos, que hagan lo que les decimos y que lo hagan rápido“, decía Frederick Taylor en 1906.

Recreen en su mente la mítica escena de Charles Chaplin en Tiempos Modernos. Eso es el Taylorismo. Reemplacen la cadena de montaje por líneas de código. Eso es el Modelo en Cascada.

Escena del largometraje Tiempos Modernos (1936).
Escena del largometraje Tiempos Modernos (1936).

La razón por la que la naciente industria del software de la década de 1970 consideró que era buena idea adoptar un modelo secuencial, rígido y que restringía tanto la libertad y creatividad de las personas sigue siendo un misterio y quizá el mundo nunca lo sabrá.

Es tan controversial el tema sobre cómo fue posible que el Modelo en Cascada se haya convertido en un estándar de la industria del software, que existen varios mitos alrededor, uno de ellas señala que desde su origen, el modelo fue malinterpretado y que su autor, Winston Royce, en realidad quiso decir que el modelo era una mala idea y que no era recomendable implementarlo pues “invitaba al fracaso”. No es broma. Incluso el Departamento de Defensa de los Estados Unidos, en 1985,  tuvo esa “interpretación” incorrecta y estandarizó su propio proceso para el desarrollo de software basado en el modelo de Royce y como suele ocurrir con casi todo, el resto del mundo siguió el mismo estándar.

Las circunstancias del contexto también pudieron influir notablemente en la estandarización del Modelo de Cascada, piensen en la alocada década de los 70: la tecnología era accesible sólo para unos pocos privilegiados; apenas eran los albores de Internet; Steve Jobs y Bill Gates eran un par de jóvenes que iniciaban la construcción de los imperios de Apple y Microsoft, respectivamente. Si lo vemos en perspectiva, el Modelo en Cascada se convirtió en el modelo más utilizado simplemente porque en ese momento se concebía al software como algo tan complicado, grande y robusto que sólo era posible producirlo bajo un proceso riguroso y detallado.

Uso de la tecnología a principios de la década de los 70.
Uso de la tecnología a principios de la década de los 70.

Al paso de los años, el mundo empezó a cambiar drásticamente gracias a una vertiginosa revolución de las Tecnologías de la Información. La tecnología llegó a la vida cotidiana y el cliente empezó a convertirse paulatinamente en el centro del universo en el desarrollo de productos y servicios.

Publicidad del lanzamiento de Apple II (1977). La tecnología llega a los hogares.
Publicidad del lanzamiento de Apple II (1977). La tecnología llega a los hogares.

La industria del software tuvo que empezar a adaptarse al nuevo escenario y los problemas del Modelo en Cascada comenzaron a emerger:

  • Poco o nulo involucramiento del cliente a lo largo del proceso.
  • Limitación de la participación activa de las personas responsables del desarrollo.
  • Incapacidad de responder satisfactoriamente ante cambios de negocio.
  • Documentación excesiva del proceso.
  • Tiempos demasiado largos de producción.
  • Recuperación tardía y costosa ante errores.

La caja de Pandora fue abierta.

Los orígenes de Agile

El Movimiento Agile surgió como una reacción de hartazgo a todo lo que significaba el Modelo en Cascada.

Para muchos expertos, el año 1994 representa el punto de quiebre en la historia del Agilismo, cuando todos los problemas que el Modelo en Cascada venía arrastrando por más de dos décadas quedan exhibidos en CHAOS Report, un estudio que reveló una cifra contundente e irrefutable:

más del 80% de los proyectos de software se entregaban con sobrecostos, en forma tardía, sin cumplir las expectativas de los clientes o incluso eran cancelados antes de concluirse.

La industria del software estaba en crisis, empezaron a surgir o a cobrar notoriedad métodos alternativos al Modelo en Cascada como Scrum, eXtreme Programming (XP) y Lean Software Development, por citar algunos. La nueva “sombrilla” de métodos empezaron a ser identificados con el nombre de Metodologías Livianas (Lightweight Methodologies). Comenzaba así la versión en el mundo del software de Civil War, o eras #teamwaterfall o eras #teamagile.

Hay que abrir un breve paréntesis en esta línea del tiempo. Aunque muchos métodos relacionados con Agile empezaron a ser cada vez más populares a partir de la década de los 90, no significa que hayan sido creados simultáneamente, algunos conceptos clave surgieron desde mucho tiempo atrás:

El siguiente hito en la historia del Agilismo llegó en el 2001 cuando un grupo de profesionales y entusiastas de los métodos livianos se reunieron “en lo alto de una montaña” (como suele contar Mike Beedle) para discutir cómo la industria del desarrollo de software debería hacer frente al nuevo contexto, cómo responder de mejor forma a los cambios que surgían por intereses de negocio y cómo consolidar una alternativa los procesos tradicionales de desarrollo de software caracterizados por la rigidez de su proceso. El Manifiesto Ágil vió la luz.

El Manifiesto Ágil

Estamos descubriendo mejores formas de desarrollar software…

Así inicia el Manifiesto Ágil, el documento que representa la declaratoria de principios de todo lo que significa el Agilismo.

Cuatro valores y doce principios. Es todo. Por más de 15 años, cada línea escrita en el Manifiesto Ágil ha permanecido intacta. Señal de su vigencia y pertinencia.

Valores:

  • Individuos e interacciones sobre procesos y herramientas.
  • Software funcionando sobre documentación extensiva.
  • Colaboración con el cliente sobre negociación contractual.
  • Respuesta ante el cambio sobre seguir un plan.

Principios:

  1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.
  2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
  3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
  4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
  5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
  6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.
  7. El software funcionando es la medida principal de progreso.
  8. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
  9. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
  10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
  11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
  12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

Waterfall vs. Agile

Lo que siguió después de la aparición del Manifiesto Ágil fue una disputa cada vez más frontal por la supremacía en la industria de desarrollo de software entre Waterfall y Agile; de manera simultánea, el mundo seguía cambiando, llegó el mundo de los dispositivos móviles, de las apps y startups.

En la versión 2012 del CHAOS Report (ahora llamado CHAOS Manifesto) se publicó una conclusión simbólica sobre la batalla entre Waterfall y Agile:

El proceso ágil es el remedio universal para el fracaso en los proyectos de desarrollo de software. Las aplicaciones de software desarrolladas a través del proceso ágil tienen tres veces la tasa de éxito del método en cascada tradicional y un porcentaje mucho menor de demoras y sobrecostos. El software debería ser construido en pequeños pasos iterativos, con equipos pequeños y enfocados”.

Parecía que la batalla tenía un ganador.

Ser Agile vs Hacer Agile

Ante el éxito de los métodos ágiles en la industria del software, su popularidad y adopción traspasaron fronteras. El ecosistema de emprendimiento y otras industrias distintas a las del desarrollo de software empezaron también a abrazar las prácticas ágiles. Hacían lo correcto, aunque por las razones incorrectas.

La promesa de ser el “remedio para el fracasso en los proyectos” comenzó a ser una carga muy pesada para el Agilismo y para lo que, insisto, realmente significa.

En 2015, otra vez el CHAOS Manifesto dió a conocer una cifra reveladora:

61% de los proyectos ágiles, son ágiles solamente en el nombre.

El Agilismo verdadero es orgánico, emerge, fluye; simplemente ocurre o perece en el intento. Es independiente de cualquier práctica dogmática, por encima incluso, de un “dogma ágil”, por contradictorio que esto parezca. Individuos e interacciones sobre procesos y herramientas. El origen de todos los males de la práctica incorrecta del Agilismo radica en la inadecuada comprensión del Manifiesto Ágil y todo lo que conlleva.

Agile no es una metodología. No es una colección de procesos y herramientas. Agile es un mindset, una forma de pensar y actuar distinta para encontrar mejores formas de hacer las cosas a través del empirismo y el aprendizaje.

La verdadera promesa de Agile

Quiero concluir con una cita del libro Por un Scrum Popular: Notas para una Revolución Agile, de Tobias Mayer y traducido al español por Alan Cyment:

“Pinten en el aire una oficina donde reina la risa y la pasión. Donde todos, inspirados por un espíritu de camaradería, habitados por un clima de entusiasmo, propósito común y esperanza, trabajan en un ambiente donde se fomenta la escucha activa, la comunicación abierta y la colaboración a mansalva.

Estoy convencido de que se puede convertir esta imagen en realidad usando un mecanismo simple y conocido, que les permitirá llegar desde su crudo presente hasta ese sitio donde les gustaría estar. Y no, ese mecanismo no se llama Scrum.

No hay framework, proceso o metodología que por sí solo permita alcanzar esta visión. Hay una sola persona que puede hacer realidad esta visión. Ese alguien eres tú”.

Espero que este llamado, los haga pensar en abrazar el Agilismo por las razones correctas.

Diseñador de Experiencia de Usuario. Scrum Master Certified. Fotógrafo. Ha participado en proyectos vinculados a HCI, usabilidad y UX en el ámbito académico, empresarial y gobierno desde 2007. Es parte del equipo de UX Nights.

Lean UX, parte 6

Lean UX es, en esencia, una manera distinta de pensar, una nueva mentalidad para el diseño y desarrollo de productos. Involucra tres cosas fundamentales: un cambio de procesos, un cambio en la forma de enfrentar el trabajo de diseño y una transformación en la forma de gestionar los proyectos.

En esta sexta y última parte, se describe la fase de feedback e investigación que culmina el ciclo de Lean UX.

Lean UX, fase 4
Lean UX, fase 4

La investigación es un proceso continuo y colaborativo. Es continuo porque se lleva a cabo a lo largo de cada ciclo de iteración del producto. Es colaborativo debido a que la responsabilidad de esta labor es de todo el equipo y se comparte entre todos.

Descubrimiento colaborativo

El descubrimiento colaborativo es un enfoque que permite sacar al equipo de la oficina (la famosa frase “get out of the building!“) para estar en contacto directo con clientes potenciales y aprender de ellos. De esta forma, todo el equipo ejecuta experimentos y todos los involucrados aportan en la recopilación de información sobre el comportamiento de los usuarios.

Para llevar a la práctica el enfoque de descubrimiento colaborativo, Jeff Gothelf sugiere adoptar las siguientes acciones:

  • Todo el equipo trabaja y decide en conjunto sobre la declaración de hipótesis y construcción del MVP.
  • Todo el equipo define y participa en la ejecución de los experimentos divididos por parejas o pequeños sub grupos.

Descubrimiento continuo

El ciclo Lean UX debe ejecutarse de forma continua y constante. Es importante que el tiempo que transcurre entre la creación de las hipótesis, el diseño de los experimentos y el feedback de los usuarios se minimice lo más posible.

Para ayudar a que el feedback e investigación sea continuo se recomienda lo siguiente:

  • Establecer un calendario permanente de actividades.
  • Simplificar al máximo el protocolo y entorno de experimentación (discount usability engineering en su máximo esplendor, Nielsen dice al respecto: “It might be hard to appreciate today when many people talk about ‘Lean UX’, but these ideas were heresy 20 years ago).
  • Simplifica el reclutamiento de usuarios para participar en la experimentación.
  • Todo el equipo participando todo el tiempo.
  • Reunir al equipo después de las sesiones de experimentación tan pronto como sea posible para revisar en conjunto los resultados y tomar decisiones sobre la siguiente versión del MVP a trabajar.

Feedback obtenido

A medida que el equipo va obteniendo feedback de diversas fuentes, a lo largo de varios experimentos, es común encontrar momentos en los que se generen resultados, aparentemente, contradictorios. A medida que se avanza en la recopilación de feedback, Jeff recomienda realizar las siguientes prácticas:

  • Identificar patrones.
  • Apartar valores atípicos.
  • Corroborar datos con otras fuentes.

Es importante señalar que el feedback obtenido de un solo experimento nunca es concluyente. La investigación en Lean UX apuesta por la continuidad. Como dijo Kaliman: “serenidad y paciencia“.

Técnicas de monitorización para el descubrimiento colaborativo y continuo

El proceso de  feedback e investigación no sólo proviene de la ejecución de experimentos. El equipo debe asumir la cultura de obtener aprendizaje, colaborativo y continuo, de todas las fuentes posibles. Algunas de las fuentes de feedback pueden ser:

  • Servicio de atención al cliente.
  • Encuestas permanentes.
  • Analítica web.
  • Pruebas A/B.

Todas estas técnicas, además de la ejecución de experimentos, forman en su conjunto la base del ciclo Lean UX. El objetivo del equipo será recorrer este ciclo tantas veces como sea posible, para perfeccionar el concepto del producto en cada iteración.

***

Esta es, en síntesis, la descripción de Lean UX bajo la perspectiva de Jeff Gothelf. Los conceptos básicos están ahí, la misión, si decidimos aceptarla, es llevar la adopción de Lean UX a nuestras organizaciones, tarea nada sencilla pero que promete obtener resultados significativos.

El libro Lean UX fue publicado en 2010, han transcurrido ya seis años y muchas cosas han cambiado desde entonces. ¿Qué significa actualmente Lean UX? El mismo Jeff responde:

It means that we build cross-functional teams, product, design, and engineering who have the customer at their core and making the customer successful as their mission.

It’s lightweight, it’s iterative, it’s low risk. And the value of the work that you’re delivering increases based on evidence that you’re collecting from those low-risk experiments and tests that you’re running, so that you’re only making further investments in a particular design direction or in the product direction, if you’re getting a signal from the market that says, this is something that we should be working on, and we’re implementing it the right way.

La siguiente pregunta podría ser: ¿qué sigue ahora, cuál es la evolución de Lean UX? Para obtener la respuesta tendremos que esperar un poco más, hasta que Jeff publique su nuevo libro: Sense and Respond: How Successful Organizations Listen to Customers and Create New Products Continuously que verá la luz en febrero de 2017.

De cualquier forma, hay mucho por aprender y practicar todavía. Adoptar Lean UX puede tomar un tiempo relativamente considerable, ¿es necesario conducir todo el ciclo e incorporarlo desde el comienzo de un proyecto? Como dicen los conocedores: depende.

Para seguir profundizando sobre la filosofía Lean les recomiendo parte de la colección The Lean Series:

El mejor consejo es iniciar la adopción de Lean UX como un cambio de mentalidad en cada uno de nosotros; más allá de las fases y técnicas específicas que definen el método, Lean UX representa un modo distinto de pensar respecto a los procesos, un modo distinto de enfrentar las actividades de diseño y una transformación en la forma de gestionar nuestros proyectos.

Hagamos una transformación de nosotros mismos, después de nuestro equipo de trabajo y poco a poco llegaremos a toda la organización. Esa es la misión de un agente del cambio.

Diseñador de Experiencia de Usuario. Scrum Master Certified. Fotógrafo. Ha participado en proyectos vinculados a HCI, usabilidad y UX en el ámbito académico, empresarial y gobierno desde 2007. Es parte del equipo de UX Nights.

El rol del Sprint Master en un Design Sprint

Design Sprint es una metodología de trabajo para resolver problemas de diseño en una semana, y utiliza elementos de metodologías ágiles y de design thinking.

Design Sprint es un modelo de colaboración que funciona para empresas o equipos de cualquier tamaño y para resolver casi cualquier problema en unos pocos días, en buena parte porque tiene límites claros sobre el uso del tiempo y los recursos que se utilizan durante el proceso. El responsable de establecer esos límites es una persona en el equipo que tiene el rol del sprint master.

Sprint masterEl sprint master es la persona que lleva el liderazgo de la sesión, y es quien ayuda a definir el reto de diseño en el sprint, define al equipo de trabajo y los ayuda a pasar por todas las etapas del proceso.

El rol de sprint master requiere entendimiento y experiencia profunda en los métodos de diseño centrado en el usuario, desarrollo de estrategias, facilitación de procesos y negociación (pero no es necesario ser un unicornio de UX).

Desarrollar estas habilidades toma tiempo y práctica, pero este rol hace una diferencia crítica al tratar de alinear al equipo para obtener resultados excepcionales.

Normalmente un sprint master es un arquitecto o especialista en experiencia de usuario: una persona con experiencia en la gestión de equipos de trabajo que tiene un conocimiento profundo en el diseño de procesos y que no teme retar a su equipo a colaborar para producir resultados en poco tiempo.

El trabajo del sprint master

El rol del sprint master es muy similar a la del scrum master en Scrum, en el sentido de que su rol en el proceso es de maestro-esclavo; es decir, tiene el control del proceso pero solo puede usar ese control para ayudar al equipo a trabajar.

La sesión de design sprint es algo que también se debe diseñar, y aquí es donde el trabajo del sprint master comienza.

Flujo de trabajo del sprint master en una sesión de design sprint
Flujo de trabajo del sprint master en una sesión de design sprint

Un buen sprint master sigue un flujo de tareas bien definido antes, durante y después del sprint. Su éxito depende de su habilidad para guiar al equipo, hacer gestión del proyecto y entender los métodos de UX que funcionan en periodos de tiempo muy cortos. Este trabajo de planeación toma tiempo, por lo general un día de preparación por cada día de sprint.

Antes del design sprint

La tarea más importante antes de comenzar un design sprint es articular el reto de diseño significativo sobre el que se centrará el trabajo de las sesiones. Un buen reto de diseño debe ser breve, inspirador y debe especificar a los usuarios objetivo y los entregables al final del sprint.

El sprint master debe seleccionar e invitar a las personas que participarán en el equipo, agendar las sesiones con expertos y las entrevistas con usuarios para las fases de “entender” y “validar” del sprint.

Finalmente, el sprint master debe preparar el material de presentación de las sesiones, reservar el espacio de trabajo, consiguir el material de trabajo, los refrigerios, bebidas y en general, asegurárse de que el proceso fluya sin problemas o interrupciones.

Durante el design sprint

Cuando el sprint comienza, el sprint master asume el rol de facilitador y anuncia la agenda y los ejercicios, lleva control del tiempo e invita a todos a participar. Si el equipo necesita cambiar el enfoque del plan original, el sprint master se encarga de que el equipo tome decisiones con rapidez minimizando las discusiones y de que cubran sus objetivos dentro de los límites de tiempo.

Durante el proceso, el sprint master es responsable de Tomar Notas Todo el Tiempo (ABC: Always Be Capturing) en un pizarrón o rotafolio, usando post-its o en una bitácora.

Después del design sprint

Las sesiones de desig sprint normalmente terminan con mucha energía y emoción, cuando el equipo logra crear una idea tangible en unos pocos días. Un buen sprint master mantiene esa energía al crear un plan de seguimiento, compartir los resultados del proceso y solicitando retroalimentación de los participantes para mejorar las sesiones en el futuro.

Consultor en experiencia de usuario, developer, conferencista, escritor y emprendedor. Trabaja en Tesseract Space, es Google Expert en UX/UI, Microsoft Regional Director y co-fundador de UX Nights.

Diseñando con Design Sprint

Design Sprint es un proceso de cinco días que sirve para resolver las preguntas críticas de un producto utilizando diseño, prototipado y la evaluación de ideas con usuarios finales.

Este proceso fue desarrollado en GV (antes Google Ventures) por Jake Knapp y mejorado por Braden KowitzMichael MargolisJohn Zeratsky y Daniel Burka como una colección de buenas prácticas de design thinking, estrategia de negocios, innovación, análisis de comportamiento y otras, empaquetadas en un proceso que cualquier equipo puede utilizar. En el Vol. XVII de UX Nights en la Cd. México había hablado de este tema, y me pareció que valía la pena retomarlo.

Al trabajar en un design sprint es posible recortar el ciclo de análisis e investigación a unos cuantos días, y el equipo de trabajo puede entender más rápidamente si vale la pena trabajar en una idea antes de comenzar a desarrollar una versión mínima de producto.

Aprender antes de construirDesign sprint le ayuda a un equipo de trabajo a obtener información clara por medio de la validación con prototipos para ver las reacciones de sus futuros usuarios antes de hacer compromisos que costarán tiempo y recursos.

Las sesiones de design sprint son colaborativas e incluyentes, y se anima a invitar a estas sesiones a tantos perfiles como sea posible, incluyendo diseñadores, programadores, expertos en negocio o en procesos. Normalmente hay un facilitador –el sprintmaster– que ayuda a dirigir el proceso y se asegura que el equipo no se desvíe de su objetivo.

Estas son las etapas típicas en la ejecución de un Design Sprint:

Proceso de Design Sprint

  • El día lunes se crea el camino a seguir en los siguientes días por medio de discusiones estructuradas. Al principio, se define un objetivo de largo plazo, y se crea un mapa del reto. En este día se invitan a expertos para que compartan su conocimiento sobre el problema con el equipo. Al final, se elige un objetivo: una parte ambiciosa pero manejable del problema que se puede resolver en una semana.
  • El día martes el equipo se enfocará en buscar soluciones. Después de revisar ideas ya existentes se comienzan a mezclar y a mejorar por medio de bocetos en papel, enfatizando el pensamiento crítico sobre la estética. En este día también se definen los perfiles de los usuarios que probarán la solución al final de la semana.
  • El día miércoles se revisan y critican las propuestas de solución desarrolladas el día anterior y el equipo decide cuáles resuelven mejor el objetivo a largo plazo. Después de elegir, se toman los bocetos ganadores y se combinan para crear un storyboard: un plan paso a paso para la construcción de un prototipo.
  • El día jueves el equipo trabajará para convertir el storyboard del día anterior en un prototipo, una versión simple y rápida de la solución que simule lo que los usuarios verán al final y que se puede construir en un día. También se prepararán los guiones para entrevistas y revisión del prototipo para el día siguiente.
  • El día viernes se realizan entrevistas con usuarios de carne y hueso para que el equipo pueda aprender de ellos al verlos utilizar el prototipo que se construyó el día anterior. Esta prueba es la que hace que el sprint valga la pena, porque al final del día el equipo aprenderá qué tal útil es su propuesta de solución y que hacer después: explorar otra solución, iterar sobre la propuesta actual o enviarla a producción.

Vale la pena aclarar que aunque design sprint toma prestados algunos conceptos de metodologías ágiles, no es sustituto ni equivalente de un sprint de scrum, ya que el proceso, los roles y los entregables son muy diferentes. Design sprint también utiliza conceptos de design thinking pero con límites claros sobre el tiempo y los recursos que se utilizarán en el proceso para mantenerlo ágil y enfocado.

Lo más importante de design sprint es que desde el principio ayuda al equipo a trabajar sobre las necesidades de sus usuarios, además de que enfoca el esfuerzo colectivo en crear cosas tangibles al mismo tiempo que reduce las discusiones.

Libro de SprintUna buena referencia sobre cómo ejecutar un design sprint es el libro que el equipo de GV publicó hace unos meses, titulado “Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days” y en el que se evaluan casos reales de implementación de la metodología, como Slack, Savioke, Blue Bottle Cafe, Foundation Medicine o FitStar, entre otros, además de que sirve como una guía hora por hora para el aspirante a sprintmaster.

Design sprint es una metodología de trabajo muy flexible que se puede aplicar al diseño o mejora de cualquier producto, e incluso se puede utilizar para hacer solo investigación de usuarios (research sprint), diseñar la visión de un nuevo negocio (vision sprint), una campaña de mercadotecnia (communication sprint) o la migración de un sistema a nuevas plataformas (new form factors sprint).

En el sitio de GV hay varios artículos (en inglés) sobre recomendaciones y técnicas para ejecutar design sprints con diferentes enfoques. El sitio de Google Developers tiene disponibles para descarga un par de ebooks para realizar sesiones de design sprint para diseñadores y programadores.

Consultor en experiencia de usuario, developer, conferencista, escritor y emprendedor. Trabaja en Tesseract Space, es Google Expert en UX/UI, Microsoft Regional Director y co-fundador de UX Nights.

Lean UX, parte 5

Lean UX es, en esencia, una manera distinta de pensar, una nueva mentalidad para el diseño y desarrollo de productos. Involucra tres cosas fundamentales: un cambio de procesos, un cambio en la forma de enfrentar el trabajo de diseño y una transformación en la forma de gestionar los proyectos.

En esta quinta parte, se describe la fase de ejecución de un experimento que permite validar una hipótesis a través de un Producto Mínimo Viable.

Lean UX, paso 3, ejecutar un experimento.
Lean UX, paso 3, ejecutar un experimento.

Introducción

En Lean UX el proceso de validación comienza con la ejecución de un experimento, probando con usuarios el MVP para comprobar las hipótesis.

Cuando el MVP es un prototipo, el proceso de ejecución del experimento incluye mostrar el prototipo desarrollado ante directivos, product owners y stakeholders del producto. Para ello, es recomendable que el equipo cuente con un día especial para realizar esta actividad de manera periódica (demo day). Cuanto más se exponga y comparta el prototipo con personas externas al equipo, más aprendizaje se obtiene. Obviamente, el mayor proceso de aprendizaje y conocimiento ocurre cuando el prototipo se muestra o prueba con clientes potenciales.

Ejecución de un experimento con prototipos

Un experimento puede ser tan simple como dejar que los usuarios utilicen y exploren libremente el prototipo para obtener el mayor feedback posible o bien, realizar un protocolo más formal a través de una prueba de usabilidad, siempre y cuando, el tipo de validación de hipótesis así lo requiera.

En una prueba de usabilidad, los usuarios tratan de realizar tareas críticas (aquellas que validan nuestra hipótesis) con el prototipo, mientras un grupo de observadores miran, escuchan y toman notas para recopilar feedback.

Dependiendo de la etapa del proyecto en que se realice un experimento de este tipo, el feedback esperado puede variar, pero por lo general se pretende:

  • Identificar problemas de usabilidad en el producto (prototipo).
  • Reunir información cuantitativa y cualitativa del desempeño de los usuarios con el producto (eficacia y eficiencia).
  • Determinar la satisfacción de los usuarios con el uso del producto.

Si se experimenta con un prototipo de lápiz y papel (paper prototyping) o si el experimento ocurre en etapas iniciales, el número de usuarios suficientes para validar la hipótesis puede ser entre 4 y 6, por grupo de usuario (protopersona).

Método: prueba de usabilidad

¿Quiénes participan?

  • Facilitador
    • Persona que conduce la prueba y orienta al usuario en las actividades a realizar durante la prueba.
  • Observador(es)
    • Persona que toma notas del comportamiento del usuario durante la prueba.
  • Wizard of Oz
    • Si la prueba se realiza con un prototipo de lápiz y papel, es necesario contar con un mago, la persona quien simulará la interacción en el prototipo.
  • Usuarios
    • Personas que cumplan con el perfil deseado (protopersonas)

Antes de empezar

  • Prototipo.

Ejecución

Una típica prueba de usabilidad puede describirse de la siguiente forma:

  1. Un facilitador recibe al usuario.
  2. El usuario toma su lugar en el espacio destinado para realizar la prueba, que debe corresponder al contexto de uso del producto.
  3. El facilitador explica al usuario el objetivo general de la prueba de usabilidad.
  4. El facilitador realiza un breve cuestionario para validar que el perfil de usuario es el correcto (protopersona), también sirve para romper el hielo.
  5. El facilitador le explica al usuario la técnica “Think Aloud Protocol” para que exprese todo lo que está pensando, en todo momento, en voz alta.
  6. El facilitador pregunta al usuario si tiene alguna pregunta.
  7. El facilitador le pide al usuario comenzar la prueba.
  8. El facilitador da lectura al primer escenario y la primera tarea, el usuario inicia la actividad.
  9. El usuario dice lo que piensa, mientras el facilitador y observador toman notas.
  10. La prueba continúa, escenario por escenario, tarea por tarea, hasta lograr la meta esperada en el tiempo determinado para la prueba.
  11. Una vez lograda la meta, o el tiempo, el facilitador da por terminada la prueba.
  12. El facilitador agradece al usuario su participación.

Como puede apreciarse, para realizar una prueba de usabilidad, además del prototipo, es imprescindible definir de manera previa tres aspectos:

  • Perfil del usuario
    • Es la representación o arquetipo de un usuario específico, en Lean UX, este arquetipo está definido por la protopersona.
  • Contexto de uso
    • Es el espacio y situación específica del uso del producto. Un escenario es una representación narrativa de un contexto de uso, permite situar a un usuario específico (protopersona) en interacción con el producto pretendiendo lograr una meta específica en un entorno específico.
  • Metas
    • Una meta es un objetivo final deseado por un usuario en un tiempo finito.
    • Una tarea es la realización de un conjunto de pasos necesarios para lograr una meta.
    • Existen tres clases de metas:
      • Metas finales: Lo que el usuario quiere hacer
      • Metas de experiencia: Lo que el usuario quiere sentir
      • Metas de vida: Lo que el usuario quiere ser

Una vez definidos el perfil de usuario, el contexto de uso y la meta a lograr, la prueba de usabilidad puede llevarse a cabo.

Recomendaciones para conducir una prueba de usabilidad

  • Se evalúa el producto, no al usuario.
  • Tratar a los usuarios con respeto.
  • Hacer sentir cómodos a los usuarios.
  • Generar confianza.
  • Recordar al usuario que exprese sus pensamientos en voz alta.
  • Ser neutral, no expresar opiniones positivas ni negativas.
  • No intervenir durante la prueba, en caso de asistencia al usuario, interrumpir el escenario y continuar a la siguiente tarea.
  • Tomar buenas notas.
  • Confiar más en lo que hace el usuario, que en lo que dice.

Recomendaciones para tomar notas

En Lean UX, en lugar de videograbar la sesión para posterior a las pruebas realizar una revisión minuciosa, como ocurre en pruebas convencionales, se recomienda adoptar el formato Lean User Research, donde el observador realiza durante la prueba un rápido registro de los aspectos críticos a considerar. El formato del observador es una hoja dividida en cuadrantes con los siguientes campos:

Lean User Research
Lean User Research

Stoppers

Se refiere a los problemas y dudas que tuvieron los participantes al estar realizando alguna tarea.

Values

Se refiere a los puntos que los usuarios consideraron que les aportó mayor valor agregado al momento de realizar las tareas.

Feedback

Se refiere a las opiniones y expresiones textuales que emitieron los usuarios a lo largo de las actividades realizadas.

Recommendations

Se refiere a las sugerencias del moderador desde la perspectiva del usuario para corregir los problemas de usabilidad y mejorar la experiencia de las personas.

Las pruebas de usabilidad deben ser una actividad de todo el equipo. Si todos observan la prueba, toman notas y absorben el feedback de los usuarios, no será necesario realizar largas sesiones de trabajo posteriores. Adicionalmente, trabajando de esta forma, el equipo podrá aprender rápidamente cuáles son las funcionalidades que se están trabajando correctamente y cuáles no. “No hay nada mejor que contemplar a los usuarios probando el [producto] en el que uno ha trabajado para que se te bajen los humos y te motives para hacerlo mejor”, afirma Jeff con toda razón.

Pruebas de usabilidad automatizadas

Además de realizar pruebas de usabilidad presenciales, es posible recurrir a pruebas online y pruebas automatizadas. Algunos tipos de este tipo de pruebas son:

  • First click testing
  • Five second testing
  • Tree testing
  • Eye tracking

Ejecución de experimentos con un MVP que no es un prototipo

Algunos ejemplos de experimentos con MVP que no son un prototipo pueden incluir:

  • Correo electrónico
    • Enviar un correo electrónico a una lista de clientes potenciales con la información de descripción del producto, oferta simulada, etc.
    • El feedback esperado puede medirse a través del índice de apertura de correo, los click-throughs o los de finalización de tarea.
  • Google Ad Words
    • Comprar un anuncio en Google Ad Words con la mayor segmentación posible.
    • El feedback a obtener incluye desde monitorear las búsquedas de los usuarios en Google, para conocer el tipo de lenguaje que le interesa a la audiencia, hasta los índices de click-throughs para validar el interés de los clientes potenciales en las palabras y mensajes que se incluyan en el anuncio.
  • Landing Page
    • Lanzar un Landing Page con un call to action obvio y específico, como “registro”, “compartir” o mejor aún “comprar ahora”.
    • El feedback consistirá en el número de conversiones logradas.
  • El botón a ninguna parte
    • En un Landing Page o en el sitio web del producto puede incluirse un botón que haga mención a la nueva funcionalidad del producto, no tiene que tener un enlace específico, ahí el truco.
    • El feedback obtenido es claro, cada vez que hay un clic en el botón, revela que hay un cliente potencial interesado en esa funcionalidad. Por obvias razones, hay que tener precaución con este tipo de experimentos.

Las opciones no se restringen a las opciones mostradas, la lista puede ser mucho mayor. Para decidir qué tipo de experimento es el más adecuado, es importante recordar la esencia de Lean UX: diseñar sólo lo necesario, salir a la luz lo más pronto posible, interactuar con usuarios reales y obtener el mayor feedback posible.

***

En la siguiente entrada, se describirá la cuarta fase del ciclo Lean UX, feedback e investigación.

Diseñador de Experiencia de Usuario. Scrum Master Certified. Fotógrafo. Ha participado en proyectos vinculados a HCI, usabilidad y UX en el ámbito académico, empresarial y gobierno desde 2007. Es parte del equipo de UX Nights.

Lean UX, parte 4

Lean UX es, en esencia, una manera distinta de pensar, una nueva mentalidad para el diseño y desarrollo de productos. Involucra tres cosas fundamentales: un cambio de procesos, un cambio en la forma de enfrentar el trabajo de diseño y una transformación en la forma de gestionar los proyectos.

En esta cuarta parte, se describe la fase de creación de un Producto Mínimo Viable que inicia con la ejecución de un Estudio de Diseño Colaborativo.

Lean UX, fase 2, creación de un MVP.
Lean UX, fase 2, creación de un MVP.

Estudio de Diseño Colaborativo

Lean UX es un proceso colaborativo al permitir que todos los miembros del equipo opinen y participen en el proyecto en sus etapas iniciales.

La colaboración es una de las formas más efectivas para que los equipos estén alineados con la directriz de diseño. La premisa básica es que mientras más conocimiento se comparte y se visualiza, menos necesidad habrá de documentar cada etapa del trabajo para poder avanzar a la siguiente.

Otro pilar en el que se sustenta el diseño colaborativo es la conversación, pues permite aportar conocimiento al proyecto y representa un catalizador en la integración y unión del equipo.

Una típica sesión de diseño colaborativo involucra la participación de todo el equipo ideando y bosquejando propuestas de solución, todas las ideas se presentan y comparten, generando discusión alrededor de ellas hasta llegar a un consenso común sobre la opción con más probabilidad de éxito.

Método: Estudio de diseño

Es una sesión informal donde todo el equipo se reúne para generar soluciones potenciales a un problema de diseño.  

¿Quiénes participan?

  • Todo el equipo. Todas las disciplinas involucradas.

Antes de empezar

  • Declaración de supuestos.

Ejecución

  • Definición del problema y sus restricciones.
  • Generación de ideas individuales (divergencia).
  • Presentación y discusión.
  • Iteración
  • Generación de ideas de equipo (convergencia)

Plantillas

  • Templates para sketching de navegadores, dispositivos móviles.

Descripción de pasos

Lean UX, Estudio de diseño
Estudio de diseño. Fuente imagen: https://paris-en.numa.co/var/sise/storage/ckeditor/images/DSCF5945(1).JPG

Definición del problema y restricciones

El tiempo estimado por iteración es de 15 a 30 minutos.

En este paso se revisa la declaración de supuestos, hipótesis, protopersonas y resultados a través de una discusión del equipo con el soporte visual de todo lo trabajado hasta ahora.

Generación de ideas individuales

El tiempo estimado por iteración es de 10 minutos.

Cada miembro del equipo trabaja de forma individual bosquejando ideas que puedan aportar a la solución. Lo ideal es tener un máximo de seis ideas por participante.

Presentación y críticas

El tiempo estimado por iteración es de 3 a 5 minutos por persona.

Cada participante tendrá un tiempo finito para presentar y argumentar su idea, a quién va dirigida (protopersona) y qué función resuelve (hipótesis). El resto del equipo debe realizar una crítica constructiva a la propuesta presentada.

Iteración y perfeccionamiento

El tiempo estimado por iteración es de 5 a 10 minutos.

Después de escuchar las propuestas y recibir críticas, todos los miembros del equipo deben volver a trabajar de forma individual, cada participante elegirá la opción más factible acorde a las críticas recibidas y realizará una nueva versión, tomando en consideración las observaciones del resto de sus compañeros.

Todos deben presentar nuevamente sus ideas.

Trabajo en equipo

El tiempo estimado es de 45 minutos.

El equipo debe ponerse de acuerdo en un solo concepto del producto. Es momento de la convergencia. La selección debe realizarse por consenso. Una vez elegida la idea, todos deben aportar en la definición de wireframes y user flows finales (si aplica). Es recomendable que esta actividad se realice en una pizarra o utilizando hojas de rotafolio para facilitar el trabajo colaborativo. El éxito del estudio de diseño radica en llegar a este punto bajo un entendimiento común del proyecto.

Los artefactos creados en el estudio de diseño son la base para la creación del Producto Mínimo Viable que se empleará para la creación del experimento que validará las hipótesis del equipo.

Producto Mínimo Viable

Lean UX, Minimum Viable Product.
Minimum Viable Product.

Lean UX utiliza ampliamente el concepto de Producto Mínimo Viable (MVP, por sus siglas en inglés).

Eric Ries, autor de Lean Startup, definió el término como:

“Un Producto Mínimo Viable es la versión de un nuevo producto que permite a un equipo obtener la máxima cantidad de aprendizaje validado sobre los clientes, con el menor esfuerzo posible”.

En Lean UX, un MVP es utilizado para la validación de hipótesis priorizadas a través de experimentos. El resultado de la experimentación indicará si la hipótesis es válida. Si la idea es correcta, debe perfeccionarse; si es errónea, debe abandonarse.

Tipos de MVP

Un MVP puede tener dos objetivos:

  • Obtener aprendizaje
  • Generar valor

Cuando se pretende validar una hipótesis y obtener feedback del mercado nos encontramos en el caso de un MVP para obtener aprendizaje. Si la creación del MVP involucra crear valor de negocio e incluso comenzar con la adopción de clientes, el objetivo es generar valor.

Respecto a su complejidad, un MVP puede ser tan simple como una simulación de funcionalidad (smoke test) hasta un nivel complejo a través de un prototipo de alta fidelidad.

Bajo estas consideraciones, objetivo y complejidad, es posible clasificar los MVP bajo los siguientes tipos:

  • Entrevistas. Se realizan entrevistas y/o cuestionarios con clientes potenciales para validar las hipótesis relacionadas con los problemas de las personas. Es uno de los métodos más rápidos y baratos. Suelen realizarse en etapas tempranas del proyecto.
  • Prototipos. Se presenta a clientes potenciales una simulación del producto con el suficiente nivel de detalle para comprender la funcionalidad a validar. Dependiendo de su complejidad, existen prototipos de baja, media y alta fidelidad. Es el rostro más común de un MVP.
  • Descripción. Se capta la atención de clientes potenciales a través de la descripción e información general sobre el producto o servicio. Es común recurrir a un Landing Page, videos demostrativos, correos electrónicos, anuncios (Google Ad Words), creación de perfiles en redes sociales e incluso a sistemas de recaudación de fondos (crowdfunding).
  • Producto. Código funcionando. No es necesario el desarrollo completo, sólo aquella funcionalidad necesaria para la validación de hipótesis. Es el tipo de MVP que permite generar más valor de negocio.
  • Concierge MVP. Consiste en la simulación de un proceso o funcionalidad del producto de forma manual pero que aparente ser automática ante los clientes potenciales.

¿A quién va dirigido un MVP?

Un MVP debe ser presentado, prioritaria pero no exclusivamente, a early adopters.

De acuerdo a la curva de adopción de la innovación de Everett Rogers, existen 5 tipos de personas que tienen una reacción diferente ante las innovaciones en productos y servicios por lo que requieren estrategias diferentes para su adopción:

  • Innovators
  • Early adopters
  • Early majority
  • Late majority
  • Laggards
Lean UX. Curva de la adopción de la innovación de Everett Rogers.
Curva de la adopción de la innovación de Everett Rogers.

De acuerdo a este modelo, un early adopter es aquel tipo de consumidor que es el primero en adquirir un producto o servicio novedoso, mucho antes que ocurra un consumo en masa.

Por lo general son líderes de opinión, prueban nuevas ideas, pero lo hacen de una manera cuidadosa. Evalúan objetivamente si una innovación va a generar un verdadero beneficio y cuando están convencidos tienen una alta predisposición a adoptarlas.

Este tipo de personas, que representa el 13.5% de la organización o grupo social, inicia el proceso de difusión de las innovaciones hacia el interior del grupo, su nivel de creedibilidad es muy fuerte porque no tienen la pasión y “enamoramiento” de los innovators, por lo que  pueden hablar con mayor objetividad de los beneficios de la innovación.

Un early adopter identificará de mejor forma el valor en un MVP y “perdonará” las limitantes que pueda tener en cuanto a funcionalidades o nivel de detalle, es por esta razón que debe ser el tipo de cliente potencial que debe buscarse para la validación de hipótesis. Sin embargo, no hay que olvidar que la meta final del producto debe ser llegar a los early majority, si logra captar a ese público, el producto tendrá más probabilidades de éxito.

¿Cuánta calidad debe tener un MVP?

La filosofía Lean indica que debe eliminarse cualquier elemento, proceso o esfuerzo que no contribuya directamente al aprendizaje o validación que se esté buscando. Existe un principio que impera cuando hay que decidir sobre qué tan complejo o refinado debe ser un MVP, el principio KISS: Keep IT Simple, Stupid. Establece que la mayoría de sistemas funcionan mejor si se mantienen simples que si se hacen complejos; por ello, la simplicidad debe ser mantenida como un objetivo clave del MVP, y cualquier complejidad innecesaria debe ser evitada.

Keep it simple stupid.
Keep it simple stupid.

Esta perspectiva debe ser tomada con mesura. Lean UX no se opone a la creación de un MVP de alta calidad, siempre que contribuya de manera significativa al proceso de aprendizaje. Tampoco significa que los MVP deben ser siempre rústicos, sobre todo si representan un obstáculo en la validación y obtención de feedback.

¿Cuáles son los principales obstáculos en la creación de un MVP?

Los de siempre, tiempo, alcance y recursos. Pero además:

  • Aspectos legales y de patentes.
  • Miedo a la competencia.
  • Miedo al riesgo.
  • Miedo a la frustración.

La clave es perder miedo al fracaso y seguir la regla: falla rápido, falla barato.

Consideraciones para la creación de un MVP

La razón de ser de un MVP es la validación de hipótesis y el aprendizaje. Al comenzar la planeación de la construcción de un MVP se debe responder tres preguntas básicas:

  • ¿Existe una necesidad por parte de un usuario para la funcionalidad a implementar?
  • ¿Existe valor en la funcionalidad a implementar?
  • ¿Existe usabilidad en la funcionalidad a implementar?

La primera pregunta debe responderse a través de métodos tradicionales de investigación de usuarios. Si sólo existe esta pregunta, el tipo de MVP requerido seguramente será del tipo entrevista o descripción, es decir, buscar generar aprendizaje pero no valor en el producto.

La segunda y tercera pregunta involucran, en esencia, la creación de un MVP destinado a crear valor del producto en el mercado y observar cómo reaccionan los usuarios potenciales en el contexto real de uso. Bajo estas consideraciones, el tipo de MVP que permite responder estas preguntas son los prototipos, funcionalidades del producto con código funcionando e incluso un concierge MVP.

Para definir qué tipo de MVP es el más conveniente, también es recomendable responder las siguientes preguntas:

  • ¿Qué trato de aprender/validar?
  • ¿Cuál es la forma más rápida para obtener ese conocimiento?

Muchas veces, la respuesta a estas preguntas conducen a la creación de un prototipo.

Prototipos

Una de las formas más comunes de crear un MVP es a través de un prototipo, un modelo del producto final que simula su comportamiento con el objetivo de aprender del mercado y validar hipótesis.

De acuerdo a su complejidad, se clasifican en:

  • Prototipos de baja fidelidad
  • Prototipos de media fidelidad
  • Prototipos de alta fidelidad

Los prototipos de baja fidelidad permiten simular el producto de una manera rápida y barata, sacrificando fidelidad y nivel de detalle.

Un prototipo de baja fidelidad físico puede ser creado con insumos de bajo costo y fácil acceso, principalmente lápiz y papel.

Un prototipo de baja fidelidad digital puede ser creado a partir de wireframes integrando interacciones básicas por medio de un software especializado.

El uso de este tipo de prototipos se restringe a la obtención de feedback y validaciones de alto nivel, como el flujo de interacción del producto, etiquetas y taxonomías.

Los prototipos de media y alta fidelidad representan un nivel de detalle significativamente mayor que los prototipos de baja fidelidad gracias a su nivel de detalle en la interacción, diseño visual o simulación de la funcionalidad.

El fin esencial de un prototipo es mostrarlo a todos los interesados en el proyecto, tanto al equipo, stakeholders y sobre todo, clientes potenciales.

Para muchos equipos de trabajo, el enfoque habitual para desarrollar un MVP es un prototipo, ya que permite comenzar con el diseño visual y la implementación de código, sin embargo, no hay que perder de vista que no es el único instrumento en la validación de hipótesis.  

Pretotipos

Alberto Savoia, un destacado autor y experto en temas de innovación, acuñó este término en 2009 para hacer referencia a una etapa del proceso de desarrollo de un producto o servicio que se encuentra entre la idea original y un prototipo. Pretotipar es una forma de probar una idea de forma rápida y barata mediante la creación de versiones extremadamente simplificadas, simuladas o virtuales del producto para ayudar a validar la premisa “si construímos esto, lo utilizarán”.

La intención es no construir algo tangible, sino recurrir a otros instrumentos de simulación, “estar seguro de construir lo correcto antes de construirlo correctamente”.

Ejemplos de técnicas de pretotipos son:

  • Mechanical Turk: Similar al concepto de Concierge MVP, consiste en reemplazar maquinaria o procesos por acciones manuales.
  • Pinocchio: Versión inerte del producto.
  • Fake Door: Punto de entrada o conversión ficticia de un producto que no existe.
  • Pretend-to-own: Realizar el alquiler o pedir en préstamo un componente del producto o servicio y ofrecerlo a los usuarios sin anunciar que no se trata de algo propio.
  • Re-label: Colocar una etiqueta falsa a un producto existente con las características de la idea a desarrollar para observar la aceptación entre clientes potenciales.

Mientras los prototipos son una herramienta necesaria para responder a muchas preguntas sobre un producto, tales como:

  • ¿Puede construirse?
  • ¿Va a funcionar?
  • ¿Va a funcionar como se pretendía?
  • ¿Cuánto cuesta producirlo?
  • ¿Cómo lo van usar las personas?
  • ¿Para qué lo van a usar las personas?

Pretotipar, por el contrario, se centra en dar respuesta a una -muy básica pero importante- cuestión: ¿es esto lo que hay que construir? Una vez que la pregunta se responde de manera positiva, entonces tiene sentido pasar de pretotipar a prototipar.

***

En la quinta y penúltima entrega se describirá la tercera fase, ejecución de un experimento.

Diseñador de Experiencia de Usuario. Scrum Master Certified. Fotógrafo. Ha participado en proyectos vinculados a HCI, usabilidad y UX en el ámbito académico, empresarial y gobierno desde 2007. Es parte del equipo de UX Nights.

Lean UX, parte 3

Lean UX es, en esencia, una manera distinta de pensar, una nueva mentalidad para el diseño y desarrollo de productos. En esta tercera parte, se describe la primera fase del ciclo Lean UX.

Lean UX no comienza con requerimientos, sino con supuestos, a partir de supuestos, creamos y validamos hipótesis, y a partir de la validación de hipótesis, medimos si hemos conseguido los resultados esperados.

La declaración de hipótesis es el punto de partida de los proyectos Lean UX. Representa una forma de expresar los supuestos que tenemos del proyecto junto con el mecanismo de validación.  Una declaración de hipótesis está integrada por:

  • Supuestos: una declaración de alto nivel que se asume como cierta.
  • Hipótesis: descripciones detalladas de los supuestos orientadas hacia el producto y el mecanismo de experimentación para su validación.
  • Resultados: El dato o valor que permitirá la validación de la hipótesis.
  • Personajes (Proto-Personas): Modelo o arquetipo de las personas para las que suponemos está orientado el producto.
  • Funciones: Características del producto que suponemos conseguirán los resultados esperados.

Supuestos

Suponer algo sobre un producto al iniciar un proyecto no es, en esencia, algo malo. El problema es no hacer explícito un supuesto. Peor aún, pensar en los supuestos como un hecho comprobado.

Definir supuestos tiene las siguientes ventajas:

  • Permite que todo el equipo comience desde el mismo punto.
  • Facilita la conversación entre el equipo sobre cómo resolver el problema.
  • Genera divergencia en las posibles soluciones.

¿Cómo declaramos supuestos en Lean UX? Aquí la descripción del método.

Declaración de supuestos y priorización

Declaración de supuestos
Declaración de supuestos.

¿Quiénes participan?

Todo el equipo y todas las disciplinas involucradas.

Antes de empezar

  • Declarar el problema.
  • Recopilar información sobre el problema.

Ejecución

  • El equipo debe debatir sobre el problema y declarar supuestos.
  • Cada miembro del equipo puede responder las preguntas de la plantilla propuesta por Jeff Gothelf o crear una propia.
  • Representar gráficamente la discusión alrededor de los supuestos.
  • Generar una lista de supuestos.
  • Priorizar los supuestos a través de una matriz de priorización. Debemos responder la pregunta: ¿cuál supuesto debemos validar primero?

Plantillas

 

Matriz de priorización.
Matriz de priorización.

Declaración de hipótesis

Una vez que se defina la lista de supuestos priorizada, el siguiente paso es transformar cada declaración de supuesto en una declaración de hipótesis agregando el mecanismo de validación. Aquí la descripción del método.

¿Quiénes participan?

Todo el equipo y todas las disciplinas involucradas.

Antes de empezar

  • Declarar supuestos.

Ejecución

El formato típico de una declaración de hipótesis es:

Creemos que [declaración] es cierta.

Sabremos que lo hemos hecho [bien/mal] cuando contemos con el siguiente feedback del mercado:

[feedback cualitativo].

[feedback cuantitativo].

La principal cualidad de esta representación es eliminar la subjetividad de la toma de decisiones y orientar al equipo a la obtención de feedback del mercado.

Resultados

Durante la declaración de hipótesis es importante definir qué resultados de alto nivel se espera obtener tras su validación e implementación. El equipo debe establecer cuáles son esos posibles resultados.

Método: brainstorming

¿Quiénes participan?

Todo el equipo y todas las disciplinas involucradas.

Antes de empezar

  • Declarar hipótesis.

Ejecución

Responder las siguientes preguntas:

  • ¿Qué resultados esperas obtener de las hipótesis a validar?
  • ¿Los resultados pueden dividirse en componentes más pequeños?
  • ¿Los componentes más pequeños pueden traducirse a un Indicador Clave de Rendimiento (KPI)?

Personas

Personas son arquetipos basados en patrones de comportamiento revelados durante el proceso de investigación de usuarios y se construyen con el propósito de ser una herramienta de comunicación durante el diseño del producto. Lean UX propone un método para la creación de estos personajes de una forma simplificada partiendo de…, adivinaron…, supuestos.

Método: Protopersonas

A partir de la declaración de supuestos, se construyen modelos que definen quién utilizará el producto y por qué. La representación es burda y esquemática, siendo esto lo deseable, a medida que aprendamos más sobre el producto y los usuarios, se va ajustando la definición de protopersonas.

Protopersonas.
Protopersonas.

¿Quiénes participan?

Todo el equipo y todas las disciplinas involucradas.

Antes de empezar

  • Declarar supuestos.

Ejecución

En una hoja de papel o rotafolio dividido en cuadrantes, colocar en el cuadrante superior derecho información demográfica básica, sólo aquella que pueda aportar valor para predecir un tipo concreto de comportamiento. Dotar de un nombre y un rostro a este personaje en el cuadrante superior izquierdo.

El cuadrante inferior izquierdo debe contener las necesidades y frustraciones de los usuarios relacionadas con el problema. El cuadrante inferior derecho contiene los supuestos sobre la soluciones para resolver sus necesidades.

Es recomendable definir a las protopersonas a través de una sesión de brainstorming, mientras más protopersonas se construyan, mejor. Las protopersonas también se validan. Eventualmente, una protopersona evolucionará a una persona (como un Pokémon).

Plantillas

Funciones

En este punto es necesario empezar a suponer cuáles serían las técnicas, funciones, productos y servicios que habrá que desarrollar para conseguir esos resultados. En Lean UX las funciones se construyen para satisfacer las necesidades de los usuarios, no al revés.

Método: brainstorming

En una sesión de brainstorming se definen las funciones que dirigirán el comportamiento de los usuarios en la dirección correcta.

¿Quiénes participan?

Todo el equipo y todas las disciplinas involucradas.

Antes de empezar

  • Declaración de hipótesis, resultados y protopersonas.

Ejecución

Escribir la mayor cantidad de ideas posibles y construir un tablero a partir de las ideas para visualizar todas las alternativas.

Con el material obtenido, es necesario organizar las funciones en hipótesis que puedan validarse. El resultado es una tabla de esta forma:

Crearemos Para Para lograr
[función] [personaje] [resultado]

Una vez construída la lista de hipótesis, iniciará la etapa de diseño.

***

En la cuarta parte de esta serie, describiré la segunda fase del ciclo Lean UX: la creación de un MVP.

Diseñador de Experiencia de Usuario. Scrum Master Certified. Fotógrafo. Ha participado en proyectos vinculados a HCI, usabilidad y UX en el ámbito académico, empresarial y gobierno desde 2007. Es parte del equipo de UX Nights.

Lean UX, parte 2

Lean UX es, en esencia, una manera distinta de pensar, una nueva mentalidad para el diseño y desarrollo de productos. En esta segunda parte, se describen los pilares y principios de Lean UX.

Pilares

Lean UX se apoya en tres pilares clave: Design Thinking, metodologías de desarrollo ágil de software y Lean Startup.

1. Design Thinking

Innovación que se alimenta de […] la observación directa de lo que la gente quiere y necesita en sus vidas y lo que les gusta o disgusta de cómo se hacen los productos, cómo se empaquetan, cómo se ponen en el mercado, cómo se venden y cómo se les presta ayuda […]. Se trata de una disciplina que, utilizando la sensibilidad y los métodos de los diseñadores, satisface las necesidades del público con aquello que resulta tecnológicamente posible y que, gracias a una estrategia de negocio viable, puede convertirse en valor para los clientes y en oportunidades en el mercado.

Tim Brown, CEO de IDEO

Design Thinking es un pilar básico de Lean UX debido a que aporta una manera de trabajar que alienta la colaboración en el equipo, independientemente del rol que cada uno desempeñe, y que considera el producto desde una perspectiva holística y abarcadora.

Proceso Design Thinking.
Proceso Design Thinking.

2. Metodologías de desarrollo ágil de software

Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:

  • Individuos e interacciones sobre procesos y herramientas.
  • Software funcionando sobre documentación extensiva.
  • Colaboración con el cliente sobre negociación contractual.
  • Respuesta ante el cambio sobre seguir un plan.

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda”.

Manifiesto ágil

 

El segundo pilar de Lean UX son las metodologías de desarrollo ágil de software. Lean UX aplica en el diseño de productos los cuatro pilares del Manifiesto Ágil:

  • Individuos e interacciones sobre procesos y herramientas. La comunicación efectiva entre miembros del equipo debe prevalecer por encima de las restricciones propias de las herramientas, ya sea en los procesos o en la producción.
  • Software funcionando sobre documentación extensiva. Cuanto antes dispongamos de un producto que funcione, seremos capaces de encontrar la solución que mejor se adapta al mercado.
  • Colaboración con el cliente sobre negociación contractual. Si el equipo colabora con el cliente, se podrá crear un entendimiento común sobre el problema y las posibles soluciones.
  • Respuesta ante el cambio sobre seguir un plan. Fallar rápido. Fallar barato. El producto inicial no dará con la mejor solución posible, el objetivo es averiguar qué se ha hecho mal lo antes posible, ajustar y volver a probar.

3. Lean Startup

El método Lean Startup es un conjunto de prácticas pensadas para ayudar a los emprendedores a incrementar las probabilidades de crear una startup con éxito. No es una fórmula matemática infalible, sino una filosofía empresarial innovadora que ayuda a los emprendedores a escapar de las trampas del pensamiento empresarial tradicional.

Eric Ries
Lean Startup

 

Lean Startup utiliza un ciclo de retroalimentación (feedback) denominado “crear-medir-aprender” que minimiza el riesgo de los proyectos y consigue que el equipo pueda desarrollar software y aprender de él en muy poco tiempo.

Con este método, los equipos desarrollan lo antes posible un Producto Mínimo Viable (MVP, por sus siglas en inglés) para comenzar el proceso de aprendizaje cuanto antes.

Proceso Lean Startup.
Proceso Lean Startup.

Lean UX aplica de manera directa la filosofía de Lean Startup sobre aumentar la frecuencia de contacto con clientes reales, reducir el despilfarro y probar lo antes posible las ideas del equipo para evitar caer en suposiciones incorrectas sobre el mercado.

En Lean UX, cada diseño es una solución propuesta para el negocio -una hipótesis-, el objetivo es validar esa solución lo más eficientemente posible, utilizando para ello la retroalimentación de los clientes.

La validación de hipótesis en Lean UX sigue el siguiente proceso:

  1. Crear un MVP.
  2. Probar la hipótesis mostrando el MVP a clientes reales.
  3. Utilizar lo aprendido para modificar el MVP.
  4. Iterar.

De esta forma, Lean UX permite de forma más rápida sacar a la luz la verdadera naturaleza de los productos. La filosofía de Lean UX es otorgar más importancia a la creación de un entendimiento común de la experiencia del usuario del producto que se diseña que a la creación y entrega de documentación.

Principios

A partir de los pilares de Design Thinking, las metodologías ágiles de desarrollo y Lean Startup, Lean UX plantea sus propios principios, una serie de atributos que permite a los equipos trabajar de manera colaborativa y multifuncional para lograr el desarrollo de productos orientados a la experiencia del usuario. 

Jeff Gothelf define los principios de la siguiente forma:

1. Equipos multifuncionales

Lean UX necesita que el equipo se conforme con todas las disciplinas que intervienen en la creación de un producto, que colabore intensamente y de manera contínua, desde el primer día hasta el final.

2. Equipos pequeños, dedicados, coubicados

Es necesario limitar el tamaño de los equipos para lograr: comunicación, concentración y camaradería.

3. Progreso igual a resultados, no a entregas de documentación

Lean UX mide el progreso del proyecto según los resultados de negocio, no por la acumulación de documentación.  

4. Equipos centrados en los problemas

El equipo debe estar enfocado en resolver problemas y no limitarse a implementar funcionalidades de desarrollo.

5. Eliminación del despilfarro

En Lean UX, todo lo que no ayude a conseguir resultados, se considera un despilfarro y debe eliminarse del proceso de trabajo.

6. Lotes pequeños

El equipo sólo debe crear el diseño necesario para avanzar, evitando crear un gran volumen sin probar ni implementar.

7. Descubrimiento continuo

En Lean UX, los clientes del producto participan en el proceso de diseño y desarrollo con el objetivo de validar las ideas sobre el producto. La investigación de mercado con clientes reales debe realizarse de forma frecuente y regular, así como involucrar a todo el equipo.

8. Get out of the building

Las respuestas a los problemas están en el mercado, con los clientes reales, no en la oficina del equipo. Es mucho mejor averiguar que nuestras ideas de solución están equivocadas antes de dedicar tiempo y recursos a construir un producto que nadie quiere.

9. Entendimiento común

A medida que un equipo trabaja de forma conjunta, logrará un conocimiento colectivo y una comprensión profunda del producto y de los clientes.

10. Antimodelos: estrellas, gurús y ninjas

Lean UX privilegia una visión de equipo. Las estrellas, gurús, ninjas y expertos reducen la colaboración y frenan la cohesión del equipo.

11. Exteriorización del trabajo

Los equipos deben mostrar su trabajo de forma abierta, más allá de un monitor. El uso de pizarrones, tableros, notas adhesivas y demás anotaciones visibles es un común denominador en Lean UX para mostrar el trabajo a compañeros, colegas y clientes.

13. Hacer en lugar de analizar

Tiene más valor crear la primera versión de una idea que emplear horas de  discusión en una reunión debatiendo si vale la pena o no construirla.

14. Aprendizaje en lugar de crecimiento

Lean UX prioriza aprender sobre una idea y después buscar su crecimiento. Escalar una idea que no se ha probado es arriesgado.

15. Permiso para equivocarse

Los equipos en Lean UX necesitan experimentar con las ideas. La mayor parte de estas ideas, no funcionará. El equipo debe sentirse libre para equivocarse. Las grandes ideas siempre proceden de los riesgos.

16. Escapar de los negocios basados en entregables

El progreso de un proyecto depende de los resultados que se consiguen, no de los documentos que el equipo escriba.

***

Tener presente los pilares y principios de Lean UX nos obliga a no olvidar su esencia, la empatía hacia los usuarios (Design Thinking), el trabajo en equipo (métodos ágiles) y la experimentación como instrumento de validación (Lean Startup). Las técnicas particulares y las fases que comprenden el método en realidad son secundarias, o como dice El Principito, “lo esencial es invisible a los ojos”.

En la tercera parte de esta serie, describiré la primera fase del proceso de Lean UX: la declaración de supuestos y las técnicas que comprende.

Diseñador de Experiencia de Usuario. Scrum Master Certified. Fotógrafo. Ha participado en proyectos vinculados a HCI, usabilidad y UX en el ámbito académico, empresarial y gobierno desde 2007. Es parte del equipo de UX Nights.

Lean UX, parte 1

Lean UX es, en esencia, una manera distinta de pensar, una nueva mentalidad para el diseño y desarrollo de productos. Involucra tres cosas fundamentales: un cambio de procesos, un cambio en la forma de enfrentar el trabajo de diseño y una transformación en la forma de gestionar los proyectos.

¿Por qué es necesario cambiar la forma en que se diseñan los productos?

Un poco de historia

En marzo de 2011, Jeff Gothelf, un reconocido diseñador de producto,  publicó Lean UX: Getting Out of the Deliverables en donde describe por primera vez el concepto Lean UX. Para Jeff, la manera en la que los diseñadores colaboran en el desarrollo de productos atraviesa una situación crítica, pasan más tiempo creando documentos en donde se especifica cómo debería ser el producto en lugar de crearlo.

Cuando los diseñadores trabajan con el paradigma de priorizar la creación de documentación exhaustiva y se combina con un entorno de desarrollo en cascada, el resultado es un consumo de tiempo perdido y la creación de una enorme cantidad de despilfarro (waste). Un despilfarro o residuo se define como cualquier cosa que termina no siendo realmente útil en el desarrollo de un producto.

Típicamente, el modelo en cascada para el desarrollo de software sigue las siguientes fases:

Modelo en cascada
Modelo en cascada

Bajo este escenario, las actividades de diseño generalmente involucran:

  • Esperar la definición de requisitos para contar con la aprobación de iniciar.
  • Leer la documentación de requisitos.
  • Elaborar mapas de sitio de alto nivel (sitemaps) y flujos de trabajo (workflows).
  • Llegar a un consenso y aprobación.
  • Desarrollar wireframes.
  • Presentar a las partes interesadas, conseguir consenso y aprobación.
  • Crear diseños visuales por cada wireframe.
  • Presentar a los interesados hasta obtener una aprobación final (después de repetidos ciclos de revisión).
  • Escribir las especificaciones, detallando cada pixel e interacción.
  • Realizar pruebas de usabilidad para futuras mejoras.
  • Revisar la fase de desarrollo, aprobar e iniciar la implementación.

Este camino deja muchas horas de despilfarro y muchos diseñadores frustrados a su paso porque al finalizar, el producto de software no corresponde a las necesidades reales de los clientes. La mayor mentira en el mundo del desarrollo de software es pensar que existirá una “Fase II” del proyecto para corregir todos los problemas que surgen en la primera entrega. La verdad es que la mayoría de las veces nunca existe una fase II.

Cómo funcionan los proyectos
Cómo funcionan los proyectos en cascada

Los métodos tradicionales de desarrollo de productos se empeñan en definir organizaciones y equipos de trabajo lineales en un mundo sometido a un cambio constante, pretende crear silos aislados en un entorno donde se necesita colaboración continua e ininterrumpida.

Este es el paradigma que intenta romper Lean UX.

Inspirado por las teorías de Lean Startup, Design Thinking y del desarrollo ágil de software, Lean UX es la práctica de traer a la luz la verdadera naturaleza del trabajo de los diseñadores, de forma más rápida, con menos énfasis en las prestaciones (documentación) y una mayor concentración en la experiencia real que está siendo diseñada.

En Lean UX los documentos tradicionales de diseño (sitemaps, wireframes, workflows, etc.) se descartan o, al menos, se reducen a la cantidad mínima de información necesaria para empezar a trabajar en la implementación lo más pronto posible. Los ciclos largos de diseño detallado se evitan en favor de ciclos muy cortos e iterativos, de baja fidelidad, con retroalimentación temprana y frecuente procedente de todos los miembros del equipo de implementación. La colaboración con todo el equipo se vuelve fundamental para el éxito del producto.

En su concepción original, el proceso Lean UX se definió a través de las siguientes fases:

Proceso original Lean UX
Proceso original Lean UX

El planteamiento retomó muchos conceptos provenientes de las metodologías ágiles: en una fase inicial, el equipo comienza a dar sus puntos de vista sobre la dirección del diseño, así como su viabilidad.  A continuación se realizan cambios a la idea original, que incluso puede ser desechada en su totalidad para proponer una nueva idea.

La inversión inicial en su representación a través del dibujo es tan mínima que no hay ningún costo significativo para replantear por completo el sentido. Una vez que se ha acordado internamente una cierta dirección, un prototipo de baja fidelidad ayuda a validar la idea con clientes reales. El aprendizaje ayuda a perfeccionar la idea, y el ciclo se repite.

Lean UX se enfocó en las actividades de diseño, lo cual permitió incorporar su ejecución a prácticamente cualquier proceso o marco de trabajo de desarrollo de software.

Desde su aparición, Lean UX empezó a ser adoptado en gran cantidad de organizaciones. Dos años más tarde, en 2013, Jeff publica el libro Lean UX: Applying lean principles to improve user experience donde define el ciclo que conocemos actualmente:

Ciclo Lean UX
Ciclo Lean UX

El ciclo inicia con la declaración de supuestos sobre el proyecto para determinar las hipótesis, después es necesario determinar qué ideas sobre el producto son válidas y cuáles deben descartarse a través de un Producto Mínimo Viable, el cual debe permitir la ejecución de un experimento que permita generar investigación y obtener retroalimentación de clientes reales. El aprendizaje adquirido es utilizado en la siguiente iteración del ciclo.

Más allá del ciclo que lo define, Lean UX representa un viaje hacia una nueva forma de trabajar, quienes deseen iniciar este viaje deben estar dispuestos a romper paradigmas, un tema particularmente difícil para quienes están inmersos en métodos de trabajo rígidos y lineales, aquellos que siguen esperando la fase II.

Escapemos de los negocios basados en documentación y volvamos a concentrarnos en la tarea más urgente: hacer felices a nuestros clientes”, es el llamado que hace Jeff Gothelf en Lean UX.

En la segunda parte de esta serie, hablaré sobre los principios de Lean UX.

Diseñador de Experiencia de Usuario. Scrum Master Certified. Fotógrafo. Ha participado en proyectos vinculados a HCI, usabilidad y UX en el ámbito académico, empresarial y gobierno desde 2007. Es parte del equipo de UX Nights.