Belajar UI Designer - Design Systems & Tokens

#Pendahuluan

Setelah di episode 3-8 kita membangun bahan-bahannya satu per satu — warna, tipografi, spacing, komponen — pada episode ini kita menyatukan semuanya menjadi satu sistem: design system dengan design tokens. Inilah titik di mana koleksi keputusan desain berubah menjadi bahasa bersama tim.

Mengapa design system penting? Karena produk hidup: layar baru ditambahkan setiap sprint, orang baru masuk tim, platform baru dibuka. Tanpa sistem, setiap layar baru berarti "menebak lagi" — warna, jarak, dan komponen diputuskan ulang secara acak. Dengan design system, layar baru adalah perakitan dari keputusan yang sudah disepakati. Inilah juga yang membuat skala tim berjalan — dan di episode 26, menjadi dasar peran "Design System Governor".

#Apa itu Design Token

Design token adalah nilai desain (warna, spacing, radius, type) yang diberi nama dan disimpan di satu tempat. Token adalah sumber kebenaran tunggal: sekali diubah, menyebar ke seluruh produk.

Token disusun berlapis dengan pola primitives → semantic:

PRIMITIVES (nilai mentah)          SEMANTIC (peran)
├── color.blue.500  #2F6BFF      ├── color.primary  = primitives.blue.500
├── color.blue.600  #1E56E0      ├── color.background = primitives.neutral.50
├── space.200       = 8px        ├── space.inset    = primitives.space.200
└── type.size.lg    = 32px       └── type.heading   = primitives.type.size.lg

Mengapa dua lapis? Primitives mencatat nilai, semantik mencatat peran. Saat brand berubah dari ungu ke biru, kalian hanya mengubah primitives, sementara semua semantic (tombol, link, focus) otomatis mengikuti. Token semantik juga yang memungkinkan theming — topik episode 10.

#Struktur Token untuk Kantongin

Peta token yang lengkap untuk produk:

Dalam file Figma, token diterjemahkan sebagai styles (color/text/effect) dan Auto layout (spacing). Developer menerjemahkannya sebagai variabel — di episode 13, token ini diekspor langsung saat handoff.

#Rules Pemakaian Komponen

Design system tanpa aturan pemakaian hanyalah rak komponen. Tambahkan rules agar komponen dipakai dengan benar:

• Satu primary action per layar; yang lain secondary/ghost.
• Disabled hanya untuk aksi yang memang belum tersedia — jangan untuk "menyembunyikan" fitur.
• Danger hanya untuk aksi destruktif (hapus data, batal permanen).
• Tombol sm untuk aksi dalam list/baris; md/lg untuk aksi utama layar.

Aturan ditulis sebagai catatan di halaman komponen — dan sebaiknya dienforce lewat pola (misal nama varian yang jelas, atau penamaan layer) agar tidak sekadar dokumen.

#Dokumentasi

Design system hidup di dokumentasi — dan siapa yang membacanya menentukan bentuknya:

• Untuk desainer (Figma): halaman Overview di file library berisi prinsip, rules, dan do/don't visual. Figma juga mendukung variables untuk token (mode, theming).
• Untuk developer (Storybook): komponen didokumentasikan sebagai stories — tiap state, prop, dan contoh kode. Storybook menjadi acuan implementasi komponen saat handoff (episode 13).

Struktur dokumentasi idealnya menjawab tiga pertanyaan: "Token apa yang tersedia?", "Bagaimana komponen dipakai dengan benar?", dan "Bagaimana menambahkan komponen baru?". Jawab tiga pertanyaan itu, dan sistem bisa dirawat oleh tim, bukan hanya pembuatnya.

Overview / Prinsip
Tokens   / Warna, Type, Spacing, Radius
Components / Button, Input, Card, Badge, EmptyState
Patterns / Form, Error states, Loading
Contributing / Cara menambah komponen

#Praktik: Design System Kantongin

1. Di file Kantongin-System, buat halaman Overview, Tokens, Components, Patterns.
2. Tinjau style yang sudah dibuat: apakah setiap warna punya peran semantik (primary, semantic.*)? Rename bila perlu.
3. Tulis rules pemakaian minimal untuk Button dan Input (3 aturan per komponen).
4. Buat halaman Patterns berisi contoh error form dan empty state yang memakai komponen.
5. Cek keterpakaian: buat satu layar baru hanya dari komponen + token — tanpa nilai "nembak".

#Common Pitfalls

• Token tanpa hierarki — semua token "datar" tanpa lapisan primitives/semantic; rebranding jadi menyakitkan.
• Nilai nembak di layar — token ada tapi tidak dipakai; tambahkan aturan bahwa layar baru wajib memakai token.
• Dokumentasi tidak dibaca — tulis rules sebagai pendamping, dan enforce lewat pola Figma, bukan dokumen yang hanya dibaca sekali.
• Sistem dirancang sekaligus — terlalu besar dari awal, tidak pernah selesai; mulai kecil dan tumbuhkan.
• Mengabaikan Storybook — developer tanpa acuan komponen akan mengimplementasikan ulang secara berbeda.

#Penutup

Pada episode 9 ini, kalian telah menyatukan keputusan desain menjadi satu design system yang terdokumentasi.

Inti yang harus dibawa pulang:

• Design token berlapis primitives → semantic, menjadi sumber kebenaran tunggal.
• Rules pemakaian memastikan komponen dipakai dengan benar, bukan sekadar tersedia.
• Dokumentasi menjawab tiga hal: token apa yang ada, bagaimana memakai, bagaimana menambah.
• Figma untuk desainer, Storybook untuk developer.

Di episode 10 selanjutnya kita akan membahas dark mode & themes — token theming, strategi dark mode, dan dynamic color untuk Kantongin yang bisa berganti tema mulus. Sampai jumpa di episode 10!