Establishing a design foundation to bridge gaps, reduce inconsistencies, and bring alignment across teams.
During a preliminary audit, I identified significant inconsistencies across the product interface, including variations in button styles, typography, status indicators, and layout hierarchy. These discrepancies not only created a fragmented user experience but also posed challenges for scalability and efficient developer handoff.
Learning the basics of a design system
This was my first time working on something at this scale, which meant building a design system entirely from scratch. I didn’t have a reference point, just a cluttered product and a blank Figma file.
The screens were all over the place - buttons, text styles, spacing, and icons lacked consistency. I wasn’t sure where to even begin. I started looking at established design systems from companies like Google, Apple, and Shopify, but those felt too big and irrelevant for where we were. What really helped was discovering Practical UI and learning about Atomic Design. Breaking things down into atoms, molecules, and organisms gave me the structure I needed to make sense of the chaos.
Laying the Foundation
Before diving into components, I focused on building a strong visual foundation, starting with a color system from scratch that, while time consuming, paid off across every screen and style.
Why HSB?
We needed a system that scaled and stayed consistent across components and states. Using HSB (Hue, Saturation, Brightness) color system made it easier to define and expand color variations from a single base, without starting from scratch each time.
Once the color system was locked, I applied the same thinking to other foundational elements. Each of these followed clear patterns, ensuring design and development could stay in sync.
TOKENS
I introduced semantic tokens early on to keep things scalable and consistent. They acted as a shared language between design and engineering, and gave the system room to grow.
I focused on foundational tokens (like colors, type, and spacing) and kept the structure flexible enough to support component-specific tokens later.
ACCESSIBILITY CONSIDERATIONS
To ensure clarity and usability across the system, all foundational styles including colors, typography, and tokens were tested for WCAG 2.1 AA compliance.
This established a consistent baseline for readable contrast and inclusive design from the start.
Building Components at Scale
Next, I moved on to components. Instead of designing everything at once, I focused on the most-used and most-needed elements. I followed Atomic Design [atoms → molecules → organisms → templates] and built:
Atoms: buttons, text inputs, checkboxes
Molecules: file upload, input with labels
Organisms: modal dialogs, tables
Templates: basic form layouts, directory, cards
The core library I delivered included:
Alert, Badge, Buttons, Checkbox, File Upload, Modal Dialog, Tag, Table, Text Input
DESIGNING FOR STATES AND REUSE
Every component came with clearly defined states: default, hover, pressed, focus, and disabled. I built each one to be visually consistent and easily swappable in Figma using Variants. This made prototyping interactions and managing edge cases smoother.
I also documented usage guidelines to reduce ambiguity, ensuring anyone using the system knew when and where to use each variation.
Bringing it all Together
To put the design system into practice, I redesigned three key product screens using the new foundations and components. These were not final screens since the product data was still evolving, I worked with dummy content to demonstrate how the system could be applied. The goal was to create a reference for future designers and validate that the system was scalable, flexible, and easy to implement in real workflows.
