As a reminder, the first part of our article focused on the notions of UX and IU Design applied to MaaS applications. In this second part, our Lead Designer Igor has established a detailed comparison of UX and IU Design of different mobility applications, especially those integrated in our MaaS API. Namely, the RATP, public transport operator in Paris. Trainline, retailer of train and bus tickets. LeCab, car with driver service. And finally, the electric scooter service Lime and OPnGO, a parking reservation service. A meticulous analysis that will allow our Lead Designer to design and share with you the prototype of his ideal MaaS application.
1. Definition of the Business Plan
One of the first things to be done is to draw up a set of specifications. A document in which it is essential to determine the objectives, context, needs, functionalities, characteristics and constraints of your mobility application. What levels, mentioned in the first part of this article, do you wish to achieve in your MaaS application? Will your solution enable the planning and reservation of multimodal or intermodal trips? As a reminder, intermodality resides in the fact of using several modes of transport on the same trip, whereas multimodality is the fact of using several modes of transport in alternation. In our case, we will start with the development of an intermodal MaaS application.
In terms of functionality, it will have to allow the user to plan in real time as well as to make reservations and payments among five different transport types and operators. These are :
- A public transport operator (Metro/Bus/Tram), with RATP
- Train and bus with Trainline
- A car and motorcycle-taxi with driver service with Le Cab
- A free-floating scooter service offered by Lime
- Finally, OPnGO a parking service
We assume that these five mobility providers already have their own APIs. This will allow us to easily integrate and collect their planning and booking data in the back-end. Lyko in particular, is in charge of gathering those data in a single and simple API, grouping together almost 1200 mobility services.
At this stage, it is a question of defining the user’s expectations. What is the role of our solution? Daily journeys? Home-to-work? Long distance? Holidays? Will it be aimed at city dwellers or people living in rural areas? These questions therefore allow us to adapt to the environment and the offer available to the user. For example, for a person living in a rural area, the use of a car is almost indispensable. However, this doesn’t mean that we can’t create a MaaS solution. The vehicle must be right at the heart of our intermodal offer. This can then lead us to look at the users’ preferred modes of transport as well as the mobility applications they already use.
Indeed, the main objective is to allow the user to use only one application to book all its transport needs. Like an aggregator ! The ultimate experience is therefore a better accessibility of these services, while providing customization according to needs, environment and context of use.
The Business Model
Commissions, subscriptions, listing fees, application fees … before any development, it is important to define your business model according to your project. Indeed, the maintenance of an application is expensive in the long term. In order to generate additional revenues, you have the choice to add commissions on each trip. Variable and/or fixed? By operators? On top or not (margin type commission)? An overview of these possible business models is essential… As we focus more on the design of the application, we recommend this article by Paul Meister for more information on MaaS business models.
2. UX/IU Design Environmental Comparison
As explained in the first part, we emphasized the importance of establishing a concrete context around our MaaS application so that it can adapt to any type of situation. Indeed, RATP, Trainline, LeCab, Lime and OPnGO differ in terms of functionalities. We have no other choice but to analyse, compare and confront these applications conscientiously, particularly with regard to their uses, functionalities and the user path. To do this, our lead designer used Steffen Schäfer’s modularity principle from his article “MaaS Platform UX – How to Create Modular Flows“. To begin with, there are three main parts to the five selected mobility applications. They are : Before, during and after the trip.
- Before the trip, the user goes through a minimum of seven screens (page/stage): Welcome, search, selection, planning, booking, verification, payment and release if necessary.
- Then, during the trip, takes into account the geolocation and navigation in real time.
- And finally, after, with the summary, the rating of the race and the issuing of the invoice.
By the way, it is important to specify that a screen can represent several steps, and conversely a step can contain several screens. On our diagrams, we have illustrated this with green boxes. The red screens are screens where we could not have access. However, they are part of the application. Here we go ! So let’s start with LeCab.
LeCab | VTC service
First and foremost, on this VTC application, we can notice a great fluidity of the service. Indeed, the steps of selection, planning and reservation are grouped together within the same screen (see green boxes). The customer experience, which is part of transport on demand, must be as fast as possible. It must be possible to book and pay with the fewest possible clicks. It is immediate purchase and for this reason LeCab causes a “fast impulse”. This is for the sole purpose of making the user understand that the race can be booked at any time. This also translates into personalized information being displayed in real time, as with the geolocation of the nearest driver. This is also the case with Lime, with the share of information on the position and status of nearby scooters. The user is informed upstream of the battery level, autonomy and reservation parameter or the setting of a ring tone.
Lime | Scooter service
At Lime, the user experience results in the ability to quickly unlock and use a self-service scooter. As we can see, from the home page to the unlocking stage, the user experience is quite simple and fast. Indeed, the “Discovery”, “Selection” and “Reservation” stages are grouped together on a single screen (see green boxes). The implementation of the QR code makes this user experience more fluid. OPnGO’s experience is also clear via the Bluetooth standard.
OPnGO| Parking lot service
Indeed, on the parking application side, your mobile phone can be transformed into a real remote control. By activating its Bluetooth, it is possible to unlock car parks equipped with it. In other cases, car parks are equipped with cameras capable of recognizing your number plate. The latter is captured during the “verification” step below, in “Pre-Ride”.
Whether by grouping the “Selection” and “Reservation” steps on the same screen or by implementing innovative unlocking systems, OPnGO’s watchword is to lighten and fluidify the user experience. This is also an issue for RATP, the Paris public transport authority.
RATP | Public transport
Route planner, it informs the user in real time. In order to offer the user an end-to-end journey, it also includes a digital ticketing system and the possibility of planning an itinerary on foot or by bike (via Vélib’). The only downside is the redirection to Vélib’ when choosing this service. However, it is important to remember that Île-de-France Mobilités has launched the deployment of its MaaS application, which brings together all the modes of transport available in the region. It will notably include RATP and Vélib’. To find out more, please read our article on this MaaS solution, which has been financed to the tune of 40 million euros.
Trainline| Train and bus service
Finally, zoom in on Trainline, an application facilitating the comparison and booking of train and bus tickets throughout Europe.
As we can see, from the home page the user has direct access to the search engine. No need for geolocation or “Map Over View” (background map). Indeed, in most cases, reservations are not immediate. The user is often in a phase of anticipation and procrastination.
To sum up, this overview of applications proved us the importance of defining its main mission, in order to arrange it accordingly. There is no need to burden your application with useless functionalities, you have to go to the essentials, in order to make your service as fluid as possible. But the question that arises is the deployment of a MaaS application resulting from the assembly of all these features? The answer is mixed. On one hand it is important to identify the essential functionalities of each transport operator. These will clearly be the essential and structural pillars of your mobility application. Nevertheless, you will certainly have to think about reorganizing, adding, removing, improving or rethinking certain functionalities. This in order to ensure that they are perfectly integrated into your MaaS solution.
3. Skeleton development
Now, let’s move on to zoning and wireframes. Their purpose is to define the location of our various elements. In order to never forget any essential functionality, we can proceed as below. The different functionalities of the applications have been applied on the basis of the route.
When selecting a route, you no longer select a single type of transport but a complete route with different modes of transport combined. The highlighted screens (attention symbol) indicate screens that may vary depending on the route or transport selected. For example:
- For itineraries including train or car park rental. A “verification” step is required to request essential information such as name, surname, age, registration, etc.
- Similarly, for routes including personal car. A “navigation” step is necessary. This will then replace the “visualization” step. Like a GPS, the navigation will include real-time voice guidance. Thus, the display screen will only give an overview of the entire route.
- For routes including scooter or parking rental. One or more “unlock” / “lock” steps are required to finalize the service.
- Finally, for itineraries including VTC, an “end of trip” step is essential, especially when paying for the ride or/and a tip.
Now that we have established the foundations of our MaaS application, all that remains is to move on to the design of the final prototype. To download the source files, in .xd version, it’s just below.