Sumbangan Design System Tanpa Merosakkan Yang Sedia Ada

Standup hari Selasa adalah tempat perkara-perkara ini berakhir. Anda telah menghabiskan tiga hari dalam Figma membina apa yang anda fikir adalah varian pemilih julat tarikh yang bersih. Ketua DS melirik pautan perkongsian, bersandar ke belakang, dan berkata: "Kita dah ada komponen tu." Dan anda mengira dalam kepala. Sama ada tiga hari anda terbuang, atau versi yang dihantar adalah versi sekali-gus yang anda bina dengan tergesa-gesa, tiada siapa yang memilikinya, dan dalam lapan bulan pereka baru akan membinanya semula dan menamakannya kali keempat.

Kedua-dua hasil itu buruk. Berita baiknya ialah jurang di antara keduanya adalah masalah proses, bukan masalah bakat. Saya telah melihat pereka IC menghantar ke dalam sistem matang dalam dua minggu dan saya telah melihat orang kanan membakar enam bulan cuba menolak varian butang melepasi pengawal. Perbezaannya jarang pada kerjanya. Ia hampir selalu pada model sumbangan.

Ini adalah versi model tersebut yang berfungsi.

Mengapa Ini Penting Sekarang

Sistem yang terpecah-belah lebih mahal daripada sistem yang perlahan. Terdapat dua mod kegagalan yang saya lihat pada setiap pasukan yang bergelut dengan ini, dan ia kelihatan bertentangan tetapi menghasilkan hasil yang sama.

Yang pertama adalah sistem yang dikawal ketat. Pasukan DS memiliki segalanya. Sumbangan memerlukan tiga kelulusan dan slot roadmap suku tahunan. IC berhenti mencuba selepas penolakan kedua. Pustaka membeku. Corak baru dibina di luar sistem kerana lebih pantas, dan kini anda mempunyai design system yang sebenarnya sebuah muzium.

Yang kedua adalah bebas untuk semua. Sesiapa boleh menerbitkan apa-apa. Pada bulan keenam, setiap skuad produk mempunyai komponen dropdown sendiri, tiga butang "utama" dalam warna biru yang sedikit berbeza, dan halaman Figma bernama "TEMP, JANGAN GUNA" yang semua orang gunakan. Selamat datang ke cukai pemecahan anda.

Pasukan produk biasa yang saya audit mempunyai 3 hingga 7 versi butang "yang sama" menjelang tahun kedua. Bukan kerana sesiapa mahukan itu. Kerana aliran sumbangan sama ada terlalu ketat atau terlalu longgar, dan laluan paling mudah adalah membina secara setempat dan tidak pernah menolak kembali.

Model di bawah adalah laluan tengah. Ia mengandaikan sumbangan adalah kemahiran kraf, bukan kemahiran politik, dan IC yang menghantar kerja DS yang bersih memperolehi pengaruh lebih cepat daripada yang membina pustaka komponen persendirian.

Bila Menggunakan DS vs. Membina Komponen Baharu

Kebanyakan perbualan "kita perlu komponen baru" berakhir saat seseorang menjalankan ujian 80/20. Ia adalah dua soalan:

1. Bolehkah saya menyelesaikan 80% daripada ini dengan komponen sedia ada ditambah props atau varian?
2. Jika saya menambah ini, adakah sekurang-kurangnya 20% pasukan akan menggunakannya dalam enam bulan?

Jika jawapan kepada #1 adalah ya, anda tidak memerlukan komponen baru. Anda memerlukan varian atau prop, yang merupakan sumbangan yang lebih kecil, lebih pantas, dan lebih murah. Jika jawapan kepada #1 adalah tidak tetapi #2 juga tidak, ini adalah komponen sekali-gus. Simpan setempat, jangan cemar pustaka.

Komponen baru hanya wajar apabila kedua-dua jawapan condong ke arah yang betul: kit sedia ada tidak dapat menampung kes tersebut, dan lebih daripada satu pasukan akan menggunakannya semula.

Perangkap yang paling kerap saya lihat adalah apa yang saya panggil perangkap hampir-sesuai. Pereka menemukan komponen yang 70% betul. Mereka memisahkannya, mengubah suai padding, menukar token, dan menghantarnya sebagai "berasaskan" yang sedia ada. Enam bulan kemudian ia telah menyimpang dalam tujuh cara yang tidak kelihatan dan pemilik design system tidak mempunyai rekod apa pun yang berlaku. Hampir-sesuai lebih teruk daripada bermula-dari-awal kerana ia berpura-pura sebagai guna semula.

Pokok keputusan yang lebih mudah, mengikut urutan:

• Komponen sedia ada, tiada perubahan, gunakan ia.
• Komponen sedia ada, prop atau keadaan baharu, cadangkan varian pada yang sedia ada.
• Komponen sedia ada tetapi tingkah laku asasnya salah, cadangkan pemfaktoran semula, bukan garpu.
• Corak benar-benar baharu, pelbagai pasukan memerlukannya, cadangkan komponen baharu.
• Corak benar-benar baharu, hanya pasukan anda memerlukannya, bina setempat, tandakan sebagai setempat, semak semula dalam 90 hari.

Yang terakhir itu baik. Komponen setempat bukan dosa. Berpura-pura komponen setempat adalah komponen sistem itulah yang jadi masalah.

Aliran Sumbangan: RFC, Semakan, Hantar, Dokumen

Setelah anda memutuskan ia bernilai ditambah, aliran adalah empat peringkat, setiap satu dihadkan masa. Keseluruhannya sepatutnya mengambil masa kurang daripada dua minggu untuk sumbangan biasa. Apa-apa yang lebih lama, ada sesuatu yang salah dengan prosesnya, bukan komponennya.

Peringkat 1, RFC (1 hingga 2 hari). Satu halaman. Masalah, penyelesaian yang dicadangkan, alternatif yang dipertimbangkan, nota kebolehcapaian, dan satu lakaran. Bukan enam mockup. Kesilapan yang saya buat selama bertahun-tahun adalah melabur terlalu banyak dalam kesetiaan sebelum perbualan. Satu lakaran membenarkan pemilik DS menolak arah tanpa anda berasa perlu mempertahankan tiga hari kerja piksel.

RFC juga adalah tempat anda menandakan kebergantungan: token baharu, ikon baharu, tingkah laku yang menyentuh komponen sedia ada. Jika anda mendapati anda memerlukan token warna baharu untuk membuatnya berfungsi, itu kini sebahagian daripada RFC, bukan kejutan pada hari kelapan.

Peringkat 2, Semakan dengan pemilik DS (1 hingga 3 hari). Async dahulu, segerak jika tersekat. Semakan bukan acara kelulusan. Ia adalah sesi reka bentuk bersama. Pemilik DS bukan penghalang anda. Mereka adalah orang yang akhirnya akan menyelenggara apa yang anda hantar, jadi input mereka tentang penamaan, props, dan kes tepi adalah struktural, bukan stilistik.

Masuk dengan RFC, tanya tiga perkara: adakah ini tergolong dalam sistem, adakah bentuk yang dicadangkan sepadan dengan corak sedia ada, dan apa yang saya terlepas di pihak kejuruteraan. Keluar dengan ya/tidak/perlu-kerja dan seorang pemilik tunggal dari pihak DS yang akan menyemak PR akhir.

Peringkat 3, Hantar di belakang bendera (3 hingga 5 hari). Bina dalam Figma, bina dalam Storybook, hantar komponen React/Vue/apa sahaja ke bendera ciri atau saluran beta dalam pustaka yang diterbitkan. Hantar di belakang bendera penting kerana ia membolehkan anda dan satu atau dua pengamal awal menguji tekanan API sebelum ia masuk ke dalam kit pengeluaran. Kebanyakan kesilapan API muncul dalam penggunaan sebenar pertama, bukan dalam RFC.

Peringkat 4, Dokumen dan promosi (1 hari). Story diterbitkan, dokumen penggunaan ditulis, nota pemansuhan jika ia menggantikan sesuatu, pengumuman dalam saluran DS dengan perenggan "bila untuk menggunakannya." Kemudian naikkan taraf dari beta ke GA dalam keluaran pustaka seterusnya.

Jika mana-mana peringkat tunggal melebihi had masanya, itu adalah isyarat amaran. Peringkat 1 yang memanjang bermakna masalahnya tidak jelas. Peringkat 2 yang memanjang bermakna pemilik DS mempunyai kebimbangan struktural dan memerlukan perbualan sebenar, bukan semakan lain. Peringkat 3 yang memanjang biasanya bermakna API salah dan anda sedang menampal sekelilingnya. Peringkat 4 tidak memanjang. Jika anda melangkauinya, anda melangkau bahagian yang menjadikannya nyata.

Konvensyen Penamaan yang Bertahan

Penamaan adalah separuh yang membosankan daripada sumbangan dan ia adalah tempat kebanyakan sumbangan gagal secara senyap. Komponen bernama BigBlueBtn akan digunakan oleh tepat satu pasukan, secara ironi, dan kemudian tidak lagi. Komponen bernama Button/Primary/Large diterima pakai kerana namanya memberitahu anda apa ia, di mana ia duduk, dan bagaimana ia berkaitan dengan yang lain.

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

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

Baca dari atas ke bawah: Button/Primary/Large/Hover tidak samar-samar, boleh disusun, dan sepadan dengan bagaimana ia sepatutnya muncul dalam panel komponen Figma dan dalam navigasi Storybook.

Tiga peraturan yang perlu dihafal:

1. Tiada kata nama khas. Tiada BobsButton, tiada Q3Modal, tiada MarketingHero. Nama itu menggambarkan perkara itu, bukan pemohon.
2. Tiada singkatan di bawah 5 aksara. Btn tidak menjimatkan apa-apa dan mengorbankan kebolehcarian. Notif lebih buruk daripada Notification.
3. Tiada kata sifat saiz yang tidak ada dalam skala. "Besar" bukan saiz. Large adalah. Jika skala anda adalah S/M/L, jangan perkenalkan XLG tanpa menambahkannya ke dalam sistem skala dulu.

Apabila nama berlanggar (dan ia akan berlanggar, terutamanya dalam sistem yang lebih besar), peraturannya ialah: nama yang lebih umum dimiliki oleh kes penggunaan yang lebih umum. Jika pemasaran mahukan Card untuk kad wira bergaya dan sistem sudah mempunyai Card untuk bekas kandungan generik, komponen pemasaran menjadi Card/Hero atau HeroCard. Nama asas kekal dengan tingkah laku asas.

Minimum Kebolehcapaian: WCAG AA sebagai Lantai

Komponen dihantar bersama ujian kebolehcapaian atau ia tidak dihantar. Ini bukan matlamat regangan. WCAG AA adalah lantai, bukan siling, dan ia adalah lantai kerana di bawahnya anda menghantar komponen yang mengecualikan pengguna secara undang-undang dan etika.

Minimum yang perlu dilalui setiap komponen sebelum ia digabungkan:

Setiap satu ini kini mempunyai alatan automatik. axe-core dalam CI menangkap yang struktural. Tambahan a11y Storybook menangkap kesilapan kontras dan ARIA yang jelas. Apa yang tidak dapat ditangkapnya (dan apa yang IC perlu lakukan sebenarnya) adalah ujian perangkap papan kekunci: tab melalui setiap keadaan, termasuk modal-terbuka, dropdown-terkembang, keadaan-ralat. Perangkap papan kekunci adalah mod kegagalan yang paling kerap saya lihat dan yang paling mudah diuji.

Jika anda tidak pasti sama ada komponen anda lulus, hantarnya melalui ujian sebelum menghantarnya melalui semakan. Pemilik DS yang perlu menandakan kegagalan kontras di peringkat 2 baru sahaja mendapati anda tidak melakukan kerja. Sumbangan yang tiba bersih dari segi kebolehcapaian adalah sumbangan yang mendapat kelulusan cepat.

Kebersihan Pustaka Figma

Figma adalah tempat sumbangan membusuk secara senyap jika anda tidak memberi perhatian. Dua perkara yang penting:

Diterbitkan vs. setempat. Komponen yang diterbitkan tinggal dalam pustaka pasukan dan tersebar ke setiap fail yang mengambilnya. Komponen setempat tinggal dalam fail yang sedang anda kerjakan dan tidak tersebar ke mana-mana. Kesilapannya adalah menggunakan komponen setempat untuk kerja prototaip, kemudian terlupa untuk sama ada memadamkannya atau menaikkan tarafnya. Enam bulan kemudian fail dibuka dan seseorang menyalin yang setempat kerana ia mempunyai bentuk yang betul.

Peraturan: komponen setempat sama ada dinaikkan taraf ke pustaka yang diterbitkan dalam dua minggu, atau dipadam. Tiada keadaan ketiga.

Instans yang dipisahkan adalah tanda amaran. Apabila pereka memisahkan instans, mereka berkata: "Saya memerlukan komponen ini tetapi sedikit berbeza dan saya tidak mahu berurusan dengan sistem." Itu adalah isyarat. Kadangkala jawapan yang betul adalah menambah varian. Kadangkala ia adalah memperbaiki komponen asas. Kadangkala pereka hanya terburu-buru. Tetapi setiap instans yang dipisahkan adalah data, dan sapu bulanan perlu menjejaki mereka.

Sapu itu sendiri adalah mekanikal: sekali sebulan, jalankan audit instans Figma (atau pemalam seperti Instance Finder), senaraikan instans yang dipisahkan, dan telusuri bersama pereka yang bertanggungjawab. Sama ada pasang semula, cadangkan varian, atau padam. Tiga puluh minit kerja yang mencegah tiga bulan pemecahan.

Pariti Kod-Reka Bentuk (Storybook)

Setiap komponen Figma mempunyai story Storybook atau ia tidak nyata. Inilah peraturan yang perlu dipasang di dinding.

Storybook adalah satu-satunya tempat di mana reka bentuk dan kod wujud bersama sebagai artifak yang sama. Figma menunjukkan anda bagaimana komponen sepatutnya kelihatan. Storybook menunjukkan anda apa ia sebenarnya. Apabila mereka menyimpang (dan mereka sentiasa menyimpang), Storybook adalah sumber kebenaran, kerana itulah yang dilihat pengguna.

Story Storybook sebenar untuk komponen yang disumbangkan mempunyai:

• Semua varian dirender (Primary, Secondary, Ghost, dan sebagainya)
• Semua keadaan dirender (Default, Hover, Focus, Disabled, Loading, Error)
• Panel kawalan yang membolehkan penyemak togol props secara langsung
• Fungsi main yang melatih interaksi papan kekunci
• Laporan tambahan a11y tanpa sebarang pelanggaran
• Garis dasar regresi visual yang dilakukan (Chromatic, Percy, atau buatan sendiri)

Regresi visual dalam CI menangkap penyimpangan sebelum PM mendapatinya. Apabila seseorang mengemas kini komponen Button dan token padding berubah dua piksel merentasi empat puluh story, perbezaan muncul dalam PR. Pemilik DS meluluskan atau menolak. Tiada kerosakan mengejut dalam pengeluaran.

Tanpanya, anda mendapati penyimpangan apabila pelanggan mengambil tangkapan skrin borang yang tidak sejajar di Twitter.

Kadar Pemansuhan

Perkara yang anda hantar akhirnya tidak akan menjadi jawapan yang betul. Disiplin pemansuhan adalah cara anda mengelakkan masalah sistem muzium.

Kadar yang perlu dijalankan:

• Semakan suku tahunan. Setiap suku, pasukan DS bersama 2 hingga 3 pereka IC menelusuri pustaka dan menandakan komponen yang: penggunaan rendah (kurang daripada 5 instans merentasi pangkalan kod), digantikan oleh varian yang lebih baharu, atau tidak lagi memenuhi piawaian kebolehcapaian/visual.
• Tetingkap pemansuhan dua keluaran. Setelah komponen ditandakan, tandainya @deprecated dalam Storybook, tambah sepanduk pemansuhan dalam Figma, dan hantar penggantian (atau laluan migrasi). Berikan dua kitaran keluaran (biasanya dua bulan) sebelum pembuangan.
• Sediakan codemod. Inilah bahagian yang pasukan selalu langkau. Jika anda memansuhkan komponen yang digunakan di 200 tempat, "sila migrasi" bukan satu rancangan. Hantar codemod (skrip kecil yang menulis semula <OldButton> kepada <Button variant="primary"> secara automatik) supaya migrasi mengambil masa beberapa minit, bukan minggu. Tanpa codemod, pemansuhan diabaikan dan komponen lama hidup selama-lamanya.

Perangkap Biasa

Empat cara sumbangan gagal, mengikut urutan kekerapan:

1. Mereka bentuk secara berasingan, kemudian membentangkan hasil siap. Anda menghabiskan tiga hari dalam Figma. Pemilik DS mempunyai tiga puluh saat konteks dan kini anda mahu mereka merestui enam mockup. Mereka tidak akan berbuat demikian. Bawa lakaran awal, bawa kerja siap lewat.
2. Menyalin-tampal komponen yang paling hampir dan "hanya mengubah suai sedikit." Perangkap hampir-sesuai. Sama ada komited kepada varian sebenar atau bina sesuatu yang baharu. Jangan sekali-kali hantar pisahan yang diubah suai seolah-olah ia adalah komponen sistem.
3. Melangkau story Storybook kerana "pembangun akan melakukannya." Mereka tidak akan, atau mereka akan melakukannya dengan buruk kerana mereka tidak mengetahui niat reka bentuk. Story adalah spesifikasi anda, sama seperti komponen Figma. Jika anda tidak menulisnya, tafsiran pembangun menjadi kebenaran.
4. Melayan pemilik DS sebagai penghalang dan bukannya pengarang bersama. Ini adalah kesilapan pemikiran yang terbesar. Pemilik DS mempunyai lebih banyak konteks daripada anda tentang apa yang akan datang, apa yang sudah lapuk, apa yang diperlukan pasukan. Libatkan mereka awal dan mereka mempercepat sumbangan anda. Elak mereka dan mereka melambatkannya kerana mereka perlu memahami pemikiran anda secara terbalik.

Templat dan Alatan

Tiga artifak yang perlu sentiasa tersedia:

Templat RFC satu halaman. Masalah (maksimum 3 ayat), penyelesaian yang dicadangkan (1 lakaran dan 3 butiran), alternatif yang dipertimbangkan (2 hingga 3, dengan sebab-tidak), nota kebolehcapaian, kebergantungan, siapa yang terjejas. Jika anda tidak dapat muatkannya dalam satu halaman, skop sumbangan tidak cukup ketat.

Senarai semak komponen. Token yang digunakan, varian ditakrifkan, semua keadaan direka bentuk, ujian kebolehcapaian lulus, story Storybook diterbitkan dengan kawalan dan fungsi main, dokumen penggunaan ditulis, garis dasar regresi visual dilakukan, notis pemansuhan jika menggantikan sesuatu. Lekatkan ia di sebelah monitor anda.

Templat notis pemansuhan. Apa yang dipansuhkan, apa yang menggantikannya, pautan ke panduan migrasi, arahan codemod, tarikh pembuangan. Dihantar dalam saluran DS, ditambah ke halaman Storybook, sepanduk dalam komponen Figma.

Mengukur Kejayaan

Anda akan tahu model berfungsi apabila:

• Sumbangan anda mendarat dalam pustaka yang diterbitkan dalam dua minggu selepas RFC. Lebih lama daripada itu, sesuatu dalam aliran rosak.
• Sifar instans yang dipisahkan daripada komponen anda selepas tiga puluh hari. Jika mereka muncul, API tidak menampung kes penggunaan.
• Story Storybook wujud, mempunyai fungsi main, dan mempunyai sifar pelanggaran kebolehcapaian.
• Satu pasukan lain menerima pakai komponen tanpa bertanya kepada anda. Ini adalah isyarat sebenar: apabila guna semula berlaku secara organik, anda benar-benar telah menyumbang kepada sistem, bukan hanya menambah kepadanya.

IC yang menghantar kerja DS yang bersih memperolehi pengaruh lebih cepat daripada yang membina pustaka komponen persendirian, kerana setiap sumbangan yang bersih menjadikan yang seterusnya lebih pantas, untuk anda dan untuk semua orang.

Ketahui Lebih Lanjut

• Penerangan Kerja Pereka Produk
• Kritik Reka Bentuk yang Benar-Benar Memperbaiki Kerja
• Penyerahan kepada Kejuruteraan Tanpa Gelung Menolak Piksel
• Kebolehcapaian Melampaui Senarai Semak