Case Study: Isoico

Laura CH
13 min readDec 20, 2021

--

Una ventaja para el sector ocio

¡Hola!

Vuelvo por aquí, vamos a ver un case study el cual comienza con los siguientes requerimientos:

_EL BRIEFING

El Cliente

Me han encargado como UX Designer de un equipo de producto, crear una aplicación móvil que sirva para crear subastas para empresas que ofrecen servicios de ocio (restaurantes, conciertos, etc.).

Objetivo: Ofrecer un beneficio extra a empresas, subastando sus últimos servicios.

Perfiles de usuario de la aplicación:

  • La empresa de servicios. La aplicación le debe permitir dar de alta su empresa y establecer los servicios a subastar, con opción a introducir un precio de venta directa para los usuarios que no quieran esperar. Siempre deberá contar con la validación del departamento de calidad de la app.
  • El cliente. La aplicación le debe permitir acceder a las subastas abiertas con diferentes tipos de filtrado (ubicación, servicio, etc.), hacer las pujas y pagar en caso de ganar alguna.

Flujo de acciones:

  • Ambos perfiles se tienen que haber dado de alta en la aplicación, cada uno según su respectivo perfil.
  • La empresa publica una subasta de sus servicios con todas sus características. Se entiende como servicios la reserva de una mesa (en caso de ser un restaurante), entradas para un concierto, billetes de avión, etc.
  • El cliente debe agregar un método de pago válido para poder participar en la subasta.
  • La empresa puede agregar una opción de “pago inmediato”. En el caso de que un cliente decida pagarlo, la subasta finaliza inmediatamente en favor de él.
  • Cuando un usuario participa en una subasta, irá recibiendo notificaciones del estado de la subasta para saber si va por delante. También se enviará notificación al ganador de la misma.
  • Al ganador de la subasta se le generará un ticket virtual con la información necesaria para acceder al servicio subastado.
  • La empresa recibirá una notificación cuando termine la subasta y recibirá el importe obtenido de la subasta mediante una pasarela de pago (o similares).

Objetivos del UX Designer:

Realizar todo el proceso que crea necesario para poder diseñar (el diseño lo hace el equipo de UI) las pantallas de:

  1. Alta de una subasta (Perfil Empresa)
  2. Mantenimiento de las diferentes subastas. Haciendo hincapié en el sistema de filtrado. (Perfil Empresa)
  3. Pantalla de detalle de una subasta (y sus sub-pantallas), sobre el cual ya tenga diferentes pujas. (Perfil Empresa)

Entregables de la prueba:

  • Workflow detallado de todo el proceso global con todas las acciones realizadas dentro y fuera de la herramienta, por ambos perfiles.
  • Bocetos en papel.
  • Wireframes digitales de las pantallas en cuestión, junto a los distintos estados, steps o sub-pantallas de interacción que pueda haber.
  • Breve explicación que justifique tus decisiones y resultado. Piensa que el paso final después de tu trabajo será que el equipo de UI diseñe las pantallas finales de la app, con lo que debemos estar seguros (dar garantías) que tenemos la mejor UX posible.
  • Cualquier otra documentación que consideres necesaria para presentar todo el contenido. Te puedes apoyar en una presentación en formato storytelling.

Una vez leído y releído a conciencia el briefing, lo primero es tener claro qué debemos mostrar con el proyecto, marcar no solo objetivos del proyecto si no también personales y trazar una estrategia, para saber abordar el reto:

¿Qué esperan encontrar?

  • Poder desarrollar un producto de principio a fin en un tiempo reducido.
  • Mostrar cómo entiendo el proceso de diseño como UX Designer.
  • Utilizar la metodología y técnicas más adecuadas para resolver con el mayor éxito posible este reto.

Estructura del reto

Para desarrollar este reto voy a realizarlo a través de la metodología Design Thinking, ya que es una metodología con la que mejor trabajamos y/o en la que más se desarrolla la parte de UX design, por ello he realizado el siguiente índice o planteamiento del proceso:

  • Introducción
  • Contexto

_DESCUBRIENDO Y DEFINIENDO

  • Investigación
  • Nuestro Usuario
  • Findings & Pain Points

_DISEÑANDO

  • Arquitectura de la información
  • Flujos
  • Wireframes, Wireflows & Framework

_Futuribles y Conclusiones

_DESCUBRIENDO

Una vez claro los objetivos y requerimientos del proyecto es hora de dar paso a la investigación y para ello comenzamos ya a plantearnos preguntas:

¿Cómo abordamos este proyecto?

Antes de nada vamos a empezar realizando un desk research, de otras empresas que ya ofrezcan el mismo servicio o similares, para que nos ayuden a entender cómo realizan los procesos de subasta, reserva y pago, ver qué flujos están acostumbrados a utilizar los usuarios y poder detectar posibles pain points para dar un mejor servicio con nuestro producto.

Desk Research

Arrancamos con la búsqueda de aplicaciones que den los mismos servicios y la verdad que me encuentro un océano azul, lo cual es una gran oportunidad para el proyecto.

A pesar de no tener referentes directos con los que poder analizar, testar y probar, abro dos líneas de investigación:

  1. Aplicaciones de otro sector, que dan un servicio similar en este caso de apuestas como Bet365 y Bwin, ya que hay funcionalidades que serían similares como las siguientes:
  • Cerrar apuesta.
  • Importes y ganancias.
  • CTA de “cobro inmediato”
  • Ranking de jugadores que podría equivaler en nuestro caso a la posición de los usuarios (clientes finales) en la subasta.
  • Listado con el estado de las apuestas
  • Menú con las diferentes categorías.
  • Sidebar con buscador.

A pesar de que estas ofrecen un servicio diferente, las funcionalidades son aportaciones totalmente extraíbles para algunos requerimientos del proyecto.

Bet365 y Bwin

2. Aplicaciones que ofrecen servicios similares del mismo sector, en este caso tomando el ejemplo de los restaurantes, ya que en la búsqueda he encontrado más aplicaciones con diferentes servicios desarrollados en el sector hostelería que en el de ocio. Entre ellas se encuentran Maybein, Too good to go, FlipEat. En cuanto a las funcionalidades:

  • Alertas/notificaciones
  • Filtros de búsqueda por día/noche, ciudad, calendario, nº personas, y otros con los que la app sería un referente de guía gastronómica (tipo de cocina, servicios del restaurante (accesibilidad, alérgenos, celíacos, grupos grandes, etc), precio y distancia (rango en km).
  • Listado de reservas activas e históricas/anteriores organizadas tipo kanban.
  • Float Button, para seleccionar el modo de visualización de los resultados.
Maybein y FlipEat
  • Método de pago, puedes pagar a través de la aplicación seleccionando una de las opciones disponibles, y en caso de tener cupones canjearlos.
  • Comentarios y valoraciones de los usuarios, podría ser un buen reclamo tanto para nuevos comercios como existentes dándoles con ellas más visibilidad.
  • Recomendaciones a los usuarios según sus gustos, sus “reservas” realizadas (que serían subastas en nuestro caso), también bueno para los comercios que ofrecen el servicio a nivel visibilidad, y bueno para los usuarios ya que estás teniéndolo en cuenta al ofrecerle servicios que van con él.
  • Información/características relevantes del sitio.
Too good to go, Maybein y FlipEat
  • Lo que más me ha llamado la atención es que en FlipEat tienen hecha la integración con los softwares de gestiónCover Manager y Restoo”, lo cual permite detectar las mesas disponibles y realizar la reserva sin necesidad de que el restaurante tenga que realizar un desarrollo adicional.

_DEFINIENDO

Nuestro Usuario

Antes de elegir y desarrollar las funcionalidades de la app, vamos a definir un usuario sacado de toda esta investigación realizada, ponernos en sus zapatos nos hará ver todo el proyecto de una forma más clara y funcional.

Volviendo a la información proporcionada sobre el proyecto, detectamos dos user persona, por un lado están las empresas que serán las que publiquen sus servicios a subastar y por otro están los usuarios, clientes finales que serán los que pujen y compren esos servicios subastados.

En primer lugar tenemos a Marc, aquí mostramos su perfil, el cual nos ayudará a diseñar y desarrollar mejor las funcionalidades de la aplicación pertenecientes al perfil de empresa:

User Persona 1

Por otro lado tenemos a Amanda, que nos va a dar una visión más clara para el perfil de clientes finales de la aplicación:

User persona 2

Findings & Pain Points

Después de realizar el research y definir nuestro usuario ha llegado el momento de recapitular, tomar decisiones y seguir con el desarrollo del proyecto.

A través de la investigación hemos obtenido una serie de findings, los cuales van a definir el desarrollo del proyecto junto a los pain points de nuestro user Marc. Hemos decidido escoger solo a Marc porque a corto plazo nos interesa desarrollar primero el perfil de empresa.

  • Debe aparecer de forma clara las subastas en sus diferentes estados.
  • Agilidad a la hora de publicar una nueva subasta.
  • Tener un buen filtrado o categorización dentro de las subastas que tiene la empresa.
  • Alertas y notificaciones cuando haya una nueva actividad.
  • Poder publicar tanto una subasta como una venta directa.

_DISEÑANDO

Arquitectura de la Información

Antes de empezar a diseñar me gustaría hacer un recordatorio de los objetivos del UX, dentro del perfil de empresa, los cuales vamos a desarrollar:

  1. Pantalla de alta de la subasta
  2. Pantallas y sub-pantallas del mantenimiento de las subastas con el sistema de filtrado.
  3. Pantalla de la subasta con los detalles y las pujas realizadas.

Primero creamos un mapa del sitio, para tener una visión general de lo que sería el perfil de empresa dentro de la aplicación, su jerarquía y funcionalidades necesarias:

Sitemap

Dentro del perfil empresa, tenemos tres opciones: mis servicios, nuevo servicio y el perfil de la empresa con sus datos y configuración. Se ha optado por referirnos con un nombre genérico (servicios) ya que no solo tendremos subastas si no que incluimos también la opción de venta directa.

También en nuestro caso lo que vamos a desarrollar es lo que hemos destacado en el sitemap, por un lado el apartado mis servicios en los que encontraremos todas las subastas en sus diferentes estados (activas, finalizadas, cobradas…) con opción a búsqueda directa o filtrado, y también estarán las notificaciones, las cuales mostrarán las nuevas actividades que ha habido en la aplicación.

Y por otro, la funcionalidad de publicar nuevos servicios, la cual destacaremos en el centro del navbar, incluyendo en ella la opción de nueva subasta y la de nueva venta directa.

Flujos

Teniendo ya más claro el mapa del sitio, vamos a diseñar los diferentes flujos que necesitamos desarrollar:

Alta del Servicio

Desde el perfil de empresa veremos como Marc puede realizar de una forma ágil una nueva alta de un servicio, como mencionamos en el apartado anterior al hacer tag sobre nuevo servicio tendrá la opción de crear una nueva subasta o crear una nueva venta directa, ambas con sus características. Una vez introducida toda la información necesaria se publica para activar el servicio dentro de la aplicación.

Flujo alta nuevo servicio

Mis Servicios

A través de este flujo nuestro usuario Marc podrá acceder a cualquier servicio dado de alta, donde podrá buscar directamente o mediante filtros, según el estado del servicio.

En el listado de servicios se mostrará la información más relevante de cada uno, haciendo tag en cualquiera de ellos se podrá acceder a la ficha del servicio en la que incluiremos información más detallada sobre el mismo.

También se incluyen en este flujo las notificaciones, para que pueda ver las nuevas actividades que ha habido en la aplicación.

Flujo mis servicios, notificaciones y filtrado.

Wireframes

Ahora toca trasladar al papel y visualizar cómo serían esas secciones y flujos en pantalla. Para ello realizo primero unos wireframes a mano, de las secciones requeridas y los elementos necesarios:

Alta del servicio

En primer lugar tenemos un navbar, el cual al realizar el sitemap, nos dió las secciones que íbamos a tener dentro del perfil de empresa: mis servicios, crear servicio y mi perfil.

En este caso al hacer tap en crear servicio, aparecen dos opciones: dar de alta una subasta o una venta directa. Después sólo queda configurar las características necesarias para cada servicio, por ejemplo, en el caso de restaurantes poner el número de mesa o de comensales, determinar la puja de partida si la hubiera, al igual que la duración en el caso de tratarse de una subasta. Una vez todo correcto solo hay que confirmar dándole al CTA de crear alta.

Wireframes alta del servicio

Mantenimiento de los servicios

En este apartado tenemos la búsqueda directa y notificaciones, y todos los servicios organizados a través de un kanban, de esta forma puede filtrar según el estado del servicio: activo, finalizado o cobrado.

En este listado aparece cada servicio en una card, la cual distinguimos visualmente el lateral izquierdo con un color según su estado para facilitar esta información al usuario. A parte cada una en cada estado recoge una serie de datos:

  • Cuando está activo el servicio veríamos el estado con la fecha, la puja y el beneficio actual, algún dato relevante (por ejemplo la mesa y comensales en el caso del restaurante, o el asiento de un teatro), a su lado el tiempo restante del servicio si lo hubiera (en el caso de la subasta el tiempo que falta hasta finalizar), el número de ticket generado y un CTA con el que Marc puede finalizar la subasta cuando lo crea necesario.
  • Cuando está finalizado la diferencia a parte del estado es que la puja y beneficios que se muestran serían los totales obtenidos con este servicio subastado, y el CTA pasaría a estar inactivo.
  • Una vez el servicio finaliza se tiene que cobrar, para ello se añade el estado cobrado, donde Marc podrá ver si lo necesitara en el CTA cobrado una factura del servicio con todos sus datos.
Wireframes resumen, características y estado de los servicios.

Detalle de un servicio

Por último, para ver el detalle de cualquier servicio sólo tenemos que hacer tap en la card del mismo y pasaremos a ver todas sus características, como vemos a continuación:

  • Lo primero algunos datos del servicio, el estado, la duración y puja mínima, y el listado de pujas que se han realizado en el cual veremos el perfil de los usuarios como Amanda, con la fecha, la puja realizada y el beneficio que tendría el servicio.
Wireframe detalle del servicio.

Wireflows

A continuación vamos a ver los wireframes digitales y el flujo tanto del alta de un nuevo servicio como el listado de servicios y su detalle, con todos los elementos que nos encontramos en cada sección.

Primero vemos el flujo de alta de un servicio, en este caso una nueva subasta donde Marc podrá incluir todas las características necesarias. Una vez introducidas solo tiene que hacer tap en el CTA crear alta para cerrar el proceso.

Todos los servicios dados de alta se recogen en la sección de mis servicios, en esta sección Marc puede buscar directamente cualquier servicio o filtrar a través del kanban según el estado en el que se encuentren. También tiene el apartado de notificaciones con el que verá de forma rápida las últimas actividades realizadas en la aplicación, nuevas pujas, subastas finalizadas, servicios vendidos, etc.

En el listado de servicios vemos cada uno en una card, con las características más relevantes. Haciendo tap en cualquier card accedemos al detalle del servicio, donde a parte de información sobre el mismo, dispondrá de un listado de pujas con el perfil de los usuarios como Amanda, con la fecha e importe de la puja y el beneficio que obtiene con ella.

Wireflow

También aquí podemos ver los diferentes estados de la card del servicio: activo, finalizado y cobrado. En los servicios activos tenemos el CTA cerrar puja, con el que se puede cerrar el proceso de subasta en cualquier momento. Al igual que en los servicios cobrados nos encontramos con el CTA factura, con el que obtienen en caso de ser necesario, una factura de este servicio.

Estados card servicio

Framework

Este es mi espacio de trabajo en figma. Para realizar los wireframes digitales se ha trabajado con una grid de 8 puntos para organizar y jerarquizar todos los elementos de la mano de autolayout, componentes y variants con los que se manejan de forma más ágil los iconos y estados del navbar. También a la izquierda se puede ver todo el trabajo que se ha realizado con esta herramienta.

Framework

_Futuribles, ¿Qué se ha quedado en el tintero?

  1. Onboarding, añadir unas pantallas de inicio después de hacer login, para que muestren a nuestro usuario Marc las funciones principales de la herramienta, y conozca así qué acciones puede realizar en su primer contacto con la aplicación.
  2. Ranking Top del sector, se podría incluir un ranking con las empresas top del mismo sector o incluso un ranking de sectores.
  3. Integración de la app con el software de gestión de la empresa, para automatizar más el proceso de los servicios que se van a subastar o vender, facilitando a usuarios como Marc el uso de la aplicación.
  4. Comentarios y valoraciones de los clientes finales, también añadir una sección donde poder ver las valoraciones que hacen los clientes sobre la experiencia que han vivido. Con esta funcionalidad tendríamos las siguientes ventajas:
  • En el perfil de empresa, Marc podrá tener un feedback del servicio que está ofreciendo a sus clientes. También podrían gestionarse los conflictos si los hubiera o agradecer esos feedbacks de los clientes en la misma sección.
  • Conoceríamos mejor a los clientes finales como Amanda, podríamos hacerles recomendaciones según sus reservas, compras y valoraciones.
  • Esas recomendaciones nos ayudarían también a promocionar diferentes negocios, dándoles a conocer ya sean nuevos como existentes.
  1. Apartado de resumen del negocio, infografías con los servicios totales y sus beneficios, filtrados por fecha…
  2. Perfil del cliente final.

_Conclusiones

En conclusión, mis sensaciones con el proyecto son muy satisfactorias, ya que en un breve periodo de tiempo se han cumplido los objetivos, descubriendo a través de la investigación esas necesidades, resolviendo los pain points de nuestro usuario principal, y diseñando los wireframes y flujos principales que se requerían en este proyecto.

Desde el research hasta los wireframes digitales, ¿Cuándo acaba el diseño? A mi parecer o forma de entenderlo, el diseño es un trabajo infinito, siempre podemos mejorarlo y siempre podemos añadir nuevas funcionalidades que lo hagan cada vez más completo. Lo importante es saber con qué limitaciones contamos, sobre todo gestionar bien los tiempos de los que disponemos para realizarlo, priorizando ideas y/o funcionalidades como hemos hecho aquí.

¡Hasta aquí!

Espero que os haya gustado la resolución del proyecto. Si habéis llegado hasta aquí solo me queda daros las gracias por haberme acompañado en todo el desarrollo.

¡Nos vemos en el próximo! 💛

--

--

Laura CH

Product Designer · UX / UI · Audiovisual Designer