Smart Cards Case Study
Feature showcase
Production screen recordings
Tapping & Interaction
1. Intro
During a major project at Moovit, I was assigned the task of conceptualizing a new homepage design. The concept focused significantly on personalization which was lacking at the time, as a result the "smart cards" feature was born, which greatly enhanced the user experience and had a positive impact on the business.
To ensure the concept aligned with existing user behavior, I analyzed data from current user interactions, identified key touch-points with significant implications for the user experience, and devised strategies to improve upon existing app interactions.
Prior to the concept, we introduced a new consumer advertisement business model, which positively influenced the company's revenue. Therefore, I recognized the importance of providing substantial value to users while maintaining alignment with business objectives during the homepage concept redesign.
To ensure the concept aligned with existing user behavior, I analyzed data from current user interactions, identified key touch-points with significant implications for the user experience, and devised strategies to improve upon existing app interactions.
Prior to the concept, we introduced a new consumer advertisement business model, which positively influenced the company's revenue. Therefore, I recognized the importance of providing substantial value to users while maintaining alignment with business objectives during the homepage concept redesign.
2. Starting Out
what do know about our users
Prior to the homepage redesign process, we’ve collected data that gave us insights on the behaviors of our users.
We looked for patterns-of-use of users who showed increased retention, increased sessions, increased session-duration and also repeated engagement.
There were several statistics we had found particularly interesting that had major positive impact on the experience, and in the process also effected the design, and these are:
1. Favorite locations:
Users who had previously saved favorite location (such as “Home / work / school”) or favorite station / line were far more likely to return to the app and showed increased engagement. “Home” as a favorite had the most positive impact.
2. Visiting inner screens:
Users who visited inner screens of the app (such as “Itinerary-screen / station-screen / line-screen” (needed?)) all showed increased retention and engagement.
3. Line View screen:
Out of all the inner screens that had positive impact, there was one who stood out above the rest: the “line-view screen”. Users who had visited this screen showed the highest scores of retention and engagement.
4. Using “Recent searches” for faster navigation:
Oftentimes users were not manually adding favorites and would just use their “recent activity” as a means to get quick access to their desired locations.
These aspects had to be taken into account, all while keeping in mind our new business model of the consumer advertisement.
We looked for patterns-of-use of users who showed increased retention, increased sessions, increased session-duration and also repeated engagement.
There were several statistics we had found particularly interesting that had major positive impact on the experience, and in the process also effected the design, and these are:
1. Favorite locations:
Users who had previously saved favorite location (such as “Home / work / school”) or favorite station / line were far more likely to return to the app and showed increased engagement. “Home” as a favorite had the most positive impact.
2. Visiting inner screens:
Users who visited inner screens of the app (such as “Itinerary-screen / station-screen / line-screen” (needed?)) all showed increased retention and engagement.
3. Line View screen:
Out of all the inner screens that had positive impact, there was one who stood out above the rest: the “line-view screen”. Users who had visited this screen showed the highest scores of retention and engagement.
4. Using “Recent searches” for faster navigation:
Oftentimes users were not manually adding favorites and would just use their “recent activity” as a means to get quick access to their desired locations.
These aspects had to be taken into account, all while keeping in mind our new business model of the consumer advertisement.
3. What problems are we solving?
Personalized Experience
Up until this point, the Moovit app had a passive approach and was not actively reacting to the user’s actions and the user’s context in order to provide a personalized experience.
This passive approach resulted in high-friction when using the app. The app didn’t anticipate users’ needs and intentions in order to provide a smoother experience, and for a utility app this was crucial.
Therefore the new homepage concept with the “smart cards” feature laid the foundations for personalization.
This passive approach resulted in high-friction when using the app. The app didn’t anticipate users’ needs and intentions in order to provide a smoother experience, and for a utility app this was crucial.
Therefore the new homepage concept with the “smart cards” feature laid the foundations for personalization.
Discoverability and smoother navigation
Based on our understanding of our users, including what contributes to their satisfaction and easier navigation ie: having at least one favorite for easier search.
What adds value and motivates to repeat engagement such as experiencing inner screens.
And what improves users’ retention the most (experiencing the "Line View screen") it became apparent that our users were experiencing high friction with navigating the app in order to achieve these objectives.
Because this feature was a byproduct of the homepage redesign, we couldn’t do a complete overhaul, therefore this was a step towards improving the discoverability and navigation.
What adds value and motivates to repeat engagement such as experiencing inner screens.
And what improves users’ retention the most (experiencing the "Line View screen") it became apparent that our users were experiencing high friction with navigating the app in order to achieve these objectives.
Because this feature was a byproduct of the homepage redesign, we couldn’t do a complete overhaul, therefore this was a step towards improving the discoverability and navigation.
4. Goals
By providing a personalized experience that adapts to the user needs and context we’ll be able to meet the goals which are to improve discovery and navigation of the app and to provide value through personalization that was missing up until this point.
Each user should receive an experience that adapts to their way of navigating the public transport domain. Because using public transportation is different by countries and even by cities of the same country, depending on infrastructure, traffic, roads, accessibility, reliability and ease of use, the experience shouldn’t be a “one size fits all” therefore it has to adapt accordingly.
Each user should receive an experience that adapts to their way of navigating the public transport domain. Because using public transportation is different by countries and even by cities of the same country, depending on infrastructure, traffic, roads, accessibility, reliability and ease of use, the experience shouldn’t be a “one size fits all” therefore it has to adapt accordingly.
5. Challenges ahead
One of the challenges with data-heavy systems is how do we navigate the data in an intuitive way without feeling overwhelmed? The data-set users interact with on public-transportation is highly-variable changing arrival time, additional line updates, route changes etc...
Therefore we need to provide the right amount of data in each step in order to help users make a decision, without feeling overwhelmed and experiencing “paralysis of analysis” - balance is key.
Up until the introduction of the “smart cards”, the ruling mindset was to give the users the raw data, unfiltered and unrefined, leaving them to sort out what to do with it. This eventually led to two core problems:
1. High friction usage
2. Data overload
These problems had to be taken into account.
Therefore we need to provide the right amount of data in each step in order to help users make a decision, without feeling overwhelmed and experiencing “paralysis of analysis” - balance is key.
Up until the introduction of the “smart cards”, the ruling mindset was to give the users the raw data, unfiltered and unrefined, leaving them to sort out what to do with it. This eventually led to two core problems:
1. High friction usage
2. Data overload
These problems had to be taken into account.
6. What do our competitors do?
Google maps
Google maps does offer some suggestions, but they are hidden under drawer and are not public transport related. In a separate tab there are options to pin trips, but only after signup
Transit
Transit do suggest nearby lines, but in a very crowded and hard to digest manner and only for lines around the user.
Citymapper
Citymapper doesn’t suggest at all and personalization has to be manually configured.
7. Mapping the data users interact with
Data structure
The data set that users interact with on public transportation is:
1. Destinations (to get to a destination the user needs a route)
a. Routes (a route consists of walking / commuting /waiting legs etc..)
2. Stations (Bus station / metro station... Each station has lines)
a. Lines (Line 1, 238, 501... Each line has trips)
i. Trips (a trip has a destination and a time. Example: line 1 to Tel Aviv at 10:07)
*Note: this is a general structure. There can be also additional sub-data set such as line-updates, arrival times, route changes, payments etc.
1. Destinations (to get to a destination the user needs a route)
a. Routes (a route consists of walking / commuting /waiting legs etc..)
2. Stations (Bus station / metro station... Each station has lines)
a. Lines (Line 1, 238, 501... Each line has trips)
i. Trips (a trip has a destination and a time. Example: line 1 to Tel Aviv at 10:07)
*Note: this is a general structure. There can be also additional sub-data set such as line-updates, arrival times, route changes, payments etc.
8. Discovery process
Identifying challenges with existing design
New concept in the right direction
The initial concept was to solve the problem of personalization and therefore improve the navigation by creating suggestion-based offers based on the user’s current location, favorite locations and favorite stations / lines and the current context.
The idea behind this was that the suggestions will act as a starting point to smooth the navigation towards inner screens and will change depending on location and context.
This was a step in the right direction but it was a partial solution because in order to enjoy the full potential of it, users had to first define their favorite locations, and we knew that a significant portion used the “recent activity” in order to navigate.
In addition, requiring users to add favorites was adding another sort of friction that we were trying to eliminate.
The idea behind this was that the suggestions will act as a starting point to smooth the navigation towards inner screens and will change depending on location and context.
This was a step in the right direction but it was a partial solution because in order to enjoy the full potential of it, users had to first define their favorite locations, and we knew that a significant portion used the “recent activity” in order to navigate.
In addition, requiring users to add favorites was adding another sort of friction that we were trying to eliminate.
Removing the steps needed to get to these screens created a different problem: Which itinerary / line / station?
9. Solution: Predicting users’ needs
A shift in mindset
Since different users use Moovit in different ways according to their needs and habits, we needed to find a personalization mechanism that will suit these types of behaviours, all while being flexible enough for future modifications.
The solution was based on the former idea of suggestion-based offers, and in order to add value with minimal friction, the suggestions will be curated by taking into account 3 variables:
1. Current user location
2. Pattern of use (searched locations + favorites)
3. Time of day
The model was specifically designed to take advantage of existing user data points (such as past searched locations, favorite stations and lines) so users didn’t need to actively set their “Home” or “Work” or other favorite locations to receive predictive suggestions.
These variables were synthesized together to provide the most accurate suggestive result, tailored specifically for each user based on the user’s actions.
The solution was based on the former idea of suggestion-based offers, and in order to add value with minimal friction, the suggestions will be curated by taking into account 3 variables:
1. Current user location
2. Pattern of use (searched locations + favorites)
3. Time of day
The model was specifically designed to take advantage of existing user data points (such as past searched locations, favorite stations and lines) so users didn’t need to actively set their “Home” or “Work” or other favorite locations to receive predictive suggestions.
These variables were synthesized together to provide the most accurate suggestive result, tailored specifically for each user based on the user’s actions.
Conceptualizing suggestions
Building on the structure of the information users interact with, I started experimenting with ways of presenting the suggested data through a series of cards.
Each card had a unique goal and information, that was determined by the the context of the user.
Each card had a unique goal and information, that was determined by the the context of the user.
Experimenting with different types of data
Route based card
This was supposed to resemble the route itself. It looked good if there’s 1-2 lines, but more than that information couldn’t fit. From our testing on users, it wasn't immediately understandable that this was a route.
In addition, oftentimes there were multiple line options for the same leg, therefore this approach wasn’t ideal.
In addition, oftentimes there were multiple line options for the same leg, therefore this approach wasn’t ideal.
Station based card
This was the initial direction for a station based card.
Lines in different parts of the world could have different properties therefore this card’s height had to take that additional information into consideration.
Lines in different parts of the world could have different properties therefore this card’s height had to take that additional information into consideration.
Cards based on current app's state
Example: While live navigation is on.
Cards based on user prompts
Example: These were prompts to action in that were in the roadmap.
Interaction
For the interaction I decided to use an horizontal scroll in order to show multiple options at a specific area, without overloading the user with data.
The original design had each following card slightly visible so the affordance of horizontal scrolling would be stronger, due to dev constraints this was not implemented on iOS (only on Android).
The original design had each following card slightly visible so the affordance of horizontal scrolling would be stronger, due to dev constraints this was not implemented on iOS (only on Android).
8. Finalizing UI
Because the feature was a byproduct of the homepage concept and also taking into account development costs, it was decided to continue with 2 types of cards which were the “Route based card” and the “station based card” to test the feature’s efficacy.
Taking into consideration the amount of data the user has to digest and the addition of these suggestions, which by themselves were adding an additional cognitive load. Users might ask, “What is this? Why am I seeing this? Is this even relevant for me?” this will be the first thing users will see when opening the app, space was limited.
Therefore in order to get the user’s attention without data overload I aimed for simplicity and to give the user the minimal amount of data that will still act as a starting-point in.
Taking into consideration the amount of data the user has to digest and the addition of these suggestions, which by themselves were adding an additional cognitive load. Users might ask, “What is this? Why am I seeing this? Is this even relevant for me?” this will be the first thing users will see when opening the app, space was limited.
Therefore in order to get the user’s attention without data overload I aimed for simplicity and to give the user the minimal amount of data that will still act as a starting-point in.
Cross app consistency
In suggested routes:
In stations tab:
Final station & route based cards UI
Without line breaks (majority of cases)
In case of long text with line-breaks
Cards Anatomy
10. “Card card on my wall, who’s the most relevant of them all?” Creating the card-scoring mechanism
User location x Pattern of use x Time of day = card
In order to show the most accurate card for each user context (her current location, the time of the day and her pattern of use), we created a card scoring mechanism that will take these 3 variables into account.
1. If it is evening (after 12pm) and the user has set "Home" as a favorite location, but is not nearby (within 400 meters):
→ Show a card suggesting a route "To Home".
2. If it is morning (until 12pm) on a working day (depending on the region) and the user has set "Work" as a favorite location, but is not nearby "Work":
→ Show a card suggesting a route "Work."
3. If the user has a favorite station and is within a proximity of 2km from their current location (if multiple stations meet this condition, prioritize the two closest ones):
→ Show details of the favorite station, including upcoming lines.
4. If the user has recently planned a trip on the same day within a similar time range (plus or minus 2 hours from the current time), and the destination is not close to the user's current location (within 400m):
→ Show a card suggesting a route to that destination.
5. If the user has made a recent trip plan within a similar time range (plus or minus 2 hours from the current time), consider the most recent trip plan that fits the time range and where the destination is not within 400m of the user's current location:
→ Show a card suggesting a route to that destination.
Fallback: If no data is available regarding the user's usage patterns, display the closest station to the user. No close stations available? Omit the card section.
The idea behind these was to try and tap in to existing user routine, and provide suggestions based on the user’s past searched locations and patterns of use, taking into account the time of day the user opened the app.
1. If it is evening (after 12pm) and the user has set "Home" as a favorite location, but is not nearby (within 400 meters):
→ Show a card suggesting a route "To Home".
2. If it is morning (until 12pm) on a working day (depending on the region) and the user has set "Work" as a favorite location, but is not nearby "Work":
→ Show a card suggesting a route "Work."
3. If the user has a favorite station and is within a proximity of 2km from their current location (if multiple stations meet this condition, prioritize the two closest ones):
→ Show details of the favorite station, including upcoming lines.
4. If the user has recently planned a trip on the same day within a similar time range (plus or minus 2 hours from the current time), and the destination is not close to the user's current location (within 400m):
→ Show a card suggesting a route to that destination.
5. If the user has made a recent trip plan within a similar time range (plus or minus 2 hours from the current time), consider the most recent trip plan that fits the time range and where the destination is not within 400m of the user's current location:
→ Show a card suggesting a route to that destination.
Fallback: If no data is available regarding the user's usage patterns, display the closest station to the user. No close stations available? Omit the card section.
The idea behind these was to try and tap in to existing user routine, and provide suggestions based on the user’s past searched locations and patterns of use, taking into account the time of day the user opened the app.
Examples around the world
Madrid
Rome
Paris
Sao Paulo
11. Battery optimization
Refresh
In one of the conversations I had with R&D, we’ve found out that in order to save the user’s battery, we needed to add a “refresh option”.
Moovit’s users can be on the move and change their current location every second, they can be riding the bus, take the metro, walk to a station - and in order to not drain the phone’s battery on every GPS update, we added a manual “refresh”.
Fresh data will still be generated each time the users opens the app, this way GPS sampling will not drain the battery too much.
Nevertheless, we cannot expect all users to manually refresh, therefore we opted for an automatic refresh every 2 minutes of usage. This way users will still receive updated data without draining the battery but still be able to manually refresh
Moovit’s users can be on the move and change their current location every second, they can be riding the bus, take the metro, walk to a station - and in order to not drain the phone’s battery on every GPS update, we added a manual “refresh”.
Fresh data will still be generated each time the users opens the app, this way GPS sampling will not drain the battery too much.
Nevertheless, we cannot expect all users to manually refresh, therefore we opted for an automatic refresh every 2 minutes of usage. This way users will still receive updated data without draining the battery but still be able to manually refresh
12. Improving understandability - 2nd iteration
We’ve initially tested this feature on iOS users only. After releasing the feature we’ve found out something very interesting that we needed to take care of.
Users understood they were getting suggestions based on their activity, but they didn’t understand what some of the suggestions were.
Users understood “Home” or “Work” trip suggestions and Favorite station suggestions, but they didn’t understand all the other suggestions such as a suggestion to a frequently searched destination.
Users understood they were getting suggestions based on their activity, but they didn’t understand what some of the suggestions were.
Users understood “Home” or “Work” trip suggestions and Favorite station suggestions, but they didn’t understand all the other suggestions such as a suggestion to a frequently searched destination.
Second iteration
There were 2 problems of the first iteration:
1. The section-header “Suggestions for you” was too vague and only explained the section’s content. Because users needed to understand not just the given suggestions, but also why these suggestions were even given in the first place.
2. Scrolling affordance. Because of development costs we didn’t implement the “Peeking card” affordance. This hindered users understandability of swiping.
Therefore, in order to explain what each suggestion was, I added a small title at the top of each card. This had 2 benefits, the first was being card-specific that explained it’s content more specifically.
The second benefit was because each card now has a title of its own, there was no need for an additional section-title as a whole, therefore saving space.
In addition, to distinct the overall section and it’s different interaction, I added a background to the section, to emphasize its distinct interaction as oppose to other sections. And also we added an “initial swipe” animation of the swipe that was triggered each time the user didn’t interact with the component for too long. All of these improved the feature's adaptation.
1. The section-header “Suggestions for you” was too vague and only explained the section’s content. Because users needed to understand not just the given suggestions, but also why these suggestions were even given in the first place.
2. Scrolling affordance. Because of development costs we didn’t implement the “Peeking card” affordance. This hindered users understandability of swiping.
Therefore, in order to explain what each suggestion was, I added a small title at the top of each card. This had 2 benefits, the first was being card-specific that explained it’s content more specifically.
The second benefit was because each card now has a title of its own, there was no need for an additional section-title as a whole, therefore saving space.
In addition, to distinct the overall section and it’s different interaction, I added a background to the section, to emphasize its distinct interaction as oppose to other sections. And also we added an “initial swipe” animation of the swipe that was triggered each time the user didn’t interact with the component for too long. All of these improved the feature's adaptation.
Dark mode using semantic colors
13. Changing user beahvior
New VS veteran users
An interesting behavior we found was that new users had almost 2x more CTR on the cards.
This suggested that veteran users had already formed strong usage-patterns with the app and were not finding the cards valuable enough in order to change their patterns of behavior.
At this point we’ve introduced a new type of card, an “Ace” so to speak - the “Recently Viewed card”, it had the most CTR of all, so much so that veteran users were now starting to use the feature and it increased their CTR almost 70%.
This suggested that veteran users had already formed strong usage-patterns with the app and were not finding the cards valuable enough in order to change their patterns of behavior.
At this point we’ve introduced a new type of card, an “Ace” so to speak - the “Recently Viewed card”, it had the most CTR of all, so much so that veteran users were now starting to use the feature and it increased their CTR almost 70%.
The "Recently viewed" card
A big pain point for users was that if a user reaches specific route-itinerary, in case the user navigated somewhere else or closed the app, that route was now hidden in a section at the bottom of the homescreen - not intuitive for a route that can be very important for the user.
The only option for that route to stick was if a user started a “live navigation” - the problem was that only specific users who needed the entire functionality used it.
Each user navigates to their destination in a different way depending a lot on familiarity and experience with the location and the local public transportation system.
What we did was in case a user reached a specific route, we will actively show the “Recently viewed” card which held the seen-route, for the entire duration of the trip, with an additional buffer time (in case user had missed the first most line).
This card received the highest priority out of all the cards, and was the first card the user sees for the entire duration of the trip.
In case of a future route for the same day, it will receive a lower priority (therefore will not be first in the stack of cards) up to 30 min prior to the start of the route, then its priority will be the highest and it will be presented first.
The only option for that route to stick was if a user started a “live navigation” - the problem was that only specific users who needed the entire functionality used it.
Each user navigates to their destination in a different way depending a lot on familiarity and experience with the location and the local public transportation system.
What we did was in case a user reached a specific route, we will actively show the “Recently viewed” card which held the seen-route, for the entire duration of the trip, with an additional buffer time (in case user had missed the first most line).
This card received the highest priority out of all the cards, and was the first card the user sees for the entire duration of the trip.
In case of a future route for the same day, it will receive a lower priority (therefore will not be first in the stack of cards) up to 30 min prior to the start of the route, then its priority will be the highest and it will be presented first.
Screen recording of tapping the clock icon
14. Card's scoring test
We’ve reached a point that we had to understand wether our model was suggesting relatively accurate results as much as possible. To do that we cooperated with the data-analyst team to conduct a test to try and answer that.
What we did was a randomizing test that will shuffle the cards randomly without taking into account the card-scoring model that was the backbone of the stack.
We were glad that we discovered that CTR dropped by ~50% percent compared to the control group that was excluded from the shuffle test.
What we did was a randomizing test that will shuffle the cards randomly without taking into account the card-scoring model that was the backbone of the stack.
We were glad that we discovered that CTR dropped by ~50% percent compared to the control group that was excluded from the shuffle test.
15. Overall
The feature was first tested on iOS, after testing it evaluating its success it was later on developed for our Android users as well.
Overall it improved retention by 10% and improved revenue from ad-exposure by 6% as it brought value for both the users and the business.
This was a a journey of 6 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.
Links:
Thank you