Rol

Researcher
Diseñador UX
Diseñador UI

Fecha

2021

Contexto

Hiklub se nos presenta como una plataforma para organizar actividades de turismo activo que proporciona al usuario grupos afines con los que participar en ellas. Además, invierte una pequeña parte de los beneficios en proyectos medioambientales.

Investigación

Después de realizar un profundo análisis de mercado decidimos entrevistar a usuarios susceptibles de usar plataformas como Airbnb Experience, Meetup y GuruWalk para la creación de un evento, ya que en nuestro brief inicial se nos pedía desarrollar el flujo para el organizador de eventos.

Por este motivo descartamos trabajar con encuestas. Quisimos centrar nuestra investigación en gente que había organizado al menos una vez algún tipo de evento y utilizar métodos cuantitativos hubiese supuesto invertir recursos y tiempo en impactar a otros usuarios.

El objetivo de nuestra investigación fue identificar cuáles eran los problemas que encontraban los creadores de eventos. Se realizó 1 entrevista a un total de 7 usuarios: creadores de eventos amateur y semi profesionales (cierta experiencia sin dedicarse profesionalmente a ello). Edad: 30–45 años.

Conclusiones de Investigación

Tras el análisis de los resultados de las entrevistas hicimos un ejercicio de clusterización. Nos dimos cuenta que todos los insights extraídos podían clasificarse en tres grandes categorías:

• Organización: el usuario necesita una plataforma única que le permita crear un evento de principio a fin y que le guíe para entender cuáles son los pasos necesarios para hacerlo.

• Comunicación: el usuario que crea un evento necesita un canal para gestionar y centralizar todas las comunicaciones con los actuales y posibles asistentes. Siente que Whatsapp no es la vía porque le obliga a estar vinculado en todo momento y la mayoría de las veces respondiendo a preguntas frecuentes que suelen repetirse.

• Visibilidad: esta tercera categorización hace referencia a la dificultad por encontrar personas afines a las que les llegue el evento y puedan apuntarse para que pueda celebrarse.

Todos estos insights que habíamos clusterizado respondían a su vez a un insight mucho más claro, el cual habíamos pasado por alto porque parecía demasiado evidente pero que definitivamente no lo era: “no sé por dónde empezar”.

User persona

Marc es una persona muy activa y el running es su afición predilecta. Comenzó entrenando solo en la calle y poco a poco fue conociendo a personas que compartían su pasión. Un día decidió crear pequeños grupos de aficionados como él y promover pequeños eventos de running.

Problema

Los usuarios que quieren crear eventos de turismo activo y actividades al aire libre necesitan ayuda para tener claro los pasos para montar su evento porque desconocen cuáles son los puntos necesarios a tener en cuenta y eso les hace sentir inseguros.

Propuesta de valor

Quisimos dar un paso más y trabajar mejor la definición de marca para que nos diera un valor añadido en la solución que íbamos a proponer para la plataforma.

Hiklub tenía un propósito, contribuir a mejorar el planeta. Y un posicionamiento de marca claro, se iba a convertir en una gran comunidad de personas afines con las que participar en actividades deportivas al aire libre. Nuestra gran apuesta además fue reforzar una de las unique selling proposition: la especialización. Como especialistas en turismo activo, íbamos a ayudar a que sus usuarios también lo fueran.

Producto

Fruto de nuestra investigación establecimos múltiples casos de uso y los ordenamos por orden de prioridad para que nuestro prototipo tuviese la mínima viabilidad posible.

1 Marc quiere organizar un evento de running.

• Marc quiere acceder fácilmente a cualquier paso de la creación del evento.

• Marc quiere modificar fácilmente cualquier contenido.

• Marc quiere revisar su evento antes de publicarlo.

2 Marc quiere editar los datos de un evento ya creado.

3 Marc quiere comunicar algo a los participantes.

Al abordar el primer caso de uso y gracias a los test de usabilidad que realizamos durante el proceso, definimos varios escenrios importantes dentro del caso 1. Los otros dos casos los empezamos a ubicar dentro del prototipo pero finalmente los pospusimos como siguientes pasos en siguientes iteraciones.

Flujo de usuario

El flujo del creador de eventos empieza en el momento que el usuario accede desde un CTA en la home de la plataforma. Si no está registrado pasa por un onboarding donde se le explica a grandes rasgos en qué consistirá la creación del evento y entonces sí:

Dividimos este proceso en 6 pasos. El último de los pasos lo dedicamos a una evaluación del evento para mejorar su visibilidad dentro de la plataforma. En los otros 5 intentamos simplificar al máximo la información necesaria y fundamental para crear con éxito un evento. También consideramos repartir los campos a rellenar lo más equitativamente posible.

El usuario pasa primero por Categoría y según el tipo de evento que elija se mostrarán durante el resto del proceso un tipo de contenido exclusivo de esa especialidad. Por este motivo solo una vez define el tipo de evento el usuario puede navegar indistintamente a través del resto de pasos, pero no antes.

Soluciones

Definimos 3 tipos de contenido de soporte durante el flujo:

• Una referencia siempre visible a modo de subtítulo en cada campo donde se empieza a tratar la especialización de cada evento. Siempre ligado a un tono cercano para que el usuario se sienta confiado y seguro.

• Sugerencias o ejemplos de otros usuarios del mismo tipo de eventos que sirvan como guía a Marc. Seguimos profundizando en un tipo de contenido enfocado en la especialización.

• Tooltips dirigidos esta vez a mejorar la visibilidad del evento dentro de la plataforma. Queremos que los eventos de Marc tengan el mayor alcance posible para que establezca vínculos con personas afines.

Concepto Central

Teniendo en cuenta la filosofía de Hiklub “disfrutar de experiencias mientras cuidas el planeta” pensamos en transmitir en todo momento el concepto de Naturaleza. Que solo con ver la primera foto se pudiese tocar y que así el usuario se sumergiese dentro de la experiencia.

Pero no solo queríamos transmitir un único concepto de naturaleza.

Quisimos transmitir también una naturaleza elegante (de ahí nuestro color principal). Una naturaleza joven y moderna y otra naturaleza que nos transmitiese calma, paz y transparencia (de ahí nuestros colores de refuerzo). Una paleta de colores basada en 3 verdes sacados directamente de nuestro concepto central.

En el tipo de imágenes que íbamos a usar decidimos ponderar como valor principal el mismo concepto. Además íbamos a tener en cuenta los colores sacados del mismo y la gente que realiza las experiencias.

Test

Una mejora importante fue la de volver a trabajar el onboarding al comenzar el evento. Al testarse 5 de los 6 usuarios ni siquiera se leía la información proporcionada, lo que derivaba en no entender tampoco la página de pagos.

Se tomó la decisión de mostrar la información en 3 pasos de manera más sintética y visual para hacerla digerible. A parte de los USPs queríamos reforzar la transparencia dejando muy claro que comisiones iban a influir en el precio final.

Otra importante mejora que se realizó fue cambiar el ícono de información para los Tooltips. Al testarse 6 de 6 usuarios no hacía click en un icono a modo de “i” al considerar que se le iba a proporcionar información básica de sistema y no lo que realmente le ofrecía la plataforma.

Cambiamos el ícono por una copa a modo de recompensa, ya que teniendo en cuenta ese contenido al usuario se le premia con mayor visibilidad dentro de la plataforma. También se le atribuyeron características de botón, se hizo más grande y se agregó una sombra.

Otra de las mejoras urgentes que se realizaron fue en la pantalla de pago. Al testar 5 de 6 usuarios se encontraban perdidos cuando encontraban la calculadora y la parte de la donación (además no habían leído la parte del onboarding).

Agrupamos toda la información en una calculadora dinámica de datos variables según número de asistentes, precio del evento y donación. Así el usuario tenia un control total de los números del evento y poder de decisión para modificarlos.