Kontribusi Design System Tanpa Merusak yang Sudah Ada

Standup hari Selasa adalah tempat hal-hal ini mati. Anda sudah menghabiskan tiga hari di Figma membangun apa yang Anda kira adalah varian date-range picker yang bersih. DS lead sekilas melihat tautan share-nya, bersandar ke belakang, dan berkata: "Kita sudah punya komponen itu." Dan Anda menghitung dalam kepala. Tiga hari Anda sia-sia, atau versi yang dikirimkan adalah yang Anda buat terburu-buru, tidak ada yang memilikinya, dan delapan bulan kemudian seorang designer baru akan membangunnya ulang dan menyebutnya keempat kalinya.

Kedua hasil itu buruk. Kabar baiknya adalah kesenjangan antara keduanya adalah masalah proses, bukan masalah bakat. Saya pernah melihat designer IC mengirimkan ke sistem yang matang dalam dua minggu dan saya pernah melihat orang senior membakar enam bulan mencoba mendorong varian tombol melewati seorang penjaga. Perbedaannya jarang pada pekerjaannya. Hampir selalu pada model kontribusinya.

Ini adalah versi model yang berfungsi.

Mengapa Ini Penting Sekarang

Sistem yang terfragmentasi lebih mahal daripada yang lambat. Ada dua mode kegagalan yang saya lihat di setiap tim yang berjuang dengan ini, dan keduanya terlihat berlawanan tapi menghasilkan hasil yang sama.

Yang pertama adalah sistem yang terjaga ketat. Tim DS memiliki segalanya. Kontribusi membutuhkan tiga persetujuan dan slot roadmap kuartalan. IC berhenti mencoba setelah penolakan kedua. Pustaka membeku. Pola baru dibangun di luarnya karena lebih cepat, dan sekarang Anda memiliki design system yang sebenarnya adalah museum.

Yang kedua adalah kebebasan tanpa aturan. Siapa pun bisa menerbitkan apa pun. Pada bulan keenam, setiap squad produk punya komponen dropdown-nya sendiri, tiga tombol "utama" dengan warna biru yang sedikit berbeda, dan halaman Figma bernama "SEMENTARA, JANGAN DIGUNAKAN" yang semua orang gunakan. Selamat datang di tagihan fragmentasi Anda.

Tim produk tipikal yang saya audit memiliki 3-7 versi "tombol yang sama" pada tahun kedua. Bukan karena ada yang menginginkannya. Karena alur kontribusi terlalu ketat atau terlalu longgar, dan jalur paling mudah adalah membangun secara lokal dan tidak pernah mendorongnya kembali.

Model di bawah ini adalah jalan tengahnya. Model ini menganggap kontribusi sebagai keterampilan kerajinan, bukan keterampilan politik, dan IC yang mengirimkan pekerjaan DS yang bersih membangun pengaruh lebih cepat daripada yang membangun pustaka komponen privat.

Kapan Menggunakan DS vs. Membangun Komponen Baru

Sebagian besar percakapan "kita butuh komponen baru" berakhir begitu seseorang menjalankan uji 80/20. Ini dua pertanyaan:

1. Bisakah saya menyelesaikan 80% masalah ini dengan komponen yang sudah ada ditambah props atau varian?
2. Jika saya menambahkan ini, apakah setidaknya 20% tim akan menggunakannya dalam enam bulan?

Jika jawaban #1 ya, Anda tidak perlu komponen baru. Anda butuh varian atau prop, yang merupakan kontribusi yang lebih kecil, lebih cepat, lebih murah. Jika jawaban #1 tidak tapi #2 juga tidak, ini adalah komponen satu kali pakai. Simpan secara lokal, jangan meracuni pustaka.

Komponen baru hanya membenarkan dirinya sendiri ketika kedua jawaban berayun ke arah yang benar: kit yang ada tidak bisa menutup kasusnya, dan lebih dari satu tim akan menggunakannya kembali.

Jebakan yang paling sering saya lihat adalah apa yang saya sebut jebakan hampir-cocok. Seorang designer menemukan komponen yang 70% sesuai. Mereka melepas, mengubah padding, menukar token, dan mengirimkannya sebagai "berdasarkan" yang sudah ada. Enam bulan kemudian sudah menyimpang dalam tujuh cara yang tidak terlihat dan pemilik design system tidak memiliki catatan apa pun yang terjadi. Hampir-cocok lebih buruk dari mulai-dari-awal karena berpura-pura menjadi penggunaan ulang.

Pohon keputusan yang lebih sederhana, secara berurutan:

• Komponen yang ada, tanpa perubahan → gunakan.
• Komponen yang ada, prop atau state baru → usulkan varian pada yang sudah ada.
• Komponen yang ada tapi perilaku mendasarnya salah → usulkan refaktor, bukan fork.
• Pola yang benar-benar baru, banyak tim membutuhkannya → usulkan komponen baru.
• Pola yang benar-benar baru, hanya tim Anda yang membutuhkannya → bangun secara lokal, tandai sebagai lokal, tinjau kembali dalam 90 hari.

Yang terakhir tidak masalah. Komponen lokal bukan dosa. Berpura-pura komponen lokal adalah komponen sistem, itulah dosanya.

Alur Kontribusi: RFC, Review, Ship, Dokumentasi

Setelah Anda memutuskan layak ditambahkan, alurnya adalah empat tahap, masing-masing dengan batasan waktu. Keseluruhannya harus memakan waktu kurang dari dua minggu untuk kontribusi normal. Jika lebih lama, ada yang salah dengan prosesnya, bukan komponen.

Tahap 1, RFC (1-2 hari). Satu halaman. Masalah, solusi yang diusulkan, alternatif yang dipertimbangkan, catatan aksesibilitas, dan satu sketsa. Bukan enam mockup. Kesalahan yang saya buat selama bertahun-tahun adalah berinvestasi terlalu banyak pada fidelitas sebelum percakapan. Satu sketsa membiarkan pemilik DS menolak arahnya tanpa Anda merasa harus mempertahankan tiga hari pekerjaan piksel.

RFC juga tempat Anda menandai dependensi: token baru, ikon baru, perilaku yang menyentuh komponen yang ada. Jika Anda menemukan perlu token warna baru untuk membuat ini bekerja, itu sekarang menjadi bagian RFC, bukan kejutan di hari kedelapan.

Tahap 2, Review dengan pemilik DS (1-3 hari). Async-first, sinkron jika macet. Review bukan teater persetujuan. Ini sesi ko-desain. Pemilik DS bukan pemblokir Anda. Mereka adalah orang yang pada akhirnya akan merawat apa yang Anda kirimkan, jadi masukan mereka tentang penamaan, props, dan kasus edge adalah struktural, bukan stilistik.

Datanglah dengan RFC, tanyakan tiga hal: apakah ini termasuk dalam sistem, apakah bentuk yang diusulkan sesuai dengan pola yang ada, dan apa yang saya lewatkan di sisi engineering. Pergi dengan ya/tidak/perlu-perbaikan dan satu pemilik dari sisi DS yang akan mereview PR akhir.

Tahap 3, Ship di belakang flag (3-5 hari). Bangun di Figma, bangun di Storybook, kirimkan komponen React/Vue/apa pun ke feature flag atau channel beta dalam pustaka yang diterbitkan. Di-belakang-flag penting karena memungkinkan Anda dan satu atau dua early adopter menguji API sebelum masuk ke kit produksi. Sebagian besar kesalahan API muncul pada penggunaan nyata pertama, bukan dalam RFC.

Tahap 4, Dokumentasi dan promosi (1 hari). Story diterbitkan, dokumen penggunaan ditulis, catatan deprecasi jika menggantikan sesuatu, pengumuman di channel DS dengan satu paragraf "kapan harus menggunakannya." Kemudian promosikan dari beta ke GA dalam rilis pustaka berikutnya.

Jika satu tahap melebihi batas waktunya, itu adalah tanda bahaya. Tahap 1 memanjang berarti masalahnya belum jelas. Tahap 2 memanjang berarti pemilik DS memiliki kekhawatiran struktural dan perlu percakapan nyata, bukan revisi lain. Tahap 3 memanjang biasanya berarti API-nya salah dan Anda menambal di sekelilingnya. Tahap 4 tidak memanjang. Jika Anda melewatinya, Anda melewatkan bagian yang membuatnya nyata.

Konvensi Penamaan yang Bertahan

Penamaan adalah separuh membosankan dari kontribusi dan di sinilah sebagian besar kontribusi diam-diam gagal. Komponen bernama BigBlueBtn akan digunakan oleh tepat satu tim, secara ironis, dan tidak pernah lagi. Komponen bernama Button/Primary/Large diadopsi karena namanya memberi tahu Anda apa itu, di mana ia berada, dan bagaimana hubungannya dengan selebihnya.

Hierarki penamaan yang bertahan lama adalah token, komponen, varian, state. Jadi:

• Token: color/primary/600
• Komponen: Button
• Varian: Primary, Secondary, Ghost
• Ukuran: Small, Medium, Large
• State: Default, Hover, Disabled, Loading

Dibaca dari atas ke bawah: Button/Primary/Large/Hover tidak ambigu, dapat diurutkan, dan sesuai dengan cara tampilannya di panel komponen Figma dan navigasi Storybook.

Tiga aturan yang perlu dihafal:

1. Tanpa kata benda khusus. Tanpa TombolBob, tanpa ModalQ3, tanpa HeroMarketing. Nama mendeskripsikan bendanya, bukan pemintanya.
2. Tanpa singkatan di bawah 5 karakter. Btn tidak menghemat apa pun dan mengorbankan kemampuan pencarian. Notif lebih buruk dari Notification.
3. Tanpa kata sifat ukuran yang tidak ada dalam skala. "Besar" bukan sebuah ukuran. Large itu ukuran. Jika skala Anda adalah S/M/L, jangan perkenalkan XLG tanpa menambahkannya ke sistem skala secara menyeluruh terlebih dahulu.

Ketika nama bentrok (dan itu akan terjadi, terutama dalam sistem yang lebih besar), aturannya adalah: nama yang lebih umum milik kasus penggunaan yang lebih umum. Jika marketing menginginkan Card untuk kartu hero yang bergaya dan sistem sudah punya Card untuk container konten generik, komponen marketing menjadi Card/Hero atau HeroCard. Nama dasar tetap dengan perilaku dasar.

Minimum Aksesibilitas: WCAG AA sebagai Lantai

Komponen dikirimkan dengan uji aksesibilitas atau tidak dikirimkan sama sekali. Ini bukan tujuan yang bisa ditunda. WCAG AA adalah lantai, bukan langit-langit, dan itu adalah lantainya karena di bawahnya Anda mengirimkan komponen yang secara hukum dan etis mengecualikan pengguna.

Minimum yang perlu dipenuhi setiap komponen sebelum digabungkan:

Semua ini kini memiliki alat otomatis. axe-core di CI menangkap yang struktural. Storybook a11y addon menangkap kontras yang jelas dan kesalahan ARIA yang umum. Yang tidak akan tertangkap (dan yang harus benar-benar dilakukan IC) adalah uji jebakan keyboard: tab melalui setiap state, termasuk modal-terbuka, dropdown-diperluas, state-kesalahan. Jebakan keyboard adalah mode kegagalan yang paling sering saya lihat dan paling mudah diuji.

Jika Anda tidak yakin apakah komponen Anda lulus, uji dulu sebelum masuk review. Pemilik DS yang harus menandai kegagalan kontras di tahap 2 baru saja menemukan bahwa Anda tidak melakukan tugasnya. Kontribusi yang tiba bersih dari sisi a11y adalah kontribusi yang disetujui cepat.

Kebersihan Pustaka Figma

Figma adalah tempat kontribusi secara diam-diam membusuk jika Anda tidak memperhatikan. Dua hal yang penting:

Diterbitkan vs. lokal. Komponen yang diterbitkan tinggal di pustaka tim dan disebarkan ke setiap file yang menggunakannya. Komponen lokal tinggal di file yang sedang Anda kerjakan dan tidak menyebar ke mana pun. Kesalahannya adalah menggunakan komponen lokal untuk pekerjaan prototipe, lalu lupa menghapusnya atau mempromosikannya. Enam bulan kemudian file dibuka dan seseorang menyalin yang lokal karena bentuknya benar.

Aturan: komponen lokal dipromosikan ke pustaka yang diterbitkan dalam dua minggu, atau dihapus. Tidak ada keadaan ketiga.

Instance yang dilepas adalah tanda bahaya. Ketika seorang designer melepas instance, mereka berkata: "Saya butuh komponen ini tapi sedikit berbeda dan saya tidak mau repot dengan sistem." Itu sinyal. Kadang jawaban yang benar adalah menambahkan varian. Kadang memperbaiki komponen mendasar. Kadang designer sedang terburu-buru. Tapi setiap instance yang dilepas adalah data, dan tinjauan bulanan harus melacaknya.

Tinjauan itu sendiri bersifat mekanis: sekali sebulan, jalankan audit instance Figma (atau plugin seperti Instance Finder), buat daftar instance yang dilepas, dan bahas dengan designer yang bertanggung jawab. Gabungkan kembali, usulkan varian, atau hapus. Tiga puluh menit pekerjaan yang mencegah tiga bulan fragmentasi.

Paritas Kode-Desain (Storybook)

Setiap komponen Figma memiliki Storybook story atau itu bukan komponen nyata. Ini aturan yang perlu dipajang di dinding.

Storybook adalah satu-satunya tempat di mana desain dan kode ada bersama sebagai artefak yang sama. Figma menunjukkan bagaimana komponen seharusnya terlihat. Storybook menunjukkan bagaimana komponen sebenarnya. Ketika keduanya menyimpang (dan selalu terjadi), Storybook adalah sumber kebenaran, karena itulah yang dilihat pengguna.

Storybook story nyata untuk komponen yang dikontribusikan memiliki:

• Semua varian dirender (Primary, Secondary, Ghost, dll.)
• Semua state dirender (Default, Hover, Focus, Disabled, Loading, Error)
• Panel kontrol yang memungkinkan reviewer mengubah props secara langsung
• Fungsi play yang menjalankan interaksi keyboard
• Laporan a11y addon tanpa pelanggaran
• Baseline regresi visual yang di-commit (Chromatic, Percy, atau buatan sendiri)

Regresi visual di CI menangkap penyimpangan sebelum PM melakukannya. Ketika seseorang memperbarui komponen Button dan token padding berubah dua piksel di empat puluh stories, diff-nya muncul di PR. Pemilik DS menyetujui atau menolak. Tidak ada kerusakan mengejutkan di produksi.

Tanpa itu, Anda tahu tentang penyimpangan ketika pelanggan men-screenshot formulir yang tidak sejajar.

Jadwal Deprecasi

Hal-hal yang Anda kirimkan pada akhirnya tidak akan menjadi jawaban yang tepat lagi. Disiplin deprecasi adalah cara Anda menghindari masalah sistem-museum.

Jadwal yang saya rekomendasikan:

• Tinjauan kuartalan. Setiap kuartal, tim DS ditambah 2-3 designer IC menelusuri pustaka dan menandai komponen yang: penggunaan rendah (kurang dari 5 instance di seluruh codebase), digantikan oleh varian yang lebih baru, atau tidak lagi memenuhi standar a11y/visual.
• Jendela deprecasi dua rilis. Setelah komponen ditandai, tandai sebagai @deprecated di Storybook, tambahkan banner deprecasi di Figma, dan kirimkan pengganti (atau jalur migrasi). Berikan dua siklus rilis (biasanya dua bulan) sebelum penghapusan.
• Sediakan codemod. Inilah bagian yang selalu dilewati tim. Jika Anda mendeprecasi komponen yang digunakan di 200 tempat, "tolong migrasikan" bukan sebuah rencana. Kirimkan codemod (skrip kecil yang secara otomatis menulis ulang <OldButton> menjadi <Button variant="primary">) sehingga migrasi membutuhkan menit, bukan minggu. Tanpa codemod, deprecasi diabaikan dan komponen lama hidup selamanya.

Kesalahan Umum

Empat cara kontribusi berjalan salah, dalam urutan frekuensi:

1. Mendesain dalam isolasi, lalu mempresentasikan hasil jadi. Anda menghabiskan tiga hari di Figma. Pemilik DS punya tiga puluh detik konteks dan sekarang Anda ingin mereka merestui enam mockup. Mereka tidak akan. Bawa sketsa lebih awal, pekerjaan yang sudah jadi lebih terlambat.
2. Copy-paste komponen terdekat yang ada dan "hanya mengubah sedikit." Jebakan hampir-cocok. Komit untuk varian nyata atau bangun sesuatu yang baru. Jangan pernah mengirimkan pelepasan yang dimodifikasi seolah-olah itu komponen sistem.
3. Melewatkan Storybook story karena "dev yang akan melakukannya." Mereka tidak akan, atau mereka melakukannya dengan buruk karena mereka tidak tahu maksud desainnya. Story adalah spesifikasi Anda, sama seperti komponen Figma. Jika Anda tidak menulisnya, interpretasi dev menjadi kebenarannya.
4. Memperlakukan pemilik DS sebagai pemblokir alih-alih ko-penulis. Ini adalah kesalahan mindset terbesar. Pemilik DS memiliki lebih banyak konteks daripada Anda tentang apa yang akan datang, apa yang sudah deprecated, apa yang akan dibutuhkan tim. Libatkan mereka lebih awal dan mereka mempercepat kontribusi Anda. Hindari mereka dan mereka memperlambatnya karena harus merekonstruksi alasan Anda.

Template dan Alat

Tiga artefak yang perlu selalu tersedia:

Template RFC satu halaman. Masalah (maks 3 kalimat), solusi yang diusulkan (1 sketsa + 3 poin), alternatif yang dipertimbangkan (2-3, dengan alasan tidak dipilih), catatan aksesibilitas, dependensi, siapa yang terpengaruh. Jika tidak muat dalam satu halaman, kontribusinya belum cukup terfokus.

Checklist komponen. Token yang digunakan, varian yang didefinisikan, semua state yang didesain, uji a11y lulus, Storybook story diterbitkan dengan kontrol dan fungsi play, dokumen penggunaan ditulis, baseline regresi visual di-commit, pemberitahuan deprecasi jika menggantikan sesuatu. Tempelkan di dekat monitor Anda.

Template pemberitahuan deprecasi. Apa yang dideprecasi, apa yang menggantikannya, tautan ke panduan migrasi, perintah codemod, tanggal penghapusan. Diposting di channel DS, ditambahkan ke halaman Storybook, banner di komponen Figma.

Mengukur Keberhasilan

Anda akan tahu model ini berfungsi ketika:

• Kontribusi Anda masuk ke pustaka yang diterbitkan dalam dua minggu dari RFC. Lebih dari itu, ada yang rusak dalam alurnya.
• Nol instance yang dilepas dari komponen Anda setelah tiga puluh hari. Jika sudah muncul, API tidak mencakup kasus penggunaannya.
• Storybook story ada, memiliki fungsi play, dan nol pelanggaran a11y.
• Satu tim lain mengadopsi komponen tanpa bertanya kepada Anda. Ini sinyal nyata: ketika penggunaan ulang terjadi secara organik, Anda benar-benar telah berkontribusi pada sistem, bukan hanya menambahkan ke dalamnya.

IC yang mengirimkan pekerjaan DS yang bersih membangun pengaruh lebih cepat daripada yang membangun pustaka komponen privat, karena setiap kontribusi yang bersih membuat kontribusi berikutnya lebih cepat, untuk Anda dan untuk semua orang.

Pelajari Lebih Lanjut

• Job Description Product Designer
• Kritik Desain yang Benar-Benar Meningkatkan Pekerjaan
• Serah Terima ke Engineering Tanpa Loop Dorong Piksel
• Aksesibilitas Melampaui Checklist