Membangun Design System untuk Produk SaaS: Pelajaran dari Socialchat.id

Ketika saya mulai sebagai UI/UX Designer di PT Booster Teknologi Indonesia untuk Socialchat.id, situasinya seperti ini: tidak ada design system, tidak ada component library, setiap halaman didesain secara independen.

Hasilnya? Button dengan 5 variasi warna yang berbeda, spacing yang tidak konsisten, dan ukuran font yang terlalu beragam. Pengalaman user jadi fragmentasi.

Dalam 6 bulan, saya build design system dari nol. Ini yang saya pelajari.

Mulai dari Token, Bukan Komponen

Kesalahan pertama banyak orang: langsung bikin komponen dulu. Yang benar adalah mulai dari design tokens — nilai primitif yang jadi fondasi segalanya.

Color Tokens

Primitives (jangan dipakai langsung di komponen):
  blue-500: #3B82F6
  zinc-900: #18181B
  zinc-400: #A1A1AA

Semantic Tokens (pakai ini di komponen):
  color-primary: {blue-500}
  color-background: {zinc-900}
  color-text-muted: {zinc-400}

Dengan semantic tokens, kalau mau ganti warna primary dari biru ke ungu, cukup ubah satu nilai — semua komponen otomatis update.

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

Struktur Komponen

Saya ikuti atomic design tapi dengan modifikasi:

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

Contoh: Button Component

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

Setiap kombinasi harus didesain dan dokumentasikan. Jadi: 4 variants × 3 sizes × 5 states = 60 frame untuk button saja.

Naming Convention

Konsistensi naming sangat penting supaya handoff ke developer smooth:

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

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

Dokumentasi yang Cukup (Tidak Berlebihan)

Dokumentasi design system sering terlalu panjang dan tidak dibaca. Yang paling efektif di Socialchat:

Untuk setiap komponen, dokumentasikan:

Kapan gunakan ini vs alternatif lain
Do’s and Don’ts (visual, bukan teks panjang)
Accessibility notes (contrast ratio, keyboard nav)

Kesalahan yang Saya Buat

1. Over-engineering di awal

Saya sempat spent 2 minggu bikin “perfect” token structure sebelum ada satu komponen pun. Pragmatis lebih baik: mulai dari yang dibutuhkan sekarang, refactor kemudian.

2. Tidak involve developer sejak awal

Design system yang bagus di Figma tidak otomatis mudah diimplementasikan. Libatkan developer dari awal untuk pastikan token names dan component API masuk akal untuk kode.

3. Tidak ada governance

Siapa yang bisa tambah komponen baru? Siapa yang approve perubahan? Tanpa ini, design system jadi liar.

Hasil Akhir

Setelah 6 bulan:

80+ komponen terdokumentasi
5 product modules menggunakan design system yang sama
Waktu desain halaman baru turun 60%
Konsistensi visual meningkat drastis

Design system bukan proyek satu kali — ini investasi berkelanjutan. Tapi ROI-nya sangat terasa ketika produk mulai scale.