My experience creating and maintaining design systems

I've had the opportunity to help lead design systems work at LaunchGood and CVS Health. At LaunchGood, I led the creation of the company's first desgin system, while at CVS Health I worked on maintaining and updating components. I'll share a little bit about what we did.

At LaunchGood, the company was preparing to do a rebrand. This included creating an updated visual identity that was consistent across products. More products were in the pipeline, and with one team, we needed a way to build fast.

We identified which products we wanted to test out the new design system with, with the understanding that we wanted universal UI components such as buttons, campaign cards, to be re-used across products, while allowing the opportunity for each product to it's own thing if needed. This was because we had a variety of products, some of which were very similar in nature, so this made sense for our context.

We also identified a product that would be the test product for this new design system.

We began by taking screenshots of various UI components. While this helped us identify things we wanted as part of the unviersal components, it also helped us see how we were using components in the real world (not isolated pieces of UI).

Now in order to use our UI components in Sketch for creating mockups, I had to learn how to set up symbols and various states of components, how to organize your components, etc. I read articles and actually came across Pablo Stanley's YouTube channel where I learned how to start setting things up in Sketch. I worked on getting components into Sketch, and worked with our CDO (who was also the visual designer) on getting the components we needed in there.

Because some of the components we audited weren't directly related to products, we realized there were certain new components that would be universally applied such as form fields. This was interesting because we had to really think about what we needed in a design system for products.

While we were getting these components into Sketch, we needed to make sure that certain things could be re-used in other things. For example, re-using background colors, or buttons in larger components. Atomic design by Brad Frost helped set out direction as well. We had base styles like color, type, shadows, etc. and then smaller components like buttons, and larger ones such as cards.

At the time, there weren't layer and text styles and all the other great features Sketch has now, so it was a little harder to do it back then.

Because our platform had some interesting technical limitations, we couldn't really just go ahead and start creating a separate package or site for the design system. Additionally, we were rolling out the design in limited quantities to newer products and were going to slowly incorporate the platform piece by piece. We ended up having to write the components in HTML every time, but in order to alleviate that, we focused on making our CSS architecture helpful.

We essentially had CSS for each UI component and worked on creating utility classes for smaller things like type and variables for color. We also worked on a naming syntax similar to BEM, but that also kept in mind the name and type of of the component since we didn't have Angular components. The naming structure included the atomic breakdown as well. For example, for the class .lgx-c-button--primary, lgx refers to our design system which isolated that CSS from the older things on the site, c refers to a component, button is the component, and --primary is the modifier.

While our design system was sort of limited to CSS due to various limitations, I certainly learned a lot from this experience:

• How to go about creating one from scratch
• How to make the design side of the design system in Sketch
• How to consider company circumstances and strategy for the roll out of the design system
• How to name things in CSS and consider atomic design, reusability, and clarity in the approach

At CVS, there already was an established design system that had some code components. While working on the design systems team creating Sketch components, helping re-design the taxonomy, and helped set the direction for the next version, (here and there as time permitted), I learned a few things as well:

• Generally people will ask for things to be put into the Sketch library so they can use it for themselves. However, in order for the design system to really be univerally applicable, there should be some discussion around broader need for the thing being suggested. This also avoids bloating the library and creating additional work needed for both design and dev.
• Clarify visual direction, especially if you bootstrap off of something like Angular Material. Things can get a little Frankenstein-ish if you aren't careful.
• Ensure that design and dev are in sync. In our group, we don't have a dedicated design systems team with designers and engineers; everyone assigned to the team helps out here and there when they have time. This leads to design components not making their way into the design system code, and isn't ideal since the value isn't necessarily getting realized. If possible, it feels like a dedicated design systems team would help a lot.
• Ensure good usability of the design system for the folks using it. In Sketch, I did things such as naming layers to where they made sense when you were using the component and needed to find something to override, stacking layers in order so they made sense on the right panel, thinking about resizing options, and even re-implementing the components with the new auto-resize feature from Sketch when it came out.
• We also worked on re-doing the taxonomy and naming convention for the components since it became difficult to find things. We did a couple of rounds of card-sorting with the team to help inform the taxonomy.