Una carrera contra el fuego
Lo que 5 días de Design Sprint me han enseñado.
¿Qué es Design Sprint?
Comenzaré con una breve descripción para todas aquellas personas que aún no estén familiarizadas con este término. Design Sprint es una metodología ideada por Jake Knapp en 2010 cuando trabajaba en Google Ventures. En ella se mezclan las metodologías ágiles con el Design Thinking para obtener como resultado un proceso de aprendizaje y validación de ideas en un tiempo muy limitado.
¿Por qué Design Sprint?
Como todo el mundo sabe, vivimos en un mundo en el que la velocidad a la que suceden los acontecimientos es frenética. Cada día salen cientos de nuevos productos y servicios al mercado y las empresas necesitan mantenerse actualizadas si quieren seguir siendo competitivas. Es por ello que ante una nueva situación de lanzamiento, o mejora de alguna funcionalidad, es aconsejable por lo menos tantear un poco el terreno para saber por dónde van los tiros. En este contexto Design Sprint aporta una serie de herramientas que ayudan a la creación y la validación de ideas en un tiempo record de 5 días, algo que agiliza mucho el proceso y que otras metodologías no logran.
El reto y el proceso
Para explicar los aprendizajes que esta metodología me ha aportado, expondré brevemente el reto al que nos enfrentamos y las distintas fases del proceso que tuvimos que llevar a cabo.
El reto
El primer día se nos facilitó un briefing con el reto, el cual incluía una breve información descriptiva y una pregunta:
¿Cómo podemos contribuir tecnológicamente a la prevención de incendios forestales y recuperación de arboledas?
A partir de esta información, lo siguiente fue ponerse sin perder un segundo manos a la obra y comenzar con el Sprint.
Día 1: La unión hace la fuerza
A través de 8 participantes, una whiteboard y diferentes dinámicas como sprint questions, HMW o user journeys, generamos una gran cantidad de ideas para poder resolver el reto que nos habían propuesto. Posteriormente se realizó una votación y se eligieron 2 sobre las que trabajaríamos al día siguiente.
Lo que aprendí de este punto: hubiese sido imposible llegar a generar tanta información y tan diferente si no hubiésemos hecho la dinámica todos juntos.
Día 2: Divide y vencerás
La segunda jornada consistió en la investigación y desarrollo de las ideas elegidas. Ahora divididos en 2 grupos y de forma individual, hicimos un pequeño research que en esta metodología se denomina Lightning Demo y posteriormente lo pusimos en común. Con las ideas creamos bocetos y notas y las concretamos un poco más a través de un ejercicio de rapidez llamado Crazy 8 y unos wireframes que expondríamos al siguiente día.
Lo que aprendí de este punto: La investigación, aunque sea en un período de tiempo corto, te permite ver cosas como: lo que es posible y lo que no, lo que ya existe y lo que no y te da pistas de por dónde puedes seguir trabajando.
Día 3: A menudo cualquier decisión, incluso la decisión incorrecta, es mejor que ninguna decisión
En este punto expusimos los wireframes creados el día anterior en el museo del arte y votamos que idea íbamos a trabajar a través de diversos métodos. Una vez decidido, creamos un storyboard para visualizar mejor nuestro producto.
Lo que aprendí de este punto: Tomar decisiones siempre es un proceso complicado y supone descartar otras ideas que pueden resultar interesantes, pero es la única forma de avanzar.
Día 4: Cada edificio es un prototipo, no hay dos iguales
Llegados al cuarto día tocaba realizar un prototipo que se trabajó de manera individual. Había que darle una forma más refinada a la idea seleccionada y reformular algunos puntos para poder posteriormente testarlo con usuarios, por lo que, lo primero que hice en mi caso, fue realizar unos wireframes de baja fidelidad en papel para hacerme una idea de las funcionalidades que la app tenía y posteriormente analizar cuáles eran las más importantes para poder trabajarlas en digital.
Me voy a detener a explicar brevemente el por qué tomé ciertas decisiones a la hora de desarrollar el prototipo y en el siguiente punto, veremos si realmente las decisiones tomadas funcionaron de cara a los usuarios.
Pantalla home
Diseñé la pantalla home para que fuese lo más sencilla e intuitiva posible. Ya que es una app que se debe usar en momentos puntuales y de emergencia, debía cumplir con la premisa de ser lo más minimalista posible para evitar crear una alta carga cognitiva.
Pantalla localización y aviso a emergencias
Esta funcionalidad la diseñé para poder ubicar a tu mascota, saber si se encuentra en una situación de riesgo y en caso de ser así, poder mandar un aviso a emergencias. Intenté crear la misma estética que en el resto de pantallas para que existiese una consistencia en el diseño y traté de usar iconos y patrones reconocibles ya usados en otros productos, todo esto con el fin de facilitar el entendimiento. El botón de emergencias lo coloqué en una zona visible y accesible y alineado a la izquierda para no crear confusión con el botón de localización del menú. En la pantalla de emergencia creé una verificación para hacer más seguro el botón y prevenir el error. Una vez enviado creé una notificación para dar feedback de la acción realizada.
Pantalla incendio cercano
El objetivo de esta pantalla es el de poder detectar animales de terceros atrapados en un incendio que estemos viendo cerca. Para este flujo me basé en los mismos requisitos que en pantallas anteriores, consistencia y estándares, prevención de errores, feedback y una estética homogénea.
Pantalla notificaciones
En este caso el objetivo era crear un flujo para que el usuario pudiera ver y gestionar el registro de notificaciones recibidas. Siguiendo la misma dinámica que en pantallas anteriores, creé las notificaciones intentando que la información estuviese clara de un simple vistazo y generando un flujo seguro con verificación para no eliminarlas por error.
Lo que aprendí de este punto: Es fundamental antes de ponerse a diseñar, tener claras cuáles son las funcionalidades más importantes, así como tener una idea de cómo quieres que funcione tu prototipo para no perder tiempo una vez que ya estés trabajando en él.
Día 5: Sólo puedes analizar los datos que tienes, sé estratégico sobre qué reunir y cómo almacenarlo.
Y llegamos a lo que sería el culmen de la metodología, aquí es cuando validaremos si esa idea en la que hemos estado trabajando resulta atractiva o no y si bien en ocasiones es necesario iterar, en otras el proceso terminará aquí.
En mi caso realicé unos test moderados a 6 participantes que inicialmente cumplían el perfil escogido: Persona que tenga mascota, le guste estar en contacto con la naturaleza y esté concienciado en mayor o menor medida con los incendios forestales.
Comencé con preguntas genéricas para saber datos cuantitativos, cualitativos y de carácter personal. Si bien la muestra era pequeña me sirvió para constatar que todos eran el perfil de usuario que necesitaba.
Posteriormente a través de la herramienta Maze, realicé unos test de usabilidad con diferentes situaciones hipotéticas para ver cómo de sencillo o complicado resultaba usar la aplicación.
Por último planteé algunas preguntas de sí o no, algunas preguntas de valoración en escala y algunas preguntas abiertas. Con esto traté de conseguir que la gente pudiese indicar si les resultaba atractiva o no y el por qué y dar una opinión personal sobre lo que les había gustado más o menos, además de poder colaborar con cosas que se les ocurrieran para posibles futuribles.
Los resultados más relevantes en cuanto a usabilidad fueron los siguientes:
- 3 de 6 entrevistados se equivocaron de icono al realizar la tarea de localizar a su mascota y dar aviso SOS.
- 4 de 6 entrevistados consiguieron dar un aviso de animales en incendio con éxito.
- Todos los entrevistados consiguieron acceder a sus notificaciones y borrar una.
- 3 de 6 entrevistados tuvieron tiempos lentos en la pantalla home.
- Todos los usuarios consideraron que la app solucionaba algún problema, su valoración fue de 3,8 sobre 5.
- Todos los usuarios consideraron la app fácil de usar, su valoración fue de 4,3 sobre 5.
Conclusión y futuribles
La conclusión extraída de los datos y preguntas analizadas fue la siguiente:
Es una aplicación que tiene potencial de cara a usuarios dueños de perros y para el sector ganadero, pero no es tan útil de cara a usuarios de otro tipo de animales ya que su uso sería mucho menos frecuente.
Para concluir, algunos futuribles extraídos de los datos analizados y comentarios que dejaron los participantes:
- Crear una sección de comunidad dentro de la app para que los usuarios puedan colaborar en labores de detección y rescate.
- Crear alianza con alguna app de geolocalización como por ejemplo Google Maps para añadir las funcionalidades que ofrece Animal Location.
- Cambiar los iconos del menú de navegación o incluir textos con la funcionalidad para evitar errores y aliviar la carga en la memoria.
- Simplificar los textos de las notificaciones al máximo para hacer más fácil su uso en situaciones de emergencia.
Lo que aprendí de este punto: Hasta que no se testa el prototipo no podemos saber realmente lo que hemos hecho. Hacer pruebas de concepto y usabilidad y poder extraer conclusiones es la parte más importante de todo proceso, hasta ese momento todo lo que hayamos hecho tendrá un sesgo personal y alejado de lo que realmente la gente necesita.
Y con esto concluye mi carrera contra el fuego a través de esta metodología que, en mi caso personal, ha servido para cumplir las 2 expectativas que prometía, validar el concepto y aprender por el camino.
