Design Thinking e Investigación
Una vez recibido el primer brief para la plataforma usamos varias herramientas de design thinking para generar ideas y buscar un camino para darle forma a nuestra propuesta.
En este momento no teníamos claro como íbamos a abordar el proyecto. Empezamos a trabajar realizando mapas mentales, moodboards, mapas stakeholders, escenarios y definiendo a las personas que serían los protagonistas de nuestra plataforma y como serían los user journeys de los usuarios.
Hemos aplicado Design Thinking centrándonos en tres aspectos: Los usuarios, la creatividad y la iteración. Cuando hablamos de usuarios nos referimos a que estamos siempre centrados en ellos e, incluso a veces, co-creando juntos. Cuando hablamos de Creatividad nos referimos a las diferentes herramientas y procesos que generan nuevas soluciones, como por ejemplo, la clasificación de insights a través de las entrevistas. Por último, con iteración nos referimos a descubrir y aprender haciendo; desarrollar para entender dónde vas.
A través del primer mapa mental nos percatamos de que el ámbito "cultura" es bastante extenso: va desde representaciones artísticas hasta sentimientos genuinos de un área geográfica, desde un concierto de música a una lengua o la gastronomía pasando por la literatura y el teatro.
Nuestra idea era abarcar todos los ámbitos posibles, para nosotros hay tantos tipos de eventos como tipo de creadores. La cultura es una singularidad humana cuyas tipologías, en su totalidad, tienen cabida en ROOOF.
Gracias al mood board comprendimos, casi por casualidad, la necesidad de las personas por mostrar su talento, lo consideramos una especie de carácterística intrínseca, otra forma más que tiene el ser humano de sentirse querido. Además, también intuimos que esta acción se daba en grupo.
Stakeholders
Empezamos a definir quiénes serían los implicados en la plataforma. Al comienzo pensamos que el espacio dónde se realizaban los eventos no estaba relacionado con el artista. Ideamos unas relaciones entre usuarios que se encontraban en un lugar ajeno a ambos y donde unos asistirían a un espectáculo mientras que otros mostraban su talento.
Entrevistas
Tras estas primeras aproximaciones comenzamos a realizar entrevistas a nuestros amigos y conocidos. En este momento eran entrevistas un tanto ingenuas donde preguntábamos aspectos relacionadas con la plataforma y con el uso en rasgos generales de internet y otros medios de comunicación.
Uno de los insights que más nos sorprendió es que la mayoría daba mucha importancia al contenido de los eventos, poniéndolo incluso por encima del precio o de la proximidad del mismo. También surgió como elemento importante la preferencia por eventos íntimos por encima de los masificados.
Uno de los problemas que detectamos es la notable negativa por parte de los entrevistados a ofrecer su casa como lugar del evento. Somos conscientes de que esto puede ser uno de los mayores problemas a la hora hacer nuestra plataforma un proyecto real. Por otra parte, pensamos que nuestra idea no es tan descabellada ya que existen otras webs, como airbnb, donde desconocidos duermen bajo el mismo techo.
En cuanto a los creadores del evento descubrimos que necesitaban ciertas funcionalidades que les hiciese sentir seguros y afines a la plataforma: deben poder decidir el lugar, la fecha, la hora el número de asistentes, el precio. Los creadores tenían que ser los usuarios "mimados", ofrecen su casa e invierten tiempo y preparación para realizar el evento. Pero no podíamos olvidar a los asistentes los cuales son mayor en número. Nos empezamos a percatar de que teníamos una posible complicación: tenemos dos tipos de usuarios muy distintos con diferentes necesidades y motivaciones. Teníamos que resolver las necesidades de cada uno y generar experiencias para ambos al mismo tiempo y a veces por separado.
Como herramienta de análisis de las entrevistas realizamos mapas de insights, para ayudarnos a digerir y entender la información recopilada.
Estas primeras entrevistas también nos sirvieron para dejar de un lado nuestra ingeniudad y buscar una forma más eficaz de sacar información de valor al entrevistado mediante el uso de preguntas más elaboradas.
A continuación, tras las entrevistas, desarrollamos unas "personas" para tener siempre presentes a que tipo de usuario nos dirigíamos, sus necesidades, motivaciones, historia, comportamiento y funcionalidades que podrían necesitar.
Personas
Lo vimos claro, en nuestra plataforma había dos tipos de usuarios: los creadores de eventos y los asistentes.
En un principio tan sólo observamos dos funcionalidades para cada uno. Pepe necesitaba un filtrador de eventos y un asistente de reserva. Por otro lado, Daniela, necesitaba crear un evento y categorizarlo.
Estas necesidades de ambos es lo que nos marcó el camino para desarrollar el primer Producto Mínimo Viable. Un primer prototipo un tanto tosco en diseño pero que respondía a 2 premisas básicas para el funcionamiento de la plataforma: crear y reservar un evento. Posteriormente, dentro de esta release, nos pareció oportuno añadir un apartado de “que es” con el fin de asegurarnos que quedaba claro de qué trataba la página.
Historias de Usuario
Después de ordenar y digerir la información que habíamos recopilado y asimilar los insights encontrados era hora de construír la plataforma.
Como objetivo nos propusimos entregar un prototipo funcional en html y css, con las funcionalidades básicas y más importantes según los resultados de nuestra investigación.
A partir de este punto generamos un featured map en el que ideamos qué historias de usuarios necesitábamos para este fin. Tras una reunión del equipo surgieron estas.
- Ver lista básica de eventos.
- Ver ficha de evento.
- Reservar evento.
- Crear evento (básico).
Workflow
También creamos un Workflow que nos daría un esqueleto a nivel de flujo de navegación de que caminos podían seguir ambos usuarios en la plataforma.
Wireframes y primeros test
Una vez hechas estas dos tareas (historia de usuarios y workflow) ya podíamos comenzar a realizar wireframes y testearlo con usuarios para asegurarnos de que no daban lugar a confusión. Es preferible detectar si todo funciona correctamente en este punto antes de comenzar a diseñar y a invertir el tiempo para no generar "waste".
En esta ocasión probamos el wireframe con algunos usuarios. Hicimos un test de guerrilla con el ipad en la cafetería de la escuela y con nuestros amigos. Consideramos que todavía la plataforma era muy sencilla y no eran necesarios test más exaustivos, los cuales los realizamos más adelante cuando la arquitectura y el diseño fuesen más completos.
Propuesta gráfica
Además, animados por nuestra condición de diseñadores gráficos, en esta primera release comenzamos a proponer la gráfica.
Elegimos tipografía para titulares y cuerpos de texto. Las seleccionadas fueron la Dosis y la Pt serif. La primera al ser redondeada y sin serifa nos generaba sensación de amabilidad, diversión casi infantil, tiempo de ocio. Además, al tener muchos pesos disponibles nos daba la oportunidad de sacarle mucho partido y darle diferentes usos. Sin duda consideramos que éste tipo de letra nos sería muy útil para los titulares.
Por otra parte, la Pt serif, sería la encarga de rellenar nuestros cuerpos de texto. Su condición es más adecuada para ser leía en largos párrafos y nos da un toque de distinción más elevado en los contenidos.
A su vez, en éste primer toque de contacto con la apariencia visual de la página, establecimos otra serie de estándares que luego cambiaron como el color, el uso de textos sobre imágenes, el logotipo y los botones.
Durante esta primera release cada uno diseñó una página completa, aún pensábamos en páginas totales y no en los elementos que la componen. Ahora en la distancia viendo todo este trabajo gráfico que realizamos consideramos que podríamos haber probado las prácticas que sugiere Brad Frost en su artículo "Atomic Design". Pero claro, debido a nuestra inexperiencia y nuestra condición de diseñadores gráficos estábamos deseando generar material visual atractivo y complejo sin pensar en el rendimiento y en el trabajo iterativo incremental.
UX
A nivel de experiencia de usuario y de normas de lenguaje visual y textual llevamos a cabo las siguientes prácticas:
Fotos de calidad y atractivas. Las consideramos parte importante del contenido de la web. Por medio de las entrevistas el usuario nos reveló que para él era muy importante el contenido del espectáculo. Debíamos mostrarle imágenes que connotasen calidad y que le incitasen a probar la experiencia que proponía el creador del evento. Pero en esta release aún teníamos en mente que fuese el usuario el que subiese estás imágenes, por lo cual decidimos dejar algunas de menor calidad para ir testeando.
Generamos un código en imágenes fotográficas. Las imágenes relacionadas con usuarios serían círculos, mientras que las relacionadas con los eventos serían rectangulares. Pretendíamos reducir la curva de aprendizaje de la web lo máximo posible.
Copys: frescos, cercanos y un poco por encima de lo establecido como formal. Definimos nuestro target como gente sin vergüenza a mostrar lo que hace y sin prejuicios por lo desconocido. Por eso nosotros nos mostramos sinceros y enseñamos nuestras debilidades con un guiño un tanto canalla.
Arquitectura de la información
En cuanto a arquitectura de la información planteamos los siguiente niveles con ésta jerarquía:
- Vamos a un evento: Consideramos que el porcentaje de usuarios que van a eventos es superior al de los creadores. Por ello dimos más importancia a ésta acción. El usuario nada más llegar a la página tendría la posibilidad de, mediante este call to action, elegir uno de los eventos que proponemos.
- A la vez teníamos que comunicar qué es Rooof. Por ello usamos un copy bien visible nada más entrar en la landing donde te explicaba de qué trataba la plataforma. A su vez, en el header había un ancla que te llevaba a una explicación más amplia.
- Publicar un evento: con este botón bien visible en el header el usuario que crea evento tiene la posibilidad de crear su acción, pero primero le conducíamos a una página dónde intentamos convencerle de las bondades que conlleva crear un evento con nuestra plataforma.
También, mostramos testimonios de otras personas que ya han creado eventos con Rooof y relatan de forma positiva su experiencia. Esta página sufriría cambios de copas en en futuro a causa de la investigación y los datos obtenidos a través de las entrevistas.
Solución tecnológica
El primer prototipo fue diseñado en illustrator y maquetado con HTML, CSS y un poco de Java Script en elementos como el header.
A la hora de crear el evento recurrimos a un typeform ya que consideramos que no era oportuno invertir tiempo en la creación de un formulario propio. Nos interesaba que lo que nos plateamos en las historias de usuario funcionase con el mínimo esfuerzo posible ya que sabíamos que todo podía cambiar.
El resultado puede verse online. Como prototipo nos ha servido para sacar mucha información y mejorar la plataforma en futuras releases.