Archivo del autor: Ricardo Alfaro

Acerca de Ricardo Alfaro

UX Designer

“Hackeando” los Design Sprints para hacer que siempre funcionen

Durante varias semanas estuve pensando cómo escribir y estructurar este artículo, para contar bien mi experiencia de cómo he logrado hacer que los famosos Design Sprints (lo mejor que hay por estos días para diseñar soluciones validadas), realmente funcionen, sobre todo en el escenario más adverso: Las corporaciones. ¡Aquí vamos!

Érase una vez…

Hace un año atrás, decidí comprarme el libro Design Sprint como parte de una investigación que respondía a la inquietud de cómo hacer que el proceso de diseño lograra ser mucho más eficiente y menos costoso aún -de lo que ya era con Lean UX.

Quise entender de primera fuente, que tan interesante era esta “famosa” metodología de la que venía escuchando hace un buen tiempo. Y resultó sorprenderme con creces. Ese grupo de diseñadores cracks de Google Ventures, encabezados por Jake Knapp, habían logrado acortar el proceso de diseño de manera asombrosa, probando con éxito en muchas startups de Sillicon Valley, una metodología que servía para desarrollar o validar ideas de productos y casi cualquier desafío que tuvieran por delante. Todo lo que contaban en el libro me hizo mucho sentido y quedé tan entusiasmado, que quise ponerme a trabajar de ese modo casi inmediatamente.

El espejismo de la utopía

Sin embargo, la primera duda que me surgió (y que de seguro a muchos, de los que aún no han tenido el placer de trabajar de esta manera, también les surge), es que si dado el contexto en que esta metodología se inventó –el de las startups– podría realmente ser aplicada con proyectos de grandes empresas. Un escenario donde la convocatoria de stakeholders, con poder decisión, suele ser difícil. Porque los altos y medianos cargos están siempre con la agenda muy apretada y contar con su participación en largas reuniones seguidas, parece ser –muchas veces– imposible.

Con mayor razón cuando se trata de diseñar. Porque al final se supone que a uno, como consultor externo, lo contratan para dar solución a los problemas casi como un mago, para que cuando el proyecto termine, el cliente levante el dedo para arriba o para abajo, para decirnos si está conforme o no con el resultado. Dependiendo de qué tan convincentes seamos para “venderle” la solución, en la que seguramente, trabajamos solos en nuestro laptop durante varias semanas.

Pero esta metodología al contrario de eso, tiene como requerimiento clave la participación y colaboración directa de nuestro cliente, en su más amplio espectro de personas y cargos. Es absolutamente necesario que en la mesa de trabajo estén presentes todos: jefes de proyecto, desarrolladores, marketing, diseñadores y cualquier persona que trabaje en la empresa, que pueda aportar una visión o perspectiva relacionada con el problema y así transformarse en co-creadores.

Aquí, los escépticos –como yo también lo era– pensarán en que convencer a dichas personas, a que, como dice el libro: liberen sus agendas por una semana completa y se dediquen full time a nuestro proceso, es derechamente una utopía. Por lo tanto, el único término que inevitablemente les rondará en la cabeza es: Imposible. Pero yo he comprobado que no lo es, y eso es lo que principalmente quiero contar.

Manos a la obra

Design Sprint en institución educacional

La primera vez que me lancé a probar Design Sprint, lo hice como un taller. Puse en práctica la metodología, para ayudar a un área de diseño y desarrollo de una importante entidad educacional. Una unidad encargada, por una parte, de desarrollar el software para solucionar diversos problemas administrativos y por otra parte, ser también los proveedores de hardware para todos los departamentos internos de la organización. Un área con desafíos complejos, pero con prácticas un tanto obsoletas, para responder con velocidad a sus requerimientos, donde habitualmente ni siquiera se hacen el tiempo ni saben cómo validar, si las soluciones son realmente efectivas o sirven bien para lo que deben.

Así que armamos equipos de 8 personas, mezclando perfiles bien representativos, como los que anteriormente describí y desarrollamos 2 sprints. Cada uno enfocado en un problema diferente. La idea principal era entregarles una herramienta que les permitiera continuar desarrollando e iterando mejores soluciones para todos los desafíos que venían. Para mejorar sustantivamente sus procesos, con una mirada más innovadora. Y de paso, por mi parte, experimentar y sumergirme de lleno en la práctica de esta metodología, para adaptarla o mejorarla, según el escenario al que me enfrentara más adelante. Y por supuesto alentar, con el ejemplo a mis compañeros del equipo a seguir mis pasos y lanzarse también, sin miedos ni prejuicios.

El resultado fue increíble, los equipos quedaron súper motivados y lograron ver cómo en una semana pudieron modelar una solución y probar con usuarios las hipótesis que levantaron y detectar en muy poco tiempo los errores que debían corregir. Un tremendo aprendizaje para ellos y para mí.

Seguido de eso, aprovechando mi entusiasmo, intenté hacer exactamente lo mismo con un cliente corporativo y no tuve buenos resultados, porque fue imposible conseguir que los stakeholders estuvieran dispuestos a dedicar 4 semanas completas a 4 sprints. El proyecto se llevo a cabo con un intento fallido de la metodología y resultó ser un híbrido muy extraño entre la vieja manera de hacer las cosas y la nueva. La conclusión: era absolutamente necesario adaptarlo.

Adaptación

Luego de las primeras experiencias con Design Sprint, revisé una a una las actividades y los tiempos y logré dar con la manera de poder adaptar el proceso y acortarlo mucho más, sin romper el espíritu ni dañar la integridad de la metodología. Mantener su esencia intacta, pero acomodada a las circunstancias.

Así que facilité un nuevamente Design Sprint, durante los 5 días como dice el libro, pero acorté los tiempos por actividades. Lo que nos permitió hacer todo en jornadas de 3 horas diarias, en vez de 6 como dicta la metodología. Y funcionó perfecto.

En retrospectiva, además de validar que se podía hacer en menos tiempo del propuesto, sin sacrificar ninguna actividad, me di cuenta también que quizás era posible suprimir algunas dinámicas, para darle más espacio y tiempo a otras que resultan ser fundamentales. Ese sería el próximo paso en mi aventura de poner a prueba los límites de la metodología.

Time-Timer

El desafío mayor

Y me tocó nuevamente el turno de enfrentarme al cliente “enterprise”, donde otra vez, tuve la oportunidad de proponer trabajar con Design Sprint. Y es ahí donde surge la problemática que describía al comienzo del artículo y por el cual falló mi primer intento en este contexto. El gran desafío era como convencer al cliente de lo bueno que trabajar así, pero por sobre todo, requerir de su participación y compromiso durante 5 días continuos por varias semanas. Así que pensando en cómo podría hacerlo funcionar, me la jugué por hacer el proceso en los mismos 5 días, pero con la participación del cliente limitada a sólo 3 días. ¿Cómo?

Simplificación

Gracias a la retrospectiva de la experiencia adquirida hasta ahí, concluí que cada día de sprint se sustenta en tareas claves, las cuales son irremplazables y absolutas responsables de que la metodología funcione. Así que la propuesta consistió básicamente en quitarle carga a los stakeholders y hacerlos participar sólo de lo esencial, simplificando el proceso a lo siguiente:

  • Día 1: Hipótesis, objetivos y mapeo de la solución.
  • Día 2: Revisión de referentes y bocetos de la solución.
  • Día 3: Análisis, discusión, votación y convergencia en la solución a prototipar.
  • Día 4: Prototipado de la solución.
  • Día 5: Pruebas con usuarios y conclusiones.

Por lo tanto, la idea era comprometer al cliente corporativo, sólo de lunes a miércoles en reuniones, inicialmente de 3 horas el lunes y martes y de 1,5 horas el miércoles, por cada semana de sprint. Lo importante es mantenerlo siempre conectado con el proceso y siendo siempre un co-creador activo de las soluciones que se vayan probando para cada hipótesis. Lo que permite que no aparezcan sorpresas al final del proyecto. Además con la ventaja de poder obtener resultados semanales concretos y plasmados en un prototipo funcional y navegable.

¿Y qué pasa entonces con el jueves y viernes? Ese es un trabajo que asumo yo. Porque objetivamente, no es necesario forzar al cliente a prototipar, si para eso estamos nosotros los diseñadores. Tenemos los skills suficientes para hacerlo seguramente mejor que ellos. Y lo mismo aplica para el viernes, cuando hay que ejecutar las pruebas. Sin embargo, la invitación a participar como espectadores está permanentemente abierta. Siempre y cuando, estas pruebas se realicen bajo el concepto de “laboratorio de usabilidad”. Porque muchas veces, cuando el target de usuarios es amplio o exploratorio, personalmente prefiero los “test de guerrilla”, dado que los usuarios son mucho más honestos que en un ambiente de laboratorio. Seguramente una discusión que es material para otro artículo o con gusto para compartir un café.

Resultados actuales

Poner en marcha este modelo para hacer Design Sprint ha sido todo un éxito. Al menos así lo hemos sentido y estamos felices con el resultado en el equipo y el cliente también lo ha demostrado. Se nota su entusiasmo desde el primer sprint, porque puede ver lo valioso y pragmático de trabajar así.

Así que hemos empezado a aplicar esta versión “hackeada” en todos los nuevos proyectos con excelentes resultados. Clientes contentos y equipo motivado. Mis compañeros y yo hemos estado trabajando ahora en pequeños ajustes y constante retrospectiva al final de cada proyecto para saber qué nos hizo falta y cuáles resultan ser los aciertos más concretos.

Hemos trabajado en proyectos con grandes y medianas empresas, instituciones públicas y privadas y por estos últimos días estamos probando la metodología en remoto con una startup, aprovechando las herramientas colaborativas para el mapeo o la votación de propuestas para el prototipo. Y creo que tenemos también la mejor impresión. En un próximo artículo prometo contar el detalle de los ajustes y sobre la experiencia a distancia.

Resumen y conclusiones

Dada la positiva impresión que hemos tenido hasta ahora y lo motivante que ha sido liderar proyectos aplicando esta metodología, me gustaría resumir las grandes ventajas que yo le encuentro:

  • El pragmatismo Lean + Agile
    Design Sprint es una maravilla del pragmatismo, que mezcla magistralmente las prácticas ágiles con el espíritu Lean, dejando de lado todo lo que realmente no aporta. Poniendo énfasis en lo que se conecta directamente con la propuesta de valor.
    Al importar el modo de trabajo Agile/Scrum en sprints, empuja la eficiencia y evita la parálisis creativa.
  • Alineación de visiones
    Como todo el equipo (cliente + consultores) son parte activa del proceso todo el tiempo, se toman las decisiones en conjunto y se evitan las sorpresas. El equipo aprende unido y en consenso se alinean en torno al mismo objetivo y propósito. Todos son co-creadores en un entorno de participación y colaboración.
  • Integración con desarrollo ágil
    Dado que esta metodología está inspirada en el desarrollo ágil. Adaptando el proceso de diseño al modo de sprints con entregas semanales, logra conectarse naturalmente con los procesos de desarrollo en entornos ágiles.

    Uno de los proyectos de los que trabajaron compañeros del equipo con Design Sprint, comenzó a ser desarrollado desde el término del primer sprint de diseño, lo que permitió una salida a producción con las primeras historias de usuario que daban vida real al MVP, mientras los demás design sprints estaban en progreso.

    Y otra de los detalles interesantes en esa misma línea, es que al término de cada sprint, el equipo de desarrollo puede empezar a escribir las historias de usuario y detectar los vacíos que puedan haber quedado fuera del prototipo, para que los diseñadores reaccionen en tiempo real y así no afectar el futuro del desarrollo.

  • Flexibilidad y versatilidad
    Estoy absolutamente convencido que es una metodología muy flexible para cambios y adaptaciones en hartos sentidos. Basta con sólo cuidar el core y las actividades clave para que todo ande a la perfección.
  • La perfección no existe (?)
    Es tanta la maravilla que he visto en la práctica de la metodología, que personalmente me ha costado encontrar algún problema de peso. Sin embargo, dudo que Design Sprint sea una metodología perfecta, es como cualquier otra, una guía, no una receta absoluta e inalterable para asegurar el éxito. Siempre es necesario probar diferentes sabores (como en la comida) y encontrar el ajuste preciso, el aliño o toque personal. Aguzar el oído en la tuerca y apretar hasta encontrar la medida justa. Aunque vale agradecer infinitamente a sus creadores por estos regalos y creo que es súper valioso también aportar con la mirada y la experiencia personal de todos nosotros, que siempre le servirán a los demás para ampliar sus perspectivas.

Diseñadores, desarrolladores y a todos los que trabajan en UX, los invito a que lean el libro (si aún no lo han hecho), que experimenten con la metodología y contribuyan al debate, para enriquecer el conocimiento de toda la comunidad.

Y por supuesto que cualquier duda que tengan, siempre feliz y dispuesto a ayudar. O si con su experiencia discrepan conmigo, bienvenidas las críticas también.
😉

Me aburrió Sketch

No pretendo escribir un manifiesto en contra de Sketch, ni de las otras herramientas que hoy encabezan la lista como favoritas entre los diseñadores de interfaces. Sólo quiero plantear mi visión personal acerca del uso innecesario de estas herramientas sobre todo para quienes tenemos experiencia escribiendo HTML/CSS, y optar por ellas a la hora de diseñar nuevas interfaces, y de paso hacer una invitación a perder el miedo.

Soy un diseñador dedicado a la experiencia de usuario hace varios años y desde hace muchos más, he dedicado tiempo a aprender e investigar permanentemente sobre los procesos de diseño y herramientas disponibles que nos ayudan a hacer mejor nuestro trabajo. Entre esas, hay un par que conocí en los últimos años y que he usado bastante, porque me parecen excelentes y porque hacen una dupla genial: Sketch +Invision.

Pero como decía al principio de este post, no lo escribo para hablar mal de estas herramientas, sino que para explicar porqué (enhorabuena, como dicen los españoles) me aburrí de ellas.

La maravilla de Sketch

Primero que todo, me gustaría decir que considero a Sketch una maravilla. Aunque lamentablemente sea sólo para usuarios de Mac. Sé que muchos consideran caros los Mac (con mucha razón) y otros tantos los detestan, así que mucha pena por los Windows/Linux users, que se la pierden.

En su última versión desarrollaron interesantes mejoras y complementos dentro del software para manejar mejor los objetos y hacerlos más inteligentes a la hora de repetirlos (los overrides) y un sin fin de otras cosas muy geniales. Además de tener una interfaz simple y amigable, ideal para diseñadores que se formaron usando Illustrator de Adobe (o el prehistórico Freehand) e incluso los que se aventuraron con Phostoshop para hacer interfaces en el pasado y sobre todo para los viudos del difunto Fireworks. Y que además de todo eso, tiene full integración con Invision, una plataforma web para crear prototipos, igualmente genial. Pero que sin embargo insisto, me aburrí de usarlas.

¿Por qué me aburrí?

Todos sabemos o creemos que escribir código supone una dificultad extra que puede verse reflejada en el tiempo. No obstante es un pro excepcional para el proceso de la implemementación en desarrollo. Y ahí hay un punto insuperable.

Por lo tanto, si yo sé HTML, ¿para qué gastar el doble de tiempo dibujando interfaces en Sketch (o el software que sea) y luego armando un prototipo en Invision (o el software que sea), si lo puedo hacer directamente en código?

Algunos podrán alegarme que HTML no es muy flexible o mejor dicho, tan rápido de manejar a la hora de probar si esto queda mejor de una manera u otra, que es lo que hacemos todos los diseñadores cuando estamos “creando”. Sin embargo, si estamos en un proceso de diseño de experiencia de usuario, habremos pasado por fases previas donde las interfaces estarán precedidas por wireframes que al menos fueron “microvalidados”. Entonces al momento de ponernos a trabajar en un prototipo, generalmente ya tenemos una base y un layout predefinido.

Así que, meterse directo al código es algo bastante lógico. Y para lo único que se justificaría gastarse un poco de tiempo usando Sketch, sería para trabajar un look and feel más prolijo. Para decidir cuál será el estilo visual que tendrán las interfaces de lo que estamos diseñando. Basta con probar algunos botones, algunos campos de formulario, y uno que otro detalle más y ya. Sólo bastará con diseñar una pantalla y tenedremos todo lo que necesitamos. No es necesario seguir gastando tiempo ahí, diseñando cada una de las interfaces porque será tiempo perdido. Y si a eso le sumas que las interfaces tienen que ser responsive, más tiempo perdido.

Hoy día, en web existe una amplia variedad de frameworks que nos facilitan la vida al hacer código, incluyendo sus microinteracciones, y lo mejor de todo, es que tienen abordado el responsive web design. Bootstrap, es el mejor ejemplo.

Perder el miedo a cerrar Sketch y abrir Sublime

Algunos también podrán insistir aquí que escribir código es mucho más lento. Pero creo que eso es una aseveración planteada desde el miedo. Un miedo que también tuve por mucho tiempo, debo reconocerlo. Pero ya por fin, es parte del pasado.

Así que, me decidí a cerrar Sketch definitivamente y lanzarme a prototipar directamente sobre HTML/CSS, lo que me ha dado muy buenos resultados, incluso en rápidos sprints, donde sólo hay un día para hacerlo.

Contaba con una ventaja que no estaba aprovechando sólo por miedo. O me había encantado tanto usar Sketch que me estaba olvidando lo genial que es mirar tu prototipo funcionando casi de verdad, adaptado en diferentes dispositivos y que cambiando un par de líneas de código o reglas de CSS podía hacer mucho más (y mucho más rápido) que duplicando artboards en Sketch o peor aún, simulando las interacciones después en Invision.

Lo mejor de todo esto, es que un prototipo HTML, es algo que agradecerán mucho los desarrolladores, que no necesitaran tener que tomar el Invision, y mirarlo para tratar de replicar las interacciones o mirar las interfaces del manual de diseño que tuviste que hacer en Zeplin o en PDF, para imitar las interfaces, con todos sus detalles. Así entonces, cuando el software esté terminado, no existirá ese maldito GAP entre lo que diseñaste en Sketch y lo que terminó resultando. Incluso harás un diseño responsable, probado de que lo que propones efectivamente se puede hacer.

¿Entonces estoy sugiriendo no usar más Sketch?

No, en absoluto. Pienso que Sketch es genial para modelar, para el momento de la “creación” y perfeccionamiento del look and feel. Es mucho más amigable que HTML para ello, porque nos permite con soltura, probar, mover, cortar, pegar, repetir, duplicar, achicar y agrandar rápidamente. Pero en la mayoría de los casos, basta con hacerlo para una sola pantalla, y de ella obtener las medidas y posición del layout o el estilo visual de los elementos de interfaz. Los colores, sombras, bordes, tamaño de la tipografía, etc. Es lo mejor que existe para manejar y exportar assets, tipo SVG.

¿Y qué pasa con el diseño mobile?

Por supuesto que no podemos ignorar que Sketch es insuperable cuando hablamos de diseño de aplicaciones móviles. Porque aún no hay nada tan simple para nosotros, los diseñadores, con respecto a meternos en el código de apps nativas, como si lo es en web.

Sin embargo la gran nueva de era de Javascript mueve la aguja de vuelta hacia la web. Hoy por hoy, las aplicaciones híbridas, están tomando fuerza por sobre las nativas, sobre todo por lo práctico y económico que es desarrollar un sólo código. Otra razón para acercarse a HTML.

Mi consejo

Si eres un diseñador con experiencia en HTML, te sugiero que hagas como yo y cierres el Sketch, abras sublime (o el editor que prefieras) y te sumerjas en el código. O si quieres puedes compartir tu desacuerdo en los comentarios, con los fundamentos que quizás me hagan entender lo equivocado que estoy.

Si eres uno de los que no sabe mucho de HTML/CSS, y por eso no te atreves a aventurarte, te recomiendo retomar el aprendizaje y mejorar, para hacer un trabajo mucho más eficiente. Recuerda que la práctica hace al maestro.

Y si eres de los diseñadores que no se manejan nada con el código, te invito a que aprendas ya. A la larga te darás cuenta lo bueno que es trabajar de este modo.

El valor de los usuarios

Cuando empecé profesionalmente esta carrera, hace más de 10 años, pocas veces escuché la palabra usuario con la misma fuerza que hoy se escucha. Corrían otros tiempos, cuando internet recién cumplía un poco más de una década en la vida de las personas y empezaban a aparecer las primeras “redes sociales”. Se hablaba bastante de la web 2.0 aún con tono futurista, cuando en realidad estábamos ad portas del lanzamiento del primer iPhone que abriría el paso definitivo a todo lo que hoy nos parece tan cotidiano y natural.

Pareciera ser entonces que en ese tiempo, los diseñadores que nos habíamos metido a este atractivo mundo digital, era sólo para hacer más bonitas las cosas y aportar con nuestro “buen gusto”. Porque haciendo un poco de memoria, los diseñadores parecíamos estar enfrascados en una competencia sin sentido entre quién hacía el botón más brillante y realista o quién hacía la mejor sombra, y otros tantos desafíos estéticos inútiles. También porque tanto los líderes de proyecto, como los mismos clientes estaban convencidos de que el éxito de su portal o sitio web dependía en gran parte de eso. Quizás no estaban tan equivocados (lo “bonito” algo ayuda), pero en gran parte sí lo estaban, porque la estética no es más que un atributo de lo que hoy entendemos como engagement, pero vacío. Y precisamente no es ese el aspecto que más importa, sino que muchos otros.

Luego empezamos a escuchar de usabilidad, navegabilidad, accesibilidad, funcionalidad y un largo etcétera. Nielsen y Norman fueron los pioneros, pues llevaban un buen tiempo estudiando sobre esto para sentar las bases sobre todos estos temas. Aspectos y atributos fundamentales que hoy son claves para lograr una buena experiencia de usuario.

¿Pero para quién hacíamos y hacemos esto? Para las personas, es decir para los usuarios. ¿Y conocíamos realmente a los usuarios, nos preocupábamos verdaderamente de ellos?

Hoy, cuando las posibilidades de interacción humano-máquina se han ampliado notablemente (las que antes dependían casi sólo de un computador), hemos potenciado nuestra creatividad y conocimiento. En estos tiempos en que contamos con múltiples dispositivos para interactuar y consumir información, por fin estamos logrando ver que allá al final, en el resultado de lo que hacemos, hay una persona esperando por una ayuda o solución para su problema, una persona igual que nosotros, que tiene una vida, una familia, amigos, una rutina y una ocupación, que tiene limitaciones, frustraciones y preocupaciones como también sueños y esperanzas. Hoy por fin, nos estamos preocupando por todos los aspectos que influyen en la experiencia que esa persona tiene con respecto a un producto digital (de hecho, así lo llamamos hoy porque ya no es sólo un sitio web, ahora es un producto que tiene un fin mucho más preciso). Nos enfocamos en diseñar y poner nuestro talento en cosas que sirven, cosas que entretienen, cosas que cambian la vida de las personas o buscan hacerlas mejores, porque están hechas y pensadas para las personas, en esas personas que los diseñadores tenemos la misión de entender y conocer bien.

Por otra parte en un ámbito comercial, el mercado ya había empezado a darse cuenta desde mucho antes, de la importancia que tiene la satisfacción del consumidor. En la venta de productos y sobre todo de servicios han resaltado los negocios y marcas exitosas a nivel mundial, por el esfuerzo que han puesto constantemente en la felicidad de sus clientes, optimizando el tiempo, mejorando el trato cordial y cercano, la dedicación especial, la transparencia, es decir la preocupación absoluta en ellos. Porque al final, todo lo que invierten y se preocupan, por consecuencia forma fuertes lazos de fidelidad y preferencia, sobre todo porque más allá del éxito económico –lógico– como retorno a la inversión, el enfoque en las personas se nota y sólo puede traducirse en éxito.

De eso mismo entonces nos preocupamos cuando hacemos diseño centrado en el usuario. Apuntamos a maximizar sus experiencias positivas y recoger lo negativo para mejorarlo constantemente.

Por lo tanto sugiero que antes de tomar un lápiz y tirar una línea sobre un papel, identifiquemos y conozcamos a los usuarios para quien vamos a diseñar. Y eso lo podemos hacer a través de las diversas técnicas de user research que existen en UX como los mapas de empatía, la construcción de user personas, las entrevistas etnográficas o los focus groups, que nos sirven para determinar sus necesidades y técnicas como las encuestas de satisfacción, las evaluaciones heurísticas, las pruebas de usabilidad, los tests de guerrilla o los a/b testings para medir la experiencia.

Sin embargo, más allá de las técnicas que utilicemos, lo importante es: salir a la calle, acercarse a los usuarios, escucharlos, estudiarlos, comprenderlos, conocer que los motiva y entender como se comportan, porque diseñar sin conocer bien para quién lo hacemos no tiene sentido.