NI Design System II

The Project

In 2020, our company had recently undergone a significant re-brand and all of our products would be impacted by the new visual aspects of that brand. For us, that meant we needed to start looking at ways to update our entire portfolio of products that spanned multiple platforms, built with modern and not so modern architectures. While some of this would be a one-time update, we were also concerned about future updates. A new brand will be refined as it matures and we need our software to quickly react to those changes.

Our products exist on web and desktop platforms. They work on multiple operating systems. Some products use modern codebases and architectures like Angular and C#. Others were built decades ago in C++. We also needed to consider some of our internal tools such as providing design assets for designers to use in Adobe XD.

The scope of this project was to create a proof of concept that determined the feasibility, priorities and cost of implementing the tooling and system for consistent and maintainable design elements across our diverse set of software products.

Responsibilites and Contributions

For this project we had a team 10 people for 1 week. My key reponsibilites and contributions were:

Drive decisions

Alongside our Chief Software Architect, we defined milestones, core technologies and key deliverables of this effort. We guided the members of our team through the project and decisions and also investigated external solutions for tooling.

Architect the tokens

My core individual contribution was defining the architecture for the design system. In this case that meant designing our architecture, naming and relationships of design tokens that defined our core systems of design elements.

Product an XD Plug-in

Lastly, I developed the plug-in that would take the output of our design token tooling and translate that into XD assets for our designers to use.

A Look Outside

The first step for this project was no different than many from my past. Go do some research. We are not the only ones to have solved this problem. What can we learn from those before us? What we discovered were some great tools that existed. We decided to use a tool created by Amazon called StyleDictionary to help us translate a single source of information into formats different products could use. We also looked at more complex design systems like Spectrum from Adobe, Carbon from IBM, Lightning from Salesforce to understand large design system architectures. Additionally, we were fortunate enough to get some guidance from Adobe on their strategy for building and rolling out something this large. This research was immensely helpful to save us time and move us forward.

The Tooling

The tooling was, conceptually, simple. Take a set of design tokens (defined in JSON) and transform it into formats that could be ingested by a particular product/platform. For example, generating a CSS file to be used by our web products. For some of our more modern products, like the web, this would be pretty straightforward. This is where StyleDictionary would help. It was also easily extendable, which we could use to help generate custom formats for our other products.

For some of our less modern platforms we still needed to create a little middleware tooling to help integrate the output and inject it into the codebases of those products.

The Architecture

At the foundation of this system is a set of tokens that could define every visual aspect of our UI. These tokens are a set of key/value pairs that can reference discreet values like ‘10’ or ‘#FFFFFF’. Alternatively, the value of a token could be a reference to another token. This allowed us to layer our system and reduce redundancies. Hopefully a discrete value can be defined once and referenced when needed. This would allow maintenance over time to be more efficient.

For our proof of concept, I wanted to find a balance in our token architecture for reducing redundancy and allowing specificity. I defined 3 layers for our token architecture. The architecture created by Adobe in Spectrum heavily influenced our own for this exercise.

Global Tokens

There are the core values of the system. Need to change to typeface for the entire product? You can do that here by making one change. The values here a rarely referenced directly by a component and the naming of the token is agnostic of its context.

Alias Tokens

This layer begins to add some context to the use of the token. It also provides a grouping mechanism so that you can change a visual property for a particular set of components.

Component Tokens

This layer is the most granular and relates to a specific component. There is token that represents every piece of visual information for a component. It allows designers and engineers to be as specific as possible when designing or developing a component.

The Outcome

With our tooling and the architecture in place, we defined a new color and typeface to be updated across a representative set of our products. We successfully defined tokens, transformed and ingested those new colors and typeface into our set of products. Simply put, yes it can be done.

Through this process we had some very important learnings that would guide future investment like the following:

• Modern technologies are going to simpler to update
• Older technologies are feasible but will be complex
• Color and fonts will be easier to update than things like layout and animation
• Updating color and iconography make a huge impact on consistency
• For existing products focus on new features

Ultimately, the proof of concept was a success. We proved the feasibility, provided priorities and estimates to move forward. As we continue this effort, we understand the challenges we will face and where the best areas for initial investment will be.