Rediseño de la app de las tarjetas de transporte de Madrid — NUDO

Alejandro Bonmatí
11 min readJul 7, 2018

--

Las bases del diseño

Esta es la segunda parte del estudio que tiene como propósito la investigación, la ideación y el prototipado del rediseño de la actual app para móviles que permite gestionar las dos tarjetas de transporte principales de la Comunidad de Madrid. Si quieres conocer los detalles de la primera parte puedes pinchar aquí.

Poniéndonos al día…

¿Cual es el propósito de nuestro proyecto? Rediseñar y mejorar la experiencia que tienen los usuarios de la app de las tarjetas de transporte de la Comunidad de Madrid (CAM) (“Tarjeta TP”).

Pero ¿qué significa mejorar la experiencia de los usuarios? Los usuarios sufren tanto problemas técnicos como de uso y necesitarían tener nuevas funcionalidades para que la app les resultase útil.

Y ¿cómo lo vamos a hacer para lograrlo? Hemos analizado las opiniones publicadas de los usuarios sobre esta herramienta, les hemos preguntado qué les molesta, qué cambiarían y que añadirían y hemos realizado la heurística de la app. Pasamos ahora a proponer soluciones y comenzar a implementarlas.

Y todo este esfuerzo ¿merece la pena? Sin duda. Somos cientos de miles los usuarios potenciales de esta aplicación, cuyo propósito no es otro que mejorar el acceso y funcionalidad de un servicio público.

Hoja de ruta

La lista de problemas es larga, muy larga. Aquí abajo figuran los principales problemas y peticiones que desde el diseño podríamos abordar para mejorar el servicio, detectados mediante heurística, netnografía y encuestas. Al lado, las acciones para lograrlo.

Mucho por hacer.

¿Cómo se han diseñado experiencias similares?

Centrando nuestro análisis en aquellas que permiten la consulta y recarga de saldo en las tarjetas, tenemos la app del Metro de Sevilla (Google Play 2,0). Esta app presenta en su home tres opciones: recarga, consulta de saldo e información sobre próximo tren. La opción de recarga redirige a la web del metro de Sevilla, desde donde puede realizarse la recarga, y la opción de saldo mantiene el flujo en la app, permitiendo añadir una tarjeta de transporte mediante su número de serie.

La del metro de valencia (Google Play 2,0), ofrece registro mediante usuario y contraseña y en la home posee un menu en la nav bar que contiene un icono para las tarjetas. Las tarjetas se añaden mediante su número o por NFC y el pago se realiza mediante tarjeta bancaria. Se proporciona una imagen de ayuda visual y un texto para el proceso de lectura de la tarjeta mediante NFC. La lectura posee un tiempo límite de espera a partir del cual salta un aviso de error. Los iconos son legibles e informativos y añade FAQ, contacto, condiciones de uso, un buscador y un canal de comunicación. En el momento de usarla, la app sufría un lag importante, aspecto que leyendo las opiniones de otros usuarios parece un problema generalizado.

De izquierda derecha, capturas de las apps del metro de Sevilla, el metro de valencia y del transporte público de Gipuzkoa.

La app oficial del transporte público de Gipuzkoa (Google Play 2,4) requiere de registro previo de la tarjeta de transporte mediante su número, DNI y contraseña. Sin embargo, este registro (y por tanto la recarga y consulta de saldo) solo puede llevarse a cabo en las tarjetas nominales. Una vez registrada la tarjeta es posible recargar y consultar el saldo y los movimientos. El pago puede hacerse con tarjeta bancaria dentro de la app. Sin embargo, algunos usuarios afirman en las opiniones de Google Play que es necesario acercarse a un cajero para llevar a cabo la recarga y que ésta solo puede hacerse previo registro de los datos bancarios en la app.

La app del CTA (Consorcio de Transporte de Asturias), permite registrar las tarjetas mediante su número, cargar abonos o tarjetas nominales y realizar el pago en la propia app mediante tarjeta de crédito o iuplay. Posee además una especie de chatbot para reportar incidencias. Carece por otro lado de información legal.

La app de la tarjeta Barik NFC del Consorcio de Transportes de Bizkaia (CTB) (Goole Play 3,4) permite realizar carga de saldo y títulos mediante el registro de la tarjeta mediante NFC y pagar con tarjeta bancaria y iupay. Posee también historial de viajes y saldo. Además, acaba de ser actualizada a la versión 2.5 a fecha de 21 de Junio (2018) y su servicio de atención al cliente responde a las comentarios de los usuarios en Google Play.

Saliendo de nuestras fronteras, en septiembre de 2017 se estreno la app para gestionar las tarjetas TFL Oyster y contactless del metro de Londres (Google Play 2,5). Al iniciarla, nos recibe un sencillo onboarding con las principales funcionalidades. Para acceder a la app hay que registrarse con usuario y contraseña y hacer lo propio a continuación con alguna tarjeta (ya sea Oyster o contactless). La app permite recargar con saldo o títulos de transporte. Permite también acceder al historial de saldo y viajes realizados. A destacar también, la tipografía, los colores y la composición de la app y los frecuentes mensajes e imágenes de ayuda. Aunque su nota en Google Play es baja y presenta numerosas quejas por parte de los usuarios, las funcionalidades, infraestructura y estrategia de la app y el sistema sin contacto de sus tarjetas de transporte (que se lanzo en 2003, casi 9 años antes que el de Madrid), los convierten en referentes mundiales cuyos avances ofrecen a desarrolladores y exportan a otras ciudades. Al igual que en la Barik NFC, su hilo de opiniones en Google Play está repleto de contestaciones a las quejas en español de los usuarios y la app recibe frecuentes actualizaciones (la actual es la versión 4.1 del 14 de junio de 2018). Estas actuaciones demuestran que estas dos apps tienen un claro compromiso por ofrecer un servicio de calidad.

Ha sido esta ultima (TfL Oyster), y en algunos aspectos la del metro de valencia y la Barik NFC, las que después de ver estas y muchas otras apps han inspirado el diseño de contenidos de nuestra propuesta. En lo que respecta a la TfL Oyster decir que compartimos con ella la visión que subyace a la arquitectura de contenidos y que sitúa al usuario en el centro de la experiencia. Del mismo modo, mencionar que nos ha sido de ayuda ver como las apps de los bancos ofrecen opciones y lidian con problemas similares a los nuestros a la hora de gestionar sus tarjetas bancarias.

De izquierda a derecha: las apps del Consorcio de Transporte de Asturias, de la Tarjeta Barik NFC y de la Tarjeta Oyster del metro de Londres.

En conclusión: los usuarios de Madrid no nos hemos vuelto locos. Casi al contrario. Ahí fuera, funcionando mejor o peor, las apps que se encargan de gestionar las tarjetas de transporte ofrecen las funcionalidades que demandan los usuario de Madrid y, de hecho, se podría decir que gran parte de ellas son un estándar.

A todo esto…¿Quién es el usuario?

Los datos más recientes a los que he podido tener acceso relativos a las tarjetas y los títulos de transporte son del año 2015. En esa fecha, la Tarjeta Multi aún no estaba en circulación y la TTP Personal, introducida en 2012, ya estaba disponible para todas las zonas y se había convertido en un estándar de uso.

En relación a los títulos de transporte, el abono de 30 días (título que se carga en las TTP personales) fue el título mayormente utilizado con un 72,2% del total. Este abono se utilizó mayoritariamente en el metro y en los autobuses de la EMT (71,2% en conjunto). Los abonos fueron vendidos prácticamente a partes iguales entre el metro (56,5%) y los estancos y puntos de venta autorizados (40,6%). La zona A (Madrid capital), con casi el 50% de los abonos, es la más vendida del abono normal.

En relación con el perfil de usuario, la última encuesta de movilidad que el CRTM tiene publicada en su web es del año 2014. La muestra comprende a 4899 personas de entre 14 y 80 años residentes en la CAM. Del mismo modo que ocurría con el uso del abono, los principales medios para desplazarse mediante transporte público son el metro y la EMT (69,77%). La encuesta encuentra que el transporte público es utilizado ligeramente más por las mujeres (58,9%) que por los hombres y que las edades están mayoritariamente comprendidas entre los 23 y los 64 años. Los desplazamientos se concentran entre las 8:00 y las 9:00 de la mañana y las 14:00 y las 20:00 de la tarde y se producen en mayor proporción dentro de la corona A de Madrid ( 68%). En cuanto al motivo del desplazamiento, el trabajo es el primero con un 41,2% y le siguen otros motivos (13,9%) y los estudios (12,8%).

Perfil usuario transporte público: alta representación de trabajadores y estudiantes de edades comprendidas entre los 23 y los 64 años, que se suelen desplazar dentro de la corona A de Madrid y que tienen predilección por el abono transporte/TTP.

Un rediseño con reglas

Diseñando para “todos”

Sin datos más concretos sobre el uso de la app, de la TTP o del usuario del transporte público en Madrid que los presentados más arriba, debemos considerar que el perfil de usuario es potencialmente muy variado y que, por tanto, nuestro diseño debe ser lo más inclusivo posible. Además, debemos tener en cuenta que se trata de un servicio público y que, por tanto, debe intentar mirar por el conjunto de la ciudadanía.

Aunque en nuestra propuesta solo se esboza un sencillo prototipo, sí queremos hacer hincapié en el hecho de que nuestro diseño incluye interacciones conocidas y opciones de accesibilidad (contraste visual, ayuda auditiva) que al menos apuntan en este sentido.

Diseñando dentro del actual sistema

Nuestro rediseño no intenta introducir cambios en el actual sistema de tarjetas y títulos y solo pretende ofrecer una solución para la gestión por parte del usuario de sus tarjetas, ya sea añadiendo funcionalidades extra o solucionando los problemas existentes. Por supuesto, este diseño se desarrolla sin ninguna de las limitaciones técnicas, de infraestructura, logísticas, económicas, legales o estratégicas (por mencionar solo algunas) a las que el CRTM estaría sometido para llevar a cabo un proyecto de este estilo.

Diseñando con un dispositivo en mente

Toda esta propuesta…¿para qué dispositivo está pensada? Para abaratar costes y tener acceso a los recursos del sistema operativo, nuestra sugerencia a nivel de desarrollo sería construir una app híbrida. La interacción y la apariencia bebe de las guías de estilo de Android o IOS, junto con otras que no forman parte de dichas guías pero que son comunes para los usuarios de aplicaciones móviles.

Los cimientos

Arriba hablábamos de los problemas y las soluciones que proponíamos para aliviarlos. Todas estas soluciones pretenden tener cabida en nuestra propuesta y tendrán más adelante su reflejo en el diseño visual pero, en lo que ahora nos toca, abordaremos como se integran en la arquitectura de la app.

Nuestra rediseño se diferencia de la actual app en nuestro enfoque centrado en el usuario.

En la imagen de abajo se muestra como la actual app se compone de cuatro opciones principales, una “rueda” de ajustes y un botón de ayuda en la top bar. Al margen de lo limitado de cada una de las opciones, creemos que el problema de esta arquitectura es que las funciones de la tarjeta no están centralizadas en un espacio. Por tanto, el objeto de la app (la tarjeta) queda deslocalizado, hecho que se acrecienta debido al propio flujo de la app; el apartado de “mis tarjetas” se mantiene vacío hasta la consulta del saldo de una tarjeta, momento en el que dicha tarjeta se agrega automáticamente a este apartado.

¿Qué caracteriza y diferencia a nuestra propuesta frente a la app actual? A nivel de arquitectura, nuestro enfoque centrado en el usuario.

La app es el vehículo para que el usuario se ponga en contacto con la tarjeta. Situar al usuario en el centro de la experiencia significa poner la tarjeta en el centro de la app y que constituya el elemento alrededor del cual gire el flujo.

Mapa de sitio. De izquierda a derecha, las pestañas principales de la home (mis tarjetas): sobre nosotros, localizador de puntos de información y recarga, calculadora de tarifas, ayuda, ajustes, historial de movimientos, dar de baja la tarjeta, consulta de saldo, recarga y un menú con otras funciones para la tarjeta (info de tarjeta, bloquear tarjeta, transferir saldo entre tarjetas y descarga de historial). Las primeras cinco opciones figurarían en un menú hamburguesa. Si deseas ver el mapa de sitio en su versión extendida puedes pinchar aquí

Este enfoque se puede implementar situando la tarjeta en la home (“mis tarjetas”) de la app y facilitando la realización de las dos funciones “estrella” de la aplicación: recargar y ver el saldo. Además, a través de la home sería posible acceder al resto de funcionalidades de la tarjeta que la gente demandaba en nuestro cuestionario (historial de movimientos, alertas o la posibilidad de eliminar o bloquear la tarjeta, entre otras). El resto de opciones no son el foco de la app pero son importantes y quedarían englobadas en el menú de la aplicación bajo un botón hamburguesa. Masivamente utilizado y fuertemente criticado por sus problemas de usabilidad, hemos optado por un menú hamburguesa:

  1. Parar no generar carga cognitiva, saturando la home con múltiples opciones sin jerarquizar, por ejemplo, usando una navbar o un un menú desplegable.
  2. Por considerar que da acceso a opciones que son secundarias y que no focalizan la navegación por la aplicación.

En cualquier caso, sería interesante testar esta opción de interfaz como solución a la arquitectura de la información.

Frente a la propuesta actual, el rediseño que proponemos:

  • Es más seguro porque necesita de usuario y contraseña para acceder.
  • Guarda la configuración para el usuario registrado la primera vez que se accede. Esto refuerza la conexión entre usuario y tarjeta (por ejemplo, los ajustes pasan a estar en el perfil de usuario).
  • Centra su atención en la tarjeta y en toda su actividad e información.
  • No necesita escanear o que se introduzcan los datos de la tarjeta cada vez que se quiere consultar o operar con ella. Por tanto, simplifica el flujo.

Situar al usuario en el centro de la experiencia significa poner la tarjeta en el centro de la app y que constituya el elemento alrededor del cual gire el flujo.

Arquitectura de la app actual (izquierda) frente a la propuesta rediseñada (derecha). Importante, hacer notar como el flujo de la app rediseñada se prioriza hacia la tarjeta y deja en un papel secundario al resto de opciones.

En el último acto…

… diseñaremos varios flujos de tareas de la app.

… generaremos y justificaremos una nueva identidad visual.

… realizaremos un test de usabilidad de un primer prototipo.

… introduciremos los cambios en nuestro prototipo, listo para ser iterado de nuevo.

Si te ha gustado el artículo, me haces feliz con un puñado de aplausos (50👏 serían algo increíble) ¡Seguro que así me animo a seguir escribiendo! Cualquier comentario será recibido con los brazos abiertos para seguir mejorando.

--

--