Design System: Menjaga Produk Tetap Konsisten Saat Terus Bertambah Besar

Design system dibutuhkan ketika produk Anda berhenti menjadi beberapa layar dan berubah menjadi sistem yang dipakai orang setiap hari. Sebelum titik itu, membangunnya lebih sering menambah pekerjaan daripada mengurangi.

Isinya berupa komponen yang benar-benar dipakai developer di dalam kode, aturan kapan komponen itu dipakai, dan catatan kenapa dibuat begitu.

Apa saja isi design system

Lapisan pertama adalah komponen: tombol, kolom isian, tabel, notifikasi, dan tampilan ketika data masih kosong. Semuanya ada dalam bentuk kode yang bisa dipanggil developer, bukan gambar di dalam file desain.

Di bawah komponen ada token, yaitu nilai dasar yang dipakai berulang: warna, jarak antar elemen, ukuran huruf, dan radius sudut. Token membuat satu perubahan kecil berlaku di seluruh produk. Kalau biru merek diperbaiki satu kali, semua layar ikut berubah, dan tidak ada lagi dua versi biru yang beredar bersamaan.

Lapisan ketiga adalah aturan pemakaian. Aturannya menjawab kapan tombol utama dipakai dan kapan tidak, bagaimana tanggal ditulis, di mana pesan error diletakkan, dan bagaimana tabel panjang ditampilkan di layar ponsel. Tanpa aturan, kumpulan komponen hanya menjadi laci berisi bagian-bagian yang masih bisa dirakit dengan cara yang berbeda-beda.

Lapisan terakhir yang paling sering hilang adalah catatan alasan. Catatannya menjelaskan kenapa form pengiriman dipisah dua langkah, atau kenapa konfirmasi hapus meminta ketikan ulang dan bukan centang. Orang yang datang setahun kemudian butuh alasan itu. Tanpanya, ia akan menyederhanakan sesuatu yang sebenarnya dibuat rumit dengan sengaja.

Syarat aksesibilitas juga paling murah ditegakkan di dalam komponen bersama. Kontras warna, ukuran area sentuh, dan label pada kolom isian cukup diperbaiki sekali di tombol, lalu berlaku di mana pun tombol itu dipakai. Alasan bisnisnya kami bahas di desain yang bisa diakses semua orang.

Dua hal sering dikira design system padahal bukan: file PDF berisi panduan warna dan logo, serta kumpulan komponen tanpa aturan dan tanpa catatan. File PDF tidak pernah dibuka developer. Kumpulan komponen tanpa aturan tetap melahirkan perdebatan setiap kali ada layar baru.

Tanda-tanda bisnis Anda membutuhkannya

Gejalanya muncul di pekerjaan sehari-hari, bukan di rapat strategi:

• Empat layar menampilkan tanggal dengan empat cara berbeda, dan admin harus berhenti sebentar untuk membedakan tanggal dari nomor.
• Menambah satu fitur kecil memakan sepekan diskusi desain, karena tidak ada keputusan lama yang bisa dijadikan acuan.
• Staf baru harus mempelajari setiap halaman satu per satu, sebab letak tombol simpan berpindah-pindah.
• Ada dua nuansa biru merek yang sama-sama berjalan di produksi, dan tidak ada yang tahu mana yang benar.

Keempatnya berasal dari satu sebab: setiap layar dibuat sebagai keputusan baru. Selama produk Anda tiga atau empat halaman, biayanya kecil. Begitu jumlah layar lewat belasan dan ada lebih dari satu orang yang menambahinya, biaya itu menumpuk di waktu developer sekaligus di waktu staf yang memakai sistemnya.

Sistem internal paling terasa manfaatnya, karena orang yang sama membuka layar yang sama puluhan kali sehari. Pembahasan lebih lengkap soal itu ada di UX untuk sistem internal yang rumit.

Kapan design system bukan belanja yang tepat

Kami akan menyarankan Anda menunda kalau produknya hanya satu alur, misalnya form pendaftaran dengan satu halaman konfirmasi. Sama juga kalau yang Anda bangun landing page, atau kalau produknya masih menguji apakah ada yang mau memakainya.

Dalam keadaan seperti itu, design system menambah pekerjaan di depan untuk konsistensi yang belum dirasakan siapa pun. Lebih buruk lagi, Anda mengunci keputusan desain sebelum tahu bentuk produk yang benar.

Jawaban yang tepat di skala kecil biasanya sudah tersedia: pakai component library yang sudah ada dan matang, lalu tambahkan satu halaman aturan pendek. Isinya warna merek, ukuran huruf, cara menulis tanggal dan rupiah, serta daftar komponen yang boleh dipakai. Satu halaman itu mengerjakan sebagian besar tugasnya, dan biayanya hampir nol.

Kalau library yang tersedia sudah menutupi kebutuhan Anda, kami akan menunjukkannya dan menyarankan Anda berhenti di situ. Pembahasan yang lebih luas soal kapan desain pantas dibayar ada di nilai bisnis dari desain UX.

Membangunnya dari layar yang sudah jadi

Design system yang dirancang di atas kertas sebelum produknya ada hampir selalu salah ukuran. Sebagian komponennya tidak pernah terpakai, sebagian kebutuhan nyata justru tidak tertampung.

Urutan yang lebih aman berangkat dari pekerjaan yang sudah berjalan. Bangun dulu layar-layar pertama sesuai kebutuhan nyata. Setelah beberapa pekan, lihat apa yang berulang: tabel dengan filter, kartu ringkasan, dialog konfirmasi. Yang berulang terus diangkat menjadi komponen bersama, dan alasan bentuknya dicatat saat itu juga, selagi masih segar.

Cara kerja ini cocok dengan pembangunan bertahap. Lingkup dan harga setiap tahap disepakati tertulis sebelum tahap itu dimulai. Anda bisa menyetujui satu tahap untuk mengangkat komponen yang sudah terbukti berulang, lalu berhenti kalau menurut Anda sudah cukup. Tidak ada komitmen ke seluruh sistem di awal, dan berhenti setelah tahap mana pun tidak perlu jadi perselisihan.

Desain yang diserahkan sebagai layar yang berjalan

Yang kami serahkan berupa layar yang berjalan, bukan PDF. Komponennya hadir sebagai kode yang langsung dipakai developer.

File desain tanpa pasangan kodenya akan melenceng dalam hitungan pekan. Developer menemukan kasus yang tidak ada di file, misalnya nama produk yang terlalu panjang atau tabel yang harus muat di layar ponsel kelas menengah. Ia memutuskan sendiri di kode, file desainnya tidak ikut diperbarui, dan sejak saat itu keduanya bercerita hal yang berbeda. Beberapa bulan kemudian tidak ada lagi yang percaya pada file itu.

Karena komponennya hidup di dalam kode, Anda bisa melihat sistemnya bekerja, bukan membaca penjelasannya. Ada demo yang berjalan setiap pekan dan link preview privat sejak pekan pertama. Anda buka tiga layar yang berbeda, lalu lihat sendiri apakah tombol, jarak, dan cara menulis tanggalnya sudah sama.

Siapa yang merawatnya setelah peluncuran

Komponen, repositori, dan seluruh akun sudah atas nama perusahaan Anda sejak hari pertama, bukan dialihkan di akhir. Serah terima hanya menegaskan apa yang sudah menjadi milik Anda sejak awal.

Alasan di balik setiap keputusan dicatat berdampingan dengan kodenya. Developer internal atau kontrak yang masuk belakangan perlu beberapa bekal untuk menambah komponen baru tanpa merusak yang lama. Ia perlu daftar komponen yang ada beserta cara memanggilnya, token sebagai sumber nilai warna dan jarak, dan catatan kenapa aturan tertentu dibuat. Dengan bekal itu ia mewarisi pemikiran di baliknya, bukan hanya folder berisi file.

Kalau tim Anda memang tidak mau repot mengurus pembaruan dan perbaikan kecil, ada layanan bulanan untuk menjalankannya. Sifatnya pilihan, bisa dihentikan kapan saja, dan akun tetap atas nama Anda.

Biayanya dan kapan kembali

Design system menambah biaya di awal. Mengangkat komponen, merapikan token, dan menulis aturannya tidak menghasilkan layar baru untuk pelanggan.

Pengembaliannya datang di layar keempat, kesepuluh, dan kedua puluh. Layar baru dirakit dari bagian yang sudah ada dan sudah diuji, bukan dirancang ulang. Semakin banyak layar yang akan dibangun, semakin cepat selisihnya tertutup.

Keputusannya bisa disandarkan pada dua angka yang sudah Anda ketahui. Pertama, berapa layar yang direncanakan dalam setahun ke depan. Kalau jawabannya di bawah sepuluh, library yang sudah ada ditambah satu halaman aturan biasanya cukup. Kedua, berapa orang yang akan menambahkan sesuatu ke produk itu tahun depan, termasuk developer kontrak dan siapa pun yang mengerjakan desain. Kalau jawabannya lebih dari satu orang, konsistensi perlu disepakati di satu tempat, dan sistem bersama mulai masuk akal.

Kalau kedua jawabannya kecil, tunda. Kalau keduanya besar, bangun dari layar yang sudah jadi, satu tahap pada satu waktu, dengan harga yang disepakati sebelum tahap itu dimulai.

Tunjukkan layar yang sudah Anda punya

Tidak ada ebook untuk diunduh di sini dan tidak ada deck. Buka saja produk Anda yang sekarang lewat satu panggilan gratis, lalu kami lihat bersama berapa banyak yang berulang dan berapa layar lagi yang Anda rencanakan.

Kalau jawaban jujurnya adalah library yang sudah ada ditambah satu halaman aturan, kami akan mengatakannya. Kalau design system memang sudah pantas dibayar, Discovery memberi Anda rencana tertulis beserta harga tetap. Keduanya tetap milik Anda, entah Anda melanjutkan bersama kami atau tidak.

Hubungi kami di WhatsApp +62 851-1769-7889 atau email hello@arktik.id.