Cara Membuat Design System Frontend yang Kecil tetapi Terawat

Tim kecil biasanya tidak kekurangan komponen UI. Masalahnya, komponen yang tampak sama mulai memiliki warna, jarak, nama, dan perilaku yang berbeda-beda. Satu tombol memiliki tiga gaya disabled, sementara input yang seharusnya seragam diduplikasi di beberapa tempat.

Design system frontend membantu mengubah keputusan yang berulang itu menjadi rujukan bersama. Namun, memulainya tidak harus berarti membangun katalog besar atau memilih tool tertentu. Untuk tim kecil, titik awal yang lebih aman adalah menginventarisasi UI yang sudah ada, memilih sejumlah keputusan yang layak dibakukan, lalu menghubungkannya dengan komponen, state, dokumentasi, dan aturan kontribusi yang sederhana.

Panduan ini membahas cara membuat design system frontend dalam batas yang praktis: dari inventaris UI sampai sistem kecil yang bisa dipakai dan dirawat. Fokusnya bukan memilih framework atau membuat program pengujian aksesibilitas, kompatibilitas browser, maupun alur coding berbantuan AI.

Mulai dari inventaris UI yang sudah ada

Jangan mulai dari daftar komponen ideal. Mulailah dari produk yang benar-benar dipakai.

Kumpulkan contoh layar, potongan kode, atau tautan ke halaman yang mewakili alur penting. Catat variasi visual dan interaksi yang muncul, termasuk state seperti hover, focus, disabled, loading, error, dan kosong. Tujuannya bukan langsung menilai mana yang benar, melainkan melihat pengulangan dan perbedaan yang perlu diputuskan.

Tabel sederhana sudah cukup untuk tahap pertama:

Temuan	Contoh	Keputusan awal
Warna tombol utama berbeda	Biru tua dan biru sedang	Pilih nama dan nilai token yang disepakati
Jarak antar-field berulang	8, 12, dan 16 px	Kelompokkan sebagai skala spacing
Input memiliki state berbeda	Default, focus, error, disabled	Dokumentasikan state wajib
Panel informasi dibuat ulang	Tiga halaman memakai markup serupa	Pertimbangkan satu komponen bersama

Berikan prioritas pada pola yang sering muncul, menimbulkan kebingungan, atau akan dipakai lintas halaman. Jangan memaksa semua pengecualian menjadi bagian dari sistem. Pengecualian yang benar-benar unik dapat tetap berada di tingkat fitur sampai ada pola yang cukup kuat untuk diabstraksikan.

Hasil inventaris yang baik bukan hanya daftar nama. Ia menjawab tiga pertanyaan: pola apa yang berulang, variasi mana yang bermakna, dan keputusan mana yang belum disepakati.

Pisahkan token dari komponen dan state

Kesalahan umum adalah mencampur semua hal ke dalam satu “library”. Pisahkan setidaknya tiga lapisan berikut.

Token adalah nama untuk keputusan dasar seperti warna, ukuran teks, radius, bayangan, dan jarak. Token menjawab, “nilai apa yang digunakan bersama?”

Komponen adalah bagian antarmuka yang memiliki struktur dan cara penggunaan, seperti button, input, card, atau alert. Komponen menjawab, “bagian UI apa yang dipakai?”

State menjelaskan kondisi komponen, misalnya default, hover, focus, disabled, loading, success, atau error. State menjawab, “bagaimana komponen ini berperilaku dalam kondisi tertentu?”

Pemisahan ini membuat perubahan lebih mudah ditelusuri. Mengganti warna aksen tidak sama dengan menambah varian button. Menambah state error juga tidak sama dengan membuat komponen baru.

Contoh token dengan CSS custom properties

CSS custom properties dapat menjadi lapisan token yang ringan dan framework-neutral. Nilai diberi nama, lalu dirujuk dengan var():

:root {
  --color-brand: #2563eb;
  --color-surface: #ffffff;
  --color-text: #172033;
  --space-2: 0.5rem;
  --space-4: 1rem;
  --radius-sm: 0.375rem;
}

.card {
  color: var(--color-text);
  background: var(--color-surface);
  padding: var(--space-4);
  border-radius: var(--radius-sm);
}

Nama token menjelaskan keputusan yang dipakai, bukan hanya nilai mentahnya. --color-brand lebih mudah ditinjau daripada menyebarkan #2563eb ke banyak selector.

Contoh ini adalah mekanisme CSS yang terbatas, bukan keseluruhan standar design-token. Custom properties mengikuti scope, cascade, dan inheritance. Karena itu, tentukan tempat deklarasi dan batas penggunaannya dengan jelas. Gunakan fallback hanya ketika perilaku fallback memang menjadi bagian dari keputusan komponen:

.button {
  color: var(--button-text, #ffffff);
  background: var(--button-background, var(--color-brand));
}

Tim yang membutuhkan pertukaran token antar-tool dapat mempelajari format token yang relevan. Namun, spesifikasi komunitas bukan alasan untuk mengadopsi struktur pertukaran yang belum dibutuhkan proyek. Mulailah dari nama dan keputusan yang konsisten; pilih format distribusi ketika ada kebutuhan nyata untuk menyinkronkan beberapa sumber.

Bangun sedikit komponen dengan state yang jelas

Setelah inventaris dan token awal tersedia, mulailah dari komponen yang paling sering dipakai atau paling mahal untuk dipelihara secara terpisah. Jumlahnya mengikuti pola yang ditemukan dan kapasitas tim, bukan target universal.

Untuk setiap komponen, tuliskan kontrak kecil:

• tujuan dan situasi penggunaan;
• struktur atau API yang disepakati;
• varian yang memang diperlukan;
• state yang harus ditampilkan;
• konten atau kombinasi yang tidak didukung;
• token yang dipakai;
• contoh penggunaan.

Misalnya, komponen Button dapat memiliki varian primary dan secondary, lalu state default, hover, focus, disabled, dan loading. Jangan menambah varian hanya karena dua halaman memiliki label atau ukuran yang berbeda. Tanyakan apakah perbedaan itu merepresentasikan kebutuhan produk atau hanya sejarah implementasi yang belum dirapikan.

State perlu diperlakukan sebagai bagian dari desain komponen, bukan catatan tambahan setelah komponen selesai. Dokumentasikan pula perilaku aksesibilitas yang relevan, seperti nama yang harus tersedia, hubungan label, atau makna state error. Dokumentasi ini membantu pemakai komponen menerapkannya dengan benar; pengujian aksesibilitas yang sistematis adalah pekerjaan tersendiri.

Dokumentasikan agar komponen dapat ditemukan dan dipakai

Komponen yang hanya hidup di folder kode belum menjadi sistem yang mudah dipakai. Pengguna perlu tahu kapan komponen dipilih, bagaimana cara memakainya, dan kapan pilihan itu tidak tepat.

Halaman dokumentasi minimum untuk sebuah komponen dapat berisi:

1. Ringkasan: masalah apa yang diselesaikan komponen tersebut.
2. Kapan digunakan: konteks yang cocok dan alternatif terdekat.
3. API atau opsi: nama properti, nilai yang diterima, dan default yang berlaku.
4. Varian dan state: contoh visual untuk kondisi yang didukung.
5. Contoh kode: contoh paling kecil yang bisa diadaptasi.
6. Do dan don’t: penggunaan yang dianjurkan dan pola yang perlu dihindari.
7. Catatan aksesibilitas: perilaku dan tanggung jawab pemakai yang perlu diketahui.
8. Status perubahan: apakah komponen stabil, sedang diubah, atau memiliki pengganti.

Storybook dapat digunakan sebagai salah satu tempat untuk menampilkan komponen dan contoh state secara terpisah. Figma juga dapat membantu menginventarisasi dan mengorganisasi fondasi visual. Keduanya pilihan, bukan syarat. Dokumentasi berbasis Markdown di repositori pun dapat memadai jika mudah dicari, dekat dengan kode, dan diperbarui bersama perubahan komponen.

Yang penting, dokumentasi tidak boleh menjadi salinan yang cepat tertinggal. Ketika API, token, atau state berubah, perbarui contoh dan aturan penggunaan dalam perubahan yang sama.

Tetapkan governance yang ringan

Governance tidak harus berupa komite atau proses persetujuan panjang. Untuk sistem kecil, cukup buat aturan kontribusi yang menjawab siapa pun yang ingin menambah atau mengubah bagian sistem.

Aturan awal dapat mencakup:

• setiap komponen baru harus menyebutkan masalah yang diselesaikan dan pola yang sudah diperiksa;
• perubahan token harus menjelaskan dampaknya pada komponen yang menggunakannya;
• varian baru perlu alasan penggunaan, bukan hanya kebutuhan satu layar;
• perubahan API, state, dan status komponen harus memperbarui dokumentasi;
• pengecualian lokal boleh dibuat ketika abstraksi bersama belum tepat, tetapi alasannya dicatat;
• pemilik atau reviewer yang ditunjuk memeriksa perubahan sebelum digabungkan.

Simpan aturan ini di tempat yang mudah ditemukan bersama dokumentasi komponen. Pada tahap awal, review manual yang konsisten lebih berguna daripada membuat proses besar yang tidak dijalankan. Seiring jumlah komponen bertambah, catatan perubahan dan status stabil/deprecated dapat membantu tim menghindari penggunaan pola lama.

Urutan kerja yang dapat dipakai ulang

Jika ingin memulai tanpa overbuilding, gunakan urutan berikut:

1. Inventarisasi UI yang sudah ada, termasuk variasi dan state.
2. Tandai keputusan yang berulang dan pengecualian yang masih valid.
3. Kelompokkan token dasar: warna, tipografi, jarak, ukuran, dan bentuk.
4. Pilih beberapa komponen yang paling sering digunakan.
5. Tentukan varian dan state yang benar-benar diperlukan.
6. Hubungkan komponen dengan token, bukan nilai mentah yang tersebar.
7. Tulis dokumentasi penggunaan, contoh, dan batasannya.
8. Tambahkan aturan kontribusi yang sederhana.
9. Tinjau ulang setelah komponen dipakai di beberapa konteks nyata.

Urutan ini bukan proses sekali jadi. Inventaris dapat menemukan pola baru, dan penggunaan komponen dapat menunjukkan bahwa sebuah abstraksi terlalu sempit atau terlalu luas. Perubahan tersebut sebaiknya mengalir kembali ke token, komponen, dokumentasi, atau aturan yang relevan.

Design system frontend yang kecil tetapi terawat bukanlah katalog terbesar. Ia adalah kumpulan keputusan yang dapat ditemukan, digunakan kembali, dan diubah dengan alasan yang jelas. Jika tim Anda baru mulai, ukur kemajuan dari berkurangnya keputusan yang tersebar dan meningkatnya kejelasan penggunaan—bukan dari banyaknya komponen yang berhasil dikumpulkan.