Happy Wednesday!

Yesterday, I shared some community definitions to the term "design system."

Christina Chen and Ted Barnes responded with their own definitions!

Ted's definition:

I tend to go with something closer to “design systems are how teams collaborate asynchronously” It keeps it open ended and works well with the DSaaS approach of delivering whatever the team needs. And makes it clear the system serves the teams — and should evolve with their needs — not a dictatorship.

Christina's definition:

I don't have a great definition but I've always had an "interview answer" prepared in my notes -

Design system: Helps design, product and engineering teams work together to build at scale, provide consistent & predictable experiences for users, and align with company vision. Comes in different shapes and sizes such as component libraries, documentation, fostering a space for community education and contribution, etc.

Design systems have been around for a long time, but I've watched them slowly become more formalized in the past 5 years. That's why I find it interesting that we haven't aligned on a definition as an industry yet.

One thing I do feel pretty confident about is that a design system is more about applying constraints and processes to the design and development process than it is about outputs and artifacts.

But that doesn't mean those outputs aren't important, or that there aren't certain artifacts that design systems tend to create.

Design systems tend to leverage the following artifacts to achieve system goals:

1. A style guide/brand guidelines
2. Design tokens
3. A design library
4. A component library (code)
5. A release strategy
6. Documentation
7. Evangelization
8. Governance

Do you agree? Am I missing something? Reply to this email and let me know!

Talk soon,

Mae