Untuk waktu yang singkat saya bekerja pada sistem desain di WebNL , sebuah agen khusus dalam desain web, pengembangan dan pemasaran yang berbasis di Belanda. Sistem desain kami bertujuan untuk meningkatkan jembatan antara desain dan pengembangan produk yang kami buat.

Di blog ini saya akan menjelaskan bagaimana kami melakukan ini, dan mengapa akhirnya tidak berhasil. Semoga ini akan mencegah orang lain melakukan kesalahan yang sama yang kami buat, meskipun kami telah belajar banyak dari mereka.

Awal perjalanan

Ketika saya mulai bekerja di WebNL, salah satu tugas pertama saya adalah untuk melihat kemungkinan meningkatkan transisi antara desain dan pengembangan produk web. Secara tradisional ini telah menjadi proses pengembang ‘menyalin’ tiruan yang dibuat oleh desainer.

Para desainer melakukan pekerjaan mereka terutama di Sketch. Mereka menerjemahkan visi mereka tentang produk ke dalam desain statis. Pengembang kemudian menulis HTML, CSS, Javascript dan PHP untuk mengubah desain statis ini menjadi produk yang berfungsi.

Salah satu ambisi terbesar di dalam perusahaan adalah menemukan cara untuk membuat proses ini lebih sedikit memakan waktu karena pekerjaan pada dasarnya dilakukan dua kali.

Jadi langkah pertama yang saya ambil adalah mencari tahu lebih banyak tentang cara-cara di mana proses ‘penyalinan’ ini dapat dilakukan secara otomatis. Saya melihat otomatisasi di Sketch dan menemukan ada plugin yang menggunakan Sketch API untuk tujuan ini. Tetapi plugin yang saya temukan kurang memiliki keandalan dan saya tidak begitu tertarik untuk menulis plugin Sketch saya sendiri.

Saya melihat lebih jauh dan menemukan bahwa Sketch baru-baru ini membuka format sistem file mereka sehingga file mereka dapat digunakan dalam alat lain. Setiap properti dari setiap grup dan lapisan dalam desain sekarang mudah diakses di luar Sketch dan saya segera menyadari bahwa saya dapat menggunakan ini untuk menerjemahkan properti ini menjadi produk yang berfungsi secara otomatis.

Membangun prototipe pertama

Setelah penemuan saya, saya segera membuat bukti konsep. Itu adalah prototipe yang sangat sederhana yang dapat mengubah file Sketsa menjadi situs web yang berfungsi. File Sketsa pada dasarnya adalah file zip yang terdiri dari gambar dan file json. Prototipe menerjemahkan file json ini ke dalam array Javascript sehingga dapat membaca semua properti yang disimpan di dalam file Sketch dan menggunakannya untuk menghasilkan situs web standar.

Pengembang kami menggunakan file terpusat tempat variabel SCSS disimpan. Variabel-variabel ini mengendalikan aspek visual elemen seperti warna, tipografi, tombol, dan elemen bentuk. Saya mengambil elemen-elemen itu dan membangunnya menjadi perpustakaan simbol Sketsa yang dapat diedit oleh desainer. Desainer kemudian dapat menggunakan elemen-elemen ini sebagai titik awal untuk proyek baru.

Ketika tampilan visual dari simbol-simbol ini telah diubah, saya dapat mengambil file Sketch dan menggunakannya untuk membuat file baru dengan variabel. Desainer sekarang dapat mengontrol elemen-elemen ini dalam produk akhir.

/**********************
Colors
**********************/$brand-primary: rgb(229,0,68);
$brand-secondary: rgb(172,171,171);
$brand-tertiary: rgb(0,0,0);
$brand-lightest: rgb(248,249,250);
$brand-darkest: rgb(52,58,63);$brand-success: rgb(85,184,144);
$brand-error: rgb(229,0,68);
$brand-warning: rgb(255,190,61);
$brand-info: rgb(23,162,184);
$text-color: black;

Ada juga beberapa kekurangannya. Kami hanya bisa menerjemahkan properti desain ke dalam kode jika sudah distandarisasi. Desainer dapat mengubah properti seperti warna, properti font, batas dan bayangan, yang kemudian diterjemahkan ke dalam kode kerja. Tetapi layer dan simbol yang mereka tambahkan tidak akan diterjemahkan.

Sepertinya itu bukan masalah. Ketika desainer akan datang dengan properti atau elemen baru, pengembang hanya bisa menulis kode baru untuk memperluas kode yang ada. Saya juga mulai membuat elemen yang lebih rumit seperti kartu dan menu dengan cara standar untuk memastikan desainer tidak harus membuat properti atau elemen baru sebanyak sebelumnya.

Pendekatan modular untuk simbol dalam sistem desain kami

Prototipe pertama saya membuat semua orang di perusahaan bersemangat. Cara kerja standar memiliki potensi untuk mempercepat alur kerja para desainer dan pengembang. Sementara desainer dapat menggunakan elemen standar sebagai template untuk membuat jumpstart, pengembang akan menghabiskan lebih sedikit waktu untuk memperbaiki hal-hal.

Kami mendapat izin untuk menghabiskan 100 jam sebagai investasi untuk proyek masa depan. Saya menggunakan jam-jam ini untuk membuat lebih banyak elemen, dan menerjemahkannya ke dalam kode. Pengembang frontend bekerja bersama saya untuk membangun elemen yang sama seperti HTML dengan properti SCSS.

Ketika kami selesai, kami mulai menggunakan sistem desain dalam produksi. Hasilnya masih moderat pada fase awal, tetapi menunjukkan banyak potensi.

Menyadari kami sedang membangun sistem desain

Ironisnya, ketika kami mulai bekerja pada sistem kami tidak tahu apa itu sistem desain. Kami belum pernah mendengarnya sampai bos kami memperkenalkan sistem desain istilah sebagai hal yang sudah ada, dan sebagai cara untuk memberi proyek nama yang nyata.

Kami menamai proyek kami Sistem Desain WebNL, dan saya mulai melihat ke perusahaan lain yang menggunakan sistem desain.

Selama ini saya membaca tentang Brad Frost , pelopor dalam sistem desain. Dia berbicara banyak tentang mereka, dan dia bahkan menulis buku tentang itu. Dari bukunya saya belajar tentang sistem desain atom, sebuah konsep yang saya terapkan dalam sistem desain kami.

Atom, molekul, organisme, templat, dan halaman

Saya juga membaca tentang bagaimana Airbnb mengotomatiskan proses desain. Mereka menggunakan pengenalan gambar yang cerdas untuk menganalisis sketsa yang dibuat di atas kertas dan menerjemahkannya menjadi prototipe yang bekerja segera. Saya menunjukkan video pekerjaan mereka di dalam perusahaan saya sendiri dan itu menyebabkan orang menjadi lebih bersemangat tentang potensi sistem desain.

Contoh lain dari Airbnb adalah reaksi terhadap sketsa . Airbnb menggunakannya untuk menghasilkan simbol Sketsa dari komponen Bereaksi yang ada. Mereka dapat menggunakan komponen reaksi sebagai satu sumber kebenaran seperti ini. Bagi kami itu tidak berhasil karena kami memulai banyak proyek baru di mana desain Sketsa adalah sumber kebenaran. Jadi alih-alih, kami mencoba membuat komponen kode dari simbol Sketsa yang ada.

Perbedaan ini juga memperlihatkan kesulitan lain yang kami hadapi dibandingkan dengan perusahaan lain. Mereka biasanya memiliki satu merek, menyediakan satu layanan melalui beberapa produk digital. Tetapi kami membuat produk untuk berbagai merek yang menyediakan lebih banyak layanan. Jadi sistem desain kami harus lebih fleksibel.

Vox Media memiliki contoh luar biasa dari sistem desain fleksibel yang dapat digunakan di berbagai merek. Bagi saya, ini membuktikan kelayakan sistem desain seperti itu, bahkan ketika itu masih akan membuat hal-hal sulit ketika mencoba untuk mengotomatisasi alur kerja antara desain dan pengembangan.

Memperbaiki bug dalam produksi

Setelah hype pertama tentang sistem desain kami, semuanya mulai menuju ke selatan. Kami menggunakan sistem secara luas, tetapi tidak pernah tanpa masalah.

Kami memutuskan untuk menggunakan sistem ini dalam sprint pendek di mana produk dibuat dalam satu minggu karena di situlah kami paling membutuhkannya. Tetapi pada beberapa kesempatan, terutama di awal, kami harus menyelesaikan masalah selama sprint.

Alih-alih menghabiskan waktu untuk produksi, kami harus men-debug sistem dan menghasilkan perbaikan bug. Terkadang para perancang baru saja merusak barang saat mengedit file Sketch. Selama uji coba pertama itu, saya berupaya mendapatkan perbaikan ke dalam sistem dan membuat hal-hal lebih bertahan lama sehingga desainer tidak dapat secara tidak sengaja memecahkan barang-barang.

Dan itu berhasil, sistem menjadi lebih baik dan lebih dapat diandalkan. Tetapi sistem masih belum memenuhi harapan.

Mengelola harapan

Sebelumnya kami tidak berharap bahwa memiliki sistem desain yang dapat mengotomatisasi berbagai hal akan membuat kami menghabiskan lebih sedikit waktu untuk proyek. Waktu yang kami hemat dapat dihabiskan sebagai waktu ekstra untuk proyek-proyek kami, kami beralasan. Tetapi setelah beberapa saat, seorang manajer produk masih menyebutkan bahwa kami tidak menghabiskan waktu lebih sedikit.

Jadi tidak semua orang mengharapkan hal yang sama dari sistem desain kami. Tapi semuanya juga tidak persis seperti yang kami harapkan. Ini karena masih ada banyak bug, tidak terkait dengan sistem desain tetapi terkait dengan proyek. Jadi, waktu yang tersisa di akhir proyek akan dihabiskan untuk menyelesaikan bug alih-alih fitur yang bagus.

Di satu sisi, ini bukan apa yang orang harapkan terjadi. Tapi saya tidak melihat ini sebagai masalah. Kami hanya harus membuat sistem lebih efisien sehingga lebih banyak waktu dapat dibebaskan, dan lebih sedikit bug yang dihasilkan.

Menangani kesalahan

Namun ini bukan karena masalah kami berakhir. Meskipun sistem telah menjadi lebih dapat diandalkan, para desainer masih membuat kesalahan saat membangun file Sketsa mereka. Kesalahan ini tidak menghasilkan kerusakan sistem lagi, karena saya telah menyiapkan pesan kesalahan yang dapat dianalisis oleh pengembang.

Ide saya adalah bahwa pesan-pesan ini akan menyebabkan pengembang dan desainer untuk berbicara lebih banyak tentang masalah bersama sehingga mereka akan saling memahami dengan lebih baik. Tetapi sementara mereka memang berbicara lebih banyak satu sama lain, itu tidak membantu mereka saling memahami. Para desainer masih belum memahami sistem desain.

Akhirnya, saya bahkan mendengar beberapa pengembang yang tidak langsung bekerja dengan sistem desain berbicara tentang bagaimana itu tidak berfungsi karena desainer tidak menggunakannya dengan benar. Saya menyadari bahwa saya harus menghabiskan lebih banyak waktu untuk menjelaskan sistem kepada para desainer dan berkolaborasi bersama mereka.

Mengajar desainer tentang sistem desain

Saya sudah menghabiskan banyak waktu dengan pengembang. Tetapi saya tidak menghabiskan banyak waktu untuk menjelaskan sistem desain kepada para desainer, dengan asumsi mereka secara intuitif akan tahu bagaimana menggunakannya. Ini kesalahan.

Setelah realisasi itu, saya menghabiskan banyak waktu mengajar desainer kami bagaimana menggunakan sistem desain. Saya menemukan bahwa mereka memiliki beberapa pemahaman tentang komponen, tetapi mereka tidak terbiasa bekerja dengan komponen bersarang, konvensi penamaan, dan bekerja dengan layer dan gaya teks.

Ini menyebabkan mereka mengabaikan beberapa prinsip Sketsa inti yang diandalkan sistem desain. Namun lebih dari itu, mereka juga tidak terbiasa bekerja dengan templat desain.

Sebelum sistem desain dibuat, mereka selalu memulai dengan halaman kosong, menggunakan ideasi untuk membuat desain baru dan inovatif. Mereka ingin setiap desain menjadi unik dan tidak ada bandingannya dengan yang lain. Meskipun sistem desain telah dibangun di atas pola yang digunakan dalam pekerjaan mereka sebelumnya, mereka ingin menyimpang dari pekerjaan itu.

Ini menyebabkan sakit kepala dengan pengembang karena mereka sekarang harus melakukan lebih banyak pekerjaan daripada mengurangi, sesuai dengan keinginan desainer.

Akhir dari Sistem Desain kami

Kami akhirnya mencapai titik di mana desainer cukup memahami tentang prinsip-prinsip Sketsa dan sistem desain sehingga mereka dapat menggunakannya tanpa banyak kesulitan.

Tetapi pada saat kami mencapai titik ini, keputusan tak terduga dibuat untuk merombak basis kode standar kami. Tidak akan ada file sentral dengan variabel SCSS lagi, membuatnya lebih sulit untuk menghasilkan variabel SCSS dari file Sketsa kami. Semua komponen kode yang ada juga rusak, mereka semua harus dibangun kembali sebelum kita bisa mengotomatiskannya lagi.

Pada saat yang sama, perusahaan lain meluncurkan Design Systems Manager (DSM). Ini adalah produk yang telah tersedia dalam versi beta beberapa saat setelah kami membuat prototipe pertama. Sistem mereka menawarkan API untuk menerjemahkan desain ke dalam variabel SCSS seperti yang kami lakukan sebelumnya. Sekarang sudah keluar dari beta dan dapat digunakan dalam produksi.

Bahkan lebih baik, ia menawarkan plugin Sketch untuk desainer yang membuatnya lebih mudah bagi mereka untuk bekerja dengan komponen dan gaya yang digunakan dalam sistem desain kami. Kami juga memutuskan bahwa akan lebih baik untuk beralih ke API mereka untuk penggunaan di masa mendatang, karena kami telah menemukan bahwa Sketch terus memperbarui format file mereka, membuatnya memakan waktu untuk mempertahankan menghasilkan variabel SCSS sendiri.

Peristiwa ini akhirnya membuat kami memutuskan untuk menarik steker pada sistem desain. Kami harus membangun kembali sistem desain dengan cara baru untuk membuatnya otomatis lagi, dan kami tidak punya waktu pada saat itu. Sebaliknya, kami fokus pada peningkatan yang lebih kecil dan basis kode baru kami.

Takeaways

Saya masih berpikir sistem desain dapat melakukan banyak hal baik, dan di WebNL kami juga masih bekerja pada sistem desain baru untuk klien. Mereka hanya lebih disesuaikan sekarang dan kurang otomatis. Tetapi ada beberapa pelajaran yang telah kita pelajari bahwa setiap orang harus mengingat sebelum membuat sistem desain mereka sendiri.

• Kelola harapan. Jangan membuat diri Anda atau orang lain berpikir sistem desain Anda akan mengubah dunia dengan menghemat waktu Anda. Alih-alih, fokuslah pada hal-hal yang benar-benar penting, seperti desainer dan pengembang saling memahami.
• Jangan lakukan semuanya sekaligus. Di awal perjalanan Anda, mungkin tergoda untuk mencoba dan membuat sistem desain yang lengkap. Ini tidak akan berfungsi karena Anda harus menjelaskan dan memutuskan semua yang Anda buat bersama desainer dan pengembang lainnya. Sebaliknya, cobalah untuk mengambil langkah-langkah kecil seiring waktu.
• Desain untuk orang. Kesalahan terbesar yang saya buat adalah berpikir bahwa saya dapat meningkatkan koneksi antara desainer dan pengembang dengan menempatkan sistem di antara mereka. Jauh lebih baik untuk benar-benar menempatkan mereka di sebuah ruangan dan membuat mereka membuat keputusan bersama, bahkan ketika proses ini membutuhkan banyak waktu dan usaha.

Saya harap pelajaran ini dapat membantu Anda menghindari kesalahan yang kami buat selama upaya pertama kami membangun sistem desain. Semoga, saya akan dapat berbagi tentang alur kerja sistem desain baru kami dalam waktu dekat. Saya juga ingin tahu tentang bagaimana orang lain menggunakan sistem desain dalam alur kerja mereka. Tinggalkan komentar jika Anda ingin membagikan pengalaman Anda atau jika Anda memiliki pertanyaan.

sumber:UX Collective blog.marvelapp.com