I’m approaching a Version 1.0 milestone on a Design System project and it has me thinking broadly about my 8+ years of experience with Design Systems. Unrelated to that project specifically, I came up with an abstracted list of five key milestones I feel exist in the life of a Design System project. This is my list, yours may be different, I’d love to compare notes.

1. Formation of the Design System Team

Congratulations, you got budget! Someone in the company financially supported the idea of a cohesive UX strategy while reducing design and development churn… or at least they let you self-organize and schedule meetings. It took a lot of energy to get buy-in and there’s a lot of hard work ahead. There may even be sedition and political subterfuge waiting in the wings!

My biggest recommendation at this stage would be to set the bar as low as possible (and then lower it further). Figure out how to create an early success. This touches on Flow and lowering the challenge level for a new team, but at its core this is about needing validation that the system works as early as possible. Speaking from experience, avoid over-engineering.

Design Systems function as internal products, however, not everyone will understand the work. If the schedule drags on, you may be appear to be spinning your wheels like a startup creating a product that never gets released. This brews internal misunderstanding and friction but do whatever you can (Internal newsletter? Blog? PowerPoints?) to document your work.

2. First Page Shipped

Nice work! Celebrate! You and your team worked hard to “componentize” a portion of the site and you hit the publish button. Your site or application is no longer a spaghetti mishmash of code, at least one piece is intentionally built and assembled in a reusable, future-looking manner. You’ve learned some lessons, probably have an Interface Inventory, and are sitting atop a giant backlog.

Figure out the fastest path to repeat this success. A proper retro/postmortem would be helpful here. The process probably wasn’t as smooth and labor-reducing as you originally sold it to management, but it’s important to remember that Design Systems are a compounding investment. Step-by-step the process of building new components will speed up. Don’t get overwhelmed by your backlog. Try to find the next release target that allows you to keep good, visible momentum.

3. Consumable in CodePen (outside the main product)

One milestone I always look forward to is being able to use the Design System outside of the main product. For me that target is CodePen, but for you it could be CodeSandbox or getting code up on npm, however you define “quickly spinning up” a new System-based project. Being able to publicly consume a Design System without private repository access or being inside the firewall/VPN lowers the bar for education, onboarding, and experimentation.

If I can hotlink to a public stylesheet or some JavaScript in CodePen, I know that I now have a complete prototyping environment. In this environment I can experiment with changes, identify problems, tweak knobs, and fix visual bugs in a place that doesn’t threaten the production environment. It creates a tactile learning environment that you don’t get from browsing a Pattern Library or Storyboard instance.

It also means you’ve almost completed the adoption story. You have a concrete idea of how to get others up and running. You’ve built a pathway for easier education and adoption of your components.

4. First Non-System Team Consumer

Getting that first email from another department asking about the Design System is a big breakthrough. Celebrate! It means the Design System has graduated from being an internal folder of HTML, CSS, and JavaScript and is now a bonafide product with customers.

At this point you’ll find holes in your process. You’ll feel the “friction” in your documentation. You’ll have to divert resources to education and maybe even establish a cadence of brown bag learning lunches or office hours. Establishing a #help-desk channel on the internal chat app isn’t a bad idea either.

Inevitably, you’ll start getting Feature Requests! Weird, niche requests with varying degrees of UX quality that are either “blocking” or very important (!!!) to managers’ managers. You’ll embark on the messy canonization process and have to learn when to say “yes” and when to say “no”. Opinions and stakeholder concerns increase exponentially.

Onboarding “outsiders” will point out major gaps in your Design System and inform your thinking on how you want to govern the System. It’ll bring up conversations about whether you’re a prescriptive or descriptive Design System and whether that’s good or bad. Do all ideas go in the folder o’ components? What about hurried ideas from new PMs trying to make a splash? What’s your philosophy on rogue one-offs? How are you going to manage one-offs?

Inadequacies in your Design System aren’t clear until “others” from the out-group start using your Design System. This goes for open source code communities too, it’s not until much later in the life of the project that you learn you designed or coded something poorly…

5. First Breaking Change

It’s inevitable. You didn’t think of one of the two billion scenarios which something might be used and it requires a backwards incompatible change or bug fix. It could be a security patch, an accessibility fix, or you straight up designed a component badly and it needs to be refactored with a new API. This situation sucks, but it’s a big growth opportunity.

Does versioning solve this? Do you cut a new component (e.g. HeroNew)? How quick can you turnaround a fix? Do you need to deploy a resource from the Design Systems team to help another team patch the issue? Do you have a list of stakeholders you can notify about this breaking change? How do you communicate and enforce this update so the old bad stuff goes away as quickly as possible?

Dozens of new considerations are born out of this moment. New internal threats may be born! Who possesses the smooth balm of inter-office politicking? These hiccups and process fouls will be hard to overcome, but your project will be forged in the fires of Mount Doom.

Not-so Open Source

In some ways Design Systems are like an open source project being used as a dependency, but I’m also starting to see it as something entirely different. In open source you typically have a BDFL (Benevolent Dictator for Life) model and success is defined by making bought-in users happy while still retaining a lot of the creative direction and control. Whereas an internal Design System typically has layers of management overseeing it and, subconsciously or not, they’re optimizing to make other departments and managers happy.

An open source project may have an easier time getting adoption, because early adopters only see potential. Hype is an insulator. An internal project faces an uphill battle of egos. Designers will invent new buttons. Developers will decide they’re going their own way over any trifling technical decision. If you block another department they’ll go rogue and that’s the last thing you want.

Often, in my experience, for an internal Design System to have widespread adoption it requires a literal executive mandate from the top floor of the building. That’s a critical distinction between Design Systems and open source because some users of the Design System might not be voluntarily using the project. The project management requires a different posture. “If you don’t like it, use something else” is antithetical to the goal of a Design System.

I believe the bulk of the work of a Design System actually starts here. Not with the building of a folder of components but with the outreach, management, sustainability, and incremental improvement work ahead.