Un manifiesto sobre sketching

Este manifiesto sobre sketching (o bocetado), publicado originalmente en inglés por  es un recordatorio que todos debemos tener en mente mientras trabajamos desarrollando ideas y productos. Este manifiesto es un punto de referencia que será muy útil mientras otras personas en un equipo de trabajo aprenden sobre la importancia de esta disciplina.

  1. El sketching es para todo el mundo.
    ¿Tienes alguna idea? Entonces el bocetado es para tí.
  2. Todos pueden hacer un sketch.
    Sí, eso te incluye a ti también.
  3. Hay que practicar todos los días.
    La consistencia es la clave para volverse bueno.
  4. El sketching es una actividad personal y también una actividad de grupo.
    Es necesario saber cuándo hay que trabajar solo y cuando hay que invitar a otros.
  5. Todo lo que se necesita es papel y un lápiz.
    No se trata de cual herramienta usas, sino lo que haces con ella.
  6. Lleva una libreta para bocetar a todas partes.
    Nunca se sabe cuando te llegará una idea, más vale estar preparado.
  7. Experimenta con tus sketches.
    Intenta utilizar colores, marcadores, sharpies, pinceles o tabletas digitales. Encuentra lo que te permite expresarte mejor (ver #16).
  8. Acepta las limitaciones de un sketch.
    Las imperfecciones son lo que hacen esta técnica especial.
  9. Sketching no es un programa que se descarga de Internet.
    No utilices herramientas digitales para reemplazar un boceto.
  10. No subestimes el poder de un sketch.
    Nunca, nunca, nunca lo subestimes, ¿de acuerdo?
  11. Sáltate la etapa de bocetado bajo tu propio riesgo.
    Puede que te sientas productivo por ahorrar unas horas de trabajo, pero te advertimos, tu idea terminará pagándolas.
  12. El propósito de bocetar no es hacer bocetos.
    No hay premios ni reconocimientos para sketches bonitos. (Ver #8).
  13. Utiliza el poder de un sketch.
    Úsalo para idear, iterar y comunicarte con otros.
  14. Nunca cedas a la presión en tus sketches.
    Dibuja tu visión y no cedas, los dioses del sketch te lo agradecerán.
  15. Hacemos sketches para entender.
    Si puedes bocetar tu idea, entonces entiendes la idea.
  16. Divértete haciendo sketches.
    Finalmente te pagan por dibujar, ¿no es genial?
Somos un grupo de profesionales de UX que trabajamos para fortalecer y profesionalizar a la comunidad de Experiencia de Usuario (User Experience) en español. Hacemos eventos en vivo por la noche para platicar de User Experience.

Diseño atómico y elementos digitales

El término “página web” es una reminicencia del pasado académico de la web, y ha sido una metáfora útil para acercar a los usuarios finales a esta tecnología. Desde la perspectiva de diseño, es necesario de ir más allá de hacer páginas para comenzar a crear sistemas multiplataforma.

Con el tiempo, la Web ha evolucionado y ya no está confinada al escaparate de un navegador web en una PC, sino que ha dado el salto a una enorme cantidad de dispositivos diversos, desde dispositivos móviles como smartphones hasta televisiones inteligentes, todos con diferentes capacidades, tamaños de pantalla, formatos y métodos de interacción.

Algunos de los dispositivos con los que las personas navegan la web
Algunos de los dispositivos que las personas usan para navegar en la web.

En este multiverso tecnológico, los profesionistas que crean, diseñan y mantienen la web se benefician al utilizar métodos y mejores prácticas que ayuden a mantener la consistencia y la escalabilidad de sus proyectos. Un concepto que se usa con frecuencia en pláticas sobre diseño de experiencia de usuario es la modularidad. Es aquí donde entran los conceptos de Diseño Atómico.

La metodología de Diseño Atómico

Diseño Atómico (Atomic Design) es una metodología de diseño creada por Brad Frost enfocada en la reutilización acumulativa de elementos modulares sencillos para crear estructuras de información más complejas.

El Diseño Atómico no se trata de diseñar una sola instancia de una página web a la vez, sino que vistos desde un punto de vista más amplio, se usa para crear la base de sistemas más grandes. El Diseño Atómico ayuda a que el diseño interactivo pueda adaptarse rápidamente a diferentes dispositivos, y es compatible con procesos de diseño centrado en el usuario, ya que se puede implementar desde las etapas tempranas de diseño usando sketches y prototipos.

La metodología de Diseño Atómico  se compone de cinco capas que trabajan juntas para crear interfaces y sistemas:

Los elementos del Diseño Atómico

1. Átomos

En esta metodología, los átomos son los elementos básicos que se utilizan en la construcción de interfaces digitales que no pueden ser reducidos en componentes más simples sin perder su funcionalidad. Los átomos de una página web incluyen las etiquetas básicas de HTML como párrafos, campos de texto, botones y  etiquetas, así como elementos básicos de estilo como colores y tipografías.

Átomos en HTML
Átomos en HTML

La tabla periódica de elementos HTML de Josh Duck ilustra de manera muy clara como todos nuestros sitios web, web apps, mensajes de correo, intranets y cualquier cosa que se visualice con un navegador web están compuestos de los mismos elementos:

Tabla periódica de elementos HTML
Tabla periódica de elementos HTML

2. Moléculas

En el diseño de interfaces, las moléculas son grupos relativamente simples de elementos visuales que funcionan juntos como una unidad. Un ejemplo sería juntar un campo de texto, una etiqueta de formulario y un botón para crear la molécula de un formulario de búsqueda.

Molécula de búsqueda
Molécula de búsqueda

Cuando se combinan, estos átomos tienen un propósito nuevo: la etiqueta define la entrada del campo, y el botón envía la información del formulario para ejecutar una búsqueda. El resultado es un componente simple y reutilizable que puede ser incluirse en cualquier sistema que necesite la funcionalidad de búsqueda.

3. Organismos

Los organismos son componentes de UI relativamente más complejos compuestos por átomos, moleculas y otros organismos. Los organismos se integran para crear las diferentes secciones de una interfaz.

Si a nuestra molécula de búsqueda le agregamos algunos elementos más, podremos obtener el organismo del encabezado, un elemento común en muchas páginas web.

Organismo de Encabezado
Organismo de Encabezado

4. Plantillas

Las plantillas son objetos a nivel de página –noten como aquí abandonamos la metáfora de elementos químicos y regresamos a elementos editoriales– que utilizan componentes basados en átomos, moléculas u organismos en una distribución que hace tangible la estructura general de contenido.

Plantilla con contenedores
Plantilla con contenedores para contenido

Las plantillas organizan los componentes básicos y les agregan contexto para que la página funcione correctamente. Otra característica importante de las plantillas es que se enfocan en la estructura del contenido en lugar del contenido final de la página. Los sistemas dinámicos deben poder adaptarse a contenido dinámico que cambia todo el tiempo, y las plantillas proveen los mecanismos para definir las propiedades de los componentes que las integran, como el tamaño y alineación de sus imágenes o la longitud y estilo de sus encabezados y párrafos.

5. Páginas

Las páginas son instancias específicas de las plantillas que utilizan contenido real. Si tomamos la plantilla de la capa anterior y la llenamos contenido real en sus contenedores podremos ver el resultado final del proceso.

Página con contenido final
Página con contenido final

Ventajas de utilizar Diseño Atómico

Como mencionaba al principio, una de las principales ventajas de utilizar esta metodología es que está enfocada en la modularidad, lo que permite crear elementos simples que pueden reutilizarse constantemente en equipos de diseño y desarrollo de cualquier tamaño sin perder la consistencia del diseño final.

La modularidad del Diseño Atómico también habilita la transversalidad entre los componentes abstractos y concretos del diseño, lo que permite generar diferentes patrones de interfaz reutilizando los mismos elementos al reorganizar su arquitectura y crear nuevos contextos para ellos.

Modularidad y reutilización de elementos atómicos
Modularidad y reutilización de elementos atómicos

El Diseño Atómico es muy útil para crear un sistema de lenguaje de diseño (Design Language System o DLS) para crear prototipos y código más eficiente y que cualquier persona en el equipo de producción puede entender y utilizar para procesos de diseño y desarrollo más rápidos y productivos. Al final, el Diseño Atómico no es un proceso lineal, sino un modelo de pensamiento sobre el que se puede iterar para crear sistemas complejos partiendo de elementos sencillos.

Equipos de productos reales, como el de Airbnb se han beneficiado al implementar Diseño Atómico en sus procesos de diseño y desarrollo, integrándolo a las metodologías que ya utilizaban previamente.

Elementos de diseño en Airbnb creados con Atomic Design
Elementos de diseño en Airbnb creados con Atomic Design

Brad Frost y Dave Olsen crearon un generador de elementos llamado Pattern Lab, basados en los principios de Diseño Atómico. Este generador está creado con el principio de “Móvil primero” (mobile first) con opciones para ajustar el tamaño de las páginas y de agregar comentarios a las secciones del sitio y a los bloques de construcción a nivel de código.

Pattern Lab, un generador de elementos para Atomic Design
Pattern Lab, un generador de elementos para Atomic Design

La versión original de Pattern Lab está escrita en PHP, pero ya hay dos versiones para NodeJS: una para Gulp y otra para Grunt. Recomiendo ampliamente jugar un poco con el demo en la herramienta para entender mejor cómo funciona una implementación real de Diseño Atómico.

* * *

Vale la pena recordar que la diversidad en los dispositivos con los que nuestros usuarios navegan la web o consumen información no se detendrá, sino que seguirá creciendo de manera acelerada, y posiblemente los modelos de diseño y desarrollo tradicionales no soportarán esa diversidad sin adaptarse a formas más ágiles de trabajo. Diseño Atómico es una metodología que  puede ayudarnos a crear sistemas e interfaces que se pueden adaptar a cualquier entorno.

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

Lean UX, parte 6

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

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

Lean UX, fase 4
Lean UX, fase 4

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

Descubrimiento colaborativo

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

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

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

Descubrimiento continuo

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

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

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

Feedback obtenido

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

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

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

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

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

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

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

***

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

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

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

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

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

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

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

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

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

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

El rol del Sprint Master en un Design Sprint

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

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

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

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

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

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

El trabajo del sprint master

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

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

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

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

Antes del design sprint

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

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

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

Durante el design sprint

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

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

Después del design sprint

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

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

Diseñando con Design Sprint

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

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

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

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

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

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

Proceso de Design Sprint

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

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

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

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

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

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

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

Lean UX, parte 5

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

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

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

Introducción

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

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

Ejecución de un experimento con prototipos

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

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

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

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

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

Método: prueba de usabilidad

¿Quiénes participan?

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

Antes de empezar

  • Prototipo.

Ejecución

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

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

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

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

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

Recomendaciones para conducir una prueba de usabilidad

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

Recomendaciones para tomar notas

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

Lean User Research
Lean User Research

Stoppers

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

Values

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

Feedback

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

Recommendations

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

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

Pruebas de usabilidad automatizadas

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

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

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

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

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

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

***

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

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

Lean UX, parte 4

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

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

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

Estudio de Diseño Colaborativo

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

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

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

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

Método: Estudio de diseño

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

¿Quiénes participan?

  • Todo el equipo. Todas las disciplinas involucradas.

Antes de empezar

  • Declaración de supuestos.

Ejecución

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

Plantillas

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

Descripción de pasos

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

Definición del problema y restricciones

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

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

Generación de ideas individuales

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

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

Presentación y críticas

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

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

Iteración y perfeccionamiento

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

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

Todos deben presentar nuevamente sus ideas.

Trabajo en equipo

El tiempo estimado es de 45 minutos.

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

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

Producto Mínimo Viable

Lean UX, Minimum Viable Product.
Minimum Viable Product.

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

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

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

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

Tipos de MVP

Un MVP puede tener dos objetivos:

  • Obtener aprendizaje
  • Generar valor

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

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

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

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

¿A quién va dirigido un MVP?

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

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

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

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

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

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

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

¿Cuánta calidad debe tener un MVP?

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

Keep it simple stupid.
Keep it simple stupid.

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

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

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

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

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

Consideraciones para la creación de un MVP

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

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

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

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

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

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

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

Prototipos

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

De acuerdo a su complejidad, se clasifican en:

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

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

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

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

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

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

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

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

Pretotipos

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

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

Ejemplos de técnicas de pretotipos son:

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

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

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

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

***

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

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

Lean UX, parte 3

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

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

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

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

Supuestos

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

Definir supuestos tiene las siguientes ventajas:

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

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

Declaración de supuestos y priorización

Declaración de supuestos
Declaración de supuestos.

¿Quiénes participan?

Todo el equipo y todas las disciplinas involucradas.

Antes de empezar

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

Ejecución

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

Plantillas

 

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

Declaración de hipótesis

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

¿Quiénes participan?

Todo el equipo y todas las disciplinas involucradas.

Antes de empezar

  • Declarar supuestos.

Ejecución

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

Creemos que [declaración] es cierta.

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

[feedback cualitativo].

[feedback cuantitativo].

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

Resultados

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

Método: brainstorming

¿Quiénes participan?

Todo el equipo y todas las disciplinas involucradas.

Antes de empezar

  • Declarar hipótesis.

Ejecución

Responder las siguientes preguntas:

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

Personas

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

Método: Protopersonas

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

Protopersonas.
Protopersonas.

¿Quiénes participan?

Todo el equipo y todas las disciplinas involucradas.

Antes de empezar

  • Declarar supuestos.

Ejecución

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

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

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

Plantillas

Funciones

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

Método: brainstorming

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

¿Quiénes participan?

Todo el equipo y todas las disciplinas involucradas.

Antes de empezar

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

Ejecución

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

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

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

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

***

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

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

Lean UX, parte 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.

“UX Nights me cambió la vida”

Desde su origen, UX Nights tuvo el objetivo de formar y consolidar una comunidad de profesionales en Experiencia de Usuario. Poco a poco hemos sido testigos de cómo la comunidad ha ido creciendo y madurando, pero en pocas ocasiones llegamos a conocer historias de vida, que son únicas y especiales.

Lizette Pradal UX/UI Designer
Lizette Pradal, UX/UI Designer

Queremos contar la historia de Lizette Pradal, una diseñadora de experiencia de usuario que platicándo con nosotros, nos dijo: “UX Nights me cambió la vida”.

Liz fue una de las veinte valientes que asistieron a UX Nights Vol. I, en septiembre de 2014, en las instalaciones de Archipiélago en la Cd. México. En esa primera edición de UX, pizzas y cervezas, se  escucharon las pláticas de Bibiana Nunes, Vero Traynor y Mauricio Angulo.

Parece que el destino ya estaba trazado desde esa primera noche, Liz asistió al evento junto con Ismael, su compañero de trabajo.

UX Nights Vol. I Desmitificando UX
UX Nights CDMX Vol. I – “Desmitificando UX”

Entusiasmados como muchos otros por la iniciativa, no dudaron en ofrecer las instalaciones de 5M2, la empresa en la que trabajaban, para realizar ahí las futuras ediciones de UX Nights. Mauricio, Bibi y compañía no dudaron en aceptar la oferta.

En esa época, Liz trabajaba diseñando interfaces, prototipos y diferentes herramientas para el equipo de ventas de 5M2 y otros clientes. Tenía un gran interés por conocer más sobre Experiencia de Usuario, así que empezó a asistir a UX Nights sin falta ¡con la facilidad de solo bajar las escaleras para llegar!

UX Nights en las oficinas de 5M2
UX Nights Vol. II en las oficinas de 5M2, con Víctor García, Adrián Kane y Adrián Solca.

En el Vol. V en CDMX sobre Prototipado, no pudo bajar las escaleras para escuchar las plática porque tenía que entregar un prototipo con urgencia. Justo mientras pensaba cómo podría grabar en video la interacción de su prototipo para compartirlo con el cliente, escuchó a lo lejos la plática de Gerardo BlancoLa habilidad de la adaptaciónGerardo contaba su experiencia trabajando con InVision, una herramienta de prototipado.

Gerardo Blanco en el Vol. V Prototipado
Gerardo Blanco en el Vol. V Prototipado

Liz le envió un tweet a Gerardo para pedirle ayuda con el prototipo en el que estaba trabajando. Poco tiempo después, Gerardo la contactó para invitarla a incorporarse a Globant, una de las organizaciones más importantes a nivel internacional en servicios de tecnología enfocada en el desarrollo de soluciones de software y donde él trabajaba.

Ella no lo pensó demasiado y decidió a emprender un nuevo reto laboral, sin saber que se encontraría con uno de los retos más grandes de su carrera profesional: al mes de ingresar a Globant la enviaron a trabajar en un proyecto piloto a Santiago de Chile para una aerolínea utilizando metodologías ágiles.

Durante tres meses, Liz estuvo en una capacitación intensiva sobre cómo trabajar de manera ágil, y también pudo poner en práctica todo lo que había visto de manera teórica en los eventos de UX Nights.

Programación en pares, equipo ágil y SCRUM Board

Liz aprendió mucho sobre esta metodología, trabajó en pares todos los días diseñando, planeando, programando servicios, implementando front-end, creando prototipos y aplicando pruebas de usuarios, entre otras tareas.

Descubrió, junto con el resto de sus compañeros, que no hay equipos de desarrollo y equipos de UX y que el trabajo en conjunto es lo más importante para lograr un producto exitoso.

Trabajo remoto desde Globant México
Trabajo remoto desde Globant México

Actualmente ella trabaja de forma remota desde la Cd. de México y viaja constantemente a Santiago. Para ella, cada día ha sido un reto y una oportunidad para crecer profesionalmente.

Liz agradece a todas aquellas personas que de manera desinteresada han compartido su conocimiento y experiencia, mes a mes, en los eventos de UX Nights.

Su futuro es prometedor y quiere seguir aprendiendo, especializarse en la integración de UX en metodologías ágiles, viajar y seguir transformando la empresa en la que trabaja.

Nos reencontramos con ella en el evento Web Analytics Wednesday de la Ciudad de México en febrero de 2016. Su historia es realmente fantástica y refleja la misión de UX Nights.

* * *

No podíamos dejar de pasar la oportunidad de compartir su historia porque como diseñadores de experiencia de usuario, nuestra primera tarea es sentir empatía por nuestros usuarios; y nuestros usuarios, son todos los que forman parte de la comunidad.

Muchas gracias a Liz por permitirnos contar su historia y esperamos que pronto nos comparta sus nuevos logros.

Así como esta historia, no dudamos que haya más; queremos conocerlas y compartirlas con todos. Contáctanos y cuéntanos tu historia.

Somos un grupo de profesionales de UX que trabajamos para fortalecer y profesionalizar a la comunidad de Experiencia de Usuario (User Experience) en español. Hacemos eventos en vivo por la noche para platicar de User Experience.