Prólogo

Al leer Lean UX , está a punto de embarcarse en un recorrido por una nueva forma de
trabajar. Para aquellos de nosotros que estamos inmersos en las técnicas de gestión
tradicionales, puede parecer un poco desorientador. A veces me gusta imaginar cómo
sería tener una vista panorámica de la típica corporación moderna. Desde lo alto, en su
mente, podría examinar cada silo de excelencia funcional uno a la vez: marketing,
operaciones, fabricación, TI, ingeniería, diseño, y así sucesivamente en una fila ordenada
de silos nítidos y bien administrados.

Imaginemos que se agachó para agarrar uno de estos silos y le quitó la parte superior para
ver el interior. ¿Qué verías? Al ser una empresa moderna, vería que cada silo está
diseñado para una máxima eficiencia. Para lograr esta eficiencia, es probable que
encuentre un enfoque altamente iterativo y centrado en el cliente para la resolución de
problemas. En la fabricación, se encontrará con el pensamiento Lean tradicional. En
Ingeniería o TI, quizás alguna variación en el desarrollo ágil. En Marketing, desarrollo de
clientes. En Operaciones, DevOps. Y, por supuesto, en Diseño, lo último en pensamiento
de diseño, diseño de interacción y técnicas de investigación de usuarios.

Si volvemos a acercarnos a nuestro punto más alto, es posible que se nos perdone por
pensar: “Esta empresa utiliza una variedad de metodologías rigurosas, basadas en
hipótesis, centradas en el cliente e iterativas. Sin duda, debe ser una empresa
extremadamente ágil, capaz de reaccionar rápidamente a los cambios en las condiciones
del mercado e innovando continuamente ”. Pero aquellos de nosotros que trabajamos en
empresas modernas sabemos cuán lejos está esto de la verdad.

¿Cómo es posible que nuestros silos departamentales estén operando con agilidad pero
nuestras empresas sean desesperadamente rígidas y lentas? Desde nuestro lejano punto
de vista, nos hemos perdido algo esencial. Aunque nuestros departamentos pueden
valorar la agilidad, las interconexiones entre ellos todavía están empantanadas en un
pasado industrial anticuado.

Considere solo un ejemplo, que espero le resulte familiar. Una empresa decide que debe
innovar para sobrevivir. Encarga a un equipo de diseño (ya sea interno o externo) para
investigar el futuro de su industria y recomendar nuevos productos innovadores que
podrían asegurar su futuro. Comienza un período de gran emoción . Los clientes son
entrevistados, observados, analizados. Los experimentos , encuestas, grupos focales,
prototipos y pruebas de humo se suceden uno tras otro. Los conceptos se conciben,
prueban, rechazan y refinan rápidamente.

¿Y qué pasa al final de este proceso? Los diseñadores presentan con orgullo, y la empresa
celebra con entusiasmo, un documento de especificaciones masivo con sus hallazgos y
recomendaciones. Cesa la iteración, la experimentación y el descubrimiento. Ahora se
pide a Ingeniería que ejecute este plan. Y aunque el proceso de ingeniería puede ser ágil,
el documento de especificaciones está rígidamente fijo. ¿Qué sucede si los ingenieros
descubren que la especificación era inviable o incluso ligeramente defectuosa? ¿Qué pasa
si los conceptos funcionan muy bien en el laboratorio pero no tienen atractivo
comercial? ¿Qué pasa si las condiciones del mercado han cambiado desde que tuvo lugar
el "aprendizaje" original?
Una vez hablé con una empresa que había encargado, a un costo terrible, un estudio de
varios años de su industria. El resultado fue una impresionante pantalla de "vista del
futuro" personalizada en su sede corporativa. Dentro de esta sala, se podía ver una
extrapolación de cómo serían los próximos 10 años en su industria, con demostraciones
de trabajo de conceptos de productos futuristas. Puede adivinar lo que sucedió durante
los siguientes 10 años: absolutamente nada. La empresa rotó a cientos o miles de
ejecutivos, gerentes y trabajadores a través de esta visión del futuro. Y de hecho, 10 años
después, la habitación ya no parece futurista. Contra todo pronóstico, sus pronósticos
resultaron ser en gran parte precisos. Y, sin embargo, la empresa no había logrado
comercializar ni siquiera una de las recomendaciones del documento de especificaciones
correspondiente. Así que le pregunté a la empresa qué planeaban hacer a
continuación. ¡Me dijeron que iban a volver con los diseñadores originales y les pedían
que pronosticaran los próximos 10 años! La empresa culpó a sus ingenieros y gerentes,
no a los diseñadores, por su fracaso en la comercialización.

Cuando les cuento esta historia a los no diseñadores, se horrorizan y quieren convencerme
de que la culpa es de la empresa de diseño elegante. Cuando se lo digo a los altos
ejecutivos, tanto en las grandes empresas como en las nuevas empresas, se
estremecen. Están constantemente inundados de quejas de todas y cada una de las
funciones de que son rápidos y de vanguardia, pero son los otros departamentos los que
ralentizan la empresa. Cuando toda la empresa no logra encontrar nuevas fuentes de
crecimiento, hay mucha culpa.

Pero la culpa no es de los diseñadores, los ingenieros o incluso los ejecutivos. El problema
son los sistemas que usamos para construir empresas. Seguimos construyendo
organizaciones lineales en un mundo que exige cambios constantes. Todavía estamos
construyendo silos en un mundo que exige una colaboración exhaustiva. Y todavía
estamos invirtiendo en análisis, discutiendo sobre especificaciones y produciendo
entregables de manera eficiente en un mundo que exige experimentación continua para
lograr una innovación continua.

Cuando este libro se publicó por primera vez en 2012, todavía era temprano para Lean
Startup. Han pasado quince años desde que comencé a escribir y hablar sobre lo que
entonces era un concepto muy nuevo, y el 2021 también es el décimo aniversario de la
publicación de The Lean Startup: How Today's Entrepreneurs Use Continuous
Innovation to Achieve Radically Successful Businesses (Crown Business , 2011). En ese
tiempo, he visto crecer y difundirse las ideas, de industria a industria, de sector a sector y
de función a función. Cada vez que nos encontramos con un nuevo terreno, hemos
confiado en líderes con visión de futuro para ayudar a traducir los principios básicos y
desarrollar nuevos procesos para implementarlos. Hemos aprendido mucho sobre cómo
se puede utilizar y los profesionales de todo el mundo han aportado nuevas herramientas
y métodos.

Lean UX es un paso importante en esa evolución. Y gracias al compromiso de Jeff Gothelf

y Josh Seiden de continuar avanzando en la disciplina, esta nueva edición se basa en lo
que ya era una mirada completa a cómo se aplican los principios de Lean Startup en un
contexto de diseño. Las herramientas y técnicas fundamentales que presenta para lograr
una colaboración superior, una entrega más rápida y, lo que es más importante, productos
dramáticamente mejores se han aumentado para incluir entradas más nuevas como Lean
UX Canvas y Hypothesis Prioritization Canvas. También hay más sobre la relación entre
Lean UX y el mapeo de historias, así como también sobre sprints de diseño.

Lean Startup es una gran carpa. Se basa en ideas establecidas de muchas disciplinas,
desde la fabricación ajustada hasta el pensamiento de diseño. Nos brinda un vocabulario
común y un conjunto de conceptos que se pueden utilizar para acelerar los resultados en
toda la empresa. Podemos dejar de perder el tiempo discutiendo sobre quién tiene la culpa
y qué departamento debería gobernar el día.

Espero que todos recordemos prestar atención al llamado de Jeff de “salir del negocio de
los entregables” y regresar nuestro enfoque al lugar al que pertenece, alistando a toda la
corporación en su tarea más urgente: deleitar a los clientes.

Es hora de derribar los silos, unir los clanes y ponerse manos a la obra.

Eric Ries

28 de julio de 2021

San Francisco, CA

Esta edición de Lean UX es una contribución oportuna al mundo en evolución del diseño,
el espíritu empresarial y la innovación. Hace diez años, parte de nuestro trabajo con
empresas implicaba tener que convencer a los líderes del valor de la innovación más allá
de su negocio principal. Este debate ha desaparecido en su mayor parte. Los líderes
corporativos ahora están convencidos de que la innovación es la mejor manera de
impulsar el crecimiento a largo plazo dentro de sus empresas.

Si bien los líderes ahora ven el valor de la innovación, aún queda un desafío
diferente. Muy pocos líderes están satisfechos con el desempeño de innovación de su
empresa. Parece que gran parte del trabajo que realizan los equipos de innovación no
sigue un proceso repetible. Esta es la pregunta que los líderes ahora nos hacen
constantemente: ¿Cuáles son las estructuras y procesos que necesitan implementar para
tener una innovación repetible?

Esto es lo que hace que esta edición de Lean UX sea tan oportuna. Creemos que la
innovación es una profesión, no simplemente un llamado para unos pocos elegidos. Para
profesionalizar la innovación, necesitamos desarrollar las herramientas y los procesos
adecuados para que los innovadores los utilicen en su trabajo diario. A medida que las
personas aprendan a utilizar estas herramientas, podrán producir un valor repetible para
sus organizaciones. Esta es la contribución continua que está haciendo Lean UX .

Incluso después de la publicación de la primera edición de Lean UX , la mayor mentira en

el desarrollo de software y productos sigue siendo la fase dos. La idea es que a los equipos
se les debería permitir ejecutar lo que sea que tengan en su hoja de ruta y luego lidiar con
los problemas de los clientes después del lanzamiento (es decir, en la segunda versión del
producto). El problema es que nunca llegamos a la fase dos y los productos defectuosos
permanecen en el mercado. Esta es probablemente la razón por la que 7 de cada 10
lanzamientos de nuevos productos fracasan.
Entonces, ¿cómo resolvemos este desafío? Primero, necesitamos desarrollar herramientas
que se ajusten a la naturaleza de la innovación. Lean UX se basa en el claro entendimiento
de que la innovación no es un desafío tecnológico o de ejecución. En cambio, el desafío
para los equipos es buscar propuestas de valor que resuenen con los clientes y modelos
de negocios que sean rentables.

Dicha búsqueda requiere que los equipos naveguen por la complejidad y la

incertidumbre. Este no es un proceso lineal basado en una simple causa y efecto. Es un
proceso no lineal. Lean UX proporciona formas para que los equipos naveguen por esta
complejidad moviéndose de manera iterativa y creativa a través de las turbias aguas de la
innovación hasta que encuentren algo que funcione.

Una vez trabajamos con un líder que seguía pidiendo a sus equipos que le aportaran diez
veces más ideas. Tratamos de recordarle gentilmente al líder que sería imposible para él
y su equipo identificar una idea 10x el primer día. Los líderes no pueden elegir ideas
ganadoras; solo pueden crear el contexto en el que surgen las mejores ideas. Al seguir el
proceso establecido en Lean UX , los equipos pueden trabajar juntos para esbozar y probar
rápidamente sus ideas comerciales. Las ideas ganadoras surgirán a través de esas pruebas
e iteraciones.

La complejidad de la innovación también significa que los equipos no pueden navegar

hacia el éxito sin colaborar con colegas de diversas funciones clave. Hay una gran
distancia que recorrer entre tener una idea y luego diseñar, probar y lanzar esa idea al
mercado. Dicho trabajo requiere una colaboración multifuncional. El desafío es que
muchas organizaciones aún mantienen los silos y las transferencias que matan la
capacidad de los equipos para colaborar.

Hemos trabajado con varias organizaciones donde los equipos de innovación necesitan
obtener la aprobación legal y de cumplimiento para ejecutar experimentos. En una de esas
organizaciones, se necesitaron más de dos meses para que se aprobara un simple
experimento del Mago de Oz. Lean UX describe formas prácticas que se pueden utilizar
para superar esas barreras a la innovación.

Incluso después del lanzamiento del producto, la mentalidad articulada en Lean UX ayuda
a los equipos a continuar esbozando y probando. Es fundamental que los equipos no
consideren el lanzamiento de un producto como el final del proceso. Es fundamental que
continúen mejorando su oferta utilizando métodos Lean UX. Es importante recordar
siempre que las empresas no están en el negocio de los entregables; ¡están en el negocio
de deleitar a los clientes!

Esperamos que no solo disfrute de la lectura de este maravilloso libro, sino que también
tome las lecciones y las aplique a su trabajo diario.

Alex Osterwalder

30 de mayo de 2021

Lausana, Suiza

Tendayi Viki
30 de mayo de 2021

Harare, Zimbabue
Nota del autor
Cuando nos dispusimos a escribir la tercera edición de este libro, nos dimos cuenta de
que la influencia de un grupo siempre diverso de profesionales, escritores, entrenadores
y consultores ha ayudado a Lean UX a crecer y evolucionar para satisfacer las necesidades
cambiantes del diseño y desarrollo de software. . Queríamos tomarnos un momento para
agradecerles.

Continuamos aprendiendo del grupo central de colegas y compañeros guerreros de la

carretera que comparten su sabiduría y comentarios con nosotros, incluidos Tendayi Viki,
Teresa Torres, Melissa Perri, Hope Gurion, Barry O'Reilly, Sam McAfee, Andy Polaine,
David Bland, Andi Plantenberg, Jonathan Bertfield, Kate Leto, Daniel Stillman, Beth
Temple, Jocelyn Miller, Bob Gower, David Bland, Douglas Ferguson, Martina Hodges-
Schell, Erin Stadler, Jeff Patton, Petra Wille, Janet Bumpas, Jonathan Berger y Adrian
Howard . Construimos nuestras ideas sobre las de ellos y las de nuestros clientes.

Como siempre, nos gustaría agradecer a las muchas personas que han contribuido con
material, historias, pistas de investigación, ayuda de Twitter, sabiduría técnica y apoyo
emocional al libro. En particular, nos gustaría agradecer a Andrew Bourne, Ike Breed,
Steven Cohn, Regine Gilbert, Victor M. Gonzalez, Zach Gottlieb, Jamila Isoke, Liz Laub,
Jon Loyens, Dan Maccarone, Jono Mallanyk, Lin Nie, Greg Petroff, Steve Portigal, Leisa
Reichelt, Delphine Sassi, Alexander Schardt, Kristin Skinner, Erik Skogsberg, Jessica
Tiao, Kate Towsey, Ben Walker, Rosie Webster y Lee Weiss.

Estamos agradecidos con el equipo de Scrum.org , incluidos Dave West, Steve Porter,
Erik Weber y Gary Pedretti, y todos los entrenadores profesionales de Scrum que
conocimos allí que ayudaron a llevar nuestro trabajo a la comunidad de Scrum y que nos
ayudaron a mejorar nuestra comprensión de las necesidades de esa comunidad.

Gracias a Eric Ries por continuar apoyando el trabajo de Lean UX y los otros autores y
títulos de la Serie Lean, y a Melissa Duffield, Angela Rufino, Mary Treseler y Jennifer
Pollock en O'Reilly, quienes continúan haciéndolo posible para este libro para tener éxito.

Finalmente, seríamos negligentes si no agradecemos a los miembros del grupo de trabajo

Balanced Team, donde comenzamos a trabajar con estas ideas hace tantos años. Estamos
agradecidos con Lane Goldstone por ser el catalizador y la fuerza impulsora para unir a
ese grupo y unir a tantas personas maravillosas. En particular, tenemos una deuda de
gratitud con Janice Fraser, quien nos presentó por primera vez las ideas de Lean Startup
y quien acuñó la frase "Lean UX".

Nota: de Jeff
A medida que nuestra asociación entra en su segunda década, sigo viendo a Josh como
un amigo, colaborador y caja de resonancia lógica. La forma en que practicamos estas
ideas es diferente a los días en que comenzamos a hacerlo, pero a medida que cambian
las necesidades del mercado y las realidades del mundo, continuamos trabajando juntos
para encontrar nuevas formas de brindar mejores formas de trabajar a la empresa.
mundo. Estoy agradecido por eso y por su incansable búsqueda de la perfecta masa madre
casera y carne en conserva.

Como siempre, nada de esto sucede sin el apoyo y el amor de la familia. Carrie, Grace y
Sophie continúan complaciendo mi trabajo, mi escritura y mis bromas de papá. No podría
pedir más. Te quiero todo. Gracias.

Nota: de Josh
En este libro, Jeff y yo describimos un estilo de trabajo que es profundamente
colaborativo. Ese es mi estilo de trabajo preferido: siempre siento que aprendo más y soy
más eficaz cuando estoy colaborando. Todo lo que he podido aportar a este libro es el
resultado de las increíbles colaboraciones que he tenido la suerte de disfrutar en mi
carrera. Ustedes saben quienes son. Les estoy muy agradecido a todos ustedes.

Sin embargo, hay una colaboración de trabajo que debo mencionar: ha sido un verdadero
placer continuar colaborando con Jeff. Jeff aporta muchas de las cosas de esta asociación
que yo no puedo, incluido el optimismo sobre los plazos, la audacia al establecer metas y
la incansable evangelización. Es un socio inteligente, trabajador y sin ego. Sin embargo,
no es divertido. Si es necesario, normalmente tengo que proporcionárselo.

Gracias, finalmente, a Vicky, Naomi y Amanda. Te amo.

De Jeff y Josh
Han pasado otros cinco años desde la última vez que actualizamos este libro. Seguimos
asombrados por la comunidad y el trabajo que han generado las ideas de este libro. Mucho
ha cambiado y, sin embargo, muchos de los problemas que enfrentan los equipos de
diseño y desarrollo de software siguen siendo los mismos. El desafío siempre ha sido
construir no solo una colaboración interfuncional más amplia, sino una conversación
continua con el cliente que influya en el trabajo que elegimos hacer. La buena noticia es
que, con la asimilación más profunda de Agile y Scrum, junto con el marco de
establecimiento de objetivos y resultados clave (OKR), las organizaciones están
analizando aún más de cerca cómo volverse más ágiles y más centradas en el
cliente. Nosotros también hemos aprendido cómo las técnicas en Lean UXse puede aplicar
aún más eficazmente. Estamos emocionados de compartir eso contigo.

Cada vez que enseñamos Lean UX o lo usamos en nuestro trabajo diario, aprendemos una
mejor manera de aplicarlo. Probamos algo nuevo, lo inspeccionamos, nos adaptamos del
aprendizaje y actualizamos nuestro pensamiento. Sospechamos que está haciendo lo
mismo y nos encantaría saberlo.

Por favor, manténgase en contacto con nosotros y comparta sus pensamientos. Puede
comunicarse con nosotros en [email protected] y [email protected] . Siempre
esperamos escuchar de usted.

Prefacio
La mayor mentira en el software sigue siendo la fase dos.

Si ha dedicado algún tiempo a la creación de productos digitales en los últimos 30 años,

independientemente de su función, ha sentido el aguijón de esta mentira. Y si su equipo
dice ser ágil, ¿la fase dos sigue siendo un concepto válido? Los equipos priorizan
funciones e ideas para cada sprint, avanzando hacia una fecha de lanzamiento mientras
llevan ideas no priorizadas a la siguiente fase de trabajo. Excepto que esa fase nunca llega,
y esas características se han ido, nunca más se supo de ellas. Como diseñadores, gerentes
de producto, entrenadores y consultores, hemos tenido cientos, si no miles, de wireframes,
elementos de la cartera de productos y flujos de trabajo que terminan en este mismo
grupo.

Pero, ¿se abandonaron estas ideas porque eran defectuosas? ¿Porque algo cambió en el
mercado? ¿Las funciones que se enviaron realmente cumplieron con los objetivos
comerciales y de los clientes? ¿O el equipo simplemente se olvidó? Nunca llegaron a la
fase dos.

En The Lean Startup , Eric Ries exponesu visión sobre cómo garantizar que las ideas que
tienen el mayor valor obtengan la mayor cantidad de recursos. El método que Ries
promueve se basa en la experimentación, iteraciones rápidas de ideas y procesos
evolutivos. En un entorno verdaderamente ágil, los equipos lanzan funciones
continuamente, lo que hace que la implementación real del código no sea un evento. Todo
el concepto de la fase dos se ha vuelto discutible.

La unión de Lean Startup y el diseño de la experiencia del usuario (UX), y su coexistencia

simbióticamente beneficiosa, es Lean UX .

¿Qué es Lean UX?

Los principios Lean que subyacen a Lean Startup se aplican a Lean UX de tres
formas. Primero, nos ayudan a eliminar los residuos de nuestro proceso de diseño de
UX. Hacemos el trabajo suficiente, ya sea diseño, investigación, redacción, lo que sea,
para hacer avanzar la conversación entre diseño, desarrollo y producto. Estas
conversaciones mínimamente viables nos alejan de las largas negociaciones
desencadenadas por traspasos muy documentados. En cambio, un proceso Lean UX crea
solo los artefactos de diseño que necesitamos para hacer avanzar el aprendizaje del
equipo . En segundo lugar, los principios Lean nos impulsan a armonizar nuestro
“sistema” de diseñadores, desarrolladores, gerentes de productos, ingenieros de
aseguramiento de la calidad, comercializadores y otros en una colaboración transparente
y multifuncional que atrae a los no diseñadores a nuestro proceso de diseño.Lean UX es
un proceso transparente que no solo revela lo que hacen los diseñadores, sino que fomenta
la participación de todos los miembros del equipo.

Por último, y quizás lo más importante, es el cambio de mentalidad que obtenemos al

adoptar un modelo basado en la experimentación y el aprendizaje validado. En lugar de
depender de una sola persona (un diseñador héroe, el ingeniero principal, una parte
interesada de la empresa) para adivinar la mejor solución desde un único punto de vista,
utilizamos la experimentación y la medición rápidas para tener una visión de afuera hacia
adentro de la experiencia que vivimos. volver a crear. Nos esforzamos por aprender
rápidamente, para descubrir, qué tan bien (o mal) nuestras ideas satisfacen las necesidades
de nuestros clientes. En todo esto, el rol del diseñador comienza a evolucionar más allá
de la mera creación de artefactos hacia la facilitación del diseño, y con eso, asumimos un
nuevo conjunto de responsabilidades.

Además de Lean Startup, Lean UX tiene otras dos bases: pensamiento de

diseño y filosofías de desarrollo ágil .El pensamiento de diseño nos ayuda a
ampliar el alcance de nuestro trabajo más allá de las interfaces y los artefactos. El
pensamiento de diseño analiza los sistemas y nos ayuda a aplicar las herramientas
de diseño a problemas más amplios. Se basa en la colaboración, la iteración, la
creación y la empatía como elementos fundamentales para la resolución de
problemas. Quizás lo más importante del pensamiento de diseño es su enfoque en
generar empatía, en todo el equipo, para el usuario final. Practicar Lean UX
significa que todo el equipo desarrolla esta empatía.Agile reenfoca el desarrollo
de software en ciclos más cortos, entrega regular de valor y aprendizaje
continuo. Busca hacer llegar ideas (a menudo como software funcional) a los
clientes rápidamente, sentir cómo se reciben estas ideas y responder con
frecuencia a nuevos aprendizajes a lo largo del camino. Como dice la guía de
Scrum: inspecciona y adapta.

Lean UX utiliza estos fundamentos para unir la velocidad de Agile y la necesidad de

diseño en el ciclo de vida del desarrollo de productos. Si ha tenido problemas para
descubrir cómo el diseño de UX puede funcionar en entornos ágiles, Lean UX es la
respuesta.

Lean UX rompe las barreras que han mantenido a los diseñadores de software aislados de
las necesidades comerciales reales, por un lado, y de la implementación real, por el
otro. Lean UX no solo trae diseñadores a la mesa, sino que también trae a nuestros socios
en administración de productos, negocios y tecnología a la pizarra para trabajar con
nosotros en las mejores soluciones de manera continua.

Al principio de su carrera, Jeff trabajó con un gran cliente farmacéutico que había
contratado a la agencia para la que trabajaba para rediseñar su plataforma de comercio
electrónico. El objetivo era aumentar los ingresos en un 15%. Jeff era el diseñador de
interacción principal del equipo. En el vacío de su oficina, Jeff y su equipo pasaron meses
investigando el sistema actual, la cadena de suministro, los competidores, el público
objetivo y los escenarios de uso contextual. Investigaron personas y ensamblaron
modelos estratégicos. Jeff diseñó una nueva arquitectura de información para el catálogo
de productos y creó una nueva experiencia de compra y pago.

El proyecto llevó meses. Y cuando el trabajo estuvo completo, el equipo lo empaquetó

todo en una plataforma de diapositivas de PowerPoint. Este era un mazo formidable, ¡y
tenía que serlo, considerando el precio de $ 600,000! El equipo fue a la oficina del cliente
y pasó un día completo de ocho horas repasando todos y cada uno de los píxeles y palabras
de esa plataforma. Cuando terminó, el cliente aplaudió. (Realmente lo hicieron). Jeff y el
equipo se sintieron aliviados. Al cliente le encantó el trabajo. Y el equipo de Jeff nunca
volvió a mirar esa baraja.
Seis meses después de esa reunión, nada había cambiado en el sitio del cliente. El cliente
tampoco volvió a mirar esa baraja.

La moraleja de esta historia: la construcción de una especificación perfecta en píxeles

puede ser una ruta para obtener tarifas de consultoría de seis cifras, pero no es una forma
de marcar una diferencia significativa en un producto real que es crucial para los usuarios
reales. Tampoco es la razón por la que un diseñador entró en el negocio del diseño de
productos. Nos pusimos manos a la obra para crear productos y servicios valiosos, no
para escribir especificaciones.

Cuando practicamos Lean UX, nos aseguramos de que estamos resolviendo un problema
real para los clientes reales de una manera significativa. Algunos equipos con los que
trabajamos hoy crean productos o servicios completamente nuevos. No funcionan dentro
de un marco o estructura de producto existente. En proyectos “greenfield” como estos,
simultáneamente estamos tratando de descubrir cómo se utilizará este nuevo producto o
servicio, cómo se comportará y cómo lo vamos a construir. Lo más importante es que
queremos validar que está resolviendo un problema significativo para su público
objetivo. Este es un entorno de cambio continuo y no hay mucho tiempo ni paciencia para
planificar o diseñar por adelantado.

Otros equipos trabajan con productos establecidos que fueron creados con métodos
tradicionales de diseño y desarrollo. Su desafío es diferente. Los sistemas en los que
trabajan se desarrollaron para satisfacer las necesidades de un período de tiempo
específico. El rápido ritmo de cambio en el mercado significa que esas necesidades
probablemente hayan evolucionado. Estos equipos necesitan optimizar estas plataformas
existentes para hacer frente a nuevas realidades al tiempo que aumentan los ingresos y el
valor de la marca. Por lo general, tienen más recursos a su disposición que una startup de
planta baja, pero aún tienen que usar sus recursos de manera eficiente, descubriendo la
mejor manera de gastar esos recursos para crear productos y servicios que sus clientes
realmente desean.

Quizás uno de los cambios más difíciles que Lean UX nos pide que hagamos es superar
la sensación de que estamos mostrando un trabajo en un estado “inacabado” o
“feo”. Incluso hoy, después de casi 15 años de trabajar de esta manera, todavía luchamos
con este. Hemos aprendido a lo largo de los años que nuestro primer intento
inevitablemente requerirá una revisión. Así que cuanto antes saquemos nuestras ideas,
antes podremos averiguar cuáles deberían ser esas revisiones. Esperar demasiado para
obtener esa retroalimentación es un desperdicio. Invertimos demasiado en el diseño
inicial y somos menos flexibles a los cambios debido al esfuerzo que ya hemos realizado.
Cuanto antes sepamos qué cambios deben realizarse, menos invertiremos en la idea
actual. Dolerá menos cambiar de rumbo.Aceptar la naturaleza iterativa del diseño y, en
términos más generales, del software requiere el apoyo de un equipo colaborativo,
humilde y de alto funcionamiento. Necesita saber, como equipo, que no va a hacer las
cosas bien la primera vez y que todos están trabajando juntos para repetir el camino a
seguir. La implementación del código no es la medida del éxito de un equipo de Lean
UX. Es el impacto positivo que tiene en sus clientes.

Hay muchos elementos que afectan el éxito de los sistemas digitales. El diseño es sin
duda un componente importante, pero la gestión de productos, la ingeniería, el marketing,
los aspectos legales, el cumplimiento y la redacción publicitaria (por nombrar algunos)
tienen un impacto en el sistema. Ninguna disciplina tiene todas las respuestas. Con ese
fin, ningún punto de vista tiene todas las respuestas tampoco.Cuanto mayor sea la
diversidad de su equipo (diversidad de género, diversidad racial, etc.), más innovadoras
y de mayor alcance serán las soluciones que generará el equipo. La inclusión es clave
para una colaboración exitosa. Esta es la naturaleza de nuestro medio digital. La
colaboración amplia crea un mejor trabajo. La revisión y la iteración hacen que los
productos sean mejores. En las páginas de este libro, hemos resumido los conocimientos
y las tácticas que nos han permitido adoptar este punto de vista y crear un éxito real para
los equipos de productos y negocios, y una satisfacción real para los clientes.

¿Para quién es Lean UX?

Este libro es, en primer lugar, para diseñadores de productos que saben que pueden
contribuir más y ser más eficaces con sus equipos. Dicho eso, creemos queLa
"experiencia del usuario" es la suma total de todas las interacciones que un usuario tiene
con su producto y servicio. Se crea a partir de todas las decisiones que usted y su equipo
toman sobre ese producto o servicio. No es solo la interfaz de usuario o la
funcionalidad. También se trata de precios, experiencia de compra, incorporación,
soporte, etc. En otras palabras, la experiencia del usuario la crea todo el equipo. Por esa
razón, este libro también es para gerentes de producto que necesitan mejores formas de
definir sus productos con sus equipos y validarlos con sus clientes. También es para los
desarrolladores y maestros de Scrum que entienden que un entorno de equipo ágil y
colaborativo conduce a un mejor código y un trabajo más significativo. Y, finalmente, es
para gerentes: gerentes de equipos de UX, equipos de proyectos, líneas de negocios,
departamentos,

¿Tú qué sacas de esto?

El libro está dividido en cuatro secciones.

La Parte I, Introducción y principios , proporciona una descripción general y una

introducción a Lean UX y sus principios fundamentales. Exponemos las razones por las
que la evolución del proceso de diseño de UX es tan crítica y describimos Lean
UX. También discutimos los principios subyacentes que deberá comprender para que
Lean UX tenga éxito en sus entornos de trabajo ágiles.

La Parte II, Proceso , presenta el lienzo Lean UX y recorre cada uno de sus ocho
pasos. También compartimos ejemplos de cómo nosotros y otros hemos hecho estas cosas
en el pasado.

La Parte III, Colaboración , analiza en profundidad la colaboración entre diseñadores y

otras disciplinas, e introduce herramientas y estudios de casos para reunir varias formas
populares de trabajo, como sprints de diseño, sistemas de diseño e investigación
colaborativa con Lean UX. Finalmente, compartimos algunas consideraciones para
integrar mejor Lean UX en los ritmos de un proceso ágil.

La Parte IV, Lean UX en su organización , aborda la integración de las prácticas Lean

UX en su organización. Discutimos los cambios organizacionales que deben tener lugar
a nivel corporativo, a nivel de equipo y a nivel de contribuyente individual para que estas
ideas realmente se afiancen.

Nuestra esperanza es que este libro continúe sirviendo como un camino a seguir para los
diseñadores de UX, sus colegas y equipos de productos en todas las organizaciones que
aún esperan la "fase dos". Aunque el libro está lleno de tácticas y técnicas para ayudarlo
a desarrollar sus procesos, nos gustaría que recuerde que Lean UX es, en esencia, una
mentalidad.

—Jeff y Josh
Parte I. Introducción y principios
Acerca de la parte I
En esta primera parte, proporcionamos una introducción a Lean UX y sus principios
fundamentales. Discutimos por qué la evolución del proceso de diseño y desarrollo de
productos es tan crítica y describimos qué es Lean UX. También discutimos los principios
subyacentes que deberá comprender para que Lean UX funcione en su organización.

El Capítulo 1, Más importante ahora que nunca , proporciona una breve historia del
diseño y desarrollo de productos y por qué es hora de que ese proceso evolucione.

En el Capítulo 2, Principios , presentamos un análisis detallado de los principios clave

que impulsan el proceso Lean UX. Estos principios ofrecen un marco para un proceso de
descubrimiento y diseño de productos más ágil, y también proporcionan pautas de gestión
básicas para estos equipos. Son fundamentales para el éxito de Lean UX y, si se
incorporan a su organización, tendrán un impacto profundo en su cultura y en la
productividad y el éxito de sus equipos.

El Capítulo 3, Resultados , se centra en la idea de resultados, que siempre han sido un

concepto importante en Lean UX, pero a lo largo de los años, hemos desarrollado nuevas
formas de pensar y trabajar con ellos. Debido a que los resultados son tan críticos para
Lean UX, hemos ampliado nuestra discusión sobre este concepto. Este capítulo comparte
con usted nuestra comprensión actual de la idea.
Capítulo 1. Más importante ahora que
nunca
No es iteración si lo haces solo una vez.

Jeff Patton

El diseño siempre está evolucionando

Cuando los diseñadores llevaron por primera vez su oficio al software en los años 80 y
90, abordaron el trabajo de la misma manera que abordaron los materiales anteriores con
los que trabajaron. En diseño industrial, diseño de impresión, diseño de moda o cualquier
campo que involucre productos físicos, el paso de fabricación es una restricción crítica. Al
diseñar para materiales físicos, los diseñadores deben averiguar qué están haciendo antes
de comenzar la producción, porque la producción es costosa. Es caro montar una fábrica
para producir artículos o prendas de vestir. Es caro configurar una imprenta para una
tirada de impresión.

Al trabajar en software, los diseñadores se enfrentaron a nuevos desafíos. Tuvieron que

descifrar la gramática de este nuevo medio y, al hacerlo, vieron emerger nuevas
especialidades como el diseño de interacción y la arquitectura de la información. Pero
el procesopor qué los diseñadores practicaron permaneció en su mayoría
incuestionable. Los diseñadores seguían diseñando productos con gran detalle por
adelantado, porque todavía tenían que lidiar con un proceso de "fabricación": el trabajo
tenía que ser duplicado en disquetes y CD, que luego se distribuían al mercado
exactamente de la misma manera que los productos físicos. repartido. El costo de hacerlo
mal sigue siendo alto. Sin embargo, paradójicamente, esta forma de trabajar no evitó que
nadie se equivocara. Con demasiada frecuencia, los diseñadores trabajaron de forma
aislada, en silos, antes de pasar su trabajo a los desarrolladores, quienes a su vez
trabajaron en un silo antes de pasar el trabajo al control de calidad, y así sucesivamente. Y
todos trabajaban con comentarios limitados del mercado.

Hoy nos enfrentamos a una nueva realidad. La producción de software se ha vuelto

continua. Internet ha cambiado la forma en que distribuimos software. La proliferación
de dispositivos móviles, wearables e Internet de las cosas ha cambiado la forma en que lo
consumimos. Ya no estamos limitados por un proceso de fabricación físico, y podemos
poner nuestros productos y servicios digitales en manos de los clientes a un ritmo sin
precedentes hace unos años.

Esto lo cambia todo.

Los equipos ahora se enfrentan a una intensa presión de los competidores que utilizan
técnicas como el desarrollo de software ágil, la integración continua y la implementación
continua para reducir radicalmente los tiempos de ciclo. Tomemos a Amazon como
ejemplo. El gigante del comercio electrónico envía un nuevo código en vivo a sus
clientes cada segundo de cada minuto . 1 Y están utilizando estos ciclos cortos como
una ventaja competitiva: lanzan pronto y con frecuencia, obtienen comentarios del
mercado e iteran en función de lo que aprenden acrear una conversación continua con los
clientes. En esencia, están descubriendo su producto al mismo tiempo que lo
están entregando . Esto tiene muchos resultados, pero estos son quizás los dos más
importantes:

• La capacidad de aprender, de forma continua y rápida, qué tan bien sus productos
satisfacen las necesidades del cliente.
• Incrementar las expectativas de los clientes en términos de calidad del producto y
tiempos de respuesta de la empresa a sus inquietudes y comentarios.

Además, esta nueva forma de trabajar no se basa en tecnologías costosas. Las plataformas
y servicios que hacen esto posible están disponibles de forma gratuita o casi gratuita para
casi todos los equipos de inicio. Esto expone a las empresas establecidas a una amenaza
que no conocían antes. Específicamente, las barreras de entrada, en casi todos los
dominios, nunca han sido más bajas. Sin la necesidad de "fabricar" un producto físico,
cualquier persona con acceso a la web puede diseñar, codificar e implementar servicios
para cualquier otra persona. Frente a estas nuevas amenazas, los enfoques tradicionales
de "resolverlo todo primero" simplemente no son viables. Entonces, ¿qué deberían hacer
los equipos de producto?

Es tiempo de un cambio.

Lean UX es la evolución del diseño de productos y la colaboración en equipo.Toma las

mejores partes del conjunto de herramientas del diseñador, las combina con el desarrollo
de software ágil y el pensamiento Lean Startup, y pone todo esto a disposición de todo el
equipo de producto. Permite a los equipos explotar esta nueva realidad para maximizar el
aprendizaje, descubrir continuamente el mejor camino a seguir y amplificar la voz del
cliente.

Lean UX es profundamente colaborativo y multifuncional porque los diseñadores,

gerentes de producto e ingenieros de software ya no pueden darse el lujo de trabajar
aislados unos de otros. Se acabaron los días del proceso de la cascada. El trabajo es
continuo. No podemos permitirnos esperar el trabajo de otros, ni podemos hacer que otros
esperen nuestro trabajo. En cambio, necesitamos un compromiso diario y continuo con
nuestros colegas si queremos tener éxito.Este compromiso continuo nos permite eliminar
los entregables pesados (y el tiempo requerido para crearlos) en favor de técnicas que
construyen un entendimiento compartido con nuestros compañeros de equipo. La
comprensión compartida permite a nuestros equipos tomar decisiones más rápido y nos
permite participar en conversaciones más estratégicas. Sí, todavía tenemos la
responsabilidad de obtener los detalles correctos: crear hermosos elementos de interfaz y
elegantes flujos de trabajo, y pensar en todas las pequeñas cosas que hacen que el diseño
de un producto funcione, desde la accesibilidad hasta los tiempos de carga de la página,
y desde las etiquetas de los botones hasta los mensajes de error. Pero al eliminar los gastos
generales de comunicación, tenemos más tiempo para concentrarnos en actividades más
fundamentales, como recopilar información que pueda afectar las elecciones estratégicas
de nuestro producto.

Lean UX también nos permite cambiar la forma en que hablamos de diseño. En lugar de
hablar acerca de las características y documentos, podemos hablar de lo que funciona -
los resultados que estamos tratando de crear. En esta nueva realidad, tenemos más acceso
a los comentarios del mercado que nunca. Esto nos permite replantear las conversaciones
de diseño en términos de objetivos comerciales, de clientes y de usuarios. Podemos medir
lo que funciona, aprender y ajustar.

Lean UX es tres cosas. Comienza como un cambio de proceso para diseñadores y equipos
de productos. Pero es mucho más que eso. Es un cambio de cultura que nos permite
abordar nuestro trabajo con humildad; reconocemos que nuestras soluciones iniciales
probablemente serán incorrectas y usamos muchas fuentes de conocimiento para mejorar
continuamente nuestro pensamiento. Finalmente, implica un conjunto de cambios
organizacionales en la forma en que organizamos y gestionamos los equipos de diseño y
desarrollo de software para que sean más inclusivos, colaborativos y
transparentes. Profundizaremos en cada uno de estos aspectos de Lean UX en el resto del
libro.

Sin embargo, quizás la mejor manera de resumir esta introducción es esta: Lean UX es la
forma en que necesitamos trabajar ahora .

1JonJenkins, “Velocity 2011: Jon Jenkins, 'Velocity Culture'”, O'Reilly, 20 de junio de

2011, video de YouTube, 15:13, https://oreil.ly/Yh7Co ; Joe McKendrick, “How
Amazon Handles a New Software Deployment Every Second”, ZDNet, 24 de marzo de
2105, https://oreil.ly/zXFoo ; Werner Vogels, "The Story of Apollo - Amazon's
Deployment Engine", All Things Distributed, 12 de noviembre de
2014, https://oreil.ly/HrMRs .
Capítulo 2. Principios
Ve por ese camino. Realmente rápido. ¡Si algo se interpone en tu camino, gira!

Mejor muerto (1985)

En el corazón de Lean UX, encontrará un conjunto básico de principios que rigen

el proceso de diseño , la cultura del equipo y la organización del equipo . Trate estos
principios como un marco. Comience con ellos para que sus equipos apunten en la
dirección correcta y téngalos en cuenta cuando comience a implementar los procesos
Lean UX que describimos más adelante en este libro. Es muy importante entender que
Lean UX no esun conjunto de reglas. En cambio, es un enfoque que adoptas. Dada la
infinita variedad de contextos en los que trabajan los equipos de productos y las diferentes
industrias, empresas, culturas, regulaciones, clientes y misiones a las que sirven los
diseñadores, es inevitable que necesite ajustar los procesos que describimos para que
funcionen en su organización. Los principios de este capítulo le proporcionarán una guía
para ayudarle a realizar esos ajustes.

En última instancia, si puede aplicar los principios, descubrirá que cambiará la cultura de
su equipo. Algunos principios tendrán más impacto que otros y será más difícil actuar
sobre algunos. Independientemente, cada principio descrito aquí lo ayudará a construir
una organización de diseño de productos que sea más colaborativa, más multifuncional y
se ajuste mejor a la realidad ágil de hoy.

Los fundamentos de Lean UX

Lean UX se basa en una serie de importantes fundamentos: es una combinación de
algunas escuelas de pensamiento diferentes. Comprender de dónde viene le ayudará a
aplicar los métodos y encontrar recursos cuando se quede atascado.

La primera base de Lean UX es el diseño de la experiencia del usuario .Lean UX es, en

esencia, una forma de practicar el diseño de la experiencia del usuario. Basándose en las
raíces en los campos de los factores humanos y la ergonomía, así como en las ideas de
diseño centradas en el ser humano que surgieron en la década de 1950 con el trabajo
dediseñadores industriales como Henry Dreyfuss, estos métodos y mentalidades se
conocen hoy como diseño de experiencia de usuario (o simplemente UX), unTérmino
acreditado a Don Norman. 1 UX abarca una serie de campos de diseño, incluido el diseño
de interacción, la arquitectura de la información, el diseño gráfico y muchos otros. Pero
el corazón de la práctica de UX es que comienza identificando las necesidades humanas,
las necesidades de los usuarios del sistema.

En la última década, hemos visto un aumento en la popularidad

del pensamiento de diseño . El pensamiento de diseño surgió en la academia en las
décadas de 1970 y 1980 y fue popularizado por la firma de diseño IDEO a principios de
la década de 2000. Es una forma de aplicar métodos de diseño centrados en el ser humano
a una amplia gama de problemas. Tim Brown, director ejecutivo y presidente de IDEO,
describió el pensamiento de diseño como "innovación impulsada por ... la observación
directa de lo que las personas quieren y necesitan en sus vidas y lo que les gusta o no les
gusta de la forma en que se fabrican, empaquetan, comercializan y venden productos
específicos". y apoyado ". 2

Brown continuó: "[es] una disciplina que utiliza la sensibilidad y los métodos del
diseñador para hacer coincidir las necesidades de las personas con lo que es
tecnológicamente factible y lo que una estrategia comercial viable puede convertir en
valor para el cliente y oportunidad de mercado".

El pensamiento de diseño es importante para Lean UXporque adopta la posición explícita

de que todos los aspectos de una empresa (o cualquier otro sistema) pueden abordarse
con métodos de diseño. Da permiso a los diseñadores para trabajar más allá de sus límites
típicos. También alienta a los no diseñadores a utilizar métodos de diseño para resolver
los problemas que enfrentan en sus roles. Entonces, UX y su primo, el pensamiento de
diseño, forman la primera base fundamental que alienta a los equipos a considerar las
necesidades humanas, colaborar con roles que no son de diseño y abordar el diseño de
productos desde una perspectiva holística.

La siguiente base de Lean UX es el desarrollo de software ágil .Los desarrolladores de

software han estado utilizando métodos ágiles durante años para reducir sus tiempos de
ciclo, crear una cadencia de aprendizaje continuo y ofrecer valor al cliente con
regularidad. Aunque los métodos ágiles pueden plantear desafíos de proceso para los
diseñadores (que le mostraremos cómo resolver en las Partes II y III), los valores centrales
de Agile están perfectamente alineados con Lean UX. Lean UX aplica los cuatro valores
fundamentales del desarrollo ágil al diseño de productos:

1. Individuos e interacciones sobre procesos y herramientas.

Lean UX favorece la colaboración y la conversación sobre los entregables y el

proceso rígido.Involucra a todo el equipo para generar ideas desde diversos puntos
de vista. Fomenta el intercambio de ideas libre y frecuente para permitir que el
equipo debata, decida y avance rápidamente.

2. Software de trabajo sobre documentación completa.

Cada problema empresarial tiene infinitas soluciones, y cada miembro de un El

equipo tendrá una opinión sobre cuál es la mejor. El desafío es averiguar qué
solución es más viable. A veces, es difícil o imposible predecir de antemano qué
solución funcionará. Al poner nuestras ideas en manos de los clientes (a menudo
a través de software de trabajo) antes, el equipo puede evaluar rápidamente las
soluciones para el ajuste y la viabilidad del mercado.

3. Colaboración con el cliente sobre negociación de contratos.

Colaborando con sus compañeros de equipo y clientesconstruye una comprensión

compartida del espacio del problema y las soluciones propuestas. Crea consenso
detrás de las decisiones. ¿El resultado? Iteraciones más rápidas, participación real
en la fabricación de productos e inversión del equipo en el aprendizaje
validado. También reduce la dependencia de la documentación pesada porque
todos los miembros del equipo ya han participado en la toma de decisiones. La
 colaboración crea alineación de manera más efectiva que la comunicación escrita,
los argumentos y la defensa elaborada.

4. Responde al cambio sobre el siguiente plan.

La suposición en Lean UX es que los diseños de sus productos iniciales estará al

menos parcialmente equivocado, por lo que el objetivo del equipo debería ser
descubrir qué se equivocaron lo antes posible. Tan pronto como el equipo
descubre qué funciona y qué no, ajusta sus propuestas y vuelve a probar. Esta
información del mercado mantiene ágiles a los equipos, empujándolos
constantemente en una dirección "más correcta".

La base final de Lean UX es el método Lean Startup de Eric Ries .Lean Startup utiliza
un circuito de retroalimentación llamado "construir-medir-aprender" para minimizar el
riesgo del proyecto y hacer que los equipos construyan y aprendan rápidamente. Los
equipos crean productos mínimos viables (MVP) y los envían rápidamente para
comenzar el proceso de aprendizaje lo antes posible.

Como dice Eric, "Lean Startup aboga inicialmente por la creación de prototipos rápidos
diseñados para probar los supuestos del mercado y utiliza los comentarios de los clientes
para hacerlos evolucionar mucho más rápido que a través de prácticas de ingeniería de
software más tradicionales ". 3

Continúa: "Los procesos Lean Startup reducen el desperdicio al aumentar la frecuencia

de contacto con clientes reales, por lo tanto, prueban y evitan supuestos de mercado
incorrectos lo antes posible".

Lean UX es una aplicación directa de esta filosofía a la práctica del diseño de productos.

Cada diseño es una solución empresarial propuesta: una hipótesis. Su objetivo es validar
la solución propuesta de la manera más eficiente posible utilizando los comentarios de
los clientes. Lo más pequeño que puede construir para probar cada hipótesis es su
MVP. No es necesario que el MVP esté hecho de código: puede ser una aproximación de
la experiencia final, ¡puede que ni siquiera sea un producto! Recopila lo que aprende de
su MVP y desarrolla sus ideas. Entonces lo vuelve a hacer.

Entonces, ¿cuál es la definición de Lean

UX?
Así es como definimos Lean UX:

• Lean UX es un enfoque de diseño que saca a la luz la verdadera naturaleza de un

producto más rápido, de una manera colaborativa, multifuncional y centrada en el
usuario.
• Los métodos Lean UX construyen una comprensión compartida del usuario, sus
necesidades, nuestras soluciones propuestas y nuestra definición de éxito.
 • Lean UX prioriza el aprendizaje continuo para generar evidencia para las
decisiones del equipo y garantizar una entrega de productos, servicios y valor en
constante mejora.

Principios
En el resto de este capítulo, expondremos los principios detrás de Lean UX. Mientras
explora este enfoque, tenga en cuenta estos principios. Piense en su experiencia con Lean
UX como un viaje de aprendizaje. Utilice estos principios para mantener el rumbo
correcto para usted y su equipo.

Hemos organizado estos principios en tres grupos: principios para guiar la organización
del equipo , principios para guiar la cultura y principios para guiar el proceso .

Principios para guiar la organización del equipo

Comencemos por echar un vistazo a los principios de Lean UX relacionados con

la organización de equipos :

• Multifuncional
• Pequeño, dedicado, ubicado
• Autosuficiente y empoderado
• Centrado en el problema

Principio: multifuncional

¿Qué es? Los equipos multifuncionales están compuestosde las diversas disciplinas
involucradas en la creación de su producto. Ingeniería de software, gestión de productos,
diseño de interacción, diseño visual, estrategia de contenido, marketing, aseguramiento
de la calidad, todos ellos forman parte de los equipos de Lean UX. Lean UX exige un alto
nivel de colaboración entre estas disciplinas. Su participación debe ser continua desde el
primer día del proyecto hasta el final del compromiso.

¿Por que hacerlo? Los equipos diversos crean mejores soluciones porque cada problema
se ve desde muchos puntos de vista diferentes. La creación de equipos diversos limita la
necesidad de procesos cerrados y basados en transferencias ("cascada"). En cambio, los
equipos pueden compartir información de manera informal, lo que crea colaboración en
una etapa más temprana del proceso e impulsa una mayor eficiencia del equipo.

Principio: pequeño, dedicado, ubicado

¿Qué es? Mantenga sus equipospequeño: no más de 10 personas principales en

total. Dedíquelos a un proyecto y póngalos en el mismo lugar.

¿Por que hacerlo? El beneficio de los equipos pequeños se reduce a tres

palabras:comunicación, enfoque y camaradería. Los equipos más pequeños son más
fáciles de mantenerse actualizados sobre el estado del proyecto, los cambios y el nuevo
aprendizaje. Dedicar su equipo a un proyecto mantiene a los miembros del equipo
enfocados en las mismas prioridades todo el tiempo y elimina las dependencias de otros
equipos. Tener todo el equipo en un solo lugar permite que las relaciones entre colegas
crezcan.

UNA NOTA SOBRE LA COLOCACIÓN

En 2020, debido a la pandemia de COVID-19, nuestra industria se vio obligada a aprender

mucho sobre el trabajo remoto.Hablaremos sobre el trabajo remoto con más profundidad
más adelante en el libro, pero por ahora, queremos comentar este principio y por qué
seguimos abogando por la colocación. La “colocación” se trata de reunir a las personas
en el mismo espacio físico. Aprendimos el año pasado que podemos reunir equipos en un
espacio virtual compartido y crear experiencias similares. Esta forma de trabajar tiene
algunos beneficios (pijamas, gatos y menos tiempo de desplazamiento) y algunos
inconvenientes (pijamas, gatos y herramientas de colaboración digital incómodas). Sin
embargo, en general, creemos que el núcleo de lo que hace que la colocación sea poderosa
es la forma en que fomenta la comprensión compartida. Alienta a los equipos a tener
conversaciones casuales y no planificadas y hace que las colaboraciones de varias
personas con gran ancho de banda sean mucho más fáciles. Aunque hemos aprendido
mucho sobre el trabajo remoto y hemos aprendido a hacerlo funcionar, Creemos que
pierde algo cuando no están juntos en una habitación. Entonces, si está trabajando de
forma remota, por cualquier motivo, intente hacerlo de una manera que limite las
transferencias, fomente la colaboración informal y busque los otros beneficios sutiles de
sentarse en la misma habitación con sus colegas.

Principio: autosuficiente y empoderado

¿Qué es? Brinde a sus equipos todas las capacidadesnecesitan operar sin dependencias
externas. Asegúrese de que tengan las herramientas que necesitan para crear y lanzar
software. Déles permiso para descubrir cómo resolver los problemas que enfrentan y para
interactuar con los usuarios y clientes a través del contacto de primera mano.

¿Por que hacerlo? Los equipos sin dependencias externas pueden optimizar su proceso
para lograr la máxima eficiencia. No quieren recursos externos, ni quieren experiencia
externa. Los equipos que pueden crear y lanzar software por sí mismos pueden moverse
a un ritmo rápido y pueden maximizar su aprendizaje.Finalmente, los equipos no pueden
aprender del mercado si no se les permite interactuar con el mercado. Los equipos deben
poder interactuar con los clientes directamente para obtener la retroalimentación que
necesitan para crear soluciones efectivas.

Principio: centrado en el problema

¿Qué es? Un equipo centrado en problemas esuno al que se le ha asignado un problema

empresarial o de usuario para resolver en lugar de un conjunto de características para
implementar. En otras palabras, este es un equipo que se ha organizado en torno a un
resultado.

¿Por que hacerlo? Asignar problemas a los equipos para resolver demuestra confianza en
esos equipos. Les permite proponer sus propias soluciones e impulsa un sentido más
profundo de orgullo y propiedad en las soluciones que implementa el equipo.También
cambia el aspecto de "hecho"; en lugar de simplemente enviar una función, los equipos
que tienen el espacio para resolver realmente los problemas normalmente tendrán que
iterar hasta que el problema se resuelva realmente.

Principios para guiar la cultura

La cultura y el proceso son inseparables. Adoptar Lean UX significa adoptar una cultura
de aprendizaje y curiosidad. Estos son los principios de Lean UX que pueden ayudar a
guiar su cultura hacia ese estado final:

• Pasando de la duda a la certeza

• Resultados, no salida
• Eliminando residuos
• Entendimiento compartido
• Sin estrellas de rock, gurús o ninjas
• Permiso para fallar

Principio: Pasar de la duda a la certeza

¿Qué es? El desarrollo de software es complejo e impredecible. Debido a esto, Lean UX

comienza con la idea de que todo es una suposición hasta que demostremos lo
contrario. A medida que trabajamos, ganamos claridad. Por lo tanto, siempre estamos
pasando de una posición de duda a una de certeza.

¿Por que hacerlo? Todo proyecto comienza con una serie de supuestos. A veces, estas
suposiciones son fáciles de detectar; a veces no los vemos hasta que es demasiado
tarde. Para eliminar el riesgo de invertir mucho tiempo y esfuerzo en un trabajo que se
basa en suposiciones erróneas, comenzamos por validar nuestras
suposiciones. Adoptamos una mentalidad de escepticismo entusiasta . Esto significa que
partimos de la duda y procedemos a validar lo que sabemos, de la forma más sistemática
y rigurosa posible. En el proceso, nuestro aprendizaje nos permite estar más seguros de
nuestras posiciones mientras buscamos mejoras continuas en nuestro trabajo.

Principio: resultados sobre producción

¿Qué es? Las características y los servicios son salidas .Los objetivos que deben alcanzar
son resultados .En Lean UX, los equipos intentan sobre todo crear un resultado: un
cambio medible en el comportamiento humano que crea valor. Lean UX mide el
progreso en términos de resultados explícitamente definidos.

¿Por que hacerlo? Cuando intentamos predecir qué características lograrán resultados
específicos, en su mayoría nos dedicamos a la especulación. Aunque es más fácil
administrar el lanzamiento de conjuntos de funciones específicas, a menudo no podemos
predecir si una función será efectiva hasta que esté en el mercado. Al administrar los
resultados (y el progreso logrado hacia ellos), obtenemos información sobre la eficacia
de las funciones que estamos construyendo. Si una función no funciona bien, podemos
tomar una decisión objetiva sobre si debe conservarse, cambiarse o reemplazarse.
Principio: eliminación de residuos

¿Qué es? Uno de los principios básicos enLa manufactura esbelta es la eliminación de
todo lo que no conduce al objetivo final. En Lean UX, el objetivo final es mejorar los
resultados; por lo tanto, cualquier cosa que no contribuya a eso se considera desperdicio
y debe eliminarse del proceso del equipo.

¿Por que hacerlo? Los recursos del equipo son limitados. Cuanto más pueda eliminar un
equipo el desperdicio, más rápido podrá moverse. Los equipos quieren trabajar en los
desafíos correctos. Quieren ser efectivos. Pensar en términos de creación de valor y
eliminación de residuos puede ayudar a los equipos a mantener su enfoque láser donde
corresponde.Pensar en el desperdicio, y específicamente eliminarlo, nos permite pensar
críticamente sobre nuestro proceso de diseño. Nos anima a pensar en la mejora continua
en la forma en que trabajamos. Pero no se trata solo del proceso. ¿Cuál es el desperdicio
final? Hacer cosas que la gente no quiere. No hagas eso. Concéntrese en el usuario y
utilice su energía para ofrecer cosas valiosas.

Principio: entendimiento compartido

¿Qué es? El entendimiento compartido es elconocimiento colectivo que se acumula con

el tiempo a medida que el equipo trabaja en conjunto. Es una gran comprensión del
espacio, el producto y los clientes.

¿Por que hacerlo? El entendimiento compartido es la moneda de Lean UX. Cuanto más
entienda un equipo colectivamente lo que están haciendo y por qué, menos necesitarán
debatir lo que sucedió y podrán pasar rápidamente a cómo resolver el nuevo
aprendizaje. Además, reduce la dependencia del equipo de informes de segunda mano y
documentos detallados para continuar su trabajo. Cuanto más pueda crear una
comprensión compartida de lo que necesitan los usuarios, más podrá superar el ego, los
juegos de poder y las decisiones de diseño autorreferenciales.

Principio: no estrellas de rock, gurús o ninjas

¿Qué es? Lean UX aboga por una mentalidad basada en equipos.Estrellas de rock, gurús,
ninjas: utilizamos estas etiquetas para describir estrellas individuales. En lugar de
centrarse en los artistas estrella, Lean UX busca la cohesión y la colaboración del equipo.

¿Por que hacerlo? Las estrellas de rock no comparten, ni sus ideas ni el centro de
atención. La cohesión del equipo se rompe cuando agrega individuos con grandes egos
que están decididos a sobresalir y ser estrellas. Cuando la colaboración se rompe, pierde
el entorno que necesita para crear la comprensión compartida necesaria para avanzar de
manera eficaz.

Principio: permiso para fallar

¿Qué es? Para encontrar la mejor solución a los problemas empresariales, Lean UXlos
equipos necesitan experimentar con ideas. La mayoría de estas ideas fallarán. El permiso
para fallar significa que el equipo tiene un entorno seguro en el que experimentar. Eso
se aplica tanto al entorno técnico (pueden impulsar ideas de una manera técnicamente
segura) como al entorno cultural (no se les penalizará por probar ideas que no tengan
éxito).

¿Por que hacerlo? El permiso para fallar es la plataforma sobre la que se construye una
cultura de experimentación. La experimentación genera creatividad. La creatividad, a su
vez, produce soluciones innovadoras. Cuando los equipos no temen por su trabajo si
hacen algo mal, son más propensos a correr riesgos. De esos riesgos surgen, en última
instancia, las grandes ideas.

LAS VIRTUDES DE LA MEJORA CONTINUA

En un video llamado "Por qué necesitas fallar", el fundador de CD Baby, Derek Sivers,
describe los sorprendentes resultados de una cerámica clase. 4

El primer día, el instructor anunció a su clase que los estudiantes se dividirían en dos
grupos. La mitad de los estudiantes solo necesitarían hacer una vasija de barro cada uno
durante el semestre. Sus calificaciones dependerían de la perfección de esa olla
solitaria. La otra mitad de la clase sería calificada simplemente por el peso de las macetas
que hicieron durante el semestre. Si hicieran 50 libras de ollas o más, obtendrían una A.
Cuarenta libras ganarían una B; 30 libras, a C; etcétera. Lo que realmente hicieron fue
irrelevante. El instructor dijo que ni siquiera miraría sus ollas. Simplemente llevaría su
báscula de baño al último día de clase y pesaría el trabajo de los estudiantes.

Al final del semestre había ocurrido algo interesante. Los observadores externos de la
clase notaron que las ollas de la más alta calidad habían sido hechas por el "grupo de
cantidad". Habían pasado todo el semestre trabajando lo más rápido posible para hacer
vasijas. A veces lo lograron y a veces fracasaron. Con cada iteración, cada experimento,
aprendieron. A partir de ese aprendizaje, se volvieron más capaces de lograr el objetivo
final: hacer vasijas de arcilla de alta calidad.

Por el contrario, el grupo que hizo un objeto no se benefició de esas iteraciones fallidas y
no aprendió lo suficientemente rápido para desempeñarse al mismo nivel que el "grupo
de cantidad". Habían pasado el semestre teorizando sobre lo que haría una vasija de barro
de "grado A", pero no tenían la experiencia para ejecutar esa grandiosa visión.

Principios para guiar el proceso

Ahora que tenemos una idea de los principios organizacionales y culturales más amplios,
echemos un vistazo táctico a cómo los equipos deben cambiar la forma en que trabajan:

• No hagas lo mismo más rápido.

• Cuidado con las fases.
• La iteración es la clave de la agilidad.
• Trabaje en pequeños lotes para mitigar el riesgo.
• Adopte el descubrimiento continuo.
• Sal del edificio.
• Exterioriza tu trabajo.
• Rehacer el análisis.
• Salga del negocio de los entregables.
Principio: no hagas lo mismo más rápido

¿Qué es? Cuando los equipos adoptan Agile,los primeros intentos a menudo implican
hacer las mismas cosas que siempre han hecho, solo que más rápido. Esto nunca funciona
bien. No puedes hacer ocho semanas de investigación en dos semanas. Ni siquiera lo
intentes. En cambio, debes comportarte de una manera nueva. Necesitas reconceptualizar
el trabajo.

¿Por que hacerlo? El objetivo de Agile no es trabajar rápido. No es para trabajar en

sprints de dos semanas. El objetivo no es seguir todas las reglas. El objetivo es trabajar
de una manera que sea apropiada para el medio del software y, al hacerlo, crear mejores
productos y servicios que brinden más valor. Entonces, los métodos ágiles nos brindan la
oportunidad de repensar la forma en que trabajamos, la forma en que colaboramos, la
forma en que entregamos valor. A veces, simplemente podemos encajar procesos
antiguos en ritmos ágiles. A veces, no podemos. Cuando eso suceda, no fuerce los
métodos, ¡reconsiderelos!

Principio: cuidado con las fases

¿Qué es? Cada vez que tienes unUna fase de investigación, una fase de diseño, una fase
de desarrollo, una fase de prueba, una fase de endurecimiento (Dios no lo quiera), en
realidad, una fase de cualquier cosa , debería servir como una señal de advertencia de
que algo anda mal. Los equipos ágiles deberían hacer todas estas cosas continuamente,
en cada sprint. Deberías investigar continuamente. Diseñando
continuamente. Construyendo continuamente. Probando… Entiendes el punto.

¿Por qué lo hacemos? El trabajo ágil se basa en una idea fundamental: inspeccionar y
adaptar. Desea tener un trabajo terminado que pueda inspeccionar de forma frecuente
y regular . Las fases, ya sean fases de investigación, fases de diseño, fases de
construcción, lo que sea, no dan como resultado un trabajo terminado. Dan como
resultado pasos de proceso terminados . Para llegar al trabajo terminado, debe pasar del
trabajo por fases al trabajo continuo.

Principio: la iteración es la clave de la agilidad

¿Qué es? Cuando estás rompiendo el trabajo en lotes pequeños, no se conforme con
porciones incrementales. En su lugar, adopte un enfoque iterativo. Espere diseñar y
probar su trabajo, a menudo el mismo trabajo, varias veces hasta que lo haga bien.

¿Por que hacerlo? Muchos equipos ágiles se mezclan enfoques incrementales (dividir una
característica grande en partes pequeñas y entregarla en varios sprints) con enfoques
iterativos (trabajar en una característica una y otra vez para mejorarla). En parte, esto se
debe a que valoramos trabajar en lotes pequeños, y ambos enfoques son de hecho
enfoques de lotes pequeños. Sin embargo, la iteración es un compromiso de rehacer su
trabajo hasta que lo haga bien, hasta que resuelva el problema que está tratando de
resolver, hasta que satisfaga las necesidades del usuario (no simplemente cumpla con las
especificaciones funcionales), hasta que entregue el resultado que usted estás intentando
crear. La iteración también es la clave para acabar con una de las frustraciones más
comunes que experimentan los diseñadores de UX en el mundo Agile: la sensación de
que nunca tenemos el tiempo suficiente para hacerlo bien. Al trabajar en una función
hasta que sea correcta, los equipos tienen la oportunidad de realizar un gran trabajo del
que están orgullosos, que satisfacen al usuario y resuelven el problema que la empresa se
propone resolver.

Principio: trabajar en pequeños lotes para mitigar el riesgo

¿Qué es? Otro fundamental de la fabricación ajustada es la práctica de dividir el trabajo

en pequeñas unidades o lotes. La manufactura esbelta utiliza esta noción para mantener
el inventario bajo y la calidad alta. Traducido a Lean UX, esto significa crear solo el
diseño que es necesario para hacer avanzar al equipo y evitar un gran "inventario" de
ideas de diseño no probadas y no implementadas.

¿Por que hacerlo? Todo proyecto comienza con supuestos. El diseño de lotes grandes
comienza con esas suposiciones no probadas y crea una gran cantidad de trabajo de diseño
además de ellas. Esto significa que, si descubrimos que una suposición fundamental es
incorrecta, debemos desechar mucho trabajo. Al trabajar en lotes más pequeños, podemos
diseñar y validar nuestras decisiones sobre la marcha, lo que reduce el riesgo de
desperdicio de trabajo.

Principio: abrazar el descubrimiento continuo

¿Qué es? El descubrimiento continuo es elproceso continuo de participación del cliente

durante el proceso de diseño y desarrollo. Esto se hace a través de actividades
programadas regularmente, utilizando métodos tanto cuantitativos como cualitativos. El
objetivo es comprender tanto qué hace el usuario con sus productos como por qué lo
hace. Así que investigas con frecuencia y a un ritmo regular. La investigación involucra
a todo el equipo.

¿Por que hacerlo? Las conversaciones regulares con los clientes brindan oportunidades
frecuentes para validar nuevas ideas de productos. La incorporación de todo el equipo al
ciclo de investigación desarrolla la empatía por los usuarios y los problemas a los que se
enfrentan. Creas un entendimiento compartido. Finalmente, a medida que el equipo
aprende en conjunto, reduce la necesidad de futuras conversaciones y documentación.

Principio: sal del edificio

¿Qué es? Esta frase, popularizada porSteve Blank, profesor, emprendedor y autor de
Stanford, se refiere a la práctica de lo que la gente de UX conoce simplemente como
"investigación de usuarios". En el mundo de la manufactura esbelta, escuchará una idea
similar expresada como "ir y ver".

Lo que todas estas comunidades han descubierto de forma conjunta es la idea de que no
encontrará la verdad sobre sus usuarios en una sala de conferencias. Tienes que ir a donde
están, observar lo que están haciendo y realmente interactuar con ellos para entender lo
que están haciendo, lo que están tratando de hacer y por qué lo están tratando de hacer.

Lean UX se alinea con esta receta: brinde a los clientes potenciales la oportunidad de
proporcionar comentarios sobre sus ideas antes de lo que lo haría en el pasado. Mucho
antes. Pon a prueba tus ideas con una fuerte dosis de realidad mientras aún son jóvenes. Es
mejor descubrir que sus ideas no dan en el blanco antes de haber invertido tiempo y
recursos en la creación de un producto que nadie quiere.

¿Por que hacerlo? En última instancia, el éxito o el fracaso de su producto no es decisión

del equipo, es del cliente. Deberán hacer clic en el botón "Comprar ahora" que
diseñó. Cuanto antes les dé una voz, antes sabrá si tiene una idea que funciona.

Principio: externaliza tu trabajo

¿Qué es? Exteriorizar significa conseguir tutrabajar fuera de su cabeza y fuera de su

computadora y a la vista del público. Los equipos usan pizarras, espacios virtuales
compartidos, pizarrones con núcleo de espuma, paredes de artefactos, impresiones y notas
adhesivas para exponer su trabajo en progreso a sus compañeros de equipo, colegas y
clientes.

¿Por que hacerlo? La externalización del trabajo permite que todos vean dónde se
encuentra el equipo. Crea un flujo de información ambiental pasivo en todo el
equipo. Inspira nuevas ideas que se basan en las que ya se han compartido. Permite que
todos los miembros del equipo, incluso los tranquilos, participen en actividades de
intercambio de información. Sus notas adhesivas o bocetos en la pizarra son tan ruidosos
como la persona más prominente del equipo.

Principio: cambio de análisis

¿Qué es? Valores Lean UX que hacen más análisis. Crear la primera versión de una idea
tiene más valor que pasar medio día debatiendo sus méritos en una sala de conferencias.

¿Por que hacerlo? La respuesta a las preguntas más difíciles que enfrentará el equipo no
se responderá en una sala de conferencias; son los clientes en el campo quienes les
responderán. Para obtener esas respuestas, es necesario que las ideas sean concretas; es
necesario crear algo a lo que la gente pueda responder. Debatir ideas sin datos basados
en el mercado es un desperdicio. En lugar de analizar escenarios potenciales, haga algo y
salga del edificio con ello.

Principio: salga del negocio de los entregables

¿Qué es? Lean UX cambia el enfoque del proceso de diseño lejos de los documentos que
el equipo está creando. En cambio, se centra en los resultados que está logrando el
equipo. Con una mayor colaboración interfuncional, la conversación con las partes
interesadas se vuelve menos sobre qué artefacto se está creando y más sobre qué resultado
se está logrando.

¿Por que hacerlo? Los documentos no resuelven los problemas de los clientes, los buenos
productos sí. El enfoque del equipo debe estar en aprender qué funciones tienen el mayor
impacto en sus clientes. Los artefactos que utiliza el equipo para obtener y comunicar ese
conocimiento son irrelevantes. Todo lo que importa es la calidad del producto, medida
por la reacción del mercado al mismo.
Terminando
Este capítulo presenta un conjunto de principios fundamentales para Lean UX. Estos son
los atributos centrales que cualquier equipo de Lean UX debería esforzarse por
incorporar. A medida que comience a formar su práctica, lo alentamos a utilizar estos
principios para definir la composición, la ubicación, los objetivos y las prácticas de su
equipo.

1Don Norman y Jakob Nielsen, "The Definition of User Experience", Nielsen Norman
Group, consultado el 15 de junio de 2021, https://oreil.ly/NxTKY .

2Tim Brown, "Design Thinking", Harvard Business Review , junio de

2008, https://oreil.ly/zl9mr .

3Josh Seiden y Jeff Gothelf, “The 3 Foundations of Lean UX”, O'Reilly Media, 25 de
octubre de 2017, https://oreil.ly/AFDOW .

4DerekSivers, “Why You Need to Fail - by Derek Sivers”, 15 de febrero de 2011, video
de YouTube, 14:54, https://oreil.ly/oZHQe .
Capítulo 3. Resultados
Tradicionalmente, los proyectos de software se enmarcan en requisitos y entregables. Los
equipos reciben requisitos y se espera que creen entregables. Estos entregables
describirán los sistemas, las características y la tecnología que satisfarán esos
requisitos. En muchos casos, los requisitos llegan sin un contexto estratégico. ¿Por qué
estamos haciendo esto? ¿Para quien? ¿Cómo se ve el éxito?

Lean UX cambia radicalmente la forma en que enmarcamos nuestro trabajo al presentar

de nuevo la contexto estratégico para nuestras opciones de características y diseño y, lo
que es más importante, cómo nosotros, todo el equipo, no solo el departamento de diseño,
definimos el éxito. Nuestro objetivo no es crear un producto o una característica: es
afectar positivamente el comportamiento del cliente o cambiar en el mundo, para crear
un resultado.

¿En qué negocio estamos?

Lean UX significa salir del negocio de los entregables. Fueronen el negocio de la
creación de resultados. Debemos centrarnos menos en las cosas que hacemos (la
documentación, las maquetas y los prototipos, las funciones, las páginas y los botones) y
más en generar resultados. Para hacer eso, nos enfocamos solo en hacer cosas que generen
los resultados que queremos.

¿Por qué centrarse en los resultados en lugar de las características y los entregables? Es
porque hemos aprendido que es difícil, y en muchos casos imposible, predecir si las
características que diseñamos y construimos crearán el valor que queremos crear. ¿Este
botón animará a la gente a comprar? ¿Esta función generará más participación? ¿La
gente usará esta función de formas que no predijimos? ¿Cambiaremos con éxito la
forma en que las personas interactúan con nuestro servicio? Por lo tanto, en lugar de
centrarse en las funciones, es mejor centrarse en el valor que estamos intentando crear y
seguir probando soluciones hasta que encontremos una que ofrezca el valor, el resultado,
que deseamos.

Este cambio de énfasis se aplica tanto a las cosas que los diseñadores hacen como parte
de su proceso (documentos, maquetas, estructuras alámbricas, especificaciones,
prototipos) como a la forma en que enmarcamos nuestro trabajo. ¿Cuál es el resultado
que quieren nuestros clientes o stakeholders? Claro, es posible que nos pidan que creemos
un sitio web o una aplicación. Pueden estar pidiendo una nueva página, un nuevo flujo,
una nueva copia. Pero lo preguntan por una razón, y parte de nuestro trabajo es
comprender y articular esa razón. Profundizaremos en cómo hacerlo en la siguiente parte
del libro. Por ahora, sin embargo, queremos equiparlo con un poco de lenguaje para
ayudarlo a replantear su trabajo lejos de los entregables y hacia los resultados, en otras
palabras, para pasar de los productos a los resultados .

Una historia sobre los resultados

Imagínese un pequeño equipo trabajando en una agencia. Jono, Nicole, Alex yAmanda
se reunirá con un nuevo cliente por primera vez. El cliente ha contratado a la agencia para
diseñar, construir y lanzar un nuevo sitio web que está comprometido a lanzar más
adelante en el año.

El equipo cliente se ha preparado para esta primera reunión. Han preparado y enviado una
lista detallada de requisitos que debe cumplir el sitio web. La lista de funciones es
ambiciosa y, para el equipo de la agencia, más que un poco aterradora. El equipo de la
agencia también ha hecho sus deberes. Han revisado la lista de requisitos y tienen un
conjunto de preguntas listas para el cliente.

Después de algunas presentaciones y cortesías, Nicole va al grano. Ella dice: “Así que
hemos tenido la oportunidad de revisar la lista de requisitos y aquí hay muchos. Una cosa
que nos ayudaría sería alejarnos de los requisitos por un momento y simplemente hablar
sobre el propósito del sitio y el servicio. ¿Puede decirnos por qué este servicio es
importante para su negocio? "

“Claro”, dice Cecily, directora general de la pequeña empresa que contrató a la

agencia. “Actualmente operamos un servicio de planificación de eventos y viajes de
aventura de muy alto nivel para quizás 50 clientes al año. Es un servicio muy
personal. Nos gustaría lanzar una versión en línea de nuestro servicio para poder atender
a miles de clientes cada año. Sabemos que hay demanda, pero la economía requiere un
enfoque de menor contacto, y eso es lo que proporcionará este sitio web ".

"Eso es genial", dice Nicole. Jono va a la pizarra y escribe Impact: un exitoso servicio de
bajo contacto que nos permite atender a miles de clientes cada año.

Nicole continúa: "Y cuando este servicio esté en vivo, ¿qué podrán hacer los clientes que
no puedan hacer hoy?"

"Bueno", dice Cecily, haciendo una pausa por un momento. "Buena pregunta. Nuestro
servicio actual es un servicio especializado de planificación de eventos para eventos a
medida en lugares exóticos. Nosotros mismos hacemos toda la planificación. En nuestro
nuevo servicio, nos gustaría que los anfitriones de eventos que no requieren nuestra
experiencia en viajes puedan encontrar planificadores de eventos con los que trabajar que
se ajusten a sus presupuestos y necesidades ".

"Impresionante", dice Jono, quien escribe en la pizarra Resultado: los anfitriones del
evento se reunirán con los planificadores de eventos calificados para eventos
nacionales y locales.

Cecily mira el tablero, un poco perpleja. Ella dice: “Eso es todo algo obvio. ¿Por qué te
ayuda esto? "

Nicole explica: "Bueno, la lista de funciones en su documento de requisitos es muy

ambiciosa". Esta es la forma cortés de Nicole de explicar que la lista es irrazonablemente
larga y con frecuencia se convierte en especulación. Ella continúa: “Dado que su fecha
límite es bastante corta, necesitaremos filtrar la lista y decidir qué compilar primero y qué
funciones pueden esperar hasta más tarde. Comprender el resultado que desean nuestros
usuarios nos ayudará a priorizar la lista de funciones para que podamos enfocarnos en
cosas que ayuden a los clientes a conocerse, encontrar proyectos y ofertar por ellos
juntos. Todo lo que no genere ese resultado se despriorizará ".
Desempaquetando la historia: producto, resultados, impacto

Ahora, la historia anterior es ficción, pero se basa en innumerables reuniones iniciales

reales, e ilustra una de las ideas clave en Lean UX: Lean UX se trata de centrarse en los
resultados.

Veamos la historia con un poco más de detalle y hablemos un poco sobre el marco detrás
del proceso de Nicole y Jono.

Primero, el cliente llegó con una larga lista de requisitos: estos los requisitos describían
el sitio web y las características del sitio que querían que la agencia diseñara y
construyera. Estas son las cosas que querían que hiciera la agencia: el resultado.

El equipo de la agencia sabía que la lista de funciones era demasiado larga (llevaría mucho
tiempo compilar todo el documento de requisitos) y, lo que es peor, sospechaban que
muchas de las funciones de esa lista no serían útiles para los usuarios finales o al
cliente. Así que el equipo de la agencia buscaba ir más allá de la lista de funciones.

Cuando Nicole preguntó sobre el impacto que buscaba el cliente, se dirigió al panorama
general.Si la directora ejecutiva quisiera mantener su trabajo, ¿qué tendría que entregar a
la junta? Usamos la palabra "impacto" para describir los objetivos de más alto nivel que
establece una empresa. Estos tienden a ser cosas como ingresos, ganancias, lealtad del
cliente. Pero también pueden ser grandes objetivos estratégicos, como el objetivo de
Cecily de crecer de un proveedor de servicios boutique a una organización con un alcance
más amplio.

El problema con los grandes objetivos (objetivos a nivel de impacto) es que hay tantas
formas de perseguirlos y tantos factores que contribuyen a ellos, que puede ser difícil
saber cómo dividir el trabajo y cómo medir el progreso hacia ese objetivo. Para abordar
eso, usamos unobjetivo intermedio, llamado "resultado". En este caso, el equipo capturó
el objetivo intermedio más importante hacia el que trabajarían, que era el
resultado: permitir que los profesionales calificados se conozcan y creen ofertas de
proyectos colaborativos.

Entonces, mientras que los productos son cosas que hacemos, como sitios web y
funciones, los resultados son cosas que hace la gente. De hecho, esa es la clave de nuestra
definición de resultados.Definimos un resultado como "un cambio en el
comportamiento humano que crea valor". 1 Cuando usamos esta definición de
resultado, estamos usando una idea intrínsecamente centrada en el ser humano para
definir el éxito. Cuando nos alejamos de los productos (las cosas que hacemos) y nos
orientamos hacia los resultados, elegimos poner a los seres humanos y sus necesidades
en el centro de lo que hacemos.

EL MODELO LÓGICO

Hemos extraído nuestro lenguaje (productos, resultados, impacto) de un modelo llamado

modelo lógico, descrito por primera vez en 2004 por la Fundación WK Kellogg. Este
modelo ha demostrado ser popular en el mundo sin fines de lucro. El objetivo del modelo
era ayudar a las personas que ejecutan proyectos complejos a evaluar la eficacia de esos
programas. Cuando los otorgantes donan dinero para un programa, generalmente tienen
un impacto en mente. ¿Cómo pueden evaluar si el dinero de su subvención se está
gastando bien? El marco del modelo lógico se desarrolló para ayudar a los evaluadores
de programas a responder esta pregunta. El modelo generalmente se visualiza como se
muestra en la Figura 3-1 .

FIGURA 3-1. EL MODELO LÓGICO

En nuestro trabajo con equipos, hemos descubierto que este modelo puede ser realmente
útil para los equipos ágiles. Lo hemos adaptado un poco para nuestro contexto más
limitado. Pero si está interesado en obtener más información, lo alentamos a que consulte
la fuente y lea más sobre la evaluación de programas en el sitio de la Fundación Kellogg.

Una mirada más profunda a un resultado

Echemos un vistazo más de cerca al resultado de nuestra historia. Primero, dijimos que
unEl resultado es un cambio de comportamiento . ¿A qué nos referimos con eso? En
nuestra historia, nuestro resultado fue: conocer a profesionales calificados y crear
propuestas de proyectos colaborativos. Este proyecto, si tiene éxito, fomentará un
comportamiento: los profesionales se encontrarán en línea para crear juntos las ofertas
del proyecto. Este podría ser un comportamiento nuevo, algo que estos profesionales no
pueden hacer hoy, o simplemente podría ser una mejor manera de hacer algo que hacen
hoy. De cualquier manera, consideramos que es un cambio de comportamiento.

¿Y qué pasa con la parte de creación de valor de nuestra definición?Bueno, si nuestro

trabajo tiene éxito, estos profesionales podrán hacer esta cosa nueva y obtendrán valor al
poder hacerlo. Entonces, hemos satisfecho ambas partes de nuestra definición. Los
profesionales podrán hacer esto nuevo y obtendrán valor al hacerlo.

Ahora, lo interesante aquí es que este nuevo comportamiento también crea valor para la
organización. Se benefician de este nuevo comportamiento del cliente, porque cuando
satisfacen a su cliente, el cliente le paga por el servicio, es más probable que le pague de
nuevo en el futuro y también es más probable que recomiende el servicio a otros. Si está
leyendo con atención, notará que estos también son comportamientos de los clientes: los
clientes pagan por el servicio, regresan por más servicio, recomiendan el servicio. Todos
estos son resultados también, pero estos resultados no necesariamente benefician al
usuario. En cambio, estos resultados benefician a la organización.

Eso es algo a lo que debemos prestar atención cuando trabajamos con resultados: ¿Quién
obtiene valor del comportamiento en cuestión? Cuando un profesional puede hacer
negocios más fácilmente, obtiene ese valor. Cuando el cliente paga por este resultado, la
organización obtiene el valor. En otras palabras, el valor depende de tu punto de
vista. Hablaremos de esto con más detalle en el Capítulo 8 . Por ahora, solo recuerde que
cada resultado viene con un punto de vista incorporado, y es importante comprender en
qué punto de vista estamos pensando. (Vea la Figura 3-2 .)
Veamos un sistema como Facebook para ver un ejemplo de punto de vista. Cuando un
usuario final inicia sesión en Facebook, obtiene valor al leer y publicar en la línea de
tiempo. Los anunciantes obtienen valor cuando los usuarios de la línea de tiempo ven e
interactúan con los anuncios. Y Facebook obtiene valor cuando los usuarios pasan más
tiempo en el sitio y los anunciantes les pagan por acceder a estas personas.Si desea que
su sistema funcione, debe crear un conjunto de resultados alineados; debe comprender las
formas en que los diferentes usuarios obtienen valor y luego entregarles ese valor de una
manera que también cree valor para su organización.
Figura 3-2. Valor alineado

El ejemplo de Facebook trae aquí otro punto de vista, que se relaciona con el valor que
crea el sistema para las personas que no lo utilizan directamente. El impacto de Facebook
en la sociedad es, bueno, llamémoslo controvertido . En términos de nuestro modelo, han
creado una forma de ofrecer valor a los usuarios, a los anunciantes y a ellos mismos, pero
¿a qué costo para la sociedad? Un marco sólido y ético para alinear el valor debe tener en
cuenta las necesidades de una amplia gama de partes interesadas, tanto las que interactúan
directamente con el sistema como las que se ven afectadas indirectamente. 2

Esto nos lleva a un punto final aquí: ninguno de los sistemas en los que trabajamos puede
describirse con una sola declaración de resultados.Todos son sistemas de resultados
interrelacionados. Además, todos estos resultados relacionados se combinan para crear el
impacto (o impactos) de alto nivel que buscamos. Esto puede dificultar el trabajo con los
resultados: un sistema típico está compuesto por muchas personas que realizan muchos
comportamientos. Es fácil sentirse abrumado rápidamente. ¿Qué comportamientos son
importantes? ¿En cuáles deberíamos enfocarnos? En los próximos capítulos,
compartiremos algunas técnicas para descubrir, comprender y mapear estos resultados
relacionados y para navegar a través de esta complejidad para encontrar los resultados
clave en los que centrarse.

Resultados, iteración y validación

Cuando cambia el enfoque de su trabajo de los productos a los resultados,crea grandes
cambios en la forma en que organiza su trabajo. Una de las grandes cosas que cambia es
la línea de meta: ¿cómo se sabe cuándo ha terminado?

En el mundo del software, normalmente utilizamos requisitos, especificaciones y criterios

de aceptación para indicarnos cuándo se realiza el trabajo. ¿Se está ejecutando el
software? ¿Cumple con las especificaciones? ¿Cumplir con los requisitos? ¿Cumplir con
los criterios de aceptación? ¿Cumple con lo que Scrum llama la "definición de
hecho"? Estos métodos son buenos porque pueden definir la línea de meta con mucha
precisión, pero casi siempre nos piden que evaluemos el resultado de nuestro trabajo.¿Y
si no queremos detenernos ahí? ¿Qué pasa si queremos medir los resultados que hemos
creado?

Resulta que, en este caso, no podemos dejar de trabajar en una cosa cuando terminamos
de hacerla. Para medir los resultados, en realidad necesitamos poner esa cosa en el mundo
y observar cómo (o si) cambia el comportamiento de las personas. En otras palabras,
aunque tenemos que completar la salida, eso no es suficiente. Tenemos que validarlo .

El proceso de validación de nuestra salida es intrínsecamente iterativo.La mayoría de las

veces, los equipos no hacen todo bien en su primer intento. Por lo general, nuestro primer
intento puede obtener algunos de los resultados que buscamos, pero generalmente no
todos. Cuando nos enfocamos en los resultados, vemos la oportunidad de mejorar y
seguimos trabajando en eso hasta que entrega los resultados que nos propusimos. Este es
el proceso que Lean Startup llama ciclo de construcción-medida-aprendizaje y lo que la
comunidad Agile llama inspeccionar y adaptar. Como sea que llames a estos bucles,
describen un enfoque iterativo. Un enfoque que significa el final de una y otra vez. Un
enfoque que significa que iteramos hasta lograr el resultado .

1Para obtener más información sobre los resultados, consulte el libro de Josh Resultados
sobre resultados: por qué el comportamiento del cliente es la métrica clave para el
éxito empresarial (Sense & Respond Press, 2019), https://oreil.ly/7O2xZ .
2Para obtener un buen resumen de los problemas aquí, consulte el artículo de Oz Lubling
"La línea borrosa entre el empoderamiento y la explotación en UX", Culture Clash, 4 de
febrero de 2021, https://oreil.ly/BDi2z .
Parte II. Proceso
Acerca de la Parte II
En la parte anterior, analizamos las ideas detrás de Lean UX: los principios que impulsan
el trabajo. En esta sección, nos volveremos muy prácticos y describiremos en detalle el
proceso de hacer Lean UX.

Hemos organizado esta sección en torno a una nueva herramienta que hemos estado
utilizando durante los últimos años: el Lean UX Canvas. Lean UX Canvas es una forma
de orquestar su proceso Lean UX. Ofrece una forma "de un vistazo" de una sola página
para enmarcar su trabajo en una función, una epopeya o una iniciativa, o incluso un
producto completo.

Esta herramienta de una sola página recopila todas las herramientas, métodos, procesos y
técnicas clave de Lean UX en un solo documento con una estructura unificada. Es una
herramienta que puede utilizar para obtener desde la primera parte del proceso de diseño
(el encuadre inicial del problema) a través del diseño, la creación de prototipos y la
investigación.

Aunque no tiene que usar el lienzo para hacer Lean UX, hemos descubierto que el lienzo
es una excelente manera de explicar el proceso, por lo que hemos optado por presentarle
el proceso Lean UX mediante el uso del lienzo.

El lienzo Lean UX
El Capítulo 4, Lean UX Canvas , proporciona una descripción general del Lean UX
Canvas. Aprenderá por qué Lean UX es escéptico con respecto a los requisitos, por qué
adopta supuestos en su lugar y cómo el Lean UX Canvas es un vehículo que puede utilizar
para capturar y probar sus supuestos. Este capítulo también presenta algunas ideas sobre
cómo facilitar el proceso de trabajo con el lienzo.

El Capítulo 5, Cuadro 1: Problema comercial , cubre la técnica que utilizará para definir
el problema que usted y su equipo están tratando de resolver desde el punto de vista de la
empresa.

El Capítulo 6, Cuadro 2: Resultados comerciales , cubre cómo define el éxito de su

proyecto. Este recuadro trata de comprender qué resultados está tratando de lograr para
su empresa, organización o clientes.

El Capítulo 7, Cuadro 3: Usuarios , cubre la sección del lienzo que define a sus usuarios
(y clientes). Esta sección describe la técnica de proto-persona y cómo usarla.

El Capítulo 8, Cuadro 4: Resultados y beneficios del usuario , trata sobre los objetivos
del usuario. ¿Qué intentan hacer sus usuarios (y clientes)? ¿Qué definirá el éxito para
ellos?
El Capítulo 9, Cuadro 5: Soluciones , es donde comenzamos a definir lo que haremos (o
haremos) para resolver los problemas que hemos definido.

Capítulo 10, Recuadro 6: Hipótesis , Capítulo 11, Recuadro 7: ¿Qué es lo más

importante que debemos aprender primero? , y el Capítulo 12, Recuadro 8: MVP y
Experimentos , cubren el tercio inferior del lienzo, lo que impulsa la conversación para
averiguar si tenemos razón en todo lo demás en el lienzo.

Profundicemos en cada recuadro y veamos exactamente cómo se desarrolla cada parte de

esta conversación, cómo facilitarla con éxito y qué hay que tener en cuenta en cada
recuadro a medida que avanza en los ejercicios y declara sus suposiciones.
Capítulo 4. El lienzo Lean UX
Las suposiciones son los nuevos requisitos
Si trabaja en una industria donde las cosas son relativamente predecibles, donde existe un
bajo riesgo y una alta certeza en lo que está haciendo la empresa, lo que se necesita para
hacer su producto, cómo se ve cuando está hecho y qué harán sus clientes con él una vez
que lo tengan, puede trabajar cómodamente con un conjunto de requisitos rígidos y
predeterminados. En un mundo con esta mentalidad de la era de la fabricación, el gran
diseño por adelantado es la norma, y cualquier variabilidad en la producción de su
producto se considera no como una respuesta ágil a un mercado cambiante, sino como
una costosa desviación del plan. Esta forma de pensar sobre los requisitos se adoptó en
los primeros días de la industria del software, fue el modelo dominante durante décadas
y continúa impregnando las formas de trabajar de muchos equipos incluso hasta el día de
hoy.

Los requisitos asumen que sabemos exactamente lo que necesitamos

construir. Idealmente, provienen del rigor de la ingeniería. Pero en software,
generalmente no tienen el rigor detrás de ellos. Aún así, se toman al pie de la letra según
la credibilidad de su autor o el título de la organización. En muchos casos, esa fe ciega se
aumenta con la frase "bueno, funcionó antes". Las personas o equipos que cuestionan el
carácter absoluto de los requisitos que han recibido son percibidos como alborotadores y
tratados como chivos expiatorios cuando los proyectos terminan incumpliendo plazos,
superando el alcance o ambos. En las organizaciones que todavía dependen en gran
medida de ellos como una forma de decirle a los equipos qué hacer, los requisitos a
menudo simplemente significan, como le gusta decir a nuestro amigo Jeff Patton,
"Cállate".

Pero las empresas actuales basadas en software operan en una realidad desprovista de
coherencia, previsibilidad, estabilidad y certeza. Decir con autoridad que una
combinación específica de código, copia y diseño logrará el resultado comercial
deseado y se entregará por completo en una fecha límite explícita no solo es
arriesgado; en la mayoría de los casos es mentira. El desarrollo de software es complejo
e impredecible. El ritmo del cambio es increíblemente rápido. Las empresas no solo
pueden enviar funciones a producción de forma continua a velocidades sin precedentes,
sino que los comportamientos de los consumidores están cambiando con la misma
rapidez. Tan pronto como se haya decidido por un conjunto de características, un enfoque
de diseño y una experiencia de usuario específica, su audiencia comienza a evolucionar
hacia nuevos modelos mentales basados en sus experiencias con otros servicios en línea.

La buena noticia es que no tenemos que depender de los requisitos. La industria ha

desarrollado nuevas formas de trabajar que nos permiten alejarnos de los rígidos
requisitos.Cuando escribimos la primera edición de este libro, Amazon enviaba el código
a producción cada 11,6 segundos. Hoy han reducido su tiempo de comercialización a un
segundo. 1Así es: cada segundo, algún cliente de Amazon en algún lugar de su ecosistema
experimenta un cambio en la forma en que funciona el producto. Sesenta veces por
minuto, Amazon tiene la oportunidad de saber qué tan bien están satisfaciendo las
necesidades de sus clientes. Sesenta veces por minuto, tienen la oportunidad de responder
a lo que están aprendiendo. Sesenta veces por minuto, tienen la oportunidad de mejorar
su experiencia de usuario. Con esta capacidad, la idea misma de un requisito rígido es, en
el mejor de los casos, anacrónica. En el peor de los casos, es un impedimento que impide
que los equipos hagan su mejor trabajo. Concedemos que Amazon está en el extremo de
esto, pero sirven como inspiración y un objetivo claro para lo que es posible. Si podemos
enviar, detectar y responder a esto rápidamente,

Hay otras razones para evitar los requisitos. El software es difícil. Incluso los ingenieros
de software experimentados le dirán que solo porque algo parece simplePara construir
no significa que en realidad va a ser fácil de construir. A menudo, cuando nos propusimos
ofrecer una experiencia de usuario específica, aprendemos que, para hacerlo,
necesitaremos desarrollar más código de lo que anticipamos. El código que pensamos que
sería simple resulta tener dependencias complejas o tiene limitaciones heredadas o se
encuentra con obstáculos no planificados, y terminamos teniendo que dedicar más tiempo
a averiguar cómo solucionar estos problemas. Esto también va en contra de los requisitos
rígidos basados en plazos.

Y, por supuesto, no solo el código es complejo e impredecible. Los humanos también son
complejos e impredecibles. Sus motivaciones innatas, personalidades, expectativas,
normas culturales y hábitos van en contra de lo que creemos será un servicio de software
ideal para que lo utilicen. Ponemos tanta fe en lo que creemos que será “fácil de usar” o
“intuitivo”, solo para descubrir que nuestro público objetivo hace todo lo posible para
evitar las simplificaciones que creemos que hicimos para ellos. ¿Por qué hacen
esto? Cualquier variedad de factores (que podríamos conocer a través de entrevistas e
investigaciones con los clientes) podría conducir a estos comportamientos inesperados,
pero todos tienen el mismo resultado neto: demuestran que nuestros requisitos son
incorrectos.

¿Entonces, qué debemos hacer? Necesitamos reconocer que la mayoría de los requisitos
son simplemente suposiciones. expresado con autoridad. Si eliminamos la autoridad, el
exceso de confianza y la arrogancia de la conversación, nos quedamos con la mejor
suposición de alguien sobre la mejor manera de lograr un objetivo de usuario o resolver
un problema comercial. Somos fabricantes de productos digitales, por lo que admitir
humildemente que estas son nuestras mejores conjeturas o suposiciones crea de forma
inmediata y explícita el espacio para el descubrimiento de productos y la experiencia de
usuario ajustada. Si entendemos como equipo que el trabajo que estamos realizando es
riesgoso precisamente porque no podemos predecir el comportamiento humano,
sabemos que parte de nuestro trabajo deberá incluir experimentación, investigación y
reelaboración. Reducimos nuestro apego a las ideas y creamos una cultura de equipo que
está más dispuesta a ajustar el rumbo, incluso a dejar de trabajar en una idea que sigue
resultando inviable.

Entonces, ¿cómo construimos una conversación que fomente las ideas de todos equipo
pero califica esas ideas como una serie de suposiciones? En versiones anteriores de este
libro compartimos una serie de ejercicios de declaración de supuestos. Estos procesos han
ayudado a lectores y profesionales a expresar sus ideas de una manera nueva,
como suposiciones comprobables. A lo largo de los años, hemos consolidado estos
ejercicios de declaración de supuestos, así como los pasos que necesitará para probar sus
supuestos, en un soloherramienta de facilitación que llamamos Lean UX Canvas.
El lienzo Lean UX
El Lean UX Canvas ( Figura 4-1 ) reúne una serie de ejerciciosque permiten a los equipos
declarar sus suposiciones sobre una iniciativa. Está diseñado para facilitar las
conversaciones dentro del equipo, pero también con las partes interesadas, los clientes y
otros colegas.Recuerde que en Lean UX estamos tratando de construir un entendimiento
compartido, y para hacerlo (especialmente cuando estamos tratando de alejarnos de los
requisitos), necesitamos un vocabulario compartido consistente que permita a las partes
interesadas y a los colaboradores individuales compartir sus ideas y crear claridad.

Si ha realizado algún trabajo Lean UX en el pasado, reconocerá la mayoría de estas

actividades. Si ha realizado trabajos de diseño anteriormente, reconocerá la importancia
de todos los temas del lienzo y lo importante que es tener conversaciones sobre estos
temas al comienzo de un proyecto. Nuestra experiencia con el uso de este lienzo es que
la estructura del lienzo ayuda a garantizar que todas estas conversaciones tengan lugar,
que las conversaciones incluyan un conjunto diverso de puntos de vista y que, cuando
haya terminado, el equipo ampliado haya construido un entendimiento compartido y el
camino a seguir. es claro.

Figura 4-1. El lienzo Lean UX

El lienzo fue diseñado para guiar la conversación desde el estado actual de su producto o
sistema, o lo que Mike Rother llamó la condición actual ("AHORA" en la Figura 4-2 )
en su libro The Toyota Kata 2, al estado futuro deseado o condición objetivo ("MÁS
TARDE" en la Figura 4-2 ).
Figura 4-2. Las áreas clave del Lean UX Canvas
¿OTRO LIENZO?

¿Otro lienzo? Buena pregunta. Desde entoncesAlex Osterwalder y el equipo de

Strategyzer le obsequiaron al mundo el Business Model Canvas, nos ha enamorado y
finalmente nos ha inundado de lienzos. Si no publica un lienzo, ¿es realmente un líder
intelectual? Nuevamente, pregunta justa. Pero los lienzos son útiles y pueden servir como
la pieza central de una colaboración en equipo equilibrada e inclusiva. Si se usa
correctamente, los lienzos:

• Consolide una serie de actividades en un proceso secuencial diseñado para

impulsar una narrativa .
• Ayuda en entornos complejos. Nos ayudan a crear un modelo visual único para
representar elementos clave de esa complejidad.
• Sirve como una herramienta de facilitación fácil de seguir para los equipos
interesados en tener un tipo específico de conversación.
• Nivele el campo de juego para los miembros del equipo menos aptos para ofrecer
sus ideas en una sesión estándar de lluvia de ideas.
• Cree un idioma compartido para que lo use el equipo.
• Encuadre con éxito el trabajo que debe realizar el equipo.
• Comunique el desafío o el trabajo que el equipo está llevando a cabo más allá del
equipo.

Usando el lienzo
En los próximos capítulos, describiremos cada sección del lienzo en detalle. Sin embargo,
antes de hacer eso, queremos responder algunas preguntas generales que surgen cada vez
que enseñamos a los equipos sobre el lienzo.
Entonces, ¿cuándo deberíamos usar el lienzo Lean UX?

Creemos que el lienzo es una excelente manera de iniciar una iniciativa. Ya sea que esté
trabajando en una nueva función, una iniciativa importante o un nuevo producto, el lienzo
es una excelente estructura para usar en su reunión inicial. A medida que se sienta cómodo
con la herramienta, comenzará a comprender cuándo una pieza de trabajo es demasiado
pequeña para el lienzo. En general, creemos que es una buena idea usarlo siempre que
esté planeando una gran cantidad de trabajo.

¿Es el lienzo Lean UX más adecuado para las ideas iniciales o para mantener la
innovación?

El lienzo realmente funciona bien para ambos tipos de trabajo. La pregunta clave es la
siguiente: ¿se enfrenta a importantes incógnitas, incertidumbre o complejidad? Ahí es
donde Lean UX Canvas, y, realmente, Lean UX en general, puede ayudar. En las primeras
etapas del trabajo, las incógnitas tienden a ser de naturaleza existencial: ¿existe la
necesidad de este producto o servicio? ¿La gente usará nuestra solución? ¿Podemos
construir un negocio resolviendo este problema? Para mantener la innovación, las
preguntas tienden a ser más pequeñas, pero eso no significa que las respuestas sean más
claras. En ambas situaciones, Lean UX Canvas puede ayudar.

¿Quién debería trabajar en el lienzo?

Uno de los valores del lienzo es la forma en que trabajar a través de él creaentendimiento
compartido en su equipo. Alienta al equipo y a las partes interesadas a realizar el trabajo
de descubrimiento de productos que los convierte en productos exitosos. Por eso creemos
que todos los miembros del equipo deben participar en el trabajo sobre el lienzo. También
pensamos que las partes interesadas y los clientes deben participar tanto como sea posible,
especialmente durante las partes del trabajo para elaborar la declaración del problema
comercial y los objetivos comerciales.

¿Cuánto tiempo deberíamos esperar gastar en un lienzo Lean UX?

Es difícil superar todo en menos de una sesión de medio día. Debido a que el lienzo es
una gran actividad de inicio, piense en cuánto tiempo dedica normalmente a iniciar
proyectos. ¿Es un ejercicio de dos días? ¿Una semana completa? Algunos equipos
trabajarán a través del lienzo de esa manera, especialmente si pueden estar todos juntos
en la misma habitación. Otros equipos optarán por realizar una serie de reuniones en el
transcurso de un par de semanas. En general, cuanto más grande e importante sea el
proyecto, más tiempo llevará. No se quede atascado en la parálisis del análisis. Cuando
no sepa algo, póngalo en el estacionamiento y continúe. Después de todo, el objetivo del
lienzo es recopilar las cosas que no sabe para que pueda comenzar a aprender sobre ellas
rápidamente.

¿Tenemos que usar el lienzo para hacer Lean UX?

Absolutamente no. Cada parte del lienzo contiene una parte útil delProceso Lean
UX. Mientras trabaja en cualquier iniciativa, querrá pensar y responder las preguntas
implícitas en cada uno de los recuadros del lienzo. Dicho esto, puedes usar absolutamente
cada cuadro en el lienzo como una técnica independiente. ¿No tiene claro cuáles son sus
usuarios? Vaya al Recuadro 3, lea sobre proto-personas y use estas ideas con su equipo
para obtener claridad. ¿No tiene claro cuál es la mejor solución a un problema? Pase a la
sección de este libro sobre el Recuadro 5 y lleve a su equipo a través de ese proceso.

Si decide utilizar el lienzo como un todo, recuerde que es una herramienta flexible. Utilice
los ejercicios que mejor funcionen para usted, teniendo en cuenta su contexto y las formas
en que funcionan para su equipo. Amplíe el número de actividades a medida que su
equipo se sienta más cómodo con la naturaleza de este trabajo. En última instancia,
queremos asegurarnos de que el cliente esté al frente y en el centro de todas sus
conversaciones. El Lean UX Canvas es un buen punto de partida para garantizar que eso
suceda.

Facilitando cada sección

En los capítulos siguientes, compartiremos las instrucciones de los ejercicios que nos
gusta usar para completar el lienzo. Aquí, nos gustaría señalar algunos patrones generales.

Ser inclusivo

Queremos que todo el equipo participe en la realización del lienzo.3 Esto significa que su
facilitación debe tener en cuenta los diferentes estilos de participación, así como los
diferentes niveles de poder y autoridad en la sala.

Para abordar eso, nos gusta usar una variante del patrón 1-2-4-All . 4 Esta es una forma
estructurada de obtener la participación de un grupo. Así es como funciona:

• Empiece pidiendo a las personas que trabajen individualmente (el "1"),

generalmente en silencio, ya sea escribiendo ideas o dibujando algo por sí
mismos. Por lo general, desea establecer un límite de tiempo agresivo en este
período (generalmente cinco minutos) para obligar a las personas a expresar sus
ideas y evitar pasar mucho tiempo editando y refinando. Después de este período
de trabajo en solitario, pida a la gente que comparta con su mesa o su subgrupo. Si
las personas han estado trabajando con Post-its, puede tener sentido pedirles que
las traigan a un muro y las publiquen allí. Opcionalmente, puede ofrecer un debate
durante este período. También puede pedirle a la gente que haga un mapeo de
afinidad en este punto.
• Luego, pide a las personas que trabajen en parejas (los "2") para elaborar o
desarrollar una idea. El trabajo en parejas toma más tiempo que el trabajo en
solitario, así que déles a las parejas más tiempo del que les permitió trabajar en
solitario. Nuevamente, después de este período de trabajo por parejas, las parejas
presentan su trabajo en su mesa o sala de subgrupos, y es posible que tenga más
discusión en este punto.
• A continuación, le pide a cada mesa o subgrupo que desarrolle su trabajo en una
sola presentación. (Esta es la parte "4" del patrón).
• Finalmente (si está tratando de producir una idea final), le pide a todo el grupo
que desarrolle una sola idea. (Esta es la parte "Todos" del patrón).

1-2-4-All es eficaz porque solicita la opinión de todos en la sala, permite estilos de trabajo
tanto en solitario como en colaboración y, finalmente, permite que el grupo se una. Querrá
adaptar este patrón al ejercicio específico, pero téngalo en cuenta al planificar el trabajo
en grupo.

Remoto versus en persona

Todos estos ejercicios se pueden realizar como talleres presenciales o de forma

remota,con software de videoconferencia y herramientas de pizarra compartida. Si está
trabajando de forma remota, recuerde interrumpir sus sesiones para permitir que las
personas se pongan de pie y evitar la fatiga de Zoom. Además, recuerde que no todo el
mundo está familiarizado con las herramientas de la pizarra en línea, por lo tanto, deje
algo de tiempo para poner al día a los participantes menos experimentados. (A veces
puede utilizar un ejercicio para romper el hielo que ayude a las personas a aprender la
herramienta).Hemos creado plantillas Lean UX Canvas que puede usar.

Terminando
En los próximos capítulos de esta sección, describiremos cada sección del lienzo en
detalle.

1 Vogels, "La historia de Apollo: el motor de implementación de Amazon".

2Mike Rother, The Toyota Kata: Gestión de personas para mejorar, adaptarse y
obtener resultados superiores (McGraw-Hill Education, 2009).

3 La idea de “todo el equipo” variará según su contexto, así que siéntase libre de adaptar
este consejo según el tamaño de su grupo y los roles de las personas en la sala.

4Este es uno de los patrones de la muy útil colección Liberating Structures. Consulte “1-
2-4-All”, Liberating Structures, consultado el 16 de junio de
2021, https://oreil.ly/12vgk .
Capítulo 5. Recuadro 1: Problema
empresarial

Figura 5-1. Recuadro 1 del lienzo Lean UX: problema empresarial

Para que Lean UX tenga éxito, los equipos deben tener problemas para resolver, no
soluciones para construir.A menudo, estas "soluciones" se expresan como requisitos o
especificaciones de funciones. Pero si los requisitos son el camino equivocado, ¿cuál es
el camino correcto? La forma correcta es comprender y expresar el problema que las
partes interesadas o los clientes están tratando de resolver. Esto es lo que hacen
las declaraciones de problemas comerciales . Las declaraciones de problemas
comerciales replantean el trabajo de una manera que exija explícitamente que se lleve a
cabo el trabajo de descubrimiento de productos.

Si bien existe cierta flexibilidad en el aspecto que puede tener una declaración de
problema empresarial, al menos debería:

• Proporcione un desafío específico para que el equipo lo resuelva en lugar de un

conjunto de características para implementar.
• Anclar al equipo en una perspectiva centrada en el cliente para que el éxito del
cliente sea una parte incorporada del objetivo final.
• Enfoque el esfuerzo del equipo especificando pautas y restricciones que le aclaren
al equipo qué está dentro del alcance y qué está fuera del alcance.
• Proporcionar medidas claras de éxito expresadas como Indicadores clave de
desempeño del negocio (impactos deseados) o resultados específicos que la
empresa quiere ver en su público objetivo.
• No definir una solución (esto es sorprendentemente más difícil de lo que parece).

Fundamentalmente, las declaraciones de problemas comerciales contienen tres partes:

1. Los objetivos actuales del producto o del sistema en el que está

trabajando el equipo. En otras palabras, ¿por qué se creó en primer
 lugar? ¿Qué problema se diseñó originalmente para resolver? ¿Qué valor se
pretendía ofrecer?
2. ¿Qué ha cambiado en el mundo y cómo ha afectado negativamente al
producto? En otras palabras, ¿dónde están las metas que nos propusimos para
este producto que no se están cumpliendo ahora?
3. Una solicitud explícita de mejora del producto que se aleja de especificar
una solución y que cuantifica la “mejora” en términos de resultados.

Cuando esté creando declaraciones de problemas comerciales, recuerde que su Es

probable que los esfuerzos iniciales estén llenos de suposiciones. Descubrirás que esto va
a ser cierto para cada parte del Lean UX Canvas. Esto esta bien; de hecho, es
inevitable. Solo tenga en cuenta que, a medida que comienza a trabajar en el problema,
es decir, a medida que comienza a hacer el trabajo de descubrimiento, puede descubrir
evidencia de que está trabajando en el problema incorrecto o dirigiéndose a la audiencia
incorrecta o midiendo el éxito en el Sentido Contrario. Esta bien. ¡Por eso haces
descubrimiento! Solo asegúrese de llevar este aprendizaje al equipo y a las partes
interesadas tan pronto como sea posible para asegurarse de no perder tiempo y esfuerzo
en una declaración de problema no válida.

Facilitar el ejercicio
Para crear una declaración de problema empresarial, ciertamente puede
sentarseinformalmente con las partes interesadas y los propietarios de productos para
redactar uno juntos. Dicho esto, nos gusta hacer esto como parte de un taller con todo el
equipo. Si está haciendo eso, le recomendamos que utilice el siguiente proceso.

Proporcione contexto y antecedentes para el equipo. Esto a menudo recae en el gerente

de producto y es fundamental para enmarcar el trabajo correctamente. Las preguntas que
el gerente de producto debe responder al equipo antes de escribir una declaración de
problema comercial incluyen:

• ¿Qué hemos observado y medido que nos lleva a creer que hay un problema?
• ¿A quién nos dirigimos con este trabajo?
• ¿Cómo encaja este trabajo en el programa de trabajo más amplio que está llevando
a cabo la empresa?
• ¿Cuál es el impacto de solucionar (y no solucionar) este problema en la salud de
la empresa?

Si tiene un grupo grande, divídalo en parejas o tríos y escriba el primer borrador del
enunciado del problema empresarial en grupos pequeños. Los grupos pequeños pueden
hacer esto juntos. No dedique más de 30 minutos a este primer borrador.

Aquí está la plantilla que usamos para redactar buenas declaraciones de problemas
comerciales.para productos existentes :

[Nuestro servicio / producto] fue diseñado para lograr [estos objetivos

comerciales / del cliente y ofrecer este valor] . Hemos observado [de esta
manera] que el producto / servicio no cumple con estos objetivos, lo que está
causando [este efecto / problema adverso] en nuestro negocio.
¿Cómo podríamos mejorar el servicio / producto para que nuestros clientes tengan más
éxito según lo determinado por [estos cambios medibles en su comportamiento] ?

Si está trabajando en iniciativas completamente nuevas , la plantilla se ve así:

El estado actual de [el dominio en el que estamos trabajando] se ha centrado

principalmente en [estos segmentos de clientes, estos puntos débiles, estos
flujos de trabajo, etc.] .

Lo que los productos / servicios existentes no logran abordar es [esta brecha o cambio
en el mercado] .

Nuestro producto / servicio abordará esta brecha mediante [esta estrategia o enfoque
de producto] .

Nuestro enfoque inicial será [este segmento de audiencia] .

Sabremos que tenemos éxito cuando veamos [estos comportamientos medibles en

nuestro público objetivo] .

Una vez que las parejas o tríos completen su primer borrador, vuelva a unirse como
equipo y lean sus borradores entre sí. Proporcione críticas y comentarios, y haga
preguntas aclaratorias sobre cada borrador. Recuerde que la crítica no es un ataque directo
a la obra, sino más bien una investigación aclaratoria para comprender mejor lo que
querían decir los autores.

Una vez que todos hayan compartido su borrador, combínelos en grupos más grandes de
cuatro a cinco miembros del equipo y consolide en un borrador de declaración. Después
de 30 minutos de consolidación de subgrupos, comparta los borradores reelaborados con
el equipo en general. Por último, dedique 30 minutos más a reunir los borradores en una
declaración de problema empresarial de todo el equipo.Recuerde que este es un ejercicio
de declaración de supuestos. Inevitablemente, algunas de estas suposiciones serán
incorrectas, por lo que el objetivo del Recuadro 1 no es escribir el enunciado perfecto del
problema. El objetivo es comenzar a construir una alineación dentro del equipo sobre
hacia dónde se dirige en esta iniciativa y cómo sabrá que ha logrado el objetivo.

Recuerde que las declaraciones de problemas comerciales son, en última instancia, sobre el
estatuto del proyecto, por lo que si las partes interesadas no han estado involucradas, deberá
incorporarlas en este punto para obtener su compromiso.

Agregue el borrador de la declaración del problema completo a su lienzo.

Algunos ejemplos de enunciados de

problemas
A continuación, se muestra un ejemplo de cómo se ve una buena declaración de problema
empresarial:
Cuando lanzamos nuestras soluciones de préstamos digitales para pequeñas y medianas
empresas (PYMES), el mercado consistía en productos anticuados vendidos por
instituciones bancarias heredadas. En ese mundo, nuestras soluciones de préstamos
digitales primero se destacaron y atrajeron a clientes PYMES que buscaban nuevas
formas de trabajar con su banco. Dado que los bancos tradicionales funcionan cada vez
más como empresas “fintech”, nuestro mercado se ha vuelto más concurrido y altamente
competitivo. Esto está provocando que los costos de adquisición de nuestros clientes
aumenten, la participación de mercado se estanque y los costos de atención al cliente
aumenten.

¿Cómo podríamos rediseñar nuestra línea de productos para pymes para que nuestros
clientes crean que estamos diseñados a propósito para respaldar sus negocios modernos
y, a su vez, reducir nuestros costos de adquisición y aumentar nuestra participación de
mercado?

Este ejemplo es de nivel relativamente alto. Está diseñado para abordar un problema a
nivel de unidad de negocio. Es importante que el equipo que trabaja en este problema
tenga la jurisdicción e influencia para afectar el trabajo a este nivel. Escribir declaraciones
de problemas comerciales que los equipos no pueden resolver porque carecen del nivel
de influencia requerido es hacer que el equipo fracase.

A continuación, se muestra un ejemplo de una declaración de problema empresarial más

táctica que se puede asignar a un equipo de nivel de función:

La función de recuperación de contraseña se implementó para ayudar a los clientes a

volver rápidamente al producto en caso de pérdida o caducidad de la
contraseña. Además, este autoservicio adicional reduciría la cantidad de llamadas al
centro de servicio al cliente, reduciendo nuestras llamadas de soporte anuales generales,
ya que las llamadas de restablecimiento de contraseña representan al menos el 35% de
las llamadas entrantes.

Hemos notado a través de informes analíticos y comentarios de estudios de usabilidad

consistentes que nuestros clientes luchan por encontrar la función de recuperación de
contraseña e, incluso cuando lo hacen, no completan el proceso de restablecimiento por
sí mismos al menos el 42% del tiempo debido a su complejidad. Esto está provocando un
aumento en los costos de soporte del centro de llamadas en un 12% al tiempo que
exacerba la insatisfacción del cliente con nuestro producto, lo que potencialmente lleva
a un aumento del 0,7% en la tasa de abandono.

¿Cómo podríamos rediseñar la experiencia de recuperación de contraseñas para que

nuestros usuarios tengan más éxito según lo determinado por las tasas de finalización
del proceso del 90% y la reducción del 50% en las llamadas al servicio de atención al
cliente sobre el restablecimiento de contraseñas?

De qué estar atento

No especifique la solución. el ejercicioAl llamarse declaración
de problema empresarial , a menudo vemos equipos que insertan soluciones en la
declaración. Esto a menudo se muestra en la parte de "cómo podríamos" de la declaración
con frases como "¿Cómo podríamos implementar una aplicación móvil que solucione esto
..." Las soluciones no deberían estar en este ejercicio en absoluto. Reservamos esa
conversación para el recuadro 5.

Obtenga el nivel correcto. Anteriormente mencionamos "nivelar" el enunciado del

problema correctamente, pero vale la pena repetir que ya sea que estén escribiendo sus
propios enunciados del problema juntos como equipo o si alguien los está escribiendo por
usted, su equipo solo debe registrarse para un enunciado del problema que sea capaz de
hacer. resolviendo. Si el problema se enmarca en un nivel demasiado alto, el equipo no
podrá resolver el problema por sí solo. Esto conducirá a la frustración, no solo con y
dentro del equipo, sino con el proceso general de Lean UX en sí.

Se específico. Otro antipatrón común es la falta de especificidad en la declaración. En

ocasiones, los equipos dejarán métricas explícitas o evidencia fuera del enunciado del
problema. Los detalles son importantes para enmarcar la importancia del problema, así
como para establecer criterios claros de éxito a nivel empresarial para el equipo. En caso
de duda, presione siempre para que la declaración sea específica.

Por último, la especificidad es importante no solo para las métricas, sino también para el
área de producto que se aborda. Los equipos utilizarán frases como "interfaz de usuario
intuitiva" o "gran experiencia de usuario" para describir el trabajo que se realizó o que se
espera que se realice. En todos los casos, frases como estas describen características
(aunque en abstracto) que, en general, deberían dejarse fuera de los enunciados del
problema.

Aquí hay dos ejemplos de frases como estas en declaraciones de problemas comerciales
y cómo corregirlas:

Cuando nos propusimos mejorar nuestra experiencia de compra, implementamos una

interfaz de usuario intuitiva para aumentar el valor promedio de los pedidos.

En este ejemplo, no está claro qué se implementó, por lo tanto, el equipo no sabe
realmente qué partes de la interfaz de usuario deben apuntar potencialmente
para mejorar .

En el siguiente ejemplo, la frase ambigua termina en la parte de "cómo podríamos" que

parece lo suficientemente benigna pero que ya enfoca al equipo en una solución específica
antes de que se haya realizado el trabajo de descubrimiento:

¿Cómo podríamos crear una interfaz de usuario más intuitiva para que los clientes
agreguen más artículos a su carrito de compras durante cada visita?

Puede ver aquí que el encuadre del trabajo le dice al equipo que solo busque las mejoras
de la interfaz de usuario en lugar de buscar la causa raíz de la disminución de los valores
promedio de los pedidos.

Y por si sirve de algo, todo el mundo se propone ofrecer interfaces de usuario intuitivas. Nadie
dice nunca: "Vamos a ofrecer una interfaz de usuario de mala calidad para la plataforma de
comercio electrónico".
Capítulo 6. Recuadro 2: Resultados
comerciales

Figura 6-1. Recuadro 2 del lienzo Lean UX: resultados empresariales

Cubrimos el concepto de resultados en el Capítulo 3 . Box 2 es donde hacen su primera

aparición en Lean UX Canvas.Una vez que tenga una declaración de problema comercial,
querrá profundizar en los cambios de comportamiento básicos que busca como parte de
la iniciativa. Normalmente, los criterios de éxito en una declaración de problema son de
alto nivel. Los criterios de éxito tienden a ser indicadores clave de desempeño o métricas
de impacto, las cosas que se encuentran en los cuadros de mando ejecutivos. Estas podrían
ser métricas como ingresos, ganancias, costo de los bienes vendidos y satisfacción del
cliente. Estos son útiles para medir la salud de la empresa, pero los equipos de nivel de
función deben trabajar en un nivel inferior.

En este ejercicio, trabajamos juntos para descubrir los principales indicadores de esas
métricas de impacto. La pregunta que estamos tratando de responder es ¿qué hará la
gente de manera diferente si nuestras soluciones funcionan? Si elegimos la
combinación correcta de código, copia y diseño, ¿qué esperamos que suceda?Las
respuestas a estas preguntas son las que buscamos en este ejercicio de declaración de
supuestos.

Cada opción en esta lluvia de ideas debe comenzar con un verbo, y cada respuesta debe
ser algo valioso que los clientes ya hagan en el sistema, algo que no sea valioso y que nos
gustaría que hicieran menos, o algo nuevo que pensamos que será valioso. y que nos
gustaría que comenzaran a hacer. En esencia, estamos pensando y destacando los viajes
de los usuarios.

Uso del recorrido del usuario

El objetivo de este ejercicio es encontrar los comportamientos valiosos de los clientes
quequiero centrarme. Para hacer eso, es útil comenzar con un modelo de comportamiento
del cliente: ¿qué está haciendo la gente hoy? ¿Qué están tratando de hacer que sea
difícil? ¿Qué están haciendo hoy que no sea productivo para ellos o para nosotros? ¿Qué
comportamientos nuevos y valiosos podemos desbloquear? Para responder a esta
pregunta, podemos utilizar la idea de los viajes de los usuarios.

El mapeo del viaje del usuario puede ser muy simple. Podemos usar una plantilla, como
Pirate Metrics o Metrics Mountain (ambas descritas a continuación). O podemos usar
herramientas que tomamos prestadas de Service Design para crear un mapa de viaje del
usuario. Independientemente del marco que elijamos, la idea es reunir al equipo y a las
partes interesadas en torno al mapa y generar una comprensión compartida del viaje de
cómo las personas se mueven a través de nuestro sistema y qué partes de ese viaje deben
ser el foco de nuestro trabajo.

Dependiendo de sus circunstancias, aquí hay algunos modelos para comenzar.

Tipo de viaje del usuario: métricas piratas

Una forma de generar métricas de resultados es utilizar Pirate Metrics.Concebido en la

incubadora de startups 500 Startups, el embudo de Pirate Metrics se ha convertido en una
forma estándar de pensar en el recorrido del usuario a través de nuestros
productos. Podemos usarlo aquí para ayudarnos a determinar qué partes de ese viaje son
relevantes para el problema que estamos abordando.

Las métricas piratas se componen de cinco tipos de comportamientos del cliente:

Adquisición

Estas son las actividades que llevan a los clientes al producto en primer lugar. Las
opciones viables aquí incluyen el número de descargas, visitas a la página de registro,
número de registros, etc.

Activación

Una vez que se ha adquirido un cliente, podemos empezar a medir si en realidad están
usando el producto. Las métricas de activación incluyen cosas como la cantidad de
cuentas creadas, la cantidad de personas seguidas, el porcentaje de nuevos registros
que realizaron una compra, etc. Estas métricas deben reflejar la funcionalidad principal
del producto.

Retencion

Si podemos lograr que los clientes prueben el producto, el próximo desafío es lograr
que continúe usándolo de forma regular. En este caso, la "base regular" será contextual
para su producto. (Para un producto como Netflix, medirías los hábitos de visualización
diarios, pero si creas un termostato de "aprendizaje" inteligente, probablemente
medirías cuántas interacciones tuvo el usuario con el dispositivo). Si estamos reteniendo
clientes, en términos generales , regresan con frecuencia para usar el producto, están
haciendo más en el producto y también están gastando tiempo.

Ingresos
 Si les hicimos llegar al producto, los convencimos de que lo probaran, y ahora
están usándolo regularmente, ¿nos están pagando? Ese es el siguiente nivel de
compromiso que buscamos en nuestros clientes. Nuestro objetivo es ver dónde y cómo
estamos convirtiendo a los clientes en usuarios pagos y cómo esos patrones evolucionan
con el tiempo. Las métricas a considerar aquí incluyen el porcentaje de usuarios pagos
versus gratuitos, el valor promedio de vida de cada cliente, etc.

Remisión

El último paso en el embudo de Pirate Metrics es evaluar si nuestro los clientes están
refiriendo a otros al producto. Si realmente lo aman, sienten que están obteniendo valor
de él y no pueden vivir sin él, se lo dirán a sus amigos o en Internet a través de
reseñas. Este es el mejor tipo de marketing que puede obtener. Las métricas para
rastrear aquí incluyen el porcentaje de nuevos usuarios que llegaron a través de
referencias, el porcentaje de usuarios actuales que refieren a otros y el costo de
adquisición por nuevo usuario.

En este punto, probablemente hayas notado que el acrónimo de este método deletrea
AARRR, que es, aparentemente, cómo hablan los piratas, de ahí el nombre Pirate
Metrics. Podemos decir con seguridad que ninguno de los dos ha conocido nunca a un
pirata y, por lo tanto, no podemos confirmar que se trate de un lenguaje pirata.

Tipo de viaje del usuario: Metrics Mountain

Una de las cosas que nos ha molestado durante un tiempo acerca de Pirate Metrics es
su visualización como un embudo. En el mundo real, todo lo que pones en un embudo
sale de ese embudo. Se tarda un poco más, pero la idea de que parte del líquido (por
ejemplo) que viertes en la parte superior del embudo no salga por la parte inferior es
ridícula. Por supuesto que lo hará. ¡Hay un agujero en el otro extremo! Tenía que haber
una metáfora mejor.

En lugar de un embudo, presentamos Metrics Mountain ( Figura 6-2 ).

Figura 6-2. Montaña métrica. Concepto de Jeff Patton y Jeff Gothelf.

La idea de una montaña para visualizar el ciclo de vida del cliente tiene mucho sentido
porque nuestro objetivo es llevar la mayor cantidad de nuestros clientes a la cima de la
montaña. Sin embargo, de manera realista, vamos a perder gente en el camino. Se
cansarán. Se aburrirán. Se distraerán. Ellos desertarán a un competidor. No todos lo
lograrán (es decir, donde se rompe la metáfora del embudo).

A medida que sus clientes ascienden por Metrics Mountain, se les pide que hagan más y
más con su producto o servicio (el ascenso se vuelve más difícil). Su objetivo es hacer
que el proceso sea lo más fácil posible y motivarlos a seguir adelante. Algunos de ellos
harán eso, especialmente si tiene una propuesta de valor, una experiencia de usuario y un
modelo de negocio convincentes. Pero cada vez más, a medida que sus clientes suben la
montaña, se irán bajando. Nuestro objetivo debe ser construir el tipo de experiencias que
lleven al mayor porcentaje de personas a la cima de la montaña.

Facilitar la conversación sobre los resultados comerciales con Metrics Mountain

Puede utilizar la metáfora de la montaña para facilitar la conversación con su equipo y las
partes interesadas acerca de los comportamientos que cree que sus usuarios deberían estar
progresando a medida que usan su producto. He aquí cómo hacerlo:

1. Comience en la base e identifique lo primero que debe hacer un usuario para

comenzar usando su producto. ¿Cómo los adquieres?¿Cómo encuentran la nueva
función en la que estás trabajando?
2. Defina una "meseta" en la montaña para cada paso posterior del recorrido del
cliente y determine el comportamiento del usuario que se necesita para llegar allí.
3. ¿Qué porcentaje de usuarios subiendo la montaña su equipo considera exitoso en
cada paso? Suma esos números al diagrama de la montaña.
1. Por ejemplo, del 100% de sus visitantes diarios, le gustaría ver al menos
el 75% descubrir la nueva función que está creando, y el 50% de esa
gente la prueba. A partir de ahí, le gustaría ver al menos el 25% de los
que intentaron seguir usando la función semanalmente,y el 10% de ellos
finalmente le pagará por esta nueva capacidad.
4. Si no está seguro acerca del recorrido exacto de su cliente, comience con Pirate
Metrics como las cinco “repisas” de la montaña. Ésta es una buena forma de
comenzar este ejercicio.

Tipo de viaje del usuario: viajes del servicio y mapas de historias del usuario

A veces, visualizar el viaje del usuario como un embudo o una montaña no tiene
sentido.Conoce bien su producto y es posible que estos modelos no se apliquen en su
caso. No lo fuerces. En su lugar, puede crear un mapa de viaje de servicio o un mapa de
historias de usuario que mapee más de cerca la forma en que un usuario se mueve a través
de su producto o servicio. El formulario no es realmente importante aquí: utilice el
método que tenga sentido para usted y su producto. El objetivo es poder visualizar el flujo
a través del producto de una manera que todos puedan ver y comprender, luego usar ese
modelo para acercarse a las partes más importantes del viaje, identificar los
comportamientos específicos cruciales para el éxito de su iniciativa y determinar las
métricas de resultados que indicarían el éxito de ese viaje.
Mapeo de resultado a impacto
El mapeo de resultado a impacto es otra técnica para visualizarla conexión entre las
métricas de impacto en la declaración de su problema comercial y los resultados tácticos
que espera ver en sus clientes. Funciona bien con su equipo de nivel de función y también
es un ejercicio poderoso para hacer junto con sus partes interesadas.

Este ejercicio también visualiza la concepto de indicadores adelantados y

rezagados. Descubrirá que las métricas de impacto son más a menudo indicadores
rezagados: medidas retrospectivas de lo que ya ha sucedido. A medida que avanza este
ejercicio, encontrará muchas de las métricas de nivel inferior,los resultados, para ser
indicadores líderes. Estos comportamientos son a menudo las cosas que deben suceder
antes de que podamos lograr la métrica de impacto. Por ejemplo, un cliente primero debe
descargar nuestra aplicación antes de poder gastar dinero en nuestro servicio. El primero
es un indicador adelantado del segundo. Lo que los equipos encuentran a menudo es que
hay muchos indicadores principales para una o dos métricas de impacto. Este ejercicio
ayuda a arrojar luz sobre ese hecho y obliga a una conversación (con suerte) productiva
sobre la priorización.

Así es como funciona:

1. Reúna al equipo y a los clientes potenciales en una sala de reuniones.

2. En una pizarra, pídale a la persona mejor pagada de la sala que escriba el objetivo
estratégico actual para el año en la parte superior de una serie de notas adhesivas.
3. Debajo de eso, pídale a esa misma persona (u otro ejecutivo) que enumere las
medidas de éxito para esa estrategia (pista: estas deben ser métricas de impacto y,
a menudo, son indicadores rezagados).
4. Debajo de cada métrica de impacto, comience a dibujar líneas que sobresalgan de
cada una (como si estuviera construyendo un organigrama).
5. Pídale a la sala que complete la línea debajo de las métricas de impacto con los
comportamientos de los clientes que impulsan esas métricas (indicadores
principales). Utilice Post-its y haga que todos trabajen individualmente en una
lluvia de ideas inicial.
6. Ahora haga que el equipo haga otra fila debajo de la última que muestre los
comportamientos del cliente que impulsan el conjunto inicial de resultados.

En este punto, su pizarra debería comenzar a parecerse al mapa que se muestra en

la Figura 6-3 :
Figura 6-3. Mapeo de resultado a impacto

Una vez que todos hayan contribuido, debe tener docenas de Post-its en la pizarra que
indiquen una variedad de comportamientos de los clientes (resultados) que ayudarán a su
empresa a alcanzar su objetivo estratégico y sus objetivos de impacto. También en este
punto, su equipo puede estar abrumado. La mayoría de las veces que hemos realizado este
ejercicio, al equipo nunca se le ocurre que hay tantas formas de impulsar un cambio
positivo.

Ahora, la parte difícil. A través de una ronda de votación puntual (u otro ejercicio de
selección facilitado), pida al equipo que elija los 10 resultados en los que creen que
deberían centrarse primero.

Lo que ha hecho aquí es crear una conexión directa entre los resultados (comportamientos
del cliente) y las métricas de impacto (lo que les importa a los ejecutivos) y los obligó a
elegir dónde debería concentrarse para el próximo ciclo. El último paso es crear una línea
de base para cada uno de estos resultados (es decir, dónde están hoy) y una meta (es decir,
dónde nos gustaría que estuvieran al final del ciclo) y asignarlos al equipo como metas.
para su próximo ciclo.

Ahora, cada vez que un equipo informa sobre el progreso de su resultado específico, sus
partes interesadas tendrán una idea clara de por qué el equipo está trabajando en eso
y cómo afecta las métricas de impacto que más les importan.

De qué estar atento

No todo número o porcentaje es una métrica de resultado. Jeff estaba trabajandocon un
gran conglomerado minorista alemán en este ejercicio específico. Su objetivo de nivel de
impacto era aumentar las ventas en la misma tienda año tras año. Mientras trabajábamos
en el ejercicio de mapeo de resultado a impacto, algunos miembros del equipo agregaron
elementos a las filas de resultados que decían "porcentaje de productos en el estante que
son de nuestra marca". Ahora, técnicamente, esta es una métrica, pero no es una medida
del comportamiento del cliente. Es una decisión de estrategia de producto que espera que
impulse el comportamiento del cliente. Un problema similar surgió una vez con otro
cliente que estaba construyendo una herramienta de automatización. Una persona del
equipo enumeró el "porcentaje de tareas manuales ahora automatizadas por el
sistema". Nuevamente, esta no es una medida del comportamiento del cliente. Es una
faceta del sistema que se está construyendo, una decisión de producto. El objetivo final
era reducir la cantidad de tiempo que el personal dedicaba a tareas repetitivas, quees una
buena métrica de resultados.

La otra cosa que hemos visto a menudo es que estos gráficos se vuelven desordenados. Es
fácil hacer que se vean bien en un libro o en una diapositiva de PowerPoint. En realidad,
nuestros negocios no son tan lineales y estos gráficos pueden volverse un poco difíciles
de manejar ( Figura 6-4 ). Los equipos a menudo encontrarán que un resultado genera
múltiples métricas de impacto (esto es perfectamente razonable) y debe duplicarse en
todo el gráfico. Cree el gráfico que funcione para su empresa y su equipo. Simplemente
no comprometa el contenido del ejercicio.
Figura 6-4. Ejemplo del mundo real de un mapa de resultado a impacto, cortesía de Delphine Sassi
y el equipo de King
 Capítulo 7. Recuadro 3: Usuarios

Figura 7-1. Recuadro 3 del Lean UX Canvas: Usuarios

Los diseñadores han sido durante mucho tiempo defensores del usuario final. Lean UX
nocambia eso. A medida que hacemos suposiciones sobre nuestro negocio y los
resultados que nos gustaría lograr, aún debemos mantener al usuario al frente y al centro
de nuestro pensamiento. El recuadro 3 del lienzo inicia una conversación más profunda
sobre nuestro público objetivo.

La mayoría de nosotros aprendimos a pensar en una persona como una herramienta para
representar lo que aprendimos en nuestra investigación. Y a menudo ocurría el caso de
que creamos personas como resultado de estudios de investigación largos y costosos. Hay
algunos problemas con las personas que se crean de esta manera.

Primero, tendemos a considerarlos intocables debido a todo el trabajo que se llevó a cabo
para crearlos. Además, a menudo ocurre que estas personas fueron creadas por un equipo
de investigación o un proveedor externo. Esto crea una brecha de conocimiento
arriesgada entre las personas que realizaron la investigación y las que utilizan las
personas.

En Lean UX, cambiamos el orden de las operaciones en el proceso de persona. También

cambiamos la creación de personas de una actividad única a un proceso continuo, uno
que tiene lugar cada vez que aprendemos algo nuevo sobre nuestros usuarios.

Al crear personas en este enfoque, comenzamos con suposiciones yluego investigue para
validar nuestra suposición. En lugar de pasar meses en el campo entrevistando personas,
pasamos unas horas creando protopersonas. Proto-personas son nuestra mejor conjetura
sobre quién está usando (o usará) nuestro producto y por qué. Los bosquejamos en papel
con la contribución de todo el equipo; queremos capturar las suposiciones de
todos. Luego, a medida que realizamos una investigación en curso, descubrimos
rápidamente cuán precisas son nuestras conjeturas iniciales y ajustamos nuestras personas
en respuesta.

Además de poner al cliente al frente y al centro de un equipo de desarrollo de productos

diverso, las proto-personas sirven para dos propósitos clave más.

Entendimiento compartido

Imagine a su equipo sentado alrededor de una mesa y alguien dice la palabra

"perro". ¿Qué imagen te viene a la mente? ¿Es la misma imagen que les viene a
la mente a sus colegas ( Figura 7-2 )? ¿Cómo lo sabes?

Figura 7-2. Perros. Estamos en deuda con nuestro erudito colega Adrian Howard por este
concepto .
Lo mismo sucede cuando alguien dice "el usuario". El enfoque de proto-persona asegura
que todos tengan la misma imagen en su cabeza cuando se invoca al "usuario".

Recordando que no somos el usuario

A menudo es fácil asumir que nuestros usuarios son como nosotros, especialmente si
consumimos los productos que fabricamos. La realidad es que tenemos un nivel de
comprensión y tolerancia por la tecnología que nuestros clientes rara vez
comparten. Pasar por un ejercicio de protopersona pone el foco en los usuarios
externos, alejando al equipo de sus preferencias personales por el producto.

USING PROTO-PERSONAS

Un equipo con el que trabajábamos en Nueva York estaba creando una aplicación
quemejoró la experiencia de Agricultura Apoyada por la Comunidad (CSA) para los
residentes de la Ciudad de Nueva York. CSA es un programa que permite a los residentes
de la ciudad juntar su dinero y comprar productos agrícolas por valor de una temporada
completa de un agricultor local. El agricultor luego entrega las cosechas semanalmente a
los miembros de la CSA. Muchos suscriptores de la CSA son personas de entre 20 y 30
años que necesitan hacer malabarismos con una vida laboral ocupada, una vida social
activa y el deseo de participar en la CSA.

El equipo asumió que la mayoría de los consumidores de CSA eran mujeres a las que les
gustaba cocinar. Pasaron aproximadamente una hora creando una persona llamada
Susan. Pero cuando salieron al campo para investigar con jóvenes profesionales de 20
años, rápidamente se dieron cuenta de que la inmensa mayoría de los cocineros y, por lo
tanto, los posibles usuarios de su aplicación, eran hombres jóvenes. Regresaron a la
oficina y revisaron su personalidad para crear a Anthony.
Anthony demostró ser un usuario objetivo mucho más preciso. El equipo no había perdido
más tiempo refinando ideas para el público equivocado. Ahora estaban enfocados en una
audiencia que, aunque todavía no era perfecta, era mucho más correcta que sus
suposiciones iniciales.

The Proto-Persona Template

Nos gusta dibujar protopersonas en papel utilizando tressecciones ( Figura 7-3 ). El
cuadrante superior izquierdo contiene un esbozo de la persona junto con un nombre y
función. El cuadro superior derecho contiene información demográfica, psicográfica y de
comportamiento básica. Un antipatrón de las personas que vemos es un énfasis excesivo
en la demografía. Para el diseño de productos, nos preocupamos menos por la demografía
y más por las necesidades, objetivos y comportamientos. Por lo tanto, cuando piense en
datos demográficos, intente centrarse en la información que predice un tipo específico de
comportamiento: comportamiento relevante para nuestro producto o servicio. Por
ejemplo, puede haber casos en los que la edad de la persona sea totalmente irrelevante,
mientras que su acceso a un dispositivo específico, como un iPhone, cambiará por
completo la forma en que interactúa con su producto. Solo queremos anotar las
"diferencias que marcan la diferencia".
Figure 7-3. A completed proto-persona template

La mitad inferior de la proto-persona es donde colocamos los detalles más

importantes. Aquí capturamos los objetivos, las necesidades, los resultados deseados y
los obstáculos que les impiden alcanzar estas necesidades. Recuerde que los usuarios rara
vez necesitan "funciones". Lo que necesitan es alcanzar algún tipo de objetivo. (No
siempre es un objetivo concreto: a veces es un objetivo emocional, un deseo no articulado,
etc.) Es nuestro trabajo decidir la mejor manera de llevarlos a sus objetivos.
Facilitar el ejercicio
Una vez más, nos gusta comenzar el proceso de creación de personas con una lluvia de
ideas:

1. Los miembros del equipo comienzan ofreciendo sus opiniones sobre a quién
debería dirigirse el proyecto y cómo eso afectaría su uso del producto.
2. El equipo crea una lista de tipos de personas.

Por ejemplo, esta lista podría contener segmentos objetivo como "estudiantes
universitarios", "entusiastas del streaming", "trabajadores médicos de primera
línea", etc.

3. Reduzca las ideas a un conjunto inicial de tres o cuatro personas que el equipo
crea que tienen más probabilidades de ser su público objetivo.
4. Trate de diferenciar a las personas en función de las necesidades y los roles en
lugar de la información demográfica.
5. Una vez que haya reducido la lista de usuarios potenciales, haga que el equipo
complete una plantilla de protopersona para cada uno.

Puede dividirse en grupos pequeños y hacer que cada grupo se concentre en una
persona, luego tráigalos al grupo para que los revise.

6. Revisa cada personaje en función de los comentarios.

Una vez que tenga un conjunto de personas con las que esté de acuerdo, compártalas con
sus colegas más allá del equipo para obtener sus comentarios.

Validación anticipada

En este punto del proceso, puede comenzar a validar algunos de sus

primeros supuestos. De hecho, antes de profundizar demasiado en la declaración de
suposiciones, este es un buen lugar para comenzar a probar algunas de esas
suposiciones. Utilice sus personajes como objetivos de reclutamiento para comenzar su
investigación.

Inmediatamente, hay tres cosas que puede determinar en función de sus proto-personas:

¿Existe el cliente?

Al contratar a las personas que creó, puede determinar rápidamente qué tan realistas
son las suposiciones de su equipo. Si no puede encontrar a las personas que dibujó,
probablemente no existan. Aprenda de eso y edite sus personajes .

¿Tienen las necesidades y los obstáculos que crees que tienen?

En otras palabras, ¿estamos resolviendo problemas reales? Puede medir esto

simplemente observando y hablando con las personas que recluta. Si estas
conversaciones y observaciones no confirman el problema, entonces está creando
soluciones para problemas que no existen, y eso rara vez termina bien.
¿Valorarían una solución a este problema?

El hecho de que un cliente sea real y tenga los puntos débiles que está resolviendo, no
significa que valorará una nueva forma de resolver ese problema. En otras palabras, solo
porque comen bananas en su cereal todos los días y no les gusta cortar bananas, no
significa que comprarán su cortadora de bananas ( Figura 7-4 ). Es importante
comprender cómo sus clientes están resolviendo actualmente estas necesidades y qué
probabilidades hay de que su idea desplace a la solución existente. Si está tratando de
desplazar herramientas de larga data como el correo electrónico o las hojas de cálculo,
es posible que se encuentre en una dura batalla. Es bueno obtener esa información más
temprano que tarde.

Figura 7-4. La cortadora de plátano. ¿Quién compra estos?

Una vez trabajamos con una startup que atendía las necesidades de inversores ángel
mediante la creación de un repositorio en línea para todo lo relacionado con sus
inversiones. Era un producto robusto que prometía agilizar y simplificar la vida de estos
usuarios. Al unirnos al proyecto, trabajamos con el equipo para construir proto-personas
y nos propusimos encontrar el público objetivo. Resulta que esto no fue un desafío en
absoluto. En los Estados Unidos, al menos, hay muchas personas que califican como
inversionistas ángeles (es decir, tienen entre 50 y 100 mil dólares adicionales para
invertir). ¡La persona existe!

A continuación, comenzamos a hablar con estas personas para comprender si les

estábamos resolviendo un problema real. Resulta que, sí, de hecho, el seguimiento de
presentaciones, hojas de términos, tablas de límites y la información de la ronda de
seguimiento fue tedioso para esta audiencia. ¡El problema existe! Esto se estaba
volviendo emocionante.

Finalmente, el equipo comenzó a captar una tendencia cuando la conversación se centró

en soluciones digitales para este problema. La inmensa mayoría de nuestro público
objetivo, algo cercano al 95%, invirtió una o dos veces al año como máximo. Para una o
dos inversiones por año, el correo electrónico y Microsoft Excel funcionaron
bien. Nuestra audiencia estaba íntimamente familiarizada con estas herramientas, y
ninguna cantidad de solidez, complejidad o incluso facilidad de uso de nuestra
herramienta de gestión de inversiones en línea haría que nuestra audiencia abandonara el
correo electrónico y Excel en favor de nuestro producto. La herramienta que estábamos
construyendo era para el 5% de inversores para los que esta era una profesión, una
población demasiado pequeña para justificar el esfuerzo que se estaba poniendo en el
producto que se estaba construyendo. Esa fue una conversación difícil de tener en la
oficina, como puedes imaginar. El hecho de que la persona exista y le esté resolviendo un
problema real no siempre significa que valorarán la solución que está construyendo. Es
mejor averiguarlo ahora, en Box 3 en Lean UX Canvas, que una vez que haya comenzado
a enviar el código a producción.

De qué estar atento

Muchos equipos con los que hemos trabajado y de los que hemos escuchado a lo largo de
los años ejecutan este ejercicio de proto-persona; sin embargo, muchos menos de ellos
realmente regresan y ajustan su pensamiento después del ejercicio de creación inicial. Es
importante que consideres a las proto-personas como documentos vivos. Cada vez que
realice conversaciones con clientes o estudios de usabilidad, pregúntese cuántas de las
creencias actuales del equipo sobre su público objetivo siguen siendo ciertas. A medida
que se revele nueva información, póngala en discusión y ajuste las personas para que los
esfuerzos de investigación futuros puedan ser más específicos y exitosos.
Capítulo 8. Recuadro 4: Resultados y
beneficios del usuario

Figura 8-1. Recuadro 4 del Lean UX Canvas: Resultados y beneficios del usuario

A pesar de la proliferación de técnicas ágiles como las historias de usuario, el usuario y

su los objetivos a menudo se pierden en los prolongados debates sobre características,
diseños e implementaciones técnicas. La empatía está en el corazón de excelentes
productos y servicios.Los diseñadores a menudo han sido responsables de defender al
usuario desde un punto de vista empático. Como sabemos ahora, esto no es
responsabilidad exclusiva del diseñador.Para lograr una comprensión compartida más
amplia de los usuarios y un sentido más profundo de empatía por lo que están tratando de
lograr, les pedimos a nuestros equipos que declaren sus suposiciones sobre lo que los
usuarios están tratando de hacer, en forma de resultados y beneficios para los usuarios.

Antes de comenzar con el recuadro 4, es posible que se esté preguntando: ¿Cuál es la

diferencia entre los resultados comerciales, los resultados del cliente y los resultados del
usuario? Buena pregunta. Echemos un vistazo a un ejemplo en el que trabaja para una
empresa que fabrica software de seguimiento de gastos corporativos.

El resultado comercial que la empresa está tratando de lograr es adquirir más clientes,
retener los que ya tienen y aumentar los ingresos mensuales por suscripción de software.

Los clientes de esta empresa, otras empresas que compran el software de seguimiento de
gastos para sus empleados, están tratando de mejorar la eficiencia de sus equipos de
contabilidad, reducir el pago de gastos que no son reembolsables y reducir los costos
operativos generales.
Los usuarios del software son los empleados de estas empresas clientes. Su objetivo
deseado es obtener el reembolso de sus gastos lo más rápido posible y reducir el tiempo
que les lleva ingresar esos gastos correctamente.

Todos estos siguen siendo resultados basados en el comportamiento, pero cada uno tiene
su propio punto de vista. En otras palabras, se refieren a los diferentes objetivos que
persiguen los diferentes grupos de personas.

Además del cambio de comportamiento, existen objetivos emocionales tanto a nivel del
cliente como del usuario. Los compradores de este software quieren sentir que están
ayudando a la empresa a tener más éxito y rentabilidad. Quieren verse bien ante sus jefes
y quieren poder señalar sus contribuciones específicas al éxito de la empresa. Esto los
motivaría a buscar una marca de software de seguimiento de gastos que les permita
hacerlo fácilmente.

Los usuarios del software desean que se les reembolse rápidamente y confían en que sus
gastos se reembolsarán por completo sin una gran cantidad de trámites burocráticos y
problemas corporativos. Esto motivaría a estos usuarios a ser más diligentes y deliberados
en el uso de este software en lugar de convertirlo en otra herramienta de TI corporativa
que no se usa o se soluciona.

Vale la pena señalar que todos estos resultados son importantes y deben mencionarse
específicamente como resultados comerciales, de clientes o de usuarios. Sin embargo, no
todos son cuantificables.Cumplir con los objetivos emocionales de los usuarios es difícil,
sobre todo si el equipo tiende a centrarse en las métricas, porque se miden estos factores
emocionales de diferentes formas. Dicho esto, el hecho de que sea difícil no significa que
no debas prestar atención a este tipo de objetivos. Estos objetivos emocionales son
fundamentales: son los que ayudan a los equipos a comprender qué tipo de experiencia
están tratando de ofrecer y, en última instancia, si lo hace bien, conducirán a un mejor
rendimiento en las métricas cuantificables.

Facilitar el ejercicio
Una vez que se hayan creado sus protopersonas, puede utilizar el material en la parte
inferior de la proto-persona como base para esta discusión. Trabajando individualmente,
en grupos pequeños o como un equipo completo, trabaje a su manera a través de cada
proto-persona. Utilice las siguientes preguntas como indicaciones:

¿Qué está tratando de lograr el usuario?

Respuesta de ejemplo: quiero comprar un teléfono nuevo.

¿Cómo quiere sentirse el usuario durante y después de este proceso?

Ejemplo de respuesta: Quiero sentir que tengo el teléfono que necesito a un buen precio
y que estoy al día con mis compañeros (es decir, quiero sentirme bien).

¿Cómo nuestro producto o servicio acerca al usuario a una meta o sueño en la vida?

Ejemplo de respuesta: Quiero sentirme conocedor de la tecnología y respetado por ello.

¿Por qué su usuario buscaría su producto?

Respuesta de ejemplo: quiero encajar con mis amigos en la escuela.

¿Qué cambio de comportamiento podemos observar que indique que han logrado su objetivo?

Ejemplo de respuesta: Traen su nuevo teléfono a la escuela todos los días.

Tenga en cuenta que no todos los resultados de los usuarios existen en todos los
niveles. Pero pensar en los resultados en estos términos puede ayudarlo a encontrar
dimensiones importantes de su solución en las que trabajar, desde los resultados
funcionales y orientados a tareas hasta los resultados más emocionales orientados a la
experiencia.

Esta sección del lienzo es donde el equipo se adentra en el lado emocional de la

conversación. No estamos hablando de funciones, píxeles o código aquí. Queremos
entender qué impulsa a nuestras personas a buscar nuestro producto y, cuando lo
encuentran, qué podrían hacer. Cuando llega el momento de comenzar a probar,
comercializar o publicitar el producto, el trabajo que hacemos en esta sección se convierte
en una mina de oro para el contenido, las llamadas a la acción y el texto instructivo útil.

De qué estar atento

A veces, los equipos se centran tanto en las funciones que este ejercicio se convierte en
un ejercicio recursivo. Hemos visto a los equipos escribir características en esta sección
porque asumen que eso es lo que motiva a sus clientes. Anotar un beneficio para el usuario
como "integración de calendario" no es el objetivo de este ejercicio. El objetivo aquí es
comprender las necesidades latentes del usuario. “Nunca llegues tarde a otra reunión” es
mucho más importante y atractivo para el usuario que los detalles de la función que lo
ayudarán a lograrlo. Apple siempre es muy bueno para diferenciar el iPhone de esta
manera frente a Samsung y otros competidores. Mientras que la competencia está
promocionando características como "cámara de 12 megapíxeles", Apple anuncia,
"Muéstrale a la abuela el bebé de todo el país".
Capítulo 9. Recuadro 5: Soluciones
Figura 9-1. Recuadro 5 del Lean UX Canvas: Soluciones

Finalmente llegamos al punto en el proceso Lean UX cuando hablamos de

soluciones. Esto es por diseño. Si bien ciertamente podríamos haber comenzado nuestro
trabajo discutiendo las soluciones o características que nos gustaría construir (y, en la
mayoría de los casos, ahí es donde comienzan los proyectos: ¡con las soluciones
requeridas!), Nuestro trabajo es mejor cuando damos un paso atrás y ponemos algunas
restricciones en su lugar. . En nuestro caso, hemos establecido restricciones con nuestra
declaración de problemas comerciales, los resultados comerciales, el trabajo personal que
hemos realizado y nuestra discusión sobre los resultados y beneficios del usuario. Sin esas
limitaciones, las soluciones resolverán el problema equivocado para las personas
equivocadas o terminarán dispersas y desenfocadas. Cada conjunto de suposiciones que
hemos declarado hasta ahora ha limitado el espacio en el que podemos crear soluciones,
y la creatividad prospera en las limitaciones.

Todavía no nos adentramos en el trabajo de diseño detallado aquí. Eso viene una vez que
completamos el lienzo. Sin embargo, comenzamos a ser específicos sobre lo que creemos
que nos llevará a nosotros y a nuestros clientes de su condición actual a
la condición objetivo .

Facilitar el ejercicio
Como ocurre con la mayoría de estos ejercicios de declaración de supuestos, hay varias
formas de facilitarlos. A continuación, enumeramos varios enfoques para ayudarlo a
comenzar, pero no dude en agregar sus técnicas de lluvia de ideas de diseño favoritas para
ayudarlo a usted y a su equipo a completar el Cuadro 5.

Mapeo de afinidad

El mapeo de afinidad es la forma más sencilla y fácil de obtener en equipo trabajando

juntos en el Cuadro 5. Haga que cada persona trabaje individualmente para generar ideas
de solución que resolverían el problema comercial y lograrían los resultados comerciales
y de usuario deseados para su persona objetivo. Cada persona debe generar tantas ideas
como pueda, poniendo una idea por nota adhesiva. Al igual que con cualquier actividad
de lluvia de ideas, es tan buena como la pregunta de encuadre utilizada para solicitar
respuestas. En este caso, la pregunta que debes plantear a tu equipo es:

¿Qué soluciones podemos diseñar y construir que sirvan a nuestras personas y creen los
resultados deseados?

Cada persona puede escribir palabras o crear pequeños bocetos en las notas adhesivas
durante cinco minutos. Luego, el equipo comparte sus ideas entre sí, clasificando ideas
similares en grupos antes de votar por puntos qué enfoques creen que tienen las mayores
posibilidades de éxito.

Si bien el mapeo de afinidad lo llevará a través del proceso más rápido, tomarse su tiempo
aquí puede generar beneficios adicionales más allá de solo identificar ideas de soluciones
de alto nivel.
Diseño colaborativo: un enfoque más estructurado

Una forma más deliberada de desarrollar ideas de soluciones es método de diseño

colaborativo que llamamos Design Studio. (Escribimos más sobre métodos de diseño
colaborativo, incluidos Design Sprints, en el Capítulo 14 ). Cuando necesita reunir a todos
para una sesión de trabajo formal, Design Studio es una forma popular de hacerlo.

Este método, nacido en el mundo de la arquitectura donde se llamó Design Charrette,

es una forma de reunir a un equipo multifuncional para visualizar posibles soluciones a
un problema de diseño. Rompe los silos organizacionales y crea un foro para los puntos
de vista de sus compañeros de equipo.

Al reunir a diseñadores, desarrolladores, expertos en la materia, gerentes de producto,

analistas de negocios y otras competencias en el mismo espacio, enfocados en el mismo
desafío, usted crea un resultado mucho mayor de lo que permite trabajar en silos. Tiene
otro beneficio. Comienza a generar la confianza que su equipo necesitará para pasar de
estas sesiones formales a colaboraciones más frecuentes e informales .

Ejecución de un estudio de diseño

La técnica descrita en las secciones que siguen es muy específica; sin embargo, debe
sentirse cómodo para ejecutar estudios de diseño menos o más formales según lo
justifique su situación y el momento. Los detalles del ritual no son tanto el punto como la
actividad de resolver problemas con sus colegas y clientes. Independientemente del
enfoque que elija, recuerde que el objetivo es generar ideas de solución que resuelvan su
problema comercial.

Configuración

Para ejecutar una sesión de Design Studio, querrá encontrar un bloque de tiempo dedicado
dentro del cual puede reunir al equipo. Debe planificar un bloque de al menos tres
horas. Querrá una habitación con mesas alrededor de las cuales la gente pueda
reunirse. La habitación debe tener un buen espacio en las paredes, de modo que pueda
colocar el trabajo en progreso en las paredes a medida que avanza.

Si está trabajando en una sesión remota, use una buena herramienta de pizarra de equipo
como Mural o Miro. Recuerde dedicar un tiempo a asegurarse de que todos se sientan
cómodos con la herramienta que elija; es posible que tenga que dedicar algo de tiempo al
comienzo de la reunión para que todos estén al tanto de las herramientas.

El equipo

Este proceso funciona mejor para un equipo de cinco a ocho personas.Si tiene más
personas, puede crear más equipos y hacer que los equipos comparen los resultados al
final del proceso. (Los grupos más grandes tardan mucho tiempo en completar los pasos
de crítica y retroalimentación, por lo que es importante dividir los grupos de más de ocho
personas en equipos más pequeños, que pueden pasar por el siguiente proceso en paralelo,
convergiendo al final).
Con sesiones remotas, aquí es donde una videoconferenciaLa función de "sala de
descanso" entra en juego. Dado que no tenemos espacio físico para dividirnos, las salas
de grupos de video brindan a cada equipo la privacidad y el enfoque que necesita para
hacer su propio trabajo.

Proceso

Design Studio trabaja dentro del siguiente flujo:

• Definición de problemas y limitaciones

• Generación de ideas individuales (divergencia)
• Presentación y crítica
• Iterar y refinar en pares (emerger)
• Generación de ideas de equipo (converger)

Suministros

Para la sesión en persona, estos son los suministros que necesitará:

• Lapices
• Plumas
• Rotuladores con punta de fieltro o similares (varios colores / grosores)
• Resaltadores (varios colores)
• Plantillas de bocetos (puede usar plantillas preimpresas de una en una y de seis en
una, o puede usar hojas en blanco de papel de 11 "x 17" [A3] divididas en seis
cajas)
• Almohadillas de caballete autoadhesivas de 25 "x 30,5" (A1)
• Dibujar puntos (o cualquier tipo de pegatinas pequeñas)

Con equipos distribuidos, todas estas herramientas se vuelven discutibles en favor de la

herramienta de colaboración en línea que ha elegido utilizar. Dicho esto, hemos visto que
algunos facilitadores remotos todavía desafían a las personas a usar papel y bolígrafo para
los bocetos iniciales, fotografiar esos bocetos y compartirlos en la herramienta de pizarra
en línea después de crearlos localmente.

Definición del problema y limitaciones (15 minutos)

El primer paso en Design Studio es asegurarse de que todos estén consciente de las
suposiciones que ha declarado hasta ahora: el problema comercial que está tratando de
resolver, los resultados que definen el éxito del esfuerzo, los usuarios a los que está
atendiendo y los beneficios que están tratando de lograr. En la mayoría de los casos, el
equipo ya es consciente de esto, ya que han trabajado juntos en el lienzo hasta este
momento. Si no han hecho este trabajo juntos, planifique un tiempo adicional para
informar al equipo y responder sus preguntas.

Generación de ideas individuales (10 minutos)

Trabajará individualmente en este paso. Entregue a cada miembro del equipo una plantilla
de seis, que es una hoja de papel con seis casillas vacías, como se muestra en la Figura 9-
2 . Puede hacer uno doblando una hoja en blanco de papel de 11 ”x 17” (A3), o hacer una
plantilla preimpresa para entregar a los participantes. (Si está utilizando una herramienta
en línea, no obligue a las personas a dibujar en esa herramienta, que suele ser difícil y
lenta. En su lugar, pida a las personas que trabajen en papel y luego comparta una foto o
escanee).

Figura 9-2. Una plantilla de "seis" en blanco

A veces, a las personas les resulta difícil enfrentarse a una página en blanco. Si ese es el
caso, pruebe este paso opcional. Pídale a todos que etiqueten cada cuadro en sus hojas
con una de sus personas y el punto de dolor o problema específico que abordarán para esa
persona. Escriba el nombre de la persona y el punto de dolor en la parte superior de cada
una de las seis casillas. Puede escribir el mismo par de persona / punto de dolor tantas
veces como tenga soluciones para ese problema, o puede escribir una combinación de
persona / punto de dolor diferente para cada cuadro. Cualquier combinación
funciona. Dedique cinco minutos a hacer esto.

A continuación, con sus hojas de seis en frente, dé a todos cinco minutos para generar
seis bocetos de soluciones de baja fidelidad (consulte la Figura 9-3 ) para cada par de
persona / problema en su hoja de seis en uno. Deben ser articulaciones visuales (bocetos
de la interfaz de usuario, flujos de trabajo, diagramas, etc.) y no palabras escritas. Anime
a su equipo revelando el pequeño y sucio secreto del diseño de interacción: si puede
dibujar un círculo, un cuadrado y un triángulo, puede dibujar todas las interfaces. Estamos
seguros de que todos en su equipo pueden dibujar esas formas, y esta idea aparentemente
tonta puede ayudar a nivelar el campo de juego.
Figura 9-3. Una pared llena de seis dibujos completos.
Presentación y crítica (3 minutos por persona)

Cuando se acabe el tiempo, comparte y critica lo que has hecho hasta ahora. Al recorrer
la sala, dé a los participantes tres minutos para compartir sus bocetos y presentarlos al
equipo ( Figura 9-4 ). Los presentadores deben indicar explícitamente para quién estaban
resolviendo un problema (en otras palabras, qué persona) y qué punto de dolor estaban
abordando, y luego explicar el bosquejo.

Cada miembro del equipo debe brindar críticas y comentarios al presentador. Los
miembros del equipo deben centrar sus comentarios en aclarar las intenciones del
presentador.

Ayude a su equipo a comprender que dar buenos comentarios es un arte. Recuérdeles que,
en general, es mejor hacer preguntas que compartir opiniones. Las preguntas ayudan al
equipo a hablar sobre lo que están haciendo y ayudan a las personas a pensar en su
trabajo. Las opiniones, por otro lado, pueden detener la conversación, inhibir la
colaboración y poner a la gente a la defensiva. Por lo tanto, cuando brinde críticas, intente
utilizar preguntas como "¿Cómo aborda esta función el problema específico de la
persona?" o “No entiendo esa parte del dibujo. ¿Puedes elaborar?" Preguntas como estas
son muy útiles. Comentarios como "No me gusta ese concepto" proporcionan poco valor
y no le dan al presentador ideas concretas para usar en la iteración.
Figura 9-4. Un equipo que presenta y critica dibujos durante un estudio de diseño.
Emparejar para iterar y refinar (10 minutos)

Ahora pida a todos que se emparejen para la siguiente ronda.(Si dos personas en la sesión
tienen ideas similares, es una buena idea pedirles que trabajen juntas). Para las sesiones
remotas, cada pareja debe trabajar en su propia sala de reuniones.

Cada pareja trabajará para revisar sus ideas de diseño ( Figura 9-5 ). El objetivo aquí es
que cada pareja elija las ideas que tienen más mérito y desarrolle una versión más
evolucionada e integrada de esas ideas. Cada pareja tendrá que tomar algunas decisiones
sobre qué conservar, qué cambiar y qué desechar. Espere que esto sea difícil y que cada
pareja no esté de acuerdo en algunas cosas. Resista la tentación aquí de crear un acuerdo
rápido volviéndose más general o abstracto. En cambio, pida a cada pareja que tome
algunas decisiones y sea más específico. Haga que cada pareja produzca un solo dibujo
en una hoja de seis hojas de 11 ”× 17” (A3). Dé a cada equipo 10 minutos para este paso.

Cuando se acabe el tiempo, reúna a todos y vuelva a pasar por el proceso de presente y
crítica.
Figura 9-5. Un equipo que trabaja en conjunto en un ejercicio de Design Studio
Generación de ideas de equipo (45 minutos)

Ahora que todos los miembros del equipo tienen comentarios sobre sus Las ideas
individuales y las personas se han emparejado para desarrollar más ideas, el equipo debe
converger en una idea. En este paso, el equipo está tratando de seleccionar las ideas que
creen que tienen más posibilidades de éxito. Este conjunto de ideas servirá como base
para el siguiente paso en el proceso Lean UX: crear hipótesis y, finalmente, diseñar y
ejecutar experimentos .

Pídale al equipo que use una hoja grande de papel de cuaderno autoadhesivo o una pizarra
para dibujar los componentes y el flujo de trabajo de su idea. Habrá muchos compromisos
y disputas en esta etapa, y para llegar a un consenso, el equipo deberá priorizar y reducir
las funciones.

Anime al equipo a crear un "estacionamiento" para las buenas ideasque no hacen el

corte. Esto hará que sea más fácil dejar de lado las ideas. Nuevamente, es importante
tomar decisiones aquí: resista la tentación de llegar a un consenso generalizando o
aplazando las decisiones.

Si ha dividido un grupo grande en varios equipos en el Estudio de diseño, pida a cada equipo que
presente su idea final en la sala cuando hayan terminado para una ronda final de crítica y
comentarios y, si lo desea, convergencia.
Usando la salida

El trabajo que realice en un estudio de diseño se incorporará al creación de hipótesis y

finalmente diseño de experimentos. Esto no significa que todas las ideas pasarán a la
consideración final, pero las ideas en las que el equipo ha convergido se pondrán a prueba
a partir del Cuadro 6, la creación de hipótesis.

Para mantener la salida visible, publíquela en un muro de diseño u otro lugar destacado
para que el equipo pueda consultarla. Decide qué dibujos intermedios (si los hay) quieren
conservar las personas y muéstralos junto con el dibujo final, de nuevo para que los
miembros del equipo puedan consultar las ideas.Independientemente de lo que publiques
en el muro, generalmente es una buena idea fotografiar todo y guardarlo en una carpeta
de archivo de algún tipo. Nunca se sabe cuándo querrá volver para encontrar
algo. También es una buena idea poner a una sola persona a cargo de la creación de este
archivo. Crear cierta responsabilidad tenderá a garantizar que el equipo mantenga buenos
registros.

De qué estar atento

La parte más difícil del diseño colaborativo es garantizar incluso participación. Si
mantiene el ejercicio simple, la mayoría de las personas sentirán que pueden participar
con bastante facilidad. (Todo el mundo puede escribir en una nota adhesiva). Si decide
utilizar técnicas más complejas como Design Studio, deberá asegurarse de que la
facilitación sea de primera categoría. (Y recuerde que todo esto será más difícil en
sesiones remotas). Si los miembros de su equipo se desconectan durante esta parte porque
sienten que estos ejercicios eran demasiado avanzados para ellos, es probable que
presenten una resistencia mucho mayor a algunos de las opciones de características y
diseño que el equipo realiza posteriormente. En este caso, tanto como en cualquier otro
lugar, la facilitación del diseño se convierte en un conjunto de habilidades básicas para
los diseñadores de su equipo.
Capítulo 10. Recuadro 6: Hipótesis

Figura 10-1. Recuadro 6 del Lean UX Canvas: Hipótesis

Cuando el equipo llega al Box 6, tiene toda la materia prima que necesita. necesita
empezar a escribir hipótesis tácticas y comprobables. Sin embargo, antes de hacer eso,
hablemos de hipótesis en general.

Hipótesis se ha convertido recientemente en una palabra popular en el desarrollo de

productos, en gran parte porque de The Lean Startup , en el que Eric Ries describe un
método de desarrollo de productos inspirado en el método científico. Aboga por probar
sus hipótesis temprano y con frecuencia. Entonces, ¿qué es una hipótesis de todos
modos? Según el Diccionario Oxford de Palabras Difíciles , es "una suposición o
explicación propuesta hecha sobre la base de evidencia limitada como punto de partida
para una mayor investigación". 1

Eso es lo que estamos a punto de crear: vamos a tomar todas nuestras suposiciones (las
suposiciones son declaraciones basadas en "evidencia limitada"), y las vamos a reunir en
una declaración unificada (nuestra "explicación propuesta" de nuestro problema y
solución) para que podamos comenzar nuestro proceso de investigación y prueba (nuestro
" investigación exahustiva").

Bien, con eso fuera del camino, comencemos a escribir hipótesis. Esta es la plantilla que
recomendamos:

Creemos que lograremos [este resultado comercial]

Si [estas personas]

Obtenga [este beneficio / resultado del usuario]

Con [esta función o solución]

La plantilla comienza con las palabras "creemos". Esto es explícito porque no lo
sabemos. Estamos haciendo suposiciones. Y luego completamos la plantilla de hipótesis
basándonos en el material que hemos creado en cada cuadro de lienzo antes de
este. Extraemos los resultados comerciales del Cuadro 2, las personas del Cuadro 3, los
beneficios del Cuadro 4 y las soluciones del Cuadro 5. De alguna manera, esta parte del
proceso es simplemente llenar los espacios en blanco.

Pero tenemos que hacer un poco más que eso. Nuestro objetivo aquí es escribir hipótesis
que tengan sentido y en las que creemos. Estas hipótesis son, en esencia, historias muy
breves diseñadas para generar apoyo para seguir una dirección de diseño
particular. Escribir una buena hipótesis que tenga sentido y que usted y su equipo crean
es en realidad la primera forma de probar la validez de las lluvias de ideas de su
solución. Si no puede armar una declaración de hipótesis convincente para una de las
ideas de solución en el Cuadro 5, entonces esa idea no debería pasar a la siguiente parte
del proceso. Y, para ser más claro, unLa hipótesis convincente es aquella en la que la
función tiene un usuario claro, el usuario obtiene un beneficio obvio de la función y el
cambio de comportamiento del usuario posterior ayuda a resolver el problema comercial
que articulamos en el Cuadro 1.

Facilitar el ejercicio
Nos gusta crear una tabla como la de la Figura 10-2. y luego complételo usando el
material que hemos llenado en las partes anteriores del lienzo. Movimos físicamente
nuestras notas Post-it a los cuadros correspondientes para formar filas de ideas
relacionadas. Cada columna está directamente relacionada con un recuadro específico del
lienzo, desde el recuadro 2 a la izquierda hasta el recuadro 5 a la derecha.

Figura 10-2. Una tabla de hipótesis

Durante este ejercicio, a menudo encontrará lagunas en sus lluvias de ideas iniciales. Es
posible que algunos resultados comerciales no tengan funciones creadas para ellos,
mientras que algunas funciones pueden no generar ningún valor para el cliente o la
empresa. Ese es parte del objetivo de este ejercicio: organizar y dar sentido a su ronda
inicial de pensamiento. Una vez que haya identificado las lagunas en sus lluvias de ideas,
rellénelas con nuevas notas adhesivas ( Figura 10-3 ) o, mejor aún, deje las ideas menos
relevantes fuera de la tabla. Esto ayudará a dar sentido a la indudable gran cantidad de
ideas que genera su equipo.

Con equipos distribuidos que utilizan una herramienta de pizarra virtual, este ejercicio se
vuelve aún más fácil. Copie y pegue sus notas de otras partes del lienzo en el Cuadro 6 y
muévalas según sea necesario para completar el cuadro.

Figura 10-3. Trabajando en el gráfico de hipótesis

Una vez que haya completado el gráfico (de 7 a 10 filas son un buen objetivo inicial),
comience a extraer hipótesis de características del mismo. Utilice la plantilla de hipótesis
para asegurarse de que incluye todos los componentes relevantes de la declaración de
hipótesis. Aquí está esa plantilla de nuevo:

Creemos que lograremos [este resultado comercial]

Si [estas personas]

Obtenga [este beneficio / resultado del usuario]

Con [esta función o solución]

Mientras escribe sus hipótesis, considere a qué persona (s) está sirviendo con sus
soluciones propuestas. No es raro encontrar soluciones que sirvan a más de una persona
a la vez. Tampoco es inusual crear una hipótesis en la que múltiples características
generen resultados similares. Cuando vea que eso sucede, refine la hipótesis para
enfocarse en una sola característica. Las hipótesis con múltiples características no son
fáciles de probar. Lo importante que debe recordar en todo este proceso es mantener sus
ideas lo suficientemente específicas para que pueda crear pruebas significativas para ver
si sus ideas son válidas.

¿CUÁL ES LA DIFERENCIA ENTRE HIPÓTESIS E HISTORIAS DE USUARIOS ÁGILES?

A menudo se nos pide que distingamos entre hipótesis declaraciones e historias de usuario
clásicas de Agile. La diferencia es sutil pero poderosa. Uno de los formatos más populares
para historias de usuarios ágiles tiene este aspecto:

Como <tipo de usuario>,

Quiero <alguna meta>

para que <alguna razón>.

Notará que el usuario y el resultado del usuario están presentes en esta historia. Dicho
esto, la mayoría de los equipos con los que hemos trabajado reemplazan "algún objetivo"
por "esta función". Una vez que se escribe la historia del usuario, la mayoría de los
equipos descartan las piezas en torno a "algún objetivo" y comienzan a implementar la
función. El usuario se olvida rápidamente mientras el equipo trabaja diligentemente para
acelerar su velocidad y ofrecer la función. El criterio de aceptación del equipo (es decir,
su definición de éxito) es que el sistema permite al usuario completar una tarea. No hay
discusión sobre si la solución es utilizable o deseable, y mucho menos placentera. No se
discute si la función genera un resultado. La única prueba que se realiza es si el sistema
"funciona según lo diseñado".

Las hipótesis tienen cambios de comportamiento (resultados comerciales) como su

definición de éxito. El envío de una característica de trabajo es una apuesta de mesa. Es
el comienzo de la conversación. El éxito de nuestro equipo no se mide por la rapidez con
la que pueden lanzar las funciones. En cambio, medimos el éxito en función de qué tan
bien nuestros clientes pueden lograr "algún objetivo" inicial y continuamente .

Esta es la diferencia clave entre historias de usuarios e hipótesis. Reenfocan al equipo en

lo que es realmente importante, hacer que el cliente tenga éxito y, por lo tanto, lograr un
objetivo comercial, en lugar de medir la productividad del equipo como éxito.

Dicho esto, todavía necesita una forma de hablar sobre los resultados y las funciones, las
cosas que está construyendo el equipo. Si sus historias de usuario están centradas en
funciones, está bien. De hecho, a menudo ocurre que una determinada hipótesis da como
resultado muchas historias de usuarios. Sin embargo, decide realizar un seguimiento del
trabajo, está bien. Solo asegúrese de que alguna parte de su proceso conecte el trabajo que
está haciendo en el nivel de funciones con los resultados comerciales y de usuario de nivel
superior que está tratando de crear.

Priorizar hipótesis
Lean UX es un ejercicio de priorización implacable. Es raro tener un presupuesto de
proyecto centrado estrictamente en el aprendizaje. En la mayoría de los casos, también
necesitamos enviar el producto. La razón por la que declaramos nuestras suposiciones al
comienzo de nuestro trabajo es para que podamos identificar los riesgos del proyecto y
establecer prioridades. ¿Qué es arriesgado y necesita pruebas? ¿Qué no es arriesgado y,
por tanto, fácil de empezar?

Después de encadenar nuestras suposiciones en hipótesis, creamos una acumulación de

trabajo potencial. A continuación, debemos averiguar cuáles son los más riesgosos, para
que podamos trabajar en ellos primero. Entendiendo que no puede probar todas las
suposiciones, ¿cómo decide cuál probar primero?

Hay muchas formas en las que puede establecer prioridades, pero hemos descubierto que
a menudo puede ser útil hacerlo de manera colaborativa y tener un marco para este
trabajo. Por eso creamos el lienzo de priorización de hipótesis que se muestra en la figura
10-4 . (Sí, otro lienzo.) El HPC es una matriz de dos por dos con el eje x mide el riesgo y
el eje y mide el valor percibido. Usamos el valor "percibido" porque es una gran
suposición. Creemos que una idea tiene un alto valor percibido si su implementación
tendrá un impacto significativo en la experiencia del usuario y, por lo tanto, en el
negocio. Cuando se trata de riesgo, evaluamos cada hipótesis por sus propios
méritos. Algunas hipótesis serán técnicamente arriesgadas. Algunos supondrán un riesgo
para la marca. Otros desafiarán nuestras capacidades de diseño. En este caso, no
normalizamos para un tipo específico de riesgo, por lo que podemos considerar todos los
aspectos del riesgo para cada hipótesis.

Figura 10-4. El lienzo de priorización de hipótesis

Mapee sus hipótesis en el lienzo en equipo.

 • Las hipótesis que aterrizan en el cuadrante 1 son las hipótesis que vamos a
probar. Se gradúan a las cajas 7 y 8 en el lienzo Lean UX.
• Si una hipótesis cae en el cuadrante 2 del HPC (alto valor, bajo riesgo), la
construiremos. Escriba las historias de los usuarios, colóquelas en la lista de
trabajos pendientes y envíelas. Pero no olvide medir esa característica una vez que
esté activa. Si no está a la altura de sus expectativas, es decir, los resultados
comerciales definidos en la hipótesis como éxito, debe revisar esta idea.
• Cualquier hipótesis que caiga por debajo del eje de riesgo en el área de bajo valor
percibido no se prueba. Si cae en el cuadrante 4 de la HPC (alto riesgo, bajo
valor), lo desechamos. Tampoco es necesario construirlo.
• Las hipótesis que terminan en el cuadrante 3 de la HPC (riesgo bajo, valor bajo)
no se prueban y, en la mayoría de los casos, no se construyen. Sin embargo, habrá
algunas hipótesis que terminan aquí que, si bien no son particularmente valiosas
o arriesgadas, aún deben construirse para que pueda operar su negocio. Por
ejemplo, tendrá que implementar un sistema de pago si está creando un servicio
de comercio electrónico, pero eso no lo diferenciará en el mercado. En este caso,
construimos los casos de uso básicos sabiendo que nuestras características
innovadoras y deliciosas, las características más riesgosas, serán probadas y
validadas antes de la implementación.

De qué estar atento

La redacción de hipótesis, como la mayoría de las técnicas nuevas, mejora con
práctica. Los equipos a menudo escriben hipótesis que son demasiado grandes para
probarlas al principio de su viaje Lean UX. Si se encuentra en esta situación, reconsidere
el alcance de su hipótesis. ¿Cómo puedes hacerlo más pequeño? ¿Cómo puede
dimensionar la hipótesis hasta un punto en el que su equipo pueda tener la propiedad total
sobre su alcance?

La redacción de hipótesis, como la redacción de declaraciones de problemas comerciales,

también se beneficia de la especificidad. Utilice números específicos en los resultados de
su negocio. Sea claro sobre la función que le gustaría crear. Esta es otra área en la que
frases como "mejor experiencia de usuario" y "interfaz de usuario intuitiva" no tienen
sentido. Si se le pide que pruebe esa "interfaz de usuario intuitiva" (y, para ser claros,
estará en el siguiente paso del lienzo), ¿qué probará? Considere reemplazar frases
ambiguas como esa por otras más específicas como "pago con un clic" o "autenticación
de reconocimiento facial".

1Archie Hobson (ed.), The Oxford Dictionary of Difficult Words (Nueva York: Oxford
University Press, 2004), sv "hypothesis".
Capítulo 11. Recuadro 7: ¿Qué es lo más
importante que debemos aprender
primero?

Figura 11-1. Recuadro 7 del lienzo Lean UX: aprendizaje

Una vez que haya priorizado sus hipótesis e identificado qué hipótesisque va a probar, el
siguiente paso en el proceso es resaltar los principales riesgos en cada hipótesis. Para
hacer esto, hacemos la primera de las dos preguntas clave de Lean UX: ¿Qué es lo más
importante que debemos aprender primero sobre esta hipótesis?

Cuando preguntamos sobre el aprendizaje, realmente estamos teniendo una conversación

sobre riesgo. Queremos descubrir todas las cosas que podrían romper nuestra hipótesis. Si
está haciendo esto con un equipo multifuncional, como le aconsejamos a lo largo del libro,
obtendrá al menos tantas respuestas a esta pregunta como disciplinas hay en la sala. Los
ingenieros de software discutirán las complejidades de desarrollar la función. Los
diseñadores plantearán problemas de flujo de trabajo y problemas de usabilidad. Los
gerentes de producto cuestionarán si brindará los beneficios comerciales que
anticipamos. Todos estos riesgos son válidos, pero en los que queremos centrarnos ahora
son los que invalidarán la hipótesis y nos permitirán avanzar rápidamente si nos
equivocamos.

En las primeras etapas del ciclo de vida de la hipótesis, el mayor riesgo suele estar
relacionado con el valor de la solución. ¿Necesita la gente una solución? ¿Lo
buscarán? ¿Lo intentarán? ¿Lo usarán? ¿Encontrarán valor en ello? Estas son las cosas
que importan desde el principio. Si la respuesta a estas preguntas es “no”, entonces no
hay necesidad de preocuparse por cómo lo vamos a diseñar o construir. Si estamos
lidiando con una hipótesis más madura, una en la que el valor ha sido validado y hemos
pasado a la implementación técnica, entonces pensar en cosas como desafíos técnicos,
usabilidad y escalabilidad se convierten en los próximos riesgos lógicos a explorar.

Facilitar el ejercicio
En términos generales, esta es una conversación. losEl equipo se sienta a revisar la
priorización de hipótesis y determina cuáles quiere probar primero. Luego haga la
pregunta ¿qué es lo más importante que debemos aprender primero sobre esta
hipótesis? Si la conversación se atasca, puede optar por hacer una lluvia de ideas aquí,
luego hacer un mapeo de afinidad y votar por puntos. O puede ceder ante algún miembro
del equipo que tenga una opinión firme. Generalmente, este paso no necesita mucho
proceso. El punto aquí es identificar los principales riesgos de uno a tres relacionados con
esta hipótesis, luego pasar a la planificación de su experimento, lo que hará en el Recuadro
8.

De qué estar atento

El consenso es bueno pero no siempre alcanzable. Si encuentras ese equipoSi la discusión
no llega a un consenso, es una clara indicación de que el equipo necesita más información
para tomar esa decisión. La única forma de hacerlo es tomar una decisión y pasar al
Recuadro 8 para crear un experimento. En la mayoría de los casos, el gerente de producto
puede realizar esta llamada. Cuando haga esto, recuerde que no abandonaremos estas
hipótesis, suposiciones y riesgos para siempre. Simplemente estamos avanzando con uno
y, si se demuestra que es falso, volveremos a la acumulación de hipótesis para hacer el
proceso nuevamente.
Capítulo 12. Recuadro 8: MVP y
experimentos

Figura 12-1. Recuadro 8 del Lean UX Canvas: MVP y experimentos

El paso final en Lean UX Canvas se centra en experimentación. La segunda pregunta

clave del lienzo que tenemos que responder es ¿Cuál es la menor cantidad de trabajo
que debemos hacer para aprender la siguiente cosa más importante? La respuesta a
esta pregunta es el experimento que va a realizar para probar su hipótesis.

Hacer la menor cantidad de trabajo no es flojo. Es magro.Recuerde, estamos tratando de

eliminar el desperdicio, y el trabajo adicional dedicado a probar su idea es un
desperdicio. De hecho, cuanto más rápido averigüe si su idea es algo en lo que debería
seguir trabajando, menos invertirá en ella. Esto hace que cambiar de rumbo sea mucho
más fácil, lo que aumenta la agilidad del equipo.

Los experimentos que se le ocurren en el Recuadro 8 son sus productos mínimos viables
o MVP. De hecho, esta es la definición exacta de MVP de The Lean Startup de Eric
Ries .

¿Qué es un MVP de todos modos?

Si le pregunta a una sala llena de profesionales de la tecnología, "¿Qué es un MVP?" es
probable que escuche una lista extensa y diversa que incluye gemas como las que siguen:

"Es lo más rápido que podemos salir por la puerta que todavía funciona".

"Es un lanzamiento feo que está lleno de compromisos y hace que todos se sientan
infelices".

"Es lo que el cliente dice que es".

"Es el conjunto mínimo de características que nos permite decir 'funciona'".

"Es la fase 1". (Y todos sabemos sobre la probabilidad de la fase 2).

La frase MVP ha causado mucha confusión en su corta vida. El problema es que se utiliza
al menos de dos formas diferentes. A veces, el término se usa para significar "un
lanzamiento pequeño y rápido". Ese es el significado al que se refieren las citas
anteriores. No es así como usamos la frase.

Cuando decimos MVP, estamos hablando de un pequeño y rápido forma de aprender

algo. A veces, esta es una versión de software. A veces, no lo es, puede ser un dibujo, una
página de destino o un prototipo. Su principal preocupación no es crear valor sino crear
aprendizaje. Ahora bien, estas dos ideas no son mutuamente excluyentes. Después de
todo, una de las cosas clave que está tratando de aprender es lo que el mercado considera
valioso. A menudo, un buen MVP creará valor y aprendizaje. Para nosotros, sin embargo,
el objetivo de un MVP es que se centra en el aprendizaje.

Ejemplo: ¿Deberíamos lanzar un boletín informativo?

Tomemos, por ejemplo, una empresa mediana que consultado hace unos años. Estaban
explorando nuevas tácticas de marketing y querían lanzar un boletín mensual. Crear un
boletín de noticias exitoso no es una tarea fácil. Necesita preparar una estrategia de
contenido, calendario editorial, maquetación y diseño, así como una estrategia continua
de marketing y distribución. Necesita escritores y editores para trabajar en ello. Con todo,
fue un gran gasto para la empresa. El equipo decidió tratar esta idea de boletín como una
hipótesis.

El equipo se preguntó: ¿Qué es lo más importante que debemos aprender primero? La

respuesta: ¿Hubo suficiente demanda por parte de los clientes de un boletín informativo
para justificar el esfuerzo? El MVP que la empresa utilizó para probar la idea fue un
formulario de registro en su sitio web actual. El formulario de registro promocionaba el
boletín y solicitaba la dirección de correo electrónico de un cliente. Este enfoque no
ofrecería ningún valor al cliente, todavía. En cambio, el objetivo era medir la demanda y
obtener información sobre la propuesta de valor y el idioma que impulsaban las
inscripciones. El equipo consideró que estas pruebas les darían suficiente información
para tomar una buena decisión sobre si continuar o no.

El equipo pasó medio día diseñando y codificando el formulario y pudo lanzarlo esa
misma tarde. El equipo sabía que su sitio recibía una cantidad significativa de tráfico cada
día: podrían aprender muy rápidamente si hubiera interés en el boletín.

En este punto, el equipo no hizo ningún esfuerzo por diseñar o crear el boletín informativo
real. Lo harían solo después de haber recopilado suficientes datos de su primer
experimento, y solo si los datos mostraban que sus clientes querían el boletín. Si los datos
fueran positivos, el equipo pasaría a su próximo MVP, uno que comenzaría a ofrecer valor
y crearía un aprendizaje más profundo en torno al tipo de contenido, formato de
presentación, frecuencia, distribución social y otras cosas que necesitarían aprender. para
crear un buen boletín. El equipo planeaba continuar experimentando con las versiones
MVP del boletín, cada una mejorando su predecesor, que proporcionarían más y
diferentes tipos de contenido y diseño y, en última instancia, brindarían el beneficio
comercial que estaban buscando .

Creando un MVP
Cuando se trata de crear un MVP, la primera pregunta es siempre, ¿qué es lo más
importante que debemos aprender a continuación? En la mayoría de los casos, la
respuesta será una cuestión de valor o una cuestión de implementación. En cualquier caso,
querrá diseñar un experimento que le brinde suficiente evidencia para responder su
pregunta y ayudarlo a decidir si continuar o no con la idea.

Creando un MVP para entender el valor

Aquí hay algunas pautas que debe seguir si está tratando de comprender el valor de su
idea:

Llegar al punto

Independientemente del método MVP que elija utilizar, concentre su tiempo en destilar
su idea a su propuesta de valor central y preséntela a sus clientes. Las cosas que rodean
su idea (cosas como navegación, inicios de sesión y flujos de recuperación de
contraseñas) serán irrelevantes si su idea en sí no tiene valor para su público
objetivo. Deja esas cosas para más tarde.

Utilice un llamado a la acción claro

Sabrá que las personas valoran su solución cuando demuestren la intención de usarla o
(¡ay!) Paguen por ella. Darle a las personas una forma de suscribirse o suscribirse a un
servicio es una excelente manera de saber si están interesados y si realmente le darían
dinero por ello.

Medir el comportamiento

Cree MVP con los que pueda observar y medir lo que la gente hace. Esto le permite
pasar por alto lo que la gente dice que hará en favor de lo que realmente hace. En el
diseño de productos digitales, el comportamiento triunfa sobre la opinión.

Habla con tus usuarios

Medir el comportamiento le dice lo que la gente hizo con su MVP. Sin saber por qué se
comportaron de esa manera, iterar su MVP es un acto de diseño aleatorio. Intente
capturar las conversaciones tanto de los que se convirtieron como de los que no lo
hicieron.

Priorizar sin piedad

Las ideas son baratas y abundantes. Deje que los mejores se prueben a sí mismos, así
que no se aferre a ideas invalidadas solo porque le gusten. Como diseñadores, sabemos
que este es particularmente difícil de practicar. Los diseñadores tienden a ser optimistas
y, a menudo, creemos que nuestras soluciones, ya sea que trabajemos en ellas durante
 cinco minutos o cinco meses, están bien diseñadas y bien pensadas. Recuerde, si los
resultados de su experimento no concuerdan con su hipótesis, está equivocado.

Mantente ágil

Los aprendizajes llegarán rápidamente; asegúrese de estar trabajando en un medio o

herramienta que le permita realizar actualizaciones fácilmente.

No reinventes la rueda

Muchas de las herramientas, sistemas y mecanismos que necesita para probar sus ideas
ya existen. Considere cómo podría usar el correo electrónico, SMS, aplicaciones de chat,
grupos de Facebook, escaparates de Shopify, herramientas sin código, foros de
discusión y otras herramientas existentes para obtener el aprendizaje que está
buscando.

Creación de un MVP para comprender la implementación

Aquí hay algunas pautas que debe seguir si está intentando Comprenda la implementación
que está considerando lanzar a sus clientes:

Ser funcional

Debe existir algún nivel de integración con el resto de su aplicación para crear un
escenario de uso realista. Aquí es importante crear su nuevo flujo de trabajo en el
contexto de la funcionalidad existente.

Integrar con análisis existentes

La medición del rendimiento de su MVP debe realizarse dentro del contexto de los flujos
de trabajo de productos existentes. Esto le ayudará a comprender los números que está
viendo.

Sea consistente con el resto de la aplicación

Para minimizar cualquier sesgo hacia la nueva funcionalidad, diseñe su MVP para que se
adapte a su apariencia, sensación y marca actuales.

Algunas pautas finales para la creación de MVP

Los MVP pueden parecer simples, pero en la práctica pueden resultar desafiante. Como
la mayoría de las habilidades, cuanto más practique, mejor se volverá en
hacerlo. Mientras tanto, aquí hay algunas pautas para crear valiosos MVP.

No es facil ser puro

Descubrirá que no siempre es posible probar solo una cosa a la vez: A menudo, intenta
saber si su idea tiene valor y determina los detalles de implementación al mismo
tiempo. Aunque es mejor separar estos procesos, tener en cuenta las pautas antes
mencionadas al planificar sus MVP lo ayudará a navegar por las compensaciones y
compromisos que tendrá que hacer.

Sea claro sobre sus objetivos de aprendizaje

 Asegúrese de saber lo que está tratando de aprender y asegúrese de tener claro qué
datos necesita recopilar para aprender. Es una mala sensación iniciar un experimento
solo para descubrir que no ha instrumentado correctamente y no está logrando capturar
algunos datos importantes.

Empieza pequeño

Independientemente del resultado deseado, cree el MVP más pequeño

posible. Recuerda que es una herramienta para aprender. Estarás iterando. Lo estarás
modificando. Es muy posible que lo esté tirando por completo. Será mucho más fácil
tirarlo si no dedicas mucho tiempo a construirlo.

No necesitas necesariamente un código

En muchos casos, su MVP no involucrará ningún código en absoluto. En su lugar,

dependerá de muchas de las herramientas existentes del diseñador de UX: bocetos,
creación de prototipos, redacción de textos publicitarios y diseño visual.

La curva de la verdad

La cantidad de esfuerzo que ponga en su MVP debe ser proporcional a la cantidad de

evidencia que tenga de que su idea es buena. Ese es el punto del gráfico ( Figura 12-2 )
creado por Giff Constable. 1 El eje x muestra el nivel de inversión que debe invertir en su
MVP. El eje y muestra la cantidad de evidencia basada en el mercado que tiene sobre su
idea. Cuanta más evidencia tenga, mayor será la fidelidad y complejidad de su
MVP. (Necesitará un esfuerzo adicional, porque lo que necesita aprender se vuelve más
complejo). Cuanta menos evidencia tenga, menos esfuerzo querrá poner en su
MVP. Recuerde la segunda pregunta clave: ¿Qué es lo más pequeño que puede hacer
para aprender la siguiente cosa más importante? Cualquier cosa más que eso es un
desperdicio.
Figura 12-2. Nuestra versión adaptada de la Curva de la verdad es un recordatorio útil de que el
aprendizaje es continuo y que una mayor inversión solo está justificada cuando los hechos lo
exigen.

Ejemplos de MVP
Echemos un vistazo a algunos tipos diferentes de MVP que son de uso común.

Prueba de página de destino

Este tipo de MVP ayuda a un equipo a determinar la demanda de su producto. Implica

crear una página de marketing con una propuesta de valor clara, una llamada a la acción
y una forma de medir la conversión. Los equipos deben generar tráfico relevante a esta
página de destino para obtener un tamaño de muestra lo suficientemente grande para que
los resultados sean útiles. Pueden hacerlo desviando el tráfico de los flujos de trabajo
existentes o utilizando publicidad en línea.

Los resultados positivos de las pruebas de la página de destino son claros, pero los
resultados negativos pueden ser difíciles de interpretar. Si nadie se "convierte", no
significa necesariamente que su idea no tenga valor. Podría simplemente significar que
no estás contando una historia convincente. La buena noticia es que las pruebas de la
página de destino son baratas y se pueden iterar muy rápidamente. Si tú lo
piensas,Kickstarter (y otros sitios de financiación colectiva) están llenos de MVP de
páginas de destino, como se muestra en la Figura 12-3 . Las personas que enumeran
productos en esos sitios buscan la validación (en forma de respaldo financiero) de que
deberían invertir en la construcción de sus ideas propuestas. Las pruebas de la página de
destino no tienen por qué ser páginas. Pueden ser anuncios u otros mensajes en línea que
tengan los componentes enumerados anteriormente.
Figura 12-3. Un ejemplo de una página de Kickstarter
Característica falsa (también conocida como el botón a ninguna parte)

A veces, el costo de implementar una función es muy alto. En estos casos, es más barato
y rápido crear la apariencia de la función donde realmente no existe. Los botones HTML,
las llamadas a la acción y otras indicaciones y enlaces proporcionan a su cliente la ilusión
de que existe una función. Al hacer clic o tocar el enlace, se notifica al usuario que la
función "estará disponible pronto" y que se le avisará cuando esto suceda. Las
falsificaciones de características son como mini páginas de destino en el sentido de que
existen para medir el interés. Deben usarse con moderación y eliminarse tan pronto como
se haya alcanzado un umbral de éxito. Si cree que podrían afectar negativamente su
relación con su cliente, puede corregirlo ofreciendo una tarjeta de regalo o algún otro tipo
de compensación a quienes encontraron su ratonera.

La figura 12-4 muestra una característica falsa que utilizó Flickr. En este caso, ofrecieron
un botón con la etiqueta "Usar como protector de pantalla" que aparentemente estaba
destinado a que el usuario especificara un álbum de fotos como protector de pantalla para
su dispositivo.

Figura 12-4. Un ejemplo de una función falsa encontrada en la aplicación Apple TV de Flickr

Sin embargo, cuando los usuarios hicieron clic en el botón, fueron recibidos por la
pantalla que se muestra en la Figura 12-5 . Flickr usó esto para recopilar evidencia de que
a un cliente le gustaría esta función. Al medir las tasas de clics, podrían evaluar la
demanda de esta función antes de crearla.
Figura 12-5. La pantalla que aparece después de hacer clic en el botón de función falsa

Figura 12-6. presenta otro ejemplo de función falsa. Aquí, MapMyRun ofreció la
oportunidad de tomar y cargar fotos mientras corría usando dos superposiciones
modales. No existía ninguna función hasta que obtuvieron una indicación de que a) la
gente quería esta función yb) cuánto estarían dispuestos a pagar por ella.
Figura 12-6. Otro ejemplo de una función falsa, esta en el sitio web de MapMyRun
mago de Oz

Una vez que haya demostrado la demanda de su idea, un MVP del Mago de Ozpuede
ayudarlo a descubrir la mecánica de su producto. Este tipo de MVP le parece al usuario
un servicio digital en pleno funcionamiento. Sin embargo, detrás de escena, los datos y la
comunicación con el grupo inicial de usuarios se manejan manualmente por humanos.Por
ejemplo, el equipo de Amazon detrás de Echo ejecutó un MVP de Wizard of Oz como
parte de sus pruebas iniciales para comprender los tipos de consultas que la gente haría y
la rapidez con la que esperarían una respuesta. En una habitación, un usuario hacía
preguntas a "Alexa", y en otra habitación, un ser humano escribía consultas en Google,
obtenía respuestas y respondía. Los usuarios de prueba no sabían que no estaban usando
software. El resto del equipo pudo observar a los usuarios y comprender cómo usarían
este nuevo producto, antes de que se invirtiera un esfuerzo de ingeniería significativo.

Ejemplo: MVP del Mago de Oz para Taproot Plus

En 2014, nuestra empresa trabajó con una organización llamada Fundación Taproot para
crear un mercado en línea para voluntarios pro bono. ( Pro bono es cuando un profesional
dona sus habilidades para ayudar a una causa digna. A diferencia de los servicios de
voluntariado no calificado en los que muchos de nosotros participamos el fin de semana,
el servicio pro bono implica el uso de sus talentos profesionales en un contexto de
voluntariado).

Nuestro cliente, Taproot Foundation, había estado ayudando a voluntarios pro bono y
organizaciones sin fines de lucro a encontrarse durante años, pero siempre habían
brindado este servicio de emparejamiento "a mano", a través de llamadas telefónicas,
correos electrónicos y reuniones en persona. Ahora querían poner ese proceso en línea:
querían crear un sitio web que actuara como un mercado de dos caras para los voluntarios
pro bono y las organizaciones que podrían beneficiarse de sus servicios.

Cuando comenzamos el proyecto, nos enfrentamos a una gran serie de preguntas: ¿cómo
debería funcionar el proceso de emparejamiento? ¿Deberían los voluntarios anunciar sus
servicios? ¿Deben las organizaciones publicitar sus proyectos? ¿Qué funcionaría
mejor? Y después de que las partes se encontraron en el sitio web, ¿cómo deberían
comenzar con el proyecto? ¿Cómo deberían las organizaciones comunicar sus
necesidades? ¿Cómo deberían los voluntarios enfocar el trabajo? Incluso los pequeños
detalles eran grandes preguntas: ¿cómo deberían las partes programar su primera llamada
telefónica?

Decidimos que era el momento perfecto para crear un MVP de Mago de Oz. Creamos un
sitio web simple, codificando a mano solo las pocas páginas estáticas que necesitábamos
para que pareciera que estábamos abiertos a los negocios. Comenzamos con una docena
de páginas en total: una página de índice y luego una página para cada uno de los 12
proyectos piloto que teníamos alineados. Detrás de escena, un administrador de la
comunidad reunió una lista de posibles voluntarios y les enviamos un correo electrónico,
enviándoles una llamada a la acción y un enlace a nuestro nuevo sitio. Para mantener la
ilusión de que teníamos un sistema en ejecución, nos aseguramos de que el correo
electrónico pareciera que provenía de nuestro nuevo sistema, no del administrador de la
comunidad.

Cuando los voluntarios hicieron clic en el enlace del correo electrónico, vieron nuestro
sitio del Mago de Oz ( Figura 12-7 ). Cuando utilizaron el sitio para solicitar una
oportunidad de voluntariado, les pareció que estaban interactuando con el sistema, pero
detrás de escena, simplemente envió un correo electrónico al administrador de la
comunidad y al equipo. Hicimos un seguimiento de todas nuestras interacciones en un
tablero de Trello simple ( Figura 12-8 ), que sirvió como nuestra "base de datos".

Figura 12-7. El sitio del Mago de Oz para la Fundación Taproot

Figura 12-8. Nuestra "base de datos" era simplemente un tablero de Trello

Operamos el sistema de esta manera durante unos meses, aprendiendo gradualmente de

nuestras interacciones, actualizando nuestros procesos comerciales y agregando
automatización y otras actualizaciones al sitio web a medida que aprendimos. Finalmente,
agregamos un backend funcional real, eliminando gran parte del aspecto de "hombre
detrás de la cortina" del sitio. También actualizamos el estilo visual, aplicando algo de
pulido maduro en el diseño gráfico ( Figura 12-9 ), después de haber aprendido lo
suficiente para entender cómo comunicar nuestra marca.
Figura 12-9. El sitio de Taproot Plus con un diseño gráfico más pulido

Al utilizar un enfoque del Mago de Oz, pudimos poner a prueba las partes de alto riesgo
del diseño (el diseño de los procesos comerciales), aprender sobre la marcha y eliminar
el riesgo de gastar mucho tiempo y dinero en diseñar y construir el Cosa incorrecta.

Creación de prototipos
Una de las formas más efectivas de crear MVP es mediante prototipos de la
experiencia. Un prototipo es una aproximación de una experiencia que te permite simular
cómo es usar el producto o servicio en cuestión. Debe poder utilizarse en una variedad de
dispositivos de destino. Al mismo tiempo, su objetivo debe ser invertir el menor esfuerzo
posible en la creación del prototipo. Esto hace que la elección de la técnica de creación
de prototipos sea importante.

La elección de la técnica que se utilizará para su prototipo depende de varios factores :

• ¿Quién interactuará con él?

• Lo que esperas aprender
• Lo que ya sabes que es verdad
• Cuanto tiempo tienes para crearlo

Es fundamental definir la audiencia prevista para su prototipo. Esto le permite crear el

prototipo más pequeño posible que generará comentarios significativos de esta
audiencia. Por ejemplo, si está utilizando el prototipo principalmente para mostrar ideas
a los ingenieros de software de su equipo, puede omitir en gran medida las áreas primarias
del producto que no se ven afectadas por la nueva experiencia, por ejemplo, la navegación
global. Sus desarrolladores saben que esos elementos están ahí y que no van a cambiar,
por lo que no necesita ilustrarlos.

Las partes interesadas, a menudo menos familiarizadas con su propio producto de lo que
jamás admitirán, probablemente necesitarán un mayor nivel de fidelidad en el prototipo
para comprender realmente el concepto. Para satisfacer las diversas necesidades de estas
audiencias dispares, su kit de herramientas de creación de prototipos debe ser bastante
amplio. Echemos un vistazo a las diferentes técnicas de creación de prototipos y
consideremos cuándo usar cada una.

Prototipos de papel

Hecho de lo más accesible componentes (papel, bolígrafos y cinta), los prototipos de

papel le brindan la capacidad de simular experiencias de una manera rápida, ingeniosa y
divertida. No es necesaria ninguna inversión digital. Usando tácticas como solapas para
mostrar y ocultar diferentes estados en una página o incluso crear una “ventana” para que
se mueva una presentación de diapositivas de imágenes, puede comenzar a darle al equipo
una idea de cómo debería funcionar el producto. Podrá tener una idea inmediata de lo que
está disponible en la experiencia y lo que falta. La creación de prototipos en papel puede
darle una idea de cómo el flujo de trabajo comienza a fusionarse en torno a los elementos
de la interfaz que ha ensamblado. Este método es especialmente útil con interfaces táctiles
que requieren que el usuario manipule elementos en una pantalla.

Pros

• Se puede crear en una hora.

• Fácilmente arreglado y reorganizado
• Barato y fácil de tirar si te equivocas
• Se puede ensamblar con materiales que ya se encuentran en la oficina.
• Actividad divertida que muchas personas disfrutan
Contras

• La iteración y la duplicación rápidas del prototipo pueden llevar mucho tiempo y

resultar tediosas.
• La simulación es muy artificial, porque no está utilizando los mecanismos de
entrada reales (mouse, trackpad, teclado, pantalla táctil, etc.).
• La retroalimentación se limita a la estructura de alto nivel, la arquitectura de la
información y el flujo del producto.
• Solo es útil con una audiencia limitada.

Mock-Ups en pantalla de baja fidelidad

Creación de una pantalla en la que se puede hacer clic de baja fidelidad La experiencia
(wireframes en los que se puede hacer clic, por ejemplo) le permite llevar un prototipo al
siguiente nivel de fidelidad. Su inversión en píxeles proporciona una sensación un poco
más realista al flujo de trabajo. Los participantes de la prueba y los miembros del equipo
utilizan mecanismos de entrada digital para interactuar con el prototipo. Esto le permite
obtener una mejor perspectiva y comentarios sobre la forma en que interactuarán con el
producto al nivel del clic, toque o gesto.

Pros

• Proporcione una buena idea de la duración del flujo de trabajo.

• Revelar los principales obstáculos para completar la tarea principal
• Permitir la evaluación de la posibilidad de encontrar elementos básicos
• Se puede utilizar para conectar rápidamente "algo en el que se puede hacer clic"
para que su equipo aprenda de sus activos existentes en lugar de forzar la creación
de otros nuevos.

Contras

• La mayoría de las personas que interactúan con estos activos son lo

suficientemente inteligentes como para reconocer un producto sin terminar.
• Se presta más atención de lo normal al etiquetado y la copia.

Prototipos en pantalla de alta y media fidelidad

Los prototipos de fidelidad media y alta tienen significativamente más detalle que los
prototipos basados en wireframe. Los usará para demostrar y probar diseños desarrollados
con un nivel de interacción, diseño visual y contenido similar (o indistinguible) de la
experiencia del producto final. El nivel de interactividad que puede crear en este nivel
varía de una herramienta a otra; sin embargo, la mayoría de las herramientas de esta
categoría le permitirán representar simulaciones de píxeles perfectos de la experiencia
final. Podrá crear elementos de interfaz como campos de formulario y menús
desplegables que funcionan, y botones de formulario que simulan acciones de
envío. Algunas herramientas permiten bifurcaciones lógicas y operaciones básicas de
datos. Muchos permiten algunos tipos de animaciones menores, transiciones y cambios
de estado.
Pros

• Produzca prototipos de alta calidad y realistas.

• Se pueden probar el diseño visual y los elementos de la marca
• Se pueden evaluar las interacciones del flujo de trabajo y la interfaz de usuario

Contras

• La interactividad es aún más limitada que los prototipos completamente nativos.

• Por lo general, los usuarios no pueden interactuar con datos reales, por lo que
existe un límite para los tipos de interacciones de productos que puede simular.
• Dependiendo de la herramienta, puede llevar mucho tiempo crear y mantener
estos prototipos. A menudo crea un esfuerzo duplicado para mantener un
prototipo de alta fidelidad y mantenerlo sincronizado con el producto real.

MVP sin código

Es posible producir un prototipo de su producto o servicio que es funcional y, sin

embargo, no tiene ningún parecido visual con el producto final que tiene en mente. Esto
se logra convirtiendo lo que se conoce como MVP sin código. Los MVP sin código se
basan en la amplia gama de herramientas como Airtable, Zapier y Webflow que no
requieren desarrollo de software, pero que aún le permiten conectar un servicio que ofrece
funcionalidad y, con suerte, algo de valor para los clientes y usuarios finales.

Pros

• Proporciona una forma rápida de probar la funcionalidad antes de escribir

software personalizado
• Le ayuda a concentrarse en las partes únicas y diferenciadoras de su servicio, sin
perder tiempo en la construcción de una gran cantidad de infraestructura.
• Requiere poca o ninguna habilidad de desarrollo de software

Contras

• Difícil de representar la marca, el diseño gráfico y otros puntos más finos de

la presentación.
• Difícil de mantener con el tiempo
• Barato para empezar, pero caro de escalar

Prototipos codificados y de datos en vivo

Los prototipos codificados ofrecen el más alto nivel de fidelidad para experiencias
simuladas. A todos los efectos, las personas que interactúan con este tipo de prototipo no
deberían poder distinguirlo del producto final a menos que se topen con los límites de su
alcance (es decir, hacen clic en un enlace a una página que no fue un prototipo). Los
prototipos codificados normalmente existen en el entorno nativo (el navegador, el sistema
operativo, en el dispositivo, etc.) y hacen uso de todos los elementos interactivos
esperados. Los botones, los menús desplegables y los campos de formulario funcionan
como lo esperaría el usuario. Reciben información del mouse, el teclado y la
pantalla. Crean un patrón de interacción lo más natural posible para los evaluadores del
prototipo.

En términos de creación de prototipos con datos, hay dos niveles de fidelidad aquí: datos
codificados (o estáticos) y datos en vivo. Los prototipos codificados se ven y funcionan
como el producto final, pero no manejan la entrada, el procesamiento o la salida de datos
reales. Siguen siendo solo simulaciones y, por lo general, ilustran algunos escenarios
predefinidos. Los prototipos de datos en vivo se conectarán con datos reales, procesarán
la entrada del usuario y mostrarán las salidas de datos adecuadas. Estos a menudo se
implementan en clientes reales y ofrecen un nivel de realismo a los clientes y una visión
del uso del prototipo por parte de los clientes que no están disponibles en los prototipos
codificados. También puede utilizarlos al realizar pruebas A / B (es decir, comparar dos
versiones de una función para ver cuál funciona mejor) determinadas funciones o cambios
en el flujo de trabajo actual.

Pros

• Potencial para reutilizar el código para la producción

• La simulación más realista para crear
• Se puede generar a partir de activos de código existentes.

Contras

• El equipo puede empantanarse al debatir los puntos más finos del prototipo .
• Se necesita mucho tiempo para crear un código de trabajo que ofrezca
la experiencia deseada .
• Es tentador perfeccionar el código antes de entregarlo a los clientes.
• Actualizar e iterar puede llevar mucho tiempo.

¿Qué debería incluir mi prototipo?

Ha elegido la herramienta para crear su MVP y está listo para empezar. No es necesario
crear un prototipo de toda la experiencia del producto. Concéntrese en los flujos de trabajo
centrales que le permiten probar los mayores riesgos en su hipótesis.

Centrarse en los flujos de trabajo principales cuando crea su MVP le da al equipo una
sensación de visión de túnel temporal (¡en el buen sentido!), Lo que les permite centrarse
en una parte específica de la experiencia y evaluar su validez y eficacia.

Demos y vistas previas

Es posible que haya desarrollado su MVP con un enfoque en solo un tipo de usuario o
solo un segmento de su base de clientes, pero puede aprender mucho compartiendo su
trabajo con sus colegas. Pruebe su MVP prototipo con sus compañeros de equipo, partes
interesadas y miembros de otros equipos. Llévalo a la zona del almuerzo y compártelo
con algunos compañeros que trabajan en diferentes proyectos. Asegúrese de que,
internamente, las personas brinden información al equipo sobre qué tan bien funciona,
cómo lo usarán y si vale la pena invertir más en él. Deje que las partes interesadas hagan
clic en él y le brinden sus puntos de vista y pensamientos.
Si su equipo tiene un día de demostración (y si no lo tiene, debería hacerlo),lleve el
prototipo allí para mostrar el progreso del proyecto. Cuanta más exposición reciba el
MVP, más información tendrá sobre su validez. A continuación, lleve su prototipo a
clientes y clientes potenciales. Permítales hacer clic en la experiencia y recopilar sus
comentarios.

Ejemplo: uso de un prototipo de MVP

Veamos cómo un equipo con el que trabajamos recientemente utilizó un prototipo de

MVP. En este estudio de caso, el equipo estaba considerando realizar un cambio
significativo en su oferta. Usamos un prototipo de MVP para apoyar el proceso de
investigación y toma de decisiones.

Esta puesta en marcha establecida estaba luchando con su producto actual: una
comunidad basada en suscripción exclusiva para la colaboración en grupo. Había estado
en el mercado durante algunos años y tuvo algo de tracción inicial, pero la adopción se
había estancado: los nuevos usuarios no se estaban registrando. Además, el producto se
enfrentaba a una competencia cada vez mayor. Al darse cuenta de que se necesitaba un
cambio radical, el equipo consideró renovar su modelo de negocio y abrir el producto a
un segmento de mercado significativamente más amplio. Su preocupación era doble:

1. ¿Los usuarios actuales aceptarían este cambio, dado que alteraría el carácter
exclusivo de la comunidad?
2. ¿El nuevo segmento de mercado estaría interesado en este tipo de producto?

Al equipo le preocupaba que pudieran recibir un doble golpe. Temían que los usuarios
existentes abandonaran el producto y que no hubiera suficientes usuarios nuevos para
compensar el déficit.

Trabajamos con el equipo para definir nuestro plan como hipótesis. Diseñamos el nuevo
segmento de mercado y definimos el conjunto básico de funcionalidades que queríamos
ofrecerles. Este fue un subconjunto de la visión definitiva, pero podría demostrarse en
cinco wireframes.

Pasamos una semana creando los wireframes para asegurarnos de que nuestros
desarrolladores, especialistas en marketing y ejecutivos estuvieran comprometidos con la
nueva dirección. Mostramos los wireframes a los clientes actuales, obteniendo dos rondas
de comentarios de los clientes en el transcurso de estos cinco días, y terminamos con un
prototipo en el que se puede hacer clic: nuestro MVP.

El momento de nuestro experimento fue fortuito: había una conferencia llena de clientes
potenciales programada para la semana siguiente en Texas. El equipo fue a la conferencia
y caminó por los pasillos del centro de convenciones con el prototipo en nuestros iPads.

Las maquetas funcionaron muy bien en los iPads: los clientes tocaron, deslizaron y
conversaron con nosotros sobre la nueva oferta. Tres días después, regresamos a la ciudad
de Nueva York con comentarios escritos en cada nota adhesiva y trozo de papel que
pudimos encontrar.
Clasificamos las notas en grupos y surgieron algunos temas claros. Los comentarios de
los clientes nos permitieron concluir que, si bien este nuevo plan de negocios tenía sus
méritos, necesitaríamos diferenciarnos más de los productos existentes en el mercado si
queremos tener éxito.

En total, pasamos ocho días hábiles desarrollando nuestras hipótesis, creando nuestro
MVP y obteniendo comentarios del mercado. Esto nos colocó en una excelente posición
para cambiar nuestra posición y refinar el producto para que se ajuste a nuestro segmento
de mercado de manera más efectiva.

1Giff Constable, “The Truth Curve”, 18 de junio de 2013, https://oreil.ly/vAXJ5 .

Capítulo 13. Reuniéndolo todo
En esta sección, hemos presentado todas las técnicas principales en Lean UX, desde
enmarcar su trabajo como una declaración de problema empresarial hasta definir el éxito
en términos de resultados tanto para la empresa como para el usuario. Le mostramos cómo
capturar la esencia de lo que sabe sobre sus usuarios como protopersonas. Hemos hablado
sobre cómo empezar a descubrir sus soluciones. Y hemos compartido formas de escribir
y probar sus hipótesis. Lean UX Canvas le brinda una forma concisa y de una sola página
de organizar su trabajo mientras aplica estas técnicas en el mundo real.

Dicho esto, el mundo real es un lugar desordenado, y cada proyecto en el que trabajes
será desordenado a su manera. (¡Esa es una de las razones para usar el lienzo en primer
lugar!) Para concluir esta sección, pensamos en compartir algunas historias de equipos
que usan Lean UX en este mundo real tan desordenado. Verá lo bien que funciona Lean
UX; de hecho, lo adecuado que es para abordar el desorden del mundo real.

En estas historias, verá que algunos de estos equipos usaron el lienzo. Otros simplemente
usaron algunas de las técnicas Lean UX que están incrustadas en el lienzo, sin usar el
lienzo en sí para organizar su trabajo. Como dijimos antes, esto está bien. Toma estas
herramientas y hazlas tuyas. Esperamos que estas historias le brinden algunas ideas e
inspiración sobre cómo hacer precisamente eso.

El lienzo Lean UX en la empresa

Recientemente escuchamos a un líder de producto y diseño en un gran empresa de
software empresarial en Silicon Valley. Esta empresa desarrolla una plataforma de
computación en la nube para ayudar a las empresas a gestionar los flujos de trabajo
digitales para las operaciones empresariales. Se pusieron en contacto porque querían
contarnos cómo habían estado usando el lienzo Lean UX para iniciar proyectos y nuevas
iniciativas. Pensamos que era una gran historia para compartir.

Un equipo de esta empresa estaba trabajando en el segundo lanzamiento de un producto

que había recibido buenos comentarios de los clientes. El producto tenía una forma
novedosa de mostrar datos: una pantalla que era realmente hermosa, que se probó bien y
que generó comentarios realmente positivos de los clientes. El producto utilizó un
elemento de interfaz de usuario inusual: un mapa personalizado que ayudó a los usuarios
a visualizar los procesos de trabajo y detectar oportunidades para mejorar los procesos.

Además de generar comentarios positivos de los clientes, esta interfaz de usuario se

mostró muy bien internamente. A las partes interesadas les encantó y apoyaron la idea de
mejorarlo. Así que parecía una elección natural aprovechar el éxito de esta función en la
próxima versión y, de hecho, eso es lo que el equipo planeaba hacer: realmente se
apoyarían en esta función para la segunda versión.

Aún así, recientemente se habían encontrado con Lean UX Canvas como una herramienta
y les gustó la forma en que estimuló el pensamiento metódico sobre el trabajo que
necesitaban hacer. Decidieron trabajar a través de un Lean UX Canvas para esta
iniciativa. Cuando lo hicieron, sucedió algo interesante. Cuando llegaron al Capítulo 8 ,
tuvieron un gran avance.

Para completar el Cuadro 4, el equipo tuvo que volver a los datos de retroalimentación
que ya habían recopilado de los clientes. Esto sucede a menudo cuando trabajas en un
Lean UX Canvas: tienes que encontrar la información que necesitas para completar una
sección. A veces, eso significa que debe realizar una investigación adicional y, a veces,
simplemente significa que debe revisar la investigación que ya ha realizado.

En este caso, cuando el equipo revisó sus datos, notaron un patrón importante en los
comentarios de los usuarios que habían pasado por alto: los clientes les decían que les
encantaba el mapa, pero que querían más del producto que simplemente la visualización
de datos. Querían que el producto fuera más proactivo. Básicamente decían: "La pantalla
es realmente hermosa, pero queremos que destaque dónde deberíamos prestar atención".

El proceso de completar un Lean UX Canvas obligó al equipo a detenerse y examinar

metódicamente los datos que habían recopilado. Un miembro del equipo me dijo: “De
hecho, tuvimos la retroalimentación. ¡Simplemente no lo estábamos escuchando!
" Continuó: "Cuando usamos el lienzo para revisar los datos sobre lo que era
materialmente importante para nuestros clientes, nos dimos cuenta de que simplemente
habíamos estado ignorando los datos".

Así que el equipo dedicó un tiempo a interpretar estos comentarios. Realmente

investigaron y resolvieron lo que pensaban que significaban los comentarios y lo que
significaban sobre los resultados que buscaban los clientes. Cuando volvieron a los
clientes para validar estas ideas, los clientes respondieron positivamente.

Después de eso, el equipo tomó una decisión fácil: necesitaban cambiar sus
prioridades. Un miembro del equipo nos dijo que la conversación en el equipo fue
clara. “Cuando se redujo la votación, no se trataba de 'mejorar el mapa'; fue 'hagamos lo
que nuestros clientes consideren realmente valioso' ”.

En el piloto del segundo lanzamiento, "obtuvimos calificaciones realmente altas de

nuestros clientes". Esas altas calificaciones ayudaron al equipo a lograr un lanzamiento
general aún más rápido. "Probablemente llegamos allí seis meses antes debido a estos
comentarios".

Validadamente: Validación de su
producto con entrevistas a clientes y un
prototipo de dos días
El emprendedor en serie Steven Cohn tuvo la idea de lanzar Validamente por los desafíos
que enfrentó como emprendedor al realizar su propia investigación de usuarios. Cuando
examinó el panorama, descubrió que otros investigadores de usuarios tenían desafíos
similares. Los investigadores de usuarios solían utilizar herramientas gratuitas como
Skype y Google Docs para realizar sus estudios. Sabía que estas herramientas no estaban
diseñadas para la investigación de usuarios y hacían que el proceso fuera
ineficaz. Algunos equipos complementaron estas herramientas con el proveedor de
servicios más conocido del sector, usertesting.com . Sabía que aquí había una
oportunidad.

Steven y su equipo utilizaron entrevistas con los clientes para descubrir las necesidades y
objetivos de este usuario (Cuadro 4 del Lean UX Canvas). En estas conversaciones,
descubrieron dónde deberían enfocarse cuando les preguntaron a los investigadores qué
hacen con los resultados que generaron sus estudios. “Ahí es donde está la mayor parte
de mi trabajo”, le dijeron. De hecho, se enteró de que la mayor parte del trabajo de los
investigadores comenzaba una vez terminada la investigación real.

El equipo de Validately se enteró de que, después de una ronda de entrevistas con los
clientes o pruebas de usabilidad, los investigadores tuvieron que volver a un documento
de notas de Google largo y desorganizado y conectar esas notas con las marcas de tiempo
en el video del estudio. Usarían estas marcas de tiempo (y algún tipo de herramienta de
edición de video) para crear clips de video, ensamblar estos clips en un carrete destacado
y finalmente compartir ese carrete con sus equipos, clientes y partes interesadas. Todo
esto solo para compartir lo aprendido durante el estudio.

El equipo realizó decenas de entrevistas para validar este problema. Aprendieron que este
trabajo, la creación de informes y videos destacados, con frecuencia representaba más del
50% del esfuerzo total dedicado a cada estudio. Sabía que había encontrado un problema
que valía la pena resolver.

El siguiente paso fue trabajar en la solución. (Recuadro 5 del Lean UX Canvas).Steven y

su equipo crearon un prototipo en InVision que planteó la hipótesis de cómo se vería una
herramienta optimizada que combinara la toma de notas, el seguimiento del tiempo y la
creación de informes y destaques. Pasaron dos días creando este prototipo antes de
mostrárselo a los clientes.

El prototipo respondió casi sin ayuda a la pregunta "¿Cómo eres mejor

que usertesting.com ?" Una vez que los clientes potenciales vieron el valor de la
herramienta optimizada que Validately deseaban construir, se interesaron de
inmediato. AEn este punto, Steven y su equipo pidieron un tipo más de
"retroalimentación". Le pidieron a la gente que se comprometiera en el acto, a comprar
un producto no en el futuro sino ahora mismo, aunque no estuviera listo para su
entrega. El contrato ofrecía una cláusula de cancelación si no se realizaba la entrega, pero
por lo demás, Steven utilizó el prototipo como herramienta de venta para un servicio que
aún no existía. El lanzamiento funcionó, lo que ayudó a validar con validez que su
solución era la correcta. Convirtieron a suficientes clientes para construir un negocio
próspero en las brechas entre herramientas gratuitas como Google Docs y
Skype. Validamente pasó a ser un gran éxito, y finalmente se vendió a UserZoom en
2019.

Los MVP que utilizaron aquí (conversación con el cliente seguida de un prototipo de dos
días) ayudaron a Steven y al equipo a reunir tres niveles de validación:

Tiempo
 ¿Nos dará la gente 30 minutos de su tiempo para discutir este problema? De lo
contrario, el problema que estamos resolviendo no es lo suficientemente
importante para ellos y probablemente no sea un espacio en el que queramos jugar.

Social

¿Las personas con las que hablamos se lo llevarán a su jefe, equipo, seguridad de
información, adquisiciones y otros en la organización? ¿Lo socializarán y lo
respaldarán internamente? Para entender esto, siempre preguntaban: "¿Me
presentará a otras personas de la organización que podrían estar interesadas en
esta herramienta?" Nuevamente, si esto resultó en ninguna presentación, también
fue una señal.

Dinero

Si el cliente potencial da su tiempo y su reputación, se le pedirá que compre. Esta

es la validación definitiva, ya que en realidad resultó en una venta.

Preparación para la prueba de Kaplan:

uso de Lean UX para lanzar un nuevo
negocio
Kaplan Test Prep ha estado ayudando a estudiantes en los EE. UU. prepararse para
pruebas estandarizadas como exámenes de ingreso a la universidad y la escuela de
medicina desde 1938. Ahora, con la educación transformándose casi anualmente, Kaplan
tiene que reinventar continuamente la forma en que ofrece valor a sus clientes. Lee Weiss,
actualmente vicepresidente senior de la empresa, ha ayudado a Kaplan a hacer
exactamente esto durante más de 20 años. Más recientemente, en el otoño de 2018, Lee
comenzó a pensar en una nueva idea para reinventar el negocio de asociaciones
universitarias de Kaplan. Quería hacer posible que las universidades crearan cursos en
línea para estudiantes de secundaria sobre temas de preparación universitaria y
profesional.

Su idea era crear una forma segura para que los estudiantes de secundaria aprendan sobre
varias carreras profesionales y prueben diferentes universidades al mismo tiempo. Lee y
sus colegas pasaron algunas semanas esbozando algunas ideas de cómo podría funcionar
esto y expresaron sus pensamientos en una plataforma de PowerPoint. Este mazo se
convirtió en su primer experimento, su MVP, para ayudarlos a probar su primera
hipótesis: que los líderes estarían interesados en sus planes.

A principios de 2019, se reunieron con el equipo de liderazgo para probar su idea. Los
líderes de Kaplan estaban entusiasmados con esta nueva idea y le dieron a Lee y a
sucolega Liz Laub la luz verde para centrarse únicamente en esta nueva idea. El equipo
de liderazgo de Kaplan les dijo a Lee y Liz: "Tómate los próximos 90 días y ve si puedes
hacer que este concepto despegue".
Lee y Liz comenzaron haciéndose la primera pregunta clave de Lean UX: ¿Qué es lo más
importante que debemos aprender primero? (Recuadro 7 en Lean UX Canvas).

Se dieron cuenta de que no tendrían un negocio en absoluto si No pude conseguir que

ninguna universidad se interesara. Con su mayor riesgo identificado, pudieron pasar a la
segunda pregunta clave de Lean UX: ¿Cuál es la menor cantidad de trabajo que
necesitamos hacer para aprenderlo? (Recuadro 8 en Lean UX Canvas).

Empezaron a hablar con universidades para ver si estarían interesado en asociarse con
ellos en esta iniciativa, aunque la iniciativa en sí aún no existía. En 90 días, el equipo
había hablado con 20 universidades diferentes y terminó con 2 de las universidades más
grandes de los EE. UU. Interesadas en la idea, todo a través de una conversación simple
y, a veces, fortuita. Esta fue una gran noticia, ya que les daría a Lee y Liz suficiente
información para hacer una solicitud más detallada al liderazgo. Una solicitud de
presupuesto para llevar un producto al mercado.

Sin embargo, antes de que pudieran hacer eso, había otras preguntas que debían
responder: como ¿qué querrían los estudiantes y los padres? ¿Cómo sería su
solución? (Estos son los tipos de preguntas que captura en el Cuadro 7 del lienzo).

Aquí es donde empezaron a aparecer los obstáculos: sus suposiciones sobre su oferta de
productos ( Capítulo 9 ) empezaron a aplastarse contra las rocas de la
realidad. Inicialmente, esperaban construir un producto que permitiera a los profesores y
estudiantes interactuar juntos en tiempo real. Desafortunadamente, las zonas horarias se
interpusieron en el camino,algo que aprendieron rápidamente a través de conversaciones
tempranas y continuas con los estudiantes. Así que pasaron a cursos asincrónicos y
rápidamente se enfrentaron a un nuevo desafío: cómo crear un curso atractivo y de gran
valor.

Asumieron que la mejor manera de hacer esto sería construir comunidades basadas en
cohortes. Probaron sus suposiciones comenzando a crear versiones anteriores de esta
oferta. Si bien esto recibió una fuerte retroalimentación positiva de los estudiantes que
participaron en las pruebas, todavía existía una demanda tanto de los padres como de los
estudiantes para recibir tutoría y apoyo en vivo. Abordaron esto contratando a ex alumnos
de estas universidades como mentores. Estas piezas fueron la base de un producto que
satisfizo necesidades tanto sincrónicas como asincrónicas.

Había una última pieza del rompecabezas que tenían que explorar en su período inicial
de 90 días, sin embargo: sus hipótesis sobre el tipo de organización que necesitarían para
construir y respaldar este negocio. No les haría ningún bien resolver esta necesidad en el
mercado con un producto atractivo si no pudieran crear un negocio viable y
sostenible. (Estas consideraciones sobre el diseño del servicio deben formar parte de la
definición de su solución en el Recuadro 5).

Aquí nuevamente, el equipo hizo una serie de suposiciones sobre a quién necesitarían
contratar, cómo deberían fijar el precio del producto, cuánto costaría ejecutarlo y, por
supuesto, qué forma debería adoptar el producto. Lee observa que casi todas estas
suposiciones eran incorrectas en retrospectiva, pero ahora tenían suficiente información
para volver al liderazgo con una solicitud más detallada: una solicitud de presupuesto ($
700,000 para ser exactos) para construir el producto y comercializarlo. La solicitud fue
aprobada, con una salvedad: tiene un año para cubrir los gastos.

El equipo empezó. Usando nada más que conversaciones con estudiantes, maestros y
administradores en sus dos clientes (ahora firmados), el equipo creó un plan de estudios
inicial de tres cursos. El objetivo era hacer cursos de la más alta calidad posible lo más
rápido posible.

Con el plan de estudios establecido, el equipo necesitaba sistemas operativos para

respaldar el trabajo: CRM, sistemas de gestión del aprendizaje, sistemas de gestión de
contenido, etc. Buscaron sistemas con el mandato de utilizar lo que los pusiera en marcha
más rápido. Unieron una experiencia liviana utilizando productos SaaS, todo fuera del
ecosistema tecnológico de Kaplan, lo que habría ralentizado su capacidad para ejecutar
pruebas rápidas. (Este es un gran uso de la técnica de MVP sin código).

El primer curso de dos semanas tuvo ocho estudiantes, todos los cuales obtuvieron el
curso gratis. Los ocho terminaron el curso y dieron una fuerte retroalimentación positiva
sobre la calidad del producto y la experiencia general. Ahora era el momento de adquirir
la primera cohorte pagada. Al principio no hubo mucho interés. Lee, Liz y el equipo
comenzaban a preocuparse. Su solicitud era larga, el costo era alto y la tarifa de solicitud
de $ 50 que habían visto en otros lugares y copiado en su producto parecía evitar que los
clientes potenciales enviaran sus solicitudes.

Los siguientes experimentos fueron claros para el equipo: eliminar la tarifa de solicitud,
acortar el proceso de solicitud y reducir el precio. Pudieron hacer esto por dos
razones. Primero, debido a que eran un equipo de innovación interno, tenían autoridad
para tomar decisiones para explorar los precios. Entonces redujeron sus precios a la
mitad. ¿La segunda razón por la que podrían experimentar así? Estaban trabajando en
sprints de una semana. Entonces, incluso si una decisión fue catastrófica, lo máximo que
tuvieron que vivir con ella fue una semana.

Sin embargo, el equipo no tuvo que esperar mucho. El día que hicieron los cambios,
recibieron más solicitudes que las dos semanas anteriores combinadas. Los ingresos por
ventas se quintuplicaron. A medida que el producto vio una tracción más fuerte, el equipo
comenzó a preocuparse por mantener la calidad del producto a medida que
escalaban. Definieron un conjunto de métricas basadas en resultados para guiar su toma
de decisiones y mantener la calidad alta: querían asegurarse de que todos los estudiantes
iniciaran sesión dentro de las 48 horas posteriores al inicio de cualquier curso, querían
ver una tasa de finalización del curso del 80%, y quería mantener un Net Promoter Score
(NPS) de 50.

Al utilizar los resultados como su estrella del norte, la toma de decisiones basada en la
evidencia como motor y los ciclos cortos para mantenerse en el buen camino, el equipo
ha logrado construir una unidad de negocio que ahora emplea a más de 30 personas.
Demostraron que seguir los datos y el instinto y Escalar lentamente las decisiones le
permite realizar las mejores correcciones de rumbo a lo largo del camino. Cuando
combina estos datos con un equipo autónomo y un mandato claro y basado en resultados,
los resultados hablan por sí mismos.
Parte III. Colaboración
Es martes, y Rick, Mark, Olga y Arti están parados en el pizarra, mirando una estructura
de alambre que han dibujado. Arti, la diseñadora, tiene un rotulador en la mano, pero no
dibuja. Rick, no entiendo a qué te refieres. ¿Puedes explicar el problema? " ella pregunta.

Rick toma el marcador, limpia una sección del tablero y vuelve a explicar el
reglamento. El equipo está diseñando una aplicación para operadores de bolsa, y la
aplicación debe obedecer un estricto conjunto de regulaciones. Rick, el analista de
negocios, es responsable de asegurarse de que los diseños del equipo respalden las reglas.

Al cabo de un rato, el equipo asiente y Arti vuelve a tomar el marcador. Ella sugiere un
cambio en el diseño de estructura metálica de la aplicación en el tablero, y el equipo
asiente nuevamente.Todos sacan sus iPhones, toman fotos del tablero y acuerdan volver
a reunirse al día siguiente. Confían en que lo que acordaron estará listo para que los
usuarios las prueben el jueves.

Arti vuelve a su escritorio para comenzar a detallar el diseño que han bosquejado. Mark,
el desarrollador de frontend, comienza a construir la página; usa componentes del Design
System que el equipo ha construido, por lo que no necesita esperar a Arti antes de poner
las piezas básicas en su lugar. Rick abre la página wiki del proyecto y comienza a
documentar las decisiones que ha tomado el equipo sobre el comportamiento de la
aplicación. Revisará estas opciones con el propietario del producto más adelante en el
día. Y Olga, la tester de control de calidad, comienza el proceso de escribir pruebas para
la nueva sección de la aplicación.

Este es el ritmo del día a día de Lean UX: un equipo que trabaja de manera colaborativa,
iterativa y en paralelo, con pocas transferencias, entregables mínimos y un enfoque en el
software de trabajo y la retroalimentación del mercado. En esta sección, verá cómo se
hace.

Acerca de la Parte III

En la parte anterior, analizamos las ideas detrás de Lean UX: los principios que impulsan
el trabajo. En esta sección, nos volvemos muy prácticos y describimos en detalle el
proceso de hacer Lean UX.

El proceso Lean UX

El Capítulo 14, Diseño colaborativo , trata sobre uno de los elementos principales de
Lean UX: la forma en que fomenta la colaboración interfuncional. Anima a los
diseñadores a trabajar con sus colegas que no son diseñadores para crear los mejores
productos posibles. Este capítulo hablará sobre algunas de las formas más importantes en
que lo hacemos.

El Capítulo 15, Retroalimentación e investigación , trata sobre cómo Lean UX aboga

por la investigación continua y la investigación colaborativa. Esto puede parecer un
cambio para muchos equipos, por lo que discutimos algunas de las cosas clave que
necesitará saber aquí.

El Capítulo 16, Integración de Lean UX y Agile , trata sobre cómo funcionan juntos los
métodos Lean UX y Agile. Agile es uno de los pilares fundamentales de Lean UX. Lean
UX nació de la necesidad de trabajar con equipos de desarrollo de software ágiles, una
lucha que muchos diseñadores enfrentan a diario. Este capítulo le ayudará a navegar.
Capítulo 14. Diseño colaborativo
Esté abierto a la colaboración. Otras personas y las ideas de otras personas suelen
ser mejores que las tuyas. Encuentra un grupo de personas que te desafíen e inspiren,
pasa mucho tiempo con ellos y cambiará tu vida.

Amy Poehler

¿Qué es una "experiencia de usuario"? Es la suma total de todos losinteracciones que un

usuario tiene con su producto y servicio. Se crea a partir de todas las decisiones que usted
y su equipo toman sobre su producto o servicio: la forma en que lo fija el precio, la forma
en que lo empaqueta y vende, la forma en que incorpora a los usuarios, la forma en que
lo respalda, lo mantiene y lo actualiza. , Y así sucesivamente y así sucesivamente.En otras
palabras, lo crea un equipo, no un diseñador individual. Por esta razón, Lean UX
comienza con la idea de que el diseño de la experiencia del usuario debe ser un proceso
colaborativo.

Lean UX reúne a diseñadores y no diseñadores en cocreación. Produce ideas que son más
grandes y mejores que sus contribuyentes individuales. Sin embargo, para ser claros, no
estamos abogando por el “diseño por comité”, una frase que implica un proceso lleno de
malos compromisos y toma de decisiones desinformada. En cambio, los procesos de Lean
UX son orquestados y facilitados por diseñadores y ejecutados por especialistas en
disciplina que trabajan desde un manual de juego común. Lean UX aumenta la propiedad
de su equipo sobre el trabajo al brindar una oportunidad para que los puntos de vista
individuales se compartan de manera temprana y continua a lo largo del proceso. En
última instancia, se trata de utilizar la experiencia diversa de su equipo para crear diseños
que funcionen .

En este capítulo, exploraremos los muchos beneficios que se derivan de esta estrecha
colaboración multifuncional.

Vamos a profundizar en...

Diseño colaborativo
En el Capítulo 10 , aprendió sobre hipótesis. Para probar sus hipótesis, a veces
simplemente realiza una investigación (descrita en el Capítulo 12 ).Pero otras veces,
necesitas diseñar y construir algo que te ayude a probar estas hipótesis. Por ejemplo, si se
encuentra en la etapa inicial de un proyecto, puede probar la demanda creando una página
de destino que mida cuántos clientes se registran en su servicio. O si se encuentra más
adelante en el ciclo de vida del producto, es posible que esté trabajando en el nivel de
funciones, por ejemplo, agregando algunas funciones nuevas que harán que los usuarios
sean más productivos. Navegar por las muchas opciones de diseño posibles para estas
funciones puede resultar difícil para los equipos. ¿Con qué frecuencia ha experimentado
conflictos de equipo sobre las opciones de diseño?

La forma más eficaz que hemos encontrado para reunir a un equipo en torno a una
dirección de diseño es a través de la colaboración. A largo plazo, la colaboración produce
mejores resultados que el diseño basado en héroes (la práctica de llamar a un diseñador o
equipo de diseño para que venga, proponga algo hermoso y despegue para rescatar el
próximo proyecto). Los equipos rara vez aprenden o mejoran trabajando con héroes. En
cambio, de la misma manera que la creación conjunta de hipótesis aumenta el coeficiente
intelectual del producto del equipo, el diseño conjunto aumenta el coeficiente intelectual
de diseño del equipo. Permite a todos los miembros del equipo articular sus ideas. Ofrece
a los diseñadores un conjunto de ideas mucho más amplio en el que basarse mientras
perfeccionan el diseño. Esto, a su vez, aumenta los sentimientos de propiedad de todo el
equipo en el trabajo.Finalmente, el diseño colaborativo genera un entendimiento
compartido en todo el equipo. Este entendimiento compartido es la moneda de cambio de
Lean UX. Cuanto más comprenda el equipo colectivamente, menos tendrá que
documentar para seguir adelante.

El diseño colaborativo es un enfoque que permite a un equipo diseñar juntos. Ayuda a los
equipos a desarrollar una comprensión compartida tanto del problema de diseño como de
la solución. Les proporciona los medios para trabajar juntos para decidir qué
funcionalidad y elementos de interfaz implementan mejor la característica que desean
crear.

El diseño colaborativo sigue siendo una actividad dirigida por diseñadores. Es elLa
responsabilidad del diseñador no solo es convocar reuniones de diseño colaborativo, sino
también facilitarlas. A veces, tendrás charlas informales y sesiones de dibujo. A veces,
sesiones individuales más estructuradas con un desarrollador en una pizarra. Otras veces,
reunirá a todo el equipo para un ejercicio de Estudio de diseño o incluso un Sprint de
diseño. La clave es colaborar con un grupo diverso de miembros del equipo.

En una sesión típica de diseño colaborativo, los equipos dibujan juntos, critican el trabajo
a medida que surge y, en última instancia, convergen en una solución que consideran que
tiene las mayores posibilidades de éxito. El diseñador, mientras sigue produciendo
diseños, asume el papel adicional de facilitador para dirigir al equipo a través de una serie
de ejercicios.

El resultado de estas sesiones generalmente consiste en baja fidelidad bocetos y

estructuras alámbricas. Este nivel de fidelidad es importante. Primero, hace posible que
todos contribuyan, incluso los miembros del equipo con habilidades de dibujo menos
sofisticadas. En segundo lugar, es fundamental para mantener la maleabilidad del
trabajo. Esto le da al equipo la capacidad de pivotar rápidamente si sus pruebas revelan
que el enfoque no está funcionando. Es mucho más fácil pasar de un enfoque fallido si no
ha dedicado demasiado tiempo a dibujar, documentar y detallar laboriosamente ese
enfoque.

Diseño colaborativo: el enfoque informal

Hace unos años, Jeff estaba diseñando un panel para una web aplicación dirigida a la
audiencia de reclutadores y empleadores de TheLadders. Había mucha información para
caber en una pantalla, y estaba luchando para que todo funcionara. En lugar de pasar
demasiado tiempo en su escritorio presionando píxeles, tomó una pizarra y le pidió a
Greg, el desarrollador principal, que se uniera a él. Jeff esbozó su idea original sobre
cómo diseñar todo el contenido y la funcionalidad de este tablero (consulte la Figura 14-
1). Luego, los dos discutieron la idea y, finalmente, Jeff le entregó el marcador a
Greg. Esbozó sus ideas en la misma pizarra. Fueron de un lado a otro, y finalmente
convergieron en un diseño y un flujo que sentían que era utilizable y factible, dado que
necesitaban ofrecer una solución dentro del sprint actual de dos semanas. Al final de esa
sesión de dos horas, regresaron a sus escritorios y comenzaron a trabajar. Jeff refinó el
boceto en una estructura alámbrica y un flujo de trabajo más formales, mientras que Greg
comenzó a escribir el código de infraestructura necesario para llevar los datos que
necesitaban a la capa de presentación.
Figura 14-1. Ejemplos de bocetos de pizarra

Habían construido un entendimiento compartido a través de su sesión de diseño

colaborativo. Ambos sabían lo que iban a construir y lo que necesitaba hacer la
función. No tuvieron que esperar para documentarlo. Esto les permitió construir la
primera versión de esta idea en un plazo de dos semanas.
CONVERSACIÓN: SU HERRAMIENTA MÁS PODEROSA

Lean UX promueve la conversación como medio principal de comunicación entre los

miembros del equipo. De esta manera, está muy en línea con el Manifiesto Ágil, que
promueve “individuos e interacciones sobre procesos y herramientas”. La conversación
une a un equipo en torno a una visión compartida. También aporta conocimientos de
diferentes disciplinas al proyecto mucho antes de lo que permitiría un ciclo de diseño
tradicional. A medida que se forman nuevas ideas o se realizan cambios en el diseño, la
percepción de un miembro del equipo puede desafiar rápidamente esos cambios de una
manera que el diseñador por sí solo no habría reconocido.

Al tener estas conversaciones temprano y con frecuencia, el equipo está al tanto de las
ideas de todos y puede comenzar con su propio trabajo antes. Si saben que la solución
propuesta requiere una determinada infraestructura de backend, por ejemplo, los
ingenieros del equipo pueden comenzar con ese trabajo mientras se refina y finaliza el
diseño. Las rutas paralelas para el desarrollo y el diseño de software son la ruta más rápida
para llegar a una experiencia real.

Estas conversaciones pueden parecer incómodas al principio; después de todo, estás

derribando muros probados por el tiempo entre disciplinas. Sin embargo, a medida que la
conversación evoluciona, los diseñadores brindan a los desarrolladores información sobre
la implementación de ciertas funciones, lo que garantiza la evolución adecuada de su
visión. Estas conversaciones promueven la transparencia del proceso y el progreso. Esta
transparencia crea un lenguaje común y vínculos más profundos entre los miembros del
equipo. Los compañeros de equipo que confían entre sí están más motivados para trabajar
juntos para producir un trabajo de mayor calidad.

Encuentre formas de tener más conversaciones con sus compañeros de equipo, tanto
relacionados con el trabajo como no. El tiempo dedicado a cultivar lazos sociales con su
equipo (comer juntos, por ejemplo) puede hacer que las conversaciones relacionadas con
el trabajo sean más fáciles, más honestas y más productivas .

Lean UX y Design Sprints

En el Capítulo 9 , escribimossobre un ejercicio llamado "Estudio de diseño". Esta es una

excelente manera de reunir un equipo para una sesión de diseño estructurada. En los
últimos años, se ha popularizado un enfoque similar llamado "Design Sprint". Descrito
en el libro Sprint de Jake Knapp, John Zeratsky y Braden Kowitz (Simon y Schuster), un
sprint de diseño es un proceso de cinco días que reúne a un equipo, define una pregunta,
desarrolla ideas, construye un prototipo y lo prueba: todo en una sola semana. Los Design
Sprints son como un estudio de diseño con esteroides. O como un mini ciclo de trabajo
Lean UX. Habiendo facilitado algunos de los nuestros, hemos visto lo poderoso que
puede ser este proceso. Si está buscando poner en marcha un equipo, un proyecto o una
iniciativa, un Design Sprint es una excelente manera de hacerlo. 1

Dicho esto, hay algunas partes quizás contradictorias de los métodos. Lean UX tiene una
forma particular de enmarcar problemas, por ejemplo. Los Sprints de diseño enmarcan
los problemas desde el primer día utilizando un método diferente. Lean UX recomienda
hipótesis, experimentos y MVP para probar sus ideas. Design Sprints lleva a los equipos
a través de la creación de prototipos y las pruebas durante los últimos días del sprint de
una manera que no utiliza hipótesis o la palabra MVP. Entonces, a veces parece que los
métodos están en conflicto.

Nuestra perspectiva es que los métodos son profundamente compatibles en espíritu, si no

en la práctica exacta. Si puede abrazar el espíritu de los métodos, Design Sprints encajará
muy bien en un enfoque Lean UX.

Dicho esto, queríamos aprender un poco más, así que nos comunicamos con Jake Knapp
para hablar sobre algunas de nuestras preguntas.

LEAN UX Y DESIGN SPRINTS: UNA CONVERSACIÓN CON JEFF, JOSH Y JAKE KNAPP

P: Mucha gente tiene preguntas sobre cómo funcionan juntos Lean UX y Design
Sprints. ¿Tiene POV sobre esta pregunta?

Jake Knapp: Para mí, Lean UX es como un libro de cocina que puede usar en todo el ciclo
de su producto y en toda su organización. Los Design Sprints son una receta única, algo
muy específico para un momento específico con una parte específica de su equipo. Las
filosofías son totalmente compatibles. Cualquiera que esté familiarizado con Lean UX
debería consultar Design Sprints y viceversa.

P: ¿Cuánta flexibilidad hay en la receta de Design Sprint? ¿Podemos ajustar la receta?

JK: Sí ... pero no ajuste la receta hasta que haya probado la original. Los pasos están ahí
por una razón, y funcionan, pero si ha ejecutado Design Sprints según el libro varias veces
y cree que necesita un ajuste, ¡inténtelo!

P: Es genial escucharlo, porque así es como recomendamos a la gente que piense sobre
Lean UX. Siempre es una cuestión de probar cosas, aprender y adaptarse en función de
lo que ha aprendido.

JK: Eso es correcto. Observa lo que pasa y toma notas. Trátelo como un experimento
dentro del experimento. Y si encuentra una mejora, hágamelo saber.

P: ¿En qué son realmente buenos los Design Sprints? ¿Para qué no son buenos?

JK: Design Sprints son genialespara equipos que quieren construir algo nuevo o cambiar
las cosas. Son ideales para iniciar grandes proyectos y mejorar su intuición sobre la
adecuación del producto / mercado. Son excelentes para generar impulso y alineación en
un equipo ... en otras palabras, un Design Sprint hace que todos remen en la misma
dirección con un propósito real. También son excelentes para restablecer la cultura del
equipo y fomentar el mejor tipo de toma de decisiones y riesgos. Pueden hacer que las
personas comprendan mejor a sus clientes y se concentren en ellos, y pueden acercar a
las personas a sus colegas. Pueden traer una renovada sensación de alegría en el trabajo,
porque finalmente puedes dejar de lado todas las tonterías y simplemente hacer lo que
más importa.

P: OK, ahora el otro lado de esa pregunta: ¿Para qué NO son excelentes?
JK: Design Sprints NO está destinado a diseñar cada detalle de su producto o planificando
todo su programa de desarrollo. No reemplazan a su MVP y no le ofrecen un camino
desde cero hasta el lanzamiento. Son realmente buenos en este momento específico; de
hecho, puedo decir con confianza que son la mejor manera que conozco de comenzar un
nuevo proyecto. Antes y después de ese momento ... así, consulte el resto del libro que
está celebración . :)

P: Parece haber mucha superposición entre los métodos. ¿Cuál deberíamos hacer?

JK: ¡Ambos!

Uso de Design Sprints en un proceso Lean UX

Entonces, como puede ver en nuestra conversación con Jake, todos cree que los métodos
funcionan bien juntos. Entonces, ¿cuál es la mejor manera de usar Lean UX para
configurar un Design Sprint exitoso? ¿Y cómo puede usar Lean UX después de haber
ejecutado un Design Sprint?

Esto es lo que recomendamos:

• Recuerde que Lean UX lo alienta a replantear su trabajo como un problema para

resolver en lugar de una "cosa para construir". No entre en un sprint pensando:
"¿Qué podemos construir?" En su lugar, use su sprint para averiguar "¿Cómo
podemos resolver nuestro problema?"
• Lean UX le anima a articular sus suposiciones sobre el problema, el público
objetivo, las posibles soluciones y cómo se ve el éxito. Esto le permite enmarcar
hipótesis, lo que puede ser una excelente manera de enmarcar un sprint de diseño.
• Utilice su (s) hipótesis (s) como entrada para su Design Sprint.
• Usa el trabajo que realizas en el sprint para comenzar a romper estas suposiciones,
probarlas y salir por el otro lado con un mejor conjunto de hipótesis y un conjunto
claro de próximos pasos.
• Este próximo conjunto de hipótesis se puede utilizar como entrada para su
próximo ciclo de trabajo Lean UX.

Sistemas de diseño
Como deja en claro la historia de Jeff y Greg en la pizarra, El diseño colaborativo es más
eficaz cuando se trabaja con lo que consideramos un bolígrafo grueso. Design Sprints es
otra técnica que adopta esta forma de trabajar de lápiz grueso. Están dibujando juntos,
tomando decisiones de alto nivel sobre concepto, estructura, flujo y funcionalidad. Este
es el nivel de resolución y detalle más apropiado para el diseño colaborativo. El diseño
colaborativo casi nunca significa que los equipos estén sentados juntos en una estación
de trabajo moviendo píxeles. De hecho, este tipo de grupo flotando en el nivel de píxeles
es lo que la mayoría de los diseñadores considerarían su peor pesadilla. (Para ser
claros: no hagas esto ) .

Y, sin embargo, el diseño no está terminado cuando el boceto está terminado. No está
completo en la pizarra. En cambio, por lo general es solo el comienzo. Entonces, ¿cómo
llevamos el diseño al nivel de píxeles? ¿Cómo llegamos al diseño visual terminado?
Cada vez más, vemos que los equipos recurren a sistemas de diseño. Los sistemas de
diseño son como guías de estilo sobre esteroides. Cuando escribimos la primera edición
de este libro, los sistemas de diseño eran algo nuevo. De hecho, como industria, todavía
no habíamos decidido realmente cómo llamarlos. En aquel entonces, estábamos
entusiasmados con los sistemas de diseño porque prometían desbloquear la colaboración
entre diseñadores y desarrolladores, y resolver una vez muchos de los problemas
repetitivos y rutinarios que enfrentaban los diseñadores, lo que significaba que los
diseñadores podían pasar a los desafíos más difíciles que agregaban más valor. .

Cuando escribimos la segunda edición de este libro, cuatro años después, los sistemas de
diseño se habían generalizado. Las grandes organizaciones con visión de futuro habían
construido o estaban construyendo sus sistemas a escala empresarial. Las empresas
emergentes las estaban implementando desde el primer día. Habían surgido
organizaciones consultoras que se especializaban en sistemas de diseño. Las conferencias
estaban uniendo a los practicantes. Tuvimos muchos más ejemplos que podríamos incluir
en la segunda edición del libro, y los dejamos en su lugar para su referencia.

Avance rápido hasta el día de hoy. Los sistemas de diseño son ahora una parte bien
establecida de la forma en que se realiza el diseño en nuestra industria. Continúan
cumpliendo la promesa de los primeros días, incluidos los beneficios que nos
entusiasmaron tanto cuando los encontramos por primera vez: continúan permitiendo que
los equipos de productos trabajen de manera colaborativa y altamente ágil. Antes de
adentrarnos en algunas de las formas en que los sistemas de diseño ayudan a los equipos
a ser más ágiles, echemos un vistazo a lo que son.

Sistemas de diseño: ¿Qué hay en un nombre?

Guías de estilo. Bibliotecas de patrones. Directrices de la marca. Bibliotecas de

activos.Sistemas de diseño. No hay mucho lenguaje común en esta parte del mundo del
diseño, así que tomemos un momento para aclarar nuestros términos.

Durante años, las grandes organizaciones crearon marcasdirectrices ( Figura 14-

2 ): documentos completos de diseño de marca y reglas de uso para esas empresas. En los
días previos a la digitalización, estas directrices eran documentos, a veces de unas pocas
páginas, pero con frecuencia grandes volúmenes encuadernados completos. A medida
que el mundo se movía en línea, estos libros a veces se trasladaban a la web como
documentos PDF, páginas web o incluso wikis.
Figura 14-2. Ejemplo de pautas de estándares de marca, este de NASA 2

Al mismo tiempo, los editores y las publicaciones a menudo mantenían guías de estilo
que cubrían las reglas de redacción y presentación del contenido. Los estudiantes
universitarios en los Estados Unidos están familiarizados con el rigor reconfortante
de The Chicago Manual de Estilo , El MLA Style Manual y la Guía de Publicaciones
Académicas y otros.

La versión del mundo de la informática de una guía de estilo está ejemplificada porLas
famosas pautas de interfaz humana (HIG) de Apple. El HIG es
un documento completo que explica todos los componentes del sistema operativo de
Apple, proporciona reglas para el uso de los componentes y contiene ejemplos que
demuestran el uso adecuado de los componentes.

Por último, los desarrolladores están familiarizados con las bibliotecas de activos .Estas
colecciones de elementos de código reutilizables están destinadas a facilitar el trabajo del
desarrollador al proporcionar código probado y reutilizable que es fácil de descargar
desde un repositorio de código siempre actualizado .

Como ocurre con muchas ideas en el mundo digital, los sistemas de diseño digital(que
llamaremos sistemas de diseño en aras de la brevedad) son una especie de combinación
de todas estas ideas. Un buen sistema de diseño contiene documentación completa de los
elementos de un diseño, reglas y ejemplos que gobiernan el uso de estos elementos y, de
manera crucial, el código y otros activos que realmente implementan el diseño .

En la práctica, un sistema de diseño funciona como una única fuente de verdad para la
capa de presentación de un producto. Los equipos pueden dibujar en la pizarra y luego
usar rápidamente los elementos que se encuentran en el sistema de diseño para ensamblar
un prototipo o una interfaz lista para producción.

El valor de los sistemas de diseño

Los sistemas de diseño son un poderoso habilitador de Lean UX. Permiten que los detalles
visuales y de microinteracción de un diseño se desarrollen y mantengan en paralelo con
las otras decisiones que toma un equipo. Por lo tanto, las decisiones como la estructura
de la pantalla, el flujo del proceso, la jerarquía de la información, las cosas que se pueden
resolver en la pizarra, pueden ser manejadas por el grupo correcto de compañeros de
equipo, mientras que las cosas como el color, el tipo y el espaciado pueden ser manejadas
por otro (muy probablemente superpuestos ) grupo de personas.

Esto tiene un par de grandes beneficios para los equipos:

Diseña más rápido

El equipo no está reinventando la rueda cada vez que diseñan una pantalla.

Prototipo más rápido

Los desarrolladores de frontend trabajan a partir de un conjunto de piezas: no

necesitan recrear los elementos de una solución cada vez; simplemente pueden
obtener las piezas adecuadas del sistema de diseño.

También tiene grandes beneficios para las organizaciones:

Mayor consistencia

Un buen sistema de diseño es fácil de usar para los desarrolladores. Por lo tanto,
es más probable que utilicen piezas que encuentran en el sistema de diseño y es
menos probable que "enrollen las suyas propias". Esto significa una mayor
probabilidad de que su trabajo se adhiera a los estándares de la marca.

Mayor calidad

Al centralizar el diseño y la creación de elementos orientados al usuario, puede

aprovechar el trabajo de algunos diseñadores y desarrolladores de UI altamente
capacitados y altamente especializados. Su trabajo de alta calidad puede ser
implementado por otros desarrolladores menos especializados en la organización
para producir resultados de primer nivel.

Costos mas bajos

Un buen sistema de diseño no es gratis. Requiere inversión para construirlo y

personal para mantenerlo. Pero con el tiempo, se amortiza al proporcionar
herramientas y marcos que hacen que los usuarios del sistema, los otros
desarrolladores de la organización, sean más eficientes y productivos. Permite a
los nuevos diseñadores ponerse al día más rápidamente, por ejemplo, porque
documenta todas las convenciones de frontend utilizadas en una aplicación. Del
 mismo modo, permite que los nuevos desarrolladores se pongan al día más
rápidamente, porque los bloques de construcción básicos de su trabajo están
disponibles en un marco fácil de usar.

Los equipos de sistemas de diseño son equipos de productos

No se equivoque: un equipo de sistemas de diseño es un equipo de producto.Aunque este

equipo está trabajando en un producto que será utilizado (en la mayoría de los casos) por
usuarios internos, este equipo es, no obstante, un equipo de producto. Tendrá muchas de
las mismas preocupaciones que tendrá cualquier equipo de producto: ante todo, necesita
hacer un producto que sus usuarios consideren valioso. Como con cualquier producto
interno, su medida de éxito no son las ventas; es adopción . Por lo tanto, comprender las
necesidades de sus usuarios y atenderlos será clave para una rápida adopción de su trabajo
y, en última instancia, clave para su éxito.

Los equipos de sistemas de diseño pueden abordar este desafío utilizando métodos Lean
UX. Algunos métodos, como ciertos tipos de experimentación, pueden ser difíciles o
imposibles para los equipos de sistemas de diseño: debido a que los sistemas de diseño
son productos de plataforma, los equipos los utilizarán en una variedad de contextos y
deben integrarse en una amplia gama de entornos. Por lo tanto, los problemas de
compatibilidad y estabilidad pueden limitar los tipos de experimentos que ejecuta.

Dicho esto, debido a que los usuarios de los sistemas de diseño son internos, debería ser
fácil acceder a ellos. Esto significa que los equipos de sistemas de diseño pueden apoyarse
en las técnicas de diseño colaborativo, utilizando talleres, sprints y sesiones de pizarra
compartida para generar colaboración y entendimiento compartido entre los
desarrolladores y usuarios de sistemas de diseño.

No te saltes los marcadores de grasa

Una preocupación sorprendente que hemos visto como sistemas de diseño. volverse más
omnipresente es que los sistemas de diseño pueden ser tan buenos y tan fáciles de usar
que los diseñadores pueden verse tentados a saltarse la etapa de diseño del “marcador
gordo” y pasar directamente al trabajo de alta fidelidad. Cuando esto sucede, las partes
interesadas, los colegas e incluso los propios diseñadores pueden malinterpretar los
artefactos que representan la fase inicial del pensamiento (la fase de desarrollo del
concepto del trabajo). Está en la naturaleza humana responder a las maquetas de alta
fidelidad de una manera diferente a como respondes a las maquetas de baja
fidelidad.Cuando muestra a las personas, especialmente a los que no son diseñadores, una
maqueta de alta fidelidad, tiende a recibir comentarios sobre los detalles. Las fuentes, los
colores y el contenido.Pero cuando le muestra a la gente un boceto en papel y lápiz,
no hay detalles para comentar. En cambio, la gente lee estos dibujos como dibujos
conceptuales y responden a eso.

Entonces, para los diseñadores, es importante no dejarse seducir por lo fácil que es
simplemente sacar Figma, tomar los componentes en su sistema de diseño y producir una
maqueta creíble. No lo hagas. Comience con sus marcadores de grasa.

Sin embargo, para los equipos de sistemas de diseño, existe la oportunidad de ayudar a
los usuarios a elegir la herramienta adecuada para el trabajo. Cuando escribimos la
primera edición de este libro, los diseñadores tenían una variedad de herramientas de
estructura de alambre digitales que estaban optimizadas para hacer dibujos con fidelidad
a los bocetos. Estamos empezando a ver que los equipos de sistemas de diseño están
considerando agregar elementos de fidelidad al boceto en sus kits de herramientas. Esta
es una tendencia fascinante y la seguiremos para ver dónde se desarrolla.

Ahora, echemos un vistazo a cómo una gran organización utiliza los sistemas de diseño
...

Estudio de caso: sistema de diseño de GE

En 2012, GE abrió GE Software en San Ramon, California. Este nuevo “Centro de

excelencia” (CoE) fue diseñado para ayudar a GE a mejorar su juego de software. Unos
años antes, una revisión estratégica ayudó a la compañía a ver cuán central se había
convertido el software en su negocio: medido en líneas de código, GE era algo así como
la 17ª compañía de software más grande del mundo. Y, sin embargo, sentían que no
estaban tratando el desarrollo de software con el enfoque que merecía.

San Ramon incluyó un nuevo equipo en GE: el equipo de experiencia del usuario de
software de GE. Este pequeño equipo en el corazón de una empresa gigante creó su
primer sistema de diseño en 2013 para escalar el impacto que podrían tener. De hecho,
con menos de 50 diseñadores para colaborar con más de 14,000 desarrolladores (dentro
de una organización de más de 300,000 personas), no había forma de que este equipo de
diseño de startups pudiera crecer lo suficientemente rápido como para tener un efecto
significativo en GE.

El primer sistema de diseño del equipo, llamado IIDS, para el Industrial Internet Design
System, fue diseñado por un grupo de diseñadores internos con la ayuda de un pequeño
equipo de Frog Design, una de las firmas de diseño líderes en el mundo. El equipo
construyó el sistema sobre Bootstrap, el marco HTML / CSS creado por Twitter. Resultó
increíblemente exitoso. En unos pocos años, los desarrolladores internos lo habían
descargado más de 11.000 veces y se había utilizado para crear cientos de
aplicaciones. Ayudó a los equipos de software de toda la empresa a producir aplicaciones
más consistentes y de mejor apariencia. Y, quizás igualmente importante, creó una gran
cantidad de visibilidad para el equipo de software y el equipo de UX en San Ramon.

Con ese éxito surgieron algunos problemas. Sin duda, el simple hecho de tener un buen
kit de interfaz de usuario no significa que un equipo pueda producir un producto bien
diseñado. Los sistemas de diseño no resuelven todos los problemas de diseño. Y
Bootstrap estaba mostrando sus límites como una opción de plataforma. Había ayudado
al equipo a lograr sus primeros objetivos: sacar algo rápidamente, proporcionar una
amplia cobertura de los elementos de la interfaz de usuario y crear una amplia adopción
al ser más fáciles de usar que las soluciones "roll-your-own". Pero Bootstrap era difícil
de mantener y actualizar y era demasiado grande para la mayoría de las necesidades.

En 2015, GE Software, tras haber tenido un gran éxito como oficina de servicios
internos, se transformó en GE Digital, una empresa generadora de ingresos por derecho
propio. Su primer producto se llamó Predix ( Figura 14-3 ), una plataforma sobre la cual
los desarrolladores dentro y fuera de GE pueden crear software para aplicaciones
industriales. Y con este cambio de estrategia, el equipo se dio cuenta de que necesitaban
repensar su sistema de diseño. Mientras que anteriormente el objetivo había sido
proporcionar una amplia cobertura y una amplia adopción, el nuevo sistema de diseño
estaría impulsado por nuevas necesidades:necesitaba habilitar grandes aplicaciones de
Predix, que era un problema más enfocado que antes. Necesitaba limitar la cantidad de
opciones de IU en lugar de admitir todos los widgets de IU posibles. Todavía tenía que
ser fácil de adoptar y utilizar (ahora estaba destinado a ser utilizado por los clientes de
GE), pero ahora era imperativo que también fuera fácil de mantener.

El equipo del sistema de diseño había crecido a unas 15 personas e incluía tecnólogos de
diseño (desarrolladores frontend apasionados tanto por el diseño como por el código),
diseñadores de interacción, diseñadores gráficos, un escritor técnico y un propietario de
producto.
Figura 14-3. El sistema de diseño GE Predix

El equipo decidió trasladar el sistema de diseño a una nueva plataforma tecnológica

( Figura 14-4 ).Ya no se basa en Bootstrap, el sistema se ha creado con Polymer, un marco
de JavaScript que permite al equipo implementar componentes web. Los componentes
web han surgido en los últimos años como una forma de permitir prácticas de desarrollo
de frontend más maduras.

Para crear el nuevo sistema de diseño, el equipo pasó casi seis

mesesprototipos. Significativamente, el equipo no trabajó de forma aislada. En cambio,
se emparejaron con uno de los equipos de aplicaciones y, por lo tanto, diseñaron
componentes para satisfacer las necesidades de sus usuarios, en este caso, los diseñadores
y desarrolladores que trabajaban en los equipos de aplicaciones. Este punto es realmente
importante. El diseño colaborativo adopta muchas formas. A veces significa diseñar con
su equipo multifuncional. A veces significa diseñar con sus usuarios finales. En este caso,
fue un híbrido: diseñar con un equipo multifuncional de diseñadores y
desarrolladores que en realidad son sus usuarios.

Figura 14-4. El sistema de diseño GE Predix en GitHub

Colaboración con equipos distribuidos

geográficamente
La distancia física es uno de los mayores desafíos para los fuertes colaboración. Algunos
de los métodos que hemos discutido en este libro se vuelven más difíciles cuando un
equipo no está en el mismo lugar. Dicho esto, como todos aprendimos en 2020, gracias a
la crisis de COVID-19, aún puede encontrar formas de colaborar cuando usted y su equipo
están separados por la distancia. Herramientas como Zoom, Skype, Google Meet y Slack
pueden proporcionar a los equipos los medios para colaborar en tiempo real. Google Docs
y sistemas similares permiten a las personas colaborar en documentos al mismo
tiempo. Las herramientas de colaboración en equipo como Mural y Miro sirven como un
espacio para la colaboración creativa. Trello y los wikis hacen posible que los equipos
rastreen la información juntos. Las herramientas de diseño como Figma se crean desde
cero con la colaboración en mente. Y un teléfono con cámara puede facilitar el
intercambio rápido de fotos de forma ad hoc.

Colaborar con equipos distribuidos

Cuando hablamos de equipos distribuidos, en realidad estamos hablando sobre una

variedad de escenarios diferentes. A veces nos referimos a que estamos en una oficina en
Nueva York con parte de nuestro equipo y necesitamos trabajar con otros compañeros de
equipo que están trabajando en la oficina de Londres. Otras veces significa que estamos
encerrados al estilo 2020, trabajando desde casa con nuestras mascotas, nuestros hijos y
nuestras parejas en la misma habitación. A veces estamos hablando de una situación
híbrida: la mayoría de nosotros estamos en la oficina, pero algunas personas están
llamando para una reunión. Lo que funciona en uno de estos contextos puede no funcionar
en otros, pero hay algunas ideas importantes que puede utilizar para facilitar la
colaboración en cualquier contexto.

Nivelar el campo de juego. ¿Alguna vez ha llamado a una reunión en la que era la única
persona al teléfono y todos los demás estaban sentados alrededor de la mesa? Es
duro. Ahora imagina una habitación llena de gente trabajando en notas adhesivas o
dibujando en la pizarra, mientras estás sentado en tu cocina escuchando el teléfono. Será
difícil, quizás imposible, para usted hacer una contribución significativa. Una solución
para esto es insistir en que se elijan las herramientas de la sala de reuniones para que todos
puedan participar. En lugar de utilizar la pizarra de la sala de conferencias, su equipo
puede abrir un documento compartido o utilizar una herramienta de pizarra en línea como
Mural o Miro. Esto significa que todos en la sala de conferencias necesitarán su propia
computadora portátil o tableta, pero también garantizará que todos puedan colaborar
como compañeros.

Crea conexiones sociales. Puede ser tentador para tratar las reuniones en línea de una
manera muy reglamentada. Reúna al equipo, apunte la agenda con fuerza, termine a
tiempo, boom. Las reuniones remotas comienzan y terminan de manera más abrupta que
las reuniones físicas. Piénselo: cuando nos reunimos en una sala de conferencias,
charlamos unos minutos en el pasillo antes de la reunión. Chismorreamos mientras
tomamos nuestras sillas. Salimos de la habitación juntos y tomamos un café juntos para
hablar. Estos momentos pueden parecer secundarios al trabajo que hacemos, pero en
realidad son un componente crucial del trabajo: nos dan tiempo para construir los lazos
sociales que permiten que suceda el trabajo. Haga el esfuerzo de crear conexiones sociales
a través de colaboraciones remotas. Consiga tiempo adicional para las aperturas lentas de
sus reuniones. Programe llamadas sociales del equipo a distancia. Crea canales sociales /
no laborales en los espacios de trabajo de Slack de tu equipo. Si puede viajar para ver a
sus compañeros de equipo remotos,

Hacer que la colaboración funcione

No todos los equipos encontrarán que la colaboración es fácil. La mayoría de nosotros

comenzamos nuestras carreras desarrollando nuestras habilidades técnicas individuales
como diseñadores, desarrolladores, etc. Y en muchas organizaciones, la colaboración
entre disciplinas es rara. (Rara vez se enseña también en la escuela, ya sea como un tema
explícito o en la forma en que están configurados nuestros sistemas educativos). Por lo
tanto, no es de extrañar que pueda parecer un desafío.

Una de las herramientas más poderosas para mejorar la colaboración es la Técnica ágil
de la retrospectiva y la práctica relacionada de crear acuerdos de trabajo en
equipo . Las retrospectivas son reuniones programadas regularmente, que generalmente
se llevan a cabo al final de cada sprint, en las que el equipo echa una mirada honesta al
sprint anterior. Examinan lo que salió bien, lo que salió mal y lo que el equipo quiere
mejorar. Por lo general, el equipo seleccionará algunas cosas en las que trabajar para el
próximo sprint. No podemos pensar en una herramienta más poderosa para mejorar la
colaboración que la práctica regular de retrospectivas efectivas.

Un acuerdo de trabajo en equipo es un documento que sirve como socio de la

retrospectiva. Realiza un seguimiento de cómo el equipo ha elegido trabajar en
conjunto. Es un libro de reglas de creación propia y continuamente actualizado que el
equipo se compromete a seguir. En cada retrospectiva, el equipo debe verificar su acuerdo
de trabajo para ver si todavía lo están siguiendo y si necesitan actualizarlo para incluir
nuevos acuerdos o eliminar los antiguos que ya no tienen sentido.

Aquí hay un resumen de lo que debería considerar cubrir en los acuerdos de trabajo de su
equipo:

Vista general del proceso

¿Qué tipo de proceso estamos usando? ¿Ágil? Si es así, ¿qué sabor? ¿Cuánto duran
nuestras iteraciones?

Ceremonias

¿Qué rituales observará el equipo? Por ejemplo, ¿cuándo se hace stand-up todos los
días? ¿Cuándo realizamos reuniones de planificación y demostraciones?

Herramientas de comunicación

¿Qué sistemas usaremos para comunicar y documentar nuestro trabajo? ¿Cuál es

nuestra herramienta de gestión de proyectos? ¿Dónde guardamos nuestros activos?

Cultura / Seguridad / Resolución de conflictos

¿Qué tipo de cultura de equipo queremos? ¿Qué necesitamos como individuos para
sentirnos seguros con nuestros compañeros de equipo? ¿Qué haremos cuando (¡no si!)
Haya un conflicto? ¿Cómo resolveremos los desacuerdos?

Horas Laborales
 ¿Quién trabaja donde? ¿Cuándo está la gente en la oficina? Si estamos en diferentes
lugares, ¿qué adaptaciones haremos para las diferencias de zona horaria?

Requisitos y diseño

¿Cómo manejamos la definición de requisitos, la redacción de historias y la

priorización? ¿Cuándo está lista una historia para diseñar? ¿Cuándo está listo un diseño
para dividirse en historias?

Desarrollo

¿En qué prácticas nos hemos conformado? ¿Usamos programación por pares? ¿Qué
estilo de prueba usaremos? ¿Qué métodos usaremos para el control de fuentes?

Límites de trabajo en curso

¿Cuál es nuestra cartera de pedidos y el tamaño de nuestra nevera? ¿Qué límites de WIP
existen en varias etapas de nuestro proceso?

Despliegue

¿Cuál es nuestra cadencia de liberación? ¿Cómo hacemos la aceptación de la historia?

Y cualquier acuerdo adicional.

SEGURIDAD PSICOLÓGICA

El diseño colaborativo es una actividad creativa. Ser efectivo,la gente necesita sentirse
segura. Esto significa seguridad física, emocional y psicológica. A menudo escuchamos
esta idea expresada de manera superficial, como "no hay malas ideas en la lluvia de ideas"
o "no existen las preguntas estúpidas". Y aunque esas cosas son ciertas, ciertamente no
son suficientes. La seguridad psicológica es más que eso.La autora Alla Weinberg define
la seguridad psicológica como "la creencia compartida de que nadie en el equipo
avergonzará o castigará a nadie más por admitir un error, hacer una pregunta o ofrecer
una nueva idea".

Lean UX tiene que ver con la idea de que el diseño es iterativo proceso. Necesitas probar,
aprender e iterar. En otras palabras, es necesario cometer errores para progresar. No
puede hacer esto si usted y su equipo no se sienten seguros.

Si usted o su equipo se encuentran estancados en una rutina, experimentan altos grados

de conflicto o, en general, actúan asustados, dé un paso atrás y pregunte: ¿Me siento
seguro en este equipo? ¿Creo que los miembros de mi equipo se sienten seguros? Si no
está seguro, considere dar un paso atrás y observar el trabajo de escritores como Weinberg
y Amy Edmondson para ayudarlo a usted y a su equipo a abordar estas inquietudes.

Terminando

El diseño colaborativo ( Figura 14-5 ) es una evolución del proceso de diseño de UX. En
este capítulo, discutimos cómo la apertura del proceso de diseño hace que todo el equipo
se adentre más en el proyecto. Le mostramos técnicas prácticas que puede utilizar para
crear un entendimiento compartido, la moneda fundamental de Lean UX. Usando
herramientas como sistemas de diseño, guías de estilo, sesiones de diseño colaborativo,
Design Studio y una conversación simple, su equipo puede construir un entendimiento
compartido que les permita avanzar a un ritmo mucho más rápido que en los entornos
tradicionales.

Figura 14-5. Un equipo que utiliza técnicas de diseño colaborativo

1La palabra "sprint" puede resultar confusa aquí. En este contexto, no estamos hablando
de un sprint de estilo ágil, lo que Scrum llamaría una "iteración". Cuando usamos la frase
"Design Sprint", usaremos letras mayúsculas para indicar que estamos hablando del
proceso específico descrito en el libro Sprint .

2NASA, “Manual de estándares gráficos de la NASA”, 8 de septiembre de

2015, https://oreil.ly/nCc4H .
Capítulo 15. Retroalimentación e
investigación
La investigación es curiosidad formalizada. Es hurgar y entrometer con un propósito.

Zora Neale Hurston

La investigación con los usuarios está en el corazón del diseño de UX. Demasiado a
menudosin embargo, los equipos subcontratan el trabajo de investigación a equipos de
investigación especializados. Y con demasiada frecuencia, las actividades de
investigación se llevan a cabo en raras ocasiones, ya sea al principio o al final de un
proyecto. Lean UX resuelve estos problemas haciendo que la investigación sea
tanto continua como colaborativa . Profundicemos para ver cómo hacer eso.

En este capítulo, cubrimos lo siguiente:

• Técnicas de investigación colaborativa que puede utilizar para generar un

entendimiento compartido con su equipo.
• Técnicas de investigación continua para construir estudios de investigación
cualitativos pequeños e informales en cada iteración.
• Cómo utilizar pequeñas unidades de investigación regular para construir estudios
de investigación longitudinales
• Cómo reconciliar comentarios contradictorios de múltiples fuentes
• Qué artefactos probar y qué resultados puede esperar de cada una de estas pruebas
• Cómo incorporar la voz del cliente a lo largo del ciclo Lean UX

Investigación continua y colaborativa

Lean UX toma técnicas básicas de investigación de UX y superpone dos ideas
importantes. Primero, la investigación de Lean UX es continua. Esto significa que integra
actividades de investigación en cada sprint. En lugar de ser un proceso costoso y
perturbador del "big bang", lo hacemos en pequeñas cantidades para que podamos
adaptarlo a nuestro proceso en curso.En segundo lugar, la investigación Lean UX es
colaborativa. Esto significa que no depende del trabajo de investigadores especializados
para brindar aprendizaje a su equipo. En cambio, las actividades y responsabilidades de
investigación se distribuyen y comparten entre todo el equipo. Al eliminar la transferencia
entre investigadores y miembros del equipo, aumentamos la calidad de nuestro
aprendizaje.Nuestro objetivo en todo esto es crear un rico entendimiento compartido
en todo el equipo.

Descubrimiento colaborativo

El descubrimiento colaborativo es el proceso de trabajar juntos como un equipo para

probar ideas en el mercado. Es una de las dos principales técnicas multifuncionales que
crean un entendimiento compartido en un equipo Lean UX. (El diseño colaborativo,
cubierto en el Capítulo 14 , es el otro).El descubrimiento colaborativo es un enfoque de
investigación que saca a todo el equipo del edificio, literal y figurativamente, para
reunirse y aprender de los clientes y usuarios. Brinda a todos los miembros del equipo la
oportunidad de ver cómo se prueban las hipótesis y, lo que es más importante, multiplica
la cantidad de perspectivas que el equipo puede usar para recopilar información sobre los
clientes.

Es esencial que usted y su equipo realicen una investigación juntos; por eso lo
llamamos descubrimiento colaborativo .La subcontratación de la investigación reduce
drásticamente su valor: desperdicia tiempo, limita la formación de equipos y filtra la
información a través de entregables, transferencias e interpretación. No lo hagas.

Los investigadores a veces se sienten incómodos con este enfoque. Comoprofesionales

capacitados, tienen razón al señalar que tienen un conocimiento especial que es
importante para el proceso de investigación. Estamos de acuerdo. Es por eso que debe
incluir un investigador en su equipo si puede. Simplemente no subcontrates el trabajo a
esa persona. En su lugar, utilice al investigador como guía experto para ayudar a su equipo
a planificar su trabajo y dirigir al equipo a través de sus actividades de investigación. De
la misma manera que Lean UX anima a los diseñadores a adoptar un enfoque más
facilitador, Lean UX les pide lo mismo a los investigadores. Los investigadores deben
utilizar su experiencia para ayudar al equipo a planificar una buena investigación, hacer
buenas preguntas y seleccionar los métodos adecuados para el trabajo. Simplemente no
hagas toda la investigación por ellos.

Descubrimiento colaborativo en el campo

El descubrimiento colaborativo es simplemente una forma de salir al campo con su

equipo. Así es como lo haces:

1. En equipo, revise sus preguntas, suposiciones, hipótesis y MVP. Decida en equipo

lo que necesita aprender. (Recuadro 7 en Lean UX Canvas).
2. Trabajando en equipo, decida su método de investigación. (Recuadro 8 en Lean
UX Canvas).Si planea trabajar directamente con clientes y usuarios, decida con
quién deberá hablar y observar para abordar sus objetivos de aprendizaje.
3. Cree una guía de entrevistas (consulte la barra lateral "La guía de entrevistas") que
todos pueden utilizar para guiar sus conversaciones.
4. Divida su equipo en pares de investigación, mezclando los distintos roles y
disciplinas dentro de cada par (es decir, trate de no tener diseñadores emparejados
con diseñadores). Si está haciendo esta investigación durante varios días, intente
mezclar los pares de entrevistas todos los días para que las personas tengan la
oportunidad de compartir experiencias con varios miembros del equipo.
5. Arma cada par con una versión de tu MVP, prototipo o otros materiales que desee
mostrar a los participantes de la investigación.
6. Envíe a cada equipo a reunirse con clientes / usuarios.
7. Un miembro del equipo entrevista mientras el otro toma notas.
8. Comience con preguntas, conversaciones y observaciones.
9. Demuestre el MVP más adelante en la sesión y permita que el cliente interactúe
con él.
10. Recopile notas a medida que el cliente proporciona comentarios.
11. Cuando el entrevistador principal haya terminado, cambie los roles para que el
tomador de notas tenga la oportunidad de hacer preguntas de seguimiento.
 12. Al final de la entrevista, pídale al cliente referencias a otras personas que también
podrían proporcionar comentarios útiles.

LA GUÍA DE ENTREVISTAS

Para prepararse para el trabajo de campo, cree una pequeña hoja de trucos que quepa en
su cuaderno. En su hoja de referencia, escriba las preguntas y los temas que ha decidido
cubrir. De esta manera, siempre estará preparado para hacer avanzar la entrevista.

Cuando planifique sus preguntas, piense en un embudo secuencial:

• Primero, intente identificar si el cliente está en su público objetivo.

• Luego, intente confirmar cualquier hipótesis de problema que tenga para este
segmento.

Finalmente, si tiene un prototipo o maqueta, muestre este último para evitar limitar la
conversación a su visión de la solución.

Un ejemplo de descubrimiento colaborativo

Un equipo con el que trabajamos en PayPal se estableció con un prototipo para realizar
una sesión de descubrimiento colaborativa. El equipo estaba compuesto por dos
diseñadores, un investigador de UX, cuatro desarrolladores y un gerente de producto; se
dividieron en equipos de dos y tres. Emparejaron cada desarrollador con un no
desarrollador. Antes de partir, hicieron una lluvia de ideas sobre lo que les gustaría
aprender de su prototipo y utilizaron estas ideas para escribir breves guías de
entrevistas. Su producto estaba dirigido a un amplio mercado de consumidores, por lo que
decidieron simplemente dirigirse a los centros comerciales locales esparcidos por su
oficina. Cada par apuntó a un centro comercial diferente. Pasaron dos horas en el campo,
deteniendo a extraños, haciéndoles preguntas y demostrando sus prototipos. Para
desarrollar sus habilidades individuales, cambiaron de rol (de líder a anotador) una hora
después de iniciar su investigación.

Cuando volvieron a reunirse, cada pareja leyó sus notas al resto del equipo. Casi de
inmediato, comenzaron a ver surgir patrones, que confirmaban algunas de sus
suposiciones y rechazaban otras.Usando esta nueva información, ajustaron el diseño de
su prototipo y se dirigieron nuevamente esa misma tarde. Después de un día completo de
investigación de campo, quedó claro qué partes de su idea funcionaron bien y qué partes
necesitarían ajustes. Cuando comenzaron el siguiente sprint al día siguiente, todos los
miembros del equipo estaban trabajando desde la misma línea de base de claridad,
habiendo construido un entendimiento compartido por medio del descubrimiento
colaborativo el día anterior.

Aprendizaje continuo

Los diseñadores e investigadores se enfrentan a mucha presión para forzar su trabajo en

un marco de sprint. El problema es que algunos trabajos solo llevan mucho tiempo,
especialmente algunos tipos de investigación. Este trabajo de ciclo largo tiene el potencial
de crear conflictos en los equipos ágiles. Los investigadores están acostumbrados a
planificar proyectos de investigación de varias semanas, por ejemplo. Y cuando intentan
hacer esto en un equipo ágil y ponen su proyecto de investigación de ocho semanas en la
lista de trabajos pendientes, terminan teniendo que explicar al final de cada sprint por qué
su trabajo no está “terminado”. Hace que todos se sientan infelices.

Volviendo a los principios

Cuando se enfrenta a un conflicto como este, es útil volver a los principios. ¿Recuerda
este principio del Capítulo 2 ? No hagas lo mismo más rápido. ¿Y éste? Cuidado con las
fases. Estos principios nos dicen que no deberíamos intentar encajar un estudio de
investigación de ocho semanas en un sprint de dos semanas. En su lugar, deberíamos
repensar la forma en que planificamos nuestra investigación y la forma en que pensamos
en "hecho" para el trabajo de investigación.

Para hacer eso, consideremos por qué el marco de Scrum insiste tanto en la noción
de hecho . Scrum dice que cualquier trabajo que hagas durante un sprint debe realizarse
al final de ese sprint. Esta es una función de fuerza poderosa: obliga a todos a mostrar su
trabajo. Y asume que el trabajo terminado es valioso. (Eso no siempre es cierto, pero ese
es el objetivo).

Entonces, para nosotros, el objetivo de done es realmente: "Ser transparente y ofrecer

valor en cada sprint".

¿Cómo podemos usar esa idea cuando planeamos una investigación? Bueno, en lugar de
pensar en completar nuestro estudio de ocho semanas en dos semanas, podemos
preguntarnos: "¿Cómo podemos ser transparentes y ofrecer valor cada dos semanas,
incluso cuando estamos trabajando en un estudio de ocho semanas?" Podríamos entregar
un informe de experiencia en las reuniones de demostración de Sprint. Podríamos
presentar algunas conclusiones iniciales después de completar la mitad de nuestras
entrevistas. Podríamos presentar y discutir las nuevas preguntas que han surgido a medida
que comenzamos a aprender cosas nuevas. Todas esas cosas son valiosas para el
equipo. Hacen transparente el trabajo. Mantienen el espíritu ágil al mismo tiempo que
mantienen alta la integridad del trabajo de investigación.

Investigación continua: la investigación nunca se hace

Un equipo ágil de alto funcionamiento debería estar investigando continuamente. Una de

las mejores prácticas fundamentales en Lean UX es crear una cadencia regular de
participación del cliente. Las conversaciones programadas con regularidad con los
clientes le permiten minimizar el tiempo entre la creación de la hipótesis, el diseño del
experimento y los comentarios de los usuarios, lo que le brinda la oportunidad de validar
sus hipótesis rápidamente.

En otras palabras, la investigación debe informar las decisiones que está tomando el
equipo de producto. Dado que toma decisiones constantemente, desea asegurarse de tener
a mano los datos de investigación más recientes en todo momento. (Y, a la inversa, la
agenda de investigación a veces debería impulsar las prioridades de desarrollo porque a
veces es necesario hacer cosas que respalden específicamente las necesidades de sus
investigadores. Es una conversación bidireccional).
En general, saber que solo faltan unos días para recibir comentarios de los clientes tiene
un efecto poderoso en los equipos. Elimina la presión de la toma de decisiones porque
sabe que pronto tendrá la oportunidad de obtener datos significativos del mercado y
corregirlos rápidamente si es necesario.

Así que deje de pensar en términos de estudios de investigación y fases de investigación,

y en su lugar piense en la investigación como una parte continua del ritmo operativo de
su equipo. Comparta su trabajo. Entregue valor cada semana. Sea honesto sobre lo que
sabe y lo que no sabe. Ayude a su equipo a aprender. El resto de este capítulo le mostrará
cómo.

Aprendizaje continuo en el laboratorio: tres usuarios cada jueves

Aunque puede crear un cronograma permanente de trabajo de campo basado Con las ideas
mencionadas anteriormente, es mucho más fácil (especialmente para las empresas que
trabajan con consumidores) atraer clientes al edificio; solo necesita ser un poco creativo
para involucrar a todo el equipo.

Nos gusta usar un ritmo semanal para programar la investigación, como se muestra en
la Figura 15-1 . A esto lo llamamos “Tres, doce, uno” porque se basa en las siguientes
pautas: tres usuarios; a las doce del mediodía; una vez por semana.

Figura 15-1. El calendario de actividades de tres, doce y uno

Así es como se desglosan las actividades del equipo:

Lunes: Reclutamiento y planificación.

Decidir, en equipo, qué se probará esta semana. Decida a quién necesita reclutar para
las pruebas yiniciar el proceso de contratación. Subcontrate este trabajo si es posible:
lleva mucho tiempo (consulte la barra lateral "Un comentario sobre la contratación de
participantes" ).

Martes: refina los componentes de la prueba

 Según la etapa en la que se encuentre su MVP, comience a refinar el diseño, el prototipo
o el producto hasta un punto que le permita contar al menos una historia completa
cuando sus clientes la vean.

Miércoles: Continúe perfeccionando, escriba el guión y finalice la contratación.

Dale los toques finales a tu MVP. Escriba el guión de prueba que su moderador seguirá
con cada participante. (Su moderador debe ser alguien del equipo si es posible). Finalice
el reclutamiento y el horario para las pruebas del jueves.

Jueves: ¡Prueba!

Pase la mañana probando su MVP con los clientes. No dedique más de una hora a cada
cliente. Todos los miembros del equipo deben tomar notas. El equipo debe planear
mirar desde una ubicación separada. Revise los hallazgos con todo el equipo del
proyecto inmediatamente después de que termine el último participante.

Viernes: Plan

Utilice su nueva perspectiva para decidir si sus hipótesis fueron validadas y qué debe
hacer a continuación.

Simplifique su entorno de prueba

Muchas empresas han establecido laboratorios de usabilidad internamente, y solía ser que
necesitabas uno. En estos días, no necesita un laboratorio; todo lo que necesita es un lugar
tranquilo en su oficina y una computadora con una conexión de red y una cámara
web. Solía ser necesario utilizar productos de prueba de usabilidad especializados para
grabar sesiones y conectar observadores remotos. En estos días, ni siquiera lo
necesitas. Realizamos pruebas de forma rutinaria con observadores remotos utilizando
nada más exótico que Zoom.

La capacidad de conectar observadores remotos es un elemento clave. Esole permite

llevar las sesiones de prueba a los miembros del equipo y las partes interesadas que no
pueden estar presentes. Esto tiene un impacto enorme en la colaboración porque extiende
la comprensión de sus clientes a lo más profundo de su organización. Es difícil exagerar
lo poderoso que es esto.

¿Quién debería mirar?

La respuesta corta es todo su equipo. Como casi todosOtro aspecto de Lean UX, las
pruebas de usabilidad deben ser una actividad grupal. Con todo el equipo observando las
pruebas, absorbiendo los comentarios y reaccionando en tiempo real, encontrará reducida
la necesidad de informes posteriores. El equipo aprenderá de primera mano dónde están
teniendo éxito y dónde fracasan sus esfuerzos. Nada es más humillante (y motivador) que
ver a un usuario luchar con el software que acaba de crear.

UNAS PALABRAS SOBRE EL RECLUTAMIENTO DE PARTICIPANTES

Reclutar, programar y confirmar a los participantes es hora intensivo. Ahorre a su equipo

de esta sobrecarga adicional transfiriendo el trabajo a un reclutador dedicado. Algunas
empresas han contratado reclutadores internos para realizar este trabajo como parte de su
equipo de DesignOps o ResearchOps, mientras que otras subcontratan el trabajo a un
tercero. En cualquier caso, el costo vale la pena. El reclutador hace el trabajo y se le paga
por cada participante que traen. Además, su reclutador se encarga de la selección,
programación y reemplazo de las ausencias el día del examen. Los reclutadores externos
suelen cobrar por cada participante que reclutan. También tendrás que presupuestar
cualquier compensación que ofrezcas a los propios participantes.

Investigación continua: algunos ejemplos

Las empresas ponen en práctica la investigación continua en muchos diferentes

caminos. Por ejemplo, el equipo de ABN AMRO, un banco de los Países Bajos, ejecuta
lo que llaman un Carrusel de validación de clientes una vez a la semana. Este evento
semanal de investigación de usuarios está estructurado como citas rápidas. Cada semana,
cinco clientes ingresan a las oficinas de la empresa. Cada cliente se configura en su propia
estación de investigación. Luego, un grupo de entrevistadores entra en la sala y se
dispersan, cada uno sentado con un cliente. (En ABN AMRO,muchos de los
entrevistadores son “personas que investigan”, en otras palabras, diseñadores y personas
de productos en lugar de investigadores capacitados. Debido a esto, los investigadores
capacitados del personal trabajan con ellos antes del evento para ayudarlos a crear su plan
de investigación y guías de discusión. Las entrevistas suelen ser realizadas por un par de
entrevistadores que trabajan juntos y se turnan para entrevistar y tomar notas).

Los entrevistadores realizan entrevistas de 15 minutos con cada participante. Cuando

terminan los 15 minutos, cada entrevistador o pareja se levanta y pasa al siguiente
participante, algo así como sillas musicales. De esta manera, cada entrevistador puede
hablar con cada participante. Después de que todos han hablado con todos los demás, los
clientes se van y los entrevistadores se reúnen para informar. Normalmente, a cada
entrevistador se le asigna un solo tema, pero aunque es posible que no estén trabajando
en el mismo conjunto de preguntas, el informe es valioso, ya que les ayuda a comprender
mejor a los clientes y les ayuda a interpretar los datos que acaban de recopilar. . Capturan
lo aprendido de este evento en una plantilla de información de una sola página y luego
agregan estos documentos a la base de datos de información compartida de la empresa. El
investigador Ike Breed, quien ayudó a configurar este proceso, nos dijo que este paso de
compartir realmente democratizó la investigación. “La gente pensaba que la base de datos
de información valiosa era algo realmente formal. Me preguntaron: '¿Quiere decir que
puedo poner algo allí?' ”. Al abrir el proceso a la contribución de un grupo más amplio,
ayudó a los equipos de diseño y productos a sentirse más dueños del proceso de
conocimiento del cliente y de los datos que se recopilaron como parte de ese proceso.

Prueba los martes

Otro investigador con el que hablamos nos contó cómo empezó una práctica llamada
"Martes de prueba" en su empresa, una empresa de servicios financieros que crea
tecnología orientada al consumidor. Andrew Bourne fue contratado allí como
investigador de usabilidad. Cuando llegó, descubrió que le esperaba un largo trabajo
atrasado. Mientras trabajaba en el trabajo pendiente, comenzó a informar sobre los
resultados de la investigación en cada demostración de Sprint, que, en su empresa, se
realizaba todos los martes. Debido a que tenía una gran cantidad de trabajo atrasado,
siempre había algo nuevo que informar. Para ayudar a asegurarse de que sus informes
fueran escuchados por todos los interesados, comenzó a publicar el contenido de su sesión
informativa con anticipación mediante anuncios por correo electrónico. Él anunciaba:
"Esta semana, estaré informando sobre X". Esto tuvo dos efectos realmente
positivos. Primero, hizo que la gente se presentara a sus sesiones informativas; a menudo,
muchas más personas estaban interesadas en los resultados de lo que había
anticipado. Además, la gente de productos empezó a acudir a él para pedirle su
colaboración en la investigación queque querían hacer. En otras palabras, aumentó la
demanda de investigación. Y no solo estudios de usabilidad. Las personas que acudían a
él pedían todo tipo de investigación, incluidos estudios formativos en las primeras etapas.

INVESTIGACIÓN CONTINUA EN SPERIENTIA LABS

Sperientia Labs es una agencia de investigación de la experiencia del usuario de unas 30

personas radicadas en Puebla, México. Sperientia ofrece investigación a los clientes en
un formato único: utilizan una serie de sprints de investigación de una
semana. “Utilizamos un enfoque en el que el marco Agile siempre está en mente”, dice
el fundador Víctor M. González.

Este enfoque tiene varios beneficios. Primero, González dice que la mayoría de sus
clientes ya están trabajando en un ritmo ágil. Esto permite a Sperientia sincronizar su
línea de tiempo con la línea de tiempo de los clientes.

Otro beneficio es la forma rápida en que estos ciclos producen resultados. Sperientia
ofrece entrevistas de descubrimiento y pruebas de usabilidad en el transcurso de una
semana muy estructurada. Planifican y reclutan el viernes, continúan reclutando y
preparándose el lunes, luego realizan pruebas con entre tres y seis participantes el martes
y miércoles por la mañana. El miércoles por la tarde, tienen una sesión informativa con
sus clientes. “En muchos casos, este informe es todo lo que los clientes necesitan y pueden
ponerse a trabajar de inmediato en lo que han aprendido”, dice González. Aún así,
Sperientia usa los jueves para capturar los resultados y las recomendaciones en un
informe, y luego se reúne con los clientes el viernes por la mañana para revisar los
hallazgos en detalle. Después del almuerzo del viernes, están listos para comenzar a
planificar su próximo ciclo.

Ahora bien, no todos los objetivos de la investigación se pueden cumplir en una semana,
y El programa de investigación típico de Sperientia dura de 3 a 12 meses. Entonces,
aunque utilizan ciclos de investigación de una semana en todos sus programas, no se
limitan a responder solo preguntas que pueden responderse en una sola semana. En
cambio, utilizan ciclos continuos de una semana para abordar una gama mucho más
amplia de preguntas.

La agencia trabaja con una variedad de objetivos de investigación de clientes: ayudan a

los clientes a comprender y desarrollar propuestas de valor, comprender el trabajo que
deben realizar los usuarios y evaluar la usabilidad y el diseño de sus ofertas.

Al utilizar un programa de varios ciclos de una semana, Sperientia puede ejecutar

programas de investigación que crecen y evolucionan a medida que aprenden. Pueden
ejecutar programas de investigación que sigan el ritmo del desarrollo de un
producto. Pueden ejecutar programas de naturaleza longitudinal. Y aunque su enfoque es
fundamentalmente cualitativo (basado en sesiones individuales con usuarios y clientes),
pueden crear programas que recopilen datos cuantitativos haciendo las mismas preguntas
semana tras semana.

Recientemente, Sperientia comenzó a experimentar con un nuevo formato de sprint de

investigación de dos semanas. Usan este formato cuando tienen que responder preguntas
que involucran algún tipo de prototipo. En estos casos, extenderán el ciclo para incluir
una semana de desarrollo de prototipos, seguida de su típica semana de
investigación. Para lograr esto, aumentan el equipo de investigación para incluir
diseñadores que puedan ayudarlos a crear prototipos para realizar pruebas.

Por lo tanto, trabajar con estos ciclos cortos de una semana ayuda a la agencia a igualar
el ritmo de sus clientes, les ayuda a ofrecer resultados rápidos y continuos y tiene un
beneficio adicional. González lo describe de esta manera: “¡Tenemos los fines de semana
con la tranquilidad de que hemos terminado!”.

Dar sentido a la investigación: una actividad en equipo

Ya sea que su equipo realice trabajo de campo o de laboratorio, investigue genera una
gran cantidad de datos sin procesar. Entender esto puede llevar mucho tiempo y ser
frustrante, por lo que el proceso a menudo se entrega a especialistas a quienes se les pide
que sinteticen los hallazgos de la investigación. No deberías hacer esto. En su lugar,
trabaje tan duro como pueda para dar sentido a los datos como equipo.

Tan pronto como sea posible después de que terminen las sesiones de investigación,
preferiblemente el mismo día, si no al día siguiente, reúna al equipo para una sesión de
revisión. Cuando el equipo se haya vuelto a reunir, pida a todos que lean sus hallazgos
entre sí. Una forma realmente eficaz de hacer esto es transcribir las notas que la gente lee
en voz alta en fichas o notas adhesivas y luego ordenar las notas por temas. Este proceso
de lectura, agrupación y discusión pone sobre la mesa las opiniones de todos y construye
el entendimiento compartido que usted busca. Con los temas identificados, usted y su
equipo pueden determinar los próximos pasos para su MVP.

Confusión, contradicción y (falta de) claridad

A medida que usted y su equipo recopilen comentarios de diversas fuentes y traten de

sintetizar sus hallazgos, inevitablemente se encontrarán con situaciones en las que sus
datos les presentan contradicciones. ¿Cómo le da sentido a todo esto? Aquí hay un par de
formas de mantener su impulso y asegurarse de que está maximizando su aprendizaje.

Busque patrones

Mientras revisa la investigación, esté atento a los patrones en los datos. Estos patrones
revelan múltiples instancias de opinión de los usuarios que representan elementos para
explorar. Si algo no sigue un patrón, es probable que sea un valor atípico.

Coloque sus valores atípicos en un "estacionamiento"

Por muy tentador que sea ignorar los valores atípicos (o tratar de incluirlos en su
solución), no lo haga. En su lugar, cree un estacionamiento o un atraso. A medida que
su investigación avanza con el tiempo (recuerde: está haciendo esto todas las semanas),
es posible que descubra otros valores atípicos que coincidan con el patrón. Se paciente.
Verificar con otras fuentes

Si no está convencido de que los comentarios que está viendo a través de un canal sean
válidos, búsquelos en otros canales. ¿Los correos electrónicos de atención al cliente
reflejan las mismas preocupaciones que sus estudios de usabilidad? ¿El valor de su
prototipo se refleja en los clientes dentro y fuera de su oficina? De lo contrario, su
muestra podría haber sido desproporcionadamente sesgada.

Identificar patrones a lo largo del tiempo

Los programas típicos de investigación de UX están estructurados para obtener

un respuesta concluyente: planeará hacer suficiente investigación para responder de
manera concluyente a una pregunta o conjunto de preguntas. La investigación Lean UX
adopta un enfoque diferente. Da prioridad a la continuidad, lo que significa que está
estructurando sus actividades de investigación de manera muy diferente. En lugar de
realizar grandes estudios, está viendo una pequeña cantidad de usuarios cada
semana. Esto significa que algunas preguntas pueden permanecer abiertas durante un par
de semanas. Sin embargo, un gran beneficio es que los patrones interesantes pueden
revelarse con el tiempo.

Por ejemplo, en el transcurso de sesiones de prueba regulares deDe 2008 a 2011, el equipo
de TheLadders observó un cambio interesante en las actitudes de sus clientes a lo largo
del tiempo. En 2008, cuando comenzaron a reunirse por primera vez con personas que
buscaban empleo de manera regular, discutían varias formas de comunicarse con los
empleadores. Una de las opciones que propusieron fue el SMS. En 2008, la audiencia,
compuesta por personas de altos ingresos de entre 40 y 50 años, mostró un fuerte desdén
por los SMS como método de comunicación legítimo. Para ellos, era algo que hacían sus
hijos (y tal vez lo hicieran con sus hijos), pero ciertamente no era una forma "adecuada"
de realizar una búsqueda de empleo.

Sin embargo, para 2011, los mensajes SMS habían despegado en Estados Unidos. A
medida que la mensajería de texto ganó aceptación en la cultura empresarial, las actitudes
de la audiencia comenzaron a suavizarse. Semana tras semana, mientras se sentaban con
los solicitantes de empleo, comenzaron a ver opiniones sobre el cambio de SMS. El
equipo vio que los solicitantes de empleo tenían muchas más probabilidades de usar SMS
en una búsqueda de trabajo a mitad de carrera que lo que hubieran hecho unos años antes .

El equipo de TheLadders nunca habría reconocido esto como una tendencia para toda la
audiencia si no fuera por dos cosas. Primero, estaban hablando con una muestra de su
audiencia, semana tras semana. Sin embargo, además, el equipo adoptó un enfoque
sistemático para investigar las tendencias a largo plazo. Como parte de su interacción
regular con los clientes, siempre hacían un conjunto regular de preguntas de
establecimiento de niveles para capturar los "signos vitales" de la búsqueda del solicitante
de empleo, sin importar qué otras preguntas, características o productos estuvieran
probando. Al hacer esto, el equipo pudo establecer una línea de base y abordar tendencias
más importantes a lo largo del tiempo. Los hallazgos sobre SMS no habrían cambiado la
comprensión del equipo de su audiencia si hubieran representado solo algunos puntos de
datos anecdóticos. Pero agregados con el tiempo, estos puntos de datos se convirtieron en
parte de un conjunto de datos muy poderoso.
Al planificar su investigación, es importante tener en cuenta no solo las preguntas
urgentes, sino también las cosas que desea aprender durante las próximas
semanas. También debe considerar las grandes preguntas. Aún debe planificar grandes
estudios independientes para abordar algunas de estas preguntas. Pero con un poco de
planificación, debería poder incorporar mucho aprendizaje a largo plazo en sus estudios
semanales.

Prueba lo que tienes

Para mantener una cadencia regular de pruebas de usuario, su equipo debe adoptar una
política de "prueba lo que tienes". Lo que esté listo el día de la prueba es lo que se presenta
a los usuarios. Esta política libera a su equipo de apresurarse hacia las fechas límite del
día de la prueba o, lo que es peor, retrasar las actividades de investigación en busca de un
momento "perfecto" evasivo. En cambio, cuando adoptas un enfoque de "prueba lo que
tienes", te encontrarás aprovechando tus sesiones de prueba semanales para obtener
información sobre lo que esté listo, y esto creará información para ti en cada etapa del
diseño y desarrollo. Sin embargo, debe establecer expectativas de manera adecuada para
el tipo de comentarios que podrá generar con cada tipo de artefacto.

Bocetos

Los comentarios recopilados en los bocetos le ayudan a validar el valor de su concepto

(consulte la Figura 15-2 ).Son excelentes sugerencias de conversación para respaldar las
entrevistas y ayudan a concretar conceptos abstractos, lo que ayuda a generar un
entendimiento compartido. Lo que no obtendrá de los bocetos es comentarios detallados
y paso a paso sobre el proceso, información sobre elementos de diseño específicos o
incluso comentarios significativos sobre las opciones de copia. Usted no va a ser capaz
de aprender mucho (si acaso) acerca de la utilidad de su concepto.
Figura 15-2. Ejemplo de un boceto que se puede utilizar con los clientes.
Wireframes estáticos

Mostrar tramas alámbricas de los participantes de la prueba ( Figura 15-3 )le permite
evaluar la jerarquía de información y el diseño de su experiencia. Además, obtendrá
comentarios sobre la taxonomía, la navegación y la arquitectura de la información.

Recibirá los primeros comentarios sobre el flujo de trabajo, pero en este punto los
participantes de la prueba se centran principalmente en las palabras de la página y en las
selecciones que están haciendo. Los wireframes brindan una buena oportunidad para
comenzar a probar las opciones de copia.
Figura 15-3. Ejemplo de una estructura alámbrica
Maquetas visuales de alta fidelidad (no se puede hacer clic)

Pasando a activos de diseño visual de alta fidelidad, recibe retroalimentación mucho más
detallada. Los participantes de la prueba podrán responder a la marca, la estética y la
jerarquía visual, así como los aspectos de las relaciones figura / fondo, la agrupación de
elementos y la claridad de sus llamadas a la acción. Los participantes de la prueba también
(casi con certeza) evaluarán la efectividad de su paleta de colores. (Vea la Figura 15-4 .)

Las maquetas en las que no se puede hacer clic aún no permiten que sus clientes
interactúen de forma natural con el diseño o experimenten el flujo de trabajo de su
solución. En lugar de ver a sus usuarios hacer clic, tocar y deslizar, debe preguntarles qué
esperarían y luego validar esas respuestas con su experiencia planificada.
Figura 15-4. Ejemplo de maqueta de Skype en el aula (diseño de Made By Many)
Maquetas en las que se puede hacer clic

Maquetas en las que se puede hacer clic, como la que se muestra en la Figura 15-
4 ,Aumente la fidelidad de la interacción al vincular un conjunto de activos estáticos en
una simulación de la experiencia del producto. En estos días, la mayoría de las
herramientas de diseño facilitan la vinculación de varias pantallas estáticas para producir
este tipo de maquetas. Visualmente, pueden ser de alta, media o incluso baja fidelidad. El
valor aquí no es tanto el pulido visual sino la capacidad de simular el flujo de trabajo y
observar cómo los usuarios interactúan con sus diseños.

Los diseñadores solían tener opciones limitadas de herramientas para crear maquetas en
las que se podía hacer clic, pero en los últimos años, hemos visto una gran proliferación
de herramientas. Algunas herramientas están optimizadas para hacer maquetas móviles,
otras son para la web y otras son neutrales a la plataforma. La mayoría no tiene capacidad
para trabajar con datos, pero con algunos (como Axure), puede crear simulaciones básicas
basadas en datos o basadas en lógica condicionada. Además, las herramientas de diseño
como Figma, Sketch, InVision y Adobe XD incluyen funciones de "espejo" con las que
puede ver su trabajo de diseño en tiempo real en dispositivos móviles y vincular pantallas
para crear prototipos sin herramientas especiales de creación de prototipos.

Prototipos codificados

Los prototipos codificados son útiles porque tienen los mejores capacidad para ofrecer
alta fidelidad en términos de funcionalidad . Esto lo convierte en la simulación más
cercana a la real que puede poner frente a sus usuarios. Replica el diseño, el
comportamiento y el flujo de trabajo de su producto. Puede probar con datos reales. Puede
integrarse con otros sistemas. Todo esto hace que los prototipos codificados sean muy
potentes; también los hace los más complejos de producir. Pero debido a que la
retroalimentación que obtiene se basa en una simulación tan cercana, puede tratar esa
retroalimentación como más autorizada que la retroalimentación que obtiene de
otras simulaciones .

Técnicas de seguimiento para el descubrimiento continuo y colaborativo

En las discusiones anteriores, analizamos formas de usar investigación cualitativa de

forma periódica para evaluar sus hipótesis. Sin embargo, tan pronto como lance su
producto o función, sus clientes comenzarán a brindarle comentarios constantes, y no solo
sobre su producto. Te hablarán de ellos mismos, del mercado, de la competencia. Esta
información es invaluable y llega a su organización desde todos los rincones. Busque
estos tesoros de inteligencia de clientes dentro de su organización y aprovéchelos para
impulsar su investigación y diseño de productos en curso, como se muestra en la Figura
15-5 .
Figura 15-5. Los clientes pueden proporcionar comentarios a través de muchos canales.
Servicio al Cliente

Los agentes de atención al cliente hablan con más clientes a diario base de la que hablará
en el transcurso de un proyecto completo. Hay varias formas de aprovechar su
conocimiento:

• Comuníquese con ellos y pregúnteles qué escuchan de los clientes sobre las
secciones del producto en el que está trabajando.
• Mantenga reuniones mensuales periódicas con ellos para comprender las
tendencias. ¿Qué les encanta a los clientes este mes? ¿Qué odian?
• Aproveche su profundo conocimiento del producto para aprender cómo
resolverían los desafíos en los que está trabajando su equipo. Inclúyalos en
sesiones de diseño y revisiones de diseño.
• Incorpora tus hipótesis en sus guiones de llamadas. Una de las formas más
económicas de probar sus ideas es sugerirlas como una solución a los clientes que
llaman con quejas relevantes.

A mediados de la década de 2000, Jeff dirigía el equipo de UX en una tecnología de

tamaño medio. empresa en Portland, Oregon. Una de las formas en que el equipo priorizó
el trabajo que realizaba fue controlando regularmente el pulso de la base de clientes. El
equipo hizo esto con una reunión mensual permanente con representantes de servicio al
cliente. Cada mes, el Servicio de atención al cliente le proporcionaría al equipo de UX las
10 principales cosas de las que se quejaban los clientes. Luego, el equipo de UX utilizó
esta información para enfocar sus esfuerzos y posteriormente medir la eficacia de su
trabajo. A finales de mes, la siguiente conversación con el Servicio de atención al cliente
le dio al equipo una clara indicación de si sus esfuerzos estaban dando frutos o no. Si el
problema no retrocedía en la lista de los 10 principales, las soluciones no habían
funcionado.

Este enfoque generó un beneficio adicional. El equipo de Servicio al Cliente se dio cuenta
de que había alguien escuchando sus ideas y comenzó a compartir de manera proactiva
los comentarios de los clientes más allá de la reunión mensual. El diálogo que se creó
proporcionó al equipo de UX un ciclo de retroalimentación continua para informar y
probar hipótesis de productos.

Encuestas de comentarios in situ

Configure un mecanismo de retroalimentación en su producto con el que los clientes

pueden enviarle sus pensamientos con regularidad. Aquí hay algunas opciones:

• Formularios de correo electrónico sencillos

• Foros de soporte al cliente
• Sitios de comunidades de terceros

Puede reutilizar estas herramientas para la investigación haciendo cosas como las
siguientes:

• Contar cuántos correos electrónicos entrantes está recibiendo de una sección

particular del sitio
• Participar en discusiones en línea y probar algunas de sus hipótesis
• Explorar sitios de la comunidad para descubrir y reclutar tipos de usuarios difíciles
de encontrar

Estos canales de retroalimentación de los clientes entrantes brindan retroalimentación

desde el punto de vista de sus clientes más activos y comprometidos. Aquí hay algunas
tácticas para obtener otros puntos de vista.

Registros de búsqueda

Los términos de búsqueda son indicadores claros de lo que son los clientes buscando en
su sitio. Los patrones de búsqueda indican lo que están encontrando y lo que no
encuentran. Las consultas repetidas con ligeras variaciones muestran el desafío de un
usuario para encontrar cierta información.

Una forma de utilizar los registros de búsqueda para la validación de MVP es lanzar
un página de prueba para la función que está planeando. Después de la búsqueda, los
registros le informarán si el contenido (o función) de la prueba en esa página satisface las
necesidades del usuario. Si los usuarios continúan buscando variaciones de ese contenido,
su experimento ha fallado.
Análisis de uso del sitio

Registros de uso del sitio y paquetes de análisis, especialmente el embudo Análisis:

muestran cómo los clientes utilizan el sitio, dónde lo abandonan y cómo intentan
manipular el producto para hacer las cosas que necesitan o esperan que haga. La
comprensión de estos informes proporciona un contexto del mundo real para las
decisiones que el equipo debe tomar.

Además, utilice herramientas de análisis para determinar el éxito de los experimentos que
se han lanzado públicamente. ¿Cómo ha cambiado el experimento el uso del
producto? ¿Están sus esfuerzos logrando el resultado que definió? Estas herramientas
brindan una respuesta imparcial.

Si recién está comenzando a crear un producto, incorpore análisis de uso desde el primer
día. Los productos de métricas de terceros, como Kissmetrics y MixPanel, hacen que
implementar esta funcionalidad sea fácil y económico, y brindan información invaluable
para respaldar el aprendizaje continuo.

Pruebas A / B

La prueba A / B es una técnica, desarrollada originalmente por especialistas en marketing,

para evaluar cuál de dos (o más) conceptos relativamente similares logran el objetivo
definido de manera más efectiva. Cuando se aplica en el marco Lean UX, las pruebas A
/ B se convierten en una herramienta poderosa para determinar la validez de sus
hipótesis. Aplicar las pruebas A / B es relativamente sencillo después de que sus ideas
evolucionen hacia un código de trabajo. Así es como funciona:

• Tome la solución propuesta y publíquela a su audiencia. Sin embargo, en lugar de

dejar que todos los clientes lo vean, publíquelo solo para un pequeño subconjunto
de usuarios.
• Mida el rendimiento de su solución para esa audiencia. Compárelo con el otro
grupo (su cohorte de control) y observe las diferencias.
• ¿Tu nueva idea movió la aguja en la dirección correcta? Si lo hizo, tiene una idea
ganadora.
• De lo contrario, tiene una audiencia de clientes que podrían ser buenos objetivos
para una mayor investigación. ¿Qué pensaron de la nueva experiencia? ¿Tendría
sentido contactarlos para realizar una investigación cualitativa?

Las herramientas para las pruebas A / B están ampliamente disponibles y pueden ser
económicas. Existen herramientas comerciales de terceros como Optimizely. También
hay marcos de prueba A / B de código abierto disponibles para todas las plataformas
principales. Independientemente de las herramientas que elija, el truco consiste en
asegurarse de que los cambios que está realizando sean lo suficientemente pequeños y la
población que seleccione sea lo suficientemente grande como para que cualquier cambio
en el comportamiento pueda atribuirse con confianza al cambio que ha realizado. Si
cambia demasiadas cosas, cualquier cambio de comportamiento no se puede atribuir
directamente a su hipótesis exacta.

Terminando
En este capítulo, cubrimos muchas formas de validar sus hipótesis. Analizamos el
descubrimiento colaborativo y las técnicas de aprendizaje continuo. Discutimos cómo
construir un proceso de prueba Lean semanal y cubrimos qué debe probar y qué esperar
de esas pruebas. Buscamos formas de monitorear la experiencia de sus clientes en un
contexto Lean UX y abordamos el poder de las pruebas A / B.

Estas técnicas, utilizadas junto con los procesos descritos en el Capítulo 4 y el Capítulo
5 , conforman el ciclo completo del proceso Lean UX. Su objetivo es atravesar este ciclo
con la mayor frecuencia posible, refinando su pensamiento con cada iteración .

En la siguiente sección, nos alejamos del proceso y echamos un vistazo a cómo integrar
Lean UX en su organización. Cubriremos los cambios organizativos que deberá realizar
para respaldar el enfoque Lean UX, ya sea que sea una startup, una gran empresa o una
agencia digital.
Capítulo 16. Integración de Lean UX y
Agile
Pregunte a cualquier persona de cualquier organización cuál es la forma predeterminada
de trabajar es para ellos, y la respuesta invariablemente será "¡Estamos haciendo
Agile!" Sigue esa pregunta con "¿Y cómo te está funcionando?" y en la mayoría de los
casos levantarán la mano y la estrecharán de un lado a otro en el gesto de "meh, está bien".

Agile nació de los desarrolladores, 17 de ellos de hecho, que representan formas

emergentes de trabajo que habían surgido de su frustración con los procesos de ingeniería
más antiguos y la imprevisibilidad del desarrollo de software. En una reunión de fin de
semana en Utah en 2001, estos desarrolladores de software reunieron una serie de
principios que llamaron Manifiesto Ágil. 1 Si no lo ha leído (debería hacerlo, es breve),
se sorprenderá al descubrir que no hay mucho “proceso” prescrito en el Manifiesto
Ágil. No hay nada allí que diga: "Te pondrás de pie todos los días a las 9:15 con tu equipo"
o "Trabajarás en ciclos de dos semanas llamados sprints". Esas son técnicas tomadas de
métodos ágiles específicos, como Scrum y Extreme Programming (XP), métodos que
fueron inventados por muchas de las personas que se unieron para crear el Manifiesto
Ágil en sí. En lugar de capturar prácticas específicas, los autores del Manifiesto
enumeraron valores y principios para el desarrollo de software altamente colaborativo y
centrado en el cliente.La línea más convincente de todo el manifiesto, y en nuestra opinión
la base de la verdadera agilidad, es "[Valoramos] responder al cambio antes que seguir
un plan".

Ese es el meollo de la cuestión, de verdad. Si trabaja de una manera que invita al

aprendizaje, acepta ese aprendizaje de una manera humilde y cambia su plan en función
de lo que ha aprendido, está siendo ágil.

En los 20 años transcurridos desde que se creó el Manifiesto, este enfoque para hacer el
trabajo se ha convertido en la forma predeterminada de trabajar en la mayoría de las
organizaciones (o al menos, la aspiración predeterminada). Estas ideas ágiles llegaron
mucho más allá de los equipos de desarrollo de software y ahora se están aplicando a
todo, desde la planificación estratégica y el liderazgo hasta los recursos humanos, las
finanzas, el marketing y, por supuesto, el diseño.

La forma más conocida de Agile es Scrum,un marco ligero inventado principalmente por
Jeff Sutherland y Ken Schwaber a mediados de la década de 1990. (Sí, Scrum ha existido
por más tiempo que el Manifiesto Ágil). Y, sin embargo, a pesar de toda su popularidad,
Scrum solo ha comenzado recientemente a pensar en cómo encaja el diseño en el
proceso.Hasta noviembre de 2020, The Scrum Guide , la documentación oficial de
Scrum, nunca había mencionado la experiencia del usuario o el diseño de ninguna
manera. A medida que el gran diseño y el enfoque en el cliente se convierten en factores
de éxito cada vez más importantes en los productos tecnológicos, tanto los diseñadores
como los profesionales de Agile han luchado por descubrir exactamente cómo integrarse
en los procesos de Agile. Mientras que el resto de Lean UX describe una forma ágil de
trabajar, este capítulo ayudará a responder algunas preguntas sobre cómo se adapta Lean
UX a la mecánica de los métodos ágiles y, en particular, nos centraremos en el diseño
dentro del contexto de Scrum.
Haga suyo el proceso ágil
A menudo nos preguntan cómo deberían funcionar los equipos ágiles recién
formados.¿Deberían usar Scrum? ¿Deberían trabajar en sprints de dos semanas? ¿Qué
nivel de formalidad deben implementar para tener éxito? Con tantas historias de
frustración con las transformaciones ágiles, los equipos y líderes quieren hacerlo bien lo
más rápido posible y minimizar el dolor, la frustración y la disminución de la
productividad. Podrías pasar los próximos 10 años leyendo todos los libros sobreLas
mejores prácticas de Scrum, pero cuando lo reduce al núcleo, le quedan los siguientes
componentes, que constituyen un excelente punto de partida para cualquier equipo:

• Trabaja en ciclos cortos.

• Entregue valor al final de cada ciclo.
• Realice una breve reunión de planificación diaria (o Scrum diario).
• Realice una retrospectiva después de cada ciclo.

Puede pasar mucho tiempo debatiendo todos los demás componentes de Scrum (así como
las cosas que la gente piensa que son parte de Scrum pero que nunca se mencionan en la
Guía de Scrum ), pero estos cuatro elementos básicos proporcionan todo lo que necesita
para aumentar la agilidad. de tu equipo. Un equipo con una alineación dedicada trabajará
en conjunto para descubrir qué pueden hacer en cada ciclo. Se reunirán a diario para
determinar cuál es el siguiente conjunto de cosas más importantes que deben hacer y, de
manera crítica, revisarán la eficacia de su proceso después de cada ciclo.

De hecho, no es exagerado decir que Las retrospectivas, cuando se usan correctamente,

son la clave para construir un equipo ágil cohesivo y multifuncional. Scrum no le dice
cómo encajar a los diseñadores o el trabajo de diseño en un sprint o cómo manejar el
trabajo de diseño en el backlog, pero si su equipo intenta una forma de incorporar el
diseño en el proceso de Scrum, lo ejecuta durante un sprint o dos, y luego, retrospectivas
para determinar qué tan bien funcionó, ha comenzado el proceso de ser dueño de su
proceso Agile. Si elimina el espíritu prescriptivo de Scrum del proceso y, en su lugar,
aplica la lente filosófica del Manifiesto Ágil, entonces, de hecho, está respondiendo al
cambio en lugar de seguir un plan. En este caso, el plan es la receta rígida del proceso
Agile; el cambio al que está respondiendo es su comprensión de qué tan bien funcionó
esa receta para usted y su equipo. Si funciona bien, ¡fantástico! Sigue haciendolo. Pero si
no logró lo que esperaba, cambie de rumbo. Ahora estásser ágil en lugar de
simplemente hacerlo .

Es por eso que las retrospectivas son tan poderosas y son el único evento de Scrum que
recomendamos más que cualquier otro. Las retrospectivas honestas e irreprochables
brindan a un equipo la oportunidad regular de ajustar su forma de trabajar. Una
retrospectiva mira hacia atrás en el último ciclo o dos y pregunta: ¿Qué ha funcionado
bien? ¿Qué no ha funcionado tan bien? ¿Qué vamos a cambiar en el futuro?La mejor
parte de abordar un proceso de esta manera es que el riesgo de cambiar su proceso es
mínimo. Lo más que tendrás que vivir con un cambio es la duración de tu sprint. Si bien
este capítulo le brindará muchas formas de construir un proceso integrado de Lean UX y
Scrum, haga lo que haga, asegúrese de usar retrospectivas para examinar lo que hace. Si
las técnicas que recomendamos no funcionan para su equipo, cámbielas, mézclelas y
combínelas o tírelas. Tu versión de Agile (o Scrum) será diferente a la de cualquier otro
equipo. Esto esta bien. De hecho, diríamos que ese es el objetivo de ser ágil.

Redefiniendo "Listo"

¿Cuándo está listo el software? Escribimos sobre esto en el Capítulo 3 . Cuandoestá

trabajando para crear un resultado, necesita enviar el software (el resultado) y luego ver
si crea el resultado que desea. No puede enviar software hasta que haya "terminado". Pero
no ha terminado realmente hasta que haya "validado" ese software.

En Scrum, nada puede transmitirse a un usuario hasta que esté "hecho". Esto tiene mucho
sentido. Debe asegurarse de que el software que está lanzando cumpla con ciertos
estándares de calidad compartidos (lo que Scrum llama "la definición de hecho") y que
ofrece la funcionalidad que usted y su equipo han planeado (lo que Scrum llama los
"criterios de aceptación" ). La definición de hecho la crea el equipo y los criterios de
aceptación generalmente los establece el gerente de producto o el propietario del
producto. Juntos, estos estándares garantizan que cada trabajo esté completo, funcione
según lo diseñado, libre de errores y lo suficientemente estable para pasar a
producción. Sin embargo, para la mayoría de los equipos de Scrum, este es el final de su
participación con esa pieza de software. Este punto final, sin embargo, no se hace
responsable de los resultados y refleja una idea mucho más antigua de la naturaleza del
software.

Cuando comenzamos nuestras carreras, el software venía en una caja. Si eso le suena
extraño, podría ser aún más extraño saber que cuando Jeff era un niño, su padre traía a
casa las tarjetas perforadas con las que venía el software en la década de 1970. En ambos
casos, con más de 20 años de diferencia, el software era estático. Tenía un estado
final. Podríamos empaquetarlo en cajas o en tarjetas de papel. Avance rápido otros 20
años, y estos conceptos parecen ridículos ahora. El software no viene en una caja y ya no
es estático. Hoy construimos sistemas que se actualizan continuamente y se pueden
optimizar indefinidamente. Hoy en día, es fácil argumentar que el
software nuncahecho. Esto hace que la pregunta "¿Cuándo terminamos?" uno difícil de
responder. Pero debemos responderla porque ayuda a responder otras preguntas aún más
importantes. ¿Pasamos a la siguiente función o no? ¿El equipo es recompensado o
castigado? ¿El interesado recibe su bono?

Scrum, con sus conceptos de "criterios de aceptación" y "definición de hecho", les ha

dado a los equipos un conjunto claro de objetivos a alcanzar. Pero esos objetivos solo
llegan hasta cierto punto. Como hemos dicho, se aseguran de que el software "funcione
según lo diseñado". Pero “funciona según lo diseñado” solo nos dice que el software hace
consistentemente lo que le pedimos que haga. Desafortunadamente, eso no es
suficiente. También necesitamos saber si el software generó valor. ¿Alguien encontró la
función que acabamos de enviar? ¿Lo intentaron? ¿Tuvieron éxito
usándolo? ¿Regresaron y lo usaron de nuevo? ¿Nos pagaron por ello? En otras palabras,
necesitamos saber si generó un resultado.

Entonces, ¿cómo saben nuestros equipos cuando el trabajo está terminado? ¿Cuándo
saben cuándo pasar a la siguiente iniciativa? Necesitamos agregar un concepto aquí: el
concepto de "validado". Y la validación comienza con nuestros clientes.
Validamos nuestro trabajo después de que está "hecho". Después de que sea
"aceptado". Después de que esté en manos de nuestros clientes. Hacemos esto midiendo
su comportamiento. Hacemos esto escuchando sus necesidades y evaluando si nuestras
características satisfacen esas necesidades, y luego iterando hasta satisfacer esas
necesidades. Una y otra vez. Resulta que los diseñadores son muy buenos haciendo este
trabajo.

Al expandir nuestra idea de hecho de "funciona según lo diseñado" a "validado con los
clientes", cambiamos hacia lo que están trabajando los equipos de Scrum. En lugar de
centrarse en las funciones de envío, se centran en hacer que los clientes tengan éxito. El
diseño es una parte integral de esto, porque el diseño proporciona muchas de las
herramientas necesarias para comprender a los clientes y perfeccionar las soluciones para
satisfacer mejor sus necesidades. Si la definición de hecho de una función se reformula
como un resultado, el equipo no tiene más remedio que probar las primeras versiones de
su idea, interactuar con los clientes para comprender cómo se pueden mejorar las cosas y
diseñar versiones optimizadas de la función para satisfacer las necesidades cambiantes.
necesidades.

He aquí un ejemplo. Criterios de aceptación expresados tradicionalmente para un flujo de

autenticación de contraseña:

• Requiere entrada de contraseña

• La contraseña cumple con las pautas de requisitos básicos
• La contraseña se ingresa correctamente y el usuario está verificado en el sistema
• El enlace de recuperación de contraseña está activo
• Aparece un mensaje de error cuando la contraseña se ingresa incorrectamente
• Después de tres intentos fallidos, el acceso se bloquea

Criterios reformulados para la misma característica:

• El porcentaje de usuarios que se autentican con éxito en el primer intento es del

99% o más
• El número de intentos de recuperación de contraseña se reduce en un 90%
• El porcentaje de llamadas al centro de llamadas solicitando el restablecimiento de
la contraseña se redujo en un 75%

En el ejemplo tradicional, el equipo crea y lanza un conjunto de características que

funcionan según lo diseñado. Con la segunda definición, el equipo no termina hasta que
el cliente tiene más éxito de lo que es hoy. Este método refleja la naturaleza moderna del
software y requiere la intervención e inclusión de investigación, descubrimiento y diseño
en el proceso Scrum. Esta recalibración del objetivo del equipo no niega el valor de los
criterios de aceptación tradicionales. Todavía queremos enviar a producción código
estable, de alta calidad, de alto rendimiento y seguro. Sin embargo, eso no es
suficiente. Esos atributos son apuestas en la mesa. Nada de eso importa si no hace que el
cliente tenga más éxito.

Todavía estamos haciendo sprints escalonados. ¿Por qué?

En mayo de 2007, Desiree Sy publicó "Adaptación de las investigaciones de usabilidad

para un diseño ágil centrado en el usuario" en la Revista de Estudios de Usabilidad . 2 Sy
es una de las primeras personas en intentar combinar Agile y UX, y muchos de nosotros
estábamos entusiasmados con las soluciones que proponía. En el artículo de 2007, Sy
describe en detalle su idea de una integración productiva del diseño ágil y centrado en el
usuario. Ella lo llamó ciclo 0 (aunque se le conoce popularmente como "sprint cero" o, a
veces, "sprints escalonados").

En resumen, Sy, junto con Lynn Miller, describió un proceso en el que la actividad de
diseño tiene lugar un sprint antes del desarrollo. El trabajo se diseña y valida durante el
“sprint de diseño” y luego se pasa al flujo de desarrollo para ser implementado durante el
sprint de desarrollo, como se ilustra en la Figura 16-1 .

Figura 16-1. Modelo de "Sprints escalonados" de Sy y Miller

Sin embargo, muchos equipos han malinterpretado este modelo. Sy siempre abogó por
una estrecha colaboración entre los diseñadores y desarrolladores durante ambos el
diseño y carreras cortas de desarrollo. Muchos equipos han pasado por alto este punto
crítico y, en cambio, han creado flujos de trabajo en los que los diseñadores y
desarrolladores se comunican mediante transferencia, creando una especie de proceso de
mini cascada.

Para los equipos que realizan la transición de cascada a Agile, trabajar de esta manera
tiene una ventaja. Te enseña a trabajar en ciclos más cortos y a dividir tu trabajo en piezas
secuenciales. Sin embargo, este modelo funciona mejor como transición. No es donde
quiere que termine su equipo.

He aquí por qué: resulta muy fácil crear una situación en la que todo el equipo nunca esté
trabajando en lo mismo al mismo tiempo. Nunca se da cuenta de los beneficios de la
colaboración multifuncional porque las diferentes disciplinas se centran en cosas
diferentes. Sin esa colaboración, no se crea un entendimiento compartido, por lo que
termina dependiendo en gran medida de la documentación y las transferencias para la
comunicación.

Hay otra razón por la que este proceso no es ideal: puede generar desperdicios
innecesarios. Pierde tiempo creando documentación para describir lo que sucedió durante
los sprints de diseño. Y si los desarrolladores no han participado en el sprint de diseño,
no han tenido la oportunidad de evaluar la viabilidad o el alcance del trabajo. Esa
conversación no ocurre hasta el traspaso. ¿Pueden realmente construir los diseños
especificados en las próximas dos semanas? Si no es así, el trabajo dedicado al diseño de
esos elementos se desperdicia.

A pesar de estos inconvenientes, muchos equipos todavía trabajan en sprints escalonados

en la actualidad. En nuestra experiencia, existen varias posibles causas fundamentales
para esto:

El equipo de diseño no está integrado en el proceso de "desarrollo".

En muchas empresas, el diseño sigue siendo un servicio compartido que funciona

como una agencia interna. Los diseñadores no están asignados a un equipo Scrum
específico. Se ven como una dependencia para que comience el trabajo de
desarrollo de software. Al hacer que los diseñadores trabajen a toda velocidad, el
trabajo de diseño puede "alimentar la máquina" del desarrollo de software.

El desarrollo de software se subcontrata

Algunas organizaciones aún subcontratan su desarrollo de software. En un mundo

donde el software es el motor de los negocios y el crecimiento, este es un talón de
Aquiles asombrosamente arriesgado. Sin embargo, si la codificación la realiza un
proveedor externo, querrán ver los diseños "finales" antes de estimar y comenzar
el trabajo. Los sprints escalonados lo hacen posible para los equipos que trabajan
con socios subcontratados.

Cargo cult Agile

Algunas organizaciones han incorporado procesos ágiles para aumentar la

eficiencia y la productividad del desarrollo de software, no para la capacidad de
cambiar de rumbo en función de nuevos conocimientos y conocimientos. En este
caso, la organización opera como una fábrica de software, produciendo funciones
lo más rápido posible. Si bien el trabajo puede dividirse en sprints y el vocabulario
ágil se usa en toda la organización, la prioridad sigue siendo simplemente enviar
funciones. Estas organizaciones generalmente se enfocan en los plazos y rara vez
se toman el tiempo para iterar y mejorar las características a través de comentarios
y validaciones. Los sprints escalonados proporcionan a la fábrica de
características el material necesario para la producción. La colaboración entre
diseñadores y desarrolladores es mínima, ya que las transferencias y los
entregables aún forman la base de la conversación entre ellos.

Los sprints escalonados son un síntoma de una organización que no ha adoptado

completamente la agilidad. Su uso es un trampolín en la dirección correcta, pero una clara
indicación de que el equipo aún no ha llegado. Su objetivo debe ser generar una mayor
colaboración y transparencia entre diseñadores y desarrolladores al tiempo que reduce el
desperdicio de entregas de documentos, revisiones de diseño prolongadas y
negociaciones de características.

Ágil de doble vía

Agile de doble vía es un modelo que integra el descubrimiento de productos y entrega el

trabajo en un solo proceso para el mismo equipo. Este es el modelo más exitoso que
hemos visto hasta la fecha para llevar el trabajo Lean UX con éxito al proceso Agile.En
muchos sentidos, el Agile de doble vía es lo que Sy y Miller intentaban transmitir con su
modelo de sprint escalonado. Sin embargo, para que funcione Agile de doble vía, un
equipo debe realizar ambos tipos de trabajo: descubrimiento (Lean UX) y entrega.

Algunos equipos interpretan Agile de doble vía como dos tipos de trabajo para dos grupos
separados de personas.

No nos gusta este modelo principalmente porque divide al equipo de desarrollo de

productos en escuadrones más pequeños (o, peor aún, separados) que luego
inevitablemente tienen que volver a unirse para construir un entendimiento
compartido. En la práctica, hemos visto a los equipos enfrentarse a los siguientes
problemas:

Equipos separados de descubrimiento y entrega: un antipatrón del que hemos sido

testigos varias veces es que los equipos se dividen entre quién realiza el descubrimiento
y quién realiza la entrega en su equipo. A menudo, el diseñador de UX y / o el gerente de
producto asumen la mayor parte del trabajo de descubrimiento. A los ingenieros se les
delega el trabajo de entrega anticipada. Esto recrea efectivamente las mini cascadas de
sprints escalonados, como se describió anteriormente. La comprensión compartida se
rompe, ralentizando el ritmo de la toma de decisiones y reduciendo la cohesión, la
productividad y el aprendizaje del equipo.

Conocimiento limitado de cómo hacer un descubrimiento: La construcción de un

proceso ágil de doble vía supone que su equipo sabe cómo hacer descubrimientos. Hay
muchas herramientas que puede utilizar para crear ciclos de retroalimentación en un
registro de descubrimiento. Sin un conocimiento más amplio de estas herramientas, los
equipos recurren a aquellas con las que están más familiarizados y, a menudo, eligen
tácticas subóptimas para el aprendizaje. Si tiene acceso a investigadores, intente
agregarlos a su equipo. Por lo menos, busque su opinión cuando comiencen las nuevas
iniciativas de descubrimiento. Los profesionales experimentados pueden enseñarle a su
equipo el mejor método para sus necesidades y pueden ayudarlo a planificar su trabajo de
descubrimiento.

No retroalimentar la evidencia del trabajo de entrega a la acumulación de

descubrimientos: este desafío es sintomático de una organización que todavía está
pensando de manera incremental. Una vez que una función pasa del descubrimiento a la
entrega, el equipo la implementará como se diseñó y la enviará. Lo bueno de esto es que,
tan pronto como está disponible, esta nueva función comienza a proporcionar un nuevo
conjunto de datos sobre qué tan bien está funcionando y dónde enfocar sus próximas
actividades de descubrimiento. Solo tiene que prestar atención y hacer que el equipo
preste atención. Asegúrese de que su equipo continúe recopilando comentarios sobre las
funciones enviadas y utilice esa información para evaluar periódicamente la priorización
de su trabajo de descubrimiento.

La doble vía funciona cuando es un solo equipo

La mejor forma de pensar en el sistema de doble vía es que se trata de dos tipos de trabajo
— descubrimiento de productos y entrega de productos — realizado por un
equipo ( Figura 16-2 ). El trabajo de descubrimiento consiste en el aprendizaje activo a
través de actividades de diseño e investigación, así como el aprendizaje pasivo a través
del análisis entrante de características y productos que ya están en el mercado. Para
construir un entendimiento compartido, nos esforzamos por tener la mayor cantidad
posible de miembros del equipo que participen en cada actividad. La cantidad de trabajo
de descubrimiento y entrega fluctuará de un sprint a otro. Esto es normal y puede
anticiparlo mientras hace planes.

Figura 16-2. Agile de doble bastidor funciona cuando es un solo equipo. Concepto de imagen:
Gary Pedretti y Pawel Mysliwiec

Si está haciendo bien el trabajo de descubrimiento, está cambiando y potencialmente

matando muchas ideas. No hacemos un trabajo de descubrimiento simplemente para
validar cada característica que tenemos en nuestro backlog. En cambio, estamos probando
y aprendiendo, y a veces eso significa que eliminamos funciones antes de enviarlas. Una
vez más, esto es ser ágil y es exactamente la razón por la que Agile se concibió en primer
lugar. Sin trabajo de descubrimiento, Agile acaba siendo solo el motor de la fábrica de
software.

Planificación del trabajo de doble vía

A lo largo de años de práctica, hemos probado muchas formas diferentes de teniendo en

cuenta ambos tipos de trabajo en el proceso Scrum. Intentamos reservar una cantidad
específica de tiempo en cada sprint para que se llevara a cabo el trabajo de
descubrimiento, pero eso fue insatisfactorio, porque en algunos sprints no había nada que
hacer, mientras que en otros era la mayor parte del trabajo.Hemos probado el enfoque de
Marty Cagan de dividir el trabajo entre disciplinas (el diseño y los administradores de
proyectos hacen el descubrimiento, los ingenieros hacen la entrega), pero los gastos
generales de las transferencias, las negociaciones y los debates redujeron la capacidad del
equipo para responder al cambio. En general, hemos descubierto que garantizar que todo
el equipo cambie su carga de trabajo según las necesidades del sprint actual es la mejor
opción. De hecho, es la opción más ágil. Permite al equipo ajustar sus actividades en
función de lo que está aprendiendo, asegurando así que el trabajo más importante ocurra
a continuación. A veces ese trabajo es descubrimiento y otras veces es entrega.

Para hacer que Agile de doble vía sea un éxito y para llevar Lean UX al flujo de trabajo
diario de su equipo Scrum, existen algunos elementos estructurales que son críticos para
que la integración brinde los resultados que busca su equipo.

Un diseñador dedicado en cada equipo: aquí no hay compromiso. Sin un diseñador

dedicado en el equipo de Scrum, lo que tiene es un equipo de ingeniería de software. Si
bien ese equipo ofrecerá absolutamente una experiencia de usuario, no tendrá el mismo
nivel de calidad sin la participación de un diseñador. Además, ese equipo carecerá de las
habilidades para hacer un buen trabajo de descubrimiento: se centrarán exclusivamente
en escribir código. Como mencionamos antes, la producción de código ya no es el
objetivo del gran desarrollo de productos digitales, es el medio para lograr un fin. El
objetivo es producir cambios significativos en el comportamiento de nuestros
clientes. Sin una comprensión profunda del cliente y la mejor manera de satisfacer esas
necesidades, su producto fallará. Los diseñadores aportan eso al equipo.

El trabajo de diseño y descubrimiento es un ciudadano de primera clase de la

acumulación: en pocas palabras, una acumulación. El trabajo de desarrollo, el trabajo de
control de calidad, el trabajo de diseño, el trabajo de investigación, lo que sea, todo va en
un trabajo pendiente, priorizado junto con el mismo equipo que hace todo ese trabajo. Tan
pronto como el trabajo se divida entre más de un trabajo pendiente, el equipo considerará
a uno de ellos como el "principal" y el otro o los otros quedarán descuidados. Puede y
debe tener ambas pistas del trabajo administradas en el mismo trabajo
pendiente. Ciertamente, puede diferenciar los diferentes tipos de trabajo en su backlog
(vea las historias de experimentos, a continuación), pero todo debe terminar en la misma
herramienta de administración de proyectos, sin importar si usa un tablero Scrum físico
o JIRA o algo más.

Usar un trabajo pendiente y tratar todo el trabajo de la misma manera garantiza que el
equipo comprenda que todos estos componentes son necesarios para el éxito de su
producto. Visualiza el trabajo de Lean UX de una manera que lo coloca al mismo nivel
que el trabajo de desarrollo de software (que siempre tiene el peso más alto en nuestra
experiencia). También destaca las compensaciones que deberán realizarse para que se
lleve a cabo el trabajo de descubrimiento.

A menudo, esto traerá consigo cuestiones de velocidad. "¿No reduciremos nuestra

velocidad si hacemos todo este trabajo de descubrimiento?" Si solo está midiendo la
velocidad de entrega, la respuesta es sí. Los equipos maduros de doble vía miden tanto la
velocidad de entrega como la velocidad de descubrimiento (o aprendizaje). Estos equipos
se dan cuenta de que, a medida que aumenta la cantidad de trabajo de aprendizaje,
inevitablemente se reducirá la cantidad de entrega. Esto se debe a que el mismo grupo de
personas realiza ambos tipos de trabajo. Esto también está bien, porque al final del día,
estamos tratando de maximizar la efectividad del equipo, y lo hacemos rastreando los
resultados, no rastreando cuántas historias completa o cuánto software crea.

Hay un par de formas de representar el trabajo Lean UX en su backlog.(Consulte la Figura

16-3 .) Puede representarlo como una historia independiente. ( La Guía Scrum llama
artículos de la cartera de productos de las historias o PBI). O puede integrar el trabajo en
la historia misma, asegurándose de que no se envíe ninguna función sin que se lleve a
cabo el trabajo de descubrimiento y diseño.
Figura 16-3. Patrones comunes para gestionar el trabajo de UX en el backlog

Participación multifuncional en actividades de aprendizaje: Lean UX trae consigo

muchos tipos de actividades de aprendizaje. Estas actividades pueden ser dirigidas por
diseñadores o investigadores o incluso gerentes de producto, pero deben ser practicadas
y atendidas por todo el equipo. Cuanto más pueda aprender el equipo en conjunto, menos
tiempo se dedicará a compartir y debatir el aprendizaje y más tiempo se podrá dedicar a
decidir qué hacer con las cosas que hemos aprendido. Esta última es una conversación y
un uso mucho más productivo del tiempo del equipo. No estamos diciendo que todos los
miembros del equipo necesiten participar en todas las actividades de
investigación. Creemos que todos deberían participar hasta cierto punto y que la
participación debería ser una parte regular de su actividad laboral, no un evento especial.

Haga de la participación en el proceso de descubrimiento el camino de menor

resistencia. Transmita las conversaciones de sus clientes internamente para que otros
puedan verlas desde sus escritorios. Si un colega se siente incómodo hablando con un
cliente, tráigalo y conviértalo en el anotador.Mida lo que Jared Spool denomina "horas
de exposición". 3 Las horas de exposición son una medida de la cantidad de tiempo que
cada miembro de su equipo está expuesto directamente a los usuarios. Asegúrese de que
cada miembro de su equipo pase al menos un bloque de tiempo de dos horas cada seis
semanas en contacto directo con los clientes. Esto podría ser dos horas en el centro de
llamadas atendiendo o escuchando llamadas. Pueden ser dos horas en la tienda o en el
piso de la fábrica observando a los clientes y usuarios. O podría estar realizando ventas
cara a cara de su producto en entornos públicos. Estas actividades generan empatía y eso,
a su vez, impulsa la curiosidad. Cuanta más curiosidad tenga todo el equipo sobre si
realmente satisfacen o no las necesidades del cliente, mayor será la probabilidad de que
las actividades de Lean UX terminen en su cartera de pedidos.

Explotar los ritmos de Scrum para

construir una práctica Lean UX
A lo largo de los años, hemos encontrado algunas formas útiles de integrar enfoques Lean
UX con los ritmos de Scrum. Echemos un vistazo a cómo puede utilizar la cadencia de
reuniones de Scrum y Lean UX para construir un proceso eficiente.

Un enfoque que pusimos juntos fue pedir a los equipos que mapeen Actividades Lean UX
sobre un diagrama del marco de Scrum para ayudarlos a enfocar la integración de las
prácticas. Compartimos un intento típico en la Figura 16-4 . Creemos que este es un
intento bastante bueno, pero le recomendamos que lo intente con su equipo. Mientras lo
revisa, recuerde las siguientes advertencias:

• Esta no es de ninguna manera una lista completa de actividades de diseño. No hay

suficientes Post-its (digitales o de otro tipo) en el mundo para cubrir eso.
• Usamos la palabra Diseño (a menudo con una D mayúscula) para que sirva como
término general para todas las actividades en las que los diseñadores de todo tipo
realizan o participan normalmente.

Como ocurre con todas las recomendaciones de este libro, este es un punto de partida. Le
muestra cómo superponer las actividades existentes sobre Scrum. Intentalo. Vea lo que
funciona para usted y su equipo y luego ajústelo en función de lo que decida durante sus
retrospectivas.

Figura 16-4. Mapeo de las actividades de Lean UX al marco de Scrum

Objetivos de Sprint, Objetivos de Producto y Temas de Sprint Múltiple

Supongamos que su organización se ha decidido por un enfoque estratégico para los

próximos dos trimestres. Su equipo decide utilizar una hipótesis arriesgada como primer
intento para lograr la estrategia. Puede usar esa hipótesis para crear un tema de sprints
múltiples que guíe el trabajo que realizará en el siguiente conjunto de sprints. Scrum llama
a estos temas "Objetivos de producto". (Piense en un objetivo de producto como un tema
de múltiples sprints que utiliza para conectar una secuencia de sprints). Sus medidas de
éxito para su tema son los resultados, como se muestra en la Figura 16-5 .

Figura 16-5. Sprints vinculados con un tema o objetivo de producto

Comienza el tema con un diseño colaborativo

Empiece a trabajar en cada tema utilizando Lean UX Canvas y quizás un ejercicio de

Design Studio. 4 (Ver Figura 16-6 .) Dependiendo del alcance de la hipótesis, la sesión
de diseño colaborativo puede ser tan corta como una tarde o tan larga como una
semana. Puede hacerlos con su equipo inmediato, pero debe incluir un grupo más amplio
si se trata de un esfuerzo a mayor escala. El objetivo de este inicio es lograr que todo el
equipo dibuje, idee y hable con los clientes juntos, creando una acumulación de ideas a
partir de las cuales probar y aprender. Además, esta actividad ayudará a definir un poco
mejor el alcance de su tema, suponiendo que haya incorporado algunos bucles de
retroalimentación de los clientes.

Figura 16-6. El Lean UX Canvas puede capturar su tema de sprint

Una vez que haya comenzado sus sprints regulares, estará probando y validando sus ideas:
aparecerán nuevos conocimientos y deberá decidir qué hacer con ellos. Usted toma estas
decisiones ejecutando sesiones subsecuentes de lluvia de ideas más breves y actividades
de descubrimiento colaborativo a medida que comienza cada nuevo sprint ( Figura 16-
7 ). Esto le permite al equipo usar la información más reciente para crear el backlog para
el próximo sprint.
Figura 16-7. Calendario y alcance de las sesiones de creación de bocetos e ideas
Reunión de planificación de Sprint

Lleve su Lean UX Canvas a la reunión de planificación del sprint. Traiga el resultado de

su sprint de diseño también. Su lío de notas adhesivas, bocetos, wireframes, prototipos de
papel y cualquier otro artefacto puede parecer inútil para los observadores externos, pero
será significativo para su equipo. Hicieron estos artefactos juntos, y por eso tienen el
conocimiento compartido necesario para extraer historias de ellos. Úselos en su reunión
de planificación para escribir historias de usuarios juntos y luego estimar y priorizar las
historias. (Vea la Figura 16-8 .)

Figura 16-8. Realice reuniones de planificación de sprints inmediatamente después de las

sesiones de lluvia de ideas
Historias de experimentos

Mientras planifica su iteración, puede haber más trabajo de descubrimiento que debe
realizarse durante la iteración que no se cubrió en el sprint de diseño o en las actividades
de descubrimiento colaborativo. Para acomodar esto en su cadencia de sprint y capturar
todo el trabajo en el mismo backlog, use historias de experimentos. Capturadas utilizando
el mismo método que sus historias de usuario, las historias de experimentos tienen dos
beneficios distintos:

Visualizan el trabajo de descubrimiento

El trabajo de descubrimiento no es inherentemente tangible como puede serlo el

trabajo de entrega. Las historias experimentales resuelven eso nivelando el campo
de juego. Todo en lo que trabaja su equipo, descubrimiento o entrega, se incluye
en la lista de trabajos pendientes como una historia.

Obligan su priorización frente al trabajo de entrega:

Una vez que esas historias están en la lista de trabajos pendientes, debe ponerlas
en orden de prioridad. Esto obliga a conversar sobre cuándo ejecutar el
experimento y, lo que es igualmente importante, en qué no trabajaremos durante
ese mismo tiempo.

Las historias experimentales se parecen a las historias de los usuarios, como se ilustra en
la Figura 16-9 .
Figura 16-9. Historias de experimentos

Las historias experimentales contienen los siguientes elementos:

• La hipótesis que está probando o lo que está tratando de aprender.

• Táctica (s) para el aprendizaje (por ejemplo, entrevistas con clientes, pruebas A /
B y prototipos)
• Quién va a hacer el trabajo
• Una estimación del nivel de esfuerzo (si hace estimaciones) de cuánto trabajo
espera que sea

Una vez que se escriben, las historias de experimentos se incorporan a su lista de trabajos
pendientes. Cuando llega su momento en el sprint, ese es el enfoque principal de la
persona asignada. Cuando termine el experimento, lleve los hallazgos al equipo de
inmediato y discútalos para determinar el impacto de estos hallazgos. Su equipo debe
estar listo para cambiar de rumbo, incluso dentro del sprint actual, si el resultado de las
historias del experimento revela información que invalida su priorización actual.

Consejo profesional: a veces sabemos que habrá trabajo de descubrimiento por

hacer, pero su forma o formato exactos no está claro al comienzo de un sprint. Para
asegurarse de que el equipo tenga ancho de banda para este trabajo durante el sprint,
coloque una historia de experimento en blanco en su backlog. A medida que el trabajo de
descubrimiento se revela durante el sprint, llénelo con detalles y establezca las prioridades
de manera adecuada. Si termina sin usar, eso es un poco más de espacio para respirar que
su equipo tiene durante ese sprint. Todos ganan.

Programa de validación de usuarios

Finalmente, para asegurarse de tener un flujo constante de comentarios de los clientes

para usar en sus experimentos, planifique sesiones de investigación de usuarios cada
semana. (Consulte la Figura 16-10 ). De esta manera, su equipo nunca estará a más de
cinco días hábiles de recibir comentarios de los clientes y tendrá tiempo suficiente para
reaccionar antes del final del sprint. Esta cadencia de investigación semanal proporciona
un buen ritmo para las historias de sus experimentos y un punto de aprendizaje natural en
el sprint.

Utilice los artefactos que creó en las sesiones de ideación como material base para sus
pruebas de usuario. Recuerde que cuando las ideas son crudas, está probando su valor. (Es
decir, ¿la gente quiere usar mi producto en lugar de usar mi producto? ) Una vez que
haya establecido que existe un deseo por su producto, las pruebas posteriores con
artefactos de mayor fidelidad revelarán si su solución es utilizable.

Figura 16-10. Las conversaciones con los usuarios ocurren durante cada sprint
Los diseñadores deben participar en la planificación

Los métodos ágiles pueden crear mucha presión de tiempo en diseñadores. Algunos
trabajos encajan fácilmente en el contexto de una historia de usuario. Otro trabajo necesita
más tiempo para hacerlo bien. Los ciclos de dos semanas de desarrollo y diseño
simultáneos ofrecen pocas oportunidades para que los diseñadores reflexionen sobre
grandes problemas. Y aunque algunos métodos ágiles adoptan un enfoque más flexible
del tiempo que Scrum (por ejemplo, Kanban elimina la noción de un lote de trabajo de
dos semanas y hace hincapié en el flujo continuo), la mayoría de los diseñadores sienten
la presión de adaptarse a su trabajo. en el cuadro de tiempo del sprint. Por esta razón, los
diseñadores deben participar en el proceso de planificación del sprint.

La principal razón por la que los diseñadores sienten presión en los procesos ágiles es que
no participan (por cualquier motivo) plenamente en el proceso. Por lo general, esto no es
culpa suya: cuando Agile se entiende simplemente como una forma de crear software, no
parece haber ninguna razón para incluir a personas que no son tecnológicas en el
proceso. Sin embargo, sin la participación del diseñador, sus preocupaciones y
necesidades no se tienen en cuenta en los planes del proyecto. Como resultado, muchos
equipos ágiles no hacen planes que permitan a los diseñadores hacer su mejor trabajo.

Para que Lean UX funcione, todo el equipo debe participar en todas las actividades (stand-
ups, retrospectivas, reuniones de planificación, sesiones de lluvia de ideas), como regla
normal, todas requieren la asistencia de todos para tener éxito. Además de negociar la
complejidad de ciertas características, la participación multifuncional permite a los
diseñadores y desarrolladores crear una priorización efectiva de la acumulación.

Por ejemplo, imagina al comienzo de un sprint que la primera historia que prioriza un
equipo tiene un componente de diseño pesado. Imagínese que el diseñador no estuviera
allí para expresar su preocupación. Ese equipo fallará tan pronto como se reúnan para su
stand-up al día siguiente. El diseñador dirá que la historia no ha sido diseñada. El
diseñador dirá que llevará al menos dos o tres días completar el diseño antes de que la
historia esté lista para su desarrollo. Imagine, en cambio, que el diseñador hubiera
participado en la priorización de la cartera de pedidos. Su preocupación se habría
planteado en el momento de la planificación. El equipo podría haber seleccionado una
tarjeta de historia que requiriera menos preparación de diseño para trabajar primero, lo
que le habría dado al diseñador el tiempo que necesitaba para completar el trabajo.

La otra víctima de la escasa participación se comparte comprensión. Los equipos toman

decisiones en reuniones. Esas decisiones se basan en discusiones. Incluso si el 90% de
una reunión no es relevante para su necesidad inmediata, el 10% que es relevante le
ahorrará horas de tiempo posterior. La participación le da la posibilidad de negociar el
tiempo que necesita para hacer su trabajo. Esto es tan cierto para los diseñadores de UX
como para todos los demás miembros del equipo.

Partes interesadas y panel de riesgos

Los controles de gestión son uno de los mayores obstáculos para mantener el impulso del
equipo. Los diseñadores están acostumbrados a hacer revisiones de diseño, pero
desafortunadamente, los registros no terminan ahí. Los propietarios de productos, las
partes interesadas, los directores ejecutivos y los clientes quieren saber cómo van las
cosas. Todos quieren bendecir el plan del proyecto en el futuro. El desafío para los
equipos centrados en los resultados es que los planes de sus proyectos dependen de lo que
están aprendiendo. Son receptivos, por lo que su plan típico establece solo pequeños lotes
de trabajo a la vez. A lo sumo, estos equipos planean una iteración o dos por
adelantado. Esta percepción de "miopía" tiende a no satisfacer a la mayoría de los
gerentes de alto nivel, lo que puede conducir a la microgestión.Entonces, ¿cómo mantiene
los registros bajo control mientras mantiene el ritmo de sus procesos Lean UX y Scrum?

Dos palabras: comunicación proactiva.

Jeff una vez dirigió un equipo que alteró radicalmente el flujo de trabajo de un producto
existente que tenía miles de clientes de pago. El equipo estaba tan emocionado por los
cambios que habían realizado que siguieron adelante con el lanzamiento sin alertar a nadie
más en la organización.Una hora después de la puesta en marcha del nuevo producto, la
vicepresidenta de servicio al cliente estaba en el escritorio de Jeff, furiosa y exigiendo
saber por qué no se le informó de este cambio. El problema era el siguiente: cuando los
clientes tienen problemas con el producto, piden ayuda. Los representantes del centro de
llamadas utilizan secuencias de comandos para solucionar problemas de los clientes y
ofrecer soluciones, excepto que no tenían una secuencia de comandos para este nuevo
producto. Porque no sabían que iba a cambiar.

Esta saludable rebanada de humilde pastel sirvió como una valiosa lección. Si desea que
sus partes interesadas, tanto las que lo administran como las que dependen de usted, se
mantengan fuera de su camino, asegúrese de que estén al tanto de sus planes y su
progreso.Mientras trabajaba en conjunto en nuestra agencia Neo, a nuestra colega Nicole
Rufuku se le ocurrió una herramienta notablemente simple y poderosa para hacer
precisamente esto: el Panel de Riesgos ( Figura 16-11 ).
Figura 16-11. El panel de riesgos

El Panel de riesgos no es más que un gráfico de tres columnas que puede crear en
PowerPoint, Excel o Google Docs.

• La primera columna enumera los principales riesgos pendientes asociados con su

iniciativa actual. Estas son cosas que son fundamentales para el éxito
del producto .
• La columna del medio tiene una escala de la gravedad de este riesgo y una
visualización codificada por colores de la tendencia de ese riesgo. ¿Es algo que
podría requerir una pequeña corrección? ¿O es existencial para el éxito del
producto? ¿Nuestro trabajo de descubrimiento nos dice que esto es cada vez más
posible o no tan malo como pensábamos?
• La tercera columna dice lo que estamos haciendo con respecto a ese riesgo.

Este tablero es un documento vivo que utiliza para comunicarse con sus partes interesadas
y clientes sobre el estado de su proyecto. Utilice este panel en sus reuniones de
planificación con su equipo. Úselo en sus demostraciones de sprint con sus partes
interesadas para ayudarlo a tomar decisiones importantes. Al hacerlo, está informando a
sus partes interesadas sobre:

• Cómo avanza el trabajo

• Lo que has aprendido hasta ahora
• ¿En qué riesgo te enfocarás a continuación?
• Resultados (la tendencia que tiene hacia su objetivo), no conjuntos de
características
• Departamentos dependientes (servicio al cliente, marketing, operaciones, etc.) y
su necesidad de estar al tanto de los próximos cambios que pueden afectarlos.
A menudo, habrá un riesgo en el tablero donde la tercera columna está vacía. Luego, una
parte interesada preguntará por qué no estamos haciendo nada al respecto. A veces, esto
es simplemente una cuestión de priorización. Pero a veces es posible que se bloquee el
progreso. Por lo tanto, una pregunta de las partes interesadas le brinda la oportunidad
perfecta para plantear cualquier desafío que pueda tener al hacer el trabajo de
descubrimiento, priorizarlo o obtener presupuesto o aprobación para hacerlo. Con el
Panel de riesgos, está contextualizando de manera efectiva el descubrimiento con impacto
comercial. El impacto empresarial tiende a resonar poderosamente con las partes
interesadas, lo que la convierte en una herramienta eficaz para impulsar una mejor
integración de su trabajo Lean UX con su proceso de entrega Agile.

Mapas de ruta basados en resultados

Uno de los mayores desafíos en Agile es planificar el trabajo en de forma lineal y
visual. Claro, hemos tenido "mapas de ruta" durante mucho tiempo, pero no hacen un
gran trabajo al representar la verdadera naturaleza del desarrollo de software. El
desarrollo de productos digitales no es lineal. Es iterativo. Construimos algunas
cosas. Los enviamos. Vemos cómo afectan el comportamiento del cliente. Los iteramos
y enviamos de nuevo.

El modelo de mapa de ruta lineal tradicional, uno en el que hay un punto de partida y un
punto final claro y específico de la función (casi siempre con una fecha fija), está
desactualizado. Refleja un modo de operar un negocio digital centrado en la
producción. En cambio, como hemos discutido a lo largo de este libro, las organizaciones
exitosas dirigidas por productos se enfocan en los resultados. Entonces, ¿cómo
construimos hojas de ruta de productos en un mundo de mejora continua, aprendizaje y
agilidad? ¿Y cómo puede este tipo de visualización garantizar que Lean UX se lleve a
cabo en nuestro proceso Agile? Utilizamos hojas de ruta basadas en resultados.

Así es como debería verse una hoja de ruta de productos ágiles ( Figura 16-12 ).
Figura 16-12. Una hoja de ruta de productos ágiles

Notará algunos componentes clave en este diagrama:

Temas estratégicos

Estos son los Estrategias de productos organizacionales establecidas por líderes

ejecutivos que apuntan a los equipos en una dirección específica. Estas pueden ser
cosas como "Expandir nuestra participación de mercado en Europa" o
"Aprovechar el tiempo infrautilizado que nuestra flota no transporta pasajeros
para entregar otros bienes y alimentos". Puede haber varios temas ejecutándose
en paralelo para una organización más grande.

Metas de OKR trimestrales

OKR, cuando bien hecho, utilice el comportamiento del cliente como métrica en
la parte de "resultados clave" de la ecuación. Estos objetivos de resultados
trimestrales son donde cada equipo se enfocará en un esfuerzo por ayudar a lograr
el tema estratégico. Este es el objetivo que los equipos se esfuerzan por lograr. Es
su definición de éxito y su definición real de hecho. Los equipos deben trabajar
junto con el liderazgo para garantizar que estén alineados y nivelados
correctamente.

Hipótesis de características / productos

Estas son las mejores conjeturas de cada equipo sobre cómo alcanzarán los
objetivos OKR de este trimestre. Mirando con un trimestre de anticipación, un
equipo puede hacer conjeturas sólidas y bien informadas sobre qué productos o
ideas de características creen que lograrán sus objetivos trimestrales. Mirando dos
trimestres por delante, esas conjeturas se vuelven menos seguras, por lo que los
equipos harán menos conjeturas y menos compromisos. Mirando tres y cuatro
trimestres, los equipos realmente no tienen idea de en qué estarán trabajando, por
lo que estas conjeturas son cada vez menos. Así es exactamente como debería
ser. Los equipos aprenderán en el próximo trimestre o dos qué tan bien
funcionaron sus ideas, qué mueve las agujas hacia adelante y cuáles deberían ser
sus próximas conjeturas. Las casillas para Q3 y Q4 se llenarán a medida que el
aprendizaje de Q1 y Q2 se sintetice y se actúe en consecuencia.

Visualizar el trabajo de esta manera pone inmediatamente la incertidumbre de desarrollo

de software al frente y al centro de la conversación. Cuando las partes interesadas
preguntan: "¿Cómo determinaremos si estas son las hipótesis correctas para trabajar ahora
y en el futuro?" la respuesta es Lean UX. Su equipo trabajará para incorporar el
aprendizaje en cada sprint para asegurarse de que siempre esté trabajando hacia el tema
estratégico y no pierda tiempo en iniciativas que no lo acercan. Combine eso con las
cadencias ágiles descritas anteriormente y tendrá una receta poderosa para brindar
experiencias valiosas a sus clientes.
Frecuencia de revisión

Cada equipo debe presentar este tipo de camino basado en resultados mapa para su
revisión al comienzo de un ciclo anual. Debe alinearse con los objetivos estratégicos que
el liderazgo ha establecido y asegurarse de que sus OKR utilicen métricas que permitan
alcanzar estos objetivos.

Si bien es responsabilidad del equipo exponer continuamente lo que están haciendo,

aprendiendo y decidiendo, los controles oficiales deben realizarse trimestralmente. Los
equipos se reúnen con los líderes para determinar qué tan bien se han orientado hacia sus
objetivos de resultados, lo que han aprendido durante el último trimestre y lo que planean
hacer en el próximo trimestre. Esta es una oportunidad perfecta para reafirmar la vigencia
de los objetivos del equipo en el futuro y realizar ajustes basados en nuevos aprendizajes,
condiciones del mercado o cualquier otro factor que pueda haber afectado la dirección de
la empresa.

Medir el progreso

Debería estar claro a estas alturas que el progreso en este tipo de camino map no se mide
en la cantidad de funciones que se han entregado o si se han entregado a tiempo. En
cambio, el progreso se mide en términos de qué tan bien hemos mejorado el
comportamiento del cliente. Si nuestras ideas no impulsaron el éxito del cliente, matamos
esas ideas y pasamos a otras nuevas. El aprendizaje impulsa ideas para futuras
acumulaciones trimestrales. También impulsa nuestra agilidad como equipo y
como empresa .

Estos mapas de carreteras son documentos vivos. No los arreglamos al comienzo de un

ciclo anual y los dejamos como si estuvieran grabados en piedra. Hay demasiada
incertidumbre y complejidad en la entrega de productos y servicios digitales. Las
organizaciones dirigidas por productos, aquellas que se centran en el éxito del cliente con
equipos empoderados, trabajan para asegurarse de que siempre apunten en la dirección
correcta. Esto significa ajustar los mapas de carreteras a medida que cambia la realidad
sobre el terreno. Las hojas de ruta basadas en resultados garantizan que los líderes y los
equipos sean transparentes entre sí, realistas sobre sus objetivos y, lo que es más
importante, realistas sobre cómo miden el éxito.

Lean UX y Agile en la empresa

Muchas de las tácticas cubiertas en este libro se centran en una equipo. Pero en el mundo
real, las grandes organizaciones tienen varios equipos de desarrollo de productos que
trabajan en paralelo. ¿Cómo se escala Lean UX cuando la cantidad de equipos aumenta a
decenas o incluso cientos de flujos de trabajo simultáneos?

Esta es una versión de la pregunta de escalamiento, que es en sí misma una pregunta en

curso en la comunidad Agile. Dado que los métodos Lean y Agile se han convertido en
las formas de trabajo predeterminadas, muchas personas se han centrado en esta
cuestión. Las grandes organizaciones tienen una necesidad legítima de coordinar la
actividad de varios equipos, y los procesos que adoptan la incertidumbre y adoptan
el aprendizaje de su camino a seguir presentan un desafío para la mayoría de los
métodos tradicionales de gestión de proyectos.

Hablemos del elefante en la sala: Scaled Agile Framework o SAFe.En el momento de

escribir este artículo, SAFe ha existido durante 10 años y, para muchas organizaciones
grandes, es la primera opción para implementar un enfoque de agilidad para toda la
organización. Si no está familiarizado con él, SAFe es un conjunto completo, detallado y
jerárquico de procesos, diagramas y vocabulario que están diseñados para aumentar la
agilidad de las grandes organizaciones. Funciona de arriba hacia abajo para dividir y
delegar el trabajo a "trenes de lanzamiento ágiles" que siguen un horario de lanzamiento
rígido. Desafortunadamente, estos procesos carecen en gran medida de comentarios o
aprendizaje de los usuarios.

Es posible que se haya sorprendido tanto como a nosotros al saber que la versión 4.5 del
marco SAFe incluía Lean UX. Debido a esto, recibimos muchas preguntas sobre cómo
hacer Lean UX en una empresa que ha implementado SAFe. La respuesta corta es esta:
no puedes. SAFe está diseñado para la producción, no para el descubrimiento. Está
optimizado para garantizar un flujo continuo de resultados y minimizar los requisitos de
cambio de los ejecutivos. Crea una rigidez dentro del proceso de desarrollo de software
que da como resultado algo que no puede, de ninguna manera, describirse como ágil.

SAFE NO ES ÁGIL

Desde el Scaled Agile Framework (SAFe para abreviar) adoptado Lean UX en la versión
4.5, hemos recibido un flujo constante de preguntas entrantes sobre cómo, exactamente,
se supone que estos dos métodos funcionan bien juntos.

La respuesta corta es que no tenemos idea.

La respuesta un poco más larga es que todos los principios que hemos incorporado en
Lean UX no parecen existir en SAFe.

El aprendizaje y la mejora continuos, el enfoque en el cliente, la humildad, la colaboración

interfuncional, la toma de decisiones basada en la evidencia, la experimentación, el diseño
y la corrección del curso, por nombrar algunos, están visiblemente ausentes en la
conversación de SAFe. En cambio, las organizaciones que adoptan esta forma de trabajo
se centran en estructuras de equipo rígidas, rituales y eventos estrictos y una distribución
desigual de los requisitos de cambio de comportamiento dependiendo de qué tan alto se
sienta uno en la organización.

En resumen, SAFe no es ágil.

Dado el intenso régimen de entrenamiento que los equipos deben atravesar para obtener
la “certificación SAFe”, no es de extrañar que se resistan al cambio. Han sido capacitados
para trabajar de una manera muy específica, una manera enfocada únicamente en la
entrega predecible, no en el aprendizaje, no en la corrección del curso y, ciertamente, no
en la agilidad. Las actividades que hacen que los equipos sean verdaderamente ágiles
requieren flexibilidad en la planificación. Requieren alineación con el éxito del cliente,
no un conjunto predeterminado de características. Requieren un proceso de
descubrimiento continuo que inevitablemente conduce a correcciones de rumbo no
planificadas. Estas correcciones "descarrilarían" un tren de liberación en poco tiempo.

Las grandes organizaciones que buscan agilidad se dan cuenta de la incertidumbre que la
acompaña y se aferran a la familiaridad de los procesos en cascada. SAFe da la ilusión de
"adoptar ágil" al tiempo que permite que los procesos de gestión familiares permanezcan
intactos. En un mundo de cambios rápidos y continuos, patrones de consumo de los
consumidores en evolución, inestabilidad geopolítica y avances tecnológicos
exponenciales, esta forma de trabajar es insostenible.

Si trabaja en una organización grande que ha adoptado o está en proceso de implementar

SAFe, pregúntese qué ha cambiado durante esta transición. ¿Estás más cerca de tus
clientes? ¿Cuánto tiempo se tarda en saber si ha entregado algo de valor? Aún mejor,
¿cómo mides el "valor"? Pregúntese qué tan fácil sería hacer pivotar una iniciativa basada
en un nuevo descubrimiento. Luego, compare esas respuestas con cómo eran las cosas
antes de comenzar a usar términos como "planificación de salas grandes", "PI" y
"ingeniero de trenes de lanzamiento".

Escalar cualquier forma de trabajar en una gran organización es complicado y

desigual. Intentar aplicar un proceso general a toda la empresa, un proceso que se centra
estrictamente en la entrega en lugar del descubrimiento continuo y la corrección del
rumbo, solo endurece las formas tradicionales de trabajo. SAFe es convincente porque
parece ofrecer una receta única para la agilidad a escala. En realidad, premia la
previsibilidad, la conformidad y el cumplimiento, al tiempo que brinda a los ejecutivos
una cobertura para la pregunta "¿Cómo nos volvemos más ágiles?"

Una discusión completa sobre cómo crear una organización verdaderamente ágil y
ajustada está más allá del alcance de este libro.5 Y, sinceramente, es un problema difícil
con pocas respuestas fáciles. Requiere liderazgo para repensar radicalmente la forma en
que establece la estrategia, forma equipos y planifica y asigna el trabajo. En esencia, las
organizaciones necesitan reducir la cantidad de andamios que implementan y permitir que
los equipos encuentren orgánicamente formas de usar los valores, principios y métodos
básicos de Agile para equipos pequeños para construir una cadencia de trabajo productiva
y luego escalarlos específicos de la organización. enfoques en pequeños incrementos.

Dicho esto, existen algunas técnicas que pueden ayudar a Lean UX a escalar en entornos
empresariales ágiles e incluso aprovechar esa escala. A continuación, presentamos
algunos problemas que suelen surgir y formas de solucionarlos.

Problema: los proyectos crecen, se les asignan más equipos. ¿Cómo se asegura de que
todos los equipos estén alineados con la misma visión y no optimicen localmente?

Enfoque de solución: el concepto de gestión con resultados se aplica tanto a un conjunto

de equipos como a los individuales. Para asegurarse de que todos los equipos que trabajan
en el mismo proyecto tengan una visión compartida, asígneles la misma métrica de éxito,
expresada como resultado. Trabajando juntos, pueden definir los indicadores principales
que impulsan esa métrica y dividir esas métricas principales entre los equipos del
proyecto. Pero no se debe permitir que los equipos se centren en las métricas principales
excluyendo el resultado más amplio: todo el conjunto de equipos tiene éxito solo si
alcanzan el resultado general juntos.
Trabajar juntos de esta manera reduce el riesgo de optimización local sin tener en cuenta
los impactos posteriores de esa optimización. Por ejemplo, si el equipo de marketing está
trabajando para alcanzar sus objetivos de resultados de adquisición, pero sobreutiliza el
correo electrónico para lograr ese objetivo, puede dañar el objetivo de retención del
equipo de producto. Si ambos equipos tuvieran los mismos objetivos de resultados, una
combinación de adquisición y retención, trabajarían juntos para aprender a equilibrar sus
esfuerzos y productos para tener éxito.

Problema: ¿Cómo se asegura de que los equipos compartan lo que están aprendiendo y
minimicen el esfuerzo duplicado para aprender las mismas cosas?

Enfoque de la solución: aunque no hay una solución milagrosa para resolver este
problema, las prácticas exitosas que hemos visto incluyen una herramienta central de
gestión del conocimiento (como una wiki), reuniones periódicas de liderazgo de equipo
(como un Scrum de Scrums) y herramientas de comunicación abierta. que se centran en
la investigación (como un canal dedicado en Slack o su herramienta de chat interna). Los
elementos de la cultura del estudio, como las sesiones regulares de crítica entre equipos,
también pueden ayudar.

Problema: las dependencias entre equipos pueden hacer que el progreso sea
lento. ¿Cómo se mantiene un ritmo regular de aprendizaje y ejecución en un entorno de
equipos múltiples?

Enfoque de solución: cree equipos "full-stack" autosuficientes. Los equipos de pila

completa tienen todas las capacidades necesarias para hacer su trabajo en el equipo. Esto
no significa que necesiten una persona de cada departamento, solo que hay alguien en el
equipo que puede hacer una o más de las cosas que el equipo podría necesitar. Las
disciplinas específicas del equipo (diseñadores, personas de contenido, desarrolladores de
frontend, desarrolladores de backend, gerentes de producto) se coordinan entre sí en
reuniones de disciplinas específicas para garantizar que estén al día en su práctica, pero
el trabajo se lleva a cabo localmente.

Terminando
Este capítulo analizó detalladamente cómo se adapta Lean UX en un proceso
ágil. Además, analizamos cómo la colaboración multifuncional permite que un equipo
avance a un ritmo rápido y cómo manejar a las partes interesadas y gerentes que siempre
quieren saber qué está sucediendo. Discutimos por qué es fundamental que todos
participen en todas las actividades y cómo el modelo de sprint escalonado, una vez
considerado el camino hacia la verdadera agilidad, formó las raíces de Agile de doble vía,
que ahora es el nuevo modelo objetivo para la mayoría de los equipos. También cubrimos,
en detalle, cómo los artefactos y eventos de scrum funcionan a su favor para aumentar su
velocidad de aprendizaje.

1“Manifiesto para el desarrollo de software ágil”, consultado el 18 de junio de

2021, http://agilemanifesto.org .
2Desirée Sy, “Adaptación de las investigaciones de usabilidad para un diseño ágil
centrado en el usuario”, Revista de estudios de usabilidad 2, no. 3 (Mayo de 2007): 112-
132, https://oreil.ly/Bhxq1 .

3JaredM. Spool, “Fast Path to a Great UX - Increased Exposure Hours”, Center Center
UIE, 30 de marzo de 2011, https://oreil.ly/cvfcF .

4Incluso podría utilizar un "sprint de diseño" al estilo de Google aquí, un nombre confuso
en este contexto. En este caso, no estamos abogando por pasar todo un sprint haciendo
diseño. En su lugar, estamos abogando por el proceso denominado "sprint de diseño", que
describimos en el Capítulo 14 .

5Hemos escrito una descripción general de alto nivel sobre este tema en nuestro
libro Sense & Respond (Harvard Business Review Press,
2017). (Ver https://senseandrespond.co .)
Parte IV. Lean UX en su organización
Acerca de la Parte IV
Integrar el diseño en Agile nunca es fácil. A veces causa mucho dolor y angustia.Jeff
aprendió eso de primera mano cuando estaba en TheLadders. Después de pasar algún
tiempo tratando de integrar el trabajo de UX con un proceso ágil, Jeff se sentía bastante
bien, hasta que una mañana su equipo de UX entregó el diagrama a continuación ( Figura
IV-1 ). Este diagrama visualizó todos los desafíos que enfrentaba el equipo mientras
intentaban integrar su práctica en Agile. Inicialmente sirvió como una gran rebanada de
humilde pastel. Sin embargo, en última instancia, proporcionó el comienzo de
conversaciones que ayudaron a Jeff, a su equipo de UX y al resto del personal de
desarrollo de productos de TheLadders a construir una práctica integrada y colaborativa.
Gráfico IV-1. El equipo de UX de TheLadders expresó sus sentimientos sobre nuestros esfuerzos
de integración Agile / UX

En los años transcurridos desde que se creó este diagrama, hemos tenido la suerte de
trabajar con muchas empresas en este desafío. Hemos trabajado con empresas que
abarcan una amplia gama de industrias, tamaños de empresas y culturas. Hemos ayudado
a las organizaciones de medios a descubrir nuevas formas de entregar y monetizar su
contenido. Hemos creado nuevas herramientas de venta para dispositivos móviles para un
fabricante de muebles comerciales. Hemos consultado con minoristas de moda, empresas
de servicios automotrices y grandes bancos para ayudarlos a desarrollar prácticas Lean
UX. Hemos trabajado con organizaciones sin fines de lucro para crear nuevas ofertas de
servicios. Y hemos entrenado a innumerables equipos.

Cada uno de estos proyectos nos brindó un poco más de información sobre cómo funciona
Lean UX en ese entorno. Usamos esa información para hacer que cada proyecto posterior
fuera mucho más exitoso. Hemos acumulado un conjunto de conocimientos durante los
últimos cinco años que nos ha dado una idea clara de lo que debe suceder, a nivel de
equipo y de organización, para que Lean UX tenga éxito. Ese es el enfoque de la Sección
IV.

En el Capítulo 17, Realización de cambios organizativos , profundizaremos en los

cambios organizativos específicos que deben realizarse para respaldar esta forma de
trabajo. No son solo los desarrolladores y diseñadores de software los que necesitan
encontrar una manera de trabajar juntos. Todo su motor de desarrollo de productos tendrá
que cambiar si desea crear una organización verdaderamente ágil.

En el Capítulo 18, Lean UX en una agencia , discutiremos los problemas que son
exclusivos de la implementación de Lean UX en el contexto de una agencia. Habiendo
vivido este desafío nosotros mismos y trabajado para capacitar a cualquier número de
empresas de diseño y desarrollo de productos, hemos llegado a comprender algunos de
los desafíos aquí. Compartiremos algunas de las cosas clave que deberá considerar para
que Lean UX tenga éxito en este tipo de negocio.
Capítulo 17. Realización de cambios
organizativos
En béisbol, no sabes nada.

Yogi Berra

En la Parte I de este libro, discutimos los principios detrás de Lean UX.Esperamos que
comprenda de esa sección que Lean UX es una forma de pensar. En la Parte II ,
discutimos algunos de los métodos clave de Lean UX, porque Lean UX también es un
proceso. A medida que trabajamos con clientes y enseñamos estos métodos a los equipos,
queda claro que Lean UX también es un método operativo y de gestión. Por esta razón,
deberá realizar algunos cambios en su organización para obtener el mayor beneficio de
trabajar de esta manera.

Los cambios organizacionales no son fáciles, pero no son opcionales. El mundo ha

cambiado: nuestras organizaciones deben cambiar con él. Cualquier negocio de escala (o
cualquier negocio que busque escalar) está, nos guste o no, en el negocio del
software. Independientemente de la industria en la que opere su empresa, el software se
ha convertido en algo fundamental para ofrecer su producto o servicio.

Esto es tanto empoderador como amenazador. La capacidad de llegar a los mercados

globales, escalar las operaciones para satisfacer la creciente demanda y crear una
conversación continua con sus clientes nunca ha sido tan fácil. Este poder también es un
arma de doble filo: ofrece las mismas oportunidades a competidores más pequeños que
nunca hubieran podido competir antes de la amplia adopción del software. Esto hace que
la necesidad de adoptar Lean UX sea aún más urgente.

Muchas organizaciones han llegado a esta conclusión y, en respuesta, han intentado

ampliar sus equipos de desarrollo de productos. Mientras lo han hecho, muchos han
utilizado los ritmos centrales de las técnicas de desarrollo de software ágiles para
operacionalizar el desarrollo de productos de software. Desafortunadamente, muchos de
estos enfoques son ágiles solo de nombre. No adoptan los valores clave de Agile, que
incluyen la colaboración, la transparencia y el aprendizaje continuo. Estos enfoques
operativos maximizan la velocidad de entrega, pero obligan a los equipos de software,
incluidos los diseñadores de estos equipos, a entrar en modo de producción. Como
resultado, se pierde gran parte del valor del diseño.

Lean UX es una forma de romper con el diseño como producción y darse cuenta del valor
total del diseño en equipos multifuncionales. Le permite utilizar el poder del software
para crear un ciclo de mejora continua que le permita a su empresa mantenerse por delante
de sus competidores. Es este circuito el que impulsa la agilidad organizativa real y permite
que su empresa reaccione a los cambios en el mercado a velocidades nunca antes posibles.

DESIGNOPS Y LEAN UX

Dado que las grandes organizaciones han adoptado el diseño en contexto operativo de los
equipos de desarrollo de productos, hemos visto el surgimiento de un movimiento
llamado DesignOps. DesignOps tiene como objetivo simplemente la operacionalización
del diseño a escala. Es una forma de pensar y gestionar las operaciones de diseño dentro
de las grandes organizaciones. Esto significa que el equipo DesignOps de su organización
debe convertirse en un actor clave en cualquier esfuerzo por adoptar Lean UX.

Una nota importante aquí: DesignOps puede ser una fuerza para adoptar nuevas formas
de trabajar, pero también puede ser una fuerza para adoptar formas de trabajo
heredadas. Muchas de las formas tradicionales de trabajo que ha desarrollado la
comunidad del diseño son maravillosas, están llenas de sabiduría y deben ser
respetadas. Pero algunas formas de trabajar son muy específicas del trabajo de diseño que
hicimos con tecnologías y modelos comerciales más antiguos.BDUF (Big Design Up
Front) y el trabajo basado en entregables son solo dos ejemplos de métodos de diseño
tradicionales que ya no sirven a los mejores intereses de los diseñadores que buscan el
máximo impacto en los equipos ágiles. Mientras trabaja para forjar un movimiento
liderado por DesignOps en su organización, tenga cuidado con las soluciones “los
diseñadores siempre lo han hecho de esta manera”, que no adoptan el verdadero espíritu
de Agile y Lean UX.

Los turnos
Cuando capacitamos a los equipos, a veces preguntan: "¿Cómo podemos poner en
práctica estos métodos aquí?" Y en este punto, siempre dudamos un poco. Aunque
estamos seguros de que la mayoría de las organizaciones pueden resolver estos
problemas, también somos conscientes de que cada organización es diferente. Encontrar
la solución adecuada requiere mucho trabajo cercano y colaboración con sus colegas y
ejecutivos.

Para prepararlo para ese trabajo, usaremos este capítulo para compartir algunos de los
cambios que las organizaciones deben realizar para adoptar Lean UX. No le
diremos cómo hacer esos cambios; Ese es tu trabajo. Pero esperamos que esta discusión
le ayude a estudiar el panorama para encontrar las áreas que va a querer abordar.

Cambio de cultura

Al implementar Lean UX, considere estas dimensiones de la cultura:

• Se humilde.
• Adopte nuevas habilidades.
• Cree espacios de trabajo abiertos y colaborativos.
• Sin héroes.
• Enamórate del problema, no de la solución.
• Desarrollar la cultura de la agencia.
• Sea realista sobre su entorno.

Organización cambiante del equipo

Para implementar Lean UX, también deberá repensar la forma en que organiza los
equipos:
 • Piense en las competencias sobre los roles.
• Cree equipos multifuncionales.
• Crea pequeños equipos.
• Trabaja con equipos distribuidos.
• Genere flexibilidad en las relaciones con proveedores externos.

Proceso de cambio

Finalmente, sus procesos de desarrollo de productos también cambiarán:

• Planifique el trabajo utilizando resultados, no productos.

• Tenga cuidado con los BDUF que se cuelan en entornos ágiles.
• Adopte la velocidad primero, la estética después,
• Aborde la deuda de UX.
• Repensar las prácticas de documentación.
• Gestione hacia arriba y hacia fuera.

Turno: Sea humilde

Imagina por un momento que trabajas en una línea de montaje. que hace coches. El estado
final de su producto está bien definido de antemano. El costo de producir ese producto es
claro. El proceso para crearlo se ha optimizado y las formas en que los clientes usarán ese
automóvil, basadas en más de cien años de observación, también son claras. En
situaciones como esta, la atención se centra en la calidad, la eficiencia y el control de
costos.

No estamos construyendo autos.

Nuestro medio es el software y nuestros productos y servicios son complejos e

impredecibles. No tienen un estado final. Podemos seguir diseñando, construyendo,
operando y optimizando nuestros productos digitales siempre que tenga sentido
económico hacerlo. Lo más desconcertante es que nuestros clientes pueden usar nuestros
servicios digitales de formas que nunca imaginamos. En muchos casos, las mejores
características de un sistema surgen con el tiempo a medida que las personas lo
utilizan. (El hashtag de Twitter es un gran ejemplo de esto: los usuarios inventaron esta
función, y luego Twitter agregó soporte para ella después del hecho). Con tantas
incógnitas, hay una cantidad limitada de confianza que podemos tener en el alcance, la
hoja de ruta, la implementación, y éxito de nuestro producto. La buena noticia es que
gracias al auge de los movimientos Agile y DevOps, podemos alejarnos de los métodos
de línea de montaje de generaciones pasadas y adoptar métodos de producción
continua. Cuando combinamos esa capacidad con Lean UX, obtenemos la capacidad de
aprender muy rápidamente qué tan válidas o inválidas son nuestras ideas.

Para aprovechar al máximo estas nuevas capacidades, su organización debe adoptar la

humildad. Su organización debe aceptar que, frente a toda esta complejidad e
incertidumbre, simplemente no podemos predecir la forma exacta que nuestro servicio
tendrá que tomar para tener éxito. Esta no es una abdicación de la visión.

En cambio, requiere una opinión firme sobre la forma que debe tomar el sistema, junto
con la voluntad de cambiar de rumbo si la evidencia del mercado revela que la visión
inicial era incorrecta. Adoptar esta mentalidad hace que sea seguro para los equipos
experimentar, fallar y aprender. Es solo a través de este proceso de prueba y error que
Lean UX puede prosperar. Si la organización no deja espacio para la corrección del curso,
el aprendizaje continuo que promueve Lean UX se verá, en el mejor de los casos, como
una distracción y, en el peor, como una pérdida de tiempo.

Cambio: Adopte nuevas habilidades

Muchas empresas recurren a los diseñadores para obtener los métodos más tácticos
y capacidades tradicionales: wireframing, especificación, diseño de UI, etc. Limitan su
participación en un proyecto a la “fase de diseño” de cualquier proceso que la empresa
esté utilizando. Conectar a los diseñadores a estos flujos de trabajo existentes limita su
eficacia al limitar el alcance de su trabajo, lo que tiene el efecto secundario de reforzar un
modelo de equipo aislado.

El éxito de un equipo colaborativo exige más. Aunque los equipos aún necesitan
habilidades básicas de UX, los diseñadores deben agregar la facilitación como una de sus
competencias básicas. Esto requiere dos cambios significativos en la forma en que hemos
trabajado hasta la fecha:

Los diseñadores deben abrir el proceso de diseño

El equipo, no el individuo, debe ser propietario del producto. diseño. En lugar de

esconderse detrás de un monitor durante días seguidos, los diseñadores deben
incorporar a sus equipos al proceso de diseño, buscar su opinión y desarrollar esa
información en el diseño. Si lo hace, comenzará a romper los silos y promoverá una
conversación más multifuncional. Para hacer esto, los diseñadores deben emplear una
amplia gama de tácticas colaborativas y deben ser creativos y profundamente prácticos,
buscando tácticas que satisfagan las necesidades del equipo, hagan avanzar la
conversación y respeten las realidades de la capacidad del equipo y el cronograma del
proyecto.

Los diseñadores deben asumir un papel de liderazgo en su equipo

Sus colegas están acostumbrados a criticar su trabajo de diseño. Lo que no están

acostumbrados a hacer es co-crear ese diseño contigo. El liderazgo de diseño y la
facilitación en actividades de lluvia de ideas grupales como Design Studio pueden crear
foros seguros para que todo el equipo conceptualice su producto y muestre las
capacidades de síntesis del equipo de diseño.

Turno: crear espacios de trabajo abiertos y colaborativos

Rompe las barreras físicas que impiden la colaboración. Ubique sus equipos y cree
espacios de trabajo para ellos que mantengan a todos visibles y accesibles. Haga espacio
para que su equipo coloque su trabajo en las paredes y otras superficies de trabajo. Nada
es más efectivo que acercarse a un colega, mostrarle un trabajo, discutir, dibujar,
intercambiar ideas, comprender las expresiones faciales y el lenguaje corporal, y llegar a
una resolución sobre un tema espinoso.
Cuando coloque personas, cree funciones cruzadas agrupaciones. Eso significa sacarlos
de las comodidades del "escondite" de su disciplina. Es sorprendente cómo incluso una
pared de cubículo puede obstaculizar la conversación entre colegas.

Los espacios de trabajo abiertos permiten que los miembros del equipo se vean y se
comuniquen fácilmente cuando surgen preguntas. Algunos equipos han ido tan lejos
como para poner sus escritorios sobre ruedas para poder reubicarse más cerca de los
miembros del equipo con los que colaboran ese día en particular. Aumente estos espacios
abiertos con salas de reuniones donde los equipos puedan intercambiar ideas. Pizarras
blancas del tamaño de una pared o simplemente pintar las paredes con pintura para pizarra
blanca proporciona muchos pies cuadrados de espacio para la discusión. En resumen,
elimine los obstáculos físicos entre los miembros de su equipo. Es posible que a sus
planificadores espaciales no les guste al principio, pero sus partes interesadas se lo
agradecerán.

A medida que los equipos distribuidos y las situaciones de trabajo "híbridas" se

vuelven más común, recuerde trasladar estas cualidades a estas situaciones
también. Asegúrese de que la colaboración y el intercambio sean fáciles y que sus equipos
tengan las herramientas que los hacen más exitosos en lugar de las que TI ha elegido para
ellos.

Turno: Sin héroes

A medida que continuamos trabajando con una variedad más amplia de equipos, todavía
hay muchos diseñadores que se resisten a Lean UX. ¿Una razón? Muchos diseñadores
quieren ser héroes.

En un entorno en el que los diseñadores crean hermosos productos, pueden mantener un

aura heroica. Los requisitos van en un extremo de la máquina de diseño, y las obras de
arte hermosas se abren paso. La gente dice "ooh" y "aah" cuando se revela el diseño. Los
diseñadores han prosperado con estas reacciones (tanto informales como formalizadas
como premios) durante muchos años.

No estamos sugiriendo que todos estos diseños sean superficiales. Educación,

capacitación formal, experiencia y una buena dosis de inspiración se encuentran en cada
documento de Photoshop que crean los diseñadores y, a menudo, los resultados son
inteligentes, bien considerados y valiosos. Sin embargo, esos resultados brillantes pueden
generar malas decisiones corporativas; pueden sesgar el juicio específicamente porque su
belleza es muy persuasiva. Los premios pueden basarse en la estética de los diseños (en
lugar del resultado que crea el diseño). Las decisiones de contratación se toman en
función de la nitidez de los wireframes, y la compensación puede depender de las marcas
asociadas a cada una de las piezas de la cartera.

El resultado de esto es que los creadores de estos documentos son anunciados como
líderes de opinión y elevados a la cima del campo del diseño de experiencias. Se les
reconoce como las personas a las que se debe acudir cuando el problema debe resolverse
rápidamente. Pero, ¿puede un solo héroe del diseño ser responsable del éxito de la
experiencia del usuario, el negocio y el equipo? ¿Debería considerarse a una persona
como la única razón del éxito de una iniciativa?
En resumen, no.

Para que Lean UX tenga éxito en su organización, todos los tipos de contribuyentes,
diseñadores y no diseñadores, deben colaborar ampliamente. Este puede ser un cambio
difícil para algunos, especialmente para diseñadores visuales con experiencia en agencias
interactivas. En esos contextos, el director creativo es intocable. En Lean UX, lo único
intocable es el conocimiento del cliente.

Lean UX literalmente no tiene tiempo para héroes. Todo el concepto de diseño como
hipótesis destrona inmediatamente las nociones de heroísmo; como diseñador, debe
esperar que muchas de sus ideas fracasen en la prueba. Los héroes no admiten el
fracaso. Pero los diseñadores de Lean UX lo adoptan como parte del proceso.

Cambio: Enamórate del problema, no de la solución

Lean UX nos hace hacer preguntas difíciles sobre la naturaleza de calidad en nuestro
trabajo de diseño.

Si eres un diseñador que lee esto, probablemente te hayas hecho una pregunta que a
menudo surge cuando la velocidad triunfa sobre la perfección estética:

Si mi trabajo ahora es presentar conceptos e ideas en lugar de un trabajo terminado,

todo lo que produzca se sentirá a medias. Siento que "voy por el bronce". Nada de lo que
produzca se terminará jamás. Nada es indicativo del tipo de productos que soy capaz de
diseñar. ¿Cómo puedo sentir orgullo y propiedad por diseños que simplemente no están
hechos?

Para algunos diseñadores, Lean UX amenaza lo que valoran en su trabajo y pone en riesgo
su cartera. Incluso podría sentir que amenaza su futura empleabilidad. Estas emociones
se basan en lo que muchos gerentes de contratación han valorado hasta la fecha: productos
atractivos (es decir, soluciones). Los bocetos, la "versión uno" de un proyecto y otros
artefactos de baja fidelidad no son la creación de un "portafolio excelente". Al darse
cuenta de que las soluciones de software continúan evolucionando con el tiempo, todo
eso ahora está cambiando.

Aunque su organización debe seguir valorando la estética, el pulido y la atención al

detalle, otras dimensiones del diseño son igualmente importantes. La capacidad de
comprender el contexto de un problema empresarial, pensar rápido y desarrollar un
entendimiento compartido necesita obtener un ascenso. Los diseñadores pueden
demostrar sus habilidades de resolución de problemas ilustrando los caminos que tomaron
para pasar de la idea al aprendizaje validado a la experiencia. Al hacerlo, demostrarán su
gran valor como diseñadores. Las organizaciones que buscan y recompensan a los
solucionadores de problemas atraerán y se sentirán atraídas por estos diseñadores.

Cambio: evolucionar la cultura de la agencia

Aplicar Lean UX en una agencia digital no es un desafío menor. La mayoría de las

agencias tienen un modelo de negocio que entra en conflicto con Lean UX. El modelo de
negocio tradicional de la agencia es simple: los clientes pagan por los entregables
(diseños, especificaciones, código, presentaciones de PowerPoint), no por
resultados. Pero la cultura de la agencia también es un gran obstáculo. La cultura del
diseño de héroes es fuerte en lugares que elevan a las personas a puestos como director
creativo ejecutivo. La colaboración interdisciplinaria también puede resultar difícil en las
grandes agencias, donde la necesidad de mantener una alta utilización ha llevado a
procesos que fomentan los silos funcionales. Estos, a su vez, conducen a "fases del
proyecto" que fomentan el trabajo centrado en los entregables.

Quizás el obstáculo más desafiante es la expectativa del cliente de "arrojarlo por la pared"
a la agencia y luego ver los resultados cuando esté listo. La colaboración entre el cliente
y la agencia en estas situaciones puede limitarse a una crítica desinformada e
improductiva que se basa en prejuicios personales, política y disimulo.

Para que Lean UX funcione en una agencia, todos los involucrados en un compromiso
deben enfocarse en maximizar dos factores: aumentar la colaboración entre el cliente y la
agencia, y trabajar para cambiar el enfoque de los productos a los resultados.

Algunas agencias están tratando de enfocarse en los resultados experimentando con un

alejamiento de los contratos de alcance fijo y basados en entregables. En cambio, sus
compromisos se basan en acuerdos simples de tiempo y materiales o, de manera más
radical, en contratos basados en resultados. En cualquier caso, los equipos se vuelven más
libres para pasar su tiempo iterando hacia una meta. Los clientes renuncian a la ilusión de
control que ofrece un contrato basado en entregables, pero obtienen la libertad de buscar
soluciones significativas y de alta calidad que se definen en términos de resultados, no de
listas de características.

Para aumentar la colaboración, las agencias pueden intentar derribar los muros que las
separan de sus clientes. Los clientes pueden participar en el proceso antes y con mayor
frecuencia. Los registros se pueden construir en torno a hitos menos formales. Y se
pueden organizar sesiones de trabajo colaborativo para que tanto la agencia como el
cliente se beneficien de la información adicional, los comentarios y la colaboración entre
ellos.

No son transformaciones fáciles, ni para la agencia ni para el cliente que las contrata, pero
es el modelo bajo el cual se construyen los mejores productos.

Una nota rápida sobre los socios para el desarrollo. En las relaciones con agencias, los
equipos de desarrollo de software (ya seaen la agencia, en el cliente o trabajando como
un tercero) a menudo se tratan como extraños y, a menudo, se incorporan al final de una
fase de diseño. Es imperativo que cambie esto: los socios para el desarrollo deben
participar a lo largo de la vida del proyecto, y no simplemente como observadores
pasivos. En su lugar, debe intentar que el desarrollo de software comience lo antes
posible. Nuevamente, está buscando crear una colaboración profunda y significativa con
todo el equipo del proyecto, y para hacerlo, debe trabajar codo con codo con los
desarrolladores.

Turno: Sea realista sobre su entorno

El cambio da miedo. El enfoque Lean UX trae consigo muchos cambios.Esto puede

resultar especialmente desconcertante para los gerentes que han estado en sus puestos
durante un tiempo y se sienten cómodos en sus funciones actuales. Algunos gerentes
pueden verse amenazados por propuestas de trabajar de una manera nueva, lo que podría
terminar teniendo consecuencias negativas para usted. En estas situaciones, intente pedir
perdón en lugar de permiso. Pruebe algunas ideas y demuestre su valor con un éxito
cuantificable. Ya sea que haya ahorrado tiempo y dinero en el proyecto o haya realizado
una actualización más exitosa que nunca, estos logros pueden ayudarlo a defender su
caso. Si su gerente aún no ve el valor de trabajar de esta manera y usted cree que su
organización está progresando por un camino de “diseño ciego” continuo, tal vez sea el
momento de considerar un empleo alternativo.

Cambio: Piense en las competencias sobre los roles

En la mayoría de las empresas, el trabajo que realiza está determinado por su puesto de
trabajo. Ese título de trabajo viene con una descripción del trabajo. Con demasiada
frecuencia, las personas en las organizaciones desalientan a otros a trabajar fuera de los
límites de sus descripciones de trabajo (por ejemplo, "No eres un desarrollador, ¿qué
puedes saber sobre JavaScript?"). Este enfoque es profundamente anticollaborativo y deja
sin utilizar el conjunto completo de habilidades, talentos y competencias de las personas.

Desalentar las aportaciones multifuncionales fomenta los silos organizativos. Cuanto más
discreto es el trabajo de una persona, más fácil se vuelve retirarse a los confines seguros
de esa disciplina. Como resultado, la conversación entre disciplinas se desvanece y crece
la desconfianza, los señalamientos con el dedo y el comportamiento CYA ("cúbrete el
culo").

Los silos son la muerte de los equipos colaborativos.

Para que Lean UX tenga éxito, su organización debe adoptar un mantra de "competencias
sobre roles". Cada miembro del equipo posee una competencia central (diseño, desarrollo
de software, investigación, etc.) y debe cumplir con ese conjunto de habilidades. Sin
embargo, los miembros también pueden poseer competencias secundarias que hacen que
el equipo trabaje de manera más eficiente.

Permita que sus colegas contribuyan a cualquier disciplina en la que tengan experiencia
e interés. Descubrirá que crea un equipo más comprometido que puede completar las
tareas de manera más eficiente. También encontrará que crea camaradería entre los títulos
de trabajo, ya que las personas con diferentes disciplinas muestran interés en lo que están
haciendo sus colegas. Los equipos que disfrutan trabajando juntos producen un mejor
trabajo.

Turno: crear equipos multifuncionales

Para muchos equipos, la colaboración es una actividad de una sola disciplina. Los
desarrolladores resuelven problemas con otros desarrolladores mientras los diseñadores
se sientan en bolsas de frijoles, encienden las lámparas de lava e "idean" con sus hermanos
de cuello alto negro. (Bromeamos.) (Bueno ... solo un poco. Nos encantan los
diseñadores).

Las ideas que nacen de las colaboraciones de una sola disciplina tienen una sola
faceta. No reflejan la perspectiva más amplia del equipo, que puede iluminar una gama
más amplia de necesidades, oportunidades, riesgos y soluciones. Peor aún, trabajar de
esta manera requiere que equipos basados en la disciplina expliquen su trabajo. Con
demasiada frecuencia, el resultado es una gran dependencia de la documentación
detallada y una desaceleración en el ritmo de aprendizaje del equipo en general.

Lean UX requiere colaboración multifuncional. Al crear interacción entre gerentes de

producto, desarrolladores, ingenieros de control de calidad, diseñadores y especialistas en
marketing, pone a todos en la misma página. Igual de importante: pones a todos al mismo
nivel. Ninguna disciplina individual dicta a la otra. Todos están trabajando hacia un
objetivo común. Permita que sus diseñadores asistan a "reuniones de desarrolladores" y
viceversa. De hecho, solo tenga reuniones de equipo.

Sabemos lo importante que es la colaboración multifuncional desde hace mucho

tiempo.El estudio de Robert Dailey de finales de la década de 1970 llamado "El papel de
las características del equipo y de la tarea en la productividad y la resolución colaborativa
de problemas del equipo de I + D" encontró un vínculo entre la productividad de
resolución de problemas de un equipo y lo que él llamó "cuatro predictores", que incluían
"certeza de la tarea". , interdependencia de tareas, tamaño del equipo y cohesión del
equipo ". 1

Mantenga a su equipo cohesionado rompiendo los límites basados en la disciplina.

Turno: crear equipos pequeños

Los grupos más grandes de personas son menos eficientes que los más pequeños. Esto
tiene sentido intuitivo. Pero menos obvio es esto: un equipo más pequeño debe trabajar
en problemas más pequeños. Este pequeño tamaño facilita el mantenimiento de la
disciplina necesaria para producir productos mínimos viables (MVP).Divida sus grandes
equipos en lo que el fundador de Amazon, Jeff Bezos, llamó "equipos de dos pizzas". Si
el equipo necesita más de dos pizzas para hacer una comida, es demasiado grande.

Si la tarea es grande, divídala en trabajos relacionados que varios equipos pequeños

puedan manejar simultáneamente. Alinee esos equipos con un único resultado para
lograr. De esta manera, todos ellos están trabajando hacia el mismo objetivo. Esto obliga
a estos pequeños equipos a autoorganizarse y comunicarse de manera eficiente al tiempo
que reduce el riesgo de que cada equipo optimice localmente.

Turno: trabajar con equipos distribuidos

Como nos ha demostrado la pandemia de COVID-19, la colocación no es siempre una

opción. Al configurar equipos distribuidos, bríndeles las herramientas que necesitan para
comunicarse y colaborar. Estos incluyen cosas como software de videoconferencia (por
ejemplo, Zoom), servicios de comunicación en tiempo real (por ejemplo, Slack),
herramientas de pizarra en línea (por ejemplo, Mural y Miro), software simple para
compartir archivos (por ejemplo, Dropbox, Google Docs), control remoto software de
emparejamiento (p. ej., Screenhero) y cualquier otra cosa que pueda hacer que su
colaboración sea más fácil y productiva.

Cuando sea posible viajar, no lo olvides de vez en cuando Los boletos de avión para
conocerse en persona contribuyen en gran medida a mantener la colaboración a larga
distancia. Quizás lo más importante que debe recordar si está tratando de implementar
Lean UX con equipos distribuidos es esto: los miembros de estos equipos deben estar
despiertos al mismo tiempo. No es necesario que la superposición abarque una jornada
laboral completa, pero debe haber un bloque de tiempo todos los días durante el cual los
colegas puedan conversar y participar en ejercicios colaborativos.

Turno: fomente la flexibilidad en las relaciones con proveedores externos

Los proveedores de desarrollo de software de terceros plantean un gran desafío a los

métodos Lean UX. Si una parte de su trabajo se subcontrata a un proveedor externo,
independientemente de la ubicación del proveedor, es más probable que el proceso Lean
UX se rompa. Esto se debe a que la relación contractual con estos proveedores puede
dificultar la flexibilidad que requiere Lean UX.

Cuando trabaje con proveedores externos, intente crear proyectos basados en tiempo y
materiales. Esto le permitirá crear una relación flexible con su socio de desarrollo. Lo
necesitará para responder a los cambios que forman parte del proceso Lean
UX. Recuerde, está creando software para aprender y ese aprendizaje hará que sus planes
cambien. Planifique ese cambio y estructura sus relaciones con los proveedores en torno
a él.

Al seleccionar socios, recuerde que muchos talleres de desarrollo subcontratados están

orientados hacia el trabajo de producción y ven el retrabajo como un problema más que
como una oportunidad de aprendizaje. Cuando busque socios para el trabajo Lean UX,
busque equipos que estén dispuestos a adoptar la experimentación y la iteración y que
comprendan claramente la diferencia entre la creación de prototipos para aprender y el
desarrollo para la producción.

Turno: planifique el trabajo utilizando resultados, no productos

Capítulo 3 analiza el papel de los resultados en Lean UX. Los equipos de Lean UX miden
su éxito no en términos de funciones completadas, sino en términos de progreso hacia
resultados específicos. Determinar los resultados es una actividad de liderazgo; es uno en
el que muchas organizaciones no son buenas o no lo hacen en absoluto. Con demasiada
frecuencia, el liderazgo dirige al equipo de producto a través de una hoja de ruta de
producto centrada en las características: un conjunto de resultados y características que
requieren que el equipo de producto produzca en una fecha específica.

Los equipos que utilizan Lean UX deben tener la capacidad de decidir por sí mismos qué
funciones crearán los resultados que requieren sus organizaciones. Para hacer esto, los
equipos deben cambiar su conversación con el liderazgo de una basada en características
a una centrada en resultados. Este cambio conversacional es radical. Los gerentes de
producto deben determinar qué métricas comerciales requieren más atención. ¿Qué efecto
están intentando crear? ¿Están tratando de influir en el comportamiento del cliente? ¿Si
es así, cómo? ¿Están intentando aumentar el rendimiento? Si es así, ¿en qué
medida? Estas métricas deben estar vinculadas a un mayor impacto comercial.

El liderazgo debe establecer esta dirección. Si no, los equipos deben exigirles este
cambio. Los equipos deben preguntar: "¿Por qué estamos trabajando en este proyecto?" y
"¿Cómo sabremos que hemos hecho un buen trabajo?" Los gerentes deben volver a
capacitarse para dar a sus equipos las respuestas a estas preguntas. Se les debe dar la
libertad de trabajar con sus equipos para determinar qué características logran mejor estos
objetivos. Los equipos deben pasar de mapas de ruta de características a acumulaciones
de hipótesis pendientes para probar. El trabajo debe priorizarse en función del riesgo, la
viabilidad y el éxito potencial.

Shift: tenga cuidado con los BDUF que se cuelan en entornos ágiles

En la comunidad ágil, a veces escuchas a la gente hablar sobre Big Design Up Front o
BDUF. Hemos estado abogando por alejarnos de BDUF durante años. Pero no siempre
fue así.

A principios de la década de 2000, Jeff era diseñador de UI en AOL y trabajaba en un

nuevo navegador. El equipo estaba trabajando para encontrar formas de innovar en
conjuntos de funciones de navegador existentes. Pero siempre tenían que esperar para
implementar algo hasta que Jeff creara las maquetas, especificaciones y diagramas de
flujo apropiados que describían estas nuevas ideas.

Un desarrollador se cansó de esperar y comenzó a implementar algunas de estas ideas

antes de que los documentos estuvieran completos. ¡Jeff estaba furioso! ¿Cómo pudo
haber seguido adelante sin una dirección de diseño? ¿Cómo podría saber qué
construir? ¿Y si estaba mal o no funcionó? ¡Tendría que volver a escribir todo el código!

Resulta que el trabajo que hizo le permitió al equipo ver algunas de estas ideas mucho
antes que antes. Les dio a los miembros del equipo una idea de la experiencia real del
producto y les permitió iterar rápidamente sus diseños para que fueran más utilizables y
factibles. A partir de ese momento, relajaron los requisitos de BDUF, especialmente
cuando el equipo introdujo funciones que requerían animaciones y nuevos patrones de
interfaz de usuario.

La ironía de la dependencia de documentos del equipo y la "inspiración" que desencadenó

en ese desarrollador no se perdió. De hecho, al final del proyecto, Jeff recibió un premio
simulado ( Figura 17-1 ) por inspirar “creatividad indocumentada” en un compañero de
equipo.

Aunque la mayoría de los equipos ágiles en estos días dicen que evitan el concepto de
BDUF, hemos visto un resurgimiento en esta práctica en entornos supuestamente
ágiles. Esta nueva y disimulada versión de BDUF a veces se llama Agilefall . (O Agile-
Scrum-Fall, Water-Scrum-Fall, o Wagile. Ya entiendes la idea). Agilefall es la
combinación de una fase de diseño inicial que da como resultado un trabajo que se
entrega, estilo cascada, a un equipo de ingeniería. para luego dividirse en historias y
desarrollarse de manera “ágil”. El argumento a favor de esta forma de trabajo se centra
en el deseo del equipo de ingeniería de mantener el rumbo durante la implementación y
poder predecir cuándo se enviará el trabajo con cierto grado de confianza. Esto se hace
en nombre de la previsibilidad y la eficiencia.
Figura 17-1. El "premio" de Jeff por inspirar la creatividad indocumentada en los ingenieros

El problema, por supuesto, es que Agilefall elimina la colaboración entre diseño e

ingeniería que Lean UX requiere para tener éxito. Termina obligando a los equipos a crear
una gran documentación para comunicar el diseño, seguida de negociaciones aún más
largas entre diseñadores y desarrolladores. ¿Suena familiar? Es BDUF con un nuevo
disfraz. El desperdicio creado con Agilefall es un síntoma de un problema de
administración más amplio que continúa empujando a los equipos hacia un alcance y
plazos fijos. Los ingenieros sienten, con razón, que la única forma en que pueden
comprometerse con el alcance y los plazos es si tienen una comprensión clara de lo que
se necesita desarrollar, junto con la promesa de que nada cambiará. (¡No importa que
Agile se trate de adoptar el cambio!) Por supuesto, como ya sabemos, el software es
complejo e impredecible e, incluso con un diseño bloqueado,

Si Agilefall es la forma en que trabaja su equipo, considere ampliar la conversación sobre

la gestión de resultados con sus partes interesadas. Al alejar la conversación del tiempo y
el alcance fijos y dirigirla hacia el comportamiento del cliente como una medida de éxito,
las demandas para hacer todo el trabajo de diseño desde el principio deberían comenzar
a desaparecer.

Shift: Adopte la velocidad primero, la estética en segundo lugar

Jason Fried, director ejecutivo de Basecamp, dijo una vez: "La velocidad primero, la
estética después".
No estaba hablando de comprometer la calidad. Estaba hablando de editar sus ideas y
procesos hasta la médula. En Lean UX, trabajar rápidamente significa generar muchos
artefactos. No pierda el tiempo debatiendo qué tipo de artefacto crear y no pierda el
tiempo puliéndolos a la perfección. En su lugar, pregúntese lo siguiente:

• ¿Con quién necesito comunicarme?

• ¿Qué necesito para comunicarles de inmediato?
• ¿Cuál es la menor cantidad de trabajo que debo hacer para comunicárselo?

Si está trabajando con un desarrollador que está sentado a su lado, un boceto en la pizarra
puede ser suficiente. Si un ejecutivo hace preguntas detalladas sobre productos, es posible
que deba crear una maqueta visual. Los clientes pueden requerir prototipos. Cualquiera
que sea el escenario, cree el artefacto que tomará la menor cantidad de tiempo. Recuerde,
estos artefactos son una parte transitoria del proyecto, como una
conversación. Hágalo. Sácalo ahí fuera. Discutir. Siga adelante.

La estética, en el sentido del diseño visual, es una parte esencial de un producto terminado
y una experiencia. El ajuste y el acabado de estos elementos hacen una contribución
fundamental a la marca, la experiencia emocional y la profesionalidad. En la etapa de
refinamiento del diseño visual del proceso, hacer el esfuerzo de obsesionarse con esta
capa de presentación tiene mucho sentido. Sin embargo, poner este nivel de pulido y
esfuerzo en los artefactos de la etapa inicial (wireframes, mapas del sitio, diagramas de
flujo de trabajo) es (generalmente) una pérdida de tiempo.

Al sacrificar la perfección de los artefactos de diseño intermedios, su equipo llegará al

mercado más rápido y aprenderá más rápidamente qué elementos de toda la experiencia
(diseño, flujo de trabajo, copia, contenido, rendimiento, propuestas de valor, etc.)
funcionan para los usuarios y cuáles no lo son. Y estará más dispuesto a cambiar y
reelaborar sus ideas si ha puesto menos esfuerzo en presentarlas.

Cambio: abordar la deuda de UX

Suele ocurrir que los equipos que trabajan en procesos ágiles no volver a mejorar la
interfaz de usuario del software. Pero, como le gusta decir a nuestro amigo Jeff Patton,
"No es iteración si lo haces solo una vez". Los equipos deben comprometerse con la
mejora continua, y eso significa no simplemente refactorizar el código y abordar la deuda
técnica, sino también reelaborar y mejorar las interfaces de usuario. Los equipos deben
adoptar el concepto de deuda de UX y comprometerse con la mejora continua de la
experiencia del usuario.

James O'Brien, un diseñador de interacción que trabaja en Londres, describe lo que

sucedió cuando su equipo comenzó a rastrear la deuda de UX de la misma manera que el
equipo solía rastrear la deuda técnica. “El efecto fue dramático. Una vez que presentamos
la reelaboración como deuda , toda oposición se desvaneció. No solo no se trataba de
que la deuda no se pagara, sino que se priorizaba constantemente ". 2

Para comenzar a rastrear la deuda de UX, puede crear una categoría de historias en su
cartera de pedidos llamada deuda de UX. A veces, sin embargo, los problemas de
experiencia no son algo que un solo equipo pueda resolver; resolver problemas mayores
puede requerir el esfuerzo coordinado de muchos equipos. Para estos esfuerzos más
grandes (experimentar problemas que abarcan grandes recorridos de usuarios), intente lo
siguiente:

• Cree un mapa del recorrido del cliente de la experiencia actual.

• Trabaje junto con su equipo para crear un segundo mapa de viaje que muestre la
experiencia ideal.
• Haga que estos dos artefactos sean claramente visibles (en una pared) uno al lado
del otro.
• Identifique a los equipos responsables de partes de ese recorrido del cliente e
invítelos al muro para revisar la brecha entre los estados actuales y deseados.
• Trabaje con estos equipos para escribir historias de deudas de UX para continuar
con sus trabajos pendientes.
• Identifique claramente en los mapas de viaje cuándo se ha mejorado la experiencia
actual y quién está trabajando en otras mejoras.

Turno: repensar las prácticas de documentación

Dependiendo del dominio en el que trabajes, tu organización podría imponer estrictos

estándares de documentación que cumplan con el cumplimiento normativo e interno. Es
posible que estos documentos no agreguen mucho o ningún valor para el proyecto
mientras está en marcha, pero el equipo aún tiene que crearlos. Muchos equipos luchan
por hacer avanzar sus proyectos cuando se enfrentan a estas regulaciones. Esperan hasta
que los documentos estén completos antes de comenzar el diseño e implementación del
trabajo, lo que ralentiza el progreso y el aprendizaje en equipo. Luego, cuando los
documentos estén completos, se desaconseja cualquier ajuste del trabajo descrito en ellos
debido a la sobrecarga de documentación que generará el cambio.

Esta situación es exactamente donde, como diseñador y entrenador Lane GoldstoneEn

pocas palabras, "lideras con la conversación y sigues con la documentación". Las
filosofías y conceptos básicos de Lean UX se pueden ejecutar dentro de estos entornos
(conversación, resolución colaborativa de problemas, bocetos, experimentación, etc.)
durante las primeras partes del ciclo de vida del proyecto. A medida que se prueben las
hipótesis y se solidifiquen las direcciones de diseño, haga la transición de las prácticas de
documentación informal a la documentación estándar que su empresa requiere. Utilice
esta documentación por el motivo exacto que exige su empresa: capturar el historial de
decisiones e informar a los futuros equipos que trabajen en este producto. No permita que
esto le impida tomar las decisiones correctas sobre el producto.

Turno: Gestionar hacia arriba y hacia fuera

Lean UX les da a los equipos mucha libertad para perseguir soluciones. Lo hace
alejándose de un enfoque de mapa de ruta de características y, en cambio, permite a los
equipos descubrir las características que creen que servirán mejor a la empresa. Pero
abandonar la hoja de ruta de funciones tiene un costo: elimina una herramienta clave que
la empresa utiliza para coordinar la actividad de los equipos. Entonces, con la libertad de
seguir su agenda, viene la responsabilidad de comunicar esa agenda.

Debe comunicarse constantemente con los miembros de su organización que no están

involucrados actualmente en su trabajo para que estén al tanto de lo que se avecina. Esta
comunicación también te hará consciente de lo que otros están planeando y te ayudará a
coordinar. Los gerentes de servicio al cliente, los especialistas en marketing, las unidades
de negocios paralelas y los equipos de ventas se benefician al saber qué está haciendo la
organización del producto. Al comunicarse con ellos de manera proactiva, les permite
hacer mejor su trabajo. A su vez, serán mucho menos resistentes al cambio que están
haciendo los diseños de sus productos.

Aquí hay dos lecciones valiosas para garantizar ciclos de validación más fluidos:

• Siempre hay otros departamentos que se ven afectados por su trabajo. Ignórelos
bajo su responsabilidad.
• Asegúrese de que los clientes estén al tanto de los próximos cambios importantes
y bríndeles la opción de optar por no participar (al menos temporalmente).

1Robert C. Daley, “El papel del equipo y las características de la tarea en la productividad
y la resolución de problemas en equipo de I + D”, Management Science 24, no. 15 (1 de
noviembre de 1978): 1557–1676, https://oreil.ly/hnN7a .

2 James O'Brien, entrevista con Joshua Seiden y Jeff Gothelf, 2012.

Capítulo 18. Lean UX en una agencia
Gran parte del enfoque de este libro ha sido explícitamente hacer que Lean UX funcione
dentro de una empresa de productos o dentro de un grupo de productos dentro de una
empresa u organización más grande. Si bien la mayoría de esos consejos se pueden aplicar
en cualquier entorno, vale la pena mencionar explícitamente las diferencias necesarias
para que Lean UX funcione en una agencia.

Por el bien de esta discusión, cuando decimos "agencia", significa cualquier organización
que vende servicios a un cliente. Este podría ser un pequeño estudio de diseño de cuatro
personas en Portland, Oregon, o una agencia de marketing de mil personas en Londres. Lo
que hace que Lean UX sea un desafío único en este entorno son, en una palabra, los
clientes. Es difícil para las agencias traer nuevas formas de trabajar a los clientes que
encuentran estas formas de trabajar ajenas a su cultura. Ahora, en algunos casos, esta será
la razón exacta por la que se contrató a su agencia. En otros, será un enfoque extranjero
continuamente amenazado por anticuerpos corporativos resistentes a diferentes formas de
trabajar. De cualquier manera, será difícil.

En este capítulo, cubriremos cinco elementos clave a considerar cuando intente llevar
formas modernas de trabajo a su empresa.

¿En qué negocio quieres estar?

Las agencias casi siempre están en el negocio de los entregables. Se les paga por entregar
un diseño, un prototipo, alguna investigación o una pieza de software funcional. Este
modelo de negocio entra en conflicto con Lean UX y su enfoque en los resultados.

El modelo de negocio tradicional de la agencia es simple: los clientes pagan por los
entregables (diseños, especificaciones, código, presentaciones de PowerPoint), no por
resultados. La otra parte del modelo comercial de una agencia es la utilización: debe
mantener a su gente facturando. La necesidad de mantener una alta utilización puede
conducir a procesos que fomenten los silos funcionales. Estos, a su vez, conducen a "fases
del proyecto" que fomentan el trabajo centrado en los entregables. La venta de equipos
multifuncionales es excelente siempre que todos los miembros del equipo sean
facturables en todo momento.

Si va a realizar la transición de la forma de trabajar de su agencia a Lean UX, debe

considerar ambos desafíos. En primer lugar, ya no puede estar exclusivamente en el
negocio de los entregables. ¿Entregará wireframes, prototipos, investigación y software
funcional? Por supuesto que lo harás. Pero estas no pueden ser las medidas de su
éxito. No pueden ser los criterios que determinan si le pagan o no. En su lugar, considere
transformar el negocio en un modelo de tiempo y materiales. No está vendiendo "una
aplicación" o "un diseño", sino que está colaborando con su cliente para encontrar una
solución a un cliente y un problema comercial que tiene el cliente. ¿Cuál es esa
solución? La respuesta sincera es, no lo sabe. En cambio, trabajará junto con el cliente
para descubrir cuál debería ser esa solución.
Para garantizar que la utilización se mantenga alta, venda equipos pequeños por períodos
de tiempo finitos con cláusulas de renovación claras. En la agencia que dirigimos durante
cuatro años juntos, propondríamos un equipo de cuatro personas compuesto por un
gerente de producto, un diseñador y dos desarrolladores como equipo inicial para casi
todos los proyectos. Ese equipo tenía un costo fijo por semana y normalmente
venderíamos un contrato de tres meses renovable en bloques de tres meses. Esto nos
ayudó a reforzar el mantra de los ciclos cortos porque el cliente tenía una opción de salida
o renovación cada trimestre. También redujo nuestro riesgo al darnos la opción de
despedir a un cliente que no encajaba bien con la forma en que queríamos
trabajar. También,

Determinar su modelo de negocio antes de un cambio total hacia un estilo de trabajo Lean
UX es importante porque también afectará a su personal actual, así como a las posibles
contrataciones. El único activo que tiene una agencia es su gente. Los diseñadores,
gerentes de producto, desarrolladores de software, etc., vienen a trabajar para usted
porque promete una cierta forma de trabajar para tipos específicos de clientes. Si promete
una forma de trabajar Lean UX y termina contratando clientes que no trabajarán de esta
manera, su personal eventualmente se irá.

Vender Lean UX a los clientes se trata de

establecer expectativas
Sus clientes llevan años contratando agencias. Muchoslos clientes esperan "arrojarlo por
la pared" a la agencia y luego ver los resultados cuando estén listos. En este caso, la
colaboración entre el cliente y la agencia puede limitarse a una crítica desinformada e
improductiva que se basa en prejuicios personales, política y disimulo. Dada la naturaleza
altamente colaborativa de Lean UX, obviamente esta no es una relación aceptable. ¿Qué
puedes hacer para evitar esto?

Cada punto de contacto que tiene con clientes actuales y potenciales es una oportunidad
para establecer expectativas sobre cómo trabajar con usted es diferente. Comienza con su
marca, su marketing, su posicionamiento y, lo más tangible, su sitio web. Diseñe y
escríbalo de tal manera que no haya duda de que trabaja de una manera que lo diferencie
de las agencias tradicionales. Aumente esas expectativas con una producción constante
de contenido en blogs, publicaciones y redes sociales. Asegúrese de que la gente conozca
su agencia como "la gente de Lean UX". La primera vez que hable con su cliente en
persona, repase cómo trabaja con él. Si tiene la suerte de presentarlos, su forma de trabajar
debe ser clara y directa en la plataforma de lanzamiento.

Si progresa en la planificación de compromisos, tenga claro cómo trabajarán juntos y por

qué eso es tan importante para crear una forma de trabajo centrada en el cliente. Si surgen
preguntas del cliente que indican que no ha asimilado completamente que su agencia no
será un socio de subcontratación para ellos, detenga el proceso y repita el proceso
nuevamente. Es muy importante comunicar esto temprano y con frecuencia, porque una
vez que se firma el contrato, cualquier cambio radical en las expectativas podría resultar
negativo para su cliente.
Nadie quiere comprar experimentos
A medida que establece expectativas sobre cómo será trabajar con usted, recuerde esta
importante afirmación: nadie quiere comprar experimentos. Tus clientes quieren
aplicaciones. Quieren software. Quieren diseño. Lo que definitivamente no quieren
comprarle es un experimento. Los experimentos son riesgosos y tienden a
fallar. Ciertamente, no son el software de producción de nivel de mercado que ayudará a
su cliente a aumentar su participación de mercado o su rentabilidad. Al menos así es como
lo ven.

Cuando lanzamos nuestra agencia por primera vez, lideramos con la idea de experimentos
en nuestro proceso de ventas. Un cliente diría: "Tengo $ 100,000 para que cree una
aplicación móvil para mi empresa". Y respondíamos: “¡Genial! Tomaremos $ 10,000 de
eso y haremos experimentos para averiguar exactamente cómo gastar los otros $ 90,000
". Sin falta, cada cliente que recibió este lanzamiento diría, “No. Solo use todo el
presupuesto para crear la aplicación. Conozco mi negocio y mis clientes. No necesitamos
experimentar ".

Esta fue una clara señal de que no nos habíamos diferenciado adecuadamente en el
mercado, no habíamos establecido las expectativas correctas con los prospectos y
estábamos liderando con una táctica en lugar del resultado final deseado.

Los experimentos son parte de Lean UX, pero son solo una táctica. Son parte de un
proceso diseñado para generar aprendizaje, una buena toma de decisiones y resultados
positivos. Liderar nuestro discurso de ventas con el resultado (por ejemplo, "Nuestro
proceso garantiza que tomemos las mejores decisiones para ayudar a resolver su desafío
de comercio móvil") demostró ser una forma de trabajo mucho más exitosa.

¡Hiciste la venta! Ahora navegue por las

adquisiciones
A veces harás todo lo correcto. Tu sitio web lo dirátu historia. Su argumento de venta
resonará. El cliente asentirá con la cabeza. ¡Tenemos un trato para nosotros! Te das una
palmadita en la espalda y comienzas a lidiar con el cierre del contrato, solo para escuchar
esa frase que todos los proveedores de servicios temen: "Está bien, déjeme que nuestra
gente de adquisiciones se ocupe de esto".

Si alguna vez ha tenido que lidiar con el departamento de adquisiciones interno (o, peor
aún, con un tercero) de una gran organización, entonces sabe cómo se siente esto. Todo
el convencimiento que hiciste con el cliente no significa nada para las personas que tienen
que aprobar el contrato y la compra. Sin falta, la conversación retrocede instantáneamente
a “OK, entonces le estamos dando $ 100,000. ¿Cuáles son los entregables específicos que
obtendremos a cambio? ¿Y en qué fecha?

Esta es otra parte del establecimiento de expectativas que debe suceder con los clientes
con anticipación. A medida que comienza a cerrar el contrato, el objetivo es alejarse de
los contratos de alcance fijo y basados en entregables. En su lugar, cree contratos para
compromisos que se basen en acuerdos simples de tiempo y materiales o, de manera más
radical, en contratos basados en resultados. Los contratos basados en resultados o los
contratos de precios basados en valor son raros. Enumeran el pago como variable en
función de la cantidad de resultado que puede generar la agencia. A menudo, esto es
demasiado riesgo para que un cliente (y agencias) lo asuman sin un límite superior al
contrato.

Ya sea que elija contratos de tiempo y materiales o contratos basados en resultados, el

equipo de la agencia tendrá más libertad para dedicar su tiempo a iterar hacia un objetivo
específico. Los clientes renuncian a la ilusión de certeza que ofrece un contrato basado
en entregables, pero obtienen la libertad de buscar soluciones significativas y de alta
calidad que se definen en términos de resultados, no de listas de funciones, y que tienen
más posibilidades de hacer que sus clientes sean más exitosos. .

Ya no eres un socio de subcontratación

Crear un proceso Lean UX con sus clientes significa que usted ya no son su agencia de
subcontratación. Usted es su socio de colaboración y trabaja para resolver un problema
empresarial. Su función no es aumentar el personal del cliente o asumir una parte del
trabajo que no pueden realizar internamente. Su función es hacer del cliente un socio
activo de su equipo. Su cliente también debe comprender esto. Vendrán a las
paradas. Participarán en la toma de decisiones de forma regular. Participarán en los
esfuerzos de descubrimiento de productos. En nuestra agencia, tomamos muy pocas
decisiones de priorización de la acumulación de productos. Esta fue la responsabilidad
explícita del cliente. La única forma en que podían hacer esto de manera efectiva era estar
presentes en las reuniones diarias, participar con el equipo en sus actividades de
aprendizaje y estar presentes en las actualizaciones de estado y las reuniones de toma de
decisiones. Lo llevamos más allá e insistimos en que el cliente se instalara en nuestro
estudio durante la duración del compromiso. ¿Por qué? Para eliminarlos de las
distracciones diarias, colóquelos en un espacio más creativo y recuérdeles que estamos
trabajando juntos como un equipo.

Estas expectativas de relación deben estar en su contrato. Su cliente debe comprometerse

con este alto nivel de compromiso si Lean UX va a funcionar.Recuerde que su objetivo
es desarrollar un entendimiento compartido. Si el cliente no está presente para el trabajo
de descubrimiento, la síntesis y la toma de decisiones, entonces debe comenzar a
documentar todo para él, enviarlo para su aprobación y esperar esa retroalimentación
antes de seguir adelante. Esto nos devolvería al estilo de trabajo tradicional de las
agencias.

Una vez, un cliente de servicios financieros aceptó todos nuestros términos para trabajar
juntos. Firmaron el contrato y se instalaron rápidamente en nuestra oficina. Trajeron sus
máquinas con Windows (oye, éramos una tienda de Mac) y desde el principio intentaron
recrear su cultura dentro de nuestro estudio. Crearon todos los obstáculos posibles para
evitar que nos reuniéramos con sus clientes. Limitaron nuestro acceso a los servidores de
implementación y esencialmente nos impidieron hacer el trabajo que habíamos acordado
en el contrato. Ocho semanas después, levantamos la mano para detener el proceso. Nos
reunimos con el cliente y le planteamos su preocupación de que las formas de trabajo que
habíamos acordado estaban encontrando una fuerte resistencia. El cliente nos dijo que no
podían hacer nada al respecto. Terminamos las cosas cuidadosamente en las próximas
dos semanas y despedimos a ese cliente. No es que no pudiéramos seguir trabajando de
la forma que ellos querían. Era solo que si lo hacíamos, corríamos el riesgo de perder
nuestro equipo debido al comportamiento del cliente. Eso fue inaceptable para nosotros.

Una nota rápida sobre socios de

desarrollo y proveedores externos
En las relaciones con agencias, los equipos de desarrollo de software (ya sea en la agencia,
en el cliente o trabajando como un tercero) a menudo se tratan como extraños y, a menudo,
se incorporan al final de una fase de diseño. Es imperativo que cambie esto: los socios
para el desarrollo deben participar a lo largo de la vida del proyecto, y no simplemente
como observadores pasivos. En su lugar, debe intentar que el desarrollo de software
comience lo antes posible. Nuevamente, está buscando crear una colaboración profunda
y significativa con todo el equipo del proyecto, y para hacerlo, debe trabajar codo con
codo con los desarrolladores.

Los proveedores de desarrollo de software de terceros representan un gran desafío para

los métodos Lean UX. Si una parte de su trabajo se subcontrata a un proveedor externo,
independientemente de la ubicación del proveedor, es más probable que el proceso Lean
UX se rompa. Esto se debe a que la relación contractual con estos proveedores puede
dificultar la flexibilidad que requiere Lean UX.

Cuando trabaje con proveedores externos, intente crear proyectos basados en tiempo y
materiales. Esto le permitirá crear una relación flexible con su socio de desarrollo. Lo
necesitará para responder a los cambios que forman parte del proceso Lean
UX. Recuerde, está creando software para aprender y ese aprendizaje hará que sus planes
cambien. Planifique ese cambio y estructura sus relaciones con los proveedores en torno
a él.

Al seleccionar socios, recuerde que muchos talleres de desarrollo subcontratados están

orientados hacia el trabajo de producción y ven el retrabajo como un problema más que
como una oportunidad de aprendizaje. Cuando busque socios para el trabajo Lean UX,
busque equipos que estén dispuestos a adoptar la experimentación y la iteración y que
comprendan claramente la diferencia entre la creación de prototipos para aprender y el
desarrollo para la producción.

Terminando
Trabajar como proveedor de servicios crea diferentes desafíos para implementar Lean
UX. Recuerde que esto es tanto un cambio cultural para su agencia como un cambio de
modelo de negocio. Cambiará no solo cómo vende, sino cómo y a quién contrata. Es
imperativo establecer expectativas con sus clientes de que su forma de trabajar desafiará
su noción de trabajar con una agencia. Un poco de creatividad y una pizca de confianza
pueden hacer que el proceso de contratación y adquisición sea más exitoso. Finalmente,
un mal cliente es un mal cliente independientemente de cómo trabajen juntos. Asegurar
la integridad de su equipo es su máxima prioridad.
Capítulo 19. Una última palabra
Después del lanzamiento de la primera edición de Lean UX , nos complació comenzar a
recibir comentarios de los lectores. Después de todo,Lean UX se trata de escuchar a sus
usuarios, por lo que queríamos comprender lo que los "usuarios" del libro tenían que
decir. Los lectores tenían mucho que decir (¡gracias!), Pero un tema surgió de todos los
demás y se ha mantenido persistente a lo largo de los años. Este tema tiene que ver con
la necesidad de desarrollar organizaciones y procesos que realmente puedan adoptar esta
forma de trabajar.

Sabemos que trabajar con Lean UX requiere cambios. Lo que no entendimos claramente
hasta que escuchamos a los lectores es que los cambios se dividen en dos categorías:
cambios que los lectores pueden hacer por sí mismos y cambios que requieren que los
líderes se involucren, líderes que quizás no quieran cambiar, por cualquier razón.

Nuestros lectores nos dijeron: Mire, podemos hacer ciertos tipos de cambios nosotros
mismos, pero para otros cambios, debemos confiar en cambiar las actitudes de nuestro
líder. Necesitamos cambiar las cosas más allá de nosotros mismos, necesitamos
cambiar la forma en que funciona nuestra organización.

Ahora bien, cambiar una organización, incluso una pequeña, es un gran desafío. Es un
desafío que la mayoría de los diseñadores y la gente de productos tienen poca capacitación
o experiencia tratando de implementar. Incluso las personas experimentadas en el campo
del desarrollo organizacional saben que cambiar de organización es difícil. Entonces
puede resultar abrumador. Y eso es lo que escuchamos de nuestros lectores. Querían
saber cómo cambiar y no sabían por dónde empezar. Querían ayuda.

Es una especie de fastidio, ¿eh?

Bueno, escucha: el objetivo de este capítulo no es hacerte sentir desesperado. Creemos

firmemente que las personas, los equipos y las empresas pueden cambiar. Además,
creemos que puede usar Lean UX para ayudarlo a realizar estos cambios. Además de
ayudar a los equipos a aprender Lean UX, hemos pasado los años desde que salió la
primera edición trabajando en este tipo de problemas de transformación, y hemos visto
de primera mano que el cambio es posible.

Ahora bien, los por qué, los cómo y los dónde de la transformación organizacional están
más allá del alcance de este libro, pero queremos ofrecerle un punto de partida.

El producto que hace el producto

En las palabras de nuestro amigo Barry O'Reilly, una organización de desarrollo de
productos es "el producto que fabrica el producto". En otras palabras, puede abordar el
desarrollo organizacional utilizando muchas de las mismas herramientas que utiliza para
el desarrollo de productos. Y creemos firmemente que puede utilizar los métodos de Lean
UX al servicio del desarrollo organizacional.
¿Qué cambio quieres hacer en tu organización? ¿Puede describir el cambio en términos
del resultado que busca? Tal vez desee que la investigación sea más colaborativa. Su
resultado podría ser: en futuros proyectos de investigación, asegúrese de que cada
miembro del equipo participe en al menos una sesión de entrevista directa con el
cliente. O tal vez desee cambiar la forma en que se asigna el trabajo a su equipo. Su
resultado podría ser: en el próximo trimestre, la mitad de las epopeyas en las que
trabajamos estarán definidas por un resultado del usuario en lugar de una lista de
funciones.

Adivina qué: ¡estás usando Lean UX! Ahora bien, ¿cómo vas a hacer estos
cambios? Bueno, querrá probar una serie de experimentos hasta que encuentre la manera
correcta de lograr su resultado. Piense en estos experimentos como un proceso mínimo
viable.

Entonces, si bien es posible que no tenga la autoridad para cambiar completamente la

forma en que funciona su organización, no hay nada que le impida reclutar un pequeño
grupo de colaboradores dispuestos y usar las herramientas de Lean UX para comenzar a
crear la organización que desea. Tendrás que empezar a diseñar cosas nuevas (como
procesos de trabajo) para nuevas personas (stakeholders, pares, colaboradores), pero
puedes hacerlo, ¿verdad? Si tu puedes hacerlo.

Estamos muy contentos de ver a tantos equipos adoptar estos métodos a lo largo de los
años, y estamos seguros de que usted también puede hacerlo. Y, como siempre, estamos
emocionados de saber de usted. ¡Buena suerte en tu viaje Lean UX y cuéntanos cómo te
va!

Como dijimos al comienzo de este libro: manténgase en contacto y comparta sus

pensamientos. Comuníquese con nosotros
en [email protected] y [email protected] . Siempre esperamos escuchar de
usted.