As I worked on multiple products at Danchi Design Studio, I found myself repeatedly rebuilding the same UI components from scratch. I found it was frustrating and hard to maintain.
To solve this, I decided to create a unified Design System to make my work more reusable and easier to apply across different projects. My goals were to build something that is:
Scalable across multiple products.
Consistent with the Danchi Design Studio brand standard.
Flexible enough to support each product’s unique needs.
There are many well-known methods and frameworks for building a Design System. However, I don’t believe there’s a one-size-fits-all approach. For my case, I’ve decided to take a more practical route by combining a few ideas that work well together:
Brad Frost’s Atomic Design: This helps structure the system using a hierarchy of elements: atoms (Tokens) → molecules (Components) → organisms (Sections).
Nathan Curtis, a Design System Consultant: I’m using his concepts of design tokens and the idea of separating the system into 2 parts: foundations (for brand-level styles) and components (for product-level elements).
I chose a 2-layer structure to keep designs consistent across products while still allowing flexibility.
The Master Design System (MasterDS) holds the core foundations that every product should share for a unified look and feel.
The Product Design System (ProductDS) builds on MasterDS foundations and allows each product to adapt components based on its platform, interactions, and accessibility needs.
I chose clear, simple naming rules to keep the system easy to understand and scale. The structure is influenced by familiar frameworks like Atomic Design, Design Tokens, and Material Design, which helps maintain consistency and makes the system easier to maintain.
I also considered how the naming could grow in the future, supporting things like dark/light mode (for wellbeing products) and custom themes (for kids’ educational products). For the kickstart of this project, we’re focusing on a simple, clear structure that covers the basic setup. The system will grow and evolve alongside product development.
Below are screenshots of the MasterDS and ProductDS files in Figma. Both are still in early development, and their structure may continue to evolve as the design progresses.
To validate the system from a design perspective, I applied it to the Ticket-booking App’s homepage. This helped me see how well the components worked in a real layout.
Through this process, I learned that using the system in a real product requires ongoing adjustments to both the UI and the system itself. These iterations ensured the ProductDS remained practical, flexible, and aligned with real product needs.
This step also helped me to think from a broader team perspective. When multiple designers work on the same product, we need a clear contribution workflow to support collaboration and maintain consistency.
I collaborated closely with the developers throughout the process. After defining the system structure and naming rules, I checked feasibility with them before building the Figma files. Once the basic components and layouts were ready, I synced again to confirm the files were clear and ready for development.
This ongoing brainstorming, feedback and alignment helped to keep the Design System more practical and functional.