Desarrollo de una app MaaS en el Grupo Ruiz

En julio de 2024 invité a Roberto Canales a un podcast. Estudiaba LEINN y quería poder preguntarles a personas con experiencia qué les había salido bien en sus empresas y, sobre todo, en qué se habían equivocado. Así empezó JuegoConSentido. En diciembre, al terminar mi proceso COP en LEINN, grabé un vídeo en el que contaba mi historia estudiando Aeroespaciales y LEINN y lo publiqué en mi red de contactos de LinkedIn.

Federico Caro, director de tecnología de Grupo Ruiz, había participado en JuegoConSentido unas semanas atrás. Vio el vídeo y me ofreció formar parte de un proyecto ambicioso de transformación tecnológica en Grupo Ruiz. Entre las cosas que me tocaría sacar adelante había una aplicación de transporte en Toledo, unos vecinos descontentos y un compromiso con la administración.

Este fue mi Proyecto de Fin de Grado en LEINN y voy a explicarte lo que aprendí diseñando desde cero un producto digital de unos 200.000 € de inversión y coordinando a más de 40 personas.

Una empresa familiar que quería triplicar su facturación

Cuando entré, Grupo Ruiz se había propuesto triplicar su facturación en apenas cinco años. Para una empresa familiar dedicada al transporte, crecer tenía mucho que ver con ganar concesiones: poder presentarse ante una administración y demostrar que éramos capaces de prestar un servicio mejor. El problema era que parte de la tecnología con la que trabajábamos tenía treinta años. Podíamos prometer información en tiempo real en una licitación; otra cosa era conseguir que el dato de un autobús llegase a tiempo y en condiciones al teléfono de un vecino.

Ahí se entendía la apuesta de Federico. Si éramos capaces de saber cómo funcionaba nuestra propia red y qué necesitaban quienes viajaban en ella, podríamos tomar mejores decisiones y llevarlas a la siguiente concesión. Y si una administración nos preguntaba qué sabíamos hacer, podríamos enseñárselo funcionando. Toledo era una buena ciudad para empezar precisamente porque allí ya se podía ver, con bastante claridad, la distancia que había entre lo que habíamos prometido y lo que estábamos dando.

Antes de encargar otra app, entender a quién le habíamos fallado

La aplicación se llamaba COPI, de «copiloto». El ayuntamiento esperaba un servicio accesible con horarios y posición de los autobuses en tiempo real. Por el camino habían cambiado personas y equipos sin que se traspasara bien el conocimiento de unos a otros. Había decisiones de diseño que costaba reconstruir y no estaba claro quién debía seguir una incidencia hasta que quedase resuelta. Teníamos que darle razones a alguien descontento para volver a confiar. Si saltábamos directamente a buscar desarrolladores, podíamos entregar simplemente una versión más moderna con los mismos errores.

Lo más útil que traía de emprender era una costumbre bastante poco tecnológica: antes de poner dinero en una solución, ir a entender al cliente. Aquí tenía que averiguar, además, quién era ese cliente. La administración contrataba el servicio, el Grupo lo operaba y quien decidía cada mañana si la aplicación merecía ocupar espacio en su móvil era el viajero. Me fui a entrevistar a quienes conocían el proyecto desde dentro y a contrastar sus explicaciones con la experiencia de los vecinos. Las analíticas nos permitieron comprobar hasta qué punto las quejas eran algo más que unas cuantas malas reseñas.

Analizamos 151 reseñas de las tiendas de Apple y Google y contrastamos lo que aparecía en ellas con un grupo de 32 vecinos voluntarios de Toledo. Había menús saturados, etiquetas que costaba interpretar, rutas incompletas y fallos al abrir o utilizar la aplicación en determinados teléfonos. Miramos también los datos de Google Play Console: casi la mitad de los usuarios activos diarios había sufrido algún fallo y, al distribuir actualizaciones, veíamos pérdidas de dispositivos. Desde dentro, una actualización significaba que el equipo había trabajado. Desde fuera podía ser el momento en que alguien decidía desinstalar el resultado de ese trabajo.

Al cruzar los testimonios entendimos por qué no bastaría con corregir los fallos más visibles. El ayuntamiento se jugaba la confianza del ciudadano; el Grupo necesitaba datos para mejorar sus operaciones y el viajero apenas tenía motivos para crearse una cuenta. Hasta que este último encontrase útil la aplicación, los otros dos seguirían sin conseguir lo que necesitaban.

El mejor Civitatis de Toledo

Una vez entendido el problema, nos hicimos una pregunta algo distinta: si consiguiéramos que la tecnología funcionase, ¿para qué querría alguien abrir nuestra aplicación antes incluso de saber qué autobús va a coger? En el equipo lo resumíamos así: montemos el mejor Civitatis de Toledo y ofrezcamos la mejor opción de transporte para llegar a cada experiencia. El cambio parece pequeño hasta que intentas dibujar la primera pantalla. Una app de transporte te pregunta adónde vas. La que imaginábamos podía ayudarte a decidir qué te apetecía hacer.

Imagina una pareja que se va de vacaciones a Canarias. Están en el hotel, tienen la tarde libre y todavía no saben qué hacer. Lo interesante para ellos sería descubrir un evento cercano, ver si pueden cenar después en un restaurante de la zona y reservar las dos cosas sabiendo cómo van a volver. Si el último autobús sale antes de que termine el concierto, ese detalle debería aparecer antes de pagar la entrada. Así entendíamos una app agéntica: que ayude a encajar un plan entero, con las preferencias y la decisión en manos de la pareja. El transporte pasa a ser el medio para disfrutar de la tarde. Y al vecino que vive allí todo el año también le sirve cuando quiere organizar un sábado distinto.

Esa era la dirección de COPI 3.0. Intentar venderla en Toledo mientras fallaba la consulta de horarios habría sido un disparate. Necesitábamos demostrar primero que podíamos dar un buen servicio con una versión intermedia: COPI 2.0 permitiría consultar líneas y paradas, comparar rutas y pagar desde el móvil. Los puntos de interés en el mapa, definidos con la administración, eran un primer paso hacia las experiencias. Así podíamos aprender si a alguien le interesaba descubrir un destino desde la aplicación antes de pedirles a comercios y restaurantes que se sumasen.

Qué tenía que resolver la primera versión

Mi primera entrega fue un documento de requisitos. «Mejorar la movilidad» expresaba una intención, pero a un diseñador le decía bastante poco. «El viajero puede seleccionar una parada, consultar el próximo autobús y guardarla para mañana» ya permitía dibujar una secuencia y, más adelante, probar si funcionaba. Revisamos qué exigía el pliego, qué había salido de las entrevistas y qué dependía de otra pieza. Mostrar la ocupación de un vehículo, por ejemplo, requería disponer del dato a bordo. Ninguna pantalla iba a resolver por sí sola la falta de un sensor.

Con esa definición podíamos presentar el alcance a dirección, acordar qué entraba en la primera entrega y trazar un calendario con Toledo como piloto. Había trabajo que queríamos mantener dentro del Grupo: decidir las prioridades, conocer la operación y responder ante la administración. Parte del diseño y del desarrollo se haría fuera. Making Science fue nuestro socio para el diseño de la experiencia y la interfaz (UX/UI), e IZERTIS para la arquitectura y el desarrollo de la aplicación.

Primero el recorrido, después la pantalla

Para entender qué es la UX, piensa en una tarea de YURNI: recargar una tarjeta. Antes de elegir colores hay que decidir por dónde entra el viajero, cómo reconoce su tarjeta, cuándo elige la recarga y en qué momento confirma la operación. Dibujamos esa secuencia con cajas y flechas. Si para saber cuánto va a pagar tiene que retroceder dos pantallas, hay algo que corregir. Y todavía cuesta lo mismo hacerlo que borrar una flecha.

Después convertimos cada paso en un boceto sencillo. Un boceto permite discutir dónde aparece el saldo; un prototipo, que enlaza varios bocetos, permite comprobar si alguien es capaz de encontrarlo. Esa diferencia explica por qué merece la pena probar algo que todavía parece inacabado. Steve Krug desarrolla una idea útil en Don’t Make Me Think: cuanto más esfuerzo dedica una persona a interpretar la interfaz, menos atención le queda para lo que había venido a hacer.

Para trabajar la accesibilidad fuimos a la ONCE y la codiseñamos con ellos. Piensa en esas dos cifras que aparecen al recargar: el saldo disponible y el importe de la operación. A simple vista puedes distinguirlas por la posición, el color o el tamaño. Pero si recorres la pantalla con VoiceOver, ¿qué oyes primero? ¿Queda claro cuánto tienes y cuánto vas a pagar? Había decisiones que en nuestra maqueta parecían resueltas porque todos la estábamos mirando. Trabajar con quienes iban a recorrerla de otra manera nos obligaba a hacernos mejores preguntas.

Y mientras en IT diseñábamos la experiencia con Making Science, nuestros compañeros de marketing trabajaban con otro proveedor en el cambio de marca de COPI a YURNI. Para el viajero todo eso iba a ser una sola aplicación. A mí me tocaba conseguir que el nombre que poníamos a una acción, el aspecto que le daba la marca y lo que realmente podía hacer el sistema contasen la misma historia.

Ahí estaba buena parte de la dificultad. Un viajero puede querer saber si en el próximo autobús quedan asientos libres. Diseño puede encontrar una forma estupenda de enseñárselo. Pero si ese autobús no dispone de la tecnología que mide la ocupación, ¿qué ponemos en la pantalla? Había que decidir qué podíamos prometer en la primera versión y qué tendría que esperar. Y tocaba decidirlo sin saber todavía si acertábamos: en cuanto dábamos una dirección, otras personas empezaban a dedicarle horas y la compañía, dinero.

Monedero de YURNI. En la primera pantalla eliges la tarjeta; en la segunda puedes revisar la operación antes de confirmarla. Fuente: presentación de YURNI, diapositiva 43.

Del autobús de Toledo a la nube

Para entender qué podíamos construir tuve que ir a Toledo y subirme a los autobuses. Desde un despacho es fácil dibujar una flecha entre «comprar billete» y «subir al bus». A bordo entiendes qué hay en medio: el viajero lleva el título en su móvil, pero quien tiene que reconocerlo es el equipo instalado en el vehículo. Me interesaba entender los dos lados de esa operación. De poco servía diseñar una compra comodísima si, al llegar a la puerta, el viajero no podía validar lo que acababa de comprar.

Con la UX y la UI definidas, quedaba decidir dónde iba a funcionar todo aquello. Podíamos alojar la plataforma en servidores propios del Grupo —lo que en tecnología llamamos on-premises— o apoyarnos en la nube. Toledo era la primera ciudad, pero el producto tenía que servir después en delegaciones con otras tarjetas, otros vehículos y otras formas de cobrar. No queríamos empezar otra aplicación cada vez que cambiásemos de ciudad.

Elegimos Google Cloud. Google era un socio tecnológico en la estrategia de transformación de la compañía y, con IZERTIS, diseñamos una arquitectura modular sobre esa base. La separación se ve en el dibujo: hay piezas distintas para el usuario, el monedero, los abonos y los billetes. Si una nueva concesión valida el billete de otra manera, podemos adaptar esa pieza y conservar el resto. La nube nos daba dónde desplegarlas; decidir bien qué hacía cada una era responsabilidad nuestra.

Arquitectura del entorno de desarrollo de Toledo. Las cuatro ramas centrales muestran cómo separamos las funciones que el viajero encuentra juntas en el móvil.

Dos horas con un viajero y un móvil sobre la mesa

Cuando tuvimos una primera versión que se podía usar, no quise repetir el error de COPI: habíamos pasado meses tomando decisiones sobre los viajeros y ahora les tocaba a ellos ponerlas a prueba. Volví a Toledo para entrevistar a usuarios reales. Reservaba dos horas por persona. Parece mucho tiempo para probar una app de autobuses, pero lo que más me interesaba de la primera parte de la conversación era que hubiese confianza. Si alguien pensaba que tenía delante al chico que había hecho la aplicación y que esperaba un cumplido, difícilmente iba a contarme todo lo que le molestaba.

Después les ponía el móvil en las manos. Ellos iban tocando y yo grababa y observaba las interacciones. Ahí cambiaban los papeles: yo conocía el recorrido que habíamos diseñado, pero me interesaba ver cuál elegían ellos sin que yo les señalase el siguiente paso. Al terminar les preguntaba qué sensaciones habían tenido y les pedía que puntuasen las dos aplicaciones, la antigua COPI y la nueva YURNI. Para quien quiera aprender a preparar una sesión de este tipo, Rocket Surgery Made Easy, de Steve Krug, explica muy bien el oficio de observar sin resolverle la tarea a quien prueba.

Los resultados me dieron una alegría enorme. En la valoración global, COPI quedó entre 4,5 y 5,5 sobre diez; YURNI, entre 8,5 y 9. Lo que más me gustó fue ver dónde apreciaban la diferencia: tanto la experiencia de uso como la fluidez pasaron de insuficiente a sobresaliente. En accesibilidad pasamos de bien a notable. Ese notable también merecía aparecer tal cual: habíamos avanzado y los usuarios todavía veían margen de mejora.

Esta es la diapositiva que presenté a toda la compañía a petición de Andrés Ruiz, CEO de Grupo Ruiz. Recoge las valoraciones de los participantes en las pruebas de Toledo.

La responsabilidad que me llevo

Empecé este proyecto al salir de una carrera en la que había aprendido a preguntar antes de construir. Lo que todavía no sabía era cuánto cuesta seguir haciéndolo cuando más de cuarenta personas necesitan que tomes una decisión para poder continuar su trabajo. Unas veces la respuesta estaba en una conversación con marketing. Otras, en la tecnología instalada en un autobús. Y alguna solo aparecía cuando conseguía callarme y dejar que otra persona usara el teléfono. Aprendí a distinguir cuándo me faltaba ir a preguntar algo y cuándo ya tenía información suficiente para decidir y hacerme cargo de las consecuencias.

Gracias a Federico Caro por invitarme a formar parte de aquel proyecto y a Andrés Ruiz por confiarme la oportunidad de contarle a toda la compañía lo que habíamos aprendido. Gracias al equipo de Grupo Ruiz, a nuestros socios de Making Science, IZERTIS y Google, a la ONCE y a los viajeros de Toledo que nos dedicaron aquellas dos horas. Cuando miré la tabla de resultados, lo que más ilusión me hizo fue reconocer todo ese trabajo en una experiencia que, para quien subía al autobús, por fin resultaba más sencilla.