Tropo Design System
The Tropo Design System was created for enterprise-wide use for Boeing and all supporting business units early in 2021. Across the company, multiple legacy as well as modern applications built using React or Angular were in desperate need of consistent UX design patterns, reusable components and UI brand consistencies.
The design system was carefully curated by, with and for designers and developers. Tropo is proudly built as an internal open-sourced product used and maintained by the users and core team.
Boeing introduced a new brand typeface called Boeing Meso. The Tropo Design System team worked closely with the corporate brand on testing, implementing and setting the standard for the new font in a digital medium. The design system was the first Boeing product to fully adopt Boeing Meso.
"A design system is still a product."
Just like any other product that we worked on, we started with research. We knew from the beginning that creating a design system at this scale was a massive undertaking (still is).
Some of the general questions asked:
Does your product have a designer?
What framework, if any, is your product using?
Is there a library or a style guide for your product?
Does your product aligned with the Boeing brand?
Is your product accessibility compliant?
The feedback that we received was overwhelming. We had multiple products willing to participate and the excitement around the product development community was starting to develop. We learned that not only does our design system have to meet the Boeing brand standards, but it will also need to support multiple Javascript frameworks (React and Angular), have the ability to be customizable for the different Boeing organizations and accessibility will be at the design foundational core.
A design system monorepo was born.
With one of our requirements being that we needed to support multiple frameworks we started to explore the idea of a single monorepo split into three different libraries: a SCSS style library using design tokens, then a React and Angular libraries that utilizies the style library. This approach allowed the design system
Maping the Tropo Design System Monorepo using GitLab.
Using design tokens
Introducing design tokens into the Tropo Design System was a must. This was an opportunity for design and development to have a common ground with naming, styling and structure of components.
Our design tokens start at the foundational level and work into the component themselves. Moving forward, whether you are looking at a Tropo component in a design program, in the style library or even in one of the Javascript libraries, the nomenclature is completely inline with eachother.
Demostrating the use of design tokens. Default, System and then Component use.
Here's an example of how powerful design tokens can be when implemented correctly. Design tokens are distingished at the foundation and then the component level. You can see the way the button component is structured and named in the Sketch Library is identical to the style library.
1. Foundational and component design token set. 2. Design tokens used in Sketch. 3. Design tokens used in style library.
Component
& structure
Designers and developers worked together to find the common ground with our design tokens, but the discussion continued when it came to how we plan and build components. When it came to implementing the components we wanted to make sure all the attributes, variants, options, etc. remained consistent across design programs and developers.
Planning out the component drilldown with options.
Exploring a Light/Dark (DayNight) Mode using design tokens and component options.
Demostrating a component structure breakdown.
What about
accessability?
When it comes building a product, accessability should be considered at the core and foundation of the product. So when it comes to building a design system, accessability should be thoroughly tested for all foundational elements and core components.
Accessability shouldn't be a feature.
When it came to building out the core of the Tropo Design System, we had foundation set with the Boeing brand standards in place. These standards focused mainly on the brand and print standards, so we had the obligation to set these standards for product development. We started with our color palettes — primary, secondary and tertiary (data visuals only). Each colors our palette has a set of supporting colors with a dark, light and scaling.
Tropo foundation supporting, scaling and data visual colors are all tested to meet the WCAG AA standard for typography and component use with our surface colors.
A non-visual accessibility experience?
When should an aria-label, aria-description, tabIndex, role, even html structure be considered when developing an interface? With the use of Typescript, we work carefully with both our designers and developers on how our components are used. When we develop our components we are able to choose when types are requires vs which ones are optional. The perfect example of this is the use of an IconButton component. Not only is there no context to what the icon is to a screenreader, but there's also need to be a role and tabIndex added. We are able to see this properity of the component required. So, if a developer goes to use a component that is missing a required props, the Component will error.
UI Sketch Library
The Tropo Design System Sketch Library v1.0