6 Pertanyaan tentang Keberhasilan dan Kegagalan Sistem Desain

Akhir-akhir ini saya banyak berpikir karena ikut terlibat dalam perancangan awal design system.

Terkait itu, ini adalah bacaan yang saya lihat minggu lalu di UX Collective. Saya menerjemahkannya untuk anggota design system di perusahaan, lalu rasanya sayang kalau tidak dibagikan juga di sini.

Katanya ini adalah rangkuman hasil wawancara dengan 10 desainer yang menangani design system.

Pertanyaan 1. Jika ingin gagal dalam peran DS?:

• Menjadi polisi

• Menggunakan kuasa desainer (bicara soal politik)

• Mengintegrasikan komponen tetapi tidak benar-benar menggunakannya

• Bekerja secara reaktif alih-alih mengantisipasi kebutuhan tim

• Tidak mendengarkan atau meneliti suara pengguna (desainer atau developer lain)

• DS yang dibuat demi DS itu sendiri

• Tidak menjaga roadmap dan proses kerja yang jelas

• Menciptakan pengalaman ideal yang tidak mungkin diwujudkan

• Tidak melakukan pengujian bersama tim

• Tidak memahami DS sebagai sebuah produk

• Membuat alat tetapi tidak mengajari orang cara menggunakannya

• Membawa terlalu banyak teori yang jauh dari cara kerja nyata

• Mengira bisa melakukannya sendirian

• Tidak berfokus 100% pada pertukaran pengetahuan dengan seseorang dari tim teknis

• Membuat komponen yang terlalu tidak fleksibel dan tidak mengizinkan detaching

• Tidak meminta bantuan dan tidak terhubung dengan orang lain (baik internal maupun eksternal)

• Memberi instruksi aturan dari jauh, bukan dari sisi orang-orang yang bekerja langsung

Pertanyaan 2. Soft skill apa yang dibutuhkan agar DS berhasil?

• Komunikasi, komunikasi, komunikasi!!!

• Bekerja bersama pengguna, mendengar, bertanya, dan meneliti itu sangat penting.

• Akui kegagalan dengan rendah hati

• Bersabarlah

• Kemampuan menciptakan ruang yang aman

• Mengajar

• Menyajikan visi yang sistematis tentang cara melakukan reuse

• Tetap tegas dan konsisten bahkan saat melakukan scale

• Saat memahami orang lain, Anda tidak harus terlalu berempati. Terimalah aturan sebagaimana adanya.

• 95% adalah hard skill dan 5% adalah soft skill untuk saat aturan dilanggar.

• Dorong pertumbuhan orang dan bagikan hal-hal itu

• Otonomi

• Terus jual produk (DS) Anda

• Berpikirlah strategis

• Libatkan semua orang

• Buat DS terdengar di mana-mana

• Curahkan sebanyak mungkin waktu untuk menemukan sebanyak mungkin skenario

• Samakan bahasanya.

Pertanyaan 3. Haruskah cara DS dijalankan lebih tersentralisasi atau lebih terdistribusi?

Ada dua pendekatan: tim terpusat yang memeriksa dan bertanggung jawab atas cara orang mendesain, dan pendekatan yang membuat semua orang ikut bertanggung jawab. Saya bertanya kepada orang-orang pendekatan mana yang lebih tepat.

• Tim kami terlalu terpusat sehingga menimbulkan bottleneck. Namun model terdistribusi juga bisa punya masalah kepemilikan yang melemah.

• Kami memiliki tim desainer beranggotakan lebih dari 100 orang untuk memusatkan DS.

• Kami bekerja sama dengan alpha library yang dibuat orang-orang, lalu dari sana membentuk backlog tim DS.

• Kami mendidik orang agar secara sukarela membuat komponen.

• Apakah akan dibuat terpusat atau tidak adalah persoalan yang sangat politis. Sebelum memutuskannya, Anda harus tahu dengan tepat seberapa scalable sistem itu perlu dibuat.

• Anda harus menyelaraskan ekspektasi dan melibatkan orang-orang dalam pembuatan DS.

• Kami ingin berkolaborasi, tetapi tidak tahu caranya, jadi kami membuat proses. (Culture vs Process)

• Di awal, mungkin pendekatannya agak kurang kolaboratif demi delivery. Setelah matang, Anda bisa membuatnya lebih kolaboratif.

• Kami kini sampai pada tahap di mana ini perlu didesentralisasi; kami harus mengajari orang cara berkontribusi.

• Jika Anda tidak mendidik orang, mereka tidak akan berkontribusi.

• Ketika desainer ingin melampaui standar dan membuat hasil yang lebih baik, pada saat yang sama mereka juga harus bisa memikirkan cara menstandarkannya.

• DS tidak bisa dikerjakan oleh 1~2 orang. Karena ini adalah membangun sebuah sistem, DS harus dimulai dari level squad.

• Ini sangat berbeda tergantung ukuran tim, dan kadang tim DS bisa fokus pada pengembangan core component sementara ambassador lain membantu menyebarkannya.

• Pada akhirnya kami adalah tim terpusat, tetapi bekerja secara kolaboratif dengan para ambassador. Keputusan akhir dibuat oleh tim DS.

4. Apakah Anda menganggap DS sebagai aturan yang lebih detail dan membatasi? Atau sesuatu yang lebih luas dan terbuka yang memberi desainer kebebasan membuat layout baru?

Tertutup atau terbuka? Jika Anda bekerja dengan design system, pertanyaan ini pasti menarik. Karena saya juga begitu, saya memutuskan untuk menanyakannya kepada orang-orang.

• Untuk hal-hal terkait "aksesibilitas", ambillah pendekatan yang lebih ketat

• Kami semua memulai dari struktur dasar yang sama, tetapi mulai menciptakan beberapa inkonsistensi. Karena itu kami memutuskan untuk tidak 100% tertutup, tetapi memberi lebih banyak batasan. Meski begitu, kami selalu berusaha mencari cara untuk tetap mengembalikan sesuatu kepada desainer

• Itu tergantung situasinya, jadi ukur dulu risikonya baru putuskan. Secara umum, tim yang lebih kecil = fleksibilitas yang lebih tinggi

• Ini bukan sekadar pekerjaan kreatif untuk membuat komponen baru. Kita butuh komponen yang cukup fleksibel agar bisa menyesuaikan kebutuhan orang-orang

• DS adalah bisnis. Semakin sedikit komponennya, semakin baik.

• Orang-orang harus senang menggunakan DS. Dari luar, mudah mengira ini seperti seragam sehingga tidak perlu fleksibel (padahal tidak begitu)

• Tidak bisa sejak awal langsung sangat ketat. Seiring berjalannya waktu yang cukup, sistem bisa mulai berevolusi ke pola-pola tertentu.

• Bagi desainer yang baru bergabung ke perusahaan, lebih banyak batasan justru bisa membantu. Untuk melanggar aturan, Anda harus mulai dari aturan dulu.

• Kami menyediakan cukup banyak bahan agar orang-orang bisa membuat resep mereka sendiri.

• Itu bergantung pada tingkat kematangan tim. Jika lebih banyak junior, mereka cenderung meminta lebih banyak panduan desain karena mereka memahami dokumentasi yang lebih sedikit. Jadi dibutuhkan lebih banyak edukasi, tetapi kami tetap berusaha agar mereka tidak terkekang dan bisa bekerja dengan bebas. Tantangan terbesarnya adalah membuat orang benar-benar membaca dan menggunakan dokumentasi, sehingga ada kemungkinan membawanya lebih dekat ke desainer seperti Figma.

• Jika terkait aksesibilitas dan estetika, sebaiknya lebih ketat.

• Token penting untuk menjaga konsistensi.

• Dokumentasi yang baik menyeimbangkan harmoni dengan orang-orang dan memberi mereka kebebasan.

Pertanyaan 5. Bagaimana pendapat Anda tentang DS yang terhubung dengan branding dan marketing?

Saya paham bahwa design system pada akhirnya harus berkaitan dengan produk digital, tetapi karena produk bisa menjadi salah satu platform brand yang paling penting, saya penasaran bagaimana orang-orang menghubungkan keduanya dalam pemikiran mereka.

• Cara berpikir tentang branding yang terhubung ke DS adalah dengan memikirkan bagaimana branding itu justru memengaruhi DS.

• Kami mulai menyesuaikan design system dengan brand untuk menyelaraskan tampilan dan nuansa brand.

• DS adalah soal scale dan brand ID, tetapi hubungan antara keduanya berbeda-beda tergantung tim brandingnya.

• Since DS is a language, MKT could support with assets for it;

• Tim branding harus bergabung ke DS sejak awal untuk membuat aturan dasar.

• Itu tergantung perusahaannya. Karena DS adalah alat untuk memperkuat brand, menjaga keselarasan itu penting. Hubungan antara dua area ini juga memengaruhi aksesibilitas DS.

• Penting untuk menemukan cara menyinkronkan diri dengan tim branding demi menyelaraskan strategi.

• They were used to join projects that the company already had a partner to support with branding, so they would come together with these partners to bring the brand inside the DS;

• Terkadang dokumentasi dan sistem bisa dipakai bersama, tetapi umumnya tidak. DS adalah interface. Tim brand biasanya punya "branding system" terpisah, dan yang lebih umum adalah library mereka saling berinteraksi. Keduanya tidak sepenuhnya sama.

Pertanyaan 6. Bagaimana cara mengukur keberhasilan DS?

• Keterlibatan, adopsi, dan survei persepsi untuk memahami kondisi tim

• Component coverage (seberapa banyak DS digunakan vs yang masih hardcoded)

• Adoption

• Time to market

• ROI

• Figma Analytics

• Respons dari tim developer

• Aksesibilitas

• Jumlah penggunaan komponen

[xguru]

Wah, bagus sekali. Terima kasih sudah merangkumnya!