Sistem Desain Adalah Tentang Hubungan

Sistem desain bisa sangat membantu. Mereka menyediakan elemen dan pedoman yang dapat digunakan kembali untuk membangun "tampilan dan nuansa" yang konsisten di seluruh produk. Akibatnya, pengguna dapat mengambil apa yang mereka pelajari dari satu produk dan menerapkannya ke produk lain. Demikian pula, tim dapat meluncurkan pola yang telah teruji untuk navigasi atau ulasan, membuat produk lebih dapat dipercaya. Sistem desain yang efektif memecahkan masalah yang membosankan dengan cara yang berulang sehingga pengembang dan desainer dapat fokus pada pemecahan masalah baru.

Namun ketika seseorang menggunakan istilah "sistem desain" dalam sebuah rapat, saya tidak pernah yakin reaksi apa yang diharapkan. Saya telah melihat keingintahuan dan kegembiraan tentang mencoba cara kerja baru, tetapi saya juga melihat frustrasi dan kekhawatiran pada gagasan tentang sistem yang membatasi kreativitas desainer. Beberapa desainer berpendapat bahwa sistem desain melemahkan kreativitas, atau bahwa mereka adalah solusi dalam mencari masalah. Sistem desain dapat terfragmentasi dari waktu ke waktu, menyebabkan tim berhenti menggunakannya.

Sistem desain tidak akan hilang. Hanya 15% organisasi yang tidak memiliki sistem desain pada tahun 2018, menurut sebuah survei. Itu turun dari 28% tahun sebelumnya. Beberapa tim menggunakan sistem desain tujuan umum yang besar seperti Desain Material Google, sementara yang lain menggunakan sistem yang lebih kecil dan lebih dipesan lebih dahulu seperti REI's Cedar dan Mozilla's Protocol.

Sistem desain harus memberdayakan tim, bukan membatasi mereka. Agar itu terjadi, kita perlu mulai berpikir lebih holistik. Sebuah sistem desain bukan hanya kode, atau desain, atau dokumentasi. Ini semua hal ini, ditambah hubungan antara orang-orang yang membuat sistem dan orang-orang yang menggunakannya. Ini tidak hanya mencakup file CSS dan dokumen Sketsa, tetapi juga kepercayaan, komunikasi, dan kepemilikan bersama. Ternyata, ada seluruh bidang studi yang didedikasikan untuk menjelajahi sistem seperti ini.

Gambar besar

Sebuah makalah tahun 1960 berjudul "Sistem sosial-teknis" mengeksplorasi interaksi antara teknologi, manusia, dan lingkungan yang lebih besar di mana mereka berada. Enid Mumford menjelaskan bahwa para peneliti mulai dengan menyelidiki bagaimana membangun hubungan yang lebih baik antara manajer dan karyawan, tetapi pada tahun 1980-an, mereka berfokus untuk membuat pekerjaan lebih efisien dan hemat biaya. Pada tahun 2011, Gordon Baxter dan Ian Sommerville menulis bahwa penelitian ini membantu menginspirasi desain yang berpusat pada pengguna, dan masih banyak pekerjaan yang harus dilakukan.

Baxter dan Sommerville berpendapat bahwa saat ini, masih ada ketegangan antara penelitian "humanistik", yang berfokus pada kualitas hidup karyawan, dan penelitian "manajerial", yang berfokus pada produktivitas mereka. Mereka juga menjelaskan bahwa penting untuk mempertimbangkan teknologi dan interaksi manusia: “kinerja sistem bergantung pada optimalisasi bersama dari subsistem teknis dan sosial.”

Saya berpendapat bahwa sistem desain adalah sistem sosio-teknis. Mereka melibatkan interaksi antara orang-orang yang membuat sistem, orang-orang yang membuat produk menggunakan sistem, dan pengguna akhir yang berinteraksi dengan produk ini. Mereka juga membangkitkan ketegangan yang sama antara efisiensi dan humanisme yang dilihat Baxter dan Sommerville.

Sistem desain tidak hanya terdiri dari gambar dan kode; mereka melibatkan percakapan antara desainer, pengembang, manajer produk, CEO, dan orang-orang acak di GitHub. Interaksi ini terjadi dalam berbagai konteks — perusahaan, komunitas open-source, rumah — dan itu terjadi lintas budaya dan batas organisasi. Membangun tim dapat berarti menyatukan orang-orang dari berbagai disiplin ilmu seperti animasi, desain suara, visualisasi data, haptics, dan copywriting. Menciptakan sistem desain yang sukses membutuhkan keahlian teknis dan soft skill yang setara.

Namun, teliti agregator berita desain atau rekayasa dan Anda cenderung melihat fokus yang berbeda pada "subsistem teknis" itu — kode dan alat, daripada orang dan percakapan. Alat kreatif mana yang terbaik dalam melacak token desain? Teknologi JavaScript apa yang harus digunakan untuk membangun komponen yang dapat digunakan kembali — Bereaksi, komponen web, atau yang lainnya? Alat pembuatan mana yang terbaik?

Jawaban atas pertanyaan-pertanyaan ini, tentu saja, “tergantung!” Siapa yang akan merancang, membangun, dan menggunakan sistem? Apa kebutuhan mereka? Kendala apa yang mereka operasikan? Alat dan teknologi apa yang membuat mereka nyaman? Apa yang ingin mereka pelajari?

Untuk menjawab pertanyaan semacam ini, Baxter dan Sommerville merekomendasikan dua jenis kegiatan:

• Kegiatan sensitisasi dan penyadaran
  Belajar tentang beragam orang yang akan membuat dan berpartisipasi dalam sistem, dan berbagi informasi itu jauh dan luas.
• Keterlibatan konstruktif
  Berkomunikasi lintas peran, membangun prototipe, dan mempertimbangkan bagian teknis dan sosial dari sistem.

Menggali

Pada awal 2019, saya adalah bagian dari sebuah tim — sebut saja mereka “tim biru” — yang sedang membangun sistem desain untuk sebuah organisasi besar. Saya memfasilitasi obrolan informal dengan tim ini dan "tim hijau", yang menggunakan sistem desain untuk membangun aplikasi web. Setiap beberapa minggu, kami mengumpulkan semua pengembang dan desainer di satu meja dan berbicara tentang apa yang sedang kami bangun dan masalah apa yang coba kami pecahkan. Obrolan ini adalah “aktivitas kepekaan dan kesadaran” kami.

Kami tidak memiliki izin untuk membuat sistem desain kami menjadi publik, jadi kami melakukan hal terbaik berikutnya: kami memperlakukannya seperti proyek sumber terbuka kecil di dalam organisasi. Kami menempatkan kode dalam repositori yang dapat diakses oleh kedua tim dan meminta kontribusi. Tim biru bertanggung jawab untuk meninjau dan menyetujui kontribusi ini, tetapi siapa pun di salah satu tim dapat berkontribusi. Tim biru juga sedang membangun aplikasi mereka sendiri, jadi dalam arti tertentu, mereka adalah pengguna dan pemelihara sistem desain.

Interaksi ini membantu tim membangun produk yang lebih baik, tetapi sama pentingnya, mereka membangun kepercayaan di antara tim. Tim biru mengetahui bahwa orang-orang menggunakan sistem dengan cermat dan membangun ide-ide baru yang cerdas di atasnya. Tim hijau mengetahui bahwa sistem tersebut benar-benar disesuaikan dengan kebutuhan mereka, sehingga mereka dapat bekerja dengannya alih-alih menentangnya. Baxter dan Sommerville mungkin menyebut pekerjaan ini "keterlibatan konstruktif."

Kami menemukan bahwa kedua tim berada di bawah tekanan untuk mempelajari teknologi baru dan memberikan produk yang lengkap dengan cepat. Dengan kata lain, mereka sudah beroperasi di bawah beban kognitif yang cukup besar. Akibatnya, kedua tim sepakat untuk fokus pada pembuatan sistem yang mudah digunakan. Itu berarti menghindari perdebatan seluruh komponen web, sebagian besar berfokus pada CSS, dan memastikan bahwa dokumentasi kami jelas dan ramah.

Menyatukan Semuanya

Organisasi dari semua ukuran membuat elemen desain yang dapat digunakan kembali untuk membantu tim membangun aplikasi yang lebih konsisten dan elegan. Kebutuhan dan dinamika organisasi yang berbeda diekspresikan dalam sistem desain mereka. Berikut adalah beberapa contoh:

• Desain Material Google memiliki beberapa implementasi dalam kerangka kerja dan bahasa yang berbeda. Ini digunakan oleh berbagai orang di dalam dan di luar Google, sehingga memiliki dokumentasi yang komprehensif dan berbagai toolkit untuk aplikasi desain.
• Sistem Desain Lancar Microsoft menargetkan empat platform yang sangat berbeda. Seperti Material, itu termasuk toolkit untuk desainer UX dan dokumentasi yang komprehensif.
• Protokol Mozilla diimplementasikan dalam Sass dan vanilla JavaScript. Ini memiliki fokus yang kuat pada internasionalisasi. Alex Gibson mengatakan bahwa sistem ini membantu Mozilla "membuat halaman web bermerek lebih cepat dengan pekerjaan manual yang tidak terlalu berulang".
• Cedar REI dibuat dengan komponen Vue.js dan tidak dapat digunakan dengan kerangka kerja JavaScript lainnya. Cedar digunakan terutama oleh pengembang internal REI dan terkait erat dengan merek perusahaan. Kode sistem desain adalah open source, tetapi font-nya tidak.
• Sistem Desain Petir Salesforce adalah kerangka kerja CSS JavaScript-agnostik. Ini secara opsional dapat digunakan bersama dengan Lightning Component Framework, yang mencakup dua implementasi JavaScript: satu menggunakan komponen web dan lainnya menggunakan kerangka Aura milik Salesforce.
• PatternFly Red Hat diciptakan untuk memberikan pengalaman pengguna yang konsisten di seluruh produk platform cloud perusahaan, sehingga memiliki kepadatan informasi yang relatif tinggi dan mencakup berbagai komponen visualisasi data. Tim PatternFly baru-baru ini beralih dari Angular ke React setelah beberapa eksperimen dengan komponen web. PatternFly juga menyertakan implementasi JavaScript-agnostik menggunakan HTML dan CSS. (Pengungkapan penuh: Saya mantan Red Hatter.)
• Sistem Desain Karbon IBM menawarkan implementasi dalam React, Vue, Angular, dan vanilla JavaScript serta perangkat desain untuk Sketch. Tim Carbon sedang bereksperimen dengan komponen web. (Hat tip untuk Jonathan Speek untuk melacak repositori itu.)

Sistem seperti ini konsisten dan andal karena orang-orang dari tim dan peran yang berbeda bekerja sama untuk membangunnya. Sistem ini memecahkan masalah nyata. Mereka bukan hasil dari pengembang yang mencoba memaksakan kehendak mereka pada desainer atau sebaliknya.

Josh Mateo dan Brendon Manwaring menjelaskan bahwa desainer Spotify “melihat peran mereka sebagai kontributor inti dan penulis bersama dari sistem bersama — yang mereka miliki.” Mina Markham menggambarkan dirinya sebagai “penerjemah antara teknik dan desain” pada sistem desain Pantsuit. Jina Anne menggali dinamika tim dan penelitian pengguna di balik sistem desain: “Spoiler alert! Anda akan membutuhkan lebih dari sekadar desainer.”

Mari Membangun Beberapa Barang!

Sekarang kita telah melalui penelitian dan beberapa contoh, mari kita bicara tentang bagaimana membangun sistem desain baru. Mulailah dengan berbicara dengan orang-orang. Cari tahu siapa yang akan menggunakan dan berkontribusi pada sistem desain Anda. Orang-orang ini mungkin akan menjangkau berbagai disiplin ilmu — desain, pengembangan, manajemen produk, bisnis, dan sejenisnya. Pelajari tentang kebutuhan dan tujuan orang, dan minta mereka untuk membagikan apa yang sedang mereka kerjakan. Pertimbangkan untuk merencanakan pertemuan informal dengan makanan ringan, kopi, atau teh untuk menciptakan suasana yang ramah. Jalin komunikasi teratur dengan orang-orang ini. Itu mungkin berarti bergabung dengan ruang obrolan bersama atau menjadwalkan pertemuan rutin. Jaga agar nada tetap santai dan ramah, dan fokuslah untuk mendengarkan.

Saat Anda berbicara tentang apa yang sedang Anda kerjakan, cari masalah dan tujuan umum. Anda mungkin menemukan bahwa tim perlu menampilkan data dalam jumlah besar, jadi mereka sedang menyelidiki alat untuk menampilkan tabel dan membuat laporan. Prioritaskan solusi untuk masalah ini.

Cari juga pola dan variasi berulang pada tema serupa. Anda mungkin menemukan bahwa tombol dan formulir masuk terlihat sedikit berbeda di seluruh tim. Apa pentingnya variasi ini? Variasi apa yang disengaja — misalnya, tombol utama versus tombol sekunder — dan variasi apa yang terjadi secara tidak sengaja? Sistem desain Anda dapat memberi nama dan membuat katalog pola dan variasi yang disengaja, dan dapat menghilangkan variasi "tidak disengaja".

Tujuannya di sini adalah untuk membangun umpan balik yang cepat dengan orang-orang yang menggunakan sistem desain. Umpan balik yang lebih cepat dan iterasi yang lebih kecil dapat membantu menghindari terlalu jauh ke arah yang salah dan harus mengubah arah secara dramatis. PJ Onori menyebut perubahan besar yang tiba-tiba ini sebagai "thrash." Dia mengatakan bahwa beberapa thrash itu bagus — itu pertanda bahwa Anda sedang belajar dan merespons perubahan — tetapi terlalu banyak bisa mengganggu. “Anda tidak perlu takut dengan thrash,” katanya, “tetapi Anda perlu tahu kapan itu berguna dan bagaimana membantu mengurangi kerugiannya. Salah satu [cara] terbaik untuk mengurangi kerugian dari thrash adalah memulai dari yang kecil — dengan segalanya .”

Pertimbangkan untuk memulai dari yang kecil dengan menyiapkan beberapa elemen dasar:

• Sistem kontrol versi untuk menyimpan kode Anda. GitHub, GitLab, dan Bitbucket adalah opsi yang bagus di sini. Pastikan bahwa setiap orang yang menggunakan sistem dapat mengakses kode dan mengusulkan perubahan. Jika memungkinkan, pertimbangkan untuk membuat kode open source untuk menjangkau audiens seluas mungkin.
• Kode CSS untuk mengimplementasikan sistem. Gunakan variabel Sass atau properti kustom CSS untuk menyimpan "token desain" — nilai umum seperti lebar dan warna.
• File package.json yang mendefinisikan bagaimana aplikasi dapat membangun dan menginstal sistem desain.
• Dokumentasi HTML yang mendemonstrasikan cara menggunakan sistem desain, idealnya menggunakan CSS sistem itu sendiri.

Dokumentasi node-sass untuk kerangka CSS Bulma menjelaskan langkah-langkah ini dengan sedikit lebih detail. Anda dapat melewatkan menginstal dan mengimpor Bulma jika Anda ingin memulai dari awal, atau Anda dapat memasukkannya jika Anda ingin memulai dengan beberapa dasar yang ada.

Anda mungkin telah memperhatikan bahwa saya tidak menyebutkan apa pun tentang JavaScript di sini. Anda mungkin ingin menambahkan elemen ini pada akhirnya, tetapi Anda tidak memerlukannya untuk memulai. Sangat mudah untuk pergi ke lubang kelinci meneliti alat JavaScript terbaik dan terbaru, dan tersesat dalam penelitian ini dapat membuat lebih sulit untuk memulai. Misalnya, "5 Alasan Komponen Web Sempurna Untuk Sistem Desain" dan "Mengapa Saya Tidak Menggunakan Komponen Web" keduanya membuat poin yang valid, tetapi hanya Anda yang dapat memutuskan alat apa yang tepat untuk sistem Anda. Dimulai dengan hanya CSS dan HTML memungkinkan Anda mengumpulkan umpan balik dunia nyata yang akan membantu Anda membuat keputusan ini ketika saatnya tiba.

Saat Anda merilis versi baru sistem, perbarui nomor versi sistem Anda untuk menunjukkan apa yang telah berubah. Gunakan versi semantik untuk menunjukkan apa yang berubah dengan angka seperti "1.4.0." Tambahkan angka terakhir untuk perbaikan bug, angka tengah untuk fitur baru, dan angka pertama untuk perubahan besar yang mengganggu. Tetap berkomunikasi dengan orang-orang yang menggunakan sistem desain, undang umpan balik dan kontribusi, dan buat peningkatan kecil saat Anda melakukannya. Cara kerja kolaboratif dan berulang ini dapat membantu meminimalkan "kemelut" dan membangun rasa kepemilikan bersama.

Terakhir, pertimbangkan untuk memublikasikan sistem desain Anda sebagai paket di npm sehingga pengembang dapat menggunakannya dengan menjalankan perintah npm install your-design-system . Secara default, paket npm bersifat publik, tetapi Anda juga dapat memublikasikan paket pribadi, memublikasikan paket ke registri pribadi, atau meminta pengembang untuk menginstal paket langsung dari sistem kontrol versi. Menggunakan repositori paket akan memudahkan untuk menemukan dan menginstal pembaruan, tetapi menginstal langsung dari kontrol versi dapat menjadi solusi jangka pendek yang mudah untuk membantu tim memulai.

Jika Anda tertarik untuk mempelajari lebih lanjut tentang sisi teknik, Katie Sylor-Miller's Building Your Design System memberikan penjelasan mendalam yang fantastis. (Pengungkapan penuh: Saya telah bekerja dengan Katie.)

Membungkus

Sistem desain terdiri dari kode, desain, dan dokumentasi serta hubungan, komunikasi, dan saling percaya. Dengan kata lain, mereka adalah sistem sosio-teknis. Untuk membangun sistem desain, jangan mulai dengan menulis kode dan memilih alat; mulai dengan berbicara dengan orang-orang yang akan menggunakan sistem. Pelajari tentang kebutuhan dan kendala mereka, dan bantu mereka memecahkan masalah. Saat membuat keputusan teknis, desain, atau strategi, pertimbangkan kebutuhan orang-orang ini daripada cara "terbaik" secara teoritis untuk melakukan sesuatu. Mulai dari yang kecil, ulangi, dan komunikasikan sambil jalan. Buat sistem Anda sesederhana mungkin untuk meminimalkan thrash, dan mengundang umpan balik dan kontribusi untuk membangun rasa kepemilikan bersama.

Dengan memberikan bobot yang sama pada pertimbangan teknik dan interpersonal, kita bisa mendapatkan manfaat dari sistem desain sambil menghindari jebakan. Kami dapat bekerja dengan cara yang efisien dan manusiawi; kita tidak harus memilih salah satu dari yang lain. Kami dapat memberdayakan tim daripada membatasi mereka. Tim yang diberdayakan pada akhirnya membantu kami melayani pengguna dengan lebih baik — yang, bagaimanapun, adalah alasan kami ada di sini.

Bacaan Lebih Lanjut tentang SmashingMag:

• Tips Untuk Mengelola Sistem Desain
• Menyertakan Animasi Dalam Sistem Desain Anda
• Beyond Tools: Bagaimana Membangun Sistem Desain Dapat Meningkatkan Cara Anda Bekerja
• Membangun Sistem Desain Skala Besar Untuk Pemerintah AS (Studi Kasus)