Design System
Design system adalah satu sumber kebenaran untuk produk. Modul ini membahas token, component library, dokumentasi, governance, naming convention, dan bagaimana accessibility dibangun ke dalam sistem sejak awal.
Tujuan Modul
User memahami cara membuat desain yang scalable.
- Memahami hubungan token, komponen, dan pola.
- Membangun component library inti dengan variant matrix.
- Mendokumentasikan komponen agar tim bisa memakainya.
- Menyusun governance dan naming convention.
Token, Komponen, dan Variant Matrix
28 menit
Tujuan Lesson
Piramida design system
Lapisan paling bawah adalah token (nilai dasar: warna, spacing, radius). Di atasnya elemen (button, input). Lebih atas lagi pola (form, card layout). Perubahan di token mengalir ke seluruh sistem.
Dari token ke komponen
Komponen tidak menulis nilai mentah; ia merujuk token. Button memakai color/brand/500 dan space/12. Saat token berubah, komponen ikut berubah otomatis dan tetap konsisten.
Variant matrix
Untuk tiap komponen, petakan properti dan nilainya: size (sm/md/lg), state (default/hover/disabled), tipe (primary/secondary). Matriks ini memastikan tidak ada kombinasi yang terlupa.
Komponen inti
Mulai dari yang paling sering dipakai:
- Button, Input, Select, Checkbox, Radio.
- Card, Modal, Toast, Dropdown, Tabs.
- Table, Badge, Pagination.
Contoh Baik
Button yang seluruh nilainya merujuk token dan punya variant matrix lengkap, sehingga semua state dan ukuran konsisten di seluruh produk.
✕ Contoh Buruk
Banyak versi button dibuat manual dengan warna berbeda-beda, sehingga tampak mirip tapi tidak pernah benar-benar sama.
Kesalahan Umum Pemula
- ⚠Komponen menulis nilai mentah, bukan token.
- ⚠Variant tidak dipetakan sehingga ada kombinasi terlupa.
- ⚠Membuat terlalu banyak komponen sekaligus.
- ⚠Tidak ada satu sumber kebenaran.
Designer Mahal Berpikir Begini
Coba Latihan
- Bangun token: color, typography, spacing.
- Buat variant matrix untuk button dan input.
- Bangun 8 komponen inti yang merujuk token.
Checklist Lesson
Uji Pemahaman
Lapisan paling dasar dalam design system?
Dokumentasi, Governance & Accessibility Sistem
24 menit
Tujuan Lesson
Dokumentasi yang dipakai
Komponen tanpa dokumentasi akan dipakai salah. Tiap komponen perlu: kapan dipakai, kapan jangan, contoh benar/salah, dan properti. Dokumentasi yang baik mengurangi pertanyaan berulang.
Governance
Governance mengatur siapa boleh menambah/mengubah komponen dan bagaimana prosesnya. Tanpa ini, sistem cepat berantakan. Tetapkan ritme review dan kontribusi yang jelas.
Naming convention
Penamaan yang konsisten membuat komponen mudah ditemukan. Sepakati pola (mis. Button/Primary/Large) dan patuhi di seluruh tim. Nama yang baik adalah dokumentasi mini.
Accessibility built-in
Bangun aksesibilitas ke dalam komponen: kontras cukup, focus state jelas, label untuk screen reader, dan target sentuh memadai. Jika komponen sudah aksesibel, seluruh produk ikut terangkat.
Contoh Baik
Halaman dokumentasi button: contoh penggunaan, do & don't, daftar properti, dan catatan aksesibilitas. Developer dan designer paham tanpa bertanya.
✕ Contoh Buruk
Komponen tanpa dokumentasi, penamaan acak, dan tidak ada aturan kontribusi. Setiap orang membuat versinya sendiri.
Kesalahan Umum Pemula
- ⚠Tidak mendokumentasikan kapan komponen dipakai.
- ⚠Tidak ada governance sehingga sistem melebar liar.
- ⚠Penamaan tidak konsisten.
- ⚠Aksesibilitas dipikir belakangan.
Designer Mahal Berpikir Begini
Coba Latihan
- Tulis dokumentasi untuk 3 komponen inti.
- Tetapkan naming convention sistem.
- Audit aksesibilitas pada button dan input.
Checklist Lesson
Uji Pemahaman
Kenapa dokumentasi komponen penting?
Project Modul
Mini Design System
Bangun design system mini lengkap dengan token, komponen inti, variant matrix, dan dokumentasi do & don't.
Deliverables:
- Token: color, typography, spacing.
- Komponen inti (button, input, select, checkbox, radio, card, modal, toast, navbar, sidebar, table).
- Variant matrix tiap komponen.
- Dokumentasi do & don't + catatan aksesibilitas.