Belajar UX Designer - Design Systems & UX Governance

#Pendahuluan

Setelah di episode 15 kita memetakan layanan JagaKota secara utuh, ada masalah yang menanti di skala: semakin besar produk dan semakin banyak tim, semakin mudah desain berantakan — tombol sama tapi warna beda, spacing tidak konsisten, dan setiap fitur baru membawa gaya sendiri. Penangkalnya: design system dan tata kelola UX (UX governance).

Mengapa penting? Karena konsistensi adalah fondasi kepercayaan. Pengguna yang melihat tombol hijau di satu layar dan biru di layar lain tidak tahu mana yang benar — dan mulai meragukan produknya. Design system juga menghemat biaya: sekali membangun pola, seribu kali memakainya.

#Pattern Library vs Design System

Komponen tanpa aturan pemakaian bukan design system — ia galeri, bukan pedoman. Yang membedakan adalah governance: siapa yang mengubah apa, kapan, dan bagaimana.

#Design Tokens: Fondasi Atomik

Token adalah nilai dasar yang diberi nama dan disimpan terpusat — mengubah satu nilai mengubah seluruh produk.

{
  "color": {
    "brand": { "primary": { "value": "#166534" } },
    "feedback": { "error": { "value": "#B91C1C" } }
  },
  "space": {
    "xs": { "value": "4px" },
    "md": { "value": "16px" }
  },
  "type": {
    "size": { "title": { "value": "20px" } }
  }
}

Prinsip token: jangan menamai berdasarkan nilai (hijau-tombol) tapi berdasarkan semantik (brand.primary). Ketika brand berubah, tinggal ganti nilai di satu tempat — tidak perlu memburu semua layar.

#UX Governance: Mengelola Perubahan

Tata kelola menjawab tiga pertanyaan: siapa yang memutuskan, kapan, dan bagaimana perubahan disebarkan. Struktur umum:

• Komite/Champion design system — pemilik token dan pola; menyetujui komponen baru.
• Kontribusi — siapa pun bisa mengusulkan; ada jalur review standar (misal PR dengan dokumentasi + contoh pemakaian).
• Versioning — perubahan breaking diberi versi; tim lain tahu kapan harus migrasi.
• Changelog — catatan perubahan yang jelas; tanpa ini, komponen berubah diam-diam dan tim kaget.

usulan_komponen:
  - kebutuhan: kenapa komponen ini ada?
  - aksesibilitas: kontras, keyboard, label
  - token: hanya pakai nilai dari design tokens
  - contoh: 2+ use case nyata
  - alternatif: mengapa tidak memakai komponen existing?

#UX Debt: Harga yang Jatuh Tempo

UX debt analog dengan technical debt: keputusan desain yang ditunda untuk mempercepat rilis, dengan ongkos yang jatuh tempo di kemudian hari. Contoh: tombol yang pakai warna hardcoded, komponen yang "hanya untuk satu halaman", copy yang tidak konsisten.

Kelola seperti aset keuangan:

1. Katalogkan — daftar UX debt beserta dampaknya.
2. Ukur — berapa banyak pemakaian warna hardcoded? berapa layar yang melanggar pola?
3. Prioritaskan — berdasarkan dampak pengguna, bukan kemudahan perbaikan.
4. Alokasikan waktu — sisihkan persentase sprint untuk membayar utang (misal 10-20%).

#Common Pitfalls

• Membangun design system terlalu dini — sistem yang lahir tanpa cukup pemakaian nyata jadi kaku; biarkan pola muncul lalu formalisasi.
• Governance yang macet — terlalu banyak persetujuan membuat tim menghindari sistem dan bikin komponen sendiri.
• Token yang di-flag "final" — sistem hidup; tetap terbuka pada revisi dengan proses yang jelas.
• Lupa dokumentasi pemakaian — komponen tanpa contoh nyata tidak akan dipakai dengan benar.

#Penutup

Inti yang harus dibawa pulang:

• Design system = library + tokens + dokumentasi + governance; bukan sekadar galeri komponen.
• Token semantik (bukan berbasis nilai) membuat perubahan brand murah.
• Governance menentukan siapa mengubah apa dan bagaimana; tanpa itu sistem membusuk.
• UX debt wajib dikatalogkan, diukur, dan diberi anggaran waktu untuk dibayar.

Di episode 17 selanjutnya kita akan membahas cross-platform UX — web, mobile, tablet, dan kanal lain — serta keseimbangan konsistensi vs platform-specific untuk JagaKota. Sampai jumpa di episode 17!