At Moovit, we maintain two distinct design systems for iOS and Android, with the goal of achieving a unified user experience. However, due to platform-specific components aligned with OS guidelines, our challenge extends beyond design system development and maintenance to aligning both platforms as closely as possible, while providing an experience that's tailored to the OS.
We’ve utilized the atomic design philosophy where we start with the smallest UI element possible and build on top of that element for more complex elements and components.
We’ve divided the design system to 3 categories:
1. Foundations
The building blocks of the app such as colors, typography, spacing, grid, shadows etc.. By first designing the building blocks, we can later on build on top of it for other components.
2. Native
OS related components that were tailored to the app style and needs. For example: Navbars, tabs ,menus, dialogs, date pickers, checkmarks, toggles etc..
3. Custom
Custom bespoke components built for the designed solutions that can be reused throughout the app. For example custom steppers, price view, time view, alerts, empty states, list items etc..
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
We've implemented semantic-colors in adherence to material design principles to establish a logical and coherent color hierarchy and to support dark mode seamlessly.
We’ve defined the colors in 4 categories:
1. System colors
Primary, secondary, tertiary, text highlights etc.
2. Status colors
Good problem, critical, info etc.
3. Background and surfaces
Background colors, surface colors for cards and elevated UI elements.
4. "On" colors
Colors that are layered on “top” of other colors, so we need to have direct relationship between the colors, for example: on primary, on dark surface, on surface etc.
By using the power of semantic colors, dark mode support is achieved smoothly, the semantic-color is used as a pointer to the relevant color in each mode.
Example:
Note: This is a general structure.
There can be additional sub-data set such as line-updates, arrival times, route changes, payments etc.
For optimal accessibility and performance, we've adopted native text styles for each operating system: Roboto for Android and San Francisco for iOS.
These styles were carefully crafted providing coherent logical sizes and weights, that could also increase or decrease proportionally in case a user modified the default text size.
Note: This is a general structure.
There can be additional sub-data set such as line-updates, arrival times, route changes, payments etc.
Here are some examples of custom and native components designed and built specifically for Moovit's needs to be reused throughout the app.
Each of these components has been thoughtfully designed, encompassing comprehensive consideration of all potential states and use cases that may arise.
Note: This is a general structure.
There can be additional sub-data set such as line-updates, arrival times, route changes, payments etc.
By iOS HIG definition, there’s no native “radio button” for iOS.
iOS doesn’t have a radio button design and only uses checkmarks, but iOS does use a “single select” functionality intended by a radio-button.
In addition, macOS does utilize radio buttons in its functionality. After careful consideration and referencing multiple popular services such airBNB, Monzo etc. I've decided to add the radio button UI element, as it has become a worldwide convention that's accepted on almost all UI platforms.
MacOS radio buttons example:
Note: This is a general structure.
There can be additional sub-data set such as line-updates, arrival times, route changes, payments etc.
The design system is always changing and evolving with advancements in technology, OS guidelines, new conventions, new user-needs, trends etc. I've led the rebuild of both design systems on Figma from the ground up, conducting weekly meeting with R&D teams, reading technical documentation to align OS components to the system in the most optimal way, to achieve ideal solutions that can be reused throughout the system while taking into account the different use cases.
