circle-loader

Pour rappel, la première partie de notre article traitait des notions d’UX et UI Design appliquées aux applications de MaaS. Dans cette deuxième partie, notre Lead Designer Igor a établi un comparatif poussé des UX et UI Design des différentes applications de mobilité, notamment intégrées à notre API MaaS. À savoir, la RATP, opérateur de transports en commun sur Paris. Trainline, revendeur de billets de trains et de bus macrons. LeCab, service de voiture avec chauffeur. Et enfin le service de trottinettes électriques Lime et OPnGO, service de réservation de parkings. Une analyse minutieuse, qui permettra à notre Lead Designer de concevoir et vous partager le prototype de son application MaaS idéale.

1. Définition du Business Plan

Une des premières choses à faire, résulte dans l’élaboration d’un cahier des charges. Un document dans lequel il est primordial de déterminer à la fois les objectifs, le contexte, les besoins, fonctionnalités, caractéristiques et contraintes de votre application de mobilité. Quels niveaux, évoqués dans la première partie d’article, souhaitez-vous atteindre dans votre application MaaS ? Votre solution permettra-t-elle la planification et réservation de trajets multimodaux ou intermodaux ? Pour rappel, l’intermodalité réside dans le fait d’utiliser plusieurs modes de transport sur un même trajet. Dans notre cas, nous allons partir sur l’élaboration d’une application MaaS intermodale.

La demande

Côté fonctionnalités, elle devra à la fois permettre à l’utilisateur la planification en temps réel ainsi que la réservation et paiement parmi cinq différents types et opérateurs de transport. À savoir :

  • Un opérateur de transport public (Metro/Bus/Tram), avec RATP
  • Le train et le bus avec Trainline
  • Un service de VTC et taxi-moto avec Le Cab
  • Un service de trottinettes free-floating proposé par Lime
  • Enfin, OPnGO un service de parking

Nous partons dans l’hypothèse que ces cinq fournisseurs de mobilité disposent d’ores et déjà de leur propre API. Ainsi, nous pourrons facilement intégrer et récolter en back-end leurs données de planification et réservation. Des données que notamment Lyko se charge de regrouper au sein d’une seule et simple API, regroupant près de 1200 services de mobilité.

banner_article_tech

Les fonctionnalités

À cette étape, il s’agit ici de définir les attentes de l’utilisateur. Quel est le rôle de notre solution ? Trajets du quotidien ? Trajet Domicile-Travail ? Longue distance ? Vacance ? Va-t-elle plutôt s’adresser à des citadins ou bien des personnes vivant en milieu rural ? Cette question soulève notamment le fait que dans ce dernier cas, l’usage de voiture est quasiment indispensable. Cela n’empêche en rien de concevoir une solution MaaS. Le véhicule doit être juste au cœur de notre offre intermodale. À cela découle également la question des applications et modes de transport préférés ?

Lyko, la boîte à outils du MaaS
Lyko, votre boîte à outils du Mobility as a Service (MaaS)

En effet, le principal objectif est de permettre à l’utilisateur de n’avoir recours qu’ à une seule application pour réserver tous ses besoins de transport. Tel un agrégateur ! En bref, l’expérience ultime relève donc d’une meilleure accessibilité de ces services, tout en apportant une personnalisation selon les besoins, l’environnement et le contexte d’usage.

Le Business Model

Commissions, abonnements, listing fees, frais de dossier … avant tout développement, il est important de définir votre modèle économique selon votre projet. En effet, la maintenance d’une application coûte de l’argent à long terme. Afin de générer des revenus additionnels, vous avez le choix de procéder à l’ajout de commissions sur chaque trajet. Variables et/ou fixes ? Par opérateurs ? On top ou pas ? Un tour d’horizon de ces possibles business models est primordial… Mais cela n’est pas le sujet de notre article, alors concentrons-nous sur le design de votre application MaaS.

2.Comparatif UX/UI Design des environnements

Comme expliqué dans la première partie, nous avons accentué le fait qu’il était primordial d’établir un contexte concret autour de notre application MaaS. Ceci dans le but qu’elle sache s’adapter à tout type de situation. En effet, la RATP, Trainline, LeCab, Lime et OPnGO diffèrent en terme de fonctionnalités. Nous n’avons pas d’autres choix que d’analyser, comparer et confronter consciencieusement ces applications, reposant sur leurs usages, fonctionnalités et étapes du parcours utilisateur. Pour cela, notre Lead designer s’est basé sur le principe de modularité de Steffen Schäfer, tiré de son article« MaaS Platform UX — How to Create Modular Flows ». Pour commencer, sur l’ensemble des cinq applications de mobilité choisies, trois grandes parties se dessinent. À savoir : L’avant, le pendant et l’après course.

  • Avant course, l’utilisateur passe par minimum sept écrans (page/étape) : L’accueil, la recherche, la sélection, la planification, la réservation, la vérification, le paiement et le déblocage si nécessaire.
  • Ensuite, le pendant course, rentre en compte la géolocalisation et navigation en temps réel.
  • Et enfin, l’après avec le résumé, la notation de la course et l’émission de la facture.

Il est important de préciser qu’un écran peut représenter plusieurs étapes, et inversement une étape peut contenir plusieurs écrans. Vous verrez sur nos schémas, que nous l’avons illustré par des encadrés verts. Les écrans rouges sont des écrans que nous n’avons pas pu récupérer. Toutefois, ils font bien partie de l’application. C’est parti ! Commençons donc avec LeCab.

LeCab | Service de VTC

Sur cette application de VTC, on remarque une grande fluidité du service. En effet, les étapes de sélection, planification et réservation sont regroupées au sein d’un même écran (cf. encadrés verts). Relevant du transport à la demande, l’expérience client se doit d’être le plus rapide possible. Il faut pouvoir réserver et payer en effectuant le moins de clics. C’est de l’achat immédiat et pour cela LeCab provoque une « pulsion rapide ». Ceci dans le seul but de faire comprendre à l’utilisateur que la course peut être réservée à tout moment. Ceci se traduit également par la mise en avant des informations personnalisées en temps réel, comme avec la géolocalisation du chauffeur le plus proche. Nous retrouvons cela également du coté de Lime, avec le partage d’informations concernant la position et l’état des trottinettes à proximité. L’utilisateur est informé en amont du niveau de la batterie, autonomie et paramètre de réservation ou la mise en place d’une sonnerie.

Lime | Service de trottinettes

Chez Lime, l’expérience utilisateur résulte dans la possibilité de déverrouiller et utiliser rapidement une trottinette en libre-service. Comme nous pouvons le remarquer, de la page d’accueil à l’étape de déverrouillage, le parcours utilisateur est plutôt simple et rapide. En effet, les étapes « Discovery », « Sélection » et « Réservation » sont regroupées sur un seul et même écran (cf. encadrés verts). La mise en place du QR code permet notamment de fluidifier cette expérience utilisateur. Expérience également limpide du côté d’ OPnGO via la norme Bluetooth.

OPnGO| Service de parkings

En effet, du côté de l’application de parking, votre portable a la possibilité de se transformer en véritable télécommande. En activant son Bluetooth, il est possible de déverrouiller les parkings qui en sont équipés. Dans d’autres cas, les parkings sont équipés de caméras en capacité de reconnaître votre plaque d’immatriculation. Cette dernière est notamment saisie lors de l’étape ci-dessous de « vérification », dans « Pre-Ride ».

Que ce soit par le regroupement sur un même écran des étapes de « Sélection » et « Réservation » ou encore la mise en place de systèmes de déverrouillage innovants, OPnGO a pour mot d’ordre d’alléger et fluidifier l’expérience utilisateur. Problématique également rencontrée du côté de la RATP, régie autonome des transports parisiens.

RATP | Service de transports publics

Planificateur d’itinéraire, il informe en temps réel l’utilisateur. Afin de proposer un voyage de bout en bout à l’usager, elle inclut également une billettique digitalisée et la possibilité de planifier un itinéraire à pied ou en vélo (via Vélib’). Le seul bémol étant la redirection vers Vélib’ lors du choix de ce service. Toutefois, important de rappeler qu’Île-de-France Mobilités a lancé le déploiement de son application MaaS regroupant l’ensembles des modes de transport disponibles sur la région. Elle comptera notamment la RATP et Vélib’. Pour en savoir plus, n’hésitez pas à lire notre article traitant de cette solution MaaS financée à hauteur de 40 millions d’euros.

Trainline| Service de trains et bus

Pour finir, zoom sur Trainline, application facilitant la comparaison et réservation de billets de train et de bus, dans toute l’Europe.

Comme nous pouvons le voir, dès la page d’accueil l’utilisateur a directement accès au moteur de recherche. Nul besoin de géolocalisation ou de « Map Over View » (carte de fond). En effet, dans la plupart des cas, les réservations ne relèvent pas d’un départ immédiat. L’utilisateur est souvent en phase d’anticipation et de procrastination.

Conclusion

En résumé, ce tour d’horizon des applications nous démontre l’importance de définir sa mission principale, afin de l’agencer en conséquence. Inutile donc d’alourdir son application avec des fonctionnalités futiles, il faut aller à l’essentiel. Ceci dans le but de fluidifier un maximum votre service. Mais se pose alors la question de savoir si le déploiement d’une application MaaS, résulte dans l’assemblage de toutes ces fonctionnalités ? La réponse est mitigée. D’un coté il est important d’identifier les fonctionnalités essentielles de chaque opérateur de transport. Ce seront clairement les piliers indispensables et structurels de votre application de mobilité. Néanmoins, il faudra sûrement réfléchir à réorganiser, ajouter, supprimer, améliorer ou repenser certaines fonctionnalités. Ceci dans le but qu’elles s’intègrent parfaitement au sein de votre solution MaaS.

3. Élaboration du squelette

Place maintenant, à l’établissement des zonings et wireframes. Ils ont pour but de définir l’emplacement de nos différents éléments. Afin de n’oublier aucune fonctionnalité essentielle, nous pouvons procéder comme ci-dessous. Les différentes fonctionnalités des applications ont été appliquées sur la base du trajet.

Pour commercer, lors de la sélection de l’itinéraire, on ne sélectionne plus un seul type de transport mais bien un itinéraire complet avec différents modes de transport combinés. Les écrans en surbrillance (symbole « attention ») signalent les écrans pouvant varier en fonction de l’itinéraire ou des transports choisis. Par exemple :

  • Pour les itinéraires incluant le train ou la location de parking. Une étape de « vérification » est nécessaire afin de demander des informations essentielles telles que le nom, prénom, âge, immatriculation, etc.
  • De même, pour les itinéraires comprenant la voiture personnelle. Une étape de « navigation » est nécessaire. Celle-ci remplacera alors l’étape de « visualisation ». Tel un GPS, la navigation comprendra un guidage vocal en temps réel. Ainsi, l’écran de visualisation ne donnera que l’aperçu de l’itinéraire dans son ensemble.
  • Pour les itinéraires incluant la trottinette ou la location de parking. Une voire plusieurs étapes de « déverrouillage » / « verrouillage » sont nécessaires afin de finaliser le service.
  • Enfin, les itinéraires incluant le VTC, une étape de « fin de trajet » est indispensable notamment dans le paiement de la course ou/et d’un pourboire.

Maintenant que nous avons posé les bases de notre application MaaS, il ne reste plus qu’à passer à la conception du prototype final. Pour télécharger les fichiers sources, en version .xd, c’est juste ci-dessous.

À découvrir: BP investit dans Whim l’application de « Mobility as a Service »

Tags:

Post a Reply

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *