The most important thing about maintaining a design system is not about the design system itself but the mindset you adopt when you approach building new components.
I know, I know.. But please hear me out.
If we think of components in the same way we think about building new features for users, first and foremost we want to identify the problem we are trying to solve (starting with user needs - in this case, also our needs as designers) and assess if we already have a component that does that.
Building a lot of components without assessing what is already there and what problem it will help to solve, is a similar pitfall that the Waterfall approach presents to design and development.
We end up with a lot of features but not necessarily the most useful ones.
My approach is strongly grounded in Design Thinking, not just when it comes to designing and doing research but also when it comes to tasks such as maintaining design systems.
Unfortunately, I cannot share the design systems that I worked with here, but here are a couple style guides I have created for my projects:
This is one of the first style guide I have created and is also a part of a case study project Bright Minds that you can find here.
This style guide also includes spacing and sizing references, which has been immensely helpful to keep my designs consistent (ensure UI is not cluttered) but also making it easier for developers to have a reference to the spacing system I am using.
As you can see some components here also have dark/light mode. This is something I am closely familiar with in more extensive design systems but also in the design systems of others, such as IOS from which I often pull specific components.
In this case, I was aiming to recreate a holistic experience for testing so adding the native IOS components made the experience more realistic, but also helped to test features like subscribing to calendar and user’s behaviour with that interaction end-to-end.