“A design system isn’t a project. It’s a product serving products.”
— Nathan Curtis, EightShapes
— Nathan Curtis, EightShapes
Our design system team is small but mighty with 2 full time product designers and 4 front end engineers. It is used by over 50 designers, thousands of engineers, and over 11 applications within the Networking Experience group at Cisco.
Design consistency was lacking
When I started my role at Cisco, I became the second full time designer tasked with improving the existing design system. A basic set of components existed, however there were duplicates, inconsistencies, and no usage guidelines.
Designers were confused about which components to use. They spent a large percentage of their design time hunting down components and often recreating them from scratch. There also wasn't a process in place for requesting new components and enhancements.
The goal of a design system is to help teams achieve higher efficiency, consistency, and scalability.
Meeting this goal saves both designers and engineers time so they can focus on creating the best products possible. This ultimately leads to significant time saved and the ability for Cisco to increase revenue in the software space.
Design System Research
In the initial phases of working on the design system, I educated myself on best practices and methodologies. I found the Design System Handbook to be very useful.
I did secondary research and read best practices for every component I enhanced or designed. For more complex components and frameworks, I worked closely with our research team to conduct studies with users of our products to ensure they were easy to understand.
One of the most challenging aspects of a design system is that you must consider not only the designers and engineers who use it, bus also the end users of the products your design system is for.
I created an extensive audit to keep track of all the existing components when I started my role at Cisco. I documented every component I could find with related links, details, and status. This allowed me to see a larger picture of how many duplicates we had as well as any gaps in the existing system.
Once I had a clear picture of everything that currently existed, my team and I began simplifying and creating guidelines for each component and publishing them on an internal website.
What started out as small library grew to over 50 different components with detailed guidelines over the last few years. These guidelines are regularly updated with a changelog.
Responsive UI kit
We started out with a UI kit in Sketch that designers could use to build their designs faster, but ran into issues with flexibility and responsiveness. Our team initiated a large scale migration to Figma and built out a new detailed library of responsive components.
Designers are able to quickly drag components into their files and change a variety of parameters to meet their needs. Variations and states are easy to change with the click of a button.
After switching to our new Figma UI kit, designers in our group estimated a 30% reduction in time spent mocking up their designs.
Modernized icon library
In addition to designing components, I art directed and led the modernization of over 300 icons and created guidelines on our website for a consistent grid, sizing, spacing, and iconography style. My team turned this new set of icons into another responsive Figma library. I currently manage all new icon requests and enhancements.
A unique illustration library
The larger design team is primarily composed of UX designers with minimal visual design experience, so creating custom illustrations from scratch for each use case was not feasible or scalable. We decided to take a unique approach with a library of illustration building blocks allowing designers to quickly create custom illustrations.
I art directed the new library and review new custom illustrations that designers create. This helps breath more life and personality into otherwise complex enterprise networking products.
Communication is key
I believe communication and building strong relationships with designers and engineers is at the core of a successful design system.
We meet with our front end engineers twice a week and chat daily on Webex to make sure we're always on the same page and moving component enhancements along smoothly. Our team reviews and tracks enhancements in GIT and provides clear redlines and feedback.
Our team also set up Webex chat rooms and regular meetings to allow designers to ask us questions and request reviews of their work.
I led the creation of quarterly newsletters that are sent to both designers and engineers announcing the latest updates and new components.
Our biggest challenge is low adoption from application engineers. We work in an organization where designers are greatly outnumbered (approximately 50 designers to 5,000 engineers). Engineers add their own features to products without any design input or review.
In a recent study of a single component we found that in our primary product 89/101 implementations did not use the correct component.
Because adoption is low we recently conducted an internal workshop with our front end engineers to brainstorm ways to improve communication with the larger engineering org. We also partnered with them to build a new library that will hopefully make Cohesion easier for engineers to use.
I’m currently leading the initiative to improve overall visual design of our components while our engineering partners build a more modern library. This new library will be completely tech agnostic and will therefore open up our design system to be used by more teams. We hope this will improve adoption challenges.
2.0 allows us to break free from older inherited styles and move toward a modern friendlier look and feel. It will also use consistent tokens for things like border radius, transitions, elevation, typography, spacing, and color.
A design system is never "done"
There is sometimes a misconception that once you complete all of the basic components needed for a design system, it's "done," but that is definitely not the case.
Tackling challenges like adoption within an engineer heavy organization require steady and consistent evangelizing and communication.
Our system is a living breathing entity that has changed so much over the last few years. My team is consistently reviewing complex use cases that stretch our design system and allow it to grow and improve.