Transformación Digital: no basta con buenas intenciones

Hoy que la Transformación Digital está en boca de todos, veo cada cierto tiempo aparecer artículos muy populares, como éste o éste, con ideas del estilo: Digital es una cuestión de actitud — ¡empodérate!, o Para transformarte digitalmente necesitas aprendizaje continuo, colaboración y respeto, o la más perniciosa de todas: Basta con estar abiertos a la disrupción.

El problema es que estos bien intencionados consejos vienen de personas que no necesariamente tienen un ADN tecnológico, y que por ende tienen la tendencia a confundir la transformación Digital con una transformación organizacional típica o, peor aún, con un proceso de crecimiento y superación personal. Diseccionando estos argumentos tal vez podamos entender por qué tantas empresas aún dan palos de ciego en sus intentos por digitalizarse.

En primer lugar, ¿qué diablos es disrupción?

Disrupción es la palabra favorita del management por estos días: Amazon hizo disrupción en la industria del retail; Netflix en la industria del entretenimiento; Uber en la industria del transporte, etc. Todos quieren, por supuesto, ser los siguientes Amazon, Netflix y Uber de sus respectivas industrias.

El problema es que la disrupción es un juicio a posteriori; sólo sabes que algo es disruptivo una vez que ya causó su impacto. Cuando estos proyectos empezaron, no eran más que ideas locas, o en el mejor de los casos, experimentos prometedores pero sumamente inciertos. Al igual que “innovación”, como premisa para ponerte manos a la obra la idea de disrupción no te sirve absolutamente de nada, porque nunca vas a tener algo en tus manos que tengas la certeza de que será disruptivo hasta que vayas y lo pongas a prueba.

Una buena cultura de trabajo no te garantiza Transformación Digital

Colaboración, aprendizaje permanente, agilidad, transparencia, empoderamiento, adaptabilidad… ¿qué empresa no quiere eso? Son cambios organizacionales que toda empresa — busque o no la Transformación Digital —  debería acometer, por motivos tan sencillos como evitar que tu talento se vaya a otra parte.

Y sin embargo, parecerte a una startup no te convierte en una. Ser ágil sin tener un propósito claro simplemente te hará correr más rápido a ninguna parte. Una cultura más abierta, colaborativa y flexible va a traerte muchas cosas, pero no va a ocasionar automáticamente ningún cambio hacia lo digital. ¿Vas a lograr un mejor lugar de trabajo? Sin duda. ¿Vas a reducir la rotación laboral? Por supuesto. ¿Va a traerte eso la visión y las decisiones estratégicas, muchas veces dolorosas, que implican transformarse digitalmente? No necesariamente.

Si te quedan dudas, piensa que compañías como Kodak o Blockbuster en sus tiempos de gloria eran lugares bastante decentes para trabajar, y aún así, nunca vieron venir el batatazo que los sacaría por completo del mercado. Y por el contrario, lugares como Apple o Amazon en sus años iniciales han sido descritos por muchos de sus primeros empleados como “brutales” o “infernales”.

Lo que sí se necesita para la Transformación Digital

En mi opinión son dos grandes cosas:

1. Estrategia

Aquí “estrategia” significa tener un norte claro en los esfuerzos de transformación. A estas alturas, digitalizar tus formularios en papel o centralizar tu información de clientes en un CRM no cuenta como Transformación Digital; con suerte, es ponerse al día. Lo mismo con mejorar tu cultura de trabajo y acelerar el flujo de ideas y la colaboración, como ya se ha dicho.

Tener una estrategia de Transformación Digital implica tomar una posición clara, definida y sustentada dentro de un ecosistema digital:

Para entender cómo te posicionas como organización en este ecosistema, primero necesitas comprenderlo profundamente; de lo contrario, serás como el invitado que llega sin disfraz a la fiesta de Halloween. Éste es el problema de muchas empresas, que emprenden esfuerzos de transformación digital “mirando para el lado”, más pendientes de su competencia directa que de esos otros actores (¡de distintas industrias!) con los que tendrán que colaborar.

El caso de Microsoft bajo Satya Nadella es muy ilustrativo: Nadella decidió transformar a Microsoft de una empresa de software a una empresa de plataformas e infraestructuras (principalmente servicios cloud e Inteligencia Artificial). También decidió cambiar la forma en la que MS se relacionaba con este ecosistema; y eso explica decisiones atrevidas como abrirse a colaborar con Linux y el software open source, que hace 5 años atrás eran totalmente impensadas.

La estrategia necesariamente involucra compromiso completo de quienes dirigen la compañía; no sirve de nada si se queda olvidada en un post-it en una sesión de ideación.

2. ADN tecnológico en el liderazgo

Para comprender este ecosistema y cómo tu organización encaja en él (y si es que encaja), necesitas un liderazgo que se mueva como pez en el agua con la tecnología. Cuando el liderazgo es ajeno a lo tecnológico, hay un montón de decisiones y apuestas que no se sustentan, porque no entregan retornos de corto plazo, o porque son demasiado riesgosas.

Muchas decisiones estratégicas de Transformación Digital son elecciones tecnológicas que comercialmente pueden parecer inadecuadas, como por ejemplo:

  • Liberar tu core tecnológico como código abierto. Eso fue exactamente lo que hizo Walmart cuando lanzaron Electrode, la plataforma que desarrollaron para sustentar a su e-commerce. Desde un punto de vista comercial, suena a que estás “regalando tu trabajo”; desde un punto de vista de estrategia tecnológica, es una jugada maestra, dado que permite que millones de desarrolladores mejoren la estabilidad y seguridad de la plataforma, que es en última instancia lo que Walmart necesita para atender mejor a sus clientes.
  • Colaborar activamente con la competencia. Fue lo que hizo Tesla al publicar sus patentes del Supercharger, y así estimular a que otros fabricantes de autos eléctricos se ahorren el I+D y lo adopten, estimulando el crecimiento de la plataforma que hará a su vez más deseables los autos de Tesla.
  • Experimentar con tecnología inmadura y en líneas de negocio aparentemente desconectadas, que es lo que ha hecho continuamente Google desde sus tiempos de Gmail y Google Maps. Muchas de sus apuestas fallan (Google Wave?), pero las que funcionan pagan grandes dividendos y multiplican el valor de Google como plataforma.

Y de vuelta, tomar decisiones tecnológicas con criterios puramente comerciales puede conducir a desastres como el de DHL, que desperdició 11 mil millones de dólares comprando dos empresas de software de forwarding (con la esperanza de acelerar su digitalización) y luego tratando de unificarlas con chicle hasta que finalmente tuvo que rendirse.


Tener un liderazgo estratégico con un ADN tecnológico (que es la síntesis de lo expuesto arriba) desencadena muchos de los efectos deseados de transformación organizacional que se mencionaron al principio: una cultura más abierta, una reestructuración que elimina burocracia, un mejor flujo de ideas, poner a las personas correctas en el equipo, etc. El punto es que llegar a ese happy place involucra cambios difíciles, dolorosos y que enfrentarán mucha resistencia interna, y la única manera de pasar al otro lado es con una visión firme de hacia dónde ir.

Es por eso que el orden de estos factores no es trivial: toda empresa que quiera acometer esos cambios hoy necesita distinguir claramente cuál es el carro y cuáles los caballos que tiran de él, y ponerlos en el orden adecuado. Es la única forma de que la transformación no venga al azar o por accidente; porque si ése es el caso, las probabilidades están bastante en contra.

Cómo saber si eres un ‘UX Chamuller’ (y qué hacer para dejar de serlo)

Chamullar (verbo). El acto de adornar oraciones con elementos innecesarios.

He aquí una lista de lo que he conseguido en mi vida gracias a chamullar:

  • Escapar de una paliza
  • Colarme en un concierto,
  • Conseguir pareja
  • Terminar la secundaria
  • Viajar sin documentos
  • Hacer que el primer párrafo de mi artículo fuera una lista para así parecer un redactor con recursos literarios. BOOM.

En general, mi relación con el chamullo ha sido buena, pero cuando traté de llevar esa experiencia al mundo digital  — y en especial al de la UX —  todo empezó a fallar.

¿La razón? Los usuarios. En un entorno cotidiano — “offline” — , los receptores de mi chamullo eran un público más o menos cautivo: tenía herramientas para retener su atención, como leer su postura corporal para adaptar mi discurso.

Entre otras herramientas más sofisticadas.

En cambio, en contextos digitales, el usuario elige qué contenido consumir y qué contenido pasarse ceremoniosamente por sus zonas más ocultas. Y, según las estadísticas, hay mucha información que termina en ese lado oscuro. De hecho, el Nielsen/Norman Group estima que, en un sitio promedio, un usuario solo lee el 20% del contenido.

Así que si quería que mi contenido entrara en la primera categoría, debía ser importante, especial, directo, y que responda a una necesidad de información.

O sea, todo lo contrario al chamullo.

Pero ¡ojo!, el ‘UX Chamulling’ va más allá de las palabras. También incluye imágenes, vídeos, colores, y demás elementos de una interfaz. Lo importante es saber detectarlo para luego evitarlo.

Y como un ‘UX Chamuller’ en recuperación, he logrado encontrar algunos síntomas, por ejemplo:

1. Utilizas frases ‘amigables’ en tus interfaces.

Entiendo tu postura, amigo UX: Quieres generar empatía y una real conexión con tus usuarios. Y para eso, utilizas frases lindas, amigables, que tocan el corazón de la gente.

Un botón tan largo no toca el corazón de la gente. De plano le atraviesa el pecho.

Como en mi caso de chamulling, apelar a estos sentimientos puede aplicarse en una conversación real, pero al trasladarse a una plataforma digital, las frases son sólo relleno. Parafraseando a Steve Krug en ‘Don’t make me think’:

Las frases amigables son como las conversaciones de ascensor: no tienen contenido, son sólo una forma de ser sociable. Pero la mayoría de usuarios web no tiene tiempo para ‘conversaciones de ascensor’, quieren ir directo a lo importante.

“Cómo apoyar a Typewolf: blablablablablablablabla”

2. Quieres diseños al estilo de Dribbble

Si la UX fuera un barrio problemático, Dribbble sería el que vende las drogas. Primero te invitaría a mirar lo que tiene, y te convence de que es lo mejor del mundo. Luego, te animaría a probarlo.

Y lo haces. Realizas tu diseño pensando en una gráfica que viste en Dribbble. A mitad de camino te das cuenta de que quizás algunos elementos no funcionan tan bien. Pero continúas. Ese es el problema con las adicciones: bloquean estas pequeñas alertas..

Tomen el ejemplo de este rediseño:

Se ve increíble y funciona perfecto… siempre y cuando vivas en un mundo en el que todos tus usuarios suben fotos profesionales con fondos simples, y donde a Facebook no le importa ganar dinero (¡ja!), pues no se han establecido espacios para la publicidad.

No tengo nada en contra de los diseños hermosos. Sí tengo todo en contra de los diseños que sacrifican funcionalidad por estética. Si estás forzando contenido para adaptarlo a tu bello diseño, estás siendo un ‘UX Chamuller’.

3. Utilizas ‘Lorem Ipsum’

Tengo un reto para ti: La próxima vez que quieras enviar un e-mail no lo redactes directamente. Utiliza primero Lorem Ipsum, y mira cómo queda. Cuando se vea bonito, ya puedes reemplazar el falso latín con el texto real que querías enviar en ese correo. ¿Te pareció una perdida de tiempo? Qué bueno, porque lo es.

Para tus diseños de webs o apps o cualquier interfaz, el resultado es el mismo: utilizar latín no te salvará de tu destino.

A diferencia de otras ocasiones en las que solo el latín te salvará de tu destino.

Y tu destino es que, eventualmente, tendrás que re-acomodar (o volver a hacer desde cero) tu diseño ‘loremipsum’ para adaptarlo al contenido real.

Para evitar esto, ningún proyecto de diseño debería empezar sin tener el contenido definido. Pero entiendo que eso no siempre es posible, y en ese caso vas a tener que redactar el contenido tú mismo.

“Pero Nico” — me dices con tu voz de dolor sit amet consectetur — “yo no sé redactar y probablemente lo que escriba sea incomprensible y terminen desechándolo”. Ah, ¿y qué pensabas? ¿Que tu cliente iba a leer tu Lorem Ipsum e iba a decir “Es exactamente lo que quería, utilicémoslo para vender mi producto, por favor”?

Si es realmente tu caso, te diría que es momento de aprender a redactar. Un UX Designer debe encargarse de brindar una gran experiencia a nivel visual, interactivo y de contenido. Si solo sabes manejar programas de diseño y esperar instrucciones, entonces no eres un UX Designer, eres un ‘chofer de mouse’.

4. Usas ejemplos que encajan perfectos en tu diseño

Tienes que crear una sección de perfil de usuario. Tu instinto UI te hace crear un card de 200 px de ancho, con una imagen de un sujeto sonriente (con lentes de carey, probablemente) y abajo un nombre muy ‘UX’: “Mark Hall”. Justo después del nombre, su fecha de nacimiento “2 de abril”. Lugar de Nacimiento: Lima. Todo encaja perfectamente en tu contenedor.

El problema con el mundo es que tiene muy poco de Mark Hall, y tiene mucho de Consuela Bananahamock Fernandez van Bronckhorst de Icorrobarrutia, nacida el 30 de noviembre en Ciudad del Cabo. ¿Está tu UI preparado para esto? ¿O creaste una interfaz que chamulla sobre su perfección?

5. Usas plantillas ‘tal-co’ (tal-como vinieron)

Déjame confesarte algo: Amo las plantillas. Están muy bien diseñadas, tienen efectos fantásticos, son responsive… básicamente el trabajo ya está hecho, y solo tienes que llenarlas de contenido, ¿verdad?

Bueno, sí. El problema es que en ocasiones las plantillas (hechas con Lorem Ipsum, probablemente) tienen muchos espacios para rellenar. Y en vez de adaptar la plantilla a las necesidades de tus usuarios, generas más contenido para llenar los espacios en blanco. (Esas itálicas son de puro juzgamiento.)

Ese contenido extra que generaste, esa foto que pirateaste de Shutterstock con la “búsqueda por imagen” de Google, ese titular con frases vacías, ese párrafo que parafrasea un contenido anterior… todo eso es chamullo al más alto nivel.

6. Escribes para Google (SEO)

Un ‘UX Chamuller’ entrenado sabrá alargar textos ad infinitum (¿loremipsum?) para poder incluir todos los keywords que permitan a Google indexar su página. El problema con este tipo de contenidos es que generan frustración: el usuario entró a tu página a buscar una respuesta, no a que le re-frasees la pregunta 10 veces en los tres primeros párrafos:

En este artículo te voy a contar cómo hacer para no escribir chamullo para el SEO. Estate atento para descubrir, en unos segundos, cómo no chamullar, florear, vender la pescá, cuando redactas para que Google detecte palabras clave en tu contenido.Mucha gente se pregunta ¿Cómo evitar el chamullo en las redacciones de Search Engine Optimization? En realidad es bastante simple dejar de chamullar cuando escribimos para los motores de búsqueda.

Pregúntate si el SEO está ayudando a tu empresa. Quizás hay más gente entrando a ver tu página, pero ninguna realmente se queda porque no encuentra lo que busca. O porque tu chamullo le impide llegar a su objetivo de usuario. O quizás porque los bombardeas con publicidad irrelevante.

Solteras en su área buscan chamullar.


Cómo dejar el ‘UX Chamulling’

Tres palabras: estrategia de contenido.

Hay mil formas de explicar lo que es, pero una con poco chamullo se resumiría así:

Toda pieza de contenido debe cumplir un objetivo específico.

‘Pieza de contenido’ es todo elemento que transmite información al usuario: Imágenes, videos, fotografías, íconos, texto, audios, tablas, números, infografías, etc.

Los ‘objetivos específicos’ pueden ser: informativos, de engagement, de empatía, de marketing, de branding…

Sobre esta información nueva, te hago la siguiente pregunta:

Cuando pensaste en hacer ese sitio web y automáticamente pensaste en poner una cabecera grande con un vídeo de fondo ¿lo hiciste porque tenías un objetivo específico para esa imagen? ¿o fue porque los chicos cool del barrio lo hacían y tu también querías ser popular?

Parte de tu recuperación de ‘UX Chamuller’ es notar que se puede seguir siendo cool sin tener que usar un header con vídeo o un efecto ‘parallax’ 👇

De hecho puedes ser ‘the coolest’.

“Pero Nico, en mi compañía / start-up / negocio / carrito sanguchero no hay un estratega de contenidos”

Entonces, querido UX Designer, tú debes asumir ese trabajo.

Si estás encargado del UX Research, asumir también el rol de Estratega de Contenido ayudará a emparejar el storytelling de tu producto con el que se muestra en tu interfaz.

Si eres diseñador de interfaces, es tu oportunidad de escalar al siguiente nivel y empezar a construir un producto coherente a nivel visual y de contenidos. Va a ser como redactar el guión de una telenovela, y luego encargarte del escenario y del maquillaje, ¿CUÁN GENIAL PUEDE SER ESO?

Pare de sufrir

Con estas lecturas recomendadas:

*El concepto de “chofer de mouse” lo tomé prestado de una charla de Daniel Mordecki sobre interfaces intuitivas.

“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.
😉