Design System
As I developed my UI skills, I realized that creating beautiful screens wasn't enough; I needed to understand how they scale. I created this design system as a self-initiated challenge to bridge the gap between static design and a living product.
Instead of designing for a specific client, my "client" was consistency. I studied industry standards like Material 3 by Google and Carbon by IBM to understand how to build a system based on tokens, reusable components, and strict accessibility standards.
How can a design system improve consistency, speed, and clarity across a growing digital product?
The Foundation
Before building any components, I defined the "physics" of the system, the rules that make every screen look related.
Color & Tokens
I moved beyond simple Hex codes and established a Token-based color system. By setting up variables in Figma, I ensured that changing a "Brand" color in the settings would instantly update every component in the file.
-
Brand Colors: Defines the primary identity (Blues).
-
Semantic Colors: Functional colors for Success (Green), Error (Red), and Warning (Yellow).
-
Neutrals: A balanced grayscale for text and backgrounds to maintain hierarchy.
Brand Collection
This collection holds the raw values of the brand identity. It defines the specific Hex codes for our palette (Blues, Reds, Greens) and font families (Poppins, Inter). These are the "primitive" values that feed the rest of the system.
Alias Collection (The Broad Roles)
Here, I grouped the brand colors into broader categories. Instead of using specific shades like Blue/500, I created aliases like Primary and Neutral.
This layer acts as a bridge, allowing me to swap out the entire brand palette without breaking the functional connections downstream.
Mapped Collection (The Semantic Functions)
This is the "brain" of the system. I assigned specific colors to specific functions on the interface. I never apply a color randomly; I apply it based on its job:
-
Text: text/body, text/headings, and text/action ensure hierarchy.
-
Surface: surface/primary etc defines background layers.
-
Interaction: action-hover, disabled states etc are pre-defined.
By using semantic names, the system is self-documenting. A developer knows exactly that text/action is for clickable links, regardless of what color it actually is.
Responsive Collection
Finally, to ensure the design adapts across devices, I created a responsive collection for numbers. This handles Spacing, Font Size, and Line Height. By tokenizing these values, I can adjust the density of the entire application for mobile or desktop from a single control panel.
Typography
A clear typographic hierarchy was established, with font properties designed to improve legibility at various text sizes, ensuring seamless adaptation across different device sizes.
All typography properties such as font size, weight, and line height are stored as tokens (variables). This allows:
-
Quick updates to all screens
-
Adaptability for future themes
-
A centralized, maintainable system
Component Library
Once foundations were in place, I built a small but realistic set of components, including:
Button Component
I designed buttons not just as flat images, but as interactive components. I utilized Figma's Component Properties to easily swap between styles (Primary, Transparent, Outline) and states (Hover, Disabled, Focus).
Menu Component
To handle density, I created a modular menu system. The dropdowns utilize the foundational spacing tokens to ensure clickable areas are large enough for mouse and touch targets.
Input Field
I created input fields that account for the entire user journey. This includes specific states for "Focus" (to aid accessibility) and error handling.
Tab Bar Component
To keep the system modular, I used a Base Component architecture for the navigation.
-
The Base (.item): I created a private utility component to define the individual tab states (Active vs. Inactive).
-
The Container: I nested these items into the main Tab Bar component.
-
Nested Properties: I exposed the properties of the .item up to the parent level. This allows a designer to swap icons or change the "Active" tab directly from the main Tab Bar panel without clicking deep into the layers.
Contact Us Form
A design system is only useful when applied to real interfaces. I utilized the atomic components to build out a realistic Contact Us form. This validated that the mapped tokens (like text/body and surface/page) worked harmoniously together to create a clean, accessible layout.
Key Learnings
1. Design tokens are the real backbone of a design system.
Foundational tokens make the system scalable, maintainable, and developer-friendly.​
2. Naming conventions matter.
Semantic naming (e.g., button/primary/hover) helps prevent confusion and speeds up handoff.​
3. Components become easy once the foundations are solid.
Building tokens first meant components almost built themselves.​
4. A good design system evolves.
Even a small system benefits from iterating, refining values, and improving structure.
5. Consistency leads to speed.
With tokens in place, designing new screens becomes faster and more efficient.
Reflections
This project gave me hands-on experience in building a design system from the ground up. While small in scope, it follows professional principles: token-driven structure, scalable components, and consistent foundations. It strengthened my thinking not just about UI, but about systems, structure, and long-term design quality. The system is still evolving, and I’m continuously learning and refining it as I gain more experience.