Lean UX - Applying Lean Principles To Improve User Experience (PDFDrive) - 1

Machine Translated by Google

Elogios para Lean UX
“Customer Development y Lean Startup cambiaron la forma en que se construyen los

negocios, porque incluso los equipos más inteligentes no pueden predecir el comportamiento
del mercado y de los usuarios. Este libro trae ambas metodologías a UX para que pueda
crear experiencias más económicas, más rápidas y, lo que es más importante, mejores”.
Alex Osterwalder, autor y empresario;

Cofundador, Business Model Foundry GmbH
“Muchos diseñadores de UX que conozco temen las palabras 'Agile' o 'Lean' por temor a que
amenace su proceso creativo y bajen los estándares de calidad de su trabajo. Pero con más
y más equipos de desarrollo de software que adoptan estas metodologías, es importante
que el equipo de UX adopte este cambio y encuentre formas de utilizar el sistema para su
beneficio. En este libro, Jeff Gothelf y Josh Seiden explican qué es Lean UX, por qué
deberías practicarlo y cómo puede ayudarte a ti y a tu equipo a crear mejores productos (de
eso se trata, ¿verdad?). Utilizando estos principios, el equipo de RunKeeper ha derribado
las barreras tradicionales entre la ingeniería y la UX y ha hecho que todos sean responsables
de crear una experiencia de usuario increíble”.
Tom Boates—VP, experiencia del usuario, RunKeeper
“Hay una revolución en marcha. Es alejarse del gran diseño por adelantado y de los equipos
aislados y especializados que se arrojan documentos por encima de la pared. Aplicando los
principios de Lean startups, Jeff y Josh exponen los principios de Lean UX, que literalmente
pueden transformar la forma en que das vida a las experiencias. Tengo experiencia de
primera mano aplicando su sabiduría y estoy emocionado de llevar Agile al siguiente nivel.
Consigue este libro. Pero lo más importante, pon este libro en práctica”.
Bill Scott—Sr. Director, ingeniería de interfaz de usuario, PayPal, Inc.
www.it-ebooks.info
“Si está buscando brindar excelentes experiencias con métodos de desarrollo Agile, ¡obtenga este libro!
Jeff y Josh comparten métodos probados para la creación de ideas creativas, la planificación y la
resolución de problemas sin un pesado equipaje de entrega”.
Christian Crumlish—Director de Producto, CloudOn
“Si bien no hay duda de que los grandes equipos de productos deben poner el diseño de la experiencia
del usuario al frente y al centro, muchos equipos han luchado por reconciliar las técnicas y los objetivos
del diseño de la experiencia del usuario con el ritmo y el paso de los equipos de desarrollo Agile
modernos. Lean UX es la colección de técnicas y mentalidad que recomiendo a los equipos de
productos modernos que saben que necesitan los beneficios de ambos”.
Marty Cagan—Fundador, Silicon Valley Product Group;
Ex vicepresidente sénior de productos y diseño de eBay
“La pasión de Jeff y Josh por hacer bien la UX (y realmente todo el desarrollo de productos) se
manifiesta con fuerza en este libro detallado pero eminentemente legible. Los estudios de caso, los
ejemplos y la investigación sirven para resaltar el poder de construir un proceso Lean UX, y hay una
gran cantidad de consejos prácticos extraídos de estos. Estoy ordenando una copia para todos en
nuestros equipos de diseño, UX y productos en Moz”.
Rand Fishkin—CEO y cofundador, Moz
“Una combinación fantástica de estudios de casos y consejos prácticos que su equipo puede usar hoy.
Ya sea que esté en una empresa emergente o en una de las 500 de Fortune, este libro cambiará la
forma en que crea productos”.
Laura Klein—Directora, los usuarios saben
“Lean UX proporciona un marco prescriptivo sobre cómo crear mejores productos, alejando el diseño
de la perfección de píxeles por el simple hecho de hacerlo, hacia el aprendizaje iterativo, un esfuerzo
más inteligente y resultados basados en resultados.
Los gerentes de producto, los dueños de negocios y los empleados de empresas emergentes, junto
con los diseñadores, pueden beneficiarse enormemente de Lean UX”.
Ben Yoskovitz, vicepresidente de productos, GoInstant
www.it-ebooks.info
Experiencia de usuario optimizada
Aplicación de los principios Lean a

Mejore la experiencia del usuario
jeff gothelf
Josh Seiden, editor
Pekín · Cambridge · Farnham · Colonia · Sebastopol · Tokio
www.it-ebooks.info
Experiencia de usuario optimizada
por Jeff Gothelf
Derechos de autor © 2013 Jeff Gothelf. Reservados todos los derechos.

Impreso en los Estados Unidos de América.
Publicado por O'Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472.
Los libros de O'Reilly se pueden comprar con fines educativos, comerciales o de promoción de ventas.
Las ediciones en línea también están disponibles para la mayoría de los títulos (http:// my.safaribooksonline.com).
Para obtener más información, comuníquese con nuestro departamento de ventas corporativo/institucional: (800)
998-9938 o corporate@oreilly.com.
Editora de adquisiciones: Mary Treseler Indexador: Lucie Haskins
Editor de desarrollo: Josh Seiden Compositor: Holly Bauer

Editora de producción: Holly Bauer Diseño de portada: Mark Paglietti
Correctora : Nancy Kotary Diseñador de interiores: Ron Bilodeau
Correctora: Jilly Gagnon Ilustrador: Kara Ebrahim
Marzo 2013: Primera Edición.
Historial de revisión de la primera edición:
2013-02-08 Primer lanzamiento
Consulte http:// oreilly.com/ catalog/ errata.csp?isbn=0636920021827 para conocer los detalles de la versión.
Nutshell Handbook, el logotipo de Nutshell Handbook y el logotipo de O'Reilly son marcas comerciales registradas
de O'Reilly Media, Inc. Lean UX y la imagen comercial relacionada son marcas comerciales de O'Reilly Media, Inc.
Muchas de las designaciones utilizadas por los fabricantes y vendedores para distinguir sus productos
se reclaman como marcas comerciales. Donde esas designaciones aparecen en este libro, y O'Reilly Media,
Inc., estaba al tanto de un reclamo de marca registrada, las designaciones se han impreso en mayúsculas o
iniciales en mayúsculas.
Aunque el editor y el autor han tenido un cuidado razonable en la preparación de este libro, la información que
contiene se distribuye "tal cual" y sin garantías de ningún tipo.
Este libro no pretende ser un consejo legal o financiero, y no todas las recomendaciones pueden ser
adecuadas para su situación. Se debe consultar a asesores legales y financieros profesionales, según sea
necesario. Ni el editor ni el autor serán responsables de ningún costo, gasto o daño que resulte del uso o la
confianza en la información contenida en este libro.
ISBN: 978-1-449-31165-0
[CW]
www.it-ebooks.info
Para Carrie, Grace y Sophie
www.it-ebooks.info
www.it-ebooks.info
Contenido
Prólogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . IX
Prefacio . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIII
Sección I: Introducción y Principios
Capítulo 1
¿Por qué Lean UX? . . . . . . . .. . . ........... . . ..3
Capitulo 2
principios . . . . . . . . . . . . . ........... . . ..5
Sección II: Proceso
Capítulo
3 Visión, marco y resultados . . . . . . . . . . . . . . 17
Capítulo 4
Diseño colaborativo. . .. . . . . . . . . . . . . . . . . . 33
Capítulo 5
MVP y Experimentos. . . . . . . . . . . . . . . . . . . . 55
Capítulo 6
..
Retroalimentación e Investigación. . . . . . . . . . . . . . . . . 73
VII
www.it-ebooks.info
Sección III: Haciendo que funcione
Capítulo 7
Integrando Lean UX y Agile. . . . . . . . . . . . . . . 95
Capítulo 8
..
Hacer cambios organizacionales. . . . . . . . . . . . . 109
índice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
viii Contenido
www.it-ebooks.info
Prefacio
Al leer Lean UX, está a punto de embarcarse en un recorrido por una nueva forma de
trabajar. Para aquellos de nosotros 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 corporación moderna típica. Desde lo alto, podría examinar
cada silo de excelencia funcional uno a la vez.
Véalos con el ojo de su mente: 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 abrió la tapa para ver el
interior. ¿Qué verías? Al ser una empresa moderna, vería cada silo diseñado para
lograr la 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 Fabricación, se encontraría con el pensamiento lean tradicional.
En Ingeniería o TI, tal vez alguna variación en el desarrollo ágil. En Marketing,
desarrollo de clientes. En Operaciones, DevOps. Y por supuesto en Diseño, lo último
en técnicas de pensamiento de diseño, diseño de interacción y de investigación de
usuarios.
Volviendo a nuestro alto nivel, se nos podría perdonar por pensar: “Esta empresa
utiliza una variedad de metodologías rigurosas, basadas en hipótesis, centradas en el
cliente e iterativas. ¡Seguramente, debe ser una empresa extremadamente ágil, capaz
de reaccionar rápidamente a los cambios en las condiciones del mercado e innovar
continuamente!” Pero aquellos de nosotros que trabajamos en empresas modernas
sabemos cuán lejos está esto de la verdad.
IX
www.it-ebooks.info
¿Cómo es posible que nuestros silos departamentales estén operando con agilidad,
pero nuestras empresas son irremediablemente rígidas y lentas? Desde nuestro
punto de vista lejano, nos hemos perdido algo esencial. Aunque nuestros
departamentos pueden valorar la agilidad, las interconexiones entre ellos todavía
están sumidas en un pasado industrial anticuado.
Considere solo un ejemplo, que espero le suene familiar. Una empresa decide que
debe innovar para sobrevivir. Encarga a un equipo de diseño (ya sea interno o
externo) que investigue el futuro de su industria y recomiende nuevos productos
innovadores que puedan asegurar su futuro. Comienza un período de gran emoción.
Los clientes son entrevistados, observados, analizados.
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é sucede al final de este proceso? Los diseñadores presentan con orgullo, y
las empresas celebran con entusiasmo, un documento de especificaciones masivo
con sus hallazgos y recomendaciones. La iteración, la experimentación y el
descubrimiento cesan. Ahora se le pide a la ingeniería que ejecute este plan. Y
aunque el proceso de ingeniería puede ser ágil, el documento de especificaciones es
rígido. ¿Qué sucede si los ingenieros descubren que la especificación era
impracticable 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" construida a medida 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 funcionales de conceptos de productos futuristas. Puedes adivinar lo
que sucedió durante los siguientes 10 años: absolutamente nada. La empresa hizo
rotar 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 medida precisos. Y, sin
embargo, la compañía no había logrado comercializar ni siquiera una de las
recomendaciones en el asistente
documento de especificaciones. Entonces le pregunté a la compañía qué planeaban
hacer a continuación; ¡Me dijeron que volverían a los diseñadores originales y les
pedirían que pronosticaran los próximos 10 años! La empresa culpó a sus ingenieros
y gerentes por no comercializar, no a los diseñadores.
Cuando cuento esta historia a personas que no son diseñadores, se horrorizan y

quieren convencerme de que la culpa es de la firma de diseño elegante. Cuando se
lo digo a los altos ejecutivos, tanto en grandes empresas como en nuevas empresas, ellos
X Prefacio
www.it-ebooks.info
morir de vergüenza. Están constantemente inundados de quejas de cada una de las

funciones de que son rápidos y vanguardistas, pero son los otros departamentos los que
ralentizan a la empresa. Cuando toda la empresa no logra encontrar nuevas fuentes de
crecimiento, hay mucha culpa para repartir.
Pero la culpa no es de los diseñadores, ni de los ingenieros, ni siquiera de 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.
Han pasado casi cuatro años desde que comencé a escribir y hablar sobre un nuevo
concepto llamado Lean Startup, y apenas un año desde que publiqué The Lean Startup:
Cómo los emprendedores de hoy usan la innovación continua para lograr negocios
radicalmente exitosos (Crown Business). En ese tiempo, he visto crecer y difundirse las
ideas, de industria en industria, de sector en sector y de función en función. Cada vez que
hemos encontrado nuevos terrenos, hemos confiado en líderes con visión de futuro para
ayudar a traducir los principios básicos y desarrollar nuevos procesos para implementarlos.
Lean UX es un paso importante en esa evolución. Por primera vez, tenemos una visión
integral de cómo se aplican los principios de Lean Startup en un contexto de diseño. En el
camino, presenta importantes herramientas y técnicas nuevas para lograr una colaboración
superior, una entrega más rápida y, lo más importante,
productos dramáticamente mejores.
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 usar para acelerar los resultados en
toda la empresa. Podemos dejar de perder el tiempo discutiendo sobre quién tiene la culpa
y qué departamento debe gobernar el día.
Tengo la esperanza de que todos recordemos prestar atención al llamado de Jeff Gothelf
de "salir del negocio de los entregables" y volver a centrarnos en el lugar al que pertenece,
involucrando a toda la corporación en su tarea más urgente: deleitar a los clientes.
Es hora de romper los silos, unir los clanes y ponerse a trabajar.
eric ries
30 de enero de 2013
San Francisco, CA
Prefacio XI
www.it-ebooks.info
www.it-ebooks.info
Prefacio
La mentira más grande en el software es la Fase II.
Si ha dedicado algún tiempo a crear productos digitales en los últimos 20 años:

independientemente de tu papel, has sentido el aguijón de esta mentira. Dejas de lado características
e ideas para la siguiente fase del trabajo y luego desaparecen, y nunca más se sabe de ellas. Como
diseñador, cientos, si no miles, de wireframes y flujos de trabajo terminaron en este mismo cubo.
Pero, ¿desaparecieron estas ideas porque tenían fallas? ¿Las características que se enviaron
realmente cumplieron con los objetivos comerciales y del cliente, por lo que las ideas de la Fase II
nunca fueron necesarias? ¿O simplemente se le acabó el tiempo al equipo? El equipo nunca llegó a
la Fase II.
En The Lean Startup, Eric Ries expone su visión sobre cómo garantizar que las ideas que tienen el
mayor valor obtengan la mayor cantidad de recursos. El método que promueve Ries se basa en la
experimentación, la iteración rápida de ideas y los procesos evolutivos. Para Ries, todo el concepto
de la Fase II se vuelve discutible.
La unión de Lean Startup y el diseño basado en la experiencia del usuario (UX)—

y su coexistencia simbiótica es Lean UX.
¿Qué es Lean UX y en qué se diferencia?

Los principios Lean subyacentes a Lean Startup se aplican a Lean UX de tres maneras. Primero,
nos ayudan a eliminar el desperdicio de nuestro proceso de diseño de UX. Nos alejamos de las
transferencias fuertemente documentadas a un proceso que crea solo los artefactos de diseño que
necesitamos para hacer avanzar el aprendizaje del equipo.
En segundo lugar, nos impulsan a armonizar nuestro "sistema" de diseñadores, desarrolladores,
gerentes de productos, ingenieros de control de calidad, especialistas en marketing y otros.
XIII
www.it-ebooks.info
en una colaboración transparente y multifuncional que incorpora a personas que no son

diseñadores a nuestro proceso de diseño. Por último, y quizás lo más importante, está el
cambio de mentalidad que obtenemos al adoptar un modelo basado en la experimentación.
En lugar de depender de un diseñador héroe para adivinar la mejor solución desde un único
punto de vista, utilizamos la experimentación y la medición rápidas para aprender rápidamente
qué tan bien (o no) nuestras ideas cumplen con nuestros objetivos. En todo esto, el rol del
diseñador comienza a evolucionar hacia la facilitación del diseño, y con eso asumimos un
nuevo conjunto de responsabilidades.
Además de Lean Startup, Lean UX tiene otros dos fundamentos: pensamiento de diseño y
filosofías de desarrollo Agile. El pensamiento de diseño adopta un enfoque centrado en la
solución para la resolución de problemas, trabajando en colaboración para iterar un camino
interminable y cambiante hacia la perfección. Trabaja hacia los objetivos del producto a
través de pasos específicos de ideación, creación de prototipos, implementación y aprendizaje
para sacar a la luz la solución adecuada. Agile reenfoca el desarrollo de software en el valor.
Busca entregar software que funcione a los clientes rápidamente y ajustarse regularmente al
nuevo aprendizaje en el camino.
Lean UX utiliza estos cimientos para romper el estancamiento entre la velocidad de Agile y
la necesidad de diseño en el ciclo de vida del desarrollo del producto. Si ha tenido problemas
para descubrir cómo el diseño de UX puede funcionar en entornos ágiles, Lean UX puede
ayudarlo.
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 a los diseñadores de software a la mesa, sino que también trae a
nuestros socios comerciales y tecnológicos a la pizarra para trabajar con nosotros en las
mejores soluciones de manera continua.
Una vez tuve un gran cliente farmacéutico que contrató a la agencia para la que trabajaba
para rediseñar su plataforma de comercio electrónico con el objetivo de aumentar los
ingresos en un 15 por ciento. Yo era el diseñador principal de interacción en nuestro equipo.
En el vacío de nuestra oficina, pasamos meses investigando el sistema actual, la cadena de
suministro, los competidores, el público objetivo y los escenarios de uso contextual.
Investigamos personas y armamos modelos estratégicos. Diseñé una nueva arquitectura de
información para el catálogo de productos y elaboré una nueva experiencia de compra y
pago.
El proyecto tomó meses. Cuando el trabajo estuvo completo, lo empaquetamos todo en una
plataforma de PowerPoint. Esta era una plataforma formidable, ¡tendría que serlo,
considerando el precio de $ 600,000! Fuimos a la oficina del cliente y pasamos 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ó (de verdad). Ellos lo amaron. Nos sentimos
aliviados. Y nunca volvimos a mirar esa baraja.
XIV Prefacio
www.it-ebooks.info
Seis meses después de esa reunión, nada había cambiado en el sitio del cliente. Tampoco
creo que hayan vuelto a mirar esa baraja.
La moraleja de esta historia: crear una especificación de píxeles perfectos puede ser una
forma de 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 ningún diseñador entró en el negocio del diseño de productos. Entramos
para construir productos y servicios valiosos, no para escribir especificaciones.
Algunos equipos con los que trabajo hoy crean productos o servicios completamente nuevos.
No están trabajando dentro de un marco o estructura de producto existente.
En proyectos “green-field” como estos, simultáneamente tratamos de descubrir cómo se
usará este nuevo producto o servicio, cómo se comportará y cómo lo construiremos. Es un
entorno de cambio continuo, y no hay mucho tiempo o paciencia para la planificación o el
diseño inicial.
Otros equipos trabajan con productos establecidos que se crearon con métodos de diseño y
desarrollo tradicionales. Su desafío es diferente. Necesitan construir sobre las plataformas
existentes mientras aumentan los ingresos y el valor de la marca. Estos equipos suelen tener
más recursos a su disposición que una startup de planta baja, pero aun así tienen que utilizar
sus recursos de manera eficiente para crear productos y servicios que sus clientes realmente
desean.
A medida que aprendí a practicar Lean UX, tuve que superar la sensación de que estaba
mostrando un trabajo "feo", "inacabado" o "no listo". Trabajar de esta manera requiere el
apoyo de un equipo de alto funcionamiento. Debe saber, como equipo, que no lo hará bien la
primera vez y que todos están trabajando juntos para iterar su camino a seguir. Quiero que
ganes esa confianza también. En las páginas de este libro, he destilado los conocimientos y
las tácticas que me han permitido 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 para diseñadores de interacción que saben que pueden contribuir más y ser más
efectivos con sus equipos. También es para gerentes de productos que necesitan mejores
formas de definir sus productos con sus equipos y validarlos con sus clientes. También es
para desarrolladores que entienden que un entorno de equipo colaborativo conduce a un
mejor código y un trabajo más significativo. Y, por último, es para gerentes (gerentes de
equipos de experiencia del usuario, equipos de proyectos, líneas comerciales, departamentos
y empresas) que entienden la diferencia que puede marcar una gran experiencia del usuario.
Prefacio XV
www.it-ebooks.info
¿Tú qué sacas de esto?

El libro está organizado en tres secciones.
•La Sección I proporciona una descripción general y una introducción a Lean UX y sus
principios fundamentales. Expongo las razones por las que la evolución del proceso
de diseño de UX es tan crítica y describo qué es Lean UX. También discuto los
principios subyacentes que deberá comprender para que Lean UX sea exitoso.
•La Sección II se enfoca en el proceso. Cada capítulo da un paso en el ciclo Lean UX y

detalla claramente cómo hacer cada paso y por qué es importante. También comparto
ejemplos de cómo yo y otros hemos hecho estas cosas en el
pasado.
•La Sección III aborda la integración de prácticas Lean UX en su organización. Discuto

el papel de Lean UX dentro de un entorno de desarrollo Agile típico. También discuto
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
arraiguen.
Mi esperanza es que este libro sea una llamada de atención para los diseñadores de
experiencias de usuario que aún esperan la Fase II. Aunque el libro está repleto de
tácticas y técnicas para ayudar a que sus procesos evolucionen, me gustaría que recuerde
que Lean UX es, en esencia, una forma de pensar.
Una nota de Jeff

Hay muchas personas que han sido pacientes, solidarias e inspiradoras al escribir este
libro. Josh y yo queríamos tomarnos un momento para agradecerles.
En primer lugar, me gustaría agradecer a Eric Ries por impulsar el movimiento Lean
Startup e instarme a escribir este libro. Su apoyo llegó en varias formas, incluidas las
perspectivas sobre el papel del diseño en Lean Startup y la experiencia con el proceso de
escritura de libros. Sirvió como proverbial hombro para llorar, en más de una ocasión.
A continuación, me gustaría agradecer a Mary Treseler, mi editora en O'Reilly. Pasamos

muchas horas en correos electrónicos, llamadas telefónicas y reuniones ocasionales en
persona trabajando en estrategias editoriales, tácticas de escritura y reseñas para llegar,
triunfalmente, debo agregar, al libro que tenemos hoy. Gracias.
En el camino, me asocié con Matthew Rothenberg para superar el obstáculo de las

revisiones de mitad de ciclo. Su camaradería, humor, ingenio y orientación editorial
ayudaron a dar forma a la versión final del libro y agregaron una humanidad muy necesaria
a las palabras.
XVI Prefacio
www.it-ebooks.info
Me gustaría agradecer a mi compañero de escritura Josh Seiden. Pasamos

mucho tiempo trabajando, enseñando, viajando y saliendo juntos en 2012, por lo
que tenía sentido lógico que él se uniera al proyecto y ayudara a llevarlo a la
meta. El libro no sería lo que es hoy sin su perspicacia y estilo de edición de
amor duro. Soy un mejor escritor por ello y este es un mejor libro gracias a él.
Gracias, Josh.
En particular, me gustaría agradecer a las muchas personas que han contribuido

con material para el libro. Al final del proyecto, teníamos más estudios de casos
y contribuciones de las que podíamos usar, por lo que parte del maravilloso
material que compartieron nuestros colegas no encajaba en el manuscrito. Este
número refleja más nuestro proceso de escritura que la calidad de la contribución.
Dicho esto, gracias a Stuart Eccles, Ian Collingwood, Lane Halley, James
O'Brien, Adam Silver, Antoine Veliz, Anders Ramsay, Desiree Sy, Zach Larson,
Emily Holmes, Greg Petroff y Duane Bray.
Muchos de los equipos con los que he trabajado a lo largo de los años inspiraron
las ideas cubiertas en el libro. Los aprendimos juntos y ayudamos a construir
mejores productos juntos, así como equipos más felices y productivos. Sé que
verá su influencia en los estudios de casos, historias y anécdotas en estas páginas.
Finalmente, quiero agradecer el amor, la paciencia y el apoyo que he recibido

de mi familia durante los 18 meses que me tomó llegar a un manuscrito final. Mi
esposa Carrie ha lidiado con demasiadas horas conmigo encerrado en mi oficina
tocando el teclado. Ese sacrificio no se me escapa. Mis hijas Grace y Sophie
también han visto demasiado a su padre acurrucado frente a su computadora
portátil. Estoy seguro de que están deseando volver a tenerme en su vida. Los
amo chicos. Gracias.
Una nota de Josh

En este libro, Jeff y yo describimos un estilo de trabajo profundamente
colaborativo. Ese es mi estilo de trabajo preferido: siempre siento que aprendo
más y soy más eficaz cuando colaboro. Todo lo que he podido contribuir a este
libro es el resultado de las increíbles colaboraciones que he tenido la suerte de
disfrutar en mi carrera.
Sin embargo, hay algunas personas que me gustaría destacar. Alan Cooper me
enseñó por primera vez lo que significa diseñar software. Trabajando con Alan,
conocí a Jeanine Harriman, quien (muchos años después) me abrió los ojos a
muchas de las técnicas informales y colaborativas que describimos en este libro.
Janice Fraser me presentó Lean Startup y me dio la oportunidad de explorar
estas técnicas en LUXr (Lean UX Residency). Lauralee Alben me dio el coraje
de abrir un estudio para seguir estas ideas, y Giff Constable me dio una patada
en el trasero para abrir ese estudio. mis amigos en
Prefacio XVII
www.it-ebooks.info
el grupo Balanced Team (http:// www.balancedteam.org) ha tenido una profunda

influencia en mi forma de pensar.
Un agradecimiento especial para Lane Halley, quien es una de las practicantes más
talentosas que he conocido y una querida amiga. Cada vez que estoy confundido, me
pregunto: "¿Qué haría Lane?" y normalmente encuentro un camino a seguir.
Quiero agradecer a Jeff por invitarme a unirme a él para llevar este libro al mercado.
El libro está en su voz porque esta es su historia. También ha sido su bebé, su pasión
y su carga durante mucho tiempo, así que estoy agradecido de que me haya abierto
la puerta para unirme a él. Estoy continuamente impresionado por su habilidad para
colaborar con gracia. Jeff y yo hemos pasado mucho tiempo trabajando juntos este
año y estoy muy orgulloso de esa colaboración.
Gracias, finalmente, a Vicky, Naomi y Amanda. te quiero.
De Jeff y Josh
Este libro es nuestro intento de capturar lo que sabemos sobre Lean UX en este
momento. Los métodos Lean son métodos de aprendizaje, y esperamos aprender y
descubrir más a medida que continuamos nuestro viaje. A medida que avanza por
este camino, nos encantaría saber sobre su viaje, sus éxitos, desafíos y fracasos,
para que podamos seguir aprendiendo a través de nuestra colaboración con usted.
Por favor, manténgase en contacto con nosotros y comparta sus pensamientos.
Puede comunicarse con nosotros en jeff@jeffgothelf.com y josh@joshuaseiden.com.
Esperamos con interés escuchar de usted.
XVIII Prefacio
www.it-ebooks.info
Sección I:
Introducción y
principios
En esta primera sección, ofrezco una introducción a Lean UX y sus principios fundamentales.
Discuto por qué la evolución del proceso de diseño de UX es tan crítica y describo qué es
Lean UX. También discuto los principios subyacentes que deberá comprender para que Lean
UX sea exitoso.
Capítulo 1, "¿Por qué Lean UX?" proporciona una breve historia del diseño de UX y por qué
es el momento adecuado para la evolución de ese proceso de diseño.
En el Capítulo 2, "Principios", presento una mirada detallada a los principios clave que
impulsan el proceso Lean UX. Estos principios ofrecen un marco para un proceso de diseño
de productos más ágil y también brindan pautas de gestión básicas para los equipos de
diseño de productos. Son fundamentales para el éxito de Lean UX y, si se incorporan a su
organización, tendrán un profundo impacto en su cultura y en la productividad y el éxito de
sus equipos.
www.it-ebooks.info
www.it-ebooks.info
Capítulo 1
¿Por qué Lean UX?
Cuando trajimos nuestro oficio al software en las décadas de 1980 y 1990, los
diseñadores abordaron el software de la misma manera que abordamos los materiales
anteriores con los que trabajábamos. En diseño industrial, diseño de estampados,
diseño de moda y 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é estamos haciendo antes de comenzar la producción, porque la
producción es costosa. Es costoso establecer una planta de producción para producir
bienes duraderos o prendas de vestir. Es costoso configurar una imprenta para una tirada.
Al trabajar en software, los diseñadores enfrentaron nuevos desafíos. Tuvimos que

descifrar la gramática de este nuevo medio y, mientras lo hacíamos, vimos surgir
nuevos lazos especiales, como el diseño de interacción y la arquitectura de la
información. Pero el proceso por el cual los diseñadores practicaron se mantuvo
prácticamente sin cambios. Todavía diseñábamos productos con gran detalle por
adelantado, porque todavía teníamos que lidiar con un proceso de "fabricación":
nuestro trabajo tenía que duplicarse en disquetes y CD, que luego se distribuían al
mercado exactamente de la misma manera que los bienes físicos. repartido. El costo
de equivocarse seguía siendo alto.
Hoy nos enfrentamos a una nueva realidad. Internet ha cambiado la distribución de

software de forma radical. La mayoría del software ahora se distribuye en línea. Ya no
estamos limitados por un proceso de fabricación físico y somos libres de trabajar en
ciclos de lanzamiento mucho más cortos.
Pero "gratis" realmente subestima esta nueva realidad. Los equipos ahora se enfrentan
a una intensa presión de los competidores que utilizan técnicas como el desarrollo ágil
de software, la integración continua y la implementación continua para
www.it-ebooks.info
reducir radicalmente sus tiempos de ciclo. Los equipos están enviando código nuevo a
producción tan rápido como se puede guardar un archivo de Photoshop. Y están utilizando
estos ciclos cortos como una ventaja competitiva: lanzando pronto y con frecuencia, obteniendo
comentarios del mercado e iterando en función de lo que aprenden y (quizás sin darse cuenta)
elevando las expectativas de los clientes en términos de calidad y tiempos de respuesta.
En esta nueva realidad, los enfoques tradicionales de "resolver todo primero" no son viables.
Entonces, ¿qué deben hacer los diseñadores?
Es tiempo de un cambio. Lean UX (UX = experiencia de usuario) es la evolución del diseño de

productos. Toma las mejores partes del conjunto de herramientas del diseñador y las recombina
de una manera que las hace relevantes para esta nueva realidad.
Lean UX es profundamente colaborativo y multifuncional, porque ya no podemos darnos el lujo

de trabajar aislados del resto del equipo del producto.
No podemos seguir pidiendo a nuestros equipos que esperen a que lo resuelvamos todo.
Necesitamos un compromiso diario y continuo con nuestros equipos si queremos ser efectivos.
Este compromiso continuo nos permite despojarnos de entregables pesados en favor de
técnicas que nos permitan construir una comprensión compartida .
con nuestros compañeros.
Lean UX también nos permite cambiar la forma en que hablamos de diseño. En lugar de
hablar de funciones y documentos, podemos hablar de lo que funciona. En esta nueva realidad,
tenemos más acceso que nunca a los comentarios del mercado. Esta retroalimentación nos
permite replantear las conversaciones de diseño en términos de metas comerciales objetivas.
Podemos medir lo que funciona, aprender y ajustar.
Lean UX es tres cosas. Es más fácil de entender como un cambio de proceso para los
diseñadores. Pero es más que eso. Es una mentalidad que nos permite abordar nuestro trabajo
de nuevas maneras. También es una forma de pensar en la gestión del software.
Profundizaré en cada uno de estos conceptos a lo largo del libro. En el próximo capítulo,
veremos los principios que sientan las bases para el diseño Lean UX.
4 Capítulo 1
www.it-ebooks.info
Capitulo 2
Principios
En el corazón de Lean UX, encontrará un conjunto básico de principios. Estos principios

cubren el proceso, la colaboración, la gestión y más. Los equipos guiados por todos estos
principios sacarán el máximo provecho del enfoque Lean UX.
Comience con estos principios para que sus equipos apunten en la dirección correcta y
téngalos en cuenta cuando comience a implementar los procesos Lean UX que describo
más adelante en este libro. Inevitablemente, tendrá que ajustar los procesos Lean UX para
adaptarlos a su organización, y los principios explicados en este capítulo le brindarán
orientación para ese trabajo.
En última instancia, si puede poner en práctica estos principios, descubrirá que cambiará la
cultura de su organización. Algunos tendrán más impacto que otros y serán más difíciles de
impulsar. Otros serán más fáciles de actuar. Independientemente, cada principio detallado
aquí lo ayudará a construir una organización de diseño de productos que sea más
colaborativa, más interfuncional y más útil para la realidad actual.
Los tres fundamentos de Lean UX

Lean UX se basa en tres cimientos. El primer fundamento es el pensamiento de diseño.
Tim Brown, director ejecutivo y presidente de la legendaria firma de diseño IDEO, describió
el pensamiento de diseño como “innovación impulsada por… la observación directa de lo
que la gente quiere y necesita en sus vidas y lo que les gusta o disgusta de la forma en que
se fabrican, empaquetan, comercializan y comercializan determinados productos. vendido y
respaldado... [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
www.it-ebooks.info
una estrategia comercial viable puede convertirse en valor para el cliente y oportunidad
de mercado.”1
El pensamiento de diseño es importante para Lean UX porque toma la posición

explícita de que todos los aspectos de un negocio se pueden abordar con métodos
de diseño. Da permiso a los diseñadores y un precedente para trabajar más allá de
sus límites típicos. También alienta a los no diseñadores a usar métodos de diseño
para resolver los problemas que enfrentan en sus funciones. El pensamiento de
diseño es una base fundamental que alienta a los equipos a colaborar entre roles y
considerar el diseño de productos desde una perspectiva holística.
La segunda base de Lean UX es el desarrollo de software Agile. Los desarrolladores

de software han estado utilizando métodos Agile durante años para reducir sus tiempos
de ciclo y brindar valor al cliente de manera continua. Aunque los métodos Agile
pueden plantear desafíos de proceso para los diseñadores (las soluciones se
proporcionan en la Sección III), los valores centrales de Agile están en el corazón de
Lean UX. Lean UX aplica los cuatro principios básicos del desarrollo Agile al diseño de productos:
1. Individuos e interacciones sobre procesos y herramientas. Para generar las

mejores soluciones rápidamente, debe involucrar a todo el equipo. Las ideas
deben intercambiarse libre y frecuentemente. Las limitaciones de los procesos y
herramientas de producción actuales se evitan en favor de la conversación con
colegas.
2. Software de trabajo sobre documentación completa. Cada problema

empresarial tiene infinitas soluciones, y cada miembro de un equipo tendrá una
opinión sobre cuál es la mejor. El desafío es averiguar qué solución es la más
viable. Al crear software que funcione antes, se puede evaluar la viabilidad y el
ajuste del mercado de las soluciones.
3. Colaboración con el cliente en la negociación del contrato. La colaboración

con sus compañeros de equipo y clientes genera 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 en equipo en aprendizaje validado. También
reduce la dependencia de una documentación pesada, ya que todos los
miembros del equipo ya han participado en la toma de decisiones que solían
requerir comunicación y defensa por escrito.
4. Responder al cambio sobre seguir un plan. La suposición en Lean UX es que

los diseños iniciales del producto serán incorrectos, por lo que el objetivo debe
ser descubrir qué es lo que está mal con ellos lo antes posible. Una vez que
descubrimos qué funciona y qué no, ajustamos nuestras propuestas y volvemos
a probar. Este aporte del mercado nos mantiene ágiles y nos empuja
constantemente en una dirección “más correcta”.
1 http:// hbr.org/ 2008/06/ design-thinking/ ar/ 1
6 Capitulo 2
www.it-ebooks.info
El tercer fundamento de Lean UX es el método Lean Startup fundado por Eric Ries.
Lean Startup utiliza un circuito de retroalimentación llamado "construir-medir aprender"
para minimizar el riesgo del proyecto y hace que los equipos desarrollen 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 inicialmente aboga por la creación de prototipos
rápidos diseñados para probar los supuestos del mercado y utiliza los comentarios
de los clientes para evolucionarlos mucho más rápido que las prácticas de ingeniería
de software más tradicionales... Los procesos Lean Startup reducen el desperdicio al
aumentar la frecuencia de contacto con clientes reales, por lo tanto, probar y evitar
suposiciones de mercado incorrectas lo antes posible.”2 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. El MVP no tiene que estar hecho de código; puede ser una
aproximación de la experiencia final. Recopila lo que aprende de su MVP y luego
desarrolla sus ideas. Entonces lo vuelves a hacer.
La práctica de Lean UX es: Lean UX es la práctica de sacar a la luz la verdadera

naturaleza de un producto más rápido, de una manera colaborativa y multifuncional
que reduce el énfasis en la documentación exhaustiva y aumenta el enfoque en la
construcción de una comprensión compartida del experiencia real del producto que
se está diseñando.
Principios
En el resto de este capítulo, expondré los principios detrás de Lean UX. Mientras
explora el enfoque Lean UX, tenga en cuenta estos principios. Piense en su
experiencia con Lean UX como un viaje de aprendizaje. Utilice estos principios para
mantener su rumbo y el de su equipo.
Principio: Equipos Multifuncionales ¿Qué
es? Los equipos multifuncionales están formados por las diversas disciplinas
involucradas en la creación de su producto. La ingeniería de software, la gestión de
productos, el diseño de interacción, el diseño visual, la estrategia de contenido, el
marketing y el control de calidad (QA) deben incluirse en un equipo 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.
2 El Lean Startup (Crown Business, 2011).
Principios 7
www.it-ebooks.info
¿Por que hacerlo? La creación de estos equipos diversos colapsa el proceso de traspaso
controlado conocido como cascada. Se aporta información sobre cada idea de todas las
disciplinas relevantes al principio del proceso. Se fomenta la conversación entre silos
funcionales, lo que impulsa una mayor eficiencia del equipo.
Principio: Pequeño, Dedicado, Colocado
¿Qué es? Mantenga sus equipos pequeños: no más de 10 personas principales en total.
Dedíquelos a un proyecto y dote de personal para todo desde la misma ubicación.
¿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 mantener actualizados
sobre el estado del proyecto, los cambios y el nuevo aprendizaje. Dedicar a su equipo a un
proyecto mantiene a todos en el equipo enfocados en las mismas prioridades todo el tiempo.
Tener todo el equipo en un solo lugar permite que crezcan las relaciones entre colegas.
Principio: Progreso = Resultados, No Producto
¿Qué es? Las características y los servicios son salidas. Los objetivos comerciales que
deben lograr son resultados. Lean UX mide el progreso en términos de resultados comerciales
definidos explícitamente.
¿Por que hacerlo? Cuando tratamos de predecir qué características lograrán resultados
específicos, en su mayoría nos dedicamos a la especulación. Si bien es más fácil administrar
el lanzamiento de conjuntos de funciones específicas, no sabemos de manera significativa si
una función es efectiva hasta que está en el mercado.
Al gestionar los resultados (y el progreso realizado hacia ellos), obtenemos información sobre
la eficacia de las funciones que estamos creando. Si una función no funciona bien, podemos
tomar una decisión objetiva sobre si se debe mantener, cambiar o reemplazar.
Principio: Equipos Centrados en Problemas
¿Qué es? Un equipo centrado en el problema es aquel al que se le ha asignado un

problema comercial para resolver, en lugar de un conjunto de características para implementar.
Esta es la extensión lógica del enfoque en los resultados.
¿Por que hacerlo? Asignar problemas a los equipos para que los resuelvan muestra confianza en
esos equipos. Les permite idear sus propias soluciones y genera un sentido más profundo
de orgullo y propiedad en las soluciones que implementa el equipo.
Principio: Eliminación de desechos
¿Qué es? Uno de los principios fundamentales de la producción Lean es la eliminación

de cualquier cosa que no conduzca al objetivo final. En Lean UX, lo último
8 Capitulo 2
www.it-ebooks.info
el objetivo 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. Cuantos más residuos pueda eliminar el
equipo, más rápido podrán moverse. Los equipos quieren trabajar en los desafíos correctos.
Quieren ser efectivos. Una disciplina de eliminación de desperdicios puede ayudar a los equipos
a mantener su enfoque láser donde corresponde.
Principio: Tamaño de lote pequeño
¿Qué es? Otro aspecto fundamental de la manufactura esbelta es el uso de lotes pequeños.
La manufactura esbelta utiliza esta noción para mantener el inventario bajo y la calidad alta.
Traducido a Lean UX, este concepto significa crear solo el diseño necesario para hacer avanzar
al equipo y evitar un gran "inventario" de ideas de diseño no probadas ni implementadas.
¿Por que hacerlo? El diseño de lotes grandes hace que el equipo sea menos eficiente. Obliga al
equipo a esperar grandes entregas de diseño. Evita que el equipo sepa si sus ideas son válidas.
Mantiene a algunos compañeros de equipo inactivos e inevitablemente da como resultado
activos de diseño que no se utilizan. Este enfoque es un desperdicio y no maximiza todo el
potencial de aprendizaje del equipo.
Principio: descubrimiento continuo
¿Qué es? El descubrimiento continuo es el proceso continuo de involucrar al cliente

durante el proceso de diseño y desarrollo. Este compromiso se realiza a través de actividades
programadas regularmente, utilizando métodos tanto cuantitativos como cualitativos. El objetivo
es comprender qué hacen los usuarios con sus productos y por qué lo hacen. La investigación
se realiza en horarios frecuentes y regulares. La investigación involucra a todo el equipo.
¿Por que hacerlo? Las conversaciones periódicas con los clientes brindan oportunidades
frecuentes para validar nuevas ideas de productos. Al involucrar a todo el equipo en el ciclo de
investigación, el equipo desarrollará empatía por los usuarios y los problemas que enfrentan.
Finalmente, a medida que el equipo aprende en conjunto, reduce la necesidad de futuras
conversaciones y documentación de informes.
Principio: GOOB: El nuevo usuario centrado
¿Qué es? Puede sonar como la primera palabra de un bebé, pero GOOB es en realidad un
acrónimo de lo que el profesor, empresario y autor de Stanford, Steve Blank, llama "salir del
edificio". Es darse cuenta de que los debates en la sala de reuniones sobre las necesidades de
los usuarios no se resolverán de manera concluyente dentro de su oficina.
En cambio, las respuestas se encuentran en el mercado, fuera de su edificio.
Principios 9
www.it-ebooks.info
Después de años de abogar por la investigación de clientes, la comunidad UX tiene un

campeón del mundo empresarial en Steve Blank. La receta de Blank: brinde a los
clientes potenciales la oportunidad de proporcionar comentarios sobre sus ideas antes
de lo que lo hubiera hecho 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 dedicado tiempo y recursos a crear un producto que
nadie quiere.
¿Por que hacerlo? En última instancia, el éxito o el fracaso de su producto no es una decisión
del equipo, sino de los clientes. Tendrán que hacer clic en el botón "Comprar ahora"
que usted diseñó. Cuanto antes les des una voz, antes sabrás si tienes una idea que
está lista para ser construida.
Principio: entendimiento compartido

¿Qué es? La comprensión compartida es el conocimiento colectivo del equipo que
se acumula con el tiempo a medida que el equipo trabaja en conjunto. Es una rica
comprensión del espacio, el producto y los clientes.
¿Por que hacerlo? La comprensión compartida es la divisa de Lean UX. Cuanto más
comprenda colectivamente un equipo lo que está haciendo y por qué, menos tendrá
que depender de informes de segunda mano y documentos detallados para continuar
con su trabajo.
Principio: Anti-Patrón: Rockstars, Gurus y Ninjas

¿Qué es? Lean UX aboga por una mentalidad basada en el equipo. Rockstars,
gurús, ninjas y otros expertos de élite de su oficio rompen la cohesión del equipo y
evitan la colaboración.
¿Por que hacerlo? Los rockstars no comparten, ni sus ideas ni el centro de atención.
La cohesión del equipo se rompe cuando se agregan personas con grandes egos que
están decididas a sobresalir y ser estrellas. Cuando la colaboración se rompe, pierde el
entorno que necesita para crear el entendimiento compartido que le permite [para evitar
la repetición] avanzar de manera efectiva.
Principio: externalizar su trabajo

¿Qué es? Externalizar significa sacar su trabajo de su cabeza y de su computadora
y ponerlo a la vista del público. Los equipos usan pizarras blancas, tableros 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 saca ideas de la cabeza de los compañeros de equipo
y las pone en la pared, lo que permite que todos vean dónde se encuentra el equipo.
Crea un flujo de información pasivo y ambiental en todo el equipo. Inspira nuevas ideas
que se basan en las que ya se han compartido. Permite a todos los miembros
10 Capitulo 2
www.it-ebooks.info
del equipo, incluso los más callados, para participar en actividades de intercambio de
información. Sus notas adhesivas o bocetos en la pizarra son tan ruidosos como los de la
persona más destacada del equipo.
Principio: Análisis de transformación

¿Qué es? Análisis de transformación de valores Lean UX. Tiene más valor crear la
primera versión de una idea 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. En cambio, serán respondidas por los clientes
en el campo. Para obtener esas respuestas, debe concretar las ideas: debe crear algo a
lo que la gente responda. Debatir ideas es un desperdicio. En lugar de analizar escenarios
potenciales, haga algo y salga del edificio con eso.
Principio: aprendizaje sobre crecimiento

¿Qué es? Es difícil descubrir qué es lo correcto para construir y escalar un negocio
en torno a eso al mismo tiempo. Son actividades contradictorias. Lean UX favorece un
enfoque en aprender primero y escalar en segundo lugar.
¿Por que hacerlo? Escalar una idea que no está probada es arriesgado. Podría funcionar. Y
puede que no. Si no funciona y lo escalaste a toda tu base de usuarios, tu equipo habrá
desperdiciado tiempo y recursos valiosos. Asegurarse de que una idea es correcta antes
de escalarla mitiga el riesgo inherente a la implementación de funciones amplias.
Principio: Permiso para fallar

¿Qué es? Para encontrar la mejor solución a los problemas comerciales, los equipos
de Lean UX deben experimentar con ideas. La mayoría de estas ideas fracasarán.
El equipo debe estar seguro de fallar si quiere tener éxito. permiso para fallar
significa que el equipo tiene un entorno seguro en el que experimentar. Esa filosofía se
aplica tanto al entorno técnico (pueden impulsar ideas de manera segura) como al entorno
cultural (no serán penalizados por intentar ideas que no tengan éxito).
¿Por que hacerlo? El permiso para fallar genera una cultura de experimentación. La
experimentación genera creatividad. La creatividad, a su vez, produce soluciones innovadoras.
Cuando los equipos no temen por sus trabajos si se equivocan en algo, son más
propensos a correr riesgos. Es a partir de esos riesgos que finalmente surgen las grandes ideas.
Finalmente, como ilustra tan bellamente la siguiente anécdota, los fracasos frecuentes
conducen a un mayor dominio de las habilidades.
Principios 11
www.it-ebooks.info
En un video llamado "Por qué necesitas fallar" (http://www.youtube.com/

reloj?v=HhxcFGuKOys), El fundador de CD Baby, Derek Sivers, describe los
sorprendentes resultados de una clase de cerámica. El primer día, el instructor anunció
a su clase que los estudiantes se dividirían en dos grupos.
La mitad de los estudiantes necesitarían hacer solo 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 ollas que
hicieron durante el semestre. Si hicieran 50 libras de ollas o más, obtendrían una A.
Cuarenta libras obtendrían una B; 30 libras, una C; y así.
Lo que realmente hicieron era irrelevante. El instructor dijo que ni siquiera miraría sus
ollas. Traía su báscula de baño al último día de clase y pesaba 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". Se habían pasado todo el semestre trabajando lo más rápido que podían
para hacer vasijas. A veces lo conseguían y otras veces fracasaban. 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 barro de alta calidad.
Por el contrario, el grupo que hizo un objeto no tuvo el beneficio de esas iteraciones
fallidas y no aprendió lo suficientemente rápido como 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
visión grandiosa.
Principio: salir del negocio de los entregables

¿Qué es? Lean UX reenfoca el proceso de diseño de los documentos que el equipo
está creando a los resultados que el equipo está logrando. Con una mayor colaboración
interfuncional, la conversación de 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é características tienen el mayor
impacto en sus clientes. Los artefactos que usa el equipo para obtener ese conocimiento
son irrelevantes. Todo lo que importa es la calidad del producto, medida por la reacción
del mercado.
12 Capitulo 2
www.it-ebooks.info
Conclusión: principios Este

capítulo presenta un conjunto de principios fundamentales para Lean UX.
Estos son los atributos centrales que cualquier equipo Lean UX debe incorporar. A
medida que comience a formar su práctica de Lean UX, lo animo a utilizar estos principios
para definir la composición, la ubicación, los objetivos y las prácticas de su equipo.
En la Sección II, pondré en práctica estos principios mientras detallo todo el proceso
Lean UX.
Principios 13
www.it-ebooks.info
www.it-ebooks.info
S e c c ión II:
Proceso
Es martes y Rick, Mark, Olga y Arti están parados frente a la pizarra,

mirando una estructura alámbrica que han dibujado. Arti tiene un marcador en
la mano, pero no está dibujando. “Rick, no entiendo a qué te diriges. ¿Puedes
explicar el problema?”
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 comerciantes de
acciones, y la aplicación debe obedecer un estricto conjunto de normas. Rick, el
analista de negocios, es responsable de asegurarse de que los diseños del equipo
cumplan con las reglas.
Al rato, el equipo asiente y Arti vuelve a tomar el marcador.

Ella sugiere un cambio en el diseño de la estructura alámbrica de la
aplicación en la pizarra y el equipo vuelve a asentir. Todos sacan sus iPhones,
toman fotos de la junta y acuerdan volver a reunirse al día siguiente. Confían en
que lo que acordaron estará listo para las pruebas de los usuarios el jueves.
www.it-ebooks.info
Arti, la diseñadora, vuelve a su escritorio para empezar a detallar el diseño que

han esbozado. Mark, el desarrollador front-end, comienza a crear la página; usa
componentes prefabricados de la guía de estilo de vida que el equipo ha
implementado, por lo que no necesita esperar a Arti antes de colocar las piezas
básicas en su lugar. Rick abre el 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 tarde ese mismo
día. Y Olga, la evaluadora de control de calidad, comienza el proceso de redacción
de pruebas para la nueva sección de la aplicación.
Este es el ritmo diario de Lean UX: un equipo que trabaja de forma colaborativa, iterativa y en
paralelo, con pocas transferencias, entregas mínimas y un enfoque en el software funcional y la
retroalimentación del mercado. En esta sección, verás cómo se hace.
En la sección anterior, le mostré las ideas detrás de Lean UX, los principios que impulsan el
trabajo. En esta sección, me pongo muy práctico y describo en detalle el proceso de
implementación de Lean UX.
El Capítulo 3, "Visión, encuadre y resultados", describe cómo Lean UX cambia radicalmente la

forma en que enmarcamos nuestro trabajo. Nuestro objetivo no es crear un resultado, es cambiar
algo en el mundo: crear un resultado. En este capítulo describiré la herramienta clave que
usamos para hacer esto: declaraciones de hipótesis.
El Capítulo 4, "Diseño colaborativo", describe el cambio en nuestro proceso de diseño.

Lean UX utiliza muchas técnicas familiares para los diseñadores, pero cambia el énfasis de
nuestro trabajo. Nos volvemos más colaborativos. Nuestro objetivo es la velocidad primero.
Priorizamos el aprendizaje. Utilizamos una herramienta clave para lograrlo: el MVP.
El capítulo 5, "MVP y experimentos", trata sobre experimentos. Lean UX se basa en la idea de

que comenzamos nuestro trabajo con una suposición. Usamos experimentos para probar
nuestras suposiciones y luego construimos sobre lo que aprendemos en esos experimentos.
Este capítulo le muestra cómo orientar su proceso de diseño en torno a los experimentos y el
aprendizaje.
El capítulo 6, “Retroalimentación e investigación”, trata sobre la retroalimentación. El trabajo de

experiencia del usuario en cualquier forma requiere una buena aportación de los usuarios. Lean
UX valora la retroalimentación continua para ayudarnos a guiar nuestro proceso de diseño. Este
capítulo le muestra las técnicas que utilizan los equipos de Lean UX para obtener comentarios
temprano y con frecuencia, y cómo incorporar esos comentarios en futuras iteraciones de productos.
www.it-ebooks.info
Capítulo 3
Visión, marco y resultados
Si no está de acuerdo con el experimento, está mal.
Dr.Richard Feynman
Tradicionalmente, los proyectos de diseño de UX están enmarcados por requisitos y

entregables; los equipos reciben requisitos y se espera que produzcan resultados.
Lean UX cambia radicalmente la forma en que enmarcamos nuestro trabajo. Nuestro
objetivo no es crear un resultado, es cambiar algo en el mundo: crear un resultado.
Comenzamos con suposiciones en lugar de requisitos. Creamos y probamos hipótesis.
Medimos para ver si hemos logrado nuestro deseado
resultados.
Este capítulo cubre la herramienta principal del trabajo centrado en los resultados: la
declaración de hipótesis. El enunciado de la hipótesis es el punto de partida de un
proyecto. Establece una visión clara para el trabajo y cambia la conversación entre los
miembros del equipo y sus gerentes de los productos (p. ej., “crearemos una función
de inicio de sesión único”) a los resultados (p. ej., “queremos aumentar la cantidad de
nuevos registros”). - ups a nuestro servicio”).
La declaración de hipótesis es una forma de expresar supuestos en forma comprobable.

Está compuesto por los siguientes elementos:
suposiciones
Una declaración de alto nivel de lo que creemos que es verdad.
17
www.it-ebooks.info
Hipótesis
Descripciones más granulares de nuestras suposiciones que se enfocan en áreas

específicas de nuestro producto o flujo de trabajo para la experimentación.
Resultados
La señal que buscamos del mercado para ayudarnos a validar o invalidar nuestras
hipótesis. Estos son a menudo cuantitativos, pero también pueden ser cualitativos.
Personas
Modelos de las personas para las que creemos que estamos resolviendo un problema.
Características
Los cambios o mejoras del producto que creemos generarán los resultados que
buscamos.
Echemos un vistazo a cada uno de estos elementos con más detalle.
suposiciones
El primer paso en el proceso Lean UX es declarar sus suposiciones. Cada proyecto comienza
con suposiciones, pero por lo general no reconocemos explícitamente este hecho. En cambio,
tratamos de ignorar las suposiciones o, peor aún, tratarlas como hechos.
Declarar sus suposiciones le permite a su equipo crear un punto de partida común. Al hacer
esto en equipo, le da a cada miembro del equipo, diseñadores y no diseñadores por igual, la
oportunidad de expresar su opinión sobre la mejor manera de resolver el problema. Pasar por
un ejercicio de declaración de suposiciones pone las ideas de todos en la pizarra. Revela la
divergencia de opiniones del equipo y también expone un amplio conjunto de posibles soluciones.
Declarar suposiciones es el primer paso en el proceso Lean UX; consulte la Figura 3-1.
Figura 3-1. Él Inclinarse proceso de paso,

experiencia de usuario 1
18 Capítulo 3
www.it-ebooks.info
Método: declaración de supuestos
Quién
Declarar suposiciones es un ejercicio de grupo. Reúna a su equipo, asegurándose de que

todas las disciplinas estén representadas, incluidos los expertos en la materia que podrían
tener conocimientos vitales sobre su proyecto. Por ejemplo, si está manejando una queja
frecuente de un cliente, podría ser beneficioso incluir un representante de servicio al cliente de
su centro de llamadas. Los representantes del centro de llamadas hablan con más clientes que
cualquier otra persona en la organización y probablemente tendrán información que el resto
del equipo no tendrá.
Preparación
Avise al equipo con anticipación del problema que abordarán para darles a todos la oportunidad
de preparar cualquier material que necesiten, o hacer cualquier investigación relacionada,
antes de comenzar. Las cosas importantes para preparar con anticipación incluyen:
1. Informes analíticos que muestran cómo se está utilizando el producto actual
2. Informes de usabilidad que ilustran por qué los clientes toman ciertas
acciones en tu producto
3. Información sobre intentos anteriores de solucionar este problema y sus éxitos

y fracasos
4. Análisis por parte del actor empresarial de cómo resolver este problema
afectará el desempeño de la empresa
5. Análisis competitivos que muestran cómo los competidores están abordando lo mismo
cuestiones
Método: Declaración del problema
El equipo necesita tener un punto de partida para el ejercicio. He encontrado útil comenzar
con una declaración del problema. (Vea la plantilla para esta declaración más adelante en esta
sección). La declaración del problema le da a su equipo un enfoque claro para su trabajo.
También define cualquier restricción importante. Necesita limitaciones para el trabajo en grupo.
Proporcionan las barandillas que mantienen al equipo conectado a tierra y alineado.
Visión, marco y resultados 19
www.it-ebooks.info
plantilla de enunciado del problema
Los enunciados de problemas se componen de tres elementos:
1. Los objetivos actuales del producto o sistema
2. El problema que la parte interesada del negocio quiere abordar (es decir, donde no se
cumplen los objetivos)
3. Una solicitud explícita de mejora que no dicta una determinada

solución
Modelo
[Nuestro servicio/producto] fue diseñado para lograr [estos

objetivos]. Hemos observado que el producto/ servicio no está
cumpliendo [estos objetivos], lo que está causando [este efecto adverso]
a nuestro negocio. ¿Cómo podríamos mejorar [servicio/producto] para
que nuestros clientes tengan más éxito según [estos criterios medibles]?
Por ejemplo, aquí hay una declaración de problema que usamos para comenzar un proyecto
en TheLadders, una firma de reclutamiento en línea donde trabajé. (Verá muchos más
ejemplos de TheLadders a lo largo de este libro).
Nuestro servicio ofrece un conducto entre los solicitantes de empleo y los empleadores
que intentan contratarlos. A través de nuestro servicio, los empleadores pueden llegar a
los solicitantes de empleo en nuestro ecosistema con oportunidades de empleo. Hemos
observado que un factor crítico que afecta la satisfacción del cliente es la frecuencia con la
que los buscadores de empleo responden a los mensajes del empleador. Actualmente, los
buscadores de empleo están respondiendo a estas comunicaciones a un ritmo muy bajo.
¿Cómo podemos mejorar la eficacia de nuestros productos de comunicación, haciendo así
que los empleadores tengan más éxito en sus trabajos y que las personas que buscan
empleo estén más satisfechas con nuestro servicio?
Las declaraciones de problemas están llenas de suposiciones. El trabajo del equipo es

diseccionar el enunciado del problema en sus suposiciones centrales. Puede hacerlo
utilizando la siguiente hoja de cálculo de supuestos comerciales. Tenga en cuenta que algunos equipos—
especialmente los equipos que comienzan desde cero, pueden no tener una declaración
clara del problema. Esta bien. Todavía puede probar la hoja de trabajo. Solo tendrá que
esperar que pueda llevar más tiempo llegar a un consenso sobre algunas de las preguntas.
20 Capítulo 3
www.it-ebooks.info
Hoja de trabajo de supuestos comerciales

Me gusta usar esta hoja de trabajo (creada por mi socio Giff Constable) para facilitar la discusión de
suposiciones. Hay muchas maneras de completar esta hoja de trabajo. Puede responder las preguntas en
equipo, simplemente discutiendo cada respuesta. O puede ejecutar un ejercicio estructurado de lluvia de
ideas/mapeo de afinidad para cada pregunta. Independientemente de cómo lo haga, recuerde que es
importante dar a todos la oportunidad de contribuir. Además, no se preocupe si llega al final de la hoja de
trabajo sin un acuerdo claro sobre todas las respuestas. El objetivo es recopilar afirmaciones que reflejen
lo que usted y su equipo piensan que podría ser cierto. Si tiene un fuerte desacuerdo sobre un punto,
capture las diferentes perspectivas.
Hoja de trabajo de suposiciones
Supuestos comerciales Suposiciones del usuario
1. Creo que mis clientes necesitan 1. ¿Quién es el usuario?

_______.
2. ¿Dónde encaja nuestro producto en su trabajo
2. Estas necesidades se pueden resolver con o vida?
_______.
3. ¿Qué problemas resuelve nuestro producto?
3. Mis primeros clientes son (o serán)
_______.
4. ¿Cuándo y cómo se utiliza nuestro producto?
4. El valor número 1 que un cliente quiere
salir de mi servicio es 5. El _______.

5. ¿Qué características son importantes?
cliente también puede obtener estos 6. ¿Cómo debe verse y comportarse nuestro
beneficios adicionales _______. producto?
6. Obtendré la mayoría de mis clientes a través

de _______.
7. Ganaré dinero antes de _______.
8. Mi principal competencia en el mercado será

_______.
9. Los venceremos por _______.
10. Mi mayor riesgo de producto es _______.
11. Resolveremos esto a través de _______.
12. ¿Qué otras suposiciones tenemos que, si se

demuestra que son falsas, harán que nuestro
negocio/proyecto fracase? _______.
Es posible que descubra que algunas de estas preguntas no se aplican a su proyecto. Está bien, puede
adaptar las preguntas a su situación como mejor le parezca. Si es temprano en la vida de su producto,
probablemente dedicará más tiempo a las suposiciones comerciales.
Si tiene un producto maduro, probablemente concentrará sus energías en las suposiciones del usuario.
El punto es lanzar una red amplia y buscar supuestos en todas las dimensiones de su proyecto.
Cuando haya completado la hoja de trabajo, tendrá una lista de declaraciones de supuestos. Su próximo
paso es priorizar estas suposiciones.
www.it-ebooks.info
Priorización de supuestos
La razón por la que declaramos suposiciones al comienzo de nuestro trabajo es para que podamos
identificar los riesgos del proyecto. Una vez que tenga una lista de suposiciones, debe averiguar
cuáles son las más riesgosas para poder trabajar en ellas primero.
Lean UX es un ejercicio de priorización despiadada. Entendiendo que no puede probar cada

suposición, ¿cómo decide cuál probar primero? Me gusta crear un gráfico como el de la Figura 3-2
y usarlo para trazar la lista de suposiciones.
El objetivo es priorizar un conjunto de suposiciones para probar en función de su nivel de riesgo

(es decir, ¿qué tan malo sería si nos equivocáramos en esto?) y cuánto conocimiento tenemos del
problema. Cuanto mayor sea el riesgo y más incógnitas involucradas, mayor será la prioridad para
probar esos supuestos.
Esto no significa que las suposiciones que no superen el primer corte se hayan ido para siempre.
Mantenga una lista de los otros supuestos que ha identificado para que pueda volver a ellos y
probarlos cuando tenga sentido hacerlo.
Figura 3-2. Matriz de priorización
Hipótesis
Con su lista priorizada de suposiciones en la mano, está listo para pasar al siguiente paso: probar
sus suposiciones. Para hacer eso, transforme cada declaración de suposición en un formato que
sea más fácil de probar: una declaración de hipótesis.
Generalmente, las declaraciones de hipótesis utilizan el formato:
Creemos [esta afirmación es verdadera].
Sabremos que estamos [bien/mal] cuando veamos los siguientes comentarios

del mercado:
22 Capítulo 3
www.it-ebooks.info
[retroalimentación cualitativa] y/ o [retroalimentación cuantitativa] y/ o

[cambio de indicador clave de desempeño].
Puedes ver que este formato tiene dos partes. Una declaración de lo que cree que
es verdad y una declaración de los comentarios del mercado que está buscando
para confirmar que tiene razón.
Expresar sus suposiciones de esta manera resulta ser una técnica realmente
poderosa. Elimina gran parte de la conversación subjetiva y política del proceso de
toma de decisiones y, en cambio, orienta al equipo hacia la retroalimentación del
mercado. También orienta al equipo hacia los usuarios y clientes.
Subhipótesis: dividir la hipótesis en partes

más pequeñas
A veces, si no la mayoría de las veces, descubrirá que su hipótesis es demasiado
grande para probarla con una sola prueba. Contendrá demasiadas partes móviles,
demasiadas subhipótesis. Cuando esto sucede, encuentro útil dividir la hipótesis
en partes más pequeñas y más específicas. Aunque hay muchas maneras de hacer
esto, he descubierto que este formato es muy útil para el trabajo de productos:
Creemos que
[haciendo esto/creando esta función/creando esta experiencia]
para [estas personas/personas]
logrará [este resultado].
Sabremos que esto es cierto cuando veamos
[esta retroalimentación del mercado, medida cuantitativa o conocimiento cualitativo].
El primer campo se completa con la característica o mejora que está considerando

realizar en su producto. El segundo campo describe exactamente cuáles de sus
clientes objetivo se beneficiarán de esta función. El último campo habla del beneficio
que esos clientes obtendrán de esa función. La declaración final lo une todo. Esta
es la declaración que determina si su hipótesis era verdadera. ¿Qué comentarios
del mercado buscará para indicar que su idea es correcta? Esta retroalimentación
podría ser un uso medido cuantitativamente de una función, un aumento en una
métrica comercial o una evaluación cualitativa de algún tipo.
www.it-ebooks.info
¡No todo son números! Vale la pena señalar que ha habido mucha reacción en el
mundo del diseño contra el diseño basado en mediciones. El argumento es que al
reducir cada decisión de diseño a factores que se pueden medir, le quitamos el deleite
y el alma a nuestros productos. De hecho, estoy de acuerdo con esta perspectiva, por
lo que creo que es tan importante incluir comentarios cualitativos en sus criterios de
éxito. ¿La gente está encantada con un diseño? ¿Recomiendan su producto a sus
amigos? ¿Tuitean al respecto? Cuando busque métricas de éxito, recuerde que no todo son números.
Echemos un vistazo a un ejemplo de cómo funciona esto volviendo a la declaración

del problema que vimos anteriormente de TheLadders:
Nuestro servicio ofrece un conducto entre los solicitantes de empleo y los empleadores
que intentan contratarlos. A través de nuestro servicio, los empleadores pueden llegar a
los solicitantes de empleo en nuestro ecosistema con oportunidades de empleo. Hemos
observado que un factor crítico que afecta la satisfacción del cliente es la frecuencia con
la que los buscadores de empleo responden a los mensajes del empleador. Actualmente,
los buscadores de empleo están respondiendo a estas comunicaciones a un ritmo muy
bajo. ¿Cómo podemos mejorar la eficacia de nuestros productos de comunicación,
haciendo así que los empleadores tengan más éxito en sus trabajos y que los solicitantes
de empleo estén más satisfechos con nuestro servicio?
Una suposición que hacemos en esta declaración del problema es que los reclutadores
utilizarán un nuevo canal (TheLadders) para interactuar con los candidatos. Esto no
es un hecho probado y necesita ser probado. ¿Cómo escribiríamos la hipótesis para
ese enunciado? Tomemos nuestra plantilla y completémosla:
Creemos que
creando un sistema de comunicación eficiente dentro de la experiencia de producto

de TheLadders
para reclutadores y empleadores
logrará una mayor tasa de éxito de contacto y un aumento en la satisfacción del producto.
Sabremos que esto es cierto cuando veamos un aumento en la cantidad de respuestas

de los solicitantes de empleo a los contactos de los reclutadores y un aumento en la
cantidad de mensajes iniciados por los reclutadores en nuestro sistema.
24 Capítulo 3
www.it-ebooks.info
La importancia de los puntos de referencia
Recuerde, ninguna de sus métricas será significativa si no tiene un punto de referencia

antes de escribir sus hipótesis. Ese punto de referencia, el estado actual de las
métricas que está utilizando para determinar el éxito de su idea, debe capturarse con
anticipación para garantizar que el equipo sepa a qué se dirige.
Completando sus declaraciones de hipótesis
Para crear sus declaraciones de hipótesis, comience a ensamblar los bloques de construcción.
Reúna una lista de los resultados que está tratando de crear, una definición de las personas a
las que está tratando de atender y un conjunto de características que cree que podrían
funcionar en esta situación. Una vez que tenga todo este material en bruto, puede juntarlo
todo en un conjunto de declaraciones. Echemos un vistazo más de cerca a cada uno de estos
elementos.
Resultados
Cuando está creando hipótesis para probar, quiere tratar de ser muy específico con respecto
a los resultados que está tratando de lograr. Discutí anteriormente cómo los equipos de Lean
UX se enfocan menos en la salida (los documentos, los dibujos, incluso los productos y
características que creamos) y más en los resultados que crean estas salidas: ¿podemos
facilitar que las personas inicien sesión en nuestro sitio? ¿Podemos animar a más personas a
registrarse? ¿Podemos fomentar una mayor colaboración entre los usuarios del sistema?
Junto con su equipo, mire el problema que está tratando de resolver. Probablemente tenga
algunos resultados de alto nivel que espera lograr (por ejemplo, aumentar las suscripciones,
aumentar el uso, etc.). Considere cómo puede dividir estos resultados de alto nivel en partes
más pequeñas. ¿Qué comportamientos predecirán un mayor uso: más visitantes al sitio?
¿Mayor número de clics en el marketing por correo electrónico? ¿Aumenta el número de
artículos en el carrito de compras? Algunas veces es útil realizar una lluvia de ideas en equipo
para crear una lista de resultados individuales que, en conjunto, cree que predecirán el
resultado más amplio que busca.
La figura 3-3 muestra un ejemplo de Giff Constable, en el que un equipo de liderazgo ejecutivo
hizo una lluvia de ideas y luego votó sobre qué indicadores clave de rendimiento (KPI) debería
seguir la empresa a continuación. Después de consolidar la lista que se muestra en la foto,
cada ejecutivo recibió cuatro M&M. Mientras lograron no comerse sus votos, estos ejecutivos
pudieron votar (con dulces) por cada métrica que consideraron más importante. Los lazos
fueron rotos por el CEO.
www.it-ebooks.info
Figura 3-3. Priorización de KPI con dulces
Personas
Los diseñadores a menudo crean modelos llamados personajes para representar a los usuarios
de sus sistemas. Si su equipo ya tiene un conjunto de personas bien definido, lo único que debe
considerar en este punto es cuáles utilizará en sus declaraciones de hipótesis. Si aún no tiene
personas, esta sección explica cómo crear personas para el proceso Lean UX.
Proto-Personas
Los diseñadores han sido durante mucho tiempo defensores del usuario final. Lean UX no es
diferente. 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 en el centro de nuestro pensamiento.
La mayoría de nosotros aprendimos a pensar en las personas como una herramienta para
representar lo que aprendimos en nuestra investigación. A menudo ocurría que creábamos
personas como resultado de estudios de investigación largos y costosos. El problema con las
personas que se crean de esta manera es la suposición de que esta es la única forma de crear
personas, así como la tendencia a considerar a las personas creadas a través de este proceso
como intocables debido a todo el trabajo que se dedicó a crearlas.
En Lean UX, cambiamos el orden de las operaciones en el proceso de persona.

Al crear personas con este enfoque, comenzamos con suposiciones y luego investigamos para
validar nuestras suposiciones. En lugar de pasar meses en el campo entrevistando a personas,
pasamos algunas horas creando
26 Capítulo 3
www.it-ebooks.info
protopersonas. Los proto-personajes son nuestra mejor suposición de quién está usando
(o usará) nuestro producto y por qué. Los esbozamos en papel con la contribución de
todo el equipo; queremos capturar las suposiciones de todos. Luego, a medida que
aprendemos de nuestra investigación en curso, descubrimos rápidamente qué tan
precisas son nuestras conjeturas iniciales y cómo necesitaremos ajustar nuestra audiencia
objetivo (y persona) y, por lo tanto, nuestro diseño.
Usando Proto-Personas
Un equipo con el que estábamos trabajando en Nueva York estaba creando una aplicación que mejoraba 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 de una
temporada completa de un agricultor local. El agricultor luego entrega sus cosechas, semanalmente, a los
miembros de la CSA. Muchos suscriptores de la CSA son hombres y mujeres entre los 20 y los 30 años que
necesitan hacer malabarismos con una vida laboral ajetreada, 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 alrededor de una hora creando un personaje llamado Susan. Pero cuando salieron al campo a
investigar, rápidamente aprendieron que la gran mayoría de los cocineros y, por lo tanto, los usuarios
potenciales de su aplicación, eran hombres jóvenes. Regresaron a la oficina y revisaron su personalidad
para crear a Timothy (Figura 3-4).
Figura 3-4. Ejemplo de protopersona
Timothy demostró ser un usuario objetivo mucho más preciso. El equipo no perdió más tiempo refinando
ideas para la audiencia equivocada. Ahora estaban enfocados en una audiencia que, aunque todavía no era
perfecta, era mucho más correcta que sus suposiciones iniciales.
www.it-ebooks.info
Persona Format
Nos gusta dibujar protopersonajes en papel usando un cuadrante dibujado a mano,
como en las Figuras 3-5 y 3-6 (comience doblando una hoja de papel en cuatro cajas).
El cuadrante superior izquierdo contiene un bosquejo aproximado de la persona y su
nombre y función. El cuadro superior derecho contiene información demográfica básica.
Intente concentrarse en la información demográfica que predice un tipo específico de
comportamiento. Por ejemplo, puede haber casos en los que la edad de la persona
sea totalmente irrelevante, pero su acceso a un dispositivo específico, como un iPhone,
cambiará por completo la forma en que interactúa con su producto.
Figura 3-5. Plantillade persona en blanco
La mitad inferior de la proto-persona es donde ponemos la carne de la información.

El cuadrante inferior izquierdo contiene las necesidades y la frustración del usuario
con el producto o la situación actual, los puntos débiles específicos que su producto
está tratando de resolver y/o la oportunidad que está tratando de abordar. El cuadrante
inferior derecho contiene soluciones potenciales para esas necesidades. Utilizará el
cuadrante inferior derecho para capturar ideas de funciones y soluciones.
28 Capítulo 3
www.it-ebooks.info
Figura 3-6. Plantilla de persona completa
Proceso de Creación de Persona
Al igual que con los otros elementos de la declaración de hipótesis, nos gusta
comenzar el proceso de creación de personajes con una lluvia de ideas. Los
miembros del equipo ofrecen sus opiniones sobre a quién debería dirigirse el
proyecto y cómo afectaría eso al uso del producto por parte de cada usuario
potencial. Una vez que se completa la lluvia de ideas, el equipo debe reducir las
ideas a un conjunto inicial de tres o cuatro personas que creen que es más probable que sean el
Trate de diferenciar las personas en torno a las necesidades y roles en lugar de por
demografía.
www.it-ebooks.info
Características
Una vez que tenga una lista de resultados en mente y se haya centrado en un grupo de
usuarios, es hora de comenzar a pensar en qué tácticas, características, productos y servicios
puede implementar para lograr los resultados deseados. Por lo general, todos los miembros
del equipo tienen una opinión sólida en esta etapa; después de todo, las funciones son las
cosas más concretas con las que trabajamos, por lo que a menudo es más fácil para nosotros
expresar nuestras ideas en términos de funciones. Sin embargo, con demasiada frecuencia,
nuestro proceso de diseño comienza cuando alguien tiene una idea para una función y
terminamos trabajando hacia atrás para tratar de justificar la función. En Lean UX, las
funciones existen para satisfacer las necesidades de la empresa, el cliente y el usuario.
Proceso de lluvia de ideas sobre características
Empleando las mismas técnicas descritas anteriormente, nos gusta crear listas de funciones
mediante una lluvia de ideas en equipo. Estamos buscando características que creemos que
impulsarán el comportamiento del cliente en la dirección deseada. Pida a cada miembro del
equipo que escriba cada idea, utilizando un marcador grueso, en una nota adhesiva. Cuando
se acabe el tiempo, pida a todos que publiquen sus notas en la pared y que el grupo las
organice por temas.
Ensamblar sus subhipótesis

Con toda su materia prima creada, está listo para organizar este material en un conjunto de
hipótesis comprobables. Nos gusta crear una tabla como la de la Figura 3-7 y luego
completarla usando el material que hemos generado.
Mientras escribe sus hipótesis, considere a qué persona(s) está sirviendo con sus soluciones
propuestas. No es inusual encontrar soluciones que sirvan a más de una persona a la vez.
Tampoco es inusual crear una hipótesis en la que una característica impulsa más de un
resultado. Cuando vea que eso sucede, divida la hipótesis en dos partes: desea que cada
declaración se refiera a un solo resultado. 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 cada una de sus ideas se mantiene firme.
Figura 3-7. Tabla de creación de hipótesis
30 Capítulo 3
www.it-ebooks.info
Cuando su lista de hipótesis esté completa, estará listo (¡por fin!) para pasar al
siguiente paso: diseñar. Si ha realizado el proceso hasta este punto con todo su
equipo (y le recomiendo encarecidamente que lo haga), estará en una excelente
posición para avanzar juntos. Este proceso es una forma muy efectiva de crear una
comprensión compartida y una misión compartida en todo su equipo.
Conclusión
En este capítulo, discutimos cómo podemos reformular nuestro trabajo en términos
de resultados, que es una técnica Lean UX de vital importancia: enmarcar nuestro
trabajo con resultados nos libera (y a nuestros equipos) para buscar las mejores
soluciones al problema en mano. También analizamos el proceso de declaración de
resultados. Para lograr esto, comenzamos con las declaraciones del problema del
proyecto y luego reconocemos nuestros supuestos, luego transformamos estos
supuestos en hipótesis. También mostramos cómo escribir declaraciones de hipótesis
que capturan las características, la audiencia y los objetivos previstos, y que son lo
suficientemente específicas como para ser probadas. Terminará con declaraciones
que servirán como hoja de ruta para el siguiente paso del proceso Lean UX: diseño colaborativo.
En el próximo capítulo, definimos el diseño colaborativo y cómo se diferencia del

diseño de producto tradicional. Analizaremos herramientas y técnicas específicas
que permiten a los equipos diseñar juntos y demostrar cómo diseñar juntos es el
comienzo del proceso de validación de hipótesis.
www.it-ebooks.info
www.it-ebooks.info
Capítulo 4
Diseño colaborativo
Mientras navega por el resto de su vida, esté abierto a la colaboración.

Las ideas de otras personas y 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
Lean UX es un proceso colaborativo. Reúne a diseñadores y no diseñadores en la co-

creación. Produce ideas que son más grandes y mejores que las de los contribuyentes
individuales. Pero no es un diseño por comité. En cambio, Lean UX aumenta la propiedad de
un equipo sobre el trabajo al brindar una oportunidad para que todas las opiniones se
escuchen mucho antes en el proceso. En este capítulo, exploramos los muchos beneficios
que se derivan de esta estrecha colaboración interfuncional. En concreto, nos fijamos en:
•Por qué todo el mundo puede diseñar
•Cómo los artefactos de baja fidelidad aumentan la colaboración
•Construir un entendimiento compartido en todo su equipo
También profundizaremos en una serie de técnicas que permiten esta forma más productiva
de trabajar, que incluyen:
33
www.it-ebooks.info
•Estudio de diseño: un ejercicio de dibujo colaborativo para todo el equipo
•Guías de estilo y bibliotecas de patrones: repositorios vivos de todos los elementos de su

producto orientados al cliente
•Técnicas de colaboración para equipos distribuidos geográficamente
En el capítulo anterior, discutimos las hipótesis de las características del producto. La primera
parte de una declaración de hipótesis de características del producto describe lo que
construiremos para resolver el problema de nuestros clientes. Estas características se pueden
diseñar de muchas maneras. Navegar por estas opciones puede ser difícil para los equipos.
¿Con qué frecuencia ha experimentado conflictos de equipo sobre las opciones de diseño?
Figura 4-1. Has escrito la hipótesis. Ahora es el momento de determinar lo que necesitarápara
las suposiciones.
prueba tu
La forma más eficaz que he 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 se presente, proponga algo hermoso y despegue para rescatar el próximo
proyecto). Los equipos rara vez aprenden o mejoran al trabajar con héroes. En cambio, diseñar
juntos aumenta el coeficiente intelectual de diseño de todo el equipo. Permite que cada
miembro del equipo articule sus ideas. Brinda a los diseñadores un conjunto mucho más amplio
de ideas para aprovechar a medida que refinan la experiencia del usuario. Esta colaboración,
a su vez, genera mayores sentimientos de propiedad sobre el trabajo realizado por todo el
equipo. Por último, el diseño colaborativo genera una comprensión compartida en todo el
equipo. Es esta comprensión compartida la moneda de Lean UX. Cuanto más comprenda
colectivamente el equipo, menos tendrá que documentar para avanzar.
El diseño colaborativo es un enfoque que permite a un equipo crear juntos conceptos de

productos. Ayuda a los equipos a desarrollar una comprensión compartida del problema de
diseño y la solución. Les permite trabajar juntos para decidir qué funcionalidad y elementos de
la interfaz implementan mejor la función en su hipótesis.
34 Capítulo 4
www.it-ebooks.info
El diseño colaborativo sigue siendo una actividad dirigida por el diseñador. Es

responsabilidad del diseñador no solo convocar estas reuniones sino también
facilitarlas. Algunas veces tendrá sesiones individuales con un desarrollador en una pizarra.
Otras veces, reunirá a todo el equipo para un ejercicio de Design Studio. La clave es
colaborar con un grupo diverso de miembros del equipo.
En una típica sesión de diseño colaborativo, los equipos dibujan juntos, critican el
trabajo a medida que surge y finalmente convergen en una solución que consideran
que tiene la mayor probabilidad de éxito. El diseñador, mientras sigue produciendo
diseños, asume el papel adicional de facilitador para guiar al equipo a través de una
serie de ejercicios.
El resultado de estas sesiones normalmente consiste en bocetos y estructuras

alámbricas de baja fidelidad. Este nivel de fidelidad es fundamental para mantener la
maleabilidad del trabajo, lo que permite que el equipo cambie 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 pasado demasiado tiempo documentando y detallando
laboriosamente ese enfoque.
Conversación: su herramienta más poderosa
Lean UX promueve la conversación como el principal medio 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 perspicacia
de un miembro del equipo puede desafiar rápidamente esas ideas de una manera que el diseñador solo
podría no haber reconocido.
Al tener estas conversaciones temprano y con frecuencia, el equipo está al tanto de las ideas de todos y
puede comenzar su propio trabajo antes. Si saben que la solución propuesta requiere cierta infraestructura
de back-end, por ejemplo, los ingenieros del equipo pueden comenzar con ese trabajo mientras se refina y
finaliza el diseño. Los caminos paralelos para el desarrollo y diseño de software son la ruta más rápida hacia
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 evoluciona la conversación, 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 vínculos entre los miembros del equipo.
Los compañeros de equipo que confían unos en otros están más motivados para trabajar juntos y producir
un trabajo de mayor calidad.
Diseño colaborativo 35
www.it-ebooks.info
Diseño colaborativo en la práctica

En 2010, estaba diseñando un tablero para una aplicación web 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 gastar demasiado tiempo
en mi escritorio empujando píxeles, agarré una pizarra y llamé al desarrollador principal.
Esbocé mi idea original sobre cómo diseñar todo el contenido y la funcionalidad de este
tablero. Lo discutimos y luego le entregué el rotulador. Esbozó sus ideas en la misma pizarra.
Fuimos de un lado a otro, hasta que finalmente convergimos en un esquema de diseño e

interacción que no solo era utilizable sino también factible dado nuestro marco de tiempo de
sprint de dos semanas (consulte la Figura 4-2). Al final de esa sesión de dos horas,
regresamos a nuestros escritorios y comenzamos a trabajar. Refiné nuestro boceto en una
estructura alámbrica y un flujo de trabajo más formales y él comenzó a escribir el código de
infraestructura necesario para llevar los datos que necesitábamos a la capa de presentación.
Habíamos construido un entendimiento compartido a través de nuestra sesión de diseño

colaborativo. Ambos sabíamos lo que íbamos a construir y lo que tenía que hacer.
No necesitábamos esperar para documentarlo. Este enfoque nos permitió construir la
primera versión de esta idea dentro de nuestro plazo de dos semanas.
Figura 4-2. Boceto de pizarra que llegó

nosotros junto. en
36 Capítulo 4
www.it-ebooks.info
Estudio de diseño
Cuando su equipo se siente cómodo colaborando, se llevan a cabo sesiones informales
como la que acabo de describir todo el tiempo. Pero a veces necesitará reunir a todos
para una sesión de trabajo formal. Design Studio es una forma popular de hacer esto.
Design Studio (a veces llamado 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 tus compañeros de
equipo. Al reunir a diseñadores, desarrolladores, expertos en la materia, gerentes de
productos, analistas de negocios y otras competencias en el mismo espacio, y enfocarlos
a todos en el mismo desafío, crea un resultado mucho mayor de lo que permite trabajar
en silos. Un estudio de diseño 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.
Dirigir un estudio de diseño

Aunque la técnica que se describe a continuación es muy específica, debe sentirse
cómodo dirigiendo estudios de diseño menos o más formales según lo requiera su
situación y el momento. Los detalles del ritual no son el objetivo final: en su lugar, debe
apuntar a resolver problemas con sus colegas y clientes.
Proceso
Design Studio sigue este camino:
1. Definición del problema y restricciones
2. Generación de ideas individuales (diverge)
3. Presentación y crítica
4. Iterar y refinar (emerger)
5. Generación de ideas en equipo (convergencia)
Suministros
Esto es lo que necesitará:
• Lápices
•Plumas
•Marcadores permanentes (múltiples colores/grosores)
•Iluminadores (múltiples colores)
www.it-ebooks.info
•Plantillas para bocetos (puede usar plantillas preimpresas de 1 y 6 páginas o puede usar
hojas en blanco de papel de 11"×17" divididas en seis cuadros)
• Blocs de caballete autoadhesivos de 25"×30.5"
• Puntos de dibujo (o cualquier tipo de pegatinas pequeñas)
El proceso funciona mejor para un equipo de cinco a ocho personas. Si tiene más personas,
cree más equipos y haga que los equipos comparen el resultado al final del proceso.
Definición del problema y restricciones (15 a 45 minutos)
El primer paso en Design Studio es asegurarse de que todos conozcan el problema que está
tratando de resolver, las suposiciones que ha declarado (incluidas las personas, como se
explica en otra parte de este capítulo), las hipótesis que ha generado y las restricciones. dentro
del cual está trabajando. Este paso puede ser cualquier cosa, desde una presentación formal
con diapositivas hasta una discusión grupal, según el nivel de comodidad del equipo.
Generación de ideas individuales (10 minutos)
Trabajará individualmente en este paso. Entregue a cada miembro del equipo una plantilla de 6
en 1: una hoja de papel con seis casillas vacías (Figura 4-3).
Puede hacer uno doblando una hoja en blanco de papel de 11"×17" (o puede usar una plantilla
preimpresa).
Figura 4-3. Una plantilla de 6 en 1.
38 Capítulo 4
www.it-ebooks.info
Opcional: a veces, las personas descubren que tienen dificultades para enfrentarse a una página en blanco.
Si ese es el caso, intente con el siguiente paso (5 minutos): pídale a cada persona que
etiquete cada cuadro de su hoja con una de sus personas y el punto de dolor o problema
específico que abordará para esa persona. Escriba el nombre de la persona y el punto de
dolor en la parte superior de cada uno de los seis cuadros. Los miembros del equipo
pueden escribir el mismo par de personas/puntos débiles tantas veces como soluciones
tengan para ese problema, o pueden escribir una combinación diferente de personas/
puntos débiles para cada casilla. Cualquier combinación funciona.
A continuación, con sus hojas de 6 en 1 en blanco (o opcionalmente etiquetadas) frente a

usted, dé a todos cinco minutos para generar seis bocetos de soluciones de baja fidelidad
para cada par de personas/puntos débiles en sus 6 en 1. Deben ser articulaciones
visuales (bocetos de interfaz de usuario, flujos de trabajo, diagramas, etc.), no palabras escritas.
Anime a su equipo revelando el sucio secreto del diseño de interacción para nivelar el
campo de juego: si puede dibujar un círculo, un cuadrado y un triángulo, puede dibujar
todas las interfaces. Estoy seguro de que todos en su equipo pueden dibujar esas formas.
Presentación y crítica (3 minutos por persona)
Cuando se acabe el tiempo, comparta y critique lo que ha hecho hasta ahora (vea la
Figura 4-4). Dando la vuelta a la mesa, dé a cada participante tres minutos para mostrar
sus bocetos y presentarlos al equipo. Los presentadores deben indicar explícitamente
para quién estaban resolviendo un problema (persona), qué punto de dolor estaban
abordando (hipótesis) y luego explicar el boceto. Cada miembro del equipo debe
proporcionar críticas y comentarios al presentador.
La crítica debe centrarse en aclarar las intenciones del presentador. Preguntas como
"¿Cómo aborda esta característica el problema específico de la persona?" son muy útiles
Comentarios como “No me gusta esa idea” brindan poco valor y no le dan al presentador
ideas concretas para iterar.
Asegúrese de que cada miembro del equipo presente y reciba críticas.
www.it-ebooks.info
Figura 4-4. Ejemplo dede

salida típica de Design Studio.
Iterar y refinar (5–10 minutos)
Ahora pida a todos que trabajen individualmente una vez más. Pida a cada
participante que tome sus seis ideas originales y, usando la crítica que acaban de
recibir, refine su pensamiento en una gran idea en una sola hoja de papel de 11"×17".
El objetivo aquí es elegir la idea que tenga más mérito y desarrollar una versión
más evolucionada de esa idea.
Una vez que se acabe el tiempo, pídale al equipo que vuelva a pasar por el presente y el proceso
de crítica.
40 Capítulo 4
www.it-ebooks.info
Generación de ideas en equipo (45 minutos)
Ahora que todos en el equipo tienen comentarios sobre su idea individual, el equipo debe converger
en una idea. En este paso, el equipo está tratando de converger en la idea que creen que tiene la
mayor probabilidad de éxito. Esta idea servirá como base para el próximo paso en el proceso Lean
UX: crear un MVP y ejecutar experimentos (ambos se tratan en el próximo capítulo).
Pídale al equipo que use una libreta de caballete autoadhesiva grande de 2'×3' o una pizarra para
esbozar los componentes y el flujo de trabajo de su idea. Habrá mucho compromiso y disputas en esta
etapa; para llegar a un consenso, el equipo deberá priorizar y reducir las funciones. Anime al equipo a
crear un "estacionamiento" para las buenas ideas que no pasan el corte, lo que hará que sea más fácil
dejar de lado las ideas.
Si tiene 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 última ronda de críticas y comentarios.
Los artefactos creados en el estudio de diseño ahora se usan para crear estructuras alámbricas,
prototipos y código inicial refinados que impulsarán al equipo para probar sus hipótesis.
Guías de estilo
Una herramienta que facilita el diseño colaborativo es la guía de estilo. Una guía de estilo es una
biblioteca de patrones ampliamente aceptada que codifica los elementos interactivos, visuales y de
copia de una interfaz de usuario y un sistema. Las guías de estilo (también conocidas como bibliotecas
de patrones) son una colección viva de todos los componentes orientados al cliente de su producto.
Si está hecho de píxeles, va en la guía de estilo.
Encabezados, pies de página, cuadrículas, formularios, etiquetas, lógica de botones y todo lo demás
relacionado con la experiencia del usuario de su producto se incluye en la guía de estilo.
Algunas empresas utilizan wikis para sus guías de estilo, lo que permite que la colección se mantenga
actualizada y accesible para todos los miembros del equipo. Otros equipos eligen crear guías de estilo
“en vivo”. Estos son repositorios de código y diseño front-end que no solo definen cómo se ve y se
comporta el producto, sino que en realidad funcionan como el marcado y las hojas de estilo
subyacentes para esa experiencia. Si cambias la guía de estilo, cambias el producto.
Las guías de estilo crean eficiencia. Proporcionan un depósito de componentes de interfaz aprobados
y listos para usar que se pueden ensamblar y alinear para formar un flujo de trabajo. Minimizando el
debate sobre elementos mundanos como la colocación de etiquetas en los formularios o el interminable
debate sobre la colocación izquierda/derecha.
www.it-ebooks.info
del botón de acción "positivo", los desarrolladores pueden comenzar a crear

componentes básicos de la interfaz de usuario sin esperar a que un diseñador defina y
especifique estos activos. Los activos ya están diseñados, definidos y recopilados en un solo lugar.
Los diseñadores visuales y de interacción también se benefician. Ya no tienen que

recrear representaciones de experiencias que ya existen. Se vuelven libres para
enfocarse en nuevos desafíos de diseño: nuevos problemas de interacción o ampliar el
sistema visual a nuevos elementos. Los ciclos de aprobación se simplifican porque los
elementos repetitivos (por ejemplo, el tratamiento de la navegación global) ya no están
sujetos a debate. Las revisiones se centran más en el desafío principal del producto y
en puntos de vista más amplios de la solución propuesta.
Creación de una guía de estilo
Hay dos enfoques básicos para crear una guía de estilo:
Big Bang
En este enfoque, su equipo se toma una cantidad limitada de tiempo (por ejemplo,
una o dos semanas o, a veces, meses) de sus esfuerzos actuales para documentar
todos los elementos de la interfaz de usuario de su producto en una guía de estilo.
El beneficio aquí es que la guía de estilo se crea en un período de tiempo
relativamente corto. Lo negativo es que su equipo no está aprendiendo nada nuevo
sobre su producto durante este tiempo.
goteo lento
En este enfoque, su equipo agrega un elemento a la guía de estilo cada vez
que crea o cambia uno para el proyecto. El mayor beneficio aquí es que el
equipo continúa trabajando en el proyecto. Sin embargo, el inconveniente es
que la guía de estilo rara vez se completa y, por lo tanto, no brinda algunas de las
eficiencias que brinda una guía completa.
Mantenimiento de una guía de estilo
Al planificar su guía de estilo, es importante planificar el mantenimiento.

Vas a necesitar crear un proceso y dedicar gente a mantener tu guía de estilo
actualizada. Piense en una guía de estilo como un proceso vivo que inicia y mantiene,
en lugar de algo estático que crea. Cuando tiene una guía de estilo actualizada y fácil
de usar, le facilita al equipo el uso real de la guía de estilo, y su objetivo debe ser
facilitar el uso de la guía de estilo en lugar de evitarla. . ¡Quiere facilitar el cumplimiento!
Así que planee dedicar personas y tiempo a mantener su guía de estilo.
Actual.
42 Capítulo 4
www.it-ebooks.info
Caso de estudio
En este estudio de caso, veremos cómo el equipo de UX de General Electric (GE) creó
una guía de estilo de nivel empresarial.
Cuando Greg Petroff tomó el mando de la práctica global de UX de GE a fines de 2011,

heredó un equipo distribuido globalmente que luchaba por brindar excelentes
experiencias de productos a una de las organizaciones más grandes del mundo. Resulta
que GE es el decimocuarto mayor productor de software del mundo y crea sistemas
para monitorear, administrar y comprender los equipos industriales que construyen. Con
500 desarrolladores por cada diseñador, al equipo le resultó difícil lograr los resultados
de diseño deseados para satisfacer las demandas masivas de la organización. Contratar
a más diseñadores no era una opción, y una amplia defensa corporativa para una mayor
consideración de los métodos de diseño de UX cambiaría las bases culturales, incluidos
los procesos, valores, prácticas de comunicación, actitudes y suposiciones, demasiado
lentamente. Además, el nuevo Centro de excelencia de UX se vio rápidamente abrumado
por las solicitudes de trabajo. Revisar todos los proyectos de UX que surgieron en la
empresa los convirtió en el cuello de botella que buscaban eliminar.
Tenía que haber una mejor manera. Inicialmente, el equipo intentó crear una comunidad
de UX en toda la empresa a través de una plataforma de redes sociales centralizada.
Aunque ese enfoque comenzó a generar camaradería, no hizo lo suficiente para
socializar una estética de diseño consistente o permitir que los equipos de desarrollo
sin capacidad de UX hicieran un buen trabajo.
Después de ejecutar algunos proyectos piloto en varias líneas comerciales, el equipo

de Petroff notó rápidamente casos de uso, personajes y patrones de diseño recurrentes.
Con las líneas de negocios individuales enfocadas en sus necesidades comerciales y
no en el conjunto, naturalmente, se estaba realizando una enorme cantidad de trabajo
duplicado en GE, ya que cada organización por separado recreaba elementos similares
una y otra vez. Peor aún, la calidad de ese trabajo no había progresado a lo que los
clientes de teléfonos inteligentes comenzaban a demandar. El método de GE no solo
era ineficiente, sino que también aumentaba la cantidad de tiempo que tardaba cada
proyecto en llegar al mercado. Y cuando los proyectos llegaron al mercado, las
experiencias en las líneas comerciales de GE fueron dispares e inconsistentes.
El equipo hizo una lluvia de ideas en el transcurso de una semana y se le ocurrió un

testaferro de cómo sería un entorno social para pautas consistentes de UX. Su público
objetivo eran los 8000 ingenieros de software de GE en todo el mundo.
El equipo se dio cuenta de que al empoderar a los desarrolladores con plantillas, pautas,
activos y fragmentos de código, podían tomar una excelente UX en sus propias manos
sin esperar la aprobación o la asistencia de diseño.
www.it-ebooks.info
Con esa iniciativa nació el Industrial Internet Design System (IIDS).

El testaferro recibió luz verde de la gerencia y se implementó durante el verano de 2012.
El IIDS se basa en marcos HTML5 modernos, como Bootstrap, jQuery y otros, pero no
se parece en nada a ellos (consulte las Figuras 4-5 y 4-6). Es una biblioteca de patrones
de diseño de interfaz de usuario funcional y de marca. Proporciona recursos gráficos,
fragmentos de código y reglas de uso para cada una de las experiencias de productos
con plantillas de GE. El equipo también creó aplicaciones de ejemplo para ayudar a otros
equipos en la composición de aplicaciones. El IIDS también incluye personajes de
clientes típicos para que los equipos de proyecto puedan tener una idea clara de sus
clientes objetivo y cómo el cliente objetivo afecta las elecciones de patrones de diseño
que hacen.
El equipo de Petroff identificó dos audiencias distintas para el IIDS. El primero fueron los
desarrolladores de GE que necesitan los activos para construir sitios y productos. El
segundo estaba compuesto por los administradores y propietarios del programa que
deben decidir qué tipo de aplicación crear. El IIDS sirve bien a ambas comunidades, con
comentarios positivos que llegan regularmente, las estadísticas de uso se disparan y las
métricas de éxito del proyecto van hacia arriba y hacia la derecha.
El IIDS está empoderando a los equipos que buscan volverse más ágiles y sumergirse
en Lean Startup. Permite a los equipos de proyectos construir prototipos de experiencias
mucho más rápido que nunca. Estos prototipos llegan a las etapas de validación meses
antes que los proyectos anteriores, lo que permite a los equipos demostrar su valía
mucho antes de la fuerte integración de back-end. Los ciclos de vida promedio de los
proyectos se han acortado hasta en seis meses con ahorros en el uso de recursos
estimados en millones por año.
Lo que es más importante, todos los equipos de GE ahora están capacitados para
obtener una versión de su experiencia en la que se puede hacer clic en días en lugar de
meses. Pueden llevar estas ideas a las partes interesadas internas y a los clientes
externos mucho antes de comprometer más recursos. Además, los equipos están mucho
mejor equipados para juzgar qué tan exitoso será el lanzamiento de un nuevo producto.
El desperdicio que una vez asoló el ciclo de diseño de productos en GE se está aliviando
lentamente a través de los recursos disponibles en el IIDS, en constante mejora.
44 Capítulo 4
www.it-ebooks.info
Figura 4-5. de IIDS.

ejemplo de la plantilla Una página
www.it-ebooks.info
Figura 4-6. Un diseño de mesa en

el IIDS.
¿Qué incluye una guía de estilo?

Si está hecho de píxeles, va a la guía de estilo. Todo el diseño de interacción.
los elementos deben definirse y agregarse a la guía de estilo. Utilice patrones de diseño
que funcionen bien en su producto actual como base de su guía de estilo. Los campos de
formulario, las etiquetas, los menús desplegables, la ubicación y el comportamiento de
los botones de opción, los eventos de Ajax y jQuery, los botones, todo debe incluirse en
la guía de estilo.
46 Capítulo 4
www.it-ebooks.info
Figura 4-7. Ejemplo de guía de estilo de TheLadders.
Proporcione tres puntos de datos para cada elemento de diseño de interacción:
Cómo se ve el elemento
Incluya detalles sobre los tamaños mínimo y máximo del elemento, las restricciones
verticales y horizontales y cualquier demanda de estilo en el elemento.
Dónde se coloca normalmente en la pantalla Deje
en claro si un elemento debe colocarse de manera consistente en ciertas áreas de la

pantalla, así como cualquier excepción que pueda anular este patrón de diseño.
Cuándo se debe usar
Es imperativo que su equipo sepa cuándo usar un menú desplegable en lugar de un

botón de opción y otros factores que determinarían la selección de un elemento de la
interfaz de usuario sobre otro.
www.it-ebooks.info
Figura 4-8. Otro ejemplo de una guía de estilo de TheLadders.

página
A continuación, incluya todos los elementos de diseño visual . Comience con la paleta
de colores general de su producto. Asegúrese de que cada color primario esté disponible
con valores hexadecimales, así como opciones de colores complementarios y secundarios.
Si ciertos elementos, como los botones, tienen colores diferentes según el estado,
asegúrese de incluir esta información. Otros elementos a incluir aquí son logotipos,
encabezados, pies de página, estructuras de cuadrícula y opciones tipográficas (es decir,
qué fuentes usar, dónde y en qué tamaño/peso). Los mismos atributos de qué, dónde y
cuándo se proporcionan para los elementos de diseño de interacción también deben incluirse aquí.
Finalmente, asegúrese de que los estilos de redacción también estén codificados.

Capture el tono de su marca, palabras específicas que usará y no usará, elecciones
gramaticales, coloquialismos tolerados (y no tolerados), junto con el idioma de los botones
(¿OK? ¿Sí? ¿Ir? etc.) y otros idiomas de navegación (anterior/ siguiente, más/menos,
etc.).
Características de una guía de estilo exitosa

Una guía de estilo exitosa tiene tres características importantes: es accesible, se mejora
continuamente (también conocido como un documento vivo) y es procesable.
Accesible
Accesibilidad significa que la guía de estilo está disponible para todos en su organización.
Las guías de estilo accesibles son:
48 Capítulo 4
www.it-ebooks.info
Fácil de encontrar
Use una URL fácil de recordar y asegúrese de que todos la conozcan.
Distribuido fácilmente
Asegúrese de que sus equipos puedan acceder a las guías de estilo a su

conveniencia (en la oficina, fuera de la oficina, en el móvil, etc.).
Fácil de buscar
Una función de búsqueda completa y precisa en la guía de estilo aumenta

considerablemente su uso.
Fácil de usar
Trate esto como lo haría con cualquier otro proyecto de diseño. Si no es utilizable, no
se usará muy rápidamente.
Mejora continua
La guía de estilo debe considerarse un documento vivo. Sí, los elementos que contiene
garantizan una experiencia uniforme para sus clientes, pero su producto (y sus clientes)
evolucionarán. La guía de estilo debe ser lo suficientemente maleable para agregar estas
actualizaciones fácilmente. Además, a medida que sus diseñadores creen nuevos elementos,
exigirán una manera fácil de agregarlos a la guía de estilo.
Recomiendo usar un wiki. Este es el por qué:
•Los wikis son lugares familiares para los desarrolladores. Esto significa que hacer que sus
compañeros de equipo en ingeniería participen en esta herramienta no implicará
obligarlos a aprender una nueva herramienta o una que fue diseñada específicamente
para diseñadores.
• Los wikis mantienen historiales de revisión (los buenos, de todos modos). Esta práctica es
crucial porque habrá ocasiones en las que desee revertir las actualizaciones de la interfaz
de usuario. Los historiales de revisión evitan que tenga que recrear estados anteriores
de la guía de estilo.
• Los wikis realizan un seguimiento de quién cambió qué y brindan la funcionalidad de

comentar. Esta función es ideal para mantener un registro de las decisiones que se
tomaron, quién las tomó y la justificación e incluso la discusión sobre la realización de
ese cambio. A medida que incorpora nuevos miembros del equipo, este tipo de captura
histórica puede ponerlos al día mucho más rápido.
En otras palabras, los wikis son su documentación.
Procesable
Su guía de estilo no es solo una biblioteca o un museo para componentes de interacción.

Debería ser una “fábrica de widgets” que pueda producir cualquier elemento de interfaz bajo
demanda. A medida que se agregue cada nuevo elemento a la guía de estilo, hágalo disponible
www.it-ebooks.info
para descargar en cualquier formato que necesite su equipo. Asegúrese de que no solo el
código esté disponible, sino también los activos gráficos y de estructura alámbrica.
Hacerlo permite que cada diseñador tenga una paleta completa de elementos de interfaz con
los que crear prototipos en cualquier momento.
¿Cómo se crea una guía de estilo?
Hay dos partes para crear una guía de estilo:
1. Cree una tabla de contenido (TOC): la TOC determina cómo se estructurará su guía de
estilo y proporciona cubos en los que puede comenzar a colocar elementos de diseño.
Separe su TOC en diseño de interacción, diseño visual, redacción, pautas de marca,
necesidades de accesibilidad y cualquier otra sección de alto nivel que tenga sentido
para su negocio.
2. Complete el contenido: como se mencionó anteriormente, hay dos formas de hacerlo: el

enfoque big bang y el goteo lento.
El enfoque big bang (en el que su equipo crea la guía de estilo completa antes de
cualquier proyecto) funciona bien si tiene un producto joven o uno relativamente simple.
El enfoque de goteo lento funciona bien si tiene un producto heredado o complejo.
Mantenimiento de una guía de estilo
Su guía de estilo debe mantenerse actualizada si quiere seguir siendo relevante y útil.
Agregue nuevas experiencias a medida que se crean y elimine las funciones obsoletas a
medida que quedan obsoletas.
Asigne un propietario a la guía de estilo. No es necesario que esa persona sea la única
responsable de la creación de contenido en la guía de estilo en sí, pero debe ser responsable
de garantizar el estado actual de la guía. El curador de su guía de estilo debe comunicarse
con los creadores de contenido y asegurarse de que los elementos se ingresen a medida que
se crean. En esencia, esta persona funciona como editor de la biblioteca de patrones. Es una
posición menos que envidiable, así que considere rotar este rol regularmente cada tres meses.
No solo para diseñadores
Su guía de estilo no debe contener información relevante solo para diseñadores.

También debe albergar fragmentos de código. Luego, los desarrolladores tienen una ventanilla
única para obtener toda su dirección de diseño, así como piezas de código fundamentales
que los llevarán a algún tipo de experiencia exponencialmente más rápido que antes.
50 Capítulo 4
www.it-ebooks.info
Una palabra sobre las guías de estilo en vivo
Los equipos que trabajan en la Web recientemente comenzaron a adoptar un nuevo

enfoque para las guías de estilo: la guía de estilo en vivo. Esencialmente, son idénticas
a las guías de estilo basadas en wiki, con una diferencia fundamental: el código en una
guía de estilo en vivo es el mismo código que usa la aplicación. Los equipos obtienen
eficiencias con este enfoque, pero asumen una infraestructura adicional y una carga
de proceso.
Las guías de estilo en vivo son básicamente una parte de su producto que solo es
visible para el equipo del producto. Es una parte de su aplicación que genera una
página "uno de cada" que muestra todos los estilos y widgets que se utilizan en el sitio.
Tiene la ventaja de estar mucho más cerca del automantenimiento.
A medida que realiza cambios en el HTML y el CSS subyacentes de su sitio, estos

cambios se muestran en las páginas de la guía de estilo. Alguien aún debe prestar
atención a esta página para asegurarse de que esté curada y mantenida y que los
conflictos se resuelvan. Pero el movimiento hacia una aplicación autodocumentada es
emocionante y promete mucho.
Colaboración con equipos distribuidos geográficamente

La distancia física es uno de los mayores desafíos para una colaboración sólida.
Algunos de los métodos que he discutido en este capítulo, especialmente Design
Studio, se vuelven más difíciles cuando un equipo no está en la misma ubicación. Pero
aún puedes encontrar formas de colaborar.
Aquí hay algunas técnicas que pueden ayudar a salvar la distancia para los equipos
distribuidos geográficamente. Herramientas como Skype, Google Docs (incluido Google
Draw), wikis y un teléfono con cámara hacen que la colaboración entre zonas horarias
sea efectiva y permite que los equipos se sientan virtualmente conectados durante
largos períodos de tiempo durante el día.
Sesión mundial de diseño colaborativo
Los equipos distribuidos geográficamente dificultan el diseño colaborativo. Pero los

beneficios valen el esfuerzo extra. Echemos un vistazo a cómo un equipo con el que
trabajé superó una separación en todo el continente y diseñaron soluciones juntos.
Este equipo se dividió en dos grupos en dos ciudades: el equipo de producto y

experiencia de usuario estaba en Nueva York y el equipo de desarrollo estaba en Van
couver. Mi objetivo era ejecutar un estudio de diseño y una sesión de mapeo de afinidad
con todo el equipo.
www.it-ebooks.info
Configuración
Les pedimos a los dos grupos que se reunieran en sus salas de conferencias individuales con
sus propias computadoras portátiles. Cada sala de conferencias tenía una Mac con una cuenta
de Skype específica de la ubicación (es decir, no era la cuenta de un individuo específico, era la
cuenta de esa oficina). Las dos oficinas se conectaron entre sí a través de sus cuentas de Skype
para que pudiéramos vernos como grupo. Este paso fue fundamental, ya que fue lo más cerca
que pudimos estar físicamente en la misma habitación.
Preparamos una presentación de configuración muy breve (alrededor de 10 diapositivas) que

explicaba el enunciado del problema que estábamos abordando. Incluía testimonios de clientes,
datos y un breve resumen de las necesidades de nuestros clientes. La presentación también
incluyó las limitaciones del espacio de solución.
Cebado de la bomba con mapeo de afinidad
Comenzamos con un ejercicio de mapeo de afinidad. Por lo general, estos se hacen con notas
adhesivas y una pizarra. En este caso, usamos una hoja de cálculo compartida de Google Docs
para realizar el ejercicio. Les pedimos a todos en ambas oficinas que iniciaran sesión en la hoja
de cálculo compartida. La hoja de cálculo en sí tenía una columna etiquetada para cada persona.
Google Docs permite que varios editores trabajen en el mismo documento. En este caso,
¡teníamos ocho miembros del equipo en el documento al mismo tiempo!
Le pedimos al equipo que presentara tantas ideas como pudiera pensar para resolver el
problema que presentamos. Cada miembro del equipo escribió una idea por celda en la columna
marcada con su nombre. Les dimos cinco minutos para generar tantas ideas como pudieran.
Para asegurarnos de que todos en cada ubicación estuvieran al tanto de todas las propuestas,
luego le pedimos a cada miembro del equipo que leyera sus ideas al equipo distribuido. Algunas
ideas pasaron rápido y otras generaron más discusión.
Para simular la agrupación por afinidad en la hoja de cálculo compartida, el facilitador (yo, en
este caso) comenzó una segunda hoja en el documento usando una computadora portátil personal.
Creé algunos encabezados de columna iniciales en la segunda hoja que reflejaban los temas
que escuchaba mientras el grupo leía sus ideas.
Luego le pedí al equipo que tomara cada idea y la copiara en el tema correspondiente en la
segunda hoja. Si no encajaba, les pedí que crearan su propio tema. También los animé a
cambiar la redacción de los temas a medida que avanzábamos si sentían que el nombre del
tema no era representativo o era engañoso.
52 Capítulo 4
www.it-ebooks.info
Al final de este proceso, teníamos una hoja de cálculo llena de ideas que se clasificaron
en temas. Algunos temas tenían solo un par de ideas; otros tenían hasta ocho.
Figura 4-9. de un
Salida remota sesión de mapeo de afinidad.
Estudio de diseño con equipos remotos
Para configurar el siguiente paso, una sesión de Design Studio, intentamos imitar una
versión coubicada de la actividad tanto como fue posible. Distribuimos papel y bolígrafos
en cada lugar. Creamos una configuración de dos monitores en cada sala de conferencias
para que cada sala pudiera ver los bocetos en un monitor y al mismo tiempo ver a sus
compañeros de equipo a través de Skype en el segundo monitor (como se muestra en
la Figura 4-10). . Le pedimos a cada equipo que usara un iPhone para fotografiar sus
bocetos y enviarlos por correo electrónico a todos los demás. Esta configuración ayudó
a conectar el diálogo y los artefactos a la conversación.
Después de esa configuración inicial, pudimos continuar con el proceso de Design Studio
como de costumbre. Cada miembro del equipo pudo presentar sus ideas en ambas
salas y recibir críticas transcontinentales. Los dos equipos pudieron refinar sus ideas
juntos y finalmente pudieron converger en una idea para llevar adelante.
www.it-ebooks.info
Figura 4-10. Dual durante

control remotoDesign Studio.
de configuración del monitor
Conclusión: diseño colaborativo

El diseño colaborativo es la evolución de UX. En este capítulo, discutí cómo el
proceso de diseño de "código abierto" hace que todo el equipo se involucre más en
el proyecto. Hablé sobre cómo los dibujos de baja fidelidad creados en las sesiones
de Design Studio pueden ayudar a los equipos a generar muchas ideas y luego
converger en un conjunto que todo el equipo pueda respaldar. Le mostré técnicas
prácticas que puede usar para crear una comprensión compartida, la moneda
fundamental de Lean UX. Usando herramientas como guías de estilo, Design Studio
y una conversación simple, los miembros de su equipo pueden construir un
entendimiento compartido que les permita avanzar a un ritmo mucho más rápido
que en los entornos tradicionales.
Ahora que todas nuestras suposiciones están declaradas y nuestras hipótesis de

diseño creadas, realmente puede entrar en el proceso de aprendizaje. En el próximo
capítulo, cubro el Producto Mínimo Viable (MVP) y cómo usarlo para planificar
experimentos. Usaremos esos experimentos para probar la validez de nuestras
suposiciones y decidir cómo seguir adelante con nuestro proyecto.
54 Capítulo 4
www.it-ebooks.info
Capítulo 5
MVP y experimentos
Toda la vida es un experimento.

Cuantos más experimentos hagas, mejor.
Ralph Waldo Emerson
Con las partes de su hipótesis ahora definidas, está listo para determinar qué ideas de
productos son válidas y cuáles debe descartar. En este capítulo, analizamos el Producto
Mínimo Viable (MVP) y lo que significa en Lean UX. Además, cubriremos:
• Determinar el enfoque del producto (¿entregar valor o aumentar el aprendizaje?)

usando MVP
•Uso de prototipos y herramientas de creación de prototipos
•Ejecución de experimentos sin prototipos
Acerca de los MVP y los experimentos
Lean UX hace un uso intensivo de la noción de MVP. Los MVP ayudan a probar
nuestras suposiciones (¿esta táctica logrará el resultado deseado?) mientras minimizan
el trabajo que ponemos en ideas no probadas. Cuanto antes podamos encontrar en
qué características vale la pena invertir, antes podremos concentrar nuestros recursos
limitados en las mejores soluciones para nuestros problemas comerciales. Este
concepto es una parte importante de cómo Lean UX minimiza el desperdicio.
55
www.it-ebooks.info
Su lista priorizada de hipótesis le ha dado varios caminos para explorar.

Para hacer esta exploración, querrá crear lo más pequeño que pueda para determinar
la validez de cada una de estas declaraciones de hipótesis.
Ese es tu MVP. Usarás tu MVP para ejecutar experimentos. El resultado de los
experimentos le dirá si su hipótesis era correcta y, por lo tanto, si debe continuar,
refinar o abandonar la dirección que está explorando.
El enfoque de un MVP
La frase MVP ha causado mucha confusión en su corta vida. El problema es que se
usa de dos maneras diferentes. A veces, los equipos crean un MVP principalmente
para aprender algo. No les preocupa entregar valor al mercado; solo están tratando de
averiguar qué quiere el mercado. En otros casos, los equipos crean una versión
pequeña de un producto o una característica porque quieren comenzar a ofrecer valor
al mercado lo más rápido posible. En este segundo caso, si diseña e implementa el
MVP correctamente, también debería poder aprender de él, incluso si ese no es el
enfoque principal. Consulte la Figura 5-1.
Figura 5-1. Vas a MVP que has

después creado y priorizado
de definido un establecer
de hipótesis.
Tomemos como ejemplo una empresa mediana con la que consulté recientemente.
Estaban explorando nuevas tácticas de marketing y querían lanzar un boletín mensual.
La creación de boletines no es una tarea fácil. Necesitas preparar una estrategia de
contenidos, calendario editorial, maquetación y diseño, así como una estrategia de
marketing continua. Necesitas escritores y editores para trabajar en ello.
Considerándolo todo, es un gran gasto para que la empresa lo lleve a cabo. El equipo
decidió tratar esta idea del boletín como una hipótesis.
La primera pregunta que tuvieron que responder fue si había suficiente demanda de los
clientes de un boletín informativo para justificar el esfuerzo. El MVP que usaron para
probar la idea fue un formulario de registro en su sitio web actual. El formulario de
registro promocionó el boletín y solicitó la dirección de correo electrónico de un cliente.
Este enfoque no ofrecería ningún valor al cliente, todavía. En cambio, la atención se centró en
56 Capítulo 5
www.it-ebooks.info
ayudar al equipo a aprender lo suficiente para tomar una buena decisión sobre si proceder.
Pasaron medio día diseñando y codificando el formulario y pudieron 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 había interés en su boletín informativo.
En este punto, el equipo no hizo ningún esfuerzo por diseñar o construir el boletín de noticias
real. Eso vendría más tarde, después de que el equipo hubiera recopilado suficientes datos
para tomar una decisión de PASA/NO PASA. Una vez que el equipo había recopilado
suficientes datos, y si los datos mostraban que sus clientes querían el boletín, el equipo
pasaría a su próximo MVP, uno que comenzaría a brindar valor y aprendizaje. Planearon
experimentar con versiones MVP del propio boletín que les permitiría probar la estrategia de
contenido, el diseño y otras características del boletín.
Crear un MVP
Cuando comience a planificar su MVP, lo primero que debe hacer es considerar lo que está
tratando de aprender. Es útil pensar en estas tres preguntas básicas:
1. ¿Existe la necesidad de la solución que estoy diseñando?
2. ¿Hay valor en la solución y las funciones que ofrezco?
3. ¿Se puede utilizar mi solución?
Si bien puede crear un MVP que lo ayude a responder cualquiera de estas preguntas, la
primera pregunta probablemente se responda mejor con los métodos tradicionales de
investigación de diseño. (En el próximo capítulo, discutimos los enfoques Lean para esta
investigación). Pero para la segunda y tercera pregunta, usar un MVP agrega mucho valor.
Si está tratando de responder a la pregunta dos, es probable que se encuentre creando un

MVP optimizado para el aprendizaje. Si su pregunta es sobre la usabilidad de su solución,
querrá enfatizar la entrega de valor en su producto. Este paso le permitirá "lanzar" un producto
al mercado y "observar" a los usuarios interactuando con él en contextos realistas.
Aquí hay algunas pautas a seguir si está tratando de maximizar su aprendizaje:
Sea claro y conciso
Dedique su tiempo a destilar su idea hasta su propuesta de valor central y preséntelo

a sus clientes
MVP y experimentos 57
www.it-ebooks.info
Priorizar sin piedad

Las ideas, como los artefactos, son transitorias. Deja que los mejores se prueben a sí mismos.
mantente ágil
La información llegará rápidamente, así que asegúrese de estar trabajando en un

medio que le permita realizar actualizaciones fácilmente.
Medir el comportamiento
Cree MVP que le permitan observar y medir lo que las personas realmente hacen,
no solo lo que dicen. En el diseño de productos digitales, el comportamiento triunfa
sobre la opinión.
Utilice una llamada a la acción
Sabrá que las personas valoran su solución cuando demuestren que la están
usando. Una llamada a la acción es una frase clara, a veces complementada con
una imagen, que le pide al usuario que realice una acción específica: “regístrate” o
“compra ahora”. Brindarles a las personas una forma de optar o registrarse en un
servicio es una excelente manera de saber si están interesados.
Aquí hay algunas pautas a seguir si está tratando de entregar valor a su

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.
Integre con los análisis existentes

La medición del rendimiento de su MVP debe realizarse dentro del contexto de
los flujos de trabajo de productos existentes.
Sea consistente con el resto de la aplicación.

Para minimizar cualquier sesgo hacia la nueva funcionalidad, diseñe su MVP
para que encaje con su marca y guía de estilo actual.
Por supuesto, encontrará que está tratando de aprender y ofrecer valor al mismo tiempo.
Tener en cuenta estas pautas al planificar sus MVP lo ayudará a navegar por las
compensaciones y los compromisos que tendrá que hacer.
Independientemente del resultado deseado, construya el MVP más pequeño posible.

Recuerda que es una herramienta para el aprendizaje. Estarás iterando. Lo estarás
modificando. Es muy posible que lo estés tirando por completo.
Y tenga en cuenta una última cosa: en muchos casos, su MVP no implicará ningún
código. En cambio, confiará en muchas de las herramientas existentes del diseñador de
UX: bocetos, creación de prototipos, redacción y diseño visual.
58 Capítulo 5
www.it-ebooks.info
Prototipos
Una de las formas más efectivas de crear MVP es creando un prototipo de la experiencia.
Un prototipo es una aproximación a una experiencia que permite simular cómo es utilizar el
producto o servicio en cuestión. Tiene que ser clicable (o tappable). Al mismo tiempo, su
objetivo debe ser gastar el menor esfuerzo posible para crear el prototipo, lo que hace que
la elección de la herramienta de creación de prototipos sea importante.
Elegir qué herramienta usar para su prototipo depende de:
•Quién va a interactuar con él
• Lo que esperas aprender
•Cuánto tiempo tienes para crearlo
Es fundamental especificar la audiencia prevista para su prototipo. Conocer a su audiencia

le permite crear el prototipo más pequeño posible que generará comentarios significativos
de esta audiencia. Por ejemplo, si usa el prototipo principalmente para demostrar ideas a los
ingenieros de software de su equipo, el prototipo puede pasar por alto en gran medida las
áreas principales del producto que no se ven afectadas por el prototipo, como la navegación
global. Sus desarrolladores saben que esos elementos están ahí y que no están cambiando,
por lo que no necesita ilustrar esos elementos para ellos.
Las partes interesadas, a menudo menos familiarizadas con su propio producto de lo que
nunca 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 conjunto de herramientas de creación de prototipos debe ser
bastante amplio. Querrá una amplia gama de métodos para comunicar sus ideas. Echemos
un vistazo a algunas formas de crear prototipos y los pros y los contras de cada uno.
Prototipos de baja fidelidad: papel

Hechos con los componentes más accesibles (papel, bolígrafos y cinta adhesiva), los
prototipos de papel (Figura 5-2) le permiten simular experiencias de una manera rápida,
astuta y divertida. No es necesaria ninguna inversión digital. El uso de tácticas como solapas
para mostrar y ocultar diferentes estados en una página o incluso la creación de una
"ventana" para que se mueva una presentación de diapositivas le da al equipo una idea de
cómo debería funcionar el producto. Podrá obtener 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. La creación de prototipos en papel es especialmente útil con
las interfaces táctiles que requieren que el usuario manipule elementos en una pantalla.
www.it-ebooks.info
Figura 5-2. Ejemplo de prototipo.

papel
ventajas
•Se puede crear en una hora
• Fácil de organizar y reorganizar
•Barato
•Se puede armar con materiales que ya se encuentran en la oficina
•Actividad divertida que muchas personas disfrutan
Contras
•La iteración rápida y la duplicación del prototipo pueden convertirse en tiempo

consumidor y tedioso
•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 y al flujo del producto
60 Capítulo 5
www.it-ebooks.info
Prototipos de baja fidelidad: Estructuras alámbricas en las que se puede hacer clic
La creación de una experiencia con estructuras alámbricas en las que se puede hacer clic (Figura 5-3)
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, lo que ofrece una mejor
perspectiva y retroalimentación sobre la forma en que interactuarán con el producto al nivel del clic,
toque o gesto.
Figura 5-3. Ejemplo de prototipo de estructura alámbrica en el que se puede hacer clic.
ventajas
•Proporciona una buena idea de la duración del flujo de trabajo
•Revela los principales obstáculos para completar la tarea principal
•Permite la evaluación de la encontrabilidad de los elementos centrales
•Se puede usar para crear rápidamente "algo en el que se pueda hacer clic" para que su equipo
aprenda de sus activos existentes en lugar de forzar la creación de
nuevos
Contras
•La mayoría de las personas que interactuarán 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
www.it-ebooks.info
Herramientas para crear estructuras alámbricas de baja fidelidad en las que se puede hacer clic
Estas son algunas de las herramientas que funcionan bien para este tipo de creación de prototipos:
Balsamiq
Una herramienta económica de estructuración de alambres que proporciona una

salida de aspecto "incompleto". Es lo más parecido al boceto digital de interfaces y
cuenta con una sólida comunidad de apoyo. Sus limitaciones son las que lo hacen
poderoso; no puede perder el tiempo ajustando los puntos más finos de la interfaz, por
lo que dedica más tiempo a las revisiones. La capacidad de vincular páginas entre sí
fácilmente lo convierte en una excelente herramienta de creación de prototipos.
Visio de Microsoft
Este programa, el abuelo de las herramientas de wireframing, todavía se puede usar

para vincular sus pantallas para crear algo en lo que se pueda hacer clic. Sin embargo,
es difícil trabajar rápidamente con Visio: los desafíos generales de usar este producto
lo hacen cada vez menos atractivo a medida que ingresan al mercado productos más
modernos, tanto de escritorio como basados en la web.
OmniGraffle (solo Mac)
En muchos sentidos, este es el equivalente Mac de Visio, aunque es más fácil de

usar, tiene características más sólidas y proporciona artefactos de mejor apariencia.
Puede usar imágenes en sus dibujos, para que pueda crear artefactos atractivos. Aún
así, su poder central está en diagramar, no en simular flujos de trabajo e interacción.
Microsoft PowerPoint
En un apuro, todavía se puede confiar en PowerPoint para falsificar cierto nivel

de interactividad. Puede usar las herramientas de dibujo nativas para dibujar estructuras
alámbricas y vincularlas, o puede importar maquetas, estructuras alámbricas o capturas
de pantalla que haya creado en otra herramienta. Al hacer clic secuencialmente a través
de sus diapositivas o al usar puntos de acceso vinculados, puede proporcionar un nivel
mínimo de interactividad falsa. En Mac, Keynote se puede usar de la misma manera.
También puede comprar bibliotecas de imágenes de Keynotopia que le permiten armar
maquetas de aspecto realista.
El mantenimiento de estos prototipos puede llevar mucho tiempo.
Fluid Designer/ Prototipo pop sobre papel
Estas herramientas de creación de prototipos móviles (y otras similares, que están

surgiendo muy rápidamente) le permiten crear rápidamente prototipos que se ejecutan
en un teléfono inteligente. Importa imágenes (o bocetos de fotografías) y los vincula
rápidamente mediante puntos de acceso. Puede simular flujos de trabajo simples muy
rápidamente.
62 Capítulo 5
www.it-ebooks.info
Nota
Soy consciente de que existen muchas opciones en el mercado para la creación de

wireframes y prototipos. La lista de herramientas que menciono en esta sección no
pretende ser exhaustiva. De hecho, se recomienda encarecidamente que pruebe tantas
de estas herramientas como pueda. Vea qué tan bien se adaptan a la forma en que usted
y su equipo trabajan juntos. La mayoría de los productos tienen una prueba gratuita para
que pueda probar el producto antes de comprometerse.
Prototipos de media y alta fidelidad

Los prototipos de fidelidad media y alta (consulte la Figura 5-4) tienen muchos más
detalles que los prototipos basados en estructuras alámbricas. Los usará para
demostrar y probar diseños que se desarrollan con un nivel de interacción, diseño
visual y/o de contenido que es similar (o indistinguible) a 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 permiten
representar simulaciones perfectas de píxeles de la experiencia final. Podrá crear
elementos de interfaz como formularios, campos, menús desplegables que funcionan
y botones de formulario que simulan acciones de envío. Algunas herramientas
permiten ramificaciones lógicas y operaciones básicas de datos. Muchos permiten
algunos tipos de animaciones menores, transiciones y cambios de estado. Además,
el costo de crear este nivel de fidelidad se reduce significativamente con el uso de estas herramien
Figura 5-4. Ejemplo de un prototipo de fidelidad media.
www.it-ebooks.info
ventajas
• Produce prototipos realistas y de alta calidad.
•El diseño visual y los elementos de la marca se pueden probar
•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
•Los usuarios normalmente no pueden interactuar con datos reales, por lo que hay 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; mantener un
prototipo de alta fidelidad y mantenerlo sincronizado con el producto real a menudo implica un esfuerzo
duplicado
Herramientas para crear estructuras alámbricas en las que se puede hacer clic de fidelidad media y alta
Estas son algunas de las herramientas que funcionan bien para este tipo de creación de prototipos (nuevamente,
esta es solo una lista muy parcial):
Axure RP
Esta herramienta de creación de prototipos cada vez más popular le permite crear páginas web realistas
con pantallas y formularios, y enviar flujos de trabajo.
Las maquetas de Axure se ejecutan en cualquier navegador y hacen un excelente trabajo de simulación
de páginas web. Debido a que importa bien las imágenes y es compatible con los elementos nativos de la
interfaz de usuario de HTML, es una herramienta de creación de prototipos de fidelidad media muy eficaz
(aunque también puede usarla para prototipos de baja y alta fidelidad). Tiene una buena lógica condicional,
por lo que puede simular una buena variedad de interacciones. Está surgiendo una creciente comunidad de
apoyo alrededor de Axure, y muchos diseñadores de interacción han comenzado a utilizarlo como su
herramienta principal. Su capacidad para generar especificaciones a partir del prototipo es una ventaja
adicional para las organizaciones que todavía exigen esas cosas a sus equipos.
fuegos artificiales de adobe
Una antigua adquisición de Macromedia, Fireworks trata de combinar lo mejor de Adobe Illustrator con lo
mejor de Photoshop y lo combina en un estofado de pseudointeractividad que lo convierte en una poderosa
herramienta de creación de prototipos cuando la fidelidad visual es importante. Puede crear pantallas y
administrar diferentes estados de elementos específicos. Puede agregar componentes de formulario de
trabajo. Puede vincular elementos a través de puntos de acceso simples. Puede crear bibliotecas de activos
personalizadas que hagan que la reutilización de los elementos de la interfaz sea eficiente y fomente el uso
de la herramienta.
64 Capítulo 5
www.it-ebooks.info
Prototipos Codificados
Los prototipos codificados ofrecen el más alto nivel de fidelidad para las experiencias simuladas.
Para 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, hagan
clic en un enlace a una página que no fue prototipada). . Los prototipos codificados 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 el usuario esperaría que lo hicieran. Estos prototipos reciben
información del mouse, el teclado y la pantalla. Crean un patrón de interacción tan natural como
sea posible para los evaluadores del prototipo.
Prototipos codificados a mano y de datos en vivo
Hay dos niveles de fidelidad para los prototipos codificados: codificados a mano y datos en vivo.
Los prototipos codificados a mano se ven y funcionan como el producto final, pero no tienen en
cuenta ningún tipo de entrada, procesamiento o salida de datos en tiempo real. Todavía son solo
simulaciones. Los prototipos de datos en vivo se conectarán con datos en tiempo real y
procesarán la entrada del usuario. Estos a menudo se implementan en clientes reales y ofrecen
un nivel de conocimiento analítico sobre el uso del prototipo por parte de los clientes que no está
disponible en los prototipos codificados a mano. También se pueden usar cuando se realizan
pruebas A/B de ciertas funciones o cambios en el flujo de trabajo actual.
ventajas
•Potencial para reutilizar código para producción
•La simulación más realista para crear
•Puede generarse a partir de activos de código existentes
Contras
•El equipo puede atascarse en el debate de los puntos más finos del prototipo
•Lleva mucho tiempo crear un código de trabajo que entregue lo deseado

experiencia
•Tentador para perfeccionar el código antes de lanzarlo a los clientes
•Actualizar e iterar puede llevar mucho tiempo
MVP y experimentos sesenta y cinco
www.it-ebooks.info
¿Qué debe ir en mi prototipo?

Ha elegido la herramienta para crear su MVP y está listo para comenzar.
No es necesario crear un prototipo de toda la experiencia del producto. En su lugar,
simule la parte más importante de la experiencia para su cliente y su negocio.
Concéntrese en los flujos de trabajo principales que ilustran su MVP.
Centrarse en los flujos de trabajo principales de su MVP le da al equipo una sensación

de visión de túnel temporal (¡en el buen sentido!), lo que les permite concentrarse en
una parte específica de la experiencia y evaluar su validez y eficacia.
Figura 5-5. Dónde encaja el prototipo en Inclinarse experiencia de usuario

ciclo
Demostraciones y avances
Pruebe su MVP prototipo con sus compañeros de equipo, partes interesadas y

miembros de otros equipos. Llévelo al área de almuerzo y compártalo con colegas que
trabajan en diferentes proyectos. Asegúrese de que las personas dentro de la empresa
brinden al equipo información sobre qué tan bien funciona, cómo lo usarán y si vale la
pena una inversión adicional. Deje que las partes interesadas hagan clic en él y le den
sus ideas y pensamientos.
Los prototipos ayudan a mostrar a las partes interesadas del proyecto que se está
progresando. Si su equipo tiene un día de demostración (y si no lo tiene, debería),
traiga el prototipo allí para mostrar el progreso del proyecto. Cuanta más exposición
obtenga el MVP, más información tendrá sobre su validez. A continuación, lleve su
prototipo a los clientes y clientes potenciales. Permítales hacer clic en la experiencia y
recopilar sus comentarios.
Poniendo todo junto: usando un prototipo de MVP

Así es como un equipo con el que trabajé usó recientemente un prototipo de MVP. En
este estudio de caso, el equipo estaba considerando realizar un cambio significativo
en su oferta. Utilizamos un prototipo de MVP para apoyar el proceso de investigación
y toma de decisiones.
66 Capítulo 5
www.it-ebooks.info
Esta startup establecida estaba luchando con su producto actual: una comunidad exclusiva
basada en suscripción para la colaboración grupal. Había estado en el mercado durante algunos
años y había ganado terreno, pero la adopción había llegado a un punto muerto: los nuevos
usuarios no se registraban. Al darse cuenta de que era necesario un cambio radical,
especialmente a la luz de la creciente competencia, consideraron renovar su modelo comercial
y abrir el producto a un segmento de mercado significativamente más amplio. Su preocupación
era doble:
•¿Aceptarían los usuarios actuales este cambio, dado que alteraría la exclusividad de la
comunidad?
•¿Estaría el nuevo segmento de mercado interesado en este tipo de

¿producto?
El equipo estaba preocupado de que pudieran recibir un doble golpe. Temían que los usuarios
existentes abandonaran el producto y que no se incorporaran suficientes usuarios nuevos para
compensar el déficit.
Trabajé con el equipo para definir nuestro plan como una hipótesis. Presentamos el nuevo
segmento de mercado y definimos el conjunto básico de funcionalidades que queríamos
proporcionar a ese segmento. Era solo un subconjunto de la visión definitiva, pero podía
articularse en cinco estructuras alámbricas.
Pasamos una semana creando los wireframes usando Balsamiq para asegurarnos de que
nuestros desarrolladores, especialistas en marketing y ejecutivos estuvieran de acuerdo con la
nueva dirección. Mostramos los wireframes a los clientes actuales (¡dos veces!) 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 voló 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 iPad: los clientes tocaron, deslizaron y conversaron
con nosotros sobre la nueva oferta. Tres días después, volvimos a Nueva York con comentarios
escritos en cada nota adhesiva y trozo de papel disponible.
Juntamos las notas en grupos y surgieron algunos temas claros. Los comentarios de los
clientes nos hicieron darnos cuenta de que, si bien este nuevo plan de negocios tenía mérito,
necesitaríamos una mayor diferenciación de los productos existentes en el mercado si
queríamos tener éxito.
En total, pasamos ocho días hábiles desarrollando nuestras hipótesis, creando nuestro MVP y
obteniendo comentarios del mercado. Este trabajo nos colocó en una excelente posición para
refinar el producto y adaptarlo a nuestro segmento de mercado de manera más efectiva.
www.it-ebooks.info
MVP no prototipos
Para muchos equipos, el enfoque predeterminado para crear un MVP es crear un prototipo,
para comenzar de inmediato a diseñar y escribir código. Es fácil entender este enfoque:
estamos capacitados para probar nuestros diseños y nuestro código, por lo que cuando
pensamos en la validación, naturalmente pensamos en crear una maqueta del producto para
probar. Sin embargo, hay muchas ocasiones en las que este paso no es necesario e incluso
puede ser perjudicial. A pesar de lo valioso que es la creación de prototipos, no es el único
camino a seguir.
A veces tiene sentido crear un MVP que no simule su producto y, en cambio, le permita
probar algo relacionado con su producto. Por ejemplo, cuando su equipo está tratando de
determinar el valor de una nueva característica o producto, a menudo tiene sentido usar un
MVP que no sea un prototipo para saber si está en el camino correcto.
El mantra a tener en cuenta al crear MVP que no son prototipos es este: siempre puedes ser
más delgado. Para planificar su MVP, hágase las siguientes preguntas:
1. ¿Qué estoy tratando de aprender?
2. ¿Cuáles son las principales señales que necesito del mercado para validar mi
¿hipótesis?
3. ¿Hay otras señales que pueda probar que sirvan como indicadores para mi señal
principal?
4. ¿Cuál es la forma más rápida de encontrar esta información?
Como ejemplo, respondamos estas preguntas para una solución que una empresa de
comercio electrónico quiere probar:
1. ¿Qué estoy tratando de aprender? Estamos tratando de saber si esta nueva solución de
comercio electrónico aumentará las compras.
2. ¿Cuáles son las principales señales que necesito del mercado para validar mi hipótesis?
La señal principal que estamos buscando del mercado es un aumento en las compras
completadas.
3. ¿Hay alguna señal que pueda probar que sirva como indicador de mi señal principal? En
lugar de compras completadas, ¿podemos probar la intención del cliente y usar eso
como un proxy para las compras?
4. ¿Cuál es la forma más rápida de encontrar esta información? Enviemos un correo

electrónico a un subconjunto de nuestros usuarios ofreciendo algunos artículos a la
venta y contemos los clics para ese llamado a la acción. Esto nos ayudará a determinar
el interés y la intención de compra.
68 Capítulo 5
www.it-ebooks.info
Tipos de MVP que no son prototipos
Echemos un vistazo rápido a algunas técnicas para crear MVP que no sean prototipos.
Correo electrónico
El correo electrónico es una herramienta muy poderosa cuando se trata de aprender

acerca de sus clientes. Las tasas de apertura, los clics y las tasas de finalización de
tareas para los destinatarios brindan información sobre si su idea tiene valor.
Google Ad Words Un
experimento muy económico para ejecutar es comprar anuncios de Google Ad

Words que apuntan a búsquedas relevantes para su negocio.
Al monitorear lo que la gente está buscando, comenzará a recibir comentarios sobre
qué tipo de lenguaje resuena con su audiencia. Al medir los clics, puedes ver cuánto
interés hay en las palabras y mensajes que propones.
Página de destino
Una página de destino para el tráfico de clics de los anuncios de Google puede validar
aún más su pensamiento. Una página de destino es el equivalente en línea de un estudio
de cine del Lejano Oeste. Es solo una fachada de su servicio, construida con un llamado
a la acción muy específico y obvio. Ya sea Registrarse, Comprar ahora o Compartir con
un amigo, cada usuario que completa la tarea en su página de destino cuenta como
validación de su idea de producto.
El botón a ninguna parte
Se puede probar una característica en su sitio agregando un botón a la interfaz que

promociona la nueva funcionalidad. Ese botón no hace más que medir la cantidad de
veces que se hace clic. Cada clic indica el deseo de un cliente por esa característica.
Con suficiente interés medible, se puede continuar con el desarrollo de la función. Por
supuesto, debe dar al usuario alguna explicación de por qué la función no funciona.
Puede usar esta interacción adicional como una oportunidad para capturar una dirección
de correo electrónico u otro comentario.
Híbridos y creatividad Cuando

hablo con equipos y emprendedores, a menudo me impresiona lo creativos
que pueden ser en su enfoque para crear MVP. El diseño de pruebas es un
proceso creativo y debe utilizar los métodos enumerados en este capítulo como
inspiración para su creatividad. El mejor enfoque para usted a menudo será
una combinación de muchos enfoques.
www.it-ebooks.info
Este es un ejemplo de cómo Cheryl Yeoh lanzó CityPockets utilizando un enfoque

híbrido llamado Concierge MVP para averiguar si su idea resolvió un problema real y
si había suficiente demanda para justificar su creación real.
Cheryl Yeoh comenzó CityPockets a partir de la hipótesis de que las personas tenían
problemas para administrar, realizar un seguimiento y canjear todas las ofertas y
cupones diarios que compraban en línea. Entrevistó a los clientes para validar que
efectivamente había una necesidad, pero no estaba segura de si su solución (una
billetera en línea para todos estos cupones) brindaría el tipo de valor que estos
clientes necesitaban. Para validar su hipótesis, lanzó una versión MVP de
CityPockets.com que presentaba solo una interfaz. Crear la integración y el
procesamiento back-end que necesitaría iba a ser costoso; no quería gastar su dinero
a menos que estuviera segura de que sus clientes encontrarían valioso su servicio.
En lugar de crear un back-end, Cheryl asignó una dirección de correo electrónico

única a cada cliente que se suscribió al servicio. Instruyó a sus clientes para que
reenviaran todos sus correos electrónicos de cupones a esa dirección. Detrás de
escena, Cheryl ingresaba manualmente cada cupón en una base de datos. Se fijó un
resultado objetivo arbitrario para sí misma: 500 correos electrónicos al día. Si los
clientes le enviaban 500 correos electrónicos al día, se sentía confiada al concluir
que habría suficiente demanda del servicio para merecer una mayor inversión. Ella
estaría lista en ese momento para construir un back-end para hacerse cargo del procesamiento.
Este enfoque, aunque involucró algo de diseño y codificación, omitió el trabajo

pesado. En cambio, permitió que Cheryl centrara su inversión en el conjunto de
funciones más pequeño posible que necesitaba para respaldar su aprendizaje. Al
final del día, esta es la esencia del enfoque Lean UX. Diseña solo lo que necesitas.
Entregarlo rápidamente. Cree suficiente contacto con el cliente para obtener
comentarios significativos rápidamente.
70 Capítulo 5
www.it-ebooks.info
Conclusión
En este capítulo, definimos el Producto Mínimo Viable como lo más pequeño que puede
hacer para saber si su hipótesis es válida. Además, discutimos las diversas formas que
puede tomar un MVP, analizamos más de cerca la creación de prototipos y discutimos
tácticas para aprender que no requieren construir
prototipos.
En el Capítulo 6, echamos un vistazo a varios tipos de investigación que puede utilizar

para asegurarse de que sus diseños estén dando en el blanco. También echamos un
vistazo a cómo su equipo puede dar sentido a todos los comentarios de su investigación.
generar.
www.it-ebooks.info
www.it-ebooks.info
Capítulo 6
Comentarios e investigación
La investigación es curiosidad formalizada. Es hurgar y

hacer palanca con un propósito.
Zora Neale Hurston
Ahora es el momento de poner a prueba nuestro MVP. Todo nuestro trabajo hasta este punto
se ha basado en suposiciones; ahora debemos comenzar el proceso de validación.
Utilizamos técnicas de investigación ligeras, continuas y colaborativas para hacer esto.
La investigación con los usuarios está en el centro de la mayoría de los enfoques de UX. Con
demasiada frecuencia, 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 solo en raras ocasiones, ya sea al comienzo de un proyecto o al final. Lean UX
resuelve los problemas que crean estas tácticas al hacer que la investigación sea continua y
colaborativa. Profundicemos para ver cómo hacerlo.
En este capítulo, cubrimos:
•Técnicas de investigación colaborativa que le permiten construir un entendimiento compartido

con su equipo
•Técnicas de investigación continua que le permiten construir pequeños estudios de

investigación cualitativos informales en cada iteración
73
www.it-ebooks.info
•Qué artefactos probar y qué resultados puede esperar de cada uno de ellos
estas pruebas
•Cómo incorporar la voz del cliente en todo el Lean UX

ciclo
•Cómo utilizar las pruebas A/B (descritas más adelante en este capítulo) en su investigación
•Cómo reconciliar comentarios contradictorios de múltiples fuentes
Continuo y Colaborativo
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 construyes actividades
de investigación en cada sprint. En lugar de un proceso de big bang costoso y disruptivo,
hacemos una investigación pequeña para que podamos adaptarla a nuestro proceso en
curso. En segundo lugar, la investigación Lean UX es colaborativa: 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 una
rica comprensión compartida en todo el equipo. Consulte la Figura 6-1.
Figura 6-1. La recopilación de comentarios finales

es parte
a través
del ciclo
deLean
la investigación
UX. paso
Descubrimiento colaborativo
El diseño colaborativo (cubierto en el Capítulo 4) es una de las dos formas principales de unir
funciones dentro de un equipo Lean UX. Descubrimiento colaborativo—
trabajar en equipo para probar ideas en el mercado—es el otro. El descubrimiento colaborativo
es un enfoque de la investigación que saca a todo el equipo del edificio, literal y figurativamente,
para reunirse con los clientes y aprender de ellos. 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 entradas que el equipo puede usar para recopilar información del cliente.
74 Capítulo 6
www.it-ebooks.info
Es esencial que usted y su equipo realicen investigaciones juntos; por eso lo llamo descubrimiento
colaborativo . La subcontratación de esta tarea reduce drásticamente su valor: desperdicia tiempo,
desperdicia la creación de equipos y filtra la información a través de entregas, traspasos e
interpretación. no lo hagas
Los investigadores a veces se oponen a este enfoque de la investigación. Como profesionales

capacitados, tienen razón al señalar que tienen conocimientos especiales que son importantes
para el proceso de investigación. Estoy de acuerdo. Es por eso que debe incluir un investigador en
su equipo si puede. Simplemente no subcontrate el trabajo a esa persona. En su lugar, utilice al
investigador como entrenador para ayudar a su equipo a planificar y ejecutar sus actividades.
Descubrimiento colaborativo en el campo
El descubrimiento colaborativo es una forma de salir al campo con su equipo.

Así es como lo haces:
•Como equipo, revise sus preguntas, suposiciones, hipótesis y MVP.

Decidan en equipo lo que necesitan aprender.
•Trabajando en equipo, decida con quién necesitará hablar para abordar sus objetivos de
aprendizaje.
•Cree una guía de entrevistas (vea la siguiente barra lateral) que todos puedan usar para guiar
sus conversaciones.
•Divida su equipo en parejas de entrevistadores, mezclando los diversos roles y disciplinas

dentro de cada pareja (es decir, trate de no tener diseñadores emparejados con diseñadores).
•Arma cada par con una versión del MVP.
•Envíe a cada equipo a reunirse con clientes/usuarios.
•Haga que un miembro del equipo realice las entrevistas mientras el otro toma notas.
•Comience con preguntas, conversaciones y observaciones.
• Demostrar el MVP más adelante en la sesión y permitir que el cliente interactúe con él.
•Recopilar notas a medida que el cliente proporciona comentarios.
• Cuando el entrevistador principal haya terminado, cambie los roles para darle a la persona que toma notas
la oportunidad de hacer preguntas de seguimiento.
•Al final de la entrevista, pídale al cliente referencias a otros

personas que también podrían proporcionar comentarios útiles.
Comentarios e investigación 75
www.it-ebooks.info
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 trucos, escriba las preguntas y los temas que ha decidido cubrir:
Con esta guía, siempre estará preparado para avanzar en 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 problemática que tenga
para este segmento. Finalmente, si tiene un prototipo o una maqueta, muéstreselo al cliente en último
lugar para evitar limitar la conversación a su visión de la solución.
Descubrimiento colaborativo: un ejemplo
Un equipo con el que trabajé en PayPal partió con un prototipo Axure para realizar una
sesión de descubrimiento colaborativo. 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. Cada desarrollador se emparejó con un no desarrollador.
Antes de partir, el equipo hizo una lluvia de ideas sobre lo que les gustaría aprender
de su prototipo y utilizó el resultado de esa sesión para escribir breves guías de
entrevistas. Su producto estaba dirigido a un amplio mercado de consumidores, por lo
que decidieron dirigirse a los centros comerciales cercanos a 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 su
conjunto de habilidades, cambiaron los roles (de entrevistador principal a tomador de
notas) una hora después de su investigación.
Cuando volvieron a reunirse, cada pareja leyó sus notas al resto del equipo.
Casi de inmediato, comenzaron a ver patrones que surgían, probando algunas de sus
suposiciones y refutando otras. Usando esta nueva información, ajustaron el diseño de
su prototipo y volvieron a salir más tarde del mediodía. Después de un día completo
de investigación de campo, quedó claro qué ideas tenían piernas y cuáles necesitaban
poda. 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
establecido un entendimiento compartido por medio del descubrimiento colaborativo el
día anterior.
Descubrimiento continuo
Una mejor práctica crítica en Lean UX es construir una cadencia regular de
participación del cliente. Las conversaciones programadas regularmente con los
clientes minimizan el tiempo entre la creación de hipótesis, el diseño del experimento
y los comentarios de los usuarios, lo que le permite validar sus hipótesis rápidamente.
En general, saber que nunca estará a más de unos días de recibir los comentarios de los clientes
76 Capítulo 6
www.it-ebooks.info
tiene un efecto poderoso en los equipos. Le quita presión a la toma de decisiones porque
sabe que nunca estará a más de unos pocos días de obtener datos significativos del
mercado.
Descubrimiento continuo en el laboratorio: tres usuarios cada jueves
Aunque puede crear un cronograma permanente de trabajo de campo basado en las

técnicas descritas en este capítulo, es mucho más fácil traer clientes al edificio; solo
necesita ser un poco creativo para involucrar a todo el equipo.
Me gusta usar un ritmo semanal para traer clientes al edificio para participar en la
investigación. Llamo a esto “3-12-1”, porque se basa en las siguientes pautas: tres
usuarios, a las 12 del mediodía, una vez a la semana (Figura 6-2).
Figura 6-2. El calendario de actividades 3-12-1.
Así es como se desglosan las actividades del equipo:
Lunes: Reclutamiento y planificación

Decidan, en equipo, qué se probará esta semana. Decida a quién necesita
reclutar para las pruebas y comience el proceso de reclutamiento. Subcontrate
este trabajo si es posible; lleva mucho tiempo.
Martes: Refinando 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: continuar refinando, escribiendo el guión y finalizando el

reclutamiento
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 cronograma para las pruebas del jueves.
www.it-ebooks.info
Jueves: ¡Pruebas!
Pase la mañana probando su MVP con los clientes. No pase más de una hora con
cada cliente. Todos en el equipo deben tomar notas. El equipo debe planear mirar desde
un lugar separado.
Revise los hallazgos con todo el equipo del proyecto inmediatamente después de que haya
terminado el último participante.
Viernes: Planificación
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 internos; 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.
Una herramienta especializada que recomiendo es el software de grabación y transmisión de
escritorio como Morae, Silverback o GoToMeeting.
El software de transmisión es un elemento clave. Le permite llevar las sesiones de prueba a los
miembros del equipo y las partes interesadas que no pueden estar presentes. Este método tiene
un enorme impacto en la colaboración porque difunde la comprensión de sus clientes en lo más
profundo de su organización. Es difícil exagerar cuán poderoso es este enfoque.
¿Quién debería mirar?
La respuesta corta es: todo tu equipo. Como casi todos los demás aspectos 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, necesitará menos informes posteriores.
El equipo aprenderá de primera mano dónde están teniendo éxito y fallando sus esfuerzos. Nada
es más humillante (y motivador) que ver a un usuario luchar con el software que acaba de crear.
Una palabra sobre el reclutamiento de participantes
Reclutar, programar y confirmar participantes requiere mucho tiempo.

Evite estos gastos generales adicionales descargando el trabajo a un reclutador externo. El
reclutador hace el trabajo y recibe un pago por cada participante que trae. Además, el reclutador
se encarga de la evaluación, la programación y el reemplazo de los que no se presentan el día de
la prueba. Estos reclutadores pueden costar entre $75 y $150 por participante reclutado.
78 Capítulo 6
www.it-ebooks.info
Estudio de caso: tres usuarios todos los jueves en Meetup Una

empresa que ha llevado el concepto de "tres usuarios todos los jueves" a
un nuevo nivel es Meetup. Con sede en Nueva York y bajo la dirección del
VP de Producto, Estrategia y Comunidad, Andrés Glusman, Meetup
comenzó con el deseo de probar todas y cada una de sus nuevas características y produ
Después de cotizar algunas opciones subcontratadas, decidieron mantener las cosas en

casa y adoptar un enfoque iterativo en su búsqueda de lo que llamaron su "proceso
mínimamente viable". Inicialmente, intentaron probar con el usuario, el moderador y el
equipo en la misma sala. Obtuvieron algunos resultados decentes de este enfoque, y había
mucho que aprender de esta técnica, incluido que se puede escalar, pero descubrieron
que los participantes de la prueba se asustarían un poco con tanta gente en la sala.
Con el tiempo, evolucionaron para tener las pruebas en una sala con solo el moderador
uniéndose al usuario. El resto del equipo vería la transmisión de video desde una sala de
conferencias separada (Meetup originalmente usó a Morae para compartir el video; hoy
usan GoToMeeting).
Meetup no escribe guiones de prueba porque no están seguros de lo que se probará cada
día. En su lugar, los gerentes de producto interactúan con los moderadores de la prueba,
utilizando la mensajería instantánea para ayudar a guiar las conversaciones con los
usuarios. El equipo informa inmediatamente después de que se completan las pruebas y
puede avanzar rápidamente.
Meetup reclutado directamente de la comunidad de Meetup desde el primer día.

Para los participantes fuera de su comunidad, el equipo utilizó un reclutador externo.
Finalmente, decidieron traer esta responsabilidad internamente, asignando el trabajo al
investigador dedicado que habían contratado para manejar todas las pruebas.
El equipo pasó de tres usuarios una vez a la semana a realizar pruebas todos los días
excepto los lunes. Su objetivo principal era minimizar el tiempo entre el concepto y la
retroalimentación del cliente.
La orientación del proceso viable mínimo práctico de Meetup también se puede ver en su
enfoque de las pruebas móviles. A medida que crecían las cifras de uso de dispositivos
móviles, Meetup no quería retrasar las pruebas en plataformas móviles mientras esperaban
equipos de prueba móviles sofisticados. En lugar de eso, construyeron los suyos por $28
(vea la figura 6-3).
www.it-ebooks.info
Figura 6-3. Plataforma de prueba de usabilidad móvil de Meetup.
A partir de 2012, Meetup ha escalado con éxito su proceso mínimo viable de

prueba de usabilidad a un programa impresionante. Ejecutan aproximadamente
600 sesiones de prueba por año a un costo total de alrededor de $ 30,000 (sin
incluir los costos de personal). Este costo incluye 100 por ciento de cobertura de
video y notas para cada sesión. Si considera que esto es más o menos equivalente
al costo de realizar un importante estudio de usabilidad subcontratado, este logro
es realmente asombroso.
80 Capítulo 6
www.it-ebooks.info
Dar sentido a la investigación: una actividad de equipo

Ya sea que su equipo realice trabajo de campo o de laboratorio, la investigación genera una gran
cantidad de datos sin procesar. Dar sentido a estos datos 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 resultados de la investigación. No deberías hacer las cosas de esta manera. En lugar
de eso, trabajen tan duro como puedan 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, o al menos al día siguiente, reúna al equipo para una sesión de
revisión. Cuando el equipo se haya vuelto a reunir, pídales a todos que lean sus hallazgos entre
ellos. Una forma eficiente 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 aportaciones 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 varias fuentes e intenten sintetizar sus
hallazgos, inevitablemente se encontrará con situaciones en las que sus datos le presenten
contradicciones. ¿Cómo le das sentido a todo? Aquí hay un par de maneras de mantener su
impulso y asegurarse de que está maximizando su aprendizaje:
buscar patrones
Mientras revisa la investigación, esté atento a los patrones en los datos.

Estos patrones revelan múltiples instancias de la opinión del usuario que representan
elementos para explorar. Si algo no cae en un patrón, es probable que sea un valor atípico.
Estacione sus valores atípicos
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 una reserva para ellos. A
medida que su investigación avanza con el tiempo (recuerde, está haciendo esto todas las
semanas), puede descubrir 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 ve a través de un canal son 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?
¿Los clientes se hacen eco del valor de su prototipo tanto dentro como fuera de su
oficina? De lo contrario, su muestra puede haber sido desproporcionadamente sesgada.
www.it-ebooks.info
Identificar patrones a lo largo del tiempo
La mayoría de los programas de investigación de UX están estructurados para obtener una respuesta
concluyente. Por lo general, planeará investigar lo suficiente para responder definitivamente una pregunta
o un conjunto de preguntas. La investigación Lean UX 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, verá una pequeña cantidad de usuarios cada semana. Por lo tanto, algunas preguntas
pueden permanecer abiertas durante un par de semanas. Otro resultado es que pueden revelarse
patrones interesantes con el tiempo.
Por ejemplo, nuestras sesiones de prueba periódicas en TheLadders revelaron un cambio interesante
en las actitudes de nuestros clientes a lo largo del tiempo. En 2008, cuando comenzamos a reunirnos
con personas que buscaban trabajo de manera regular, discutíamos varias formas de comunicarnos con
los empleadores. Una de las opciones que propusimos fue SMS. Debido a que nuestra audiencia
generalmente estaba compuesta por personas de altos ingresos de entre cuarenta y cincuenta años, sus
primeras respuestas mostraron un fuerte desdén por los SMS como un método de comunicación legítimo.
Para ellos, era algo que hacían sus hijos (y que tal vez hacían 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 los Estados Unidos. A medida que
los mensajes de texto ganaron aceptación en la cultura empresarial, esta actitud comenzó a suavizarse.
Semana tras semana, mientras nos sentábamos con los buscadores de empleo, comenzamos a ver que
estas opiniones cambiaban. Vimos que los buscadores de empleo eran mucho más propensos a usar
SMS en una búsqueda de empleo en la mitad de su carrera de lo que lo habrían hecho solo unos años antes.
Nunca hubiéramos reconocido esto como una tendencia de toda la audiencia si no hubiéramos estado
hablando con una muestra de esa audiencia semana tras semana. Como parte de nuestra interacción
regular con los clientes, siempre hicimos un conjunto regular de preguntas de nivelación para capturar
los "signos vitales" de la búsqueda del solicitante de empleo, sin importar qué otras preguntas, funciones
o productos estuviéramos probando. Como anécdota, estos hallazgos no habrían influido en nuestras
creencias sobre nuestro público objetivo. Agregados con el tiempo, se volvieron muy poderosos y dieron
forma a nuestras futuras discusiones y consideraciones sobre productos.
prueba todo
Para mantener una cadencia regular de pruebas de usuarios, su equipo debe adoptar una política de
"probar todo". Lo que esté listo el día de la prueba es lo que se muestra a los usuarios. Esta política evita
que su equipo se apresure a cumplir con los plazos del día del examen. En su lugar, aprovechará sus
sesiones de prueba semanales para obtener información en cada etapa de diseño y desarrollo. Sin
embargo, debe establecer expectativas adecuadamente para el tipo de comentarios que podrá generar
con cada tipo de artefacto.
82 Capítulo 6
www.it-ebooks.info
bocetos
Los comentarios recopilados en los bocetos (Figura 6-4) lo ayudan a validar el valor de su
concepto. Lo que no obtendrá en este nivel es una retroalimentación táctica paso a paso
sobre el proceso, información sobre los elementos de diseño o incluso una retroalimentación
significativa sobre las opciones de copia. No podrá aprender mucho (si acaso) sobre la
usabilidad de su concepto.
Figura 6-4. de un que puede

Ejemplo de boceto ser utilizado con los clientes.
Estructuras alámbricas estáticas
Mostrar los wireframes de los participantes de la prueba (Figura 6-5) le permite evaluar la
jerarquía de la información y el diseño de su experiencia. Además, obtendrá comentarios
sobre taxonomía, navegación y arquitectura de la información.
Recibirá los primeros hilos de retroalimentación del flujo de trabajo, pero en este punto los
participantes de la prueba se centran principalmente en las palabras de la página y las
selecciones que están haciendo. Los wireframes brindan una buena oportunidad para
comenzar a probar las opciones de copia.
www.it-ebooks.info
Figura 6-5. Ejemplo de estructura alámbrica.
Mockups visuales de alta fidelidad (no se puede hacer clic)
Al pasar a activos de diseño visual de alta fidelidad, recibe muchos más comentarios tácticos. Los
participantes de la prueba podrán responder a la marca, la estética y la jerarquía visual, así como a 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 opinarán (casi con seguridad) sobre la efectividad de su
paleta de colores.
Las maquetas en las que no se puede hacer clic aún no permiten que sus clientes reaccionen de forma
natural al diseño o los pasos posteriores de la experiencia. En lugar de preguntar a sus clientes cómo se
sienten acerca del resultado de cada clic, debe preguntarles qué esperarían y luego validar esas
respuestas contra su experiencia planificada.
Mockups (se puede hacer clic)
Un conjunto de maquetas en las que se puede hacer clic, básicamente un prototipo creado en Axure,
Fireworks, ProtoShare o cualquier otra herramienta de creación de prototipos viable (consulte la Figura 6-6).
evita las trampas de mostrar pantallas que no se vinculan entre sí. Los usuarios ven los resultados reales
de sus clics. Este tipo de maqueta no le permitirá evaluar las interacciones con los datos (por lo que no
puede probar el rendimiento de búsqueda, por ejemplo), pero aún puede aprender mucho sobre la
estructura de su producto.
84 Capítulo 6
www.it-ebooks.info
Figura 6-6. Ejemplo de maqueta en la que se puede hacer clic de Skype the Classroom. (Diseño de Hecho en
Por Muchos.)
Prototipos Codificados
El código en vivo es la mejor experiencia que puede ofrecer a los participantes de

la prueba. Reproduce el diseño, el comportamiento y el flujo de trabajo de su producto.
La retroalimentación es real y puede aplicarla directamente a la experiencia. Puede
simular una conexión de datos en vivo o conectarse realmente a datos en vivo; si
diseña bien su experiencia de prueba, los usuarios no podrán saberlo, pero sus
www.it-ebooks.info
Las reacciones le proporcionarán una visión directa de la forma en que los datos reales
afectan la experiencia (Figura 6-7).
Figura 6-7. Los clientes pueden proporcionar retroalimentación

a través de losmuchos
canales.
Técnicas de Monitoreo para Continuo, Colaborativo

Descubrimiento
En las discusiones previas de este capítulo, analicé formas de usar la investigación
cualitativa de manera regular para evaluar sus hipótesis. Pero una vez que 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 ocultos de inteligencia de clientes dentro de su organización y aprovéchelos
para impulsar su diseño e investigación de productos en curso.
Servicio al Cliente
Los agentes de atención al cliente hablan con más clientes diariamente que durante el
transcurso de un proyecto completo. Hay múltiples formas de aprovechar sus
conocimientos:
86 Capítulo 6
www.it-ebooks.info
•Comuníquese con ellos y pregúnteles qué están escuchando de los clientes sobre las
secciones del producto en las que está trabajando.
•Realizar 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 las sesiones de diseño y
las revisiones de diseño.
•Incorpore sus 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 llamen con una
queja relevante.
A mediados de la década de 2000, dirigí el equipo de UX en una empresa tecnológica

mediana en Portland, Oregón. Una de las formas en que priorizamos el trabajo fue revisando
regularmente el pulso de la base de clientes. Hicimos esto con una reunión mensual
permanente con nuestros representantes de servicio al cliente. Cada mes, nos
proporcionarían las 10 principales quejas de los clientes. Utilizamos esta información para
centrar nuestros esfuerzos y, posteriormente, medir la eficacia de nuestro trabajo. Si
intentamos resolver uno de estos puntos débiles, esta conversación mensual nos dio una
clara indicación de si nuestros esfuerzos estaban dando frutos; si el problema no estaba
retrocediendo en la lista de los 10 principales, nuestra solución no había funcionado.
Un beneficio adicional de este esfuerzo fue que el equipo de servicio al cliente se dio
cuenta de que alguien estaba escuchando sus ideas y comenzó a brindarnos comentarios
de los clientes de manera proactiva fuera de nuestra reunión mensual. El diálogo que siguió
nos proporcionó un circuito de retroalimentación continuo para usar con muchas de nuestras
hipótesis de productos.
Encuestas de retroalimentación en el sitio
Configure un mecanismo de comentarios en su producto que permita a los clientes enviarle

sus opiniones con regularidad. Algunas opciones incluyen:
• Formularios de correo electrónico simples
•Foros de atención al cliente
•Sitios de comunidades de terceros
Puede reutilizar estas herramientas para la investigación haciendo cosas como:
•Contar cuántos correos electrónicos entrantes recibe de un determinado

sección del sitio
•Participar en debates en línea y sugerir algunos de sus

hipótesis
www.it-ebooks.info
• Solicitar sitios comunitarios para participantes de prueba difíciles de encontrar
Estos canales de comentarios de clientes entrantes brindan comentarios desde el punto de vista de sus
clientes más activos y comprometidos. Aquí hay algunas tácticas para obtener otros puntos de vista:
Buscar registros
Los términos de búsqueda son indicadores claros de lo que buscan los clientes en su sitio. Los
patrones de búsqueda indican lo que están encontrando y lo que no están encontrando. Las
consultas repetidas con ligeras variaciones muestran el desafío de un usuario para encontrar
cierta información.
Una forma de usar los registros de búsqueda para la validación de MVP es iniciar una página
de prueba para la característica que está planeando. Seguir los registros de búsqueda le indicará
si el contenido de prueba (o función) en esa página satisface las necesidades del usuario. Si
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 análisis de embudos.

muestre cómo los clientes usan el sitio, dónde lo dejan 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? ¿Tus
esfuerzos están logrando el resultado que definiste? Estas herramientas proporcionan una
respuesta imparcial.
Pruebas A/ B
Las pruebas A/B son una técnica, desarrollada originalmente por especialistas en marketing,
para evaluar cuál de dos (o más) conceptos relativamente similares logran un objetivo 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. La aplicación de pruebas A/
B es relativamente sencilla una vez que sus hipótesis se convierten en código de trabajo.
Así es como funciona: tome la experiencia propuesta (su hipótesis) y publíquela a su

audiencia. Sin embargo, en lugar de permitir que todos los clientes lo vean, libérelo solo a un
pequeño subconjunto de usuarios. Luego, mida sus criterios de éxito 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, tienes una hipótesis ganadora. De lo contrario, tiene una
audiencia de clientes a la que recurrir e interactuar directamente para comprender por qué su
comportamiento no cambió.
88 Capítulo 6
www.it-ebooks.info
Hay varias compañías que ofrecen conjuntos de pruebas A/B, pero básicamente
todas funcionan de la misma manera. El nombre sugiere que solo puedes probar
dos cosas, pero de hecho puedes probar tantas permutaciones de tu experiencia
como quieras (esto se llama prueba A/B/n). El truco es asegurarse de que los
cambios que está realizando sean lo suficientemente pequeños como para que
cualquier cambio en el comportamiento se les pueda atribuir directamente. Si
cambia demasiadas cosas, cualquier cambio de comportamiento no se puede
atribuir directamente a su hipótesis.
Las empresas que ofrecen herramientas de pruebas A/B incluyen Unbounce para
pruebas de páginas de destino, Google Content Experiments (anteriormente Site
Optimizer), Adobe Test&Target (anteriormente Omniture) y Webtrends Optimize.
Conclusión
En este capítulo, cubrí muchas formas de comenzar a validar los MVP y los experimentos
que ha construido en torno a sus hipótesis. Examiné las técnicas de descubrimiento
continuo y descubrimiento colaborativo. Discutí cómo construir un proceso de prueba de
usabilidad esbelto cada semana y cubrí lo que debe probar y qué esperar de esas
pruebas. También analicé formas de monitorear la experiencia del cliente en un contexto
Lean UX y mencioné el poder de las pruebas A/B.
Estas técnicas, utilizadas junto con los procesos descritos en los Capítulos 3 a 5,
conforman el ciclo completo del proceso Lean UX. Su objetivo es recorrer este ciclo con
la mayor frecuencia posible, refinando su pensamiento con cada iteración.
En la siguiente sección, me alejo del proceso y analizo cómo se integra Lean UX dentro
de su organización. Ya sea que sea una empresa nueva, una gran empresa o una
agencia digital, cubriré todos los cambios organizacionales que deberá realizar para
respaldar el enfoque Lean UX. Estas ideas funcionarán en la mayoría de los procesos
existentes, pero en el Capítulo 7, cubriré específicamente cómo hacer que el desarrollo
de software Lean UX y Agile funcionen bien juntos.
www.it-ebooks.info
www.it-ebooks.info
Seccion 3:
Haciendo que funcione
De 2007 a 2011, lideré el equipo de UX en TheLadders, una bolsa de trabajo en línea

con sede en la ciudad de Nueva York. Durante mi mandato, la empresa comenzó su
transición de Waterfall a Agile. Fue un esfuerzo impulsado por los desarrolladores,
pero la empresa reconoció que, a menos que se incluyera UX, la transición fracasaría.
Dependía de mí descubrir cómo integraríamos Lean UX con este nuevo estilo de
trabajo. En 2007, si buscaba en Google "Agile UX", la página de resultados estaría
repleta de publicaciones de blog, artículos y estudios de casos que documentaban el
fracaso y la frustración. Los temas principales parecían ser gritos de "¡Agile apesta!"
y reglas que afirman que "UX no tiene por qué trabajar de esta manera".
Sin inmutarse, continué buscando ideas de colaboración e integración.

Encontré el modelo de "carrera escalonada" de Lynne Miller y Desiree Sy, en el que
el equipo de UX trabaja en una carrera por delante de los desarrolladores, y lo probé.
Aunque fue útil para hacernos pensar en nuestro trabajo en pequeñas ráfagas, no
hizo nada para aumentar la colaboración entre las disciplinas o para reducir el
esfuerzo desperdiciado en las especificaciones de funciones que nunca se construirían.
www.it-ebooks.info
Estábamos convencidos de que había una mejor manera, así que, como buenos Agilistas,
continuamos afinando nuestro proceso. Después de varios meses, sentí que habíamos
alcanzado nuestro ritmo. Aumentamos la colaboración, comenzamos a producir menos
documentos y aumentamos nuestros esfuerzos de validación de clientes. Los gritos
internos de "Agile apesta" y "Odio esto" también habían disminuido. Me sentía bastante
bien con nuestro pequeño equipo.
Un lunes por la mañana entré en la oficina listo para comenzar la semana y encontré el
diagrama de la Figura III-1 impreso y colocado cuidadosamente sobre mi escritorio.
Figura III-1. Los UX TheLadders

esfuerzos.expresaron sus sentimientos sobre el equipo en nuestros Ágil/UX
integración
Resulta que las cosas no eran tan color de rosa como había pensado. Mi equipo se fue y
realizó su propia retrospectiva (léase: sesión de ventilación) y produjo este diagrama como
su "entrega" para mí. Me tomó un poco por sorpresa, pero a medida que profundizaba en
los detalles del documento y discutía los puntos débiles clave con el equipo, los agujeros
en nuestro proceso se hicieron evidentes.
www.it-ebooks.info
Mire el diagrama: si ha intentado integrar Agile y UX, quizás reconozca algunos de estos
problemas. El equipo sintió que no había suficiente tiempo para hacer el trabajo de
"medalla de oro". Sentían que su trabajo no era de misión crítica.
Sintieron que no tenían tiempo para iterar. La lista continua. Cuando muestro este
diagrama a otros equipos que luchan por integrar Agile y UX, siempre hay muchas
sonrisas tristes de reconocimiento.
Encontrar este diagrama en mi escritorio fue una lección de humildad, pero provocó un
diálogo e involucró el proceso de aprendizaje que está en el corazón de los enfoques
ágiles. El diálogo nos permitió comenzar un proceso de descubrimiento que finalmente
resultó en la colaboración multifuncional que hizo que nuestro proceso Agile fuera un
éxito, como se describe en la Sección II.
Sobre la Sección III

¿Cómo puede integrar el proceso Lean UX en su organización? Esa es la pregunta que
responderé en la Sección III.
En el Capítulo 7, "Integración de Lean UX y Agile", tomaré las tácticas discutidas en la

Sección II y le mostraré exactamente cómo encajan en un proceso típico de Scrum y
cómo lo hacen más efectivo.
En el Capítulo 8, "Realización de cambios organizacionales", profundizaré en los cambios

organizacionales específicos que deben realizarse para respaldar esta forma de trabajar.
No son solo los desarrolladores y diseñadores de software los que necesitan encontrar
una manera de trabajar juntos. Los gerentes de productos, los gerentes de proyectos, en
resumen, todo su motor de desarrollo de productos, tendrá que cambiar si desea crear
una organización verdaderamente ágil.
www.it-ebooks.info
www.it-ebooks.info
Capítulo 7
Integrando Lean UX y Agile
Los métodos ágiles ahora son la corriente principal. Al mismo tiempo, gracias al enorme éxito de
productos como el Kindle y el iPhone, también lo es el diseño de la experiencia del usuario. Pero
hacer que Agile funcione con UX ha sido un desafío durante mucho tiempo. En este capítulo, reviso
cómo los métodos Lean UX pueden encajar dentro del sabor más popular de Agile, el proceso
Scrum, y analizo cómo combinar Lean UX y Agile puede crear un equipo más productivo y un
proceso más colaborativo. Cubriré:
Definición de términos
Solo para asegurarnos de que todos estamos en la misma página sobre ciertas palabras
como "sprint" e "historia".
Sprints escalonados
El único salvador de la integración Agile/UX ahora es solo un trampolín hacia la

verdadera cohesión del equipo.
Escuchando los ritmos de Scrum
Las cadencias de reunión de Scrum son guías claras para la integración de Lean UX.
Participación
Un proceso verdaderamente interfuncional requiere que todos sean parte de él.
El diseño como deporte de equipo
Asegurarse de que el proceso de diseño, una vez cerrado, ahora esté abierto a todos los
miembros del equipo es clave para su éxito.
95
www.it-ebooks.info
Manejando arriba y afuera
Elimine los obstáculos para el progreso de su equipo siendo proactivo con su

comunicación.
Algunas definiciones
Los procesos ágiles, incluido Scrum, usan muchos términos propietarios. Con el tiempo,
muchos de estos términos han cobrado vida propia. Para asegurarme de que los estoy usando
claramente, me he tomado el tiempo de definir algunos de ellos aquí (si está familiarizado con
Scrum, puede omitir esta sección).
Melé
Una metodología ágil que promueve ciclos de tiempo limitado, autoorganización

del equipo y alta responsabilidad del equipo. Scrum es la forma más popular de Agile.
Historia del usuario
La unidad de trabajo más pequeña expresada como un beneficio para el usuario final.
Las historias de usuario típicas se escriben con la siguiente sintaxis:
Como [tipo de usuario]
quiero [lograr algo]
Para que [ocurra algún beneficio]
Reserva
Una lista priorizada de historias de usuarios. El backlog es la herramienta de gestión

de proyectos más poderosa en Agile. Es a través de la preparación activa del backlog que
el equipo administra su carga de trabajo diaria y reenfoca sus esfuerzos en función del
conocimiento entrante. Así es como el equipo se mantiene ágil.
Sprint:
Ciclo de un solo equipo. El objetivo de cada sprint es entregar software que funcione. La
mayoría de los equipos Scrum trabajan en sprints de dos semanas.
Stand-up:
una breve reunión diaria del equipo en la que cada miembro aborda los desafíos del día,
una de las herramientas de auto-responsabilidad de Scrum. Cada miembro debe declarar
a todos los compañeros de equipo, todos los días, lo que está haciendo y lo que se
interpone en su camino.
Retrospectivo
Una reunión al final de cada sprint que analice honestamente lo que salió bien, lo que
salió mal y cómo el equipo intentará mejorar el proceso en el próximo sprint. Su proceso
es tan iterativo como su
96 Capítulo 7
www.it-ebooks.info
producto. Las retrospectivas le dan a su equipo la oportunidad de optimizar

su proceso con cada sprint.
Reunión de planificación de iteraciones
Una reunión al comienzo de cada sprint en la que el equipo planifica el

próximo sprint. A veces, esta reunión incluye estimación y recopilación de
historias. Esta es la reunión que determina la priorización inicial del backlog.
Más allá de los sprints escalonados

En mayo de 2007, Desiree Sy y Lynn Miller publicaron “Adaptación de
investigaciones de usabilidad para un diseño ágil centrado en el usuario” en el
Journal of Usability Studies (http:// www.upassoc.org/ upa_publications/ jus/ 2007may/ agile-ucd
pdf). Sy y Miller fueron algunas de las primeras personas en intentar combinar Agile
y UX, y muchos de nosotros estábamos entusiasmados con las soluciones que
proponían. En el artículo, Sy y Miller describen en detalle su idea de una integración
productiva de Agile y el diseño centrado en el usuario. Utilizan una técnica llamada
Ciclo 0 (es posible que también la hayas oído llamar "Sprint Zero" o "Staggered Sprints").
En resumen, Sy y Miller describen un proceso en el que la actividad de diseño tiene

lugar un sprint antes del desarrollo (Figura 7-1). El trabajo se diseña y valida durante
el “sprint de diseño” y luego pasa al flujo de desarrollo para ser implementado durante
el sprint de desarrollo.
Figura 7-1. ellaycorre”

el “modelo escalonado” de Miller.
Muchos equipos han malinterpretado este modelo. Sy y Miller siempre abogaron por
una fuerte colaboración entre diseñadores y desarrolladores durante los sprints de
diseño y desarrollo. Muchos equipos han pasado por alto este punto crítico y, en su
lugar, han creado flujos de trabajo en los que los diseñadores y desarrolladores se
comunican mediante transferencia, creando una especie de proceso en mini cascada.
Integrando Lean UX y Agile 97
www.it-ebooks.info
Los sprints escalonados pueden funcionar bien para algunos equipos. Si su entorno
de desarrollo no permite lanzamientos frecuentes (por ejemplo, trabaja en software
empaquetado o integrado, o entrega software a un entorno en el que la
implementación continua es difícil o imposible), la ventaja de obtener el diseño
correcto es más alto. En estos casos, Lean UX puede no ser una buena opción para
su equipo, ya que tendrá que trabajar duro para obtener la retroalimentación del
mercado que necesita para que muchas de estas técnicas funcionen.
Para estos equipos, los sprints escalonados pueden permitir una mayor validación
del trabajo de diseño, siempre que sigan trabajando de manera muy colaborativa.
Y los equipos que hacen la transición de Waterfall a Agile también pueden
beneficiarse de trabajar de esta manera, porque les enseña a trabajar en ciclos más
cortos y a dividir su trabajo en partes secuenciales.
Sin embargo, este modelo funciona mejor como transición. No es donde quieres que
termine tu equipo. He aquí por qué: se vuelve muy fácil crear una situación en la que
todo el equipo nunca esté trabajando en lo mismo al mismo tiempo. Nunca te das
cuenta de los beneficios de la colaboración multifuncional porque las diferentes
disciplinas se centran en cosas diferentes. Sin esa colaboración, no construye una
comprensión compartida, 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 es menos que ideal: puede generar
desperdicios innecesarios. Pierdes 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 factibilidad 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,
el trabajo que se dedicó al diseño de esos elementos es un desperdicio.
Construyendo Lean UX en el ritmo de Scrum

Como dije al comienzo de este capítulo, intentamos usar Sprints escalonados en
TheLadders. Y cuando tuvimos problemas, continuamos mejorando nuestro proceso,
eventualmente terminando con una rutina profundamente colaborativa que se
desarrollaba a través de los ritmos de Scrum. Echemos un vistazo a cómo puede
usar la estructura de reuniones de Scrum y Lean UX para construir un proceso eficiente.
Temas
Scrum tiene muchas reuniones. Muchas personas desaprueban las reuniones, pero
si las usa como hitos durante su sprint, puede crear un proceso Lean UX y Agile
integrado en el que todo el equipo está trabajando en lo mismo al mismo tiempo.
98 Capítulo 7
www.it-ebooks.info
Tomemos un modelo de sprint de dos semanas y supongamos que podemos unir

una serie de estos sprints bajo un mismo paraguas, que llamaremos un tema (Figura
7-2).
Figura 7-2. Sprints vinculados con el tema. un
Sesiones de lanzamiento para bocetos e ideación
Cada tema debe iniciarse con una serie de ejercicios de lluvia de ideas y validación
como los descritos en la Sección II. Estas actividades pueden ser tan cortas como
una tarde o tan largas como una semana. Puedes hacerlos con tu equipo inmediato
o con un grupo más amplio. El alcance del tema determinará cuánta participación y
tiempo requieren estas actividades iniciales.
El objetivo de este inicio es hacer que todo el equipo dibuje e idear juntos, creando
una acumulación de ideas para probar y aprender.
Una vez que haya comenzado sus sprints, estas ideas se probarán, validarán y
desarrollarán nuevos conocimientos, y deberá decidir qué hacer con ellos. Usted
toma estas decisiones mediante la ejecución de sesiones posteriores de lluvia de
ideas más cortas que tienen lugar antes de que comience cada nuevo sprint, lo que
le permite al equipo utilizar la información más reciente para crear el backlog para el
próximo sprint. Consulte la Figura 7-3.
Figura 7-3. alcancede esbozo, ideación y lluvia de ideas.

Calendario y sesiones
Reunión de planificación de iteraciones
El resultado de la sesión inicial debe llevarse a la reunión de planificación de la

iteración (IPM). Su desorden de notas adhesivas, bocetos, estructuras alámbricas,
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 entendimiento compartido necesario para extraer
www.it-ebooks.info
historias de ellos. Úselos en su IPM (Figura 7-4) para escribir historias de usuarios
juntos, luego evalúe y priorice las historias.
Figura 7-4. Realice reuniones de planificación de iteraciones inmediatamente después de las sesiones de intercambio de ideas.
Calendario de validación de usuario
Finalmente, para garantizar un flujo constante de opiniones de los clientes contra las
que validar, planifique sesiones de usuario cada semana (Figura 7-5). Su equipo
nunca estará a más de cinco días hábiles de la validación del cliente, pero aún así
sus ideas tendrán tiempo suficiente para reaccionar antes del final del 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 están en bruto, está probando
su valor (es decir, ¿la gente quiere usar mi producto?). Una vez que haya establecido
un deseo por su producto, las pruebas posteriores con artefactos de mayor fidelidad
revelarán si su solución es utilizable.
Figura 7-5. con

Usuarios de conversaciones pase la semana.
todos
100 Capítulo 7
www.it-ebooks.info
Participación
Una de las grandes lecciones que aprendí del diagrama que mostré al comienzo de la Sección
III fue que los diseñadores necesitan tiempo para ser creativos. Los ciclos de dos semanas de
desarrollo y diseño simultáneos ofrecen pocas oportunidades para el tiempo creativo. 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 pone énfasis en el flujo de una sola
pieza). Pero aún puede hacer tiempo dentro de un sprint de Scrum en el que pueden tener lugar
actividades creativas.
La razón por la que mi equipo de UX en TheLadders no encontraba ese tiempo era que no
estábamos participando completamente en el proceso de Scrum. Esto no fue del todo culpa
nuestra: el contenido de muchas reuniones de Scrum ofreció poco valor a los diseñadores de UX.
Sin embargo, sin nuestra participación, nuestras preocupaciones y necesidades no fueron
tomadas en cuenta en los planes del proyecto. Como resultado, no estábamos creando el tiempo
dentro de los sprints para que se llevara a cabo el trabajo creativo; el resto del equipo no entendió
que ese tiempo era necesario.
Para que Lean UX funcione en Agile, todo el equipo debe participar en todas las actividades:
standups, retrospectivas, IPM, sesiones de lluvia de ideas, todas requieren la asistencia de todos
para tener éxito. Además de negociar la complejidad de ciertas características, la participación
interfuncional permite a los diseñadores y desarrolladores crear una priorización efectiva de la
acumulación.
Por ejemplo, imagine al comienzo de un sprint que la primera historia que un equipo prioriza tiene
un gran componente de diseño. Imagine que el diseñador no estaba allí para expresar su
preocupación. Ese equipo fracasará tan pronto como se reúna para su standup al día siguiente.
El diseñador anunciará que la historia no ha sido diseñada. Y él o ella dirá que tomará por lo
menos dos o tres días completar el diseño antes de que la historia esté lista para el 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 necesitara menos preparación de diseño para trabajar
primero, lo que le habría dado al diseñador el tiempo necesario para completar el trabajo.
La otra víctima de la escasa participación es el entendimiento compartido. Los equipos toman

decisiones en las reuniones. Esas decisiones se basan en discusiones. Incluso si el 90 por ciento
de una reunión no es relevante para su necesidad inmediata, el 10 por ciento que es relevante le
ahorrará horas explicando lo que sucedió en la reunión y por qué se tomaron ciertas decisiones.
La participación le permite negociar el tiempo que necesita para hacer su trabajo.

Esto es cierto tanto para los diseñadores de UX como para todos los demás miembros del equipo.
www.it-ebooks.info
El diseño es un deporte de equipo: estudio de caso Knowsy
En este estudio de caso, la diseñadora y entrenadora Lane Halley detalla cómo reunió a todos los
jugadores (desarrollo, diseño, marketing y partes interesadas) para crear un juego para tabletas.
En mi trabajo como diseñador de productos, utilizo prácticas Lean UX en una variedad de

proyectos. Recientemente he trabajado en productos de entretenimiento, comercio electrónico y
redes sociales para diferentes plataformas, incluidos iPad, iPhone y Web.
Los equipos han sido pequeños, de tres a siete personas. La mayoría de mis proyectos también
comparten las siguientes características:
•El proyecto se ejecuta dentro de un marco Agile (enfoque en el cliente, entrega continua,
reuniones en equipo, documentación liviana, responsabilidad del equipo en las decisiones,
rituales compartidos como standups, retrospectivas, etc.).
•El equipo está formado por personas con una combinación de habilidades (desarrollo front-end
y back-end, experiencia de usuario y arquitectura de la información, gestión y marketing de
productos, diseño gráfico, redacción).
•La gente del equipo generalmente se desempeñó en su área de especialización/fortaleza, pero

apoyó otras especialidades y se interesó en aprender nuevas habilidades.
La mayoría de los equipos con los que trabajo crean productos o servicios completamente nuevos.
No están trabajando dentro de un marco o estructura de producto existente.
En proyectos de “campos verdes” como estos, estamos tratando simultáneamente de descubrir
cómo se utilizará este nuevo producto o servicio, cómo se comportará y cómo lo vamos a construir.
Es un entorno de cambio continuo, y no hay mucho tiempo o paciencia para la planificación o el
diseño inicial.
La empresa de juegos de innovación

Innovation Games Company (TIGC) produce juegos serios, en línea y en persona, para la
investigación de mercado. TIGC ayuda a las organizaciones a obtener información útil sobre las
necesidades y preferencias de los clientes para mejorar el rendimiento a través del juego
colaborativo. En 2010, me invitaron a ayudar a TIGC a crear un nuevo juego para el mercado de
consumo.
Formé parte del equipo que creó Knowsy para iPad, un juego de pasar y jugar que se trata de
aprender lo que sabes sobre tus amigos, familiares y compañeros de trabajo, al mismo tiempo que
evalúas qué tan bien te conocen. La persona que conoce mejor a los otros jugadores gana el
juego. Es un juego rápido, divertido y verdaderamente “social” para hasta seis jugadores.
102 Capítulo 7
www.it-ebooks.info
Era nuestra primera aplicación para iPad y teníamos un plazo ambicioso: un mes para crear el
juego y aceptarlo en la App Store. Nuestro pequeño equipo tenía una combinación de
experiencia en la materia y habilidades en el desarrollo de front-end y back-end, así como en el
diseño visual y de interacción. También le pedimos a otras personas que nos ayudaran a probar
el juego en varias etapas de desarrollo.
Una visión compartida potencia el trabajo independiente
Hasta que se codifica un nuevo producto, es difícil para las personas trabajar con la misma
visión del producto. Puede reconocer una falta de visión compartida cuando el equipo discute
sobre qué características son importantes o qué se debe hacer primero.
También puede haber una sensación general de que el equipo no se está “moviendo lo
suficientemente rápido” o que el equipo está repasando los mismos problemas una y otra vez.
Mientras trabajaba en Knowsy, busqué formas de hacer que mi práctica de UX fuera más
colaborativa, visual, ligera e iterativa. Busqué oportunidades para trabajar en tiempo real con
otras personas del equipo (como los desarrolladores y el gerente de producto) y descifrar las
cosas lo más rápido posible con el nivel de fidelidad responsable más bajo.
A medida que encontramos las soluciones correctas y el equipo entendió y aceptó el concepto
de diseño, pude aumentar la fidelidad de los artefactos de diseño, confiando en que
compartíamos una visión del producto (Figura 7-6).
Figura 7-6. Los Knowsy con

equipo
la pared de artefactos detrás de ellos.
www.it-ebooks.info
Romper el cuello de botella del diseño

Al principio del proyecto, me senté con el desarrollador front-end para hablar sobre el diseño
del juego. Creamos juntos un flujo de juego de alto nivel en papel, pasándonos el marcador
de un lado a otro mientras hablábamos. Esta fue mi oportunidad de escuchar y aprender lo
que estaba pensando. Mientras esbozábamos, pude señalar las inconsistencias al hacer
preguntas como: "¿Qué hacemos cuando esto sucede?" Este enfoque tuvo la ventaja de
cambiar el diálogo de "Yo tengo razón y tú estás equivocado" a "¿Cómo resolvemos este
problema?"
Figura 7-7. El prototipo de papel comienza para tomarforma.
Después de que tuviéramos este acuerdo básico, pude crear un prototipo en papel (Figura
7-7) del juego basado en el flujo y probarlo con el equipo.
El efecto en el equipo fue inmediato. De repente, todos "lo entendieron" y estaban
entusiasmados con lo que estábamos haciendo. La gente comenzó a contribuir con ideas
que encajaban bien entre sí, y pudimos identificar en qué partes podíamos trabajar cada uno
que apoyaba el todo.
Una vez que todos estuvimos en sintonía, fue más fácil para mí tomarme un tiempo lejos del
equipo y documentar lo que habíamos acordado en un prototipo en el que se podía hacer
clic. Consulte la Figura 7-8.
104 Capítulo 7
www.it-ebooks.info
Figura 7-8. Lane actualizando el prototipo real del muro de artefactos a tiempo.
El resultado
La incursión de Knowsy en Lean UX resultó ser un éxito. Llevamos la aplicación a la
tienda de Apple antes de la fecha límite. Más tarde me llamaron para ayudar al equipo a
hacer otra variante del producto. Para esa ronda, utilicé un proceso similar. Debido a que
estaba trabajando de forma remota y el equipo de desarrollo no estaba tan disponible
para colaborar, tuve que hacer entregas más pesadas. Sin embargo, el principio básico
de iterar nuestro camino hacia una mayor fidelidad continuó.
Más allá del equipo Scrum

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 sus planes de proyecto dependen de lo que
están aprendiendo. Son receptivos, por lo que su plan típico establece solo pequeños lotes de trabajo a
A lo sumo, estos equipos planean una o dos iteraciones por delante. Esta “miopía”
percibida tiende a no satisfacer a la mayoría de los gerentes de alto nivel. Entonces,
¿cómo mantiene a raya los registros mientras mantiene el ritmo de sus procesos Lean UX
y Scrum?
www.it-ebooks.info
Dos palabras: comunicación proactiva.
Una vez dirigí un equipo que alteró radicalmente el flujo de trabajo de un producto existente que tenía
miles de clientes que pagaban. Estábamos tan entusiasmados con los cambios que habíamos
realizado que continuamos 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 mi escritorio, furiosa y exigiendo saber por qué no se le informó sobre este cambio. Resulta que
cuando los clientes tienen problemas con el producto, piden ayuda. Los representantes del centro de
atención telefónica usan guiones para solucionar las necesidades de los clientes y ofrecer soluciones,
y no tenían un guión para este nuevo producto... porque no sabían que iba a cambiar.
Este saludable trozo 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, no se interpongan en su
camino, asegúrese de que estén al tanto de sus planes.
Aquí hay algunos consejos:
•Comuníquese de manera proactiva con los propietarios y ejecutivos de sus productos.
•Hacerles saber:
– Cómo va el proyecto
– Lo que intentaste hasta ahora y aprendiste
– Lo que intentarás a continuación
•Mantenga las conversaciones enfocadas en los resultados (cuáles son sus tendencias
hacia su objetivo), no conjuntos de funciones.
•Asegúrese de que los departamentos dependientes (servicio al cliente, marketing, operaciones,

etc.) estén al tanto de los próximos cambios que pueden afectar su trabajo.
•Déles suficiente tiempo para actualizar sus flujos de trabajo si es necesario.
106 Capítulo 7
www.it-ebooks.info
Conclusión
Este capítulo analizó más de cerca cómo Lean UX encaja en un proceso Scrum.
Además, hablé sobre cómo la colaboración multifuncional permite que un equipo
avance a un ritmo acelerado y cómo manejar a esos molestos accionistas y
gerentes que siempre quieren saber qué está pasando. Discutí por qué es
fundamental que todos participen en todas las actividades y por qué el modelo de
sprint escalonado es solo un punto de referencia en el camino hacia la verdadera agilidad.
En el próximo y último capítulo, veremos los cambios organizacionales que deben

realizarse para respaldar Lean UX. Este capítulo puede servir como un manual
para los gerentes sobre lo que deberán hacer para preparar a los equipos para el éxito.
www.it-ebooks.info
www.it-ebooks.info
Capítulo 8
Hacer cambios organizacionales
Anteriormente en este libro, discutí los principios detrás de Lean UX. Espero que
entiendas de esa sección que Lean UX es una mentalidad. También he discutido
algunos de los métodos clave de Lean UX, porque Lean UX también es un proceso.
A medida que trabajé con clientes y enseñé estos métodos a los equipos, quedó
claro que Lean UX también es un método de gestión. Por este motivo, deberá
realizar algunos cambios en su organización para obtener el mayor beneficio de
trabajar de esta manera.
Cuando entreno equipos, a veces me preguntan: "¿Cómo puedo poner en práctica

estos métodos aquí?" En este punto, estoy un poco indeciso. Aunque confío en
que la mayoría de las organizaciones pueden resolver estos problemas, también
soy consciente de que cada organización es diferente. Encontrar la solución
adecuada requerirá mucho trabajo y colaboración con sus colegas.
Para prepararlo para ese trabajo, usaré este capítulo para compartir con usted
algunos de los cambios que las organizaciones deben hacer para adoptar Lean
UX. No te voy a decir cómo hacer esos cambios. Ese es tu trabajo. Pero espero
que esta discusión lo ayude a examinar el paisaje para encontrar las áreas que
abordará.
En este capítulo, discutiremos los siguientes cambios que su organización puede

necesitar hacer en estas áreas:
•Pasar de los productos a los resultados
•Pasar de roles limitados a capacidades colaborativas
• Adopción de nuevas habilidades
109
www.it-ebooks.info
•Creación de equipos multifuncionales
•Crear equipos pequeños
•Creación de espacios de trabajo abiertos y colaborativos
•No depender de los héroes
• Eliminación del “Gran diseño por adelantado”
•Poner la velocidad en primer lugar, la estética en segundo lugar
• Valoración de la resolución de problemas
•Abrazar la deuda de UX
•Cultura de agencia cambiante
•Trabajar con proveedores externos
• Navegación de estándares de documentación
•Ser realista sobre su entorno
•Gestionar hacia arriba y hacia afuera
CAMBIO: Resultados
En el Capítulo 3, discutí el rol de los resultados en Lean UX. Los equipos de Lean UX miden su
éxito no en términos de características completadas sino en términos de progreso hacia resultados
específicos. Determinar los resultados es una actividad de liderazgo, una en la que muchas
organizaciones no son buenas o no hacen en absoluto. Con demasiada frecuencia, el liderazgo
dirige al equipo del producto a través de una hoja de ruta del producto: un conjunto de resultados
y características que requieren que el equipo del producto produzca.
Los equipos que intentan utilizar Lean UX deben estar capacitados para diseñar las soluciones a
los problemas comerciales que se les asignan. En otras palabras, deben estar facultados para
decidir por sí mismos qué características 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 los resultados, y este cambio de conversación es radical. Los
gerentes y propietarios de productos deben determinar qué métricas comerciales requieren más
atención. A su vez, deben tener conversaciones sobre los resultados con sus gerentes. De esta
manera, el cambio inevitablemente llegará a los niveles más altos de la organización.
El liderazgo debe establecer esta dirección, y los equipos deben exigir este cambio del liderazgo.
Los gerentes deben volver a capacitarse para dar a sus equipos la libertad de experimentar. Las
conversaciones sobre los requisitos del producto deben basarse en los resultados comerciales:
¿qué estamos tratando de lograr al crear este producto? Esta regla también es válida para las
decisiones de diseño. Los criterios de éxito deben
110 Capítulo 8
www.it-ebooks.info
redefinir y eliminar las hojas de ruta. En su lugar, los equipos acumulan hipótesis que les gustaría
probar y las priorizan en función del riesgo, la viabilidad y el éxito potencial.
MAYÚS: Roles
En la mayoría de las empresas, el trabajo que realiza está determinado por su cargo. 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 las descripciones de su trabajo
(p. ej., "No eres un desarrollador, ¿qué puedes saber sobre JavaScript?"). Este enfoque es
profundamente anticolaborativo y significa que no se utiliza toda la gama de habilidades, talentos y
competencias de los trabajadores.
Desalentar la entrada de funciones cruzadas fomenta los silos organizacionales. Cuanto más
discreto es el trabajo de una persona, más fácil le resulta retirarse a los confines seguros de esa
disciplina. Como resultado, la conversación entre disciplinas se desvanece y crece la desconfianza,
las acusaciones y el comportamiento de "cubrir el trasero". Los silos son la muerte de los equipos
colaborativos.
Para que Lean UX tenga éxito, su organización necesita adoptar un mantra de “competencias
sobre roles”. Cada miembro del equipo posee una competencia básica:
diseño, desarrollo de software, investigación, etc., y debe cumplir con ese conjunto de habilidades.
Sin embargo, él o ella también pueden poseer competencias secundarias que hacen que el equipo
funcione de manera más eficiente.
Permita que sus colegas contribuyan en cualquier disciplina en la que tengan experiencia e interés.
Descubrirá que trabajar de esta manera crea un equipo más comprometido que puede completar
las tareas de manera más eficiente. También encontrará que genera camaradería entre los títulos
de trabajo, ya que las personas con diferentes disciplinas muestran interés en lo que hacen sus
colegas. Los equipos que disfrutan trabajando juntos producen un mejor trabajo.
SHIFT: nuevas habilidades para diseñadores de UX
Muchas empresas contratan diseñadores para crear esquemas, especificaciones y mapas del sitio.
Esta contratación se realiza para llenar la fase de "diseño" del proceso de cascada.
Conectar a los diseñadores de interacción a estos flujos de trabajo existentes limita su efectividad
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
principales. Este cambio requiere dos cambios significativos en la forma en que hemos trabajado
hasta la fecha:
Hacer cambios organizacionales 111
www.it-ebooks.info
Los diseñadores deben abrir el proceso de diseño.
El equipo, no el individuo, debe poseer el diseño del producto. En lugar de esconderse detrás
de un monitor durante días, los diseñadores deben involucrar a los equipos en el proceso de
diseño, buscar su opinión y construir esa perspectiva en el diseño. Si lo hace, comenzará a
romper los silos y permitirá que tenga lugar una conversación más interfuncional.
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. Su liderazgo y facilitación en
actividades grupales de intercambio de ideas, como Design Studio, pueden crear foros seguros
para que todo el equipo conceptualice su producto.
SHIFT: Equipos multifuncionales

Para muchos equipos, la colaboración es una actividad de una sola disciplina. Los desarrolladores
resuelven problemas con otros desarrolladores, mientras que los diseñadores se sientan en bolsas
de frijoles, encienden las lámparas de lava e "idean" con sus hermanos de cuello alto negro (estoy
bromeando... ¡Me encantan los diseñadores!).
Las ideas nacidas de colaboraciones de una sola disciplina son de una sola faceta. No reflejan la
perspectiva más amplia del equipo, que puede iluminar una gama más amplia de necesidades,
como las necesidades del cliente, el negocio o la tecnología. Peor aún, trabajar de esta manera
requiere equipos basados en disciplinas para explicar su trabajo entre sí. Con demasiada frecuencia,
el resultado es una gran dependencia de la documentación detallada.
Lean UX requiere una colaboración multifuncional. Al crear interacción entre gerentes de producto,
desarrolladores, ingenieros de control de calidad, diseñadores y comercializadores, pone a todos en
la misma página. Igualmente importante: pones a todos en el mismo nivel. Ninguna disciplina 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 fines de la década de 1970, "El papel del equipo y las características de la tarea
en la productividad y la resolución colaborativa de problemas en equipos de investigación y
desarrollo",1 encontró un vínculo entre la productividad de resolución de problemas de un equipo y
lo que llamó "cuatro predictores": certeza de la tarea, interdependencia de tareas, tamaño del equipo
y cohesión del equipo. Mantenga la cohesión de su equipo rompiendo los límites basados en la
disciplina.
1 Dailey, 1978, Management Science, vol. 24, núm. 15, 1579–1588.
112 Capítulo 8
www.it-ebooks.info
TURNO: Equipos pequeños
Los grupos más grandes de personas son menos eficientes que los más pequeños. Esto tiene
sentido intuitivo. Pero esto es menos obvio: un equipo más pequeño debe trabajar en
problemas más pequeños. Este pequeño tamaño facilita mantener la disciplina necesaria para
producir productos mínimos viables. Divida sus grandes equipos en lo que el fundador de
Amazon.com, Jeff Bezos, llamó "equipos de dos pizzas" (http://www.fastcompany.com/ 50106/
inside-mind-jeff-bezos). Si el equipo necesita más de dos pizzas para hacer una comida, es
demasiado grande.
MAYÚS: espacio de trabajo
Rompe las barreras físicas que impiden la colaboración. Reubique a sus equipos y cree
espacios de trabajo para ellos que mantengan a todos visibles y accesibles. Haz espacio para
que tu equipo ponga su trabajo en las paredes y otras superficies de trabajo. Nada es más
efectivo que acercarse a un colega, mostrarle algún trabajo, discutir, dibujar, intercambiar
ideas, comprender las expresiones faciales y el lenguaje corporal, y llegar a una resolución
sobre un tema espinoso.
Cuando coubique a las personas, cree agrupaciones multifuncionales. Eso significa sacar a
los miembros del equipo de las comodidades del “escondite” de su disciplina.
Es sorprendente cómo incluso la pared de un cubículo puede dificultar la conversación entre
colegas.
Los espacios de trabajo abiertos permiten que los miembros del equipo se vean entre sí y se
comuniquen fácilmente cuando surjan preguntas. Algunos equipos han ido tan lejos como
poner sus escritorios sobre ruedas para poder trasladarlos más cerca de los miembros del
equipo con los que están colaborando ese día en particular. Aumente estos espacios abiertos
con salas de reuniones donde los equipos puedan intercambiar ideas. Las pizarras blancas
del tamaño de una pared o pintar las paredes con pintura para pizarra blanca proporcionan
muchos pies cuadrados de espacio para debatir. En resumen, elimine los obstáculos físicos
entre los miembros de su equipo. Es posible que al principio no les guste a los planificadores
de espacios, pero las partes interesadas se lo agradecerán.
Si la ubicación conjunta no es una opción, proporcione a los equipos las herramientas que
necesitan para comunicarse. Estos incluyen cosas como software de videoconferencia (por
ejemplo, Skype) y tableros inteligentes, pero también boletos de avión para encontrarse en
persona de vez en cuando. Es sorprendente lo que una o dos reuniones en persona al año
harán en la moral del equipo.
www.it-ebooks.info
SHIFT: No más héroes

En los equipos con los que he trabajado hasta la fecha, no han sido los desarrolladores los que
han rechazado Lean UX. Son los diseñadores los que más han resistido.
¿La razón más grande? Muchos diseñadores quieren ser héroes.
En un entorno en el que los diseñadores crean productos hermosos, pueden alcanzar un aura
heroica. Los requisitos van en un extremo de la máquina de diseño y las magníficas obras de arte
salen. 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 estoy sugiriendo que todos estos diseños sean superficiales. La escolarización, la formación
formal, la experiencia y una buena dosis de inspiración forman parte de cada documento de
Photoshop que crean los diseñadores y, a menudo, los resultados son inteligentes, bien pensados
y valiosos. Sin embargo, esos entregables brillantes pueden conducir a malas decisiones
corporativas. Pueden sesgar el juicio específicamente porque su belleza es muy persuasiva. Los
premios se basan en la estética de los diseños (en lugar del resultado del trabajo), las decisiones
de contratación se toman en función de la nitidez de los wireframes y la compensación depende
de las marcas adjuntas a cada una de las piezas del portafolio.
Los creadores de estos documentos son anunciados como líderes intelectuales y elevados a la
cima del campo del diseño de experiencias. Pero, ¿puede un solo héroe del diseño ser responsable
del éxito de la experiencia del usuario, el negocio y el equipo? ¿Debe anunciarse 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 colaboradores:
diseñadores y no diseñadores— deben colaborar ampliamente. Este cambio puede ser difícil para
algunos, especialmente para los diseñadores visuales con experiencia en agencias interactivas.
En esos contextos, el Director Creativo es intocable. En Lean UX, lo único intocable es la
percepción 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 fallen en las pruebas. Los héroes no admiten el fracaso. Pero los diseñadores de
Lean UX lo aceptan como parte del proceso.
No más BDUF, bebé

En la comunidad Agile, a veces escuchas a la gente hablar sobre Big Design Up Front o BDUF.
He estado abogando por alejarme de BDUF durante años. Pero no siempre fue así.
114 Capítulo 8
www.it-ebooks.info
A principios de la década de 2000, era diseñador de interfaz de usuario en AOL y trabajaba en un

nuevo navegador. El equipo estaba trabajando para encontrar formas de innovar en los conjuntos
de funciones del navegador existentes. Pero siempre tenían que esperar para implementar
cualquier cosa hasta que hubiera creado las maquetas, especificaciones y diagramas de flujo
apropiados que describieran estas nuevas ideas.
Un desarrollador se cansó de esperarme y comenzó a implementar algunas de estas ideas antes

de que los documentos estuvieran completos. Chico, ¡estaba molesto! ¿Cómo podría haber
seguido adelante sin mí? ¿Cómo podría saber qué construir? ¿Y si estaba mal o no funcionaba?
¡Tendría que reescribir todo el código!
Resultó que el trabajo que hizo nos permitió ver algunas de estas ideas mucho antes que antes.
Nos dio una idea de la experiencia real del producto y nos permitió iterar rápidamente nuestros
diseños para que fueran más utilizables y factibles.
A partir de ese momento, relajamos nuestros requisitos de BDUF, especialmente cuando
avanzamos hacia 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 nos escapó. De hecho, al final del proyecto, me dieron un premio simulado
por inspirar “creatividad no documentada” en un
compañero de equipo
Figura 8-1. Mi “premio” por inspirar creatividad indocumentada en ingenieros.
www.it-ebooks.info
SHIFT: Velocidad Primero, Estética Segundo
Jason Fried, director ejecutivo de 37Signals, dijo una vez: “Primero la velocidad, segundo
la estética” (https://twitter.com/ jasonfried/ status/ 23923974217). No estaba hablando de
comprometer la calidad. Hablaba de editar sus ideas y procesos hasta la médula. En
Lean UX, trabajar rápido 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, utilice el que le llevará la menor cantidad de tiempo para crear y comunicar
a su equipo. Recuerde, estos artefactos son una parte transitoria del proyecto, como una
conversación. Hazlo. Sácalo ahí. Conversar. Siga adelante.
La estética, en el sentido del diseño visual, es una parte esencial de un producto y

experiencia terminados. 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 (estructuras, mapas del sitio y diagramas de
flujo de trabajo) es 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ápido qué elementos de la experiencia completa
(diseño, flujo de trabajo, copia, contenido, rendimiento, propuestas de valor, etc.) están
funcionando para los usuarios y que no lo son. Y estará más dispuesto a cambiar y
reelaborar sus ideas si se ha esforzado menos en presentarlas.
SHIFT: Resolución de problemas de valor
Lean UX nos hace hacer preguntas difíciles sobre cómo valoramos el 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 en lugar de ideas terminadas,

cada idea que produzco se siente a medias. De hecho, siento que "voy por el
bronce". Nada de lo que produzco está nunca terminado. Nada es indicativo
del tipo de productos que soy capaz de diseñar. Estoy realizando un trabajo
de medalla de bronce, ¡a propósito! ¿Cómo puedo sentirme orgulloso y dueño
de diseños que simplemente no están hechos?
Para algunos diseñadores, Lean UX amenaza lo que ven como su cuerpo de trabajo
colectivo, su cartera y quizás incluso su futura empleabilidad.
Estas emociones se basan en lo que muchos gerentes de contratación han valorado
hasta la fecha: resultados atractivos. Los bocetos en bruto, la "versión uno" de un
proyecto y otros artefactos de baja fidelidad no son los ingredientes de un "portafolio
asesino", pero todo eso ahora está cambiando.
116 Capítulo 8
www.it-ebooks.info
Si bien su organización debe continuar valorando la estética, el pulido y la atención a

los detalles, la capacidad de pensar rápido y generar un entendimiento compartido
debe obtener una promoción. Los diseñadores pueden demostrar sus habilidades para
resolver problemas ilustrando el camino que tomaron para pasar de la idea al
aprendizaje validado y a la experiencia. Al hacerlo, demostrarán su profundo valor
como diseñadores. Las organizaciones que buscan y recompensan a los solucionadores
de problemas atraerán y se sentirán atraídas por esos diseñadores.
Turno: Deuda UX
A menudo sucede que los equipos que trabajan en procesos ágiles en realidad no
regresan para mejorar la interfaz de usuario del software. Pero, como dice el refrán,
"no es iterativo si solo lo haces una vez". Los equipos deben comprometerse con la
mejora continua, y eso significa no solo refactorizar el código y abordar la deuda
técnica, sino también volver a trabajar y mejorar las interfaces de usuario. Los equipos
deben adoptar el concepto de deuda 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 rastreaba la deuda técnica: “El efecto fue dramático. Una vez que
presentamos [retrabajo] como deuda, toda oposición se desvaneció. No solo no había
duda de que la deuda no se pagaría, sino que se le dio prioridad constantemente.”2
Para usar el concepto de deuda de UX, escriba historias para capturar un análisis de
brecha entre dónde está la experiencia hoy y dónde le gustaría que fuera. Agregue
estas historias a su cartera de pedidos. Abogar por ellos.
SHIFT: Las agencias están en el negocio de los entregables

Aplicar Lean UX en una agencia interactiva no es un desafío pequeño. La mayoría de
las agencias están configuradas de manera que dificultan la implementación de Lean
UX, que se basa en la colaboración multifuncional y la gestión centrada en los
resultados. Después de todo, el modelo comercial básico de la agencia es simple: los
clientes pagan por los resultados, no por los resultados. Pero la cultura de 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 ser difícil en las grandes agencias, donde los procesos
y las "fases del proyecto" fomentan los entregables y los silos departamentales.
Tal vez el obstáculo más desafiante es la expectativa del cliente de "lanzarlo por la
borda" a la agencia y luego ver los resultados cuando esté listo.
La colaboración entre el cliente y la agencia en este caso puede limitarse a
2 Correspondencia privada
www.it-ebooks.info
crítica desinformada e improductiva que se basa en prejuicios personales, políticas

y CYA.
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 resultados.
a los resultados.
Algunas agencias intentan centrarse en los resultados experimentando con un

alejamiento de los contratos de alcance fijo y basados en entregables. En cambio,
sus compromisos se basan en simples acuerdos de tiempo y materiales o, más
radicalmente, en contratos basados en resultados. En cualquier caso, el equipo tiene
la libertad de pasar su tiempo iterando hacia un objetivo específico, no solo un entregable.
Los clientes renuncian a la ilusión de control que ofrece un contrato basado en
entregas, 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.
Para aumentar la colaboración, las agencias pueden intentar derribar los muros que
las separan de sus clientes. Los clientes pueden incorporarse al 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 la contrata,

pero es el modelo bajo el cual se construyen los mejores productos.
Una nota rápida sobre los socios de desarrollo

En las relaciones de agencia, los equipos de desarrollo de software (ya sea en la
agencia, en el cliente o en un equipo de terceros) a menudo son tratados como
extraños y, a menudo, se incorporan al final de una fase de diseño. Es imperativo que
cambie esta tradición: los socios para el desarrollo deben participar durante la vida
del proyecto, y no como observadores pasivos. En su lugar, debe buscar 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 a codo con los desarrolladores.
SHIFT: trabajar con proveedores externos

Los proveedores de desarrollo de software de terceros plantean 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 falle. La relación contractual con estos proveedores puede hacer
que la flexibilidad que requiere Lean UX sea difícil de lograr.
118 Capítulo 8
www.it-ebooks.info
Cuando trabaje con proveedores externos, intente crear proyectos basados en el

tiempo y los materiales. Si lo hace, le permitirá crear una relación flexible con su
socio de desarrollo, que necesita 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 estructure sus
relaciones con los proveedores en torno a él.
SHIFT: Estándares de documentación

Muchas organizaciones tienen estándares de documentación estrictos que les
ayudan a cumplir con el cumplimiento tanto interno como externo y regulatorio.
Independientemente del valor que estos documentos aporten al equipo, la
organización exige que estos se creen de cierta manera y dentro de ciertas pautas.
Intentar eludir este paso conducirá inevitablemente a la repetición del trabajo,
retrasos e insatisfacción con el desempeño de su trabajo.
Esta situación es exactamente cuando, como lo expresó el diseñador y entrenador

Lane Halley, "diriges con la conversación y sigues con la documentación". Las
filosofías y los conceptos básicos de Lean UX se pueden ejecutar en estos
entornos (conversación, resolución colaborativa de problemas, bocetos,
experimentación, etc.) durante las primeras etapas del ciclo de vida del proyecto.
A medida que se prueban las hipótesis y se solidifican las direcciones de diseño,
vuelva de Lean UX al estándar de documentación que requiere su empresa. Utilice
esta documentación exactamente por la razón que exige su empresa: capturar el
historial de decisiones e informar a los futuros equipos que trabajen en este
producto. No permita que eso le impida tomar las decisiones correctas sobre los productos.
SHIFT: Sea realista acerca de su entorno

El cambio da miedo. El enfoque Lean UX trae consigo muchos cambios.
El cambio puede ser especialmente desconcertante para los gerentes que han
estado en su puesto por un tiempo y se sienten cómodos en su función actual.
Algunos gerentes pueden verse amenazados por propuestas de trabajar de una
manera nueva, lo que podría tener consecuencias negativas para usted. En estas
situaciones, intente pedir perdón en lugar de permiso. Pruebe algunas ideas y
demuestre su valor a través de éxitos cuantificables. Ya sea que ahorró tiempo y
dinero en el proyecto o lanzó una actualización más exitosa que nunca, estos
logros pueden ayudarlo a presentar su caso. Si su gerente todavía 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 hora de considerar un
empleo alternativo.
www.it-ebooks.info
SHIFT: Manejando Arriba y Afuera
Lean UX brinda a los equipos mucha libertad para buscar soluciones efectivas. Lo hace
alejándose de un enfoque de hoja de ruta del producto, en lugar de empoderar a los equipos
para que descubran las funciones que creen que servirán mejor a la empresa.
Pero abandonar la hoja de ruta del producto tiene un costo: elimina una herramienta clave que
la empresa usa 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 actualmente no

están involucrados en su trabajo para asegurarse de que estén al tanto de lo que se avecina.
Esta comunicación también lo hará consciente de lo que otros están planeando y lo ayudará a
coordinar. Los gerentes de servicio al cliente, los vendedores, las unidades comerciales 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 cambio,
serán mucho menos resistentes a los cambios que están haciendo los diseños de sus productos.
Dos lecciones valiosas para garantizar ciclos de validación más fluidos:
•Siempre hay otros departamentos que se ven afectados por su trabajo.

Ignóralos bajo tu propio riesgo.
•Asegúrese de que los clientes estén al tanto de cualquier cambio importante que se avecina
y permitirles optar por no participar (al menos temporalmente).
Una última palabra
Justo cuando estábamos dando los toques finales a este capítulo, recibimos un correo electrónico
de un colega. A veces puede parecer imposible cambiar los hábitos arraigados de una
organización. Así que me encantó recibir este correo electrónico, del que he extraído aquí, en el
que Emily Holmes, directora de K12 UX en Hobsons, describe los cambios que ha realizado en
su organización:
120 Capítulo 8
www.it-ebooks.info
Creo que muchas empresas empresariales luchan por encontrar la mejor

manera de implementar estas técnicas. Inicialmente tuvimos mucha
resistencia a que no podíamos hacer Lean UX porque "no somos una
startup", pero por supuesto eso no es cierto.
Trajimos a un entrenador para ayudar a reforzar con el equipo nuestro

objetivo de mover nuestro proceso de desarrollo hacia una metodología
Lean UX (puede ayudar tener una voz externa para reforzar lo que se dice
internamente), y desde entonces hemos hecho un buen progreso. En menos
de un año, la estructura de nuestro equipo ha pasado de esto:
A esto:
www.it-ebooks.info
122 El capitulo es el 8
www.it-ebooks.info
Presenté el siguiente sistema para ayudar a nuestros equipos a internalizar lo

que debe suceder a medida que avanzamos en la fase de descubrimiento de un
proyecto, para que no nos saltemos ningún paso y todos puedan comenzar a
comprender por qué es necesario que ocurra este proceso de pensamiento.
Requiere entrenamiento continuo de mi parte, y aún no lo hemos dominado por

completo, pero realmente está ayudando a que todo el equipo esté sincronizado y
hable el mismo idioma. Eso no es poca cosa, ya que nuestro equipo incluye
personas que están acostumbradas al análisis comercial, las especificaciones
técnicas y el desarrollo en cascada. Es un poco divertido, para que las personas no
se sientan demasiado resentidas por tener que cambiar viejos hábitos. Y
definitivamente nos ayuda a combatir los “monstruos” que tradicionalmente han
sido problemáticos para nuestra organización.
Creo que muchas de las cosas que funcionan para nosotros podrían aplicarse a
otras organizaciones empresariales con bastante éxito.
Yo también lo creo, y espero que los cambios y principios que he esbozado

en este capítulo te sirvan de guía.
www.it-ebooks.info
Conclusión
Lean UX es la evolución del diseño de productos. Combina las mejores técnicas
de diseño de interacción con el método científico para crear productos que son
fáciles de usar, hermosos y mediblemente exitosos. Al combinar las ideas detrás
de Lean Startup, el desarrollo de software Agile y el pensamiento de diseño, este
enfoque elimina la hinchazón y la incertidumbre del diseño del producto y lo empuja
hacia un resultado objetivamente fundamentado. Espero que las tácticas, las
estrategias y los estudios de casos de este libro le hayan sido útiles. Estoy ansioso
por continuar la conversación más allá del libro y me encantaría saber de usted
mientras se prepara para construir sus equipos Lean UX. Si tienes éxito y si fallas,
házmelo saber. Quiero tratar este libro como una instantánea en el tiempo y usar
todos sus conocimientos para continuar impulsando un mejor diseño, dinámica de equipo y éxito.
Envíame un correo electrónico a jeff@jeffgothelf.com o envía un correo electrónico a Josh a josh@joshuaseiden.com
con tus historias. Esperamos con interés escuchar de usted.
124 Capítulo 8
www.it-ebooks.info
Índice
Números
37Señales, 116 B backlog, definido, 96
Herramienta Balsamiq, 62
UN concepto de tamaño de lote, 9

BDUF (Big Design Up Front), 114–115 puntos de
Pruebas A/B, 65, 88
referencia, 25
programa Adobe Fireworks, 64
Enfoque de Big Bang a las guías de estilo, 42, 50
Adobe Test&Target, 89 estética
en cambios organizacionales, 116 ejercicio de mapeo
Gran diseño por adelantado (BDUF), 114–115
de afinidad, 52–53 agencias, interactivo, 117–118
Blank, Steve, 9
características de
Desarrollo ágil de software sobre, XIV,
lluvia de ideas,
6 comunicación en equipos, 35
30 en el estudio de caso de
tiempos de ciclo y, 3, 6 integración de
GE, 43 personas, 29 software
Lean UX y, 95–107 terminología para,
de transmisión, 78
96–97 herramientas de análisis, 88 suposiciones
Brown, Tim, 5 ciclo
de retroalimentación construir-medir-aprender, 7
Hoja de trabajo de supuestos comerciales, 21 botón
a ninguna parte, 69
Hoja de trabajo de supuestos comerciales, 21
C
declarar, 18–22 definir,
17 formular enunciados llamado a la acción, 58
de problemas, 19–20 comentarios e
investigación de estudios de casos, 79–86
priorización, 22 Guía de estilo de General Electric, 43–46
pruebas, 22–25 Knowsy, 102–105 cambiar
Herramienta Axure RP, 64 el entorno, 119
125
www.it-ebooks.info
prototipos de estructura alámbrica en los socios de desarrollo, 118

que se puede hacer clic sobre, 84 descubrimiento colaborativo, 74–
baja fidelidad, 61–63 fidelidad media 76, 86–89 continuo, 76–78, 86–89
y alta, 64–65 prototipos codificados, estándares de documentación, 119
65, 85 diseño colaborativo sobre, 33–35 configuraciones de monitor dual, 53
estudio de caso en, 43–51 ejemplo de, 36
para distribución geográfica equipos,
51–54 ejecutando un estudio de diseño,
37–41 guías de estilo, 41–42
Correo electrónico como MVP no prototipo,
descubrimiento colaborativo sobre, 74–
69 Emerson, Ralph Waldo, 55
76 técnicas de monitoreo para,
experimentación, cultura de, 11 experimentos
86–89
y MVP. Ver MVPs (Productos Mínimos Viables)
externalización del trabajo, 10–11
comunicación en equipo, 35, 106; F

Agricultura apoyada por la comunidad falla, permiso para, 11–12
(CSA) ejemplo, 27 características
Jugadores Más Valiosos de Concierge, 70 Prueba A/B, 65
Constable, Giff, 21, 25 botón a ninguna parte, 69
descubrimiento continuo acerca identificación en declaraciones de hipótesis, 25,
de, 9, 76–78 técnicas de 30 comentarios e investigación sobre,
monitoreo para, 86–89 estilos de redacción 73–74 estudio de caso, 79–86 descubrimiento
en guías de estilo, 48 comportamiento cubre tu colaborativo, 74–76, 86–89 descubrimiento
trasero (CYA), 111 crítica (Design Studio), 39 continuo, 76–78, 86–89 técnicas de monitoreo
equipos multifuncionales aproximadamente, 7–8 para, 86–89 reclutar participantes, 78 simplificar
cambios organizacionales en, 112 el entorno de prueba, 78
CSA (apoyado por la comunidad

Agricultura) ejemplo, 27
atención al cliente, 86–87 Feynman, Ricardo, 17
Comportamiento CYA (cúbrete el culo), 111 Herramienta Diseñador de fluidos, 62
Frito, Jason, 116
D
Dailey, Robert, 112 GRAMO
demostraciones de prototipos, 66 Estudio de caso de General Electric, 43–46

Design Studio equipos distribuidos geográficamente
sobre, 34, 37 ejercicio de mapeo de afinidad, 52–53
generación de ideas en equipo, colaboración con, 51–54 presentación de
41 generación de ideas individuales, 38–39 preparación para, 52
iteración y perfeccionamiento de ideas, 40 Glusman, Andrés, 79
presentación y crítica, 39 definición de Acrónimo de GOOB, 9–10
problemas y restricciones, 38 Palabras publicitarias de Google, 69
Experimentos de contenido de Google, 89
flujo del proceso, 37–41 Documentos de Google,
suministros necesarios, 37–38 51–52 proyectos totalmente
pensamiento de diseño. Véase también diseño nuevos, crecimiento XV, aprendizaje, 11
colaborativo sobre, XIV, 5–6 proceso
de diseño de reenfoque, 12–13 tamaño de lote
pequeño en, 9
126 Índice
www.it-ebooks.info
H K
prototipos codificados a mano, 65 indicadores clave de rendimiento (KPI), 25–26

héroes, diseñadores como, 114
prototipos de alta fidelidad, 63–64, 84 Estudio de caso Knowsy, 102–105
Holmes, Emily, 120 KPI (indicadores clave de rendimiento), 25–26
Hurston, Zora Neale, 73 hipótesis
definidas, 18 subhipótesis, 23–26,
30–31 formato típico para, 22– L
23 enunciados de hipótesis sobre, 17
páginas de aterrizaje, 69
montaje de subhipótesis, 30–31
Método Lean Startup, XIII, 7
suposiciones en, 17, 18–22 completar, 25–29
Lean UX
elementos en, 17–18 características en,
sobre, XIII–XV, 3–4
25, 30 hipótesis en, 18, 22–25 resultados en,
fundamentos de, 5–7
18, 25–26 personajes en, 25, 26–29
integración del desarrollo Agile y, 95–107
principios detrás, 7–12
aprender sobre el crecimiento, 11

prototipos de datos en vivo, 65 guías
de estilo en vivo, 51 prototipos de
baja fidelidad estructuras alámbricas
en las que se puede hacer clic, 61–63
yo
papel, 59–60
ideas e ideación
generando individuo, 38–39 generando M
equipo, 41 iterando y refinando, 40
rediseñar el análisis, 11 administrar
sesiones iniciales para, 99 presentando
hacia arriba y hacia afuera, 120
y criticando, 39 priorizando, 58
reuniones, metodología Scrum, 98–100 estudio de
caso de Meetup, 79–80 métricas y puntos de referencia
de medición, 25 medir el comportamiento, 58 medir el
firma de diseño IDEO, 5
progreso, 8 programa Microsoft PowerPoint, 62
IIDS (Sistema de Diseño de Internet Industrial),
programa Microsoft Visio , 62 prototipos de
44–46
fidelidad media, 63–64 Miller, Lynn, 91, 97
Sistema de Diseño de Internet Industrial
Productos mínimos viables (MVP) sobre, 7, 55–56
(IIDS), 44–46
creación, 57–65 enfoque de, 56–57 híbridos, 69 no
sobre la integración de Lean UX y Agile,
prototipo, 69 prototipos , 66–69 maquetas. Ver
95–96
prototipos de técnicas de monitoreo para un
Estudio de caso Knowsy, 102–105
descubrimiento colaborativo continuo, 86–89
Consideraciones de participación, 101
Metodología Scrum y, 98–100 sprints
escalonados y, 95, 97–98 terminología para,
96–97 elementos de diseño de interacción en
guías de estilo, 46 agencias interactivas, 117–118
guía de entrevistas, 76
IPM (reunión de planificación de iteraciones), 97, 99–

100 reunión de planificación de
iteraciones (IPM), 97, 99–100
Índice 127
www.it-ebooks.info
MVP (productos mínimos viables) personas

aproximadamente, 7, 55–56 creación, acerca de, 25,
57–65 enfoque de, 56–57 híbridos, 69 26 lluvia de ideas, 29
no prototipo, 69 prototipos, 66–69 protopersonajes, 26–29
Petrov, Greg, 43–44
Poehler, Amy, 33
Herramienta Pop Prototyping on Paper, 62
presentación y crítica (Diseño
norte Studio), 39
vistas previas de prototipos, 66
MVP no prototipos sobre,
principios del concepto de tamaño
68–69 tipos de, 69
de lote Lean UX, 9
descubrimiento continuo, 9
equipos multifuncionales, 7–8
LA trabajo de externalización, 10–11
O'Brien, James, 117 GOOB, 9–10
Programa OmniGraffle, 62 aprendizaje sobre crecimiento,
encuestas de opinión in situ, 87–89 11 remodelación del análisis,
cambios organizativos, 109–110 11 permiso para fallar, 11–12
equipos enfocados en problemas,
BDUF, 114–115 8 el progreso es igual a resultados,
entorno de cambio y, 119 equipos 8 reenfoque del proceso de diseño, 12–13
multifuncionales, 112 habilidades de eliminación de desperdicios, 8–9
diseñador, 111–112 socios de entendimiento compartido, 10 mentalidad
desarrollo, 118 estándares de de equipo, 10 tamaños de equipo, 8
documentación, 119 héroes, 114 suposiciones prioritarias, 22 ideas, 58
agencias interactivas, 117–118 comunicación proactiva, 106 definición de
resultados, 110–111 hojas de ruta de problemas y restricciones
productos, 120 roles, 111 equipos
pequeños, 113 velocidad y estética,
116 proveedores externos, 118–119
(Design Studio), 38
equipos enfocados en problemas, 8
enunciados de problemas, 19
Deuda de UX, 117 elementos de, 20 plantillas de
resolución de problemas de valor, 116–117 enunciados de problemas, 20
espacio de trabajo, 113 equipos centrados ciclos de vida de desarrollo de productos
en resultados, 105
resultados método Lean Startup y, 7
creando, 17, 25–26 Lean UX in, XIV
definido, 8, 18 distribución de software in, 3
Estudio de caso Knowsy, 105 hojas de ruta de productos, 120 proto-
cambios organizacionales en, 110–111 personajes sobre, 26–27 proceso de
valores atípicos, estacionamiento para, 81 creación para, 29 formatos para
salidas, definidas, 8 dibujo, 28–29 prototipo de prueba
de MVP, 66 consideraciones de
P uso, 66–67 prototipos sobre, 59 elección
herramientas para, 59 estructura
prototipos en papel, 59–60, 104
alámbrica en la que se puede hacer
estacionamiento para valores
clic, 61–65, 84
atípicos, 81 patrones, identificación,
81, 82 permiso para fracasar, 11–12
128 Índice
www.it-ebooks.info
codificado, 65, consideraciones de uso, 50

85 demostraciones y vistas wikis como, 41, 49 ensamblaje
previas, 66 contenido determinante de subhipótesis, 30–31
de, 66 alta fidelidad, 63–64, 84 descomposición de hipótesis
baja fidelidad, 59–63 fidelidad en, 23–26
media, 63–64 papel, 59–60, 104 encuestas, comentarios en línea, 87–89
Sy, Desiree, 91, 97
R T
investigar. Ver comentarios y reuniones tabla de contenido (TOC), 50
retrospectivas de investigación, 96 Ries, equipos. Véase también comunicación de
Eric, XIII, 7 hojas de ruta, producto, 120 diseño colaborativo en, 35, 106
roles, cambios organizacionales en, 111 multifuncional, 7–8, 112 distribuida
geográficamente, 51–54 centrada en
resultados, 105 centrada en problemas, 8
S consideraciones de tamaño, 8, 113
mentalidad basada en equipos, 10 pruebas
cronogramas, validación de usuarios,
A/ B, 65, 88 suposiciones, 22–25 funciones,
100 Metodología Scrum que construye
65 prototipos, 66 entorno de simplificación, 78
Lean UX en, 98–100 definidos, 96
probar todo la política, 82 usabilidad, 78,
reuniones y, 98–100 participación en,
80 The Innovation Games Company
101 registros de búsqueda, 88
(TIGC), 102 temas, sprints y 98
presentaciones de configuración para
proveedores externos, 118–119 37
equipos distribuidos geográficamente, 52
Signals, 116 TIGC (The Innovation Games
entendimiento compartido, 10, 36 turnos,
Company), 102 TOC (índice), 50
organizativo. Ver cambios
organizacionales
análisis de uso del sitio, 88

Sivers, Derek, 12 se
recopilaron
comentarios sobre bocetos, 83
sesiones iniciales para, 99
enfoque de goteo lento para guías de estilo,
42, 50 distribución de software,
U
3 velocidad y estética en cambios
organizacionales, 116 laboratorios de usabilidad,
78 pruebas de usabilidad, 78, 80
sprints historia de usuario, definida, 96
definidos, 96 programaciones de validación de usuario, 100
escalonados, 91, 95, 97–98 deuda UX, 117
temas y, 98–99 modelo de
sprint escalonado, 95, 97–98 reuniones de
EN
pie, 96 wireframes estáticos, 83–84 guías
programación
de estilo, 41–42 características de éxito ,
de validación para usuarios,
48–50 componentes de, 46–47 crear, 42,
100 ciclos más fluidos para,
50 vivir, 51 mantener, 42, 50
120 resolución de problemas de valor,
116–117 proveedores, terceros, 118–
119 verificación de datos, 81 elementos
de diseño visual en guías de estilo, 48–49
Índice 129
www.it-ebooks.info
Eliminación de residuos W ,
8–9, 55 modelo en cascada, 8, 98
Webtrends Optimize, 89 wikis
como guías de estilo, 41, 49
wireframes en los que se puede
hacer clic, 61–65, 84 prototipos
de baja fidelidad, 61–63 prototipos de
fidelidad media y alta, 64–65 estáticos, 83–
84 trabajo, externalización, 10– 11
espacio de trabajo en turnos
organizacionales, 113
Y
Sí, Cheryl, 70
130 Índice
www.it-ebooks.info
“Lectura obligatoria para emprendedores.”

—Dan Heath, coautor de Switch y Made to Stick
“La plantilla esencial para comprender el desafío de liderazgo crucial de

nuestro tiempo: ¡iniciar y administrar el crecimiento!”
—Warren Bennis, Profesor Distinguido de Negocios,

Universidad del Sur de California
“Cambia la forma en que pensamos sobre la innovación y el espíritu empresarial”.

–El tiempo financiero
@leanstartup facebook.com/EricRies
THELEANSTARTUP.COM
Obtenga más información sobre cómo Dropbox, Wealthfront y
otras startups exitosas están construyendo sus negocios.
www.it-ebooks.info

Lean UX - Applying Lean Principles To Improve User Experience (PDFDrive) - 1

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Lean UX - Applying Lean Principles To Improve User Experience (PDFDrive) - 1

Cargado por

Copyright:

Formatos disponibles

Machine Translated by Google

Machine Translated by Google

Elogios para Lean UX

“Customer Development y Lean Startup cambiaron la forma en que se construyen los

Alex Osterwalder, autor y empresario;

Tom Boates—VP, experiencia del usuario, RunKeeper

Bill Scott—Sr. Director, ingeniería de interfaz de usuario, PayPal, Inc.

resolución de problemas sin un pesado equipaje de entrega”.

Christian Crumlish—Director de Producto, CloudOn

modernos. Lean UX es la colección de técnicas y mentalidad que recomiendo a los equipos de

productos modernos que saben que necesitan los beneficios de ambos”.

Marty Cagan—Fundador, Silicon Valley Product Group;

Ex vicepresidente sénior de productos y diseño de eBay

nuestros equipos de diseño, UX y productos en Moz”.

Rand Fishkin—CEO y cofundador, Moz

forma en que crea productos”.

Laura Klein—Directora, los usuarios saben

más inteligente y resultados basados en resultados.

con los diseñadores, pueden beneficiarse enormemente de Lean UX”.

Ben Yoskovitz, vicepresidente de productos, GoInstant

Experiencia de usuario optimizada

Aplicación de los principios Lean a

Pekín · Cambridge · Farnham · Colonia · Sebastopol · Tokio

Experiencia de usuario optimizada

por Jeff Gothelf

Derechos de autor © 2013 Jeff Gothelf. Reservados todos los derechos.

Editora de adquisiciones: Mary Treseler Indexador: Lucie Haskins

Editor de desarrollo: Josh Seiden Compositor: Holly Bauer

Marzo 2013: Primera Edición.

Historial de revisión de la primera edición:

2013-02-08 Primer lanzamiento

Para Carrie, Grace y Sophie

Sección I: Introducción y Principios

Sección II: Proceso

Sección III: Haciendo que funcione

Cuando cuento esta historia a personas que no son diseñadores, se horrorizan y

morir de vergüenza. Están constantemente inundados de quejas de cada una de las

Pero la culpa no es de los diseñadores, ni de los ingenieros, ni siquiera de los ejecutivos.

Es hora de romper los silos, unir los clanes y ponerse a trabajar.

La mentira más grande en el software es la Fase II.

Si ha dedicado algún tiempo a crear productos digitales en los últimos 20 años:

La unión de Lean Startup y el diseño basado en la experiencia del usuario (UX)—

¿Qué es Lean UX y en qué se diferencia?

en una colaboración transparente y multifuncional que incorpora a personas que no son

¿Para quién es Lean UX?

¿Tú qué sacas de esto?

•La Sección II se enfoca en el proceso. Cada capítulo da un paso en el ciclo Lean UX y

•La Sección III aborda la integración de prácticas Lean UX en su organización. Discuto

Una nota de Jeff

A continuación, me gustaría agradecer a Mary Treseler, mi editora en O'Reilly. Pasamos

En el camino, me asocié con Matthew Rothenberg para superar el obstáculo de las

Me gustaría agradecer a mi compañero de escritura Josh Seiden. Pasamos

En particular, me gustaría agradecer a las muchas personas que han contribuido

Finalmente, quiero agradecer el amor, la paciencia y el apoyo que he recibido

Una nota de Josh

el grupo Balanced Team (http:// www.balancedteam.org) ha tenido una profunda

Gracias, finalmente, a Vicky, Naomi y Amanda. te quiero.

¿Por qué Lean UX?

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

Hoy nos enfrentamos a una nueva realidad. Internet ha cambiado la distribución de

Es tiempo de un cambio. Lean UX (UX = experiencia de usuario) es la evolución del diseño de

Lean UX es profundamente colaborativo y multifuncional, porque ya no podemos darnos el lujo

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