Lean UX, parte 6

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

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

Lean UX, fase 4
Lean UX, fase 4

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

Descubrimiento colaborativo

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

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

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

Descubrimiento continuo

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

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

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

Feedback obtenido

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

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

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

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

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

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

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

***

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

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

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

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

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

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

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

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

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

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

Lean UX, parte 5

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

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

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

Introducción

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

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

Ejecución de un experimento con prototipos

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

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

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

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

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

Método: prueba de usabilidad

¿Quiénes participan?

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

Antes de empezar

  • Prototipo.

Ejecución

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

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

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

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

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

Recomendaciones para conducir una prueba de usabilidad

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

Recomendaciones para tomar notas

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

Lean User Research
Lean User Research

Stoppers

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

Values

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

Feedback

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

Recommendations

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

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

Pruebas de usabilidad automatizadas

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

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

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

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

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

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

***

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

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

Lean UX, parte 4

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

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

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

Estudio de Diseño Colaborativo

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

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

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

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

Método: Estudio de diseño

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

¿Quiénes participan?

  • Todo el equipo. Todas las disciplinas involucradas.

Antes de empezar

  • Declaración de supuestos.

Ejecución

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

Plantillas

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

Descripción de pasos

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

Definición del problema y restricciones

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

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

Generación de ideas individuales

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

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

Presentación y críticas

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

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

Iteración y perfeccionamiento

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

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

Todos deben presentar nuevamente sus ideas.

Trabajo en equipo

El tiempo estimado es de 45 minutos.

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

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

Producto Mínimo Viable

Lean UX, Minimum Viable Product.
Minimum Viable Product.

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

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

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

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

Tipos de MVP

Un MVP puede tener dos objetivos:

  • Obtener aprendizaje
  • Generar valor

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

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

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

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

¿A quién va dirigido un MVP?

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

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

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

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

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

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

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

¿Cuánta calidad debe tener un MVP?

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

Keep it simple stupid.
Keep it simple stupid.

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

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

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

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

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

Consideraciones para la creación de un MVP

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

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

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

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

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

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

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

Prototipos

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

De acuerdo a su complejidad, se clasifican en:

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

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

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

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

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

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

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

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

Pretotipos

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

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

Ejemplos de técnicas de pretotipos son:

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

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

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

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

***

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

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

Lean UX, parte 3

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

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

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

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

Supuestos

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

Definir supuestos tiene las siguientes ventajas:

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

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

Declaración de supuestos y priorización

Declaración de supuestos
Declaración de supuestos.

¿Quiénes participan?

Todo el equipo y todas las disciplinas involucradas.

Antes de empezar

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

Ejecución

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

Plantillas

 

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

Declaración de hipótesis

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

¿Quiénes participan?

Todo el equipo y todas las disciplinas involucradas.

Antes de empezar

  • Declarar supuestos.

Ejecución

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

Creemos que [declaración] es cierta.

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

[feedback cualitativo].

[feedback cuantitativo].

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

Resultados

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

Método: brainstorming

¿Quiénes participan?

Todo el equipo y todas las disciplinas involucradas.

Antes de empezar

  • Declarar hipótesis.

Ejecución

Responder las siguientes preguntas:

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

Personas

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

Método: Protopersonas

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

Protopersonas.
Protopersonas.

¿Quiénes participan?

Todo el equipo y todas las disciplinas involucradas.

Antes de empezar

  • Declarar supuestos.

Ejecución

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

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

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

Plantillas

Funciones

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

Método: brainstorming

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

¿Quiénes participan?

Todo el equipo y todas las disciplinas involucradas.

Antes de empezar

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

Ejecución

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

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

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

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

***

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

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

Lean UX, parte 2

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

Pilares

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

1. Design Thinking

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

Tim Brown, CEO de IDEO

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

Proceso Design Thinking.
Proceso Design Thinking.

2. Metodologías de desarrollo ágil de software

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

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

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

Manifiesto ágil

 

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

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

3. Lean Startup

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

Eric Ries
Lean Startup

 

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

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

Proceso Lean Startup.
Proceso Lean Startup.

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

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

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

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

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

Principios

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

Jeff Gothelf define los principios de la siguiente forma:

1. Equipos multifuncionales

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

2. Equipos pequeños, dedicados, coubicados

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

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

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

4. Equipos centrados en los problemas

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

5. Eliminación del despilfarro

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

6. Lotes pequeños

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

7. Descubrimiento continuo

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

8. Get out of the building

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

9. Entendimiento común

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

10. Antimodelos: estrellas, gurús y ninjas

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

11. Exteriorización del trabajo

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

13. Hacer en lugar de analizar

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

14. Aprendizaje en lugar de crecimiento

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

15. Permiso para equivocarse

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

16. Escapar de los negocios basados en entregables

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

***

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

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

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

Lean UX, parte 1

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

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

Un poco de historia

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

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

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

Modelo en cascada
Modelo en cascada

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

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

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

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

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

Este es el paradigma que intenta romper Lean UX.

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

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

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

Proceso original Lean UX
Proceso original Lean UX

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

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

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

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

Ciclo Lean UX
Ciclo Lean UX

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

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

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

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

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