It's funny to think about a time when the concept was nascent.
I remember creating UI style guides paired with a brand guide and then throwing it over the fence to let the developers figure it out.
We've come a long way.
I've built many design systems from scratch, remixed a bunch, and worked with good (and very bad) ones belonging to some notable companies.
Here are a few takes and tips that I can provide from my experience.
Designs systems are only as useful as it is usable for those implementing it
A design system is just one approach to product development that makes it easier to communicate ideas for implementation. You create artifacts, organize them, and share them to communicate your designs to an engineer, designer, and product manager to execute.
Thus, it is essential to acknowledge just creating a design system isn't the goal. The goal is to get across your ideas clearly and consistently.
Here's a list of things I'd suggest you put that additional effort into as you're working through developing your system:
Organization is a superpower
Make things easy to find. This begins at the top level with a good team and file structure for projects and consistent naming conventions. Spotify has a great example of how they structure their projects in Figma. You can check it out here.
Then, more granularly, naming things consistently on the component level is a godsend. I generally follow a structure similar to this: Category / Type / State / Version. An example would be you have a button with multiple states. You'd want to name it something like Button / Small / Hover / v1. Make sure you use the "/" separator because this is optimized for the Figma instance swap feature. It'll make it easier to search and swap your components.
Good version control helps tell the story
I can't express enough how important it is to have a single source of truth but also a track record of where you've been.
One reason being it's very easy, especially with multiple designers, product managers, and engineers collaborating for things to slip through the cracks. It becomes difficult to track the state of the system. You lose designs, flows, components and constantly have to point people back to where things are.
Another reason is you want to be able to explain the journey of the designs easily and how they got to where they did so, there's no redundant exploration or questioning of decisions.
Figma has a built-in function for version control, but I mainly use this as a safety net. What you want to do instead is create a file structure that clearly defines what something is:
Have an agreed-upon process for feedback, updating, and communication
A defined process is the needle that threads all of the work together. This falls into the world of Design Ops, and you'll likely split duties with others. But, you want to make sure that there is a clearly defined written SOP on how designs move from one stage to the next, when and who you're pulling in at what stage, how you're gathering feedback, and how to communicate best and track the implementation of that feedback.
Setting guidelines will help your direct team members and save you the headache from dealing with external or low-touch contributors.
The design system should change from mobile to web
This is obvious, but I've seen too many cases where designers try to force-fit cohesiveness between web and mobile. Whether due to laziness or pressure, we have to acknowledge that different form factors intrinsically require different needs.
Don't use a component or interaction that works well on the web if it doesn't make sense on mobile. It's ok to deviate if justified. Document why and share your position with your team.
Accessibility matters, dark patterns matter
All great designers are great users. And to be a great user, the product has to be usable and trustworthy.
This begins with ensuring that your product is conducive to the user's intentions and aspirations and leveling the playing field for all.
The vibe should always be collective co-creation
Building a company, product, or team is all about the people making it and who it ultimately serves. A design system is no different.
Thus, it would help if you always worked with the mindset that the design system is built upon and for collective ownership. It does not belong to you, him, her, or me.
We all play a role in its existence, and when we understand that, it can improve.
Hand-off should be less of throwing it over the fence and more of a continuous, collaborative moment
Throwing work over the fence is the worst operational process and philosophy ever, especially if you expect the product and users to be evolutionary and not something indifferent to change and time-sensitive.
I love this graphic from Daniel Eden on how design fidelity should scale alongside engineering, not bifurcated into two cycles.
This helps maintain expectations, contributes to less compromise and infighting, and ultimately yields higher quality work because everyone works in tandem and is on the same page.
Balance enforcing with exploration
Design systems limit creativity.
The goal of a design system is to create a unified visual language that helps us work and iterate quickly while maintaining cohesiveness. But naturally, we have a tendency to go rogue because we might think we know of a better solution, or it might be more cumbersome to adopt an institutionalized system than to leverage what we're already comfortable with. This is the paradox of design systems.
My advice is to keep exploring but to carve out ownership and a motivation to evolve the system.
It will feel like an uphill battle at times, but cooperation and open contribution is the name of the game and will ultimately lead to better outcomes.
The system should be more of a framework than a doctrine
At the end of the day, a design system is just a means to an end. It is not a one-size-fits-all, even though it aims to be.
Things will change as the product evolves. It's essential to establish flexibility and versatility within the system and the processes that manage it.
Experiment often, track the impact and iterate. Your team and your users will thank you for it.
Thanks for reading.