Design System: Investasi yang Sering Dianggap Buang Waktu

Design system sering dianggap sebagai pekerjaan tambahan yang bisa ditunda. Saat roadmap penuh, tim cenderung memilih langsung membangun halaman dan fitur karena hasilnya terlihat lebih cepat dibanding merapikan token, mendokumentasikan komponen, atau menyamakan pola interaksi.

Pendekatan itu memang bisa bekerja pada fase awal.

Masalahnya muncul ketika produk mulai punya banyak halaman, developer bertambah, designer bekerja pada beberapa flow sekaligus, dan komponen yang awalnya terlihat mirip mulai memiliki lima versi berbeda. Perubahan kecil seperti spacing, focus state, ukuran button, atau validation pattern kemudian membutuhkan koordinasi di banyak tempat.

Dalam konteks design system, yang dibangun bukan hanya kumpulan komponen. Design system merupakan sekumpulan prinsip, foundations, design decisions, reusable components, dokumentasi, dan tooling yang membantu banyak orang membangun pengalaman produk secara konsisten.

Atlassian, misalnya, mendeskripsikan design system mereka sebagai kombinasi guidelines, foundations, tools, dan components. Foundations mencakup token, color, spacing, typography, dan pola visual; components menjadi building block reusable untuk kebutuhan interaksi. Ini menunjukkan bahwa design system jauh lebih luas daripada sekadar file Figma atau package React.

Artikel existing ini punya tiga gagasan utama: design system menjaga konsistensi antar tim, komponen standar mempercepat development, dan investasi awalnya dapat terbayar melalui efisiensi jangka panjang. Ketiga gagasan itu tetap menjadi fondasi artikel ini.

Sebelumnya, artikel Multi-Tenant CMS: Solusi Buat Kelola Banyak Situs Sekaligus membahas bagaimana shared platform mengurangi duplikasi saat banyak situs dikelola bersama. Design system menerapkan prinsip serupa pada layer UI: keputusan yang sama tidak perlu dibuat ulang oleh setiap produk dan setiap tim.

Apa Itu Design System dan Kenapa Penting?

Design system adalah sumber bersama untuk keputusan desain dan implementasi UI yang berulang. Ia membantu designer dan developer menggunakan bahasa, token, komponen, pola interaksi, serta aturan accessibility yang sama sehingga produk dapat berkembang tanpa menghasilkan variasi yang tidak perlu.

Design system biasanya terdiri dari beberapa layer:

1. Principles — cara tim mengambil keputusan desain.

2. Design tokens — representasi keputusan seperti color, spacing, typography, radius, atau elevation.

3. Primitives — building block dasar untuk layout dan styling.

4. Components — button, input, dialog, table, tabs, dan elemen reusable lain.

5. Patterns — kombinasi komponen untuk kasus tertentu seperti form, empty state, atau navigation.

6. Documentation — aturan penggunaan, contoh, accessibility, dan batasan.

7. Tooling — library desain, package kode, linting, testing, atau release process.

Atlassian menyebut design tokens sebagai single source of truth untuk menyimpan dan memberi nama pada design decisions, sementara components digunakan sebagai reusable building blocks untuk kebutuhan interaksi. Pendekatan seperti ini membantu keputusan desain tidak hanya hidup di kepala satu designer.

Kenapa Design System Sering Terasa Seperti Buang Waktu?

Design system terasa mahal karena biaya pembuatannya muncul lebih dulu, sedangkan manfaatnya muncul secara kumulatif.

Tanpa design system, developer bisa membuat button baru dalam waktu singkat.

Dengan design system, tim mungkin harus:

• menentukan variant;

• merancang states;

• memikirkan accessibility;

• menyusun API komponen;

• membuat test;

• menulis dokumentasi;

• memastikan implementasi cocok dengan design file.

Untuk satu button, pekerjaan tersebut tampak berlebihan.

Tetapi pertanyaannya berubah ketika button yang sama digunakan pada 80 halaman.

Apakah lebih murah membuat keputusan sekali dengan matang, atau membuat 80 implementasi lalu memperbaiki ketidakkonsistenannya nanti?

Design system adalah investasi pada pengurangan pekerjaan berulang.

Nilainya meningkat bersama skala produk dan tim.

Bagaimana Design System Menjaga Konsistensi Antar Tim?

Konsistensi muncul ketika keputusan yang sama memiliki sumber yang sama.

Tanpa sistem bersama, developer bisa membuat:

Primary button
Submit button
Save button
CTA button
Blue button
MainAction

Padahal semuanya mungkin mewakili pola yang sama.

Perbedaannya perlahan menyebar:

• padding berbeda;

• warna sedikit berbeda;

• hover state berbeda;

• loading state berbeda;

• radius berbeda;

• focus ring tidak konsisten.

Dengan shared component:

<Button variant="primary">
  Simpan
</Button>

detail implementation dipusatkan.

Produk tidak harus identik di setiap layar, tetapi pola yang memang sama sebaiknya benar-benar sama.

Carbon Design System juga menekankan bahwa reuse komponen secara sistematis membantu menciptakan konsistensi visual dan fungsional antarproduk.

Konsistensi bukan sekadar estetika.

Ia mengurangi beban belajar pengguna karena pola interaksi menjadi predictable.

Bagaimana Design System Mempercepat Development?

Design system mempercepat development karena tim tidak memulai setiap feature dari nol.

Developer tidak perlu lagi bertanya:

• warna error apa;

• loading button seperti apa;

• spacing antar-field berapa;

• modal punya close behavior bagaimana;

• disabled state seperti apa;

• focus ring memakai style apa.

Keputusan tersebut sudah tertanam di component dan documentation.

Designer juga mendapat keuntungan.

Alih-alih mendesain ulang primitive yang sama, designer dapat menyusun flow menggunakan library yang sudah mencerminkan komponen production.

Atlassian bahkan menjelaskan bahwa library desain internal mereka dicocokkan satu-ke-satu dengan React components yang digunakan developer untuk menyederhanakan handoff dan implementasi.

Ketika desain dan kode berbicara bahasa yang sama, translation cost berkurang.

Kenapa Design Tokens Menjadi Fondasi Penting?

Design token memisahkan keputusan desain dari nilai mentah.

Daripada menulis:

color: #0052cc;
margin-top: 16px;

tim bisa menggunakan konsep seperti:

color.action.primary
space.200

Nilai aktual bisa berubah.

Semantic intent tetap.

Ini penting ketika produk memiliki:

• dark mode;

• multiple theme;

• rebranding;

• accessibility update;

• responsive scale;

• multi-brand UI.

Jika brand color berubah, tim tidak harus mencari ratusan hex code.

Token dapat diperbarui dari satu sumber.

Design token juga membuat komunikasi designer-developer lebih presisi.

Keduanya tidak lagi berbicara tentang “biru yang agak gelap”.

Mereka berbicara tentang token yang sama.

Apa Bedanya Component Library dan Design System?

Component library adalah bagian dari design system, bukan keseluruhannya.

Component library biasanya fokus pada implementasi reusable:

• button;

• input;

• modal;

• table;

• tabs;

• dropdown.

Design system lebih luas.

Ia juga menjelaskan:

• kapan component digunakan;

• kapan tidak digunakan;

• bagaimana tone konten;

• spacing;

• accessibility;

• responsive behavior;

• design principles;

• contribution process.

Sebuah repository berisi 50 komponen tanpa dokumentasi penggunaan belum tentu menjadi design system yang matang.

Ia mungkin baru component library.

Kenapa Accessibility Lebih Mudah dengan Design System?

Accessibility adalah salah satu area yang paling diuntungkan oleh reusable foundation.

Komponen seperti dialog, tabs, combobox, menu, dan form punya banyak detail:

• keyboard navigation;

• focus management;

• accessible name;

• ARIA semantics;

• contrast;

• error announcement;

• screen reader behavior.

Jika setiap feature team membuat sendiri, risiko inconsistency besar.

Dengan foundational component yang diuji, banyak masalah dapat diselesaikan sekali lalu diwarisi seluruh consumer.

Atlassian menempatkan accessibility sebagai salah satu foundation resmi dalam design system mereka. Carbon juga menyertakan accessibility sebagai bagian dari guidance komponen.

Tetapi efeknya juga bisa berbalik.

Jika komponen shared memiliki bug accessibility, bug itu menyebar ke seluruh produk.

Karena itu, foundational components perlu review dan testing lebih ketat daripada komponen feature lokal.

Bagaimana Design System Mengurangi Technical Debt?

Technical debt frontend sering muncul bukan dari satu keputusan besar, tetapi dari ratusan variasi kecil.

Contoh:

• delapan ukuran modal;

• enam versi input;

• empat loading spinner;

• button berbeda antarfeature;

• typography hardcoded;

• spacing tanpa token.

Setiap variasi membuat perubahan global lebih mahal.

Design system mengurangi debt dengan mengkonsolidasikan pola.

Jika requirement accessibility baru muncul, tim dapat memperbaiki primitive.

Jika rebranding terjadi, token berubah.

Jika loading pattern diperbarui, component dapat diupgrade.

Namun design system juga bisa menciptakan technical debt jika tidak dikelola.

Contohnya:

• component terlalu banyak variant;

• deprecated component tidak pernah dihapus;

• version tidak jelas;

• documentation stale;

• contribution tanpa review.

Design system tetap software.

Ia perlu maintenance.

Kapan Tim Sebaiknya Mulai Membuat Design System?

Tidak perlu menunggu organisasi punya 100 developer.

Tetapi juga tidak perlu membangun enterprise design system ketika produk baru punya tiga layar.

Waktu yang tepat biasanya ketika mulai muncul pola berulang.

Sinyalnya:

• component yang sama dibuat berkali-kali;

• designer sering mengoreksi inconsistency;

• developer bertanya style yang sama berulang;

• onboarding engineer melambat;

• beberapa produk mulai berbagi UI;

• redesign membutuhkan banyak perubahan manual.

Mulai kecil.

Tidak perlu langsung membuat 80 komponen.

Bangun foundation yang paling sering digunakan:

• color;

• spacing;

• typography;

• button;

• input;

• form;

• modal.

Kembangkan berdasarkan usage nyata.

Kenapa Jangan Membangun Design System Terlalu Besar di Awal?

Overengineering design system bisa sama buruknya dengan tidak punya sistem.

Tim bisa menghabiskan berbulan-bulan membuat:

• component yang belum pernah dibutuhkan;

• variant hipotetis;

• documentation sangat detail;

• tooling kompleks.

Sementara feature delivery berhenti.

Prinsip yang lebih sehat adalah extraction.

Bangun produk.

Temukan pola.

Standardisasi pola yang sudah terbukti.

Atlassian dalam prinsip design system-nya juga menekankan foundational problems sebelum mencoba menyediakan pattern komprehensif.

Design system bukan katalog semua UI yang mungkin ada.

Ia adalah kumpulan solusi untuk masalah yang memang berulang.

Bagaimana Mendesain API Komponen yang Sehat?

Shared component memiliki consumer: developer.

Karena itu API komponen perlu dirancang seperti public interface.

Contoh kurang ideal:

<Button
  blue
  bold
  rounded
  smallPadding
/>

Props tersebut mengekspos detail style.

Lebih baik:

<Button
  appearance="primary"
  size="medium"
>
  Simpan
</Button>

API kedua berkomunikasi dengan semantic intent.

Jika visual primary button berubah, consumer tidak harus berubah.

Hindari juga component dengan puluhan boolean prop.

Contoh:

compact
small
bordered
flat
dark
legacy
newStyle

Itu tanda component mulai kehilangan boundary.

Composition sering lebih sehat daripada menambah configuration tanpa batas.

Atlassian saat ini juga mendorong reusable component yang lebih kecil dibanding component besar dengan API sangat kompleks.

Bagaimana Menangani Custom Component?

Design system tidak boleh memaksa semua UI masuk ke existing component.

Jika feature benar-benar membutuhkan pola baru, custom component valid.

Gunakan beberapa pertanyaan:

1. Apakah pola ini hanya untuk satu feature?

2. Apakah muncul di beberapa tempat?

3. Apakah cocok menjadi bagian sistem?

4. Apakah behavior sudah cukup stabil?

Jika masih eksperimen, simpan di feature layer.

Jika mulai berulang dan stabil, pertimbangkan promosi ke design system.

Design system sebaiknya tumbuh berdasarkan bukti.

Bagaimana Governance Design System Bekerja?

Design system perlu owner.

Tanpa owner, shared library mudah berubah menjadi tempat semua orang menaruh component.

Governance dapat menentukan:

• siapa yang approve component baru;

• bagaimana contribution dilakukan;

• kapan component dianggap stable;

• bagaimana breaking change dirilis;

• bagaimana deprecated component dihapus;

• bagaimana dokumentasi diperbarui.

Governance tidak harus berarti satu tim mengontrol semuanya.

Model contribution bisa terbuka.

Feature team dapat mengusulkan component.

Design system team menjaga standar.

Yang penting, ada proses.

Bagaimana Versioning dan Release Dikelola?

Code component perlu lifecycle.

Gunakan:

• semantic versioning jika sesuai;

• changelog;

• deprecation warning;

• migration guide;

• automated test.

Jangan menghapus prop yang dipakai 50 aplikasi tanpa migration path.

Untuk monorepo, versioning bisa lebih sederhana karena perubahan dapat dilakukan lintas package bersamaan.

Untuk package eksternal, compatibility lebih penting.

Release design system seharusnya diperlakukan seperti release software.

Bagaimana Testing Design System Seharusnya Dilakukan?

Shared component memiliki blast radius besar.

Testing perlu mencakup:

• unit behavior;

• interaction;

• accessibility;

• visual regression;

• responsive;

• keyboard;

• theme;

• browser.

Visual regression sangat berguna.

Perubahan CSS kecil bisa memengaruhi puluhan component.

Screenshot diff membantu menemukan masalah sebelum release.

Namun jangan mengejar snapshot sempurna untuk setiap pixel.

Fokus pada regression yang memang berdampak.

Bagaimana Dokumentasi yang Bagus Membantu Adoption?

Component yang bagus tetapi sulit ditemukan tidak akan dipakai.

Dokumentasi perlu menjawab:

• apa fungsi component;

• kapan digunakan;

• kapan tidak;

• props;

• examples;

• states;

• accessibility;

• content guidance.

Carbon Design System, misalnya, membagi guidance component ke usage, style, code, dan accessibility.

Struktur seperti ini membantu berbagai role.

Designer melihat usage.

Developer melihat code.

QA melihat state.

Bagaimana Mengukur ROI Design System?

ROI design system sulit diukur hanya dari satu angka.

Gunakan beberapa indikator.

Adoption

Berapa persen feature menggunakan shared component?

Duplication

Apakah jumlah custom button/input menurun?

Delivery time

Apakah feature baru lebih cepat dibuat?

Bug

Apakah UI regression menurun?

Accessibility

Apakah issue yang sama bisa diperbaiki di satu tempat?

Consistency

Apakah audit UI menemukan lebih sedikit variasi?

Onboarding

Apakah developer baru lebih cepat produktif?

ROI design system adalah akumulasi pengurangan pekerjaan berulang.

Jangan hanya mengukur jumlah component.

50 component yang tidak digunakan tidak bernilai.

Kapan Design System Justru Menjadi Bottleneck?

Design system bisa menjadi bottleneck jika:

• semua perubahan harus menunggu satu tim;

• component terlalu rigid;

• release lambat;

• contribution sulit;

• dokumentasi tidak jelas;

• feature team sering fork component.

Jika tim mulai membuat:

CustomButtonV2

karena shared Button sulit diubah, itu sinyal.

Design system harus memberi foundation.

Bukan menjadi birokrasi.

Atlassian menyebut nilai design system mereka sebagai foundational, harmonious, dan empowering. Prinsip “empowering” penting: sistem harus mempermudah orang lain bekerja.

Bagaimana Menjaga Fleksibilitas Tanpa Kehilangan Konsistensi?

Gunakan layer.

Contoh:

Design Tokens
   ↓
Primitives
   ↓
Components
   ↓
Patterns
   ↓
Feature UI

Semakin ke bawah, semakin spesifik.

Feature bebas membangun experience.

Tetapi tetap menggunakan foundation yang sama.

Atlassian juga menggunakan primitives dan composition untuk membangun pengalaman yang tetap konsisten sambil memberi fleksibilitas pada developer.

Konsistensi tidak berarti semua layar identik.

Konsistensi berarti keputusan fundamental tidak dibuat ulang tanpa alasan.

Bagaimana Design System Mendukung Banyak Brand?

Multi-brand membuat design token semakin penting.

Shared component bisa menggunakan token berbeda untuk tenant atau brand.

Contoh:

Brand A:
color.primary = blue

Brand B:
color.primary = green

Component tetap sama.

Theme berubah.

Ini jauh lebih scalable daripada membuat component terpisah per brand.

Namun hanya cocok jika interaction pattern memang cukup serupa.

Jika brand memiliki experience yang benar-benar berbeda, jangan memaksakan satu component universal.

Contoh Skenario: Tanpa Design System

Bayangkan tiga squad membangun produk yang sama.

Squad A membuat modal.

Squad B juga membuat modal.

Squad C menyalin modal A lalu memodifikasi.

Enam bulan kemudian ada requirement:

semua modal harus memiliki focus trap, responsive layout baru, dan tombol close dengan accessible label.

Tim harus memperbaiki tiga implementasi.

Lalu ternyata ada dua modal lain yang dibuat oleh developer yang sudah pindah tim.

Pekerjaan sederhana berubah menjadi audit.

Contoh Skenario: Dengan Design System

Tim memiliki satu Dialog primitive.

Feature menggunakan:

<Dialog>
  <DialogHeader />
  <DialogBody />
  <DialogFooter />
</Dialog>

Saat accessibility behavior diperbaiki, semua consumer mendapat manfaat.

Feature team tetap mengontrol content.

Foundation tetap shared.

Inilah leverage design system.

Apa Hubungan Design System dengan Component Reuse?

Design system dan component reuse sangat terkait, tetapi tidak identik.

Artikel Kenapa Component Reuse Lebih Penting dari Framework yang Dipakai membahas bahwa reuse dapat mengurangi duplikasi dan biaya maintenance.

Design system memperluas prinsip itu.

Bukan hanya component yang di-share.

Design decision juga di-share.

Token.

Pattern.

Documentation.

Accessibility.

Language.

Karena itu, design system adalah infrastructure untuk consistency.

Checklist Design System yang Sehat

Sebelum memperbesar design system, cek:

1. Apakah component dibuat berdasarkan kebutuhan nyata?

2. Apakah design token punya semantic meaning?

3. Apakah desain dan code menggunakan vocabulary yang sama?

4. Apakah component API mudah dipahami?

5. Apakah accessibility diuji?

6. Apakah documentation tersedia?

7. Apakah contribution process jelas?

8. Apakah ada owner?

9. Apakah component punya lifecycle?

10. Apakah deprecated component dihapus?

11. Apakah adoption diukur?

12. Apakah feature team tetap fleksibel?

13. Apakah design system mempercepat delivery?

14. Apakah shared component benar-benar digunakan?

15. Apakah sistem mengurangi variasi UI?

Jika design system membutuhkan lebih banyak effort daripada value yang dihasilkan, scope-nya perlu dievaluasi.

FAQ tentang Design System

Apakah startup kecil perlu design system?

Tidak perlu design system besar. Tetapi token dasar dan beberapa shared components sudah bisa memberi manfaat. Mulai dari kebutuhan nyata lalu tumbuhkan secara bertahap.

Apa beda design system dan UI kit?

UI kit biasanya berisi asset visual atau component desain. Design system lebih luas karena mencakup prinsip, token, component implementation, dokumentasi, accessibility, dan governance.

Apakah design system hanya untuk designer?

Tidak. Developer, content designer, QA, dan product team juga merupakan pengguna. Design system yang hanya hidup di Figma belum menyelesaikan masalah implementasi.

Apakah semua UI harus memakai design system?

Tidak. Feature-specific UI tetap valid. Design system sebaiknya menangani pola yang reusable dan stabil.

Kapan component baru masuk design system?

Ketika use case-nya sudah cukup jelas, berulang, dan relevan lintas feature. Hindari memasukkan abstraction yang masih sangat eksperimental.

Bagaimana tahu design system berhasil?

Lihat adoption, pengurangan duplicate component, delivery speed, UI consistency, accessibility issue, dan seberapa sering feature team tetap membuat versi custom.

Kesimpulan

Design system memang membutuhkan investasi di awal.

Tim perlu menyusun token, component, dokumentasi, testing, governance, dan release process.

Tetapi biaya tersebut sebaiknya dibandingkan dengan alternatifnya: setiap designer dan developer terus membuat keputusan yang sama berkali-kali.

Ketika produk tumbuh, design system membantu menjaga konsistensi, mempercepat development, memperbaiki accessibility, mengurangi technical debt, dan membuat perubahan global lebih mudah dilakukan.

Kuncinya adalah jangan overengineering.

Mulai dari pattern yang benar-benar berulang.

Bangun foundation.

Dokumentasikan.

Ukur adoption.

Perbaiki berdasarkan penggunaan.

Design system yang sehat bukan library paling besar.

Ia adalah sistem yang membuat tim lebih sedikit mengulang keputusan dan lebih banyak fokus pada masalah produk yang benar-benar baru.

Jika tim kamu sedang membangun shared component library, design tokens, multi-brand UI, atau ingin merapikan frontend dan design workflow yang mulai tidak konsisten, kamu bisa diskusikan kebutuhan teknologi bisnis kamu dengan tim Sukses Corp Tech untuk membahas struktur design system yang sesuai dengan skala produk dan tim.