Una breve introducción a Agile, parte 1

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

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

Contexto histórico sobre Agile

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

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

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

El Modelo en Cascada y los antecedentes de Agile

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

La caja de Pandora fue abierta.

Los orígenes de Agile

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

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

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

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

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

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

El Manifiesto Ágil

Estamos descubriendo mejores formas de desarrollar software…

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

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

Valores:

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

Principios:

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

Waterfall vs. Agile

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

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

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

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

Ser Agile vs Hacer Agile

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

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

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

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

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

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

La verdadera promesa de Agile

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

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

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

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

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

Diseñ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.

Diseñando la web física

La Internet de las Cosas –Internet of Things, o IoT– es la promesa de que en algún momento los objetos cotidianos que nos rodean estarán conectados a la red mundial de datos. Aunque esta visión aún no llega por completo, la Web Física –Physical Web– es un paso importante para volverla tangible.

La Web Física (Physical Web)  podría sonar como un intento de darle un nombre distinto al Internet de las Cosas, aunque es realidad es una parte de ésta. Internet y la Web no son lo mismo, son diferentes entidades donde la primera se refiere a la tecnología e infraestructura que hace posible la red mundial de comunicación; la segunda se refiere a un servicio de transmisión de datos con la que se puede interactuar a través de un navegador web, o browser.

De  manera análoga, Internet de las Cosas es una colección de objetos inteligentes que se están conectando rapidamente a Internet, y la Web Física nos permite tener acceso e interactuar con esos objetos a través de un navegador web de una manera simple e intuitiva.

Web física en un iPhone  Web física en Android

Una solución de Web Física se basa en tres componentes:

1. Objetos inteligentes

El primer componente de la Web Física son esos objetos inteligentes que mencioné antes, que son pequeños dispositivos capaces de emitir una señal de corto alcance usando Bluetooth a otros dispositivos que se encuentren cerca, como smarthphones, para interactuar con ellos con información que obtienen de Internet.

Beacon comunicándose con una app
Un beacon comunicándose con una app

Los beacons son un buen ejemplo de estos objetos, además de que son baratos y sencillos de instalar. Algunos beacons tienen sensores que les permiten detectar su ubicación geográfica, medir la temperatura ambiente donde están instalados o detectar si otros dispositivos alrededor suyo se están acercando o alejando de ellos.

Tal vez el principal problema de los beacons es que para proveer una experiencia de usuario enriquecida dependen de que los usuarios tengan instalada un app en su móvil con capacidades para reconocerlos y comunicarse con ellos. Si el usuario no tiene la app o no puede instalarla, el beacon es invisible para él.

2. Direcciones web

URLPara resolver este problema, la Web Física utiliza como segundo componente una dirección web o URL. Los objetos inteligentes en la Web Física envían constantemente una dirección web que cualquier dispositivo cercano al objeto puede recibir; la idea es replantear los sitios web móviles para que muestren información relevante a un usuario en una ubicación física, por ejemplo: junto a una máquina expendedora, un poster, una parada de autobús o una cafetería, sin necesidad de que los usuarios descarguen una app primero sino que utilicen una app que ya está en su dispositivo: su browser.

3. El navegador web

Navegadores web para móvilEl tercer elemento de la Web Física es el navegador web del smartphone, que toma el lugar de la app en esa conexión con un beacon e interpreta la dirección que se le envía para abrir una página móvil específica para el contexto del usuario.

El navegador es capaz de detectar los beacons de Web Física alrededor suyo y mostrar su información ordenada por una combinación de factores como proximidad, intensidad de su señal, las preferencias del usuario, su historial de búsqueda y de navegación.

Al seleccionar un enlace de Web Física en una parada de autobús podría mostrar los horarios de los autobuses y un mapa con sus rutas. Una máquina expendedora podría ofrecer una página web para seleccionar y comprar un producto, o un parquímetro puede dirigir a su usuario a una página para pagar por tiempo de estacionamiento:

A donde sea que cada dirección web dirija, toda la interacción ocurrirá dentro del navegador web sin necesidad de que el usuario descargue una app especial para cada experiencia.

* * *

Comenzar a experimentar con la Web Física es muy sencillo: toda la información técnica está disponible en GitHub y hay una guía para comenzar desde cero en ese mismo sitio. Muchos beacons comerciales como BKON, Estimote y GemTot ya son compatibles con sus protocolos.

Aunque el planteamiento de la Web Física suena simple, aún se tienen que resolver los problemas que ya existen con la web móvil como privacidad, SPAM, problemas de usabilidad y de conectividad antes de que el concepto despegue del todo.

La idea de la Web Física es crear un estándar abierto que eventualmente pueda integrarse en cada dispositivo y navegador, y así comenzar a conectar la web con el mundo allá afuera.

 

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.

El modelo HEART para medición de UX

Hay muchas cosas que se pueden medir en medios digitales, pero no todo lo que se mide es útil para UX. El modelo HEART nos ayuda a obtener información valiosa sobre la experiencia de los usuarios reutilizando métricas simples.

Al realizar pruebas A/B o en la medición de día a día de un producto digital se pueden obtener muchas métricas que no son útiles en el diseño de experiencia de usuario. Estas métricas pueden describir el comportamiento de los usuarios al interactuar con nuestros productos, pero que no están ligadas a la experiencia de usar un sistema, como el número de visitas a un sitio web, el número de visitantes únicos, la popularidad de una app en su marketplace o la frecuencia de compra de un producto.

Estas métricas, también llamadas “métricas de vanidad“, pueden ser útiles en otros contextos pero no son buenas métricas de usabilidad ni son útiles para tomar decisiones de diseño por si solas ya que no se relacionan ni con la calidad del producto ni con los objetivos del proyecto. Para que sean útiles desde la perspectiva de UX es necesario interpretarlas primero.

El espejismo de las métricas de vanidad

El modelo HEART es una técnica que se puede aplicar para reutilizar las métricas simples en insights cuantitativos y medibles que son útiles para la mejora de la experiencia de usuario de un producto completo o solo de una característica específica. En este modelo, se crean cinco categorías de métricas:

  • Felicidad (Happiness): mide las actitudes de los usuarios hacia el sistema, normalmente obtenidas por medio de encuestas. Por ejemplo: satisfacción, facilidad percibida de uso o su net-promoter score.
  • Engagement: el nivel de involucramiento del usuario con el producto, medido normalmente usando métricas de de comportamiento asociadas al concepto como frecuencia, intensidad o profundidad de la interacción sobre un periodo de tiempo. Algunos ejemplos son el número de visitas por usuario por semana, o el número de fotografías que publica un usuario al día.
  • Adopción (Adoption): es el número de nuevos usuarios de un producto o de una característica de un producto. Por ejemplo: el número de cuentas creadas en los últimos siete días o el porcentaje de usuarios de GMail que utilizan etiquetas en sus correos.
  • Retención (Retention): es la tasa con la que los usuarios regresan a utilizar un producto. Por ejemplo: el número de usuarios activos en un periodo de tiempo que siguen utilizando el producto en un periodo de tiempo posterior. Una métrica interesante es la tasa del fracaso en la retención, comúnmente conocida como “churn”.
  • Tareas (Task success): incluye métricas tradicionales de comportamiento en experiencia de usuario, como eficiencia (el tiempo que toma terminar una tarea), efectividad (el porcentaje de tareas completadas) y la tasa de errores. Esta categoría puede aplicar en las áreas de un producto que están enfocadas a tareas para el usuario, como un buscador, un formulario o la creación de un perfil en el sistema.

En la práctica no es necesario crear métricas para todas las categorías de HEART, sino que se pueden elegir una o dos que sean importantes para el proyecto que se está analizando. El modelo HEART puede ayudar a decidir si vale la pena agregar o no una categoría en particular. Por ejemplo, la categoría de engagement puede que no sea relevante en un contexto corporativo donde se espera que los usuarios utilicen un producto como parte de su trabajo diario.

En este caso, el diseñador de UX puede elegir enfocarse en la categoría de felicidad o la de tareas, aunque aún podría considerarse útil la categoría de engagement para características específicas del producto como un indicador de su utilidad.

El proceso de Objetivos-Señales-Métricas

La definición de las métricas para HEART no es directa, ya que es específica para cada proyecto dependiendo de sus características, objetivos y de la información que esté disponible. Para decidir con mayor facilidad cuáles métricas definir y rastrear se utiliza el proceso Objetivos-Señales-Métricas (Goals-Signals-Metrics).

  • Los objetivos (goals) deben ser claros y estar alineados, ya que diferentes personas en el proyecto pueden tener objetivos diferentes. Este proceso es una oportunidad para alinearlos y definir de manera conjunta hacia dónde se quiere llevar el producto. Un error común es definir los objetivos de un proyecto usando las métricas que ya existen, por ejemplo: “nuestro objetivo es aumentar el tráfico del sitio web“.
    Es obvio que todo el equipo quiere eso, pero ¿cómo es que el diseño de experiencia de usuario puede ayudar a mejorar esta métrica? El objetivo de UX podría ser “atraer nuevos usuarios” o “aumentar el engagement de usuarios existentes“.
  • Las señales (signals) son indicadores que reflejan las actitudes o sentimientos de los usuarios hacia un sistema por medio de acciones, y que son sensibles a los cambios en el  diseño, por ejemplo, una señal de engagement puede ser el número de usuarios que no terminan de ver un video, o el tiempo de permanencia en una página con una densidad de información alta. Un objetivo puede tener una o varias señales asociadas.
  • Las métricas (metrics) nos dan al final información valiosa en la interacción entre los usuarios y nuestro producto. Es importante utilizar el criterio SMART en la creación de estas métricas y evitar incluir información solo “porque es interesante” y en su lugar alinearlas con las métricas de usabilidad generales del proyecto.

El modelo HEART junto con el proceso de objetivos-señales-métricas pueden ayudarnos a definir y priorizar de manera natural las métricas para obtener información que se pueda utilizar en el diseño centrado en el usuario. Al final, se puede utilizar como una tabla para hacer el mapa de análisis:

Ejemplo de una tabla HEART
Ejemplo de una tabla HEART

Este modelo se puede implementar de manera muy sencilla y ayuda a enfocar las métricas de otras áreas en un proceso de mejora de diseño, al tiempo que ayuda a tener información que refleje la calidad de la experiencia de los usuarios junto a los objetivos de negocio.

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.

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.

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.

Aplicaciones web progresivas, el retorno de la web al móvil

Durante años los sitios web ha sido relegados en los dispositivos móviles sobre las apps nativas debido a problemas de rendimiento, compatibilidad y, sobre todo, de conectividad. Las aplicaciones web progresivas (progressive web apps) prometen resolver estos problemas.

Las aplicaciones web progresivas (progressive web apps) son un acercamiento al desarrollo de apps para móviles que combinan lo mejor de la web y lo mejor de las apps nativas. Estas nuevas web apps son útiles para sus usuarios desde la primera visita en un navegador web, sin necesidad de instalar nada más.

A medida que el usuario crea una relación con la app de manera progresiva, ésta se vuelve más poderosa y útil: carga rápidamente, incluso en redes lentas o cuando el dispositivo está desconectado, puede enviar notificaciones, tiene un icono en la pantalla del móvil y funciona a pantalla completa.

Funcionamiento de una app web progresiva

Una aplicación web progresiva es:

  • Estándar – utiliza la misma plataforma y tecnología que se utiliza para crear páginas web: HTML, CSS y Javascript.
  • Progresiva (¡obvio!) – funciona para todos los usuarios, independientemente de cuál navegador web o sistema operativo utilice, porque está construída para mejorar progresivamente desde el principio.
  • Responsiva – se ajusta a cualquier resolución y formato de pantalla: escritorio, móviles, tabletas, televisiones o lo que sea.
  • Independiente de la conexión – está mejorada con service workers para funcionar sin conexión o en redes lentas con conexiones intermitentes.
  • Como una app nativa – el usuario la usará como una app, con soporte para navegación e interacción con gestos.
  • Fresca – siempre estará actualizada gracias al proceso automático de actualización del service worker.
  • Segura – trabaja sobre HTTPS para prevenir que alguien intercepte datos y para asegurarse de que el contenido no ha sido manipulado por otros.
  • Descubrible – es identificable como una “aplicación” gracias al manifiesto de la W3C y al registro de funciones del service worker, permitiendo a los buscadores web encontrarlas.
  • Interactiva – hace fácil interactuar con ella incluso cuando está cerrada con características como notificaciones tipo push.
  • Instalable – le permite a sus usuarios crear accesos directos en la pantalla de su teléfono sin necesidad de una tienda de apps.
  • Enlazable – se pueden compartir fácilmente usando su dirección en la web (URL) y no requiere procesos de instalación complejos.

Ya existen casos de empresas que han comenzado a implementar apps web progresivas, como AirBerlin o Flipkart con resultados bien documentados en mejoras de experiencia de usuario, retención y conversión.

Apps web progresivas

Google creó un taller para aprender a crear aplicaciones web progresivas desde cero, incluyendo consideraciones de diseño y detalles de implementación para asegurar que tus web apps cumplan todos los principios que mencioné arriba.

Las aplicaciones web progresivas son una oportunidad para regresar a la web su importancia dentro de dispositivos móviles -o en cualquier otro dispositivo-, y de romper los problemas y  dependencias de compatibilidad que tienen las apps nativas.

La flojera es adaptativa

Un principio básico que he aprendido al practicar diseño de experiencia de usuario es comprender que los humanos, por lo general, escogeremos lo que sentimos como el camino de menor resistencia.

Este simple hecho es responsable de varias de las fallas más frustrantes en nuestros diseños: usuarios que no leen las instrucciones, que no completan los tutoriales, que no llenan formas correctamente hasta casos más complejos en los que los usuarios pasan por alto alguna funcionalidad clave o no utilizan todas las herramientas a su disposición.

El camino de menor resistencia”, no tiene una definición absoluta porque depende del contexto. No todos los usuarios o casos de uso se benefician de una simpleza absoluta. El camino de menor resistencia, o en otras palabras, nuestro nivel de pereza, depende de la tarea que estemos buscando lograr, nuestras expectativas de cuánto esfuerzo estamos dispuestos a aplicar en lograrla y las opciones que tenemos disponibles para hacerlo.

Photoshop es un buen ejemplo. Adobe, la empresa que desarrolló el programa, podría determinar sin problema alguno las 50 o 100 acciones más comunes y simplificarlas, pero en este caso los usuarios que dependen de la flexibilidad y complejidad de la misma herramienta, creo yo que no se beneficiarían de una reducción en las herramientas disponibles ya que cada herramienta tiene un uso para alguna tarea específica y aún cuando no usen todas todo el tiempo, su popularidad y liderazgo como software de diseño gráfico ha definido sus funcionalidades como el estándar a seguir.

Herramientas disponibles en Photoshop
Herramientas disponibles en Photoshop

En el otro extremo tenemos Instagram, cuyo éxito y rápida adopción se debe, entre otros factores, a su simpleza de uso y que hace sentir hasta al usuario más novato como un fotógrafo profesional. Teru Kuwayama, fotógrafo profesional dijo para The Telegraph : “Obviamente es horrible ser un fotógrafo profesional y enfrentar la inconveniencia de perder tu pedestal y tu modo de vida ante una aplicación de $2, pero eso no significa que sea malo para la fotografía en general.”

El  selector de filtros de Instagram permite editar fotos con un tap.
El selector de filtros de Instagram permite editar fotos con un tap.

Pensando en otro ejemplo (tomado de un artículo de Paul Boag), últimamente muchos vehículos, como los de BMW, cuentan con una aplicación con la que pueden encender el auto. El proceso para hacerlo, usando la aplicación es:

  1. Sacar el teléfono del bolsillo.
  2. Encender la pantalla.
  3. Desbloquear el teléfono.
  4. Encontrar la aplicación del auto.
  5. Iniciar la aplicación del auto.
  6. Buscar la función de abrir el auto.
  7. Seleccionar la opción.

La alternativa es:

  1. Sacar la llave de mi bolsillo.
  2. Presionar el botón de “abrir”.

O aún mejor:

  1. Si el vehículo tiene apertura por proximidad, el usuario sólo necesita acercarse al auto con la llave en la bolsa para desbloquearlo.
Aplicación de BMW ConnectedDrive
Aplicación de BMW ConnectedDrive

La primera opción es mucho más compleja que la segunda, lo que puede afectar el volumen de usuarios que la consideran conveniente. Y los usuarios que sí la utilizan puede que olviden la novedad al poco tiempo y eventualmente optar por la solución más simple. Y es que eso es exactamente el punto: en mi ejemplo de Photoshop vs Instagram la tarea es aparentemente la misma: obtener una imagen, pero también afectan los otros factores que mencioné: cuánto esfuerzo estamos dispuestos a invertir en lograr nuestro objetivo y las opciones que tenemos disponibles para lograrlo.

Un diseñador profesional que utiliza Photoshop como herramienta de trabajo está mucho más dispuesto a invertir tiempo, esfuerzo y hasta dinero con tal de tener una imagen de mayor calidad que un usuario en Instagram, el conflicto viene cuando le damos un nivel de complejidad nivel Instagram a un usuario que en realidad está buscando en Photoshop.

En UX, a veces se menciona que “menos es más”. Para mi, el minimalismo en las interfaces y experiencias que desarrollo es una cualidad fundamental, pero también es importante recordar que menos, en algunas situaciones puede simplemente ser menos. No todas las interfaces son iguales para todos los usuarios.

Otro ejemplo me viene a la mente: Snapchat. Uno de los elementos que más me gusta de esta aplicación es cómo han logrado un filtro “natural” para solo ser usable por usuarios que entienden de qué va, generalmente usuarios jóvenes. El UX de Snapchat es muy sencillo, hay una pantalla de Snap y una pantalla de Chat, la principal barrera de uso no es su interfaz, sino el hecho de que si los usuarios no piensan “en hablar con imágenes” simplemente no le encuentran propósito ni valor.

Los creadores de Snapchat entienden que, para usuarios de cierta edad, las imágenes existen para “conservar” un momento o “recordarlo”, porque ese fue el uso que aprendieron en un mundo en que las cámaras tenían una cantidad limitada de exposiciones o que hacían complejo el proceso de capturar una imagen. Estos usuarios de hecho esperan un mayor nivel de complejidad en Snapchat, esperan que el proceso de capturar una imagen sea más especial, más memorable y que haya alguna manera de conservarlas (aunque nunca las vuelvan a ver) y por lo tanto “no le agarran la onda” y no utilizan la aplicación.

La base de usuarios real de Snapchat son usuarios que aprendieron que tienen un acceso tan fácil y cercano a tomar fotos que las pueden usar para tareas tan burdas como simple comunicación cotidiana. A ellos no les importa conservar cada imagen y cada momento porque es el equivalente a querer conservar cada conversación por más irrelevante que sea. Para estos usuarios Snapchat es el camino de menor resistencia para comunicarse, no tienen que escribir, solo deben tomar una foto y listo.

Estos son algunos ejemplos sencillos, pero la lección es vital para entender de fondo lo que significa hacer diseño de UX: tenemos que trascender los mantras de “menos es más” y “simplifica” para revelar el verdadero foco de lo que hacemos, que es entender exactamente qué tanto “menos” o qué tan “simples” desarrollar las experiencias, ya que ésta es información que solo nuestros usuarios y la investigación que hagamos de sus necesidades nos pueden enseñar. Nunca subestimemos la pereza de nuestros usuarios pero tampoco sobre-estimemos el camino de menor resistencia, porque los caminos no son iguales para todos.