Industry
Fintech
Company
Get Orbital
Role
Product Designer (Sole Designer)
Status
Shipped
Design System Governance
Design System Governance

Context
The design system library existed, but without clear usage standards.
Components were implemented differently across squads, and engineering often made design decisions independently.
Without semantic rules or ownership, the system functioned as a reference library — not an enforced standard.
The design system library existed, but without clear usage standards.
Components were implemented differently across squads, and engineering often made design decisions independently.
Without semantic rules or ownership, the system functioned as a reference library — not an enforced standard.
Component Governance Model
Component Governance Model
Introducing systematic governance across our Client Portal platform.
Introducing systematic governance across our Client Portal platform.

From Component Library to Governance Framework
From Component Library to Governance Framework

Before
A visual design library without documented usage standards.

After
A structured governance system defining semantic intent, accessibility compliance, and implementation logic.
A visual design library without documented usage standards.
A structured governance system defining semantic intent, accessibility compliance, and implementation logic.


Before
After
A structured governance system defining semantic intent, accessibility compliance, and implementation logic.
A visual design library without documented usage standards.


Before
After
Approach
The issue wasn’t missing components — it was missing governance.
I formalised usage standards, semantic colour intent, and system layering to eliminate interpretation drift.
The issue wasn’t missing components — it was missing governance.
I formalised usage standards, semantic colour intent, and system layering to eliminate interpretation drift.
System Scope
Governance introduced across core product layers:
Navigation → Data Display → Feedback → Controls → Complex Patterns
Governance introduced across core product layers:
Navigation → Data Display
→ Feedback → Controls
→ Complex Patterns
System Structure
To prevent interpretation drift, I separated foundations (tokens, grids), reusable UI (components, patterns), and usage governance (guidelines). This made application logic explicit across teams.
To prevent interpretation drift, I separated foundations (tokens, grids), reusable UI (components, patterns), and usage governance (guidelines). This made application logic explicit across teams.
Establishing Governance Foundations
Establishing Governance Foundations
Semantic Colour Governance
Colour was redefined by intent (Primary, Success, Warning, Error) and validated to WCAG AA.
Decorative usage was replaced with enforced semantic meaning.
Colour was redefined by intent (Primary, Success, Warning, Error) and validated to WCAG AA.
Decorative usage was replaced with enforced semantic meaning.

Colour governance introduced semantic intent and accessibility validation beyond the original palette structure.
Colour governance introduced semantic intent and accessibility validation beyond the original palette structure.
Component Governance — Banner System
Banner variants existed in the system but lacked defined semantic rules.
I formalised severity usage, interaction behaviour, and contextual placement to prevent inconsistent signalling across features.
Banner variants existed in the system but lacked defined semantic rules.
I formalised severity usage, interaction behaviour, and contextual placement to prevent inconsistent signalling across features.

Banners do not have hover or focus states. Only action elements within the banner respond to interaction.
Banners do not have hover or focus states. Only action elements within the banner respond to interaction.
Impact
The design system evolved from a loosely referenced component library into an enforced internal standard.
Reduced UI implementation variance across engineering squads
Established shared semantic language between design and development
Enabled non-product teams to implement UI consistently without design intervention
Shifted the system from visual reference to governed application logic
The design system evolved from a loosely referenced component library into an enforced internal standard.
Reduced UI implementation variance across engineering squads
Established shared semantic language between design and development
Enabled non-product teams to implement UI consistently without design intervention
Shifted the system from visual reference to governed application logic
Explore the Full Governance Documentation
Explore the Full Governance Documentation
The complete component usage standards, semantic token structure, and implementation guidelines are documented in Figma. → View Design System Governance Documentation
The complete component usage standards, semantic token structure, and implementation guidelines are documented in