A System Built on Parity
How to treat all of your users equally
My dad bought my first smart phone, an HTC Droid Eris, in 2009. We went to Best Buy and instead of looking up anything technically significant about the phones, I picked the Eris because it had a skateboarding robot on the screen. I loved that phone — when it rained there were wipers that would clean the digital water droplets off the screen and the ability to have two clocks on the home screen for my east & west coast homies. Two years later I felt the social pressures of a designer/iMessage and switched to an iPhone, but never lost my love for Bugdroid.
Flash forward — now I work on a design system attempting to become the canonical way of designing and building at Lyft by fulfilling four main goals:
- Deliver coherency & predictability to our products
- Reduce design and engineering time and debt
- Raise the quality of our experiences for every person and every edge case
- Create a universal design system that works best for Lyft on all platforms
…and that last one, parity, is very important because it ultimately affects the first three. If we only build for one platform, let’s say iOS, then we’re not delivering a consistent product, reducing time and debt or raising the quality of experiences for every person for Android or Web.
Why parity is important
When we first started our system Kathy, our Android engineer lead, brought up a sentiment that is all too common in the engineering community:
Being on multiple feature teams previously, I had felt this too. We recently conducted a simple survey to better understand the situation and the results confirmed our suspicions:
What happened was we started to get some native iOS paradigms, like centered headers and chevrons at the end of list items, being introduced into Android where they weren’t native — which is confusing to our end users.
But what was really happening here? Surely designers aren’t jerks, so we talked with them to find the real culprit. Truth is they do care about both platforms and understand that they’re different, but they just have no time. So that got us to thinking:
How might we (the design systems team) prioritize treating our users, designers, and engineers equally? The answer: platform parity in everything we do.
Ultimately that means a designer can hand off a Sketch file with designs for only one platform and the other platform can read it like a menu. The system elements will capture what is different. Additionally, we encourage designers to switch which platform they design for every other project.
How to build for parity
This is how the design systems team approaches components cross platform:
Name parity
A consistent name across all platforms makes communicating about components easier. Our rules for choosing a name are deceivingly simple:
- It has to be easily recognizable as what it is to all platform engineers and designers.
- It cannot have the name of another native component.
We start the process by researching it’s native ones. For example this component is called “Popup” Android, “Dropdown Menu” Material Design, “Popover” HIG (Isn’t naming components after food an Android thing?), and “<select><option>” HTML.
Thanks, I hate it. We ultimately decided to go with “Dropdown with Popup Menu” where “Dropdown” refers specifically to the input field and “Popup Menu” refers to the elevated card with list items inside. It’s a name that every platform understands… even though down and up are hilariously in the same component.
Feature parity
Most of the time feature parity is easy because many of our component’s features are system agnostic like Tooltip, Button, and Carousel with Carousel Page Indicator (another fun naming exercise.)
However, sometimes this is difficult because there are components whose features need to visibly replicate their platform in order to match expected behaviors. A good example is Sheet where the Android back button plays a role of cancel button visible in iOS. We balanced system and platform parity by having them use the same button size, text styles, and allowing both to have icons and text, while keeping the inset and cancel button on iOS.
Another example is Header where copy and icons are common on iOS, while Android uses icons only. We prioritized parity by only allowing for icons on both platforms. They have the added benefit of not growing too long or truncating when localized. Our iconographers make sure our icon-only actions in the header are clear.
Process parity
Building We design and build in parallel so any discussions on details that come up during implementation (and there are usually many) get addressed and considered together. We don’t announce that an attribute or component as ready to use until it is complete in design, Android, and iOS.
Migrating There are numerous legacy features built without parity in mind. By migrating these features to our system, we can fix inconsistent designs and behaviors. Engineers on both platforms are able to independently migrate designs for the same feature and use the same system components. We make this process efficient by providing decision trees.
Contributing Lastly, contributions from other teams can cause a component to fall out of sync. It is rare that design, iOS and Android designers and engineers from the contributing team are all available to create the component together. We treat this lack of parity like a bug and prioritize it over other elements on our roadmap.
Last thoughts
Prioritizing parity is important because we want to treat our users equally, communicate with the same language, and promote consistent designs and behaviors. This focus on parity has enabled us to provide a truly universal design system that is adopted equally on all platforms.
This article was originally written for DesignSystems.com by Kathy Ma, Sam Soffes and myself, which morphed into an Android Meetup talk at Lyft and now back into an article!
I’m Linzi Berry, currently design systems manager at Lyft. I sweat the details so you don’t have to. My hope in documenting system design thinking and process is to contribute and learn from the design community at large. Please subscribe!
