Orion Product Language

Orion has been making software for over 20 years, but up until 2017, the design was mainly handled by the engineers building the software. This led to a product that was riddled with consistency issues, lack of accessibility (WCAG 2.1), and desperately needing a modern visual upgrade.

The goal was to unify our design and development teams by providing a consistent language we could speak to one another and a library of components, both in Figma and in code, that could be easily used across our various products.

When I joined the team in February 2020, the OPL project was just getting started and we hit the ground running by conducting research into design systems created by top companies around the globe as well as talking with our developers to understand their needs.

We created a UI development group to create buzz around the grassroots project and start to get buy-in from our development teams and leadership. This helped us form a small internal UI Engineering team to start developing the components the design team produced.

The design team crafted guiding principles for our component library that helped us make sound objective decisions for each component.

Our system is divided into three main Figma libraries:

By keeping these pieces separate, we've been able to keep each part slimmed down and focused, as well as making it easy for designers to find what they need.

As each component was completed, a designer would write out guidelines for usage and provide examples and showcase any variations a component had. This content was then loaded into our design system site to be consumed by both designer and developer.

Throughout the process I assisted the UX Engineering team in developing each and every component. I was tasked to bridge the gap between the design team and the development teams.

Each component would go through intensive review to assure the look and feel matched the design, down to the pixel. I contributed a significant portion of the front-end styling and all animations. I also helped the team develop our theme switching process and our design token usage.

From the start, we wanted to create a system that allowed us to offer different themes for our user base. We also had one product that solely used a dark theme and multiple products that solely used a light theme.

Initially we tried just inverting our colors, but quickly found that each component within the UI needed specific changes between themes. That's where design tokens came in.

We set off by deconstructing every single component and assigning a specific color token to each individual piece. Background, text, icon, etc, all got their own color. Each of those colors then mapped directly back to our main core colors and allowed us to easily update a single piece of each component if needed.

Leveraging a plugin called Themer, we were able to easily switch color themes within Figma to allow any designer to use dark mode components without having to duplicate our component library.