Users waiting at a station can oftentimes feel lack of control, anxiety and uncertainty. These are strong negative emotions, especially in areas with low public transport reliability. In this feature we sought to alleviate this pain by providing a sense of control, and enable users to track their line in real time.
One of the main pain points of users who use public transportation is the “lack of control”, this feeling is being felt especially during waiting times in which users have to wait passively for their line to arrive.
In extreme cases this can provoke feelings of anxiety and helplessness resulting from uncertainty, depending on public transport reliability. Therefore we sought to alleviate this pain by providing a sense of control and enabling our users to track their line in real time, see its progress on the map and eventually feel in control.
Because the feature was a byproduct of the homepage concept redesign, it was constrained in development scope, but laid the foundations for personalized experience and easier navigation
Due to the feature technical complexities, we held several meetings with the R&D teams to align both iOS and Android in order to provide a holistic approach that can be developed on both platforms as best as possible.
🛜 GPS Latency:
GPS data is refreshed every 10-30 seconds, depending on the operator and country. However, there’s signal latency caused by transmitting updates from vehicles to operators and then to us, this eventually impacts data accuracy. This latency, especially when involving government oversight in some countries, required attention.
⚠️ GPS Fluctuations & Signal Loss:
GPS data can fluctuate and signals may be lost due to factors like tunnels, underground routes, or dense urban areas. We had to take into account these signal losses as well.
❗ No GPS Data:
Some lines lack GPS signals, providing only real-time data without GPS information. This limits our ability to pinpoint their exact locations.
🤯 Data Overload:
Showing busy stations with multiple line-options can result in excessive data, posing challenges for easy data digestion. We needed to take the user context into account in order to provide a reduced amount of potential data.
📱 Global Entry Points:
Due to development costs, this feature had to be global and not limited to specific screens.
This posed the challenge of taking into account multiple entry points, each of which can have a different context.
Google
Google maps provides the option to see lines on the map, but only a handful of the upcoming lines. Overall they do a good job, but it’s hard to navigate between the multiple line options and it’s not obvious which line is operated by which operator, and requires a tap. In addition, multiple lines are hard to distinguish because of overlap in routes and operator colors.
Transit
Transit also does a good job, but the main problem is that the app only shows a specific line, and not multiple lines. In addition, it’s impossible to view line-live-locations for a specific station, and no additional data is provided.
Citymapper
Cityampper only shows the live location of one line at a time, and only on their “line screen”.
After reviewing current solutions of our competitors, we've concluded that a "global" feature that will be accessible from multiple locations in the app is the superior approach in Moovit's case, as it will be recognizable globally, the feature will behave the same regardless of where the user opened it therefore simplifying its learnability and interaction.
To provide real-time "live location", we've anchored the lines to the relevant station.
Using the station as the anchor enhances context, including arrival time predictions and station countdowns for each line.
We've sorted the lines from earliest to latest to provide a simple and easy to understand chronological order, and upon entry the default selected line is the earliest upcoming one.
🚏 1. Station (Azrielly station for example)
🚍 a. Lines (Lines 1, 601, 82, 51 etc...)
🚌 i. Line 1 arrives in 3 min
🚌 ii. Line 60 arrives in 6 min
🚌 iii. Line 82 arrives in 11 min
🚌 iiii. etc...
UI Design
Latency & Signal Fluctuations
The GPS data we receive from 3rd party operators is always 20s - 30s late, therefore I've added a "last updated" indication.
In case GPS updated more than 90 sec ago, we show a "problem" yellow indication, indicating that there is a medium problem.
In case GPS updated more than 5 min we show "critical" red indication, indicating a critical problem
This way we've defined a time-safety buffer of up to 90s in which we can say with high certainty where the line GPS is at, and to not mislead users with inaccurate data.
Visual Data Overload
In order to reduce the amount of visual noise, and help users digest the data shown easily, I've created a clear distinction between the "selected" and "unselected" line. The selected line and its route update with the operator color and corresponding stops, and all the rest are visually less prominent in a neutral color until selected.
In addition, the unselected lines' icons are colored with the operator color, this way we provide a hint of the "unselected" line operator, and visually emphasis the selected line to reduce cognitive load and increase focus.
Global Entry Points
I've used the native iOS "Modal Stack" component that can be opened anywhere in the app where there's a combination of line & station and provide an "additional layer" to keep current context instead of moving to a different screen entirely (on Android it was developed as a full screen due to dev cost).
In addition, where users open the feature from will affect the amount of potential lines that are shown, for example if a user enters the feature from an "itinerary", only the relevant lines for that itinerary will be shown, and not all lines of the station, therefore reducing the amount of potential data using relevant context.
The initial design was a "tooltip bubble" above the selected line in order to show arrival times, line information etc.
This would mean that navigating the different line options can only be done using the map.
Using only the map for navigation can be a difficult interaction for some users, users need to zoom in / out, locate the desired line and tap on it - all this can be a hard task.
Additionally, due to dev constraint the additional data position had to be in a static position instead of moving element.
For this reason I've used a card that contains the data, the card can be swiped right and left, navigating to later arrivals.
Now users are able to navigate both using the map (tapping on lines) and also with a card-swipe for later arrivals.
The card is always connected to selected line, and the default selection upon entry is the most upcoming line.
Placing the cards at the bottom had the advantage of being close to the thumb-zone, users could reach it easily, also as the information was an additional to the location on the map, it was optimal for it to be at in the periphery of sight and not taking too much attention in the center of the screen which where the “line icons” were.
🚧 Modified Service Alert
⏱ Real Time Data
⚠️ Route Deviation
(older design version)
Using semantic colors
The card provided the relevant information for the selected line, ie: arrival time, line number, alerts etc.
Because the feature gave a sense of “real world” view, meaning what the user sees is an exact representation of the real world, I’ve added an additional piece of information that didn’t exist prior, the “stops away” count that shows the amount of stops left until the line reached the relevant station.
Secondary cards data
The card's additional data is secondary in importance and can change by line (drop off only / detours / out of route etc.)
Because the data is secondary and varies, we've used a swap animation in loops to show the potential data.
🇮🇱 Israel
➡️ From Itinerary Screen
🇳🇱 Netherlands
➡️ From Line Screen
🇮🇹 Italy
➡️ From Stations Tab
Lines progress transition
In order to provide a sense of "live location" we've added transitions on the lines progress. This had the effect that the line is actually moving and users get a real world view. Keeping users engaged and feeling in control.
Station's Name
Stations names can be very long (for example "Central Bus Station - Tel Aviv Floor 7...") and this data can result in long strings of text, therefore we've added a fade-slide transition for the station name to keep its size in an expected range without breaking the UI-composition.
Long text transition example:
Initially the "live location" feature showed lines for up to 1 hour ahead, regardless of amount of lines.
Testing showed that it was high in battery consumption due to transition animations for lines on the map, calculating states and positions, and sometimes fetching too much data for trips up to 1 hour aheaed, all these resulted in high CPU cost and battery consumption.
Looking at the data showed that most users would only interact with the most upcoming 1-4 lines.
Taking this into account, and to save the users' phones battery, we've limited the amount of potential "live locations" lines to 20, which saved battery drainage and kept a balanced amount of lines on the map.
By providing real-time line-tracking we've addressed the negative feelings that can rise in waiting times, increased users sense of control, increased users trust and as a consequence significantly improved retention, significantly improved subscription conversion when promoted (compared to other feature-promotions), therefore exceeding initial KPIs goals.
Long term testing showed that users who experienced the feature had:
✅ Increased retention by 92%
✅ Increased subscription conversion rate by 152%
✅ One of the highest usage time in the app - 45 seconds
KPIs improvements:
🤳
Average usage time
🥳
Improved user retention
🚀
Improved subscription conversion rate
The live location feature had tremendous positive effects for both users and Moovit.
It improved retention by 92%, increased subscription conversion rate by 152% when promoted in the subscription screen, had a 45 seconds average using time which increased session-duration and therefore ad-exposure and revenue - All while providing tremendous value for both the users and the business.
The feature has been so successful that it it's now provided only for subscribed users, and is the leading-promoted feature when subscribing to premium plan.
This was a journey of 5 months of planning, testing, designing, developing iterations that were the result collaboration of design, product, data and R&D coming together for a unified goal.
Additional Links:
