Design System
One token library, one component set, one shared language built to unify every enterprise product
Design Systems
Enterprise · Foundations
Type
Product Designer
Scope
8 weeks
Platform
2 Enginners, 1 PM, me
Domain
Web
Enterprise Design System
One token library, one component set, one shared language built to unify every enterprise product and make inconsistency structurally impossible.
Role | UX Designer — End-to-end |
|---|---|
Tools | Figma Variables · Auto Layout |
Timeline | 6–8 months |
Serves | RMS · PeopleAssist AI · SDI + all downstream products |
Coverage | 20+ Components · Foundations · Core Components · Data · Templates |
First thing first — "reasons" — why it was needed?
Across the enterprise product suite, every designer was solving the same foundational problems independently choosing their own colours, sizing their own buttons, naming their own components. Every developer was rebuilding the same dropdown from scratch. The same status colour meant different things in different tools. Every sprint absorbed time that should have gone to product problems, not infrastructure decisions already made somewhere else.
Being a growing team, we didn't have a proper design system in place so we built one. It's what now keeps our visual hierarchy and data alignment consistent across every screen.
UX Audit
Overall Colour Contrast and Visual Hierarchy
No Visual Hierarchy Inconsistent typography in page & section titles, table titles, filters, and tabs reduces clarity and weakens visual hierarchy. Misplaced status elements make it harder for users to identify key information quickly.
Colour Contrast & Overuse of Red Screens lacked sufficient colour contrast, affecting readability and accessibility. Primary colour (red) was heavily used across statuses, alerts, and CTAs it should be reserved for highlighting priority actions where user attention and interaction are required.
Best Practices
Consider colour saturation: bright colours naturally stand out, so use them for important items; less-saturated colours for items of lesser importance. Reserve warm bright colours, like red, for warnings or errors.
Don't use too many colours: limit colour use to 2 primary and 2 secondary colours per screen.
Don't use too many contrast variations: use no more than 3 contrast variations for complex designs.
Do not rely only on colour to communicate visual hierarchy people with colour blindness may not perceive differences between certain colour combinations.
UX Audit — Tables
Header Styling Variations
Some tables had highlighted headers while others didn't, making it hard to distinguish structure. Violated Consistency & Standards (Jakob's Law) users expect uniform patterns.
Inconsistent Row Heights
Uneven row heights disrupted scanning and created visual noise. Violated Aesthetic and Minimalist Design consistent row height creates rhythm and predictability.
Inconsistent Data Alignment
Data was left-aligned in some tables and centre-aligned in others. Left-aligned text supports faster scanning, especially for text-heavy or mixed-data tables.
Best Practices
Standardise header design: uniform header backgrounds, font weights, and spacing improve recognition and reduce confusion.
Fix row heights: apply consistent row height across tables for better visual flow and scannability.
Align headers and data: ensure proper alignment so users can intuitively associate column titles with their content.
Use left alignment for most data: right alignment should be reserved for numerical, centre for symmetrical data only (e.g. status icons).
Goal
Build a clean, reusable and easily accessible system which makes components consistent throughout the product.
We didn't want people to detach components and use them separately so we created scalable, tokenised components that enforce consistency by architecture, not by agreement.
Colour Palette
Every colour has a semantic role
We followed the WCAG colour contrast ratio of 4.5:1 for smaller text and 3:1 for larger text for better accessibility. No component ever references a raw hex value every colour passes through the semantic token layer.
Brand Blue #2A8C8C - Primary · Actions · Links
Deep Blue #1B2A3B - Hero · Sidebar · Headings
Yellow #E8A020 - Accent · Logo · Highlights
White #FFFFFF - Surfaces · Cards · Base
Orange #C4621A - Warning · Escalation
Purple #6E4FC4 - System · Automated
Green #3D8B5E - Success · Confirmed
Red #C23B3B - Error · Critical only
Dark Grey #2E3440 - Primary text · Labels
⚠️ Secondary colours limited to ≤20% of visual space per screen. Red reserved exclusively for errors — never as a data series or decorative element.
Primitive → Semantic → Component Token Architecture
Layer 1 · Primitive Tokens - brand-blue-500 · brand-blue-700 · brand-yellow · brand-green · brand-red · brand-orange
Layer 2 · Semantic Tokens - color/action/primary · color/status/success · color/status/error · color/status/warning · color/system/auto · color/surface/disabled
Layer 3 · Component Tokens - button/primary/bg · chip/success/bg · input/error/border · alert/warning/fill · flow-node/system/fill · button/disabled/bg
Typography
Inter + DM Sans
Designed to be both functional and accessible with the aim for WCAG contrast ratio of at least AA. Primary information such as headers will track the strongest contrast. Primary colours are used sparingly.
Display · 48–72px - inter · 800 · −0.04em · Line height 1.0 - Hero heading, Hero / Page title
H1 · 32px - Inter · 700 · −0.03em · Line height 1.1 - Section heading, Major sections
H2 · 24px - Inter · 700 · −0.02em · Line height 1.2 - Sub-section heading, Card titles
Body · 16px - DM Sans · 400 · 1.65 line height - Body · Paragraphs
Body Sm · 14px - DM Sans · 400 · 1.6 line height - Captions · Helper text
Label · 11px - DM Mono · 500 · +0.18em · CAPS - Tags · Chips · Semantic token / status label / overline
Spacing & Grid
8-point base unit
We used a 12-column grid system to make designs responsive 12 is highly divisible (by 2, 3, 4, 6). All spacing elements abide by a rule of 8. This ensures further consistency and alignment for complex layouts, and makes development handoff significantly easier.
Spacing Scale (Figma Variables) spacing/xs 4px · spacing/sm 8px · spacing/3 12px · spacing/md 16px · spacing/lg 24px · spacing/xl 32px · spacing/2xl 48px · spacing/3xl 64px · spacing/4xl 96px
Grid System 12 columns · 24px gutter · 64px margin
Border Radius Tokens radius/xs 2px · radius/sm 6px · radius/md 12px · radius/lg 20px
How We Defined the Components
Naming Convention
Naming convention followed for colour tokenisation of components: Button / Primary / Default / Text each component carries its size/state grid: Default, Hover, Disabled across Primary, Secondary, and Tertiary variants.
For every component we added: variants, states, anatomy, size, style, and detailed measurements (whatever applicable).
References followed: states and sizes from Material Design, Carbon Design System, Goldman Sachs, Salesforce Lightning aligned with our dev team's existing library usage.
UI Components
A Glimpse of What I Built
Status Chips all semantic variants: Confirmed · Action Required · Error · In Progress · System Processing.
Data Table Component left-aligned text, semantic status chips, consistent row heights.
Date Range Picker month view with multi-select capability.
Documentation & Usage Guidelines
Built for the Next Designer
For every component we added: variants, states, anatomy, size, style, and detailed measurements (whatever applicable) so that anyone can use them from day one without breaking consistency.
We took reference from Material Design, Carbon Design System, Ant Design System as our dev team uses the material library — ensuring the design system and component library spoke the same language.
Button — Component Spec
Attributes Container height (regular) 44px · Container height (large) 48px · Container height (small) 36px · Container shape: 4px corner radius
Label 14px · Medium font size
Padding Left/right padding (regular) 24px · (large) 24px · (small) 16px
Icons Left icon size 20px · Right icon size 20px
Token Bindings Background: color/action/primary · Text: color/surface/white · Border radius: radius/sm
How the "System" Is Maintained
One Folder. Everything Linked.
One folder: "Design System" where we documented all UI components. Each file has a Link Index so that navigation between components is always accessible from a single source of truth.
Foundations - Colours · Typography · Spacing · Icons
Core Components - Matrix · Heatmap charts
Tables - Standard · Expanded · With pagination
Templates - Header · Filters · Mega menu · Footer
Links Index - Master navigation across all DS files
UI Components — Before & After
UX Research - Behind the Scenes
We Did Intense Secondary Research While Building the System
Brands explored how leading systems handle colour & components: Material Design (Google) · Carbon DS (IBM) · Goldman Sachs DS · Salesforce Lightning · Uber Base DS · Ant Design System.
Goal:
How component states and sizes are defined across enterprise systems
How tokenisation is structured from primitive to semantic
What documentation depth is required for reliable developer adoption
Observation:
All leading systems use a primitive → semantic → component token hierarchy not flat colour application
Components are only considered complete when every interactive state is documented
The systems with highest adoption rely on white space and neutral tones with colour used strategically, not emotionally
Impact — What We Achieved
The Numbers
100% - Consistency throughout all dashboard and product designs across the suite
2× - Collaboration with developers became better complete specs eliminated Slack clarification queries
3× - Increased project delivery speed foundational decisions made once, reused everywhere
My Learnings
What This Project Changed
Scalable Component - Built components using atomic design principles atoms → molecules → organisms. So that components can scale to any new product without rebuilding from scratch.
Documentation - Added detailed documentation for all components variants, states, anatomy, measurements, and token bindings. So anyone can use them from day one without breaking consistency.
Dev Collaboration - Worked closely with developers and explained how Figma Variables map to code tokens so they could build fast, reference once, and never re-ask the same implementation question.
"A design system isn't a project you finish. It's the infrastructure decision you make and then spend every subsequent project either benefiting from, or paying the compound interest on having skipped."
— Charan Raj · Enterprise Design System · 2024
Concept Case Study · Anonymized from real work · Client details available privately on request
