Belajar Product Designer - Scalable Design Systems
Memperluas design system dari satu produk ke banyak produk dan tim: token governance lintas produk, contribution model yang terbuka, dan cara menjaga sistem tetap sehat saat organisasi bertumbuh. Di episode ini kalian menyusun strategi scaling design system Sehati dari satu tim menjadi tiga tim produk
#Pendahuluan
Setelah di episode 8 kita membangun design system pertama Sehati, dan di episode 22 kita menjadikannya penjaga batas untuk komponen generatif — pada episode ini kita menghadapi pertanyaan scaling: apa yang terjadi saat satu produk menjadi tiga produk, dan satu tim menjadi sepuluh?
Design system yang hebat di satu tim bisa runtuh saat di-scale: komponen beranak pinak, token saling tumpang tindih, dan tim mulai "fork" untuk kebutuhan masing-masing. Skalabilitas bukan soal ukuran library — soal governance dan model kontribusi. Di episode ini kita susun fondasi agar sistem tetap sehat saat bertumbuh.
#Token Governance Lintas Produk
Saat tim bertambah, godaan terbesarnya adalah masing-masing membuat token sendiri ("kita butuh warna khusus untuk produk klinik"). Solusinya ada di struktur token berlapis yang sudah kita bangun di episode 8 — tetapi dengan disiplin yang lebih tegas.
| Lapisan | Siapa yang boleh mengubah | Contoh |
|---|---|---|
| Primitive | Hanya core team | blue.500, gray.700 — palet sumber |
| Semantic | Core team + proposal | color.primary, color.danger |
| Product-specific | Tim produk masing-masing | color.triage.merah (khusus produk triase) |
Aturan utamanya: produk memakai semantic + product-specific, tidak boleh menyentuh primitive secara langsung (kecuali darurat). Dengan begitu, rebranding tetap satu tempat, dan tim produk punya ruang ekspresi tanpa merusak fondasi.
#Contribution Model: Siapa Boleh Menambah
Design system mati jika hanya "dijaga segelintir orang" (bottleneck) atau jika semua orang bebas menambah (chaos). Jawabannya: contribution model — jalur resmi bagi siapa pun untuk berkontribusi, dengan review yang konsisten.
Kebutuhan tim → Usulan (RFC singkat)
→ Review core team (desain + eng)
→ Impact check: komponen? token? docs?
→ Setuju → build di library + dokumentasi
→ Ditolak → jawaban + alternatifKunci model ini: jalur terbuka, keputusan terpusat. Semua orang boleh mengusulkan; hanya core team yang memutuskan. Ini menjaga kecepatan (banyak kontributor) dan kualitas (review konsisten) sekaligus.
#Komponen & Variants: Kelola Pertumbuhan
Komponen yang sehat tumbuh beraturan, bukan eksponensial. Beberapa teknik:
- "3 use-cases" rule (episode 8) — abstraksi hanya setelah 3 pemakaian nyata.
- Composition over proliferation — gabungkan komponen kecil, jangan buat komponen baru untuk tiap kombinasi.
- Audit berkala — komponen yang tidak terpakai 6 bulan dikaji: dihapus atau disuntikkan pemakaian.
- Versioning & changelog — perubahan komponen dicatat; tim tahu apa yang berubah dan kapan.
❌ > 30% komponen tidak dipakai di produk nyata
❌ Token ganda untuk makna sama (blue.500 vs primary.500)
❌ Tim produk membuat komponen sendiri, bukan dari library
❌ Tidak ada changelog; perubahan datang diam-diamJika tiga dari empat indikator muncul, sistem butuh "rescue mission": audit, buang yang mati, dan perbaiki governance.
Tip
Investasi terbaik untuk scaling design system bukan lebih banyak komponen, melainkan dokumentasi dan komunikasi: changelog yang jelas, cara pakai yang singkat, dan komunitas internal (channel diskusi) tempat tim bertanya. Design system yang tidak dipahami akan dihindari — lalu di-fork. Membangun rasa kepemilikan tim lebih penting daripada menambah komponen.
#Dari Satu Tim ke Tiga Tim: Studi Sehati
Skenario: Sehati berkembang — tim pasien, tim dokter, dan tim klinik (B2B). Langkah scaling yang realistis:
| Langkah | Tindakan |
|---|---|
| 1 | Tetapkan core team 1 desainer + 1 eng sebagai penjaga |
| 2 | Pindahkan library ke workspace bersama (Figma library + Storybook) |
| 3 | Tambah lapisan product-specific tokens untuk kebutuhan tiap tim |
| 4 | Terapkan contribution model dengan RFC singkat |
| 5 | Adakan audit bulanan & changelog publik |
| 6 | Rekrut contributors dari tiap tim untuk berbagi beban |
Perhatikan: langkah 1-2 adalah fondasi; langkah 3-4 adalah governance; langkah 5-6 menjaga momentum. Tanpa governance (3-4), langkah apapun akan kembali berantakan seiring pertumbuhan.
#Praktik: Strategi Scaling Sehati
- Tulis 1 halaman governance untuk design system Sehati: siapa mengubah token, siapa menyetujui komponen baru.
- Buat RFC template 1 halaman untuk usulan komponen baru.
- Audit design system kalian dengan 4 indikator tidak sehat di atas — catat temuannya.
- Susun rencana 6 langkah untuk pindah dari 1 tim ke 3 tim.
#Penutup
Inti yang harus dibawa pulang:
- Scaling design system adalah soal governance, bukan ukuran library.
- Token berlapis (primitive/semantic/product) menjaga satu sumber kebenaran.
- Contribution model: jalur terbuka untuk semua, keputusan terpusat di core team.
- Jaga komponen tetap ramping: 3 use-cases, composition, audit berkala, changelog.
- Investasi di dokumentasi & rasa kepemilikan lebih besar nilainya daripada komponen baru.
Di episode 24 selanjutnya kita akan membahas design for emerging platforms — merancang untuk AR/VR, voice, dan embedded AI products, dan bagaimana prinsip yang sudah kalian pelajari diterjemahkan ke medium yang berbeda. Sampai jumpa di episode 24!