Pernah gak kamu buka file Figma, lalu merasa component library-nya sudah banyak, tapi tetap bikin kerja jadi lambat?
Button ada banyak versi. Input ada banyak duplikat. Naming-nya beda-beda. Ada component yang pakai Auto Layout, ada juga yang masih manual. Awalnya kelihatan “aman”, tapi begitu project makin besar, design system mulai terasa seperti lemari berantakan.
Menurut saya, masalahnya sering bukan karena kita kurang jago bikin UI. Masalahnya ada di struktur komponen Figma yang belum dipikirkan dari awal.
Banyak designer bisa membuat component. Tapi tidak semua designer membangun component yang mudah dipakai, mudah di-maintain, dan mudah dikembangkan ketika product mulai besar.
Di artikel ini, saya ingin bahas cara berpikir yang lebih rapi untuk menyusun component library di Figma. Bukan teori berat, tapi pendekatan praktis yang bisa kamu pakai saat membangun design system untuk product, client project, atau bahkan template pribadi.
Saya pernah mengalami hal ini dan sering sekali, jadi saya belajar dari pengalaman dan belajar dari kekurangan itu. Ya, sebenarnya saya masih belajar bagaimana membuat sebuah komponen yang lebih praktis dan scalable. jadi, apa yang saya tulis di sini lebih menceritakan secara general. Karena tidak ada hukum yang tetap, tergantung pada bagaimana cara desainer membuat sebuah komponen yang scalable, dan tentunya caranya cukup banyak.
Kenapa Struktur Komponen Figma Itu Penting?
Design system yang bagus bukan cuma kumpulan button, input, modal, dan card.
Design system yang bagus adalah sistem yang membuat designer bisa mengambil keputusan dengan lebih cepat. Developer juga lebih mudah membaca hasil design. Product team lebih gampang menjaga konsistensi visual dari satu halaman ke halaman lain.
Kalau struktur komponen Figma berantakan, efeknya pelan-pelan akan terasa:
- Designer membuat component baru padahal sudah ada.
- Developer bingung karena nama di Figma beda dengan nama di code.
- Dark mode sulit dibuat karena warna masih hardcoded.
- Satu perubahan kecil harus diedit di banyak tempat.
- File makin berat dan sulit dibuka.
- Handoff jadi penuh pertanyaan.
Ini yang sering disebut sebagai design debt. Awalnya kecil, lama-lama jadi mahal.
Karena itu, sebelum terlalu fokus membuat component yang terlihat cantik, kita perlu memikirkan fondasinya dulu.
1. Mulai dari Design Tokens, Bukan dari Button
Kesalahan yang cukup sering terjadi adalah langsung membuat button, card, input, atau modal tanpa menentukan token terlebih dahulu.
Padahal, token adalah fondasi dari design system.
Design tokens adalah nilai dasar yang dipakai berulang, seperti warna, typography, spacing, radius, shadow, dan opacity. Di Figma, ini bisa dibuat dengan Variables atau Style, lalu digunakan ke dalam component.
Contoh token yang lebih rapi:
color/background/default
color/background/subtle
color/text/primary
color/text/secondary
spacing/xs
spacing/sm
spacing/md
radius/sm
radius/md
typography/body/medium
Perhatikan, nama token di atas tidak memakai nama visual seperti blue-500 atau gray-100 sebagai acuan utama. Kenapa? Karena warna bisa berubah.
Hari ini gray-100 mungkin cocok untuk background light mode. Tapi saat masuk dark mode, nama itu bisa jadi membingungkan. Lebih aman memakai nama yang berdasarkan fungsi, misalnya background/default atau text/primary.
Ini disebut semantic naming.
Dengan pendekatan ini, ketika brand berubah atau product butuh dark mode, kamu tidak perlu mengecat ulang semua component satu per satu. Kamu cukup update token-nya, lalu component yang memakai token itu akan ikut berubah.
2. Pakai Naming yang Mudah Dicari
Component yang bagus tetap bisa terasa buruk kalau namanya tidak jelas.
Bayangkan kamu punya component seperti ini:
Button Blue
Button Main
Button New
Primary CTA Final
Button 2
Secara visual mungkin benar, tapi untuk team, ini bikin bingung. Designer lain tidak tahu mana yang harus dipakai. Developer juga tidak bisa membaca maksudnya dengan cepat.
Salah satu cara yang lebih rapi adalah memakai slash-based naming:
Button / Primary
Button / Secondary
Button / Ghost
Input / Text / Default
Input / Text / Error
Card / Product / Default
Modal / Confirmation
Struktur ini membuat component lebih mudah dicari di Figma Assets panel. Saat designer mengetik “Button”, semua variasi button akan muncul dalam satu kelompok yang lebih jelas.
Prinsip sederhananya:
Component / Type / Variant
Atau kalau component-nya lebih kompleks:
Component / Category / Type / State
Contoh:
Button / Primary / Default
Button / Primary / Hover
Button / Primary / Disabled
Input / Text / Error
Input / Text / Disabled
Tapi hati-hati, naming jangan terlalu panjang juga. Kalau semua hal dimasukkan ke nama component, library bisa jadi melelahkan untuk dibaca. Gunakan naming untuk struktur utama, lalu gunakan component properties untuk detail yang bisa dikontrol di instance.
3. Buat Base Component dan Variants
Kalau kamu masih membuat component terpisah seperti ini:
Button Primary
Button Secondary
Button Ghost
Button Danger
Button Disabled
Button Loading
Kemungkinan library kamu akan cepat membesar.
Masalahnya bukan karena jumlah button-nya banyak. Masalahnya adalah setiap button bisa punya struktur yang mirip, tapi tidak saling terhubung. Ketika kamu mau mengubah padding, radius, atau typography, kamu harus update banyak component satu per satu.
Pendekatan yang lebih scalable adalah membuat satu base component dengan variants.
Contoh struktur:
Button
- Type: Primary, Secondary, Ghost, Danger
- Size: Small, Medium, Large
- State: Default, Hover, Focus, Disabled, Loading
- Icon: None, Leading, Trailing
Dengan cara ini, designer cukup memilih instance Button, lalu mengubah property sesuai kebutuhan.
Keuntungannya:
- Lebih mudah di-maintain.
- Lebih sedikit component duplikat.
- State lebih konsisten.
- Struktur lebih dekat dengan implementasi developer.
- Designer tidak perlu mencari terlalu banyak component.
Untuk component yang sering dipakai seperti button, input, badge, tab, dan chip, pendekatan base component + variants ini sangat membantu.
4. Auto Layout Bukan Optional
Kalau component kamu masih banyak yang dibuat manual tanpa Auto Layout, jujur saja, itu akan menyulitkan saat product makin besar.
Auto Layout membuat component berperilaku lebih dekat dengan UI asli. Button bisa menyesuaikan panjang text. Card bisa mengikuti isi content. Form field bisa tetap rapi saat helper text muncul. Layout juga lebih mudah dijelaskan ke developer karena mirip konsep flexbox di CSS.
Contoh sederhana:
Button yang baik seharusnya tidak punya width hardcoded, kecuali memang ada alasan khusus.
Lebih baik:
- Width: Hug contents atau Fill container sesuai kebutuhan.
- Height: berdasarkan padding dan text style.
- Gap: pakai spacing token.
- Padding: pakai spacing token.
- Radius: pakai radius token.
Jadi saat label berubah dari “Save” menjadi “Save Changes”, button tetap rapi tanpa harus digeser manual.
Untuk component yang reusable, Auto Layout harus jadi default, bukan bonus.
5. Gunakan Component Properties Supaya Tidak Banjir Variants
Variants itu bagus, tapi kalau semua hal dibuat menjadi variant, component library bisa meledak.
Misalnya button punya:
- 5 type
- 3 size
- 5 state
- 3 icon position
- 2 kondisi full width
- 2 kondisi dengan badge atau tanpa badge
Kalau semuanya dijadikan variant, jumlahnya bisa sangat banyak. Designer juga jadi bingung memilih.
Di sini component properties sangat berguna.
Gunakan:
- Boolean property untuk show/hide icon, badge, helper text, atau trailing action.
- Text property untuk label yang bisa diedit.
- Instance swap untuk mengganti icon, avatar, atau nested component.
- Variant property untuk perbedaan visual utama seperti type, size, dan state.
Contoh di button:
Button
Type: Primary / Secondary / Ghost
Size: Small / Medium / Large
State: Default / Hover / Disabled / Loading
Show Icon: True / False
Icon: Instance Swap
Label: Text Property
Dengan cara ini, component tetap fleksibel tanpa membuat library terasa penuh dan berat.
6. Bangun Component Secara Bertingkat
Design system yang rapi biasanya tidak dibuat dari component besar langsung. Ada struktur bertingkat.
Kamu bisa membayangkannya seperti ini:
Atoms → Molecules → Organisms
Contoh:
Atoms:
- Icon
- Avatar
- Badge
- Tag
Molecules:
- Input Field
- Button Group
- User Chip
Organisms:
- Navigation Bar
- Data Table Row
- Notification Toast
Kenapa ini penting?
Karena component besar sebaiknya tidak dibuat dari copy-paste elemen kecil. Kalau Avatar dipakai di banyak tempat, Avatar harus jadi component sendiri. Lalu component lain menggunakan Avatar sebagai nested component.
Jadi saat kamu update Avatar, semua component yang memakai Avatar ikut update.
Ini sangat membantu untuk menjaga konsistensi, terutama di product yang punya banyak screen.
7. Pisahkan Library Berdasarkan Fungsi
Untuk project kecil, satu file Figma mungkin masih aman.
Tapi kalau design system sudah mulai besar, satu file raksasa bisa jadi masalah. File terasa berat, susah dicari, dan terlalu berisiko kalau semua orang bisa mengedit component utama.
Struktur yang lebih sehat bisa seperti ini:
01. Tokens Library
02. Foundations Library
03. Core Components
04. Pattern Library
05. Product Files
Penjelasannya:
Tokens Library
Berisi color, typography, spacing, radius, shadow, dan variable mode seperti light/dark.
Foundations Library
Berisi icon, illustration, logo, brand assets, dan asset dasar lain.
Core Components
Berisi component utama seperti button, input, checkbox, tabs, modal, dropdown, tooltip.
Pattern Library
Berisi section atau pattern yang lebih besar, misalnya pricing section, form layout, dashboard card, table layout.
Product Files
Berisi screen actual dari product, yang memakai library di atas.
Dengan struktur ini, design system jadi lebih mudah dijaga. Tidak semua orang harus mengedit file core component. Product designer bisa tetap cepat bekerja di product file tanpa merusak library utama.
8. Samakan Nama di Figma dengan Code
Salah satu sumber friction paling umum antara designer dan developer adalah naming yang tidak sama.
Designer menyebutnya “Main Button”. Developer menyebutnya Button primary. Designer menyebutnya “Top Bar”. Developer menyebutnya NavigationHeader.
Kelihatannya kecil, tapi di handoff ini bisa bikin diskusi jadi panjang.
Lebih baik sejak awal, nama component di Figma dibuat sedekat mungkin dengan nama di code.
Contoh:
Figma:
Button / Primary
Code:
<Button variant="primary" />
Atau:
Figma:
Navigation / Header
Code:
<NavigationHeader />
Ini bukan berarti designer harus selalu mengikuti cara developer menulis code. Tapi minimal, designer dan developer punya bahasa yang sama.
Kalau kamu sedang membuat design system untuk client, coba ajak developer untuk audit 10 sampai 20 component utama. Samakan naming-nya. Ini akan sangat membantu saat handoff, QA, dan dokumentasi.
9. Dokumentasi Langsung di Figma
Component yang rapi tetap bisa salah dipakai kalau tidak ada dokumentasinya.
Dokumentasi tidak harus panjang seperti buku. Yang penting cukup membantu designer memahami:
- Component ini dipakai untuk apa?
- Kapan boleh dipakai?
- Kapan tidak boleh dipakai?
- Apa saja variant dan state-nya?
- Bagaimana spacing dan behavior-nya?
- Apa catatan accessibility-nya?
Contoh struktur dokumentasi sederhana:
Overview
Anatomy
Variants
States
Usage
Do / Don't
Accessibility Notes
Untuk button, misalnya:
Overview:
Button digunakan untuk action utama atau sekunder di dalam interface.
Do:
Gunakan Primary Button untuk action utama dalam satu section.
Don't:
Jangan gunakan dua Primary Button yang bersaing dalam satu area kecil.
Dokumentasi seperti ini bisa dibuat langsung di halaman component library. Jadi designer tidak perlu pindah ke Notion atau Google Docs hanya untuk memahami cara memakai component.
Buat saja sederhana dulu. Lebih baik ada dokumentasi pendek tapi dipakai, daripada dokumentasi panjang tapi tidak pernah dibaca.
10. Design System Butuh Owner dan Aturan
Ini bagian yang sering dilupakan.
Design system bukan cuma file. Design system juga butuh proses.
Kalau semua designer bebas menambah component ke library utama, lama-lama library akan penuh dengan component sekali pakai. Awalnya niatnya “cuma sementara”, tapi akhirnya tinggal selamanya.
Minimal, design system perlu:
- Satu owner utama.
- Aturan kapan component boleh masuk library.
- Proses review sebelum publish.
- Aturan untuk update component lama.
- Cara menandai component yang deprecated.
- Catatan changelog sederhana.
Untuk team kecil, prosesnya tidak perlu ribet. Bisa sesederhana ini:
Propose → Review → Build → Test → Publish
Yang penting ada guardrail.
Kalau tidak ada owner, design system akan berjalan tanpa arah. Dan biasanya, file akan kembali berantakan.
Contoh Struktur Sederhana untuk Kamu Mulai
Kalau kamu ingin mulai merapikan struktur komponen Figma, jangan langsung mencoba membuat sistem besar.
Mulai dari yang paling sering dipakai dulu.
Prioritas awal:
1. Colors & typography tokens
2. Spacing & radius tokens
3. Button
4. Input field
5. Checkbox / Radio / Toggle
6. Badge / Tag
7. Modal
8. Card
9. Table component, kalau product kamu banyak data
10. Dokumentasi sederhana
Setelah itu, baru pikirkan pattern yang lebih besar seperti page layout, dashboard cards, form templates, atau responsive sections.
Untuk naming, kamu bisa mulai dengan format ini:
Component / Type / State
Contoh:
Button / Primary / Default
Button / Primary / Disabled
Input / Text / Error
Badge / Status / Success
Modal / Confirmation
Untuk properties, mulai dari yang paling sering berubah:
Label
State
Size
Type
Show Icon
Icon Instance
Helper Text
Dengan struktur sederhana seperti ini, design system kamu sudah jauh lebih mudah dipakai dibanding file yang hanya berisi component random tanpa aturan.
Kesimpulan
Struktur komponen Figma yang baik bukan tentang membuat library terlihat keren. Tujuan utamanya adalah membuat kerja design lebih cepat, lebih konsisten, dan lebih mudah di-maintain.
Kalau saya ringkas, fondasinya seperti ini:
- Mulai dari design tokens.
- Gunakan naming yang jelas.
- Buat base component dengan variants.
- Pakai Auto Layout di reusable component.
- Gunakan component properties agar variants tidak terlalu banyak.
- Bangun component secara bertingkat.
- Pisahkan library jika file mulai besar.
- Samakan bahasa design dan code.
- Dokumentasikan component langsung di Figma.
- Buat aturan kontribusi dan owner.
Tidak perlu langsung sempurna. Design system itu tumbuh. Yang penting, setiap component baru dibuat dengan struktur yang lebih jelas dari sebelumnya.
Kalau kamu sedang membangun design system di Figma, coba mulai dari satu component dulu. Misalnya Button. Rapikan token-nya, naming-nya, variants-nya, Auto Layout-nya, properties-nya, dan dokumentasinya.
Dari satu component yang rapi, kamu akan mulai punya standar untuk component berikutnya.
Kalau kamu designer yang sedang mulai membangun design system, jangan tunggu sampai file terlalu berantakan. Mulai rapikan dari component yang paling sering dipakai. Kecil dulu, tapi konsisten.
