Definisikan keputusan, bukan sekadar galeri gaya
Sistem desain lebih dari sekadar tangkapan layar. Ia merekam keputusan yang berulang: jarak antar bagian, perlakuan tindakan utama, cara kerja kesalahan formulir, dan bahasa yang digunakan setelah berhasil atau gagal. USWDS menggambarkan design tokens sebagai palet diskrit untuk nilai seperti tipografi, spasi, warna, tinggi garis, dan opasitas. Dokumentasikan aturan, tujuan, varian yang disetujui, dan pemiliknya. Mulailah dengan fondasi dan lima sampai delapan komponen yang paling sering digunakan dalam perjalanan penting; menstandarkan setiap halaman sekaligus biasanya menimbulkan kebisingan daripada kejelasan.
Catat peran warna yang disetujui, tipografi, spasi, border, radius, breakpoint, dan pilihan gerak yang benar-benar digunakan situs Anda.
Gunakan pola untuk susunan tugas yang dapat diulang, seperti pembuatan akun atau hasil pencarian, daripada untuk sekadar ornamen visual tunggal.
Gunakan token untuk mengendalikan nilai berulang
Design token adalah nama yang mudah dibaca yang diasosiasikan dengan sebuah nilai. Design Tokens Community Group menggambarkan token sebagai cara lintas platform untuk mengekspresikan keputusan desain; paling sedikit, token adalah nama dan nilai. Gunakan nama bertujuan seperti color-action-primary atau space-section daripada menyebarkan nilai mentah di seluruh template. Simpan pemetaan terdokumentasi dari token tujuan ke nilai dasar. Token mempermudah perubahan terkoordinasi, tetapi mereka tidak menjamin kontras, branding, atau hirarki yang baik. Validasi setiap kombinasi yang dirender dan status halaman.
Buat token untuk pilihan yang berulang, bukan setiap pengecualian; jika tidak, daftar token hanya akan mempertahankan ketidakkonsistenan.
Untuk token yang digunakan luas, cantumkan halaman yang terpengaruh, uji layar perwakilan, dan berikan panduan migrasi atau rollback bila diperlukan.
Bangun komponen dengan perilaku dan batasan
Komponen adalah bagian antarmuka yang dapat digunakan kembali dengan perilaku, bukan hanya bentuk visual. Dokumentasikan struktur semantik, input yang wajib dan opsional, varian, perilaku responsif, dan semua status relevan: loading, disabled, error, empty, dan success. Sertakan perilaku keyboard dan panduan konten. Jangan memaksakan setiap tata letak ke dalam komponen. GOV.UK mengevaluasi komponen bersama untuk kegunaan, keunikan, kegunaan, konsistensi, dan keserbagunaan; itu adalah disiplin berguna untuk memutuskan apa yang layak dipelihara bersama. Komponen yang digunakan luas dapat menyebarkan cacat secara luas, jadi uji di halaman tempat orang menggunakannya.
Daftarkan setiap status yang terlihat pengguna dan tunjukkan label nyata, teks panjang, dan kesalahan sehingga batasan implementasi terlihat.
Tandai varian lama dengan jelas, beri nama penggantinya, dan hapus hanya setelah perjalanan yang terdampak ditinjau.
Jadikan aksesibilitas sebagai kondisi rilis
Aksesibilitas harus dibangun ke dalam sistem karena pilihan berulang dapat mengulangi hambatan. WCAG 2.2 mengharuskan, pada Level A, operasi keyboard untuk fungsionalitas kecuali jalur gerak itu melekat, dan mengharuskan urutan fokus yang bermakna saat urutan penting. Buat kontrol semantik, fokus yang terlihat, label, pergerakan fokus yang logis, identifikasi kesalahan, dan penyelesaian tugas tanpa pointer bagian dari panduan komponen. Gunakan pemeriksaan otomatis sejak awal, lalu pengujian manual keyboard, zoom, responsif, dan halaman. USWDS memperingatkan bahwa komponen yang dapat diakses tidak menjamin layanan yang dapat diakses; kode khusus, salinan, integrasi, dan konteks tetap perlu ditinjau.
Pastikan orang dapat mencapai, mengoperasikan, memahami, dan meninggalkan kontrol tanpa mouse atau jebakan keyboard.
Kewajiban hukum bervariasi menurut yurisdiksi dan kontrak. Mintalah tinjauan aksesibilitas dan hukum yang memenuhi syarat ketika kepatuhan bersifat material.
Perlakukan standar konten sebagai standar antarmuka
Kata-kata adalah input komponen, bukan dekorasi yang ditambahkan setelah desain. Tetapkan aturan untuk label tindakan, label formulir, kesalahan, heading, tautan, terminologi, tanggal, angka, dan singkatan. Panduan GOV.UK memfavoritkan suara aktif dan berbicara langsung kepada pengguna sebagai 'you' bila memungkinkan; gunakan prinsip bahasa yang jelas dan konsisten, sambil menyesuaikan suara dengan audiens Anda. Padukan aturan dengan model konten: nyatakan bidang mana yang wajib, panduan panjang yang masuk akal, dan apa yang terjadi saat informasi tidak ada. Letakkan panduan di dokumentasi komponen dan alur kerja CMS, di mana editor dapat menggunakannya.
Jelaskan apa yang gagal, di mana itu terjadi, dan tindakan selanjutnya ketika aman dan berguna untuk melakukannya.
Batas adalah sinyal untuk mendesain ulang atau menulis ulang, bukan izin untuk menghilangkan makna esensial.
Kelola sistem sebelum tumbuh lebih cepat daripada kepercayaan
Tata kelola adalah proses ringan untuk kepemilikan, permintaan, tinjauan, rilis, dan pensiun. Tunjuk pemilik yang bertanggung jawab dan grup tinjau yang dapat menghadirkan keahlian desain, engineering, konten, dan aksesibilitas. Cocokkan bukti dengan blast radius. Pola lokal mungkin memerlukan pernyataan masalah dan pengujian halaman. Perubahan tombol atau token bersama harus menyertakan perjalanan yang terpengaruh, pemeriksaan aksesibilitas, perbandingan visual, catatan migrasi, dan instruksi rollback. GOV.UK meminta kontributor menunjukkan sebuah komponen berguna untuk banyak tim, bukan duplikat, dan diuji dengan pengguna perwakilan; gunakan itu sebagai model praktis daripada aturan universal.
Simpan masalah, opsi, keputusan, pemilik, versi yang terpengaruh, dan tanggal tinjau di tempat yang bisa dicari tim.
Labeli perubahan sebagai patch, additif, atau breaking agar konsumen tahu kapan migrasi dan periode kompatibilitas diperlukan.
Cegah regresi sebelum rilis
Hubungkan sistem ke pengiriman. Wajibkan perubahan untuk mengidentifikasi token dan komponen yang disentuh, lalu uji status yang terpengaruh dan halaman representatif. Perbandingan visual, pengujian interaksi, tinjauan konten, dan pemeriksaan aksesibilitas menemukan cacat yang berbeda. Prioritaskan perjalanan berdampak tinggi selain yang bertrafik tinggi; akses akun dan formulir kontak bisa penting meski trafiknya sederhana. Ini mendukung pekerjaan optimisasi uptime proaktif dan remediasi milik Status Is UP dengan mempersempit cakupan cacat dan membuat perbaikan yang disetujui lebih mudah diverifikasi. Ini bukan pemantauan downtime atau pengganti rencana insiden.
Simpan versi komponen, hasil pengujian, temuan, persetujuan, dan setiap risiko yang diterima bersama catatan rilis.
Pertahankan versi stabil sebelumnya dan uji langkah pemulihan dan verifikasi tertulis selama pemeliharaan berisiko rendah.