MaaS Platform UX — How to Create Modular Flows

An approach to ensure a scalable and consistent user experience across multiple mobility service providers

While we face a mobility landscape growing more complex every day, we witness a strong shift towards on demand mobility solutions. Car-, bike- and ridesharing come to mind, as well as ridehailing and the ongoing rise of micromobility services.

As a result the concept of Mobility as a Service (MaaS) emerged as an increasingly important solution to manage multi- and intermodal transport scenarios.

This article is for everyone interested and focused on UX design. It lays down an approach on how to integrate different mobility service providers into a MaaS platform. The outcome is a modular framework, which provides a scalable foundation for the integration of new providers while maintaining a consistent user experience.

The approach in this article is meant as a case study, including real rental flows of two vehicle sharing providers. All made decisions are exemplary to illustrate the single process steps.

Alright, so let’s begin. 🚀

So What is MaaS About?

First of all the MaaS concept is a user centric approach. It aims to offer tailored mobility solutions for the user to meet their current mobility needs.

To achieve this, it relies on the integration of different transport related services and offers access to them through a single interface. While we see different platform variants out there, a platform usually includes:

• Discovery
  overview of available options, usually supported by real time information
• Trip Planning
  a multimodal search for possible trips from A to B
• Booking/Payment
  necessary features to allow for direct booking and payment of the chosen option

To sum it up, a MaaS platform enables its users to retrieve all necessary information to compare current available mobility options, pick their preferred one and use it right away.

In essence, a MaaS platform setup allows to streamline the user mode choice.

The UX Challenge for MaaS Platforms

The MaaS concept also holds some tough challenges.

Since MaaS relies on integrating different mobility providers we face with every new integration or update the challenge to merge largely differing requirements into a design that allows a consistent user experience.

Further the integration-scope usually only allows to take in the core functionalities of a provider. Highly specific features (e.g. car2go offers a “radar feature” to automatically detect nearby cars) are often not realistic in terms of effort and technical feasibility.

In an ideal scenario we create a framework that reflects provider specific requirements; that is flexible enough to stay scalable; and provides a consistent user experience across multiple providers.

The Approach

So how to create such a framework? Since we want to achieve a scalable and consistent solution, we can start out our design process by identifying the common ground across providers.

To achieve this throughout the process we will identify and define dependencies between elements and flows. A good strategy is to continually examine which elements::

• are indispensable
• can be unified
• can be left out

In order to find those dependencies, we categorize, sort and reorder the original elements until we have a clear picture of their single building blocks.

This step results at first in a deconstruction of the original custom arrangement, which helps us to achieve the necessary flexibility for rebuilding them in a modular way. In total we can visualize it like this:

👉 In this article we will only take care of the modularization of flows.
In order to achieve a fully working modular framework, a similar process as described above applies to the modularizing content. This one will be featured in a follow up article.

The Process Steps

Regarding the modularization of flows, we can divide the above scheme into 4 parts:

1. We first gather all relevant requirements in an audit.

2. Then we categorize the custom flows to a level where similarities and dependencies between the different providers are clearly graspable.

3. From this point on, we are going to work out the common ground for the following steps by synthesizing the different flows into a single one.

4. Finally we modularize this created flow by applying different operations to unify the remaining elements where possible and make them more flexible in use.

The result will be a modular flow setup based on the original requirements of the providers.

How Does This Look for Real?

Case study time: Let’s assume we are at the brink of building a brand new MaaS platform. The platform will feature two mobility providers.

To illustrate the following process of integrating them into a modular framework, I picked out the rental flows of two vehicle-sharing providers. (The process is of course applicable to a far bigger range of providers and not bound to ride-sharing business models.)

Heads up, big pictures ahead 🤓

1 — Audit

Before we start with the integration, we need to take all relevant requirements into account. This step typically ends up with lists about use cases, features, available data (APIs), flows, style-guides etc. In our case, we start with a screen-by-screen overview of our two booking flows:

Car2go is a free-floating carsharing service. Within the operating area, users are able to select an available car, rent it out and park it at any location after finishing their ride.

TIER offers a similar approach but with e-scooters.

2 — Categorize

While it is easy to see that one flow consists of more steps than the other, we now need to find a way to identify the similarities between them. A good way to start is to look for categories which are valid for both flows.

Since we talk about mobility services, let’s start with these three basic categories:

• Pre Ride
  includes everything before a ride
• On Ride
  includes everything while we are on a ride
• Post Ride
  includes everything after we finished our ride

Without changing the order or number of screens we now see that car2go is requiring more interaction in the Pre Ride category.

This is nice, but we need to dig deeper to define what we want to keep and what can be left out. We can achieve a more detailed categorization by identifying single flow steps. If we do that, we might end up with something like this:

If we now look at our freshly sorted setup, it becomes clear that some steps are necessary for both providers whereas the majority is only required by a single provider. Also a single step can contain multiple screens.

3 — Synthesize

To push things further towards a modular framework, we now focus completely on the flow similarities between our providers. For this we take out the content of the screens for now and only keep one screen per step. Leaving the order and number of steps untouched, our comparison would then look as follows:

From this perspective we may consider the steps featuring both providers as mandatory, while the steps required by only one provider can be considered as optional.

Mandatory steps are always required, the need for optional steps depends on the provider.

In this sense and without being limited by content, we no longer need to talk about two flows, since their remaining properties can also be expressed within a single flow. Merging them together, we get something like this:

It is important to note, that this combined flow still contains all prior identified steps and screens. Also their order remains intact. The main difference of course that we now talk …well…about a single flow.

4— Modularize

The current level of abstraction exposes the common ground of our two initial flows. We can now examine further which dependencies are still required and apply various operations to increase and utilize the modularity.

👉 The application of the following strategies depends on the particular flow logic, as well as the modularity of content and functionality. The latter will be a topic in the follow up article.

Merge
If two (or more) steps or screens are compatible enough in terms of functionality and content, they can be merged.

While this is strategy usually reduces the overall length of a flow, it is important to keep a close eye on the flow logic.

Adapt
If the flow setup is not sufficient, we can add, change or take out new steps or screens.

This is especially true when new providers get integrated. If the requirements can’t be matched the process starts anew with an Audit.

Reuse
It is also possible to reuse the same kind of step or screen multiple times. As a result either new steps or screens get introduced or existing ones are replaced.

A Modular Flow

While applying those strategies we have to be aware that any further modularization needs to be continually evaluated against the initial provider requirements flow. Let’s see some examples for how those strategies could work for our modular booking flow:

Merge

• The categories Rate Trip and Trip Summary could be combined, since both offer optional content and functionality after the ride has ended. Let’s call the new one Options for now.
• If we think about using the Map Overview screen to handle the Selection of a vehicle, as well as the Reservation, we can combine them. While this behavior was already featured in the original car2go flow, this time we include also the requirements of the TIER flow.

Reuse

• We can take the just formed Options screen and reuse it to replace the categories Verification and End Rental. Since we don’t interfere with the flow logic and all those categories hold optional content and functionality.

Conclusion

The shown approach offers a way to integrate differing flows into a single modular flow. Highlighting dependencies and indispensable requirements, the process supports informed decisions on which elements are required and which can be left out.

Once established, a modular flow setup like this can serve as a foundation for a consistent user experience across multiple mobility service providers. Further it offers the necessary flexibility to add new providers and adapt existing flows to match new requirements and hence leverage the scalability of a MaaS platform.

But…Something is Missing 👀

Stay tuned for the follow up on how to modularize content and interactions to create a truly modular framework.