Experiencias gastronómicas sorpresa

Descubrimiento e ideación

Lo primero que hicimos fue definir dos sesiones de co-creación con el cliente para así poder alinear objetivos. El objetivo de estas sesiones era identificar los momento clave en los que un usuario utilizaría este producto, o sea, contratar una experiencia gastronómica sorpresa. De aquí salieron dos momentos claves los cuales utilizamos para sacar las necesidades del usuario en base a estos dos contextos. Estas necesidades las idearíamos en base a tres categorías: social, emocional o personal y funcional. Con esto nos quedaba una infinidad de necesidades que mediante un diagrama de afinidad las fuimos agrupando en términos que utilizamos para definir los diferentes arquetipos que estaban presentes.

Como ya sabemos, construir un producto que sea para todo el mundo es algo que lleva al fracaso. Por tanto, teníamos que acotar cuáles de todos ellos iban a ser nuestros usuarios clave. Por ello, definimos unos ejes en los cuales colocaríamos valores que definían al producto y en base a ellos, situamos a estos arquetipos. Lo que definimos con el cliente fue qué cuadrante de este esquema era el que íbamos a acotar, aquel que representaba la propuesta de valor del producto y por ende, los arquetipos ubicados en este sector serían aquellos que serían nuestro público objetivo.

‍

‍

Este usuario tipo se caracterizaría por:

• Ser un explorador de planes de ocio. Buscaba planes innovadores y diferentes que le sorprendieran y le sacaran de la rutina
• Ser una persona con la necesidad de cuidar a los suyos y de preocuparse porque pasaran un rato agradable.

Otro ejercicio muy útil que llevamos a cabo en la sesión fue el de idear mensajes comerciales y verdades del negocio en base a los valores definidos anteriormente. Este ejercicio nos ayudó mucho para posteriormente enfocar ciertos copies y conceptos que tendrían lugar en la web.

‍

Análisis

Observamos la web actual y pudimos sacar aquellos pain points en los que debíamos focalizarnos. Éstos los utilizamos para definir los KPIs que iríamos a analizar en la competencia directa e indirecta. Esto nos sirvió para ver cómo productos parecidos contaban el valor de su servicio así como el uso del mismo y también cómo resolvían el proceso de compra que era uno de nuestros principales problemas.

‍

Definición y conceptualización

Uno de los requisitos comerciales consistía en definir la estructura de la web de manera que pudiesen escalar el producto en varias ciudades conforme fuesen abriendo en ellas. Para ello realizamos una arquitectura de la información de manera que estructuráramos las secciones de la web de la forma más óptima para poder cumplir este requisito. Principalmente tendríamos:

• Una página principal genérica donde se explicaría el valor del servicio, cómo funciona, las ciudades en las que estaba disponible y los 4 tipos de planes (de forma genérica de nuevo, o sea, sólo contando las características en sí del plan). A partir de esta página principal, el usuario podía ir a ver la página específica de la ciudad que quería ver.
• Una página de ciudad: donde le aparecerían estos 4 mismos planes pero con el precio específico de cada ciudad y con contenido personalizado de la ciudad en concreto. Estas páginas específicas de ciudad realmente serían una especie de template en la que se cargarían los datos dinámicamente según la ciudad que estuviese viendo el usuario.
• Una página de plan: Lo mismo para los planes, cada plan tendría una página específica que se cargaría con los datos de la ciudad y el plan que estuviese visualizando.

Además también tendríamos una página de ‘Cómo funciona’, ‘ Valores’ y ‘Blog’.

Lo siguiente fue realizar los user-flows que iban a tener lugar en la web. Es decir, los procesos para comprar una experiencia o para canjearla. Esto nos ayudó a redefinir el proceso que era uno de los objetivos del proyecto y lo que decidimos fue partir de la base del rol que la persona que estaba realizando la compra iba a tener en la experiencia. A partir de esta elección, el usuario iria por un flujo u otros con unas variables definidas según ese rol elegido. Con esto solventábamos uno de los puntos de fricción que existían anteriormente ya que los usuarios no entendían la diferencia en algunas situaciones entre los conceptos de ‘regalar’ y ‘reservar’.

‍

‍

Estos procesos se los presentamos a cliente con un prototipo en wireframes de media fidelidad para que aprobaran estructura y ciertos copies, de manera que si surgía algún cambio, pudiese ser más ágil realizarlo. Una vez aprobados tanto los procesos como las diferentes páginas, pudimos pasar a la fase de diseño.

‍

Diseño visual

Una de las partes que más disfruto en los proyectos es la de buscar inspiración. Realicé un análisis exhaustivo de productos digitales que me inspirasen y evocasen a diseñar la experiencia de este proyecto y una vez tuve claro el enfoque, lo que hicimos fue diseñar lo fundamental. Es decir, como en wireframes si que teníamos especificado todo el proceso, lo que decidimos, para agilizar sobre todo para poder ganar más tiempo en la parte de construcción, fue diseñar aquellos elementos más importantes así como la página principal ya que con ello era suficiente para poder definir el resto.

La gama de colores con la que íbamos a trabajar la conformamos con los mismos colores que ya estaban usando ya que toda su marca en redes sociales estaba creada así y la intención no era modificarla. Con éstos colores, sacamos unos secundarios menos saturados para poder crear contraste.

En las sesiones de co-creación definimos cuál sería el estilo que debía respirar la web a lo que el cliente decidió que fuese algo con un aire elegante y ,a la vez, fresco. La parte elegante la podemos visualizar en los colores, las tipografías y el estilo de las imágenes. La parte fresh podemos verla en el uso de las formas redondeadas y los degradados.

‍

‍

Otro punto que nos pidieron fue resolver el scroll tan largo que se quedaba en mobile. Para ello lo que hicimos fue reducir la manera de contar el ‘Cómo funciona’ de 5 a 3 pasos y a su vez, añadiendo un scroll horizontal automático que haría que, cuando el usuario navegara por la web en móvil, al llegar a este paso, se mostraran los 3 pasos de manera horizontal con el propio movimiento de scroll.

‍

‍

Construcción no-code

Para la materialización de este proyecto utilizamos las siguientes herramientas no-code:

• Webflow: para la parte visual del front y CMS de los elementos dinámicos que tendríamos en la web
• Xano: como base de datos para los procesos de compra. Aquí alojaríamos todas las reservas realizadas con su información particular. Esta herramienta nos posibilitaba realizar APIs necesarias para permitir esta base de datos