What is a design system?
A design system can mean different things to different people. It could be a pattern library, a style guide, a set of guidelines. The delivery method can vary as well: Storybook, Figma, Zeplin, a simple PDF, the options are endless.
For me, a design system is a collection of these things, all nicely packaged up.
It's a collection point for code, design, layouts, icons, style guides and branding.
The most important thing is that it's a single source of truth.
An evolution
Design systems can be tricky.
Sometimes you get there step by step, figuring out along the way what works for the team.
1. Zeplin
When starting from scatch, use what's available to you. Zeplin is a great resource for creating a library of components.
At this stage devs were not using re-usable components in their work, so for the time being Zeplin is the source of truth for developers, while Sketch components that are published to Zeplin are the source of truth for designers.
2. Zeplin → Storybook
You can't do it alone.
A pretty component library is great, but without a supportive dev team a design system is hard work.
Lucky for me, a talented dev on the team took the initiative and created our first re-usable component library using Bit and rendering in Storybook.
I was now able to link directly to Storybook from my Zeplin components.
3. Storybook documentation
We now had a live design system with devs starting to incorporate components into their work. But was it a true design system yet?
A design system needs documentation - where a component is used, how it should be used, and notes on accessibility.
I could write all these things, but it wasn't appealing to me to have to ask a dev everytime I wanted to update information.
I'd had experience with repos before, and while I'm not a dev I can figure out a lot of things, so I was onboarded on how to use markdown and create skeleton pages for upcoming components.
After creating these items I would then go through the approval process like a dev to get my work published.
4. Processes
We now had a fancy new design system, the hard part was over right?
Unfortunately not.
How do you manage change requests, approve new components, and enforce standards?
This is really where you need to work together with a dedicated dev who is willing to take ownership with you. I'm not as technical as I want to be so there's only so much I can do to ensure the system is working as efficiently as possible.
Therefore a process was put in place:
- A pull request was created and the changes or new components were published to storybook
- I would check over the changes from a UI perspective and add comments
- If the change was approved in the comments, the lead dev would then check over the code to make sure everything was up to standard
- Once happy the lead would approve the PR and merge
- Any bugs or updates were raised as an issue in GitHub