"A design system is a collection of reusable components, guided by clear standards, that can be assembled together to build any number of applications."
And with that brief description on Google I started to understand what design systems are, why companies should use them, and how to implement them. Warning: if you don't have interest in design systems the following is boringly nerdy.
I figured I'd share my journey to design system awareness and maybe some folks can avoid some of the pitfalls.
For starters, read every book and article you can to fully familiarlize yourself with what a design system is and how they are maintained. The first book I read that really introduced me to design systems was Brad Frost's Atomic Design. It is an excellent starting point because it describes the modularity that is essential to building a design system. You don't have to follow Brad's work verbatim, but it's a great place to start. I started making components using Brad's atoms, molecules, and organisms (and templates and pages that few seem to use).
Commit to a design tool! There are several good tools that make use of components, and some coming up that claim to be "design system ready" (that remains to be seen). Whichever tool you pick, stick with it, so try them all like I did. To name a few:
Start taking a few good courses on design system creation:
Should you use an existing turnkey Design System creation tool?
My first attempt putting together a design system started with taking an existing color palette in our company's "Visual Design Language" pattern library, and creating Figma components for each color.
Figma is web-based, so the tool gives you the ability to embed live Figma frames (artboards in other design tools), pages, or whole files - when those files or components are updated, it all happens in real time in the embedded view. For example, while you are reading this if I were editing the color palette, you would see the changes happening dynamically in real time.
This is the primary reason I am partial to Figma, it eliminates design drift as I call it, because everyone works in concert. I have written a few articles in Medium about Figma and was interviewed by the San Francisco Business Times
where I describe Figma as the "design tool of the future" because it's cross-platform and highly collaborative.
A couple of my Medium articles on Figma:
What I did wrong in my first attempt was not use those component colors to create the building blocks for my atoms in the pattern libraries. For example, any button color I want to be dynamic and a living entity in my design system would have to be created by using the color component's "atom" from the color palette that has been "componentized" for use in the design system.
My second attempt was too complex in the construction of the components. You have to remember to make the symbols/components simple enough that overrides in the actual design are easy to do without "detaching" the symbol/component from your atomic structure. For example, I was creating a table column header by trying to put constrained column headings in the molecular component, but I can't tell beforehand what the table design might need for columns. So I would have to detach the column header every time I went to alter a table. Not good. So in my next pattern design, I kept the column header empty except for a representative first column heading and last column heading, both constrained to the left and right of the header bar respectively. That way I could adjust the base component width and the two default headers would have appropriate spacing but are overridden by title. And I could make the far right column header invisible if it was not being used.
My third attempt seems to be working great. (I'm avoiding the word "final" because design system pattern libraries are always being modified to allow for added and removed components, updates to the brand, alterations to micro-interactions, etc.) Correcting my first mistakes has made the component set flexible and changeable without painful redundant work due to breaking symbol/component connections. I have now done a Figma and Sketch component library, and plan on using any tools that assist in design system creation and management as they arise. (At this writing, Invision is producing Invision Studio which we assume will be design system savvy.)
This is where I left work on a Sketch design system library at ADP. In Sketch, you make use of masks to create overrides for any attributes of a symbol you want to change in the placed symbols. For example, I have made masks for each icon, so I can use the color symbols to override the icon color from any file or page.
After leaving ADP in May of 2018 I joined Toptal, the premier online freelance hiring agency. Since I was in between contracts I started creating this Figma Design System Library as a generic framework, for whenever I go to agencies that are smart enough to use Figma, and are not restricted by security concerns (Figma being an online app it takes an act of God to get some companies to even consider using it).
What I'm doing is creating a basic framework for a design system component library using Figma. At this point it is empty, the idea being that you only add elements as you need them. One key to starting a design system from scratch is to keep the number of components limited to MVP only. This kitchen-sink framework is only to show what could be built out in a design system, not necessarily what should be for your use case. This file is straightforward - each large component grouping (which I borrowed from the excellent Sales Force Lightning Design System) represents simple, complex, structure, and featured components. The components are arranged in Figma frames, so they are organized by type in the team component library.
When the design system framework is filled in, it will be easy to find what you need using their search or browsing by the type of component.