HomeAboutResume
Enterprise ยท Design System ยท Fintech Platform

Rebuilding the Foundation: Design System v1.0 โ†’ v1.5

The product couldn't stop. But the system was breaking it quietly โ€” hardcoded values, duplicate components, inconsistent states, and a Figma file nobody trusted. I rebuilt it from the ground up without pausing a single sprint.

RoleProduct Designer
PlatformWeb App
Versionv1.0 โ†’ v1.5
Tokens472 total
Design System โ€” Token Architecture
Layer 1 โ€” Primitives ยท 184 tokens
--n-000#FFFFFF
--n-900#131313
--p-500#32FC9C
โ†“
Layer 2 โ€” Semantics ยท 288 tokens
--bg-primary-weakestp-100
--fg-primary-defaultp-500
Back to Work
01 โ€” Context

When the Foundation Breaks, Everything Built on It Does Too

PT Praisindo Teknologi builds an investment management platform for retail and institutional users โ€” a product where trust, clarity, and precision are table stakes. When I joined, the design system had grown organically and painfully.

Every screen had its own hardcoded color values. Components were copy-pasted and modified slightly โ€” creating a maze of near-duplicates. Developers couldn't trust the Figma files. Every handoff became a long clarification conversation about which version was "real."

The core constraint: The product couldn't stop shipping. I had to rebuild the entire design system in parallel with ongoing feature development โ€” without creating regressions, blocking the team, or missing sprint deliverables.

Before โ€” DS v1.0 Pain
  • Colors and spacing hardcoded per screen
  • Components duplicated 3โ€“5ร— across pages
  • No naming convention, layers mostly unnamed
  • No states (hover, disabled, error) on components
After โ€” DS v1.5 Foundation
  • Primitive โ†’ Semantic token hierarchy
  • Single source of truth for all components
  • Consistent BEM-style naming convention
  • Complete state coverage for every element
184
Primitive Tokens
288
Semantic Tokens
30+
Components Rebuilt
v1.5
Current Version
02 โ€” Token Architecture

The Two-Layer System That Made Everything Possible

The old system had no token layer โ€” every value was hardcoded directly in components. The new architecture follows a deliberate two-layer system: Primitive โ†’ Semantic.

Layer 1 โ€” Primitives ยท 184
--n-000#FFFFFF
--n-900#131313
--p-500#32FC9C
โ†’ alias
Layer 2 โ€” Semantics ยท 288
--bg-primary-weakestp-100
--fg-primary-defaultp-500
--fg-error-defaulterr-500

Core principle: Components consume Semantic tokens only โ€” never Primitives directly. A theme change or brand refresh requires updating exactly one alias, not hunting through every component in the file.

03 โ€” Component Library

Rebuilding 30+ Components Without Breaking the Product

I audited every legacy component against the new token system, identified inconsistencies, and rebuilt where needed. The process: reference โ†’ audit โ†’ rebuild โ†’ document โ†’ release.

Button Component Rebuilt

The original had zero variant consistency. The rebuilt component creates a single, extensible foundation with all interaction states fully implemented.

5
Colors
3
Styles
6
States
Input Field Improved

6 interaction states โ€” each with label, helper text, and optional icon variants. Standardized error states across the entire product.

๐Ÿ”’ Specific UI screenshots are masked due to NDA. All structural decisions and token references are fully documented in the internal Figma system.

04 โ€” Scalability

Light/Dark Mode as a Token Swap

Adding full light/dark mode support required zero component changes. Every component already consumed semantic tokens โ€” switching themes meant updating token values at one layer only.

DS v1.0 โ€” Style-based
Dark theme? Redesign everything.
Components had hardcoded color values. Adding a dark theme meant duplicating every component manually.
button { background: #32FC9C } .dark button { background: #1db97a }
DS v1.5 โ€” Token-based
Dark theme? Swap one layer.
Components consume semantic tokens only. Theme switching is a single variable swap at the root.
button { background: var(--bg-primary-default) } [theme="light"] { --bg-primary-default: #1db97a }
05 โ€” File Structure

From Organic Chaos to Intentional Architecture

The new structure follows a numbered, layered convention any team member can navigate within seconds of opening the file.

Before โ€” Organic Chaos
๐Ÿ“ Design System โ””โ”€โ”€ Components โ””โ”€โ”€ Logo โ””โ”€โ”€ Typography
After โ€” Intentional Structure
๐Ÿ“ Design System v1.5 โ””โ”€โ”€ ๐ŸŽจ 01 ยท Tokens โ””โ”€โ”€ โš™๏ธ 03 ยท Components โ””โ”€โ”€ ๐Ÿ“‹ 04 ยท Patterns
06 โ€” Outcomes

What Changed When the Foundation Was Solid

Area Result Meaning
Total token coverage 472 tokens Fully named, organized, and documented
Component states Complete Hover, focus, active, disabled, error, loading
Theme support Light + Dark Zero component changes needed
Designer velocity ~3ร— faster Finding and applying components is now structured
07 โ€” Reflection

What This Project Taught Me About Scale

Insight 01
Systems thinking
How does this decision scale across 50 screens and 12 months of future features?
Insight 02
Tokens are key
The semantic layer makes every design decision reversible and maintainable.