DESIGN SYSTEM
Create a native mobile design system
My role
UX strategy
Interaction design
Visual design
Tools
Figma
Spreadsheet
Confluence
Background
Roche began with a web-first design system, One Design System (ODSU), to support its clinician-facing web applications. As digital products expanded, the necessity for native applications and a supporting design system became apparent.
Solution
Add a native mobile design system to an existing global web-first design system.
Impact
The native mobile system has been utilized by the two native mobile products. For the next steps, we are working on what it would mean to integrate products through acquisition into the system, as well as what introducing semantic language means for the entire ODSU system.
Research
In my research phase, I analyzed current native app development efforts within the company, native design system principles, reviewed our current web-first design system (ODSU), and studied how other companies tackled this problem:
Current efforts - With engineering, we met with the teams of a couple of Android app efforts within Roche. In the end, we decided that building a navify-branded Native Android Mobile Toolkit would be the best approach to utilize the latest Android framework of Compose and to prioritize accessibility.
Analyze native design system principles - I collaborated with the engineering team to analyze the existing native design systems. For design, this was iOS Human Interface Guidelines and Material Design; for development, this was SwiftUI and Compose.
Review current web-first design system (ODSU) - In our review, the key things we wanted to understand were the development framework used, the token naming system, and the accessibility of components.
Other companies’ efforts - I studied how other design teams tackled this challenge, including DoorDash’s introduction of Native Design System into Prism. From this, we extracted what would be possible for our small, but mighty 2-person design team 💪.
A comparison of the different native app design system efforts.
Opportunity
How might we seamlessly integrate native design principles and components into our established web-first design system to ensure consistent and intuitive user experiences across platforms, while maximizing development and design efficiency?
Design Strategy
1.
2.
3.
4.
Take inventory
I assessed the existing web components to identify a subset of components needed for adaptation to native platforms and those requiring redesign or creation from scratch. When parity with the native components provided a greater user experience, the native component would be added to the system. Examples of this are native iOS and Android navigation patterns and bottom bars.
Parity across platforms.
Inventory of buttons
It was important to create parity across platforms to ease the design and development burden. This included:
Naming parity in tokens and components.
Design parity in components across platforms for brand cohesion, while respecting iOS and Android design patterns and experience.
Structural parity between how the components are built for both design and development.
Figma files and code parity between how our product designers and developers interact with the design files and code base, regardless of platform.
Accessibility first.
Spreadsheet of mapping ODSU tokens to components
We decided to utilize the native components, when possible, to lean into the built-in accessibility features, such as light and dark mode. This would mean that there would be some differences in components between ODSU and native application.
Reuse. Reuse. Reuse.
Converting Android Compose components to ODSU’s look and feel
It was important to build a design system that was flexible enough for sub-branding opportunities, white-labeling, and future mergers. The way to do that was to provide a robust token naming system.
Token naming summary
Results
Structure
For the structure of the files, we kept the token naming the same, which allowed the design system to be flexible enough to be themed out to different sub-brands, such as navify and cobas. The icons are all drawn from a common library named ODSU icons. For the iOS and Android platforms, a native icon library created for each, utilizing the same icons. Next, for the file structure, ODSU Web, Android Native, and iOS Native had separate files.
Token naming
The token naming was by far the biggest challenge, as the web-first design had only named the tokens up to the alias level, which could be quite broad. The ask was for the design system to introduce semantic token naming, giving both designs and developers the specificity needed to have clarity on the token’s purpose.
Native code
To keep the UX consistent for the product designers, I kept the structure of the native app design system file and naming convention the same as the ODSU file. However, one the biggest wins, was solving how to translate this to native code through the use of Figma variables.