Design System, Dibalik Layar (Part 1)

Mulai pertengahan tahun 2017 ketika istilah Design System mulai awam terdengar, hampir semua berjibaku, berlomba untuk jadi yang terdepan, ditandai dengan munculnya banyak study-case “cerita tentang pembuatan design system” di perusahaan mereka.

Namun demikian, belum begitu banyak yang membahas polemik di belakang layarnya: bagaimana sistem politik, cara governing, distribusi — transisi & sosialisasi, maintenance, scaling, atau sekadar “Kenapa kita butuh design system” beserta perencanaannya.

Dari selusin cerita yang gw temukan di medium ttg proses pembuatan design system, khususnya di Indonesia, ya! setidaknya ada 5–8 Designer yang mempunyai pattern awalan cerita serupa :

• In {Insert : Year / Quarter / Satuan Waktu Lainnya} I got assigned to build {insert : Name of the Company}’s Design System….
• Back in {Insert : Year / Quarter / Satuan Waktu Lainnya} our company did not have proper guidelines…..
• As our team started to grow, with more designers working on different projects…..

Anyway, regardless of the reason, gw mengapresiasi, serta mengacungkan jempol kepada teman-teman designer yang sudah bisa ngelobby perusahaan tempatnya bekerja untuk memfasilitasi pengembangan design system. Apresiasi juga saya lontarkan setinggi-tingginya kepada para stakeholder dan management yang sudah berani memberikan ruang untuk inisiasi tersebut 👏.

Photo by Christopher Gower on Unsplash

Ok, back to the topic. Dari beberapa artikel yang sudah gw baca, bisa gw tarik asumsi serta simpulkan, bahwa : kebanyakan masih menjustifikasi manfaat dan fungsi dari Design System, instead of mencari solusi dari pokok permasalahan yang ada.

Contoh gampangnya gini deh: “Wah design kita ngak konsisten nih, jadinya asset kita duplicated ampe .apk memblendung, kita butuh Design System untuk nge-solve problem ini nih”

Disisi lain tim designya cuman ada beberapa (2–3) orang aja, kalopun sampek ngak konsisten, ya itu berarti elu yang …….{isi sendiri} Tong… . Pertanyaanya adalah : Apakah ini harus di solve dengan design system? atau sebenernya bisa dikomunikasikan internally?

Atau se-signifikan apa sih implikasi duplicated asset ke besaran size .apk ? sampek seolah-olah ke-tidak-beradaan Design System menjadi kambing hitam? Pertanyaanya adalah : Apakah ini cuman bisa di solve dengan design system? atau sebenernya bisa dikomunikasikan dgn cara lain sama tim Engineering?

Photo by Xavi Cabrera on Unsplash

Maksudnya adalah, Yes I Agree… Design System itu penting dan akan sangat berguna membantu day-to-day kerjaan kita sebagai designer untuk mencapai hasil yang efektif dan efisien di dalam konteks product development. Tapi perlu diingat juga, komitmen yang ada juga ngak bisa main-main, seperti dua sejoli yang akan menikah, pastilah mereka merencanakan kalau punya anak nanti pendidikanya seperti apa, gimana mencukupi kebutuhannya, dst.. begitu pula dengan si Design System, perlu perencanaan yang bukan kaleng-kaleng.

Percuma juga kan kalo ujung2nya si Design System nggak terurus dgn baik.. detach sana detach sini, akhirnya menjadi tumpukan design debt yang lebih gedhe daripada sebelum ada inisiasi Design System.

Ada beberapa hal yang mungkin bisa kita take in consideration terlebih dulu dan dibicarakan bersama dengan keseluruhan tim, misalnya :

• Bakal gimana bentuk ownership dari Design System yg dibuat?
• Perlu punya dedicated team apa engga? gimana ngejustifikasi ke stakeholder?
• Gimana transisi migrasi komponen Design System ke produk?
• Gimana memfasilitasi designer apabila butuh suatu komponen, namun belum terfasilitasi di library yang ada?
• Kalo ada komponen baru, Engineer di Tim mana yang bertanggung jawab ngecoding-nya?
• Gimana tracking buat versioningnya? supaya ketika kita ngomong KOMPONEN X kita merujuk ke satu sumber yang sama.
• Gimana nyusun Information Architecture-nya supaya semua tim produk bisa dengan jelas dapet visibility-nya?
• Gimana kalo ada komponen yang ngak works? cara ngereplace-nya bakal seperti apa?
• Gimana cara supaya designer & engineer yang lain bisa ikut merasakan benefitnya?
• Dan masih banyak hal lain terkait Design System diluar sekadar bikin komponen UI aja.

Kadang gw masih sering bertanya, yang mereka maksud dengan ‘Design System’ sebenernya itu beneran Design System? atau cuman UI Kit sih?

Hal-hal tersebut kalo dibahas dalam satu tulisan akan sangat panjang, orang bakal males juga bacanya… jadi semoga aja niatan gw untuk mencurahkan isi dalam otak gw sejalan dengan semangat buat menuliskanya.

Photo by Maria Teneva on Unsplash

Lalu gimana dong? kapan waktu yg tepat untuk memulai Design System?

Well.. biar kalian tambah bingung, gw jawab dengan sebuah cerita: Kalo diibaratkan dengan salah satu kebutuhan pokok manusia, Hirarki Maslow tau kan? salah satu kebutuhan dasar manusia adalah MAKAN & MINUM. Makan & Minum ini bisa dielaborasi secara definisi dengan perspective Fungsional & Solusional:

Ketika kita lapar, apa yang kamu lakukan? salah satunya adalah makan. Apakah yang kita makan perlu spesifikasi tertentu? Bisa ngak solusi dari lapar tadi makan dengan bahan-bahan seadanya di rumah yang kita proses sendiri? Atau.. Apakah kita harus merogoh kocek untuk makan di resto fensy disalah satu rooftop SCBD? Sudahkah kita memperhitungkan Hidden Cost-nya? Apakah kebutuhan dasar lainnya sudah terpenuhi? dsb.

Pertanyaan ini yang bisa menjawab adalah diri kita sendiri, salah satu konsiderasinya adalah melalui perspective mana yang kita pakai.

Pada dasarnya yang membedakan Fungsional & Solusional adalah : fungsi terlihat applicable di berbagai situasi. Namun bukan berarti jawaban untuk menyelesaikan masalah. Sementara solusi di khususkan untuk situasi tertentu, di mana dalam situasi tersebut membutuhkan penyelesaian khusus yang tidak dimiliki oleh opsi-opsi lainnya.

Design System itu (sebatas pengetahuan gw yaa…) adalah living organism yang butuh di nurture sampek mature. Sebagai orang tua kita harus assist doi biar bisa jalan, ngajarin cara berhitung sampek ngajarin juga tata cara ber-etika, klo kita cuman bikin anak aja trus nggak diopeni, ya bisa disebut kita adalah designer yang dzolim.

Tergantung dengan situasi tempat kita bekerja, kita ngak perlu memaksakan ikutan trend biar kekinian, bisa jadi kita cukup bikin pattern-pattern yang re-usable aja di Figma, selanjutnya bisa kita komunikasikan dengan sesama designer lainnya. Dan manpower yang ada bisa dialokasikan untuk ngesolve permasalahan-permasalahan yang lain.

Sebenernya ini cuman curahan hati, berdasarkan pengalaman ketika gw berkomitmen membantu sebuah organisasi untuk develop Design System mereka, banyak unsur politik didalamnya yang ternyata belum pernah dijelaskan oleh kebanyakan designer lainnya, semoga kalian yang gak sengaja baca ini, dan punya pengalaman atau cerita, komen-komen aja ya biar kita bisa diskusi bareng dan gw juga bisa mengambil ilmu dari pengalaman kalian, katanya sih Experience is the Best Teacher, tapi kalo Experience-nya ngak enak, gw prefer belajar dari Experience-nya orang lain aja deh, jadi bisa tetep dapet insight-nya, wkwk.

📚 I write kinds of stuff on My Blog