Hitungan Balik Modal Design System untuk Produk yang Tumbuh

Design system layak dibayar kalau tim Anda sudah sering membangun ulang hal yang sama. Penghematannya datang dari keputusan yang tidak perlu diambil dua kali, bukan dari layar yang jadi lebih cantik.

Karena itu hasilnya hampir tidak terasa di rilis pertama. Yang terasa adalah fitur kelima, dan orang berikutnya yang merawat produk Anda. Kami membahas cara menjaga produk tetap konsisten selama ia tumbuh di panduan design system untuk produk yang berkembang.

Ke mana uang sebenarnya habis kalau tidak ada design system

Biayanya tidak pernah muncul sebagai satu baris di invoice. Ia tersebar di banyak pekerjaan kecil yang kelihatan wajar satu per satu.

• Tabel daftar pesanan dibangun tiga kali, di halaman admin, di halaman gudang, dan di laporan, masing-masing dengan bug sendiri.
• Form dengan validasi yang mirip tapi tidak sama, sehingga pesan error di satu halaman berbeda bunyinya dengan halaman lain.
• QA memeriksa layar yang seharusnya berperilaku identik, karena tidak ada jaminan bahwa ketiganya memang identik.
• Developer baru bertanya tombol mana yang benar untuk aksi hapus, lalu memilih sendiri dan menambah versi keempat.

Sistem internal paling cepat menumpuk duplikasi seperti ini. Layarnya banyak dan tidak ada orang luar yang melihatnya. Beberapa pola yang biasa muncul di situ kami bahas di UX untuk sistem internal yang rumit.

Yang menanggung tumpukan itu bukan orang yang membangunnya pertama kali. Biayanya jatuh ke siapa pun yang merawat produk setelah peluncuran, termasuk developer internal atau kontrak yang mewarisi kodenya.

Isi design system, dalam bagian yang bisa Anda tunjuk

Supaya tidak terdengar abstrak, bagilah jadi empat bagian yang bisa Anda lihat sendiri di layar.

Token adalah daftar nilai dasar: warna, ukuran huruf, jarak antar elemen, dan radius sudut. Satu daftar, dipakai semua halaman. Komponen adalah potongan yang dipakai berulang, seperti tombol, kolom input, tabel, dan notifikasi. Pola adalah cara komponen itu disusun untuk pekerjaan tertentu, misalnya bagaimana form panjang dipecah atau bagaimana halaman menampilkan keadaan kosong saat belum ada data.

Bagian keempat yang paling sering dilupakan: alasan tertulis di balik setiap aturan. Kenapa tombol hapus selalu memerlukan konfirmasi. Kenapa tabel pesanan tidak pakai paginasi. Tanpa catatan itu, tiga bagian pertama hanya kumpulan file.

Semuanya diserahkan sebagai layar yang berfungsi, bukan PDF yang harus ditafsirkan ulang oleh developer.

Hasilnya muncul di tiga tempat, dan tidak ada yang di rilis pertama

Yang pertama kecepatan fitur kelima. Fitur pertama justru lebih lambat, karena token dan komponennya baru dibuat sambil jalan. Fitur kelima memakai yang sudah ada, dan pertanyaan soal warna, jarak, serta bentuk tombol tidak dibuka lagi.

Yang kedua biaya mengubah sesuatu di semua tempat sekaligus. Anda memutuskan kolom harga harus menampilkan mata uang, atau tombol yang tidak aktif harus kelihatan jelas tidak aktif. Dengan satu sumber, perubahannya satu kali. Tanpa itu, seseorang harus mencari semua tempat yang terdampak, dan selalu ada satu yang terlewat sampai ada pelanggan yang menemukannya.

Yang ketiga biaya menyiapkan orang berikutnya. Developer atau desainer baru menemukan daftar komponen beserta alasannya. Ia bisa ikut mengerjakan fitur di minggu pertama, tanpa menebak-nebak sambil membuka halaman-halaman lama.

Ketiganya bagian dari argumen yang lebih besar soal nilai uang dari kualitas desain. Kerangkanya kami uraikan di nilai bisnis dari desain UX.

Kapan masih terlalu awal

Produk dengan empat layar dan satu developer tidak butuh library komponen. Yang ia butuhkan kesepakatan sederhana: dipakai warna apa, ukuran huruf apa, dan jangan membuat tombol jenis baru tanpa alasan. Membangun design system penuh di tahap itu berarti membayar struktur untuk masalah yang belum ada.

Kalau alat siap pakai sudah menyelesaikan pekerjaannya, termasuk di urusan seperti ini, kami akan bilang begitu dan mengarahkan Anda ke sana.

Ada beberapa tanda bahwa waktunya sudah datang. Muncul permukaan kedua, misalnya aplikasi mobile atau portal untuk pelanggan di samping admin internal. Masuk developer kedua, dan keputusan tampilan mulai berbeda antar orang. Atau ada rencana perubahan tampilan yang perkiraannya berminggu-minggu, karena tidak ada satu pun bagian yang dipakai bersama.

Kenapa alasan tertulis lebih penting daripada file komponennya

Komponen rusak pelan-pelan ketika tidak ada yang tahu kenapa aturannya ada. Misalnya, setahun kemudian seseorang melihat tombol dengan jarak yang terasa aneh, menganggapnya kesalahan, lalu memperbaikinya. Ternyata jarak itu dibuat lebar karena operator gudang memakainya sambil berdiri dengan satu tangan.

Kalau alasan seperti itu tidak tercatat, orang berikutnya punya dua pilihan dan keduanya buruk. Ia mengubah aturannya dan merusak sesuatu yang tidak ia lihat, atau ia membuat komponen sendiri di sebelahnya supaya tidak mengganggu yang lama. Pilihan kedua terjadi lebih sering, dan dari situlah tumpukan versi keempat dan kelima lahir.

Kami mencatat keputusan dan alasannya di sebelah kodenya. Orang yang mewarisi produk Anda ikut mewarisi pemikirannya, bukan hanya kumpulan file. Itu yang membuat design system bertahan melewati pergantian orang.

Membelinya bertahap, bukan sebagai proyek besar

Design system yang baik biasanya tidak dirancang dari nol di depan. Ia ditarik keluar dari layar yang sudah Anda miliki: lihat pola mana yang sudah terbukti dipakai berulang, baru jadikan itu komponen.

Karena itu pekerjaannya bisa dibeli bertahap. Discovery satu sampai dua minggu untuk memeriksa produk Anda sekarang, menghitung berapa banyak pola yang sebenarnya diulang, dan menulis rencananya. Keluarannya rencana tertulis dan harga tetap untuk tahap berikutnya, dan dokumen itu milik Anda apa pun keputusan Anda. Tahap sesudahnya disepakati harga dan ruang lingkupnya sebelum dimulai.

Jadi Anda bisa berhenti setelah tahap mana pun, termasuk setelah tahap pertama. Itu berguna di pekerjaan seperti ini, karena hasilnya menipis setelah pola yang paling sering dipakai selesai ditangani. Berhenti di titik itu keputusan yang tepat, dan bukan tanda proyek yang gagal.

Cara mengetahui apakah berhasil

Kami tidak menjanjikan angka penghematan, dan tidak ada angka yang bisa dipercaya sebelum Anda mengukurnya di produk sendiri. Tapi ada beberapa hal yang bisa Anda cek sendiri, sebelum dan sesudah.

• Berapa lama satu layar baru selesai, dari disepakati sampai bisa dibuka di link preview.
• Berapa komponen sekali pakai yang ditambahkan tiap bulan, dan apakah jumlahnya turun.
• Satu perubahan global, misalnya format harga, perlu berapa kali edit: satu, atau dua belas.
• Developer baru perlu berapa lama sampai ia mengerjakan fitur tanpa menanyakan pilihan tampilan.

Kalau keempatnya tidak bergerak setelah satu tahap, Anda berhenti dan tahu alasannya. Hubungan antara kualitas desain dan hasil bisnis kami bahas lebih jauh di desain UI UX dan pertumbuhan bisnis.

Ceritakan apa yang tim Anda bangun ulang tiap sprint

Tidak perlu menyiapkan istilah desain. Ceritakan saja produk Anda sekarang: ada berapa layar, berapa orang yang mengerjakannya, dan bagian mana yang selalu dibangun ulang setiap kali ada fitur baru. Kita lihat bersama apakah design system sudah layak dibayar, atau kesepakatan sederhana saja sudah cukup untuk sekarang. Obrolan pertamanya gratis, tanpa deck, langsung dengan engineer yang akan mengerjakannya.

Kalau jawabannya belum, kami akan bilang begitu. Kalau memang perlu dikerjakan, discovery memberi rencana tertulis dan harga tetap, dan dokumen itu milik Anda apa pun keputusan Anda setelahnya. Gunakan formulir kontak yang membuka WhatsApp, atau kirim email ke hello@arktik.id.