Operasi desain ("DesignOps") adalah area yang berkembang dari keprihatinan bagi tim desain yang berusaha membantu tim mereka meningkatkan nilai yang mereka hasilkan untuk organisasi tuan rumah mereka dan pelanggan organisasi itu. Karena ini adalah bidang minat yang sedang berkembang, inkonsistensi dalam penggunaan "DesignOps", baik sebagai istilah dan sebagai praktik, masih ada.
Dalam posting blog ini, saya menyajikan pemikiran saya sendiri tentang DesignOps, yang telah sangat dipengaruhi oleh meningkatnya percakapan di antara rekan-rekan desain dari organisasi seperti Autodesk, Uber, Airbnb, Pinterest, Expedia, dan bahkan perusahaan non-teknologi seperti CapitalOne, Royal Bank of Canada (RBC), dan GE.
Alat Pengembang dan Desainer Tidak (Selalu) Sama
Jika Anda seorang pengembang, kode Anda. Anda dapat menulis kode dalam TextEdit atau Notepad dan menggunakan FTP, atau Anda mungkin lebih suka editor seperti Emacs dan vi. Anda kemudian dapat mulai menambahkan alat lain seperti IDE, kontrol versi, atau repo data. Dan pada akhirnya Anda dapat lapisan dalam sistem CI dan menambahkan pelacakan masalah dan pengujian otomatis. Masing-masing lapisan alat ini dimaksudkan untuk membuat Anda lebih baik sebagai pembuat kode dan lebih berharga bagi organisasi Anda. Pilihan alat yang digunakan adalah keputusan operasional.
Sistem operasional, yang terdiri dari proses, praktik, dan alat — seperti Agile, perangkat lunak manajemen proyek (JIRA, dll), dan ruang sunyi dan ruang kolaboratif — ada untuk membuat Anda sebagai pengembang lebih produktif, sehingga meningkatkan output Anda. Semua hal ini bertujuan untuk membuat Anda lebih baik dalam mengerjakan keahlian Anda: coding.
Di dunia desain, kami merenungkan hal-hal serupa. Beberapa sistem operasional mendukung proses desain itu sendiri; yang lain mendukung kolaborasi lintas-fungsional dengan teknik untuk memastikan niat desain dieksekusi sedekat mungkin dengan apa yang ada dalam pikiran tim desain. Poin terakhir khususnya adalah kekuatan pendorong di balik operasi desain: bagaimana kami berkolaborasi, berkomunikasi, menyerahkan hasil kerja, dan bermitra dengan teknik telah menjadi bagian sentral dari bagaimana DesignOps berkembang.
Sementara banyak organisasi telah mengoperasionalkan tim desain mereka dengan mengadopsi alat yang sama yang digunakan pengembang — JIRA, GitHub, atau Confluence, misalnya — keputusan ini tidak memperhitungkan alat dan proses berbeda yang unik untuk alur kerja perancang. Sebagai tim skala desain, menggunakan alat pengembangan dan proses untuk desain memiliki konsekuensi yang tidak diinginkan dari pengenceran nilai desain. Desainer tidak menggunakan IDE; mereka menggunakan alat grafis, dan bahkan bukan alat grafik tunggal. Desainer tidak membagikan atau berkolaborasi dalam kode melalui file teks di lingkungan sumber terbuka; mereka menggunakan campuran format grafik vektor dan raster yang sering dibuat dalam sistem tertutup, berpemilik. Desainer tidak melakukan hal yang sama seperti yang dilakukan pengembang (well, tidak semua desainer, dan mereka tidak boleh). Mereka akan mengeksplorasi banyak opsi di hampir setiap tahap proses desain. Konsep "forking" tidak akan skala ketika melihat 10-20 alternatif interaksi mikro tunggal dalam file yang sama di mana 5-10 alternatif tata letak dikelola.
Pada saat yang sama, tren yang berkembang dalam menciptakan sistem desain terkadang memaksa desainer untuk bekerja dalam file di mana mereka mungkin harus berinteraksi dengan kode pada tingkat tertentu. Ini biasanya dimaksudkan sebagai titik interaksi antara desainer dan pengembang. Karena sistem desain terdiri dari komponen yang ditulis dengan perpaduan CSS, HTML, dan JavaScript, menggunakan kontrol versi standar, manajemen masalah, dan bahkan alat manajemen proyek Agile mulai lebih masuk akal.
Ini menciptakan jenis komplikasi baru untuk desainer, di mana beberapa operasi menggunakan satu jenis sistem dan bagian lain membutuhkan sesuatu yang lain sama sekali. Kabar baiknya adalah ini mendorong desainer untuk lebih sadar dan disengaja tentang bagaimana mereka menggunakan sistem tersebut, terutama yang berada dalam garis pandang langsung dan komunikasi pengembang.
Mengatur Tim Desain
Menggunakan sistem yang berbeda untuk mengelola aset hanyalah satu aspek dari operasi desain, dan operasi secara keseluruhan hanyalah satu aspek untuk membuat individu dan tim menjadi lebih baik dalam keahlian mereka. Manajemen sumber daya manusia adalah pertimbangan penting lainnya untuk tim yang ingin memperbesar nilainya. Dan mirip dengan bidang manajemen aset operasi, organisasi yang berbeda akan menemukan berbagai cara untuk mengelola dan mengatur tim desain mereka.
Sebagai contoh, banyak tim desain memusatkan pekerjanya dalam satu kelompok desain tunggal, menugaskan anggota ke proyek sementara masih melaporkan langsung ke pemimpin desain tunggal. Organisasi lain melakukan yang sebaliknya: desainer disewa untuk bekerja secara langsung dalam tim proyek, dan "guild" diciptakan untuk membantu mengelola kebutuhan desain spesifik mereka.
Singkatnya, budaya organisasi dan tim yang berbeda membutuhkan solusi yang berbeda, yang bergantung pada banyak faktor. Dan ketika memperhitungkan aspek operasi lainnya seperti menjalankan sistem desain, proses desain, dan bahkan praktik penelitian, DesignOps menjadi jauh lebih kompleks.
Sumber daya
Kami akan membagikan lebih banyak wawasan tentang filosofi dan proses DesignOps spesifik DigitalOcean di posting blog mendatang. Sementara itu, Anda dapat membaca lebih lanjut tentang DesignOps di Amplify Design.
Jika Anda berada di NYC, bergabunglah dengan kami untuk konferensi pertama tentang topik DesignOps 6-8 November ini di Museum of the Moving Image, yang disebut DesignOps Summit. DigitalOcean akan ada di sana dan tim Anda mungkin menemukan nilai dalam pertemuan dengan sekelompok besar orang yang tertarik untuk mengembangkan pola pikir operasional untuk memperkuat nilai tim desain mereka. Kami berharap dapat melihat Anda di sana!