Building a Design System for a SaaS Product: Lessons from Socialchat.id

When I joined PT Booster Teknologi Indonesia as UI/UX Designer for Socialchat.id, the situation looked like this: no design system, no component library, every page designed independently.

The result? Buttons with 5 different color variations, inconsistent spacing, and too much variation in font sizes. The user experience was fragmented.

Within 6 months, I built a design system from scratch. Here’s what I learned.

Start with Tokens, Not Components

The first mistake many people make: jumping straight to building components. The right approach is to start with design tokens — the primitive values that form the foundation of everything.

Color Tokens

Primitives (don't use directly in components):
  blue-500: #3B82F6
  zinc-900: #18181B
  zinc-400: #A1A1AA

Semantic Tokens (use these in components):
  color-primary: {blue-500}
  color-background: {zinc-900}
  color-text-muted: {zinc-400}

With semantic tokens, if you want to change the primary color from blue to purple, you only change one value — all components update automatically.

Spacing Tokens

base: 4px

xs:  4px  (1x)
sm:  8px  (2x)
md:  16px (4x)
lg:  24px (6x)
xl:  32px (8x)
2xl: 48px (12x)
3xl: 64px (16x)

Typography Scale

Display: 48px / 700 / -0.03em
H1:      36px / 700 / -0.02em
H2:      24px / 600 / -0.01em
H3:      18px / 600
Body:    14px / 400 / 1.6
Caption: 12px / 400 / 1.5

Component Structure

I followed atomic design but with modifications:

Tokens (primitives)
  └── Atoms (Button, Input, Badge, Avatar)
        └── Molecules (SearchBar, FormGroup, UserCard)
              └── Organisms (DataTable, ConversationList, Navbar)
                    └── Templates (DashboardLayout, InboxLayout)

Example: Button Component

Button
├── Variant: Primary | Secondary | Ghost | Danger
├── Size: sm | md | lg
├── State: Default | Hover | Focus | Disabled | Loading
└── Icon: Left | Right | Icon only

Every combination needs to be designed and documented. So: 4 variants × 3 sizes × 5 states = 60 frames for the button alone.

Naming Convention

Consistent naming is critical for smooth developer handoff:

Format: [Category]/[Component]/[Variant]/[State]

Examples:
  Form/Input/Default/Focused
  Feedback/Badge/Success/Default
  Navigation/NavItem/Active
  Data/Table/Row/Hover

Documentation That’s Sufficient (Not Excessive)

Design system documentation is often too long and goes unread. What worked best at Socialchat:

For each component, document:

1. When to use this vs. alternatives
2. Do’s and Don’ts (visual, not long text)
3. Accessibility notes (contrast ratio, keyboard nav)

Mistakes I Made

1. Over-engineering at the start

I spent 2 weeks building a “perfect” token structure before a single component existed. Pragmatism works better: start with what’s needed now, refactor later.

2. Not involving developers from the beginning

A great design system in Figma doesn’t automatically translate to easy implementation. Involve developers from the start to ensure token names and component APIs make sense in code.

3. No governance

Who can add new components? Who approves changes? Without this, the design system becomes chaotic.

Final Results

After 6 months:

• 80+ components documented
• 5 product modules using the same design system
• Design time for new pages dropped 60%
• Visual consistency improved dramatically

A design system isn’t a one-time project — it’s an ongoing investment. But the ROI becomes very tangible as the product starts to scale.