One of the things we do at work we writing new UI components is create unit tests and stories to validate + illustrate the functionality of what we’ve created.
It works well as a process, since it forces us to think about how components could be reused across different apps and not have it defined by specific business logic. This encourages components to be reused in the future, rather than having to reinvent the wheel with each new project.
There are many mature examples of this in different design systems. Polaris by Shopify is one such example, which is still tightly coupled with Shopify as a product but allows anyone to see each component as a sum of smaller pieces. Something like Polaris has a tight, consistent design because of this, and you can feel how each component has had a lot of thought and effort behind it.
I hadn’t known about this approach until recently, which is known by some as “atomic design”. When I was learning about UI and UX a few years back, I genuinely thought that designs systems were born out of a product, not the other way round. You would design your product first, then break it down to the component level to create your design system.
Looking at what I used to do when designing apps or tools, it seems crazy to me that I wasn’t doing this. It makes so much sense from a consistency and development point of view, and it’s evident in my early work that this was affecting me (although at the time I did not know this).
I love the idea of developing a mini design system that I can utilise for various web projects. I feel as though having the added restriction of only being able to use a select set of components would actually open up a lot of creative possibilities, and would also (hopefully) result in me being able to finish things faster.
Let’s see how it goes.