One of my major responsibilities at Syngenta was establishing a design system to support our growing team, and to bring consistency to the wide range of products we work on globally.
After inventorying our existing styles and patterns, we prioritized designing and documenting foundational elements (color, typography, and spacing) and a few basic components (buttons, text fields) as our starting point. Color was the highest priority, as there were significant contrast issues with the existing brand palette.
Starting by researching color theory and how it relates to contrast, I then went through many methods and variations in order to develop a full color system. My goal was to build the color system in a way that accessibility is built into each tone in the scale, and to support theming for the various brands under the Syngenta umbrella.
The new color palette and other foundations/components have started to be adopted across our products. I have worked closely with our lead iOS engineer to develop a UI kit with color variables and pre-built components, which has significantly sped up development time and improved consistency across our mobile apps.
Summer 2019
This color system is just a small snapshot of the work around building out a design system at Syngenta. Of course there's designing UI components (incl. Buttons, Text Inputs, Alerts, etc.) for web and mobile platforms but also things like building processes and outlining best practices for our component structure & design tooling.
Perhaps most importantly, there's also regularly advocating for the merit of investing in a design system to leadership and cross-functional partners. In introducing the idea of a design system, half the battle has been around highlighting the benefits of such a system, how it can be used, and how it can be implemented into and help to streamline our product work.
Between April and June 2019, our team grew from 20 to 100, distributed across three locations globally. The rapid increase in scale introduced new challenges in maintaining consistency across all of the products we support and reducing duplicate design and development work.
To address this, we started working on a design system that would serve as a source of truth for both design and code. We started by establishing a “digital foundation”, since Syngenta’s official brand guidelines are designed for print, with only a single page on “digital” usage.
In auditing Syngenta’s marketing websites and any existing web/mobile apps, we found that there the most problems with the application of color:
We set out to create a color system with a range of hues and shades designed around the following principles:
Without a formal art or graphic design background, I took to the internet to give myself a crash course in color theory, color models, contrast, and the different ways other design systems have organized colors into a coherent system.
After my quick research phase, I arrived at a few choices I would have to make:
- Color selection: procedurally generated vs. manually curated
- Color scale: simple & limited (~4 shades) vs. full & comprehensive (~10 shades)
To get an idea of how procedural color selection could work, I built a simple tool using SCSS lighten/darken functions to more rapidly test how each hue responds to changes in lightness.
This worked for quickly generating variations on a core hue, manipulating only the lightness value tended to create washed out colors, and it was difficult to control contrast values between equivalent shades.
Rather than trying to control for these factors programmatically, I opted for a manual process for color selection. By locking in each hue, and having a rough lightness range for shade, I was able to mostly standardize contrast scores while maintaining visual consistency between hues. With this approach, designers could swap out equivalent shades and maintain proper contrast levels.
I kept the palette limited to four shades per hue (two light shades for backgrounds, a base shade for icons, and a dark shade for text). With a small palette, I was able to eliminate some of the midtones that tend to have low contrast and reduce the number of similar options designers have when selecting colors.
After testing with various components and UIs, having just four shades per hue proved to be a bit too limited, making it difficult to design clearly differentiated states for buttons and other components. However, rather than just adding more shades to the palette, I explored various ways to maintain the simplicity of the current palette while providing auxiliary shades where needed.
To expand the palette, I used the existing four shades as anchor points and filled in the gaps by editing the saturation and value curves to create a smooth transition between each shade.
With a full palette of ten shades, I tested colors out in the context of components to see which combination of shades pass contrast standards while maintaining visual clarity.
After the testing, we ended up with three core shades (100, 500, 700) and six auxiliary shades for when additional shades are needed (like hover/active states). These colors adhered to the principles we set early on — contrast between equivalent shades was reliably consistent, maintained clarity in the darker shades, and were reminiscent of Syngenta’s brand colors.
Having a standard set of colors was only half the battle. Creating clear guidelines that define when, where, and how to use the palette was the next step.
While our long-term goal is to build a website to host our documentation and other useful design system tooling, we didn’t want to slow ourselves down by creating something from scratch. Instead, we used Confluence since our team already uses it for other documentation.
The initial documentation includes high-level principles, swatches, hex codes, and usage guidelines. Over time, we plan to add more examples and images showing proper usage.
Our color system, documentation, and implementation are ever-evolving to fit the needs of our growing product team. In order to keep up with that, we intend to establish a global system of design tokens (essentially, individual design decisions stored as variables).
So far, we’ve laid the foundation by creating a standard naming convention for colors across our iOS, web, and Figma libraries. In our Figma libraries, we have started to include styling information in the format of CSS to help designers and developers start to use the same language.
Taking this to the next level of abstraction (i.e., button-primary-background-
color instead of teal-500) would better support theming for different brands, allowing colors to be swapped around without having to update every single component.
Moreover, building out design tokens in this way makes the CSS more semantic/readable, hopefully making easier for designers to understand and work with CSS and for developers to more easily break down design specs.
