El rol del Sprintmaster en un Design Sprint

Design Sprint es una metodología de trabajo que utiliza elementos de metodologías ágiles y de design thinking. El responsable de su ejecución es el Sprintmaster.

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 sprintmaster.

El sprintmaster 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 sprintmaster 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.

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 sprintmaster 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

Un buen sprintmaster 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 sprintmaster 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 sprintmaster 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 sprintmaster 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 sprintmaster 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 sprintmaster 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 design 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 sprintmaster 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ño de productos con Design Sprint

Design Sprint es un proceso de cinco días que sirve para resolver los puntos críticos de un producto utilizando diseño, prototipado y validación 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.

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.

Design 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:

  • 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.

Una 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.

El modelo HEART para medición de UX

Hay mucho que se puede medir en medios digitales, pero no todo lo que se mide es útil para UX. El modelo HEART sirve para 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: la satisfacción del usuario o su percepción de usabilidad.
  • 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 exitosas (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

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.

Diseño de métricas de usabilidad

Para medir la usabilidad de un producto, primero es necesario definir las métricas adecuadas y luego utilizar la información que revelan para mejorarla. ¿Cómo se crean las métricas de usabilidad?

La Experiencia de Usuario, o UX como se abrevia comúnmente, se refiere a los todos los aspectos en la relación de una persona con un producto, aplicación o sistema. Muchas personas parecen pensar que la experiencia de usuario es una característica nebulosa que no puede ser medida o cuantificada por su naturaleza cualitativa. ¿Cómo medir objetivamente, por ejemplo, el sentimiento de una persona cuando no puede interpretar un captcha, o cuando logra utilizar una aplicación con éxito sin leer el instructivo antes?

La realidad es que todos los puntos de interacción de un usuario, sus comportamientos y actitudes hacia un sistema pueden ser medidos, aunque es cierto que algunos son más sencillos de medir que otros.

¿Por qué querríamos medir la experiencia de usuario? La respuesta corta es: para que pueda mejorar.

Si en estos días un sitio web, app o producto para consumidor final no se encuentra en un proceso de mejora continua, entonces ya se está quedando rezagado contra su competencia y respecto a sus clientes.

Una métrica es una manera de medir o evaluar un fenómeno o cosa particular de manera cuantitativa. Podemos decir que algo es más alto, largo o rápido porque somos capaces de medir y cuantificar estos atributos para hacer comparaciones en otros escenarios. Para que la métrica sea significativa es necesario que exista un acuerdo sobre cómo medir algo y que exista un método consistente y confiable para realizar mediciones.

Las métricas de usabilidad son una herramienta que nos ayuda a definir dónde se encuentra nuestro producto en relación con su competencia o con las expectativas de sus usuarios y para enfocar nuestros esfuerzos y recursos donde pueden tener mayor impacto para mejorarlo: las áreas en donde los usuarios lo encuentran confuso, ineficiente o frustrante.

La definición de una métrica -de usabilidad o cualquier otra- puede seguir los mismos principios que un Indicador Clave de Desempeño (KPI – Key Performance Indicator), usando el acrónimo SMART, significa que deben ser:

  • ESpecíficos (Specific)
  • Medibles (Measurable)
  • Alcanzables (Achievable)
  • Relevantes (Relevant)
  • Temporales (Timely), en el sentido de que sea posible hacer un seguimiento de su evolución en el tiempo.

Lo que hace diferente a una métrica de usabilidad de cualquier otro tipo de métrica es que la primera revela algo sobre la experiencia personal de la persona que está utilizando la app, el sitio web o el sistema. La métrica de usabilidad revela también sobre la interacción entre la persona y el sistema, como su eficacia (la capacidad de ejecutar una tarea con éxito hasta terminarla), su eficiencia (la cantidad de esfuerzo necesaria para terminar la tarea) o la satisfacción (el grado en el que el usuario se siente contento con él mismo o con la tarea que acaba de realizar).

Usabilidad es el balance entre la eficacia, la eficiencia y la satisfacción que un usuario obtiene al usar un sistema digital.

Algunos ejemplos de métricas de usabilidad son:

  • la tasa de éxito de ejecución de una tarea,
  • el tiempo que toma realizar una tarea,
  • el número de clics, teclazos o taps que realiza el usuario mientras realiza una tarea,
  • las calificaciones de satisfacción o frustración,
  • el sentimiento de los comentarios que comparten los usuarios, o
  • el número de veces que una persona observa de manera fija un hipervínculo en la pantalla.

Otra diferencia entre una métrica de usabilidad y cualquier otra es que éstas miden algo relacionado con las personas, sus comportamientos y actitudes. Debido a que las personas son increíblemente diversas y diferentes entre sí, es común que sea complicado definirlas o intentar estandarizarlas.

Algunas cosas no deberían ser consideradas como métricas de usabilidad, como las preferencias o actitudes de una persona que no estén ligadas a la experiencia de usar un sistema, como podrían ser: la popularidad de una app en su marketplace, el tráfico de un sitio web o la frecuencia de compra de un producto. Aunque todas ellas son cuantificables y pueden reflejar algún tipo de comportamiento de sus usuarios, no están basadas en una interacción vivencial que refleje la variabilidad de la información que entregan.

La finalidad de las métricas de usabilidad siempre debe ser proveer respuestas a las preguntas que son críticas para el equipo que desarrolla tecnología y que no pueden ser resueltas de ninguna otra manera. Preguntas como ¿a los usuarios les gustará la nueva versión del producto? o ¿este producto es más eficiente que el de la competencia? son las que los estudios con personas y interpretación de las métricas de usabilidad pueden resolver, al mismo tiempo que sirven para mejorar el producto desde la perspectiva de quienes lo usarán después.

Las métricas nunca deben de ser un objetivo, sino un medio para obtener insights, es decir, un entendimiento profundo sobre las emociones y sentimientos de una persona mientras usa un producto digital. Con insights y métricas objetivas que los respalden podremos descubrir y crear nuevas maneras de crear experiencias de usuario positivas y sorprendentes.