Mejorando un servicio de alquiler de bicicletas: un case study UX

Prototipando una nueva funcionalidad para Bicing

Mientras estudiaba en Ironhack realicé un proyecto enfocado en desarrollar una feature para un producto ya existente. En mi caso, el producto asignado era la app del servicio de Bicing en Barcelona, que permite a los usuarios usar bicicletas para desplazarse por la ciudad mediante el pago de una tarifa. La funcionalidad a añadir en la app, es la opción de reservar bicicleta en una estación y también un espacio para aparcar en la estación de destino.

En este artículo os detallo el proceso que seguí para realizar este case study. Así que espero que poder ayudar a otros estudiantes de UX a comprender este tipo de procesos.

0. Contexto y datos
1. Research e investigación: ¿cómo usan los barceloneses este servicio?
2. Acotando el problema
3. Ideando una solución: ¡la teníamos delante!
4. Prototipado y testeo
5. Next Steps
6. Aprendizajes

0. Contexto y datos

El briefing

La tarea asignada era añadir una funcionalidad a un producto ya existente, en este caso, la aplicación Bicing, para el servicio de igual nombre del Ajuntament de Barcelona. Para ello, tuvimos que enfocar la investigación para entender cómo los usuarios se desenvuelven actualmente sin dicha funcionalidad, y detectar problemas y necesidades en el servicio para implementarla correctamente.

Scope

Se nos pidió completar el proyecto en un plazo de una semana, así que tuvimos muy poco tiempo para planificar, investigar y saltar a la fase de prototipado.

Objetivos del proyecto

En mi caso, la funcionalidad a implementar era permitir al usuario poder reservar una bicicleta y también permitir que guardase un espacio para aparcar en el destino. Y además, hacerlo en un prototipo de alta fidelidad.

Cliente

Bicing es un servicio público disponible para los residentes en Barcelona. Lleva en operativo desde 2007, cuenta con unos 113,400 usuarios aproximadamente en este momento y gracias a él muchas personas se mueven a diario con agilidad por la ciudad.

1. Research: ¿cómo usan los barceloneses este servicio?

Enfoqué la investigación en aprender un poco más acerca del servicio, los usuarios y los problemas que tenían al usarlo. Para ello, llevé a cabo 10 entrevistas a usuarios de diferentes perfiles, una encuesta y documenté mediante estudios de uso y estadísticas sobre el servicio.

/1.1 Las entrevistas

Al inicio, el target de las entrevistas parecía demasiado amplio: Bicing es un servicio público disponible para cualquiera (siempre que sea residente). Aun así, conseguí entrevistar a 10 usuarios en activo de diferentes perfiles (edad, sexo, profesión, zonas de la ciudad).

Preguntas como “¿cómo ha sido tu experiencia con el servicio?” o “¿qué problemas has encontrado durante el uso?” resultaron triggers que fácilmente me brindaron opiniones muy claras (e incluso acaloradas) de las que recabar información para definir problemas clave.

Preguntas como “¿qué destacarías de tu experiencia con el servicio?” o “¿qué problemas has encontrado durante el uso?” me facilitaron entender cómo los usuarios viajan y se las arreglan cuando encontraban estaciones llenas, y determinar así patrones de comportamiento.

Hallazgos

Profundizando en los incidentes y problemas encontrados por los usuarios, se identificó rápidamente que se enfocaban mayoritariamente en dos puntos: el servicio físico (las bicicletas y estaciones) y la aplicación, donde el 100% de los usuarios entrevistados y encuestados expresaron haber tenido problemas más de una vez. Ningún usuario manifestó problemas con la web, proceso de alta o similares.

Sobre el servicio, las impresiones de los usuarios giraban en torno a la falta de mantenimiento de las bicicletas, como se había implementado el cambio a la nueva flota de bicicletas eléctricas y como muchas de ellas se encontraban con poca carga tras haber pagado para usarlas, problemas con los anclajes que derivan en llamadas al servicio de atención con disputas por cobros indebidos dado que la bicicleta no era reconocida por el sistema como “devuelta”…

Con respecto a la app rápidamente destacó que todos los usuarios la consideran poco fiable debido a la baja frecuencia de refresco para ver los datos de la cantidad de bicicletas o huecos en tiempo real, y por tanto la calificaban de poca utilidad. Otro aspecto a considerar es que algunas funcionalidades no se comprendían bien, como por ejemplo la función para planificar rutas. Por último, algunos usuarios (¡6 de los 10 entrevistados!) no conseguían reservar bicicletas correctamente dado que al tratar de usar esta funcionalidad, la aplicación se cerraba inesperadamente.

/1.2 La encuesta

La encuesta sirvió para contrastar cuáles de los problemas detectados en las entrevistas eran más comunes entre los usuarios, otros problemas diferentes, y cómo actuaban para conseguir igualmente sus objetivos. Con un total de 30 participantes, 23 usuarios respondieron que no conocían o eran incapaces de usar con efectividad la funcionalidad recién añadida* de reserva de bicicletas en estaciones. Siendo este el segundo motivo de desencanto en la interacción con la aplicación y el servicio, adelantado sólo por el mal mantenimiento de las bicicletas que encontraban.

*Aclaración: La funcionalidad que se me específico implementar ya existía pero no funcionaba correctamente y a algunos usuarios no les aparecía. Lo que daba a entender que se estaba implementando en el momento en que realicé este proyecto.

/1.3 Task Analysis — ¿Cómo se desenvuelven los usuarios con la app actualmente?

La acción para reservar es muy simple, y sólo puede realizarse si el usuario previamente ha hecho log-in en el servicio. Al pedir a los usuarios que realicen una reserva de bicicleta (realicé 5 task analysis), todos tenían claro cómo llevarla a cabo, pero pocos consiguieron ejecutarla correctamente por múltiples motivos: desde cierres inesperados, a mensajes y dialogs indicando que no se ha podido completar la acción. Esta situación deriva en que muchos se desplazan en persona a la estación para verificarlo y no usan la app, tal y como habían comentado otros usuarios en entrevistas y encuestas.

2. Acotando el problema

Atando todos los hallazgos, traté de definir el problema a través de los usuarios para así poder definir y diseñar la solución.

/2.1 User persona

A partir de la muestra de usuarios creé un user persona representativo de los usuarios del servicio:

/2.2 Problem Statement

Los usuarios de Bicing necesitan reservar bicicleta y parking porque cuando llegan no hay sitio, y les hace perder tiempo tener que desplazarse hasta otra estación.

/2.3 Analizando el user flow actual

En este vídeo vemos el userflow actual de un usuario que ya ha hecho log-in para reservar una bicicleta. Salta a la vista que el proceso es corto y muestra directamente a la cuenta atrás y el tiempo disponible para dirigirse a por la bicicleta.

3. Ideando la solución

Partiendo del flujo actual de la aplicación, me surgieron rápidamente y sin dificultad muchas ideas a modo de brainstorming… ¿Quizás sería necesario dotar al usuario con algo más de información durante el proceso? U otras opciones como mostrar el nombre de la estación en el momento de confirmar reserva, posibilidad de cancelación, ver el estado de la reserva de manera menos invasiva, capacidad de reservar un “combo” directo de bici y aparcamiento, aumentar el tiempo disponible de reserva…

Teniendo en cuenta todas estas ideas y los constraints actuales de la app, me puse manos a la obra para mejorar el flujo e implementar la funcionalidad de forma más cómoda a los usuarios.

4. Prototipado y testeo

Durante la fase de desarrollo, pasé desde un prototipo en baja fidelidad para testear el flujo básico del usuario, hasta un prototipo de alta fidelidad en el que ya trabajé los aspectos de UI de la solución. A continuación os muestro el trabajo realizado en cada una de las tres fases.

/4.1 Low-Fi

  • Realicé 5 tests en LowFi, en los que realicé 2 iteraciones.
  • Uno de los primeros cambios que implementé (por olvido) es que se debe estar logeado para mostrar ciertos acciones, como la de reservar.
  • El menú burguer de la izquierda está accesible en toda pantalla.
  • Cada estación tiene ficha con información detallada.
  • Big Learning: un prototipo en baja fidelidad no debe tener color.

/4.2 Mid-Fi

  • 2 tests realizados, con 1 iteración por medio.
  • Añadí la opción de reservar aparcamiento y bici por separado mediante dos botones diferentes
  • Añadí el nombre de la estación al reservar, para mejorar la usabilidad.
Proceso Low-Fi > Mid-Fi > High-Fi

/4.3 High-Fi

  • 3 tests realizados, 1 iteración.
  • Corrección de UX writing: clarifiqué algunos CTA.
  • Unifiqué los iconos para igualar a los existentes en la app.
Aquí podemos ver la funcionalidad implementada en la app.

5. Next Steps

En este sprint conseguí la meta del brief: implementar las funcionalidades de reserva de bicicleta y aparcamiento. Pero detecté otras ideas que ayudarían a mejorar la experiencia de usuario y que me gustaría poder implementar y testear en futuros sprints. Como por ejemplo…

-Crear una opción “reservar ruta favorita” que haga una reserva doble de bici y estación para un trayecto que realizamos con frecuencia.

-Integrar en el user flow la posibilidad de cancelar las reservas. De esta manera no obligamos al usuario a tener que esperar 5 minutos si por error no ha reservado en la estación que más le conviene o si simplemente ha cambiado de opinión.

-Integrar dentro del área de usuario la opción para consultar si tenemos alguna reserva en activo, dado que al ahora integrar dos tipos de reserva debemos clarificar al usuario estas dos opciones.

-¡Seguir iterando! Siempre podemos mejorar y seguir investigando.

6. Aprendizajes

/5.1 Documenta todo el proceso. Siempre.

SACA. FOTOS. DE. TODO. No cuentes con dejar post-its o anotaciones de tu fase de research en algún sitio y contar con que estarán para revisitarlas más adelante. Cada paso tomado durante el proceso deber ser documentado de manera sencilla y rápida: una foto clara y listo. ¿Y si para cuando necesites fotografiar todas tus notas alguien las ha quitado? Cuenta siempre con tener un back-up y no dar las cosas por sentado.

/5.2 Un Low-Fi es un Low-Fi.

No pierdas tiempo en los detalles si no son necesarios. El perfeccionismo está bien, pero sólo donde sea encesario. Perder tiempo en detalles de un prototipo de baja fidelidad sólo hará que tardes más en encontrar fallos, y la idea es fallar rápido, para detectar cosas a corregir.

/5.3 Tiempos, descanso y salud…

Tu cuerpo también es otra de tus herramientas de trabajo. Si no le das momentos de pausa y lo tratas como debes… no podrás rendir al 100% en el proyecto. Tenlo siempre presente.

/5.4 Cada proyecto es diferente…

Por lo que cada proceso es único. Las recetas exactas no existen y debes aprender a adaptar las herramientas de que dispones a las necesidades del proyecto.

Y si has llegado hasta aquí… ¡gracias por leer mi case study! Espero que te haya gustado y si te apetece compartir tu opinión o tienes algún comentario, ¡no dudes en compartir tu punto de vista!

A graphic designer, over here to learn (specially about UX/UI) and have fun!🤟🏻

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store