Diskusi Desain: Kolaborasi Desainer dan Pengembang yang Lebih Baik dengan Aaron Walter dari InVision

Selamat datang di seri Design Talks kami yang didedikasikan untuk berbagi wawasan para pemimpin pemikiran dan orang-orang top yang terlibat dalam desain dari seluruh dunia. Kami mewawancarai para ahli yang bekerja dengan desain dalam konteks yang berbeda, dengan tujuan yang berbeda, dan melalui pendekatan yang berbeda. Dalam seri ini, kami berharap dapat memberikan inspirasi intelektual dan kreatif kepada semua pembaca kami.

Desainer sering kesulitan untuk bekerja dengan pengembang dan sebaliknya. Tim di kedua sisi bisa belajar banyak dari satu sama lain, namun lapisan perlawanan tetap ada. Tamu minggu ini adalah Aarron Walter, Wakil Presiden Pendidikan Desain di InVision dan kita akan berbicara tentang kolaborasi desainer dan pengembang.

Aarron memanfaatkan 15 tahun pengalaman menjalankan tim produk dan mengajar desain untuk membantu perusahaan menerapkan praktik terbaik desain. Dia mendirikan praktik UX di MailChimp dan membantu mengembangkan produk dari beberapa ribu pengguna menjadi lebih dari 10 juta.

Panduan desainnya telah membantu Gedung Putih, Departemen Luar Negeri AS, dan lusinan perusahaan besar, perusahaan rintisan, dan perusahaan kapitalis ventura. Dia adalah penulis buku terlaris Merancang untuk Emosi dari A Book Apart. Anda akan menemukan @aarron di Twitter berbagi pemikiran tentang desain dan Anda dapat mempelajari lebih lanjut tentang Aarron di aarronwalter.com.

On the Design Better Podcast, pembawa acara Aarron Walter dan Eli Woolery mewawancarai para pemimpin desain dan influencer yang berbagi cerita tentang bagaimana mereka memecahkan masalah dan jalur karier mereka. Tamu termasuk David Kelley (pendiri IDEO dan pendiri Stanford d.school), Julie Zhuo (VP Produk dan Desain di Facebook), dan Jake Knapp (penulis buku terlaris Sprint).

Halo Aarron, senang memiliki Anda di Blog Desain Toptal. Apakah developer dari Mars dan desainer dari Venus?

Dalam pengalaman saya, desainer dan pengembang mungkin memiliki lebih banyak kesamaan daripada yang mereka sadari, tetapi pasti ada beberapa perbedaan berbeda dalam cara kita berpikir tentang berbagai hal. Desainer suka memikirkan sistem desain, dan pengembang memikirkan kode modular yang mudah dirawat. Tapi cara kita melakukannya mungkin sedikit berbeda.

Pengembang telah menemukan cara untuk memecah pekerjaan mereka menjadi bagian-bagian yang lebih kecil, dan desainer cenderung menganggap semuanya sebagai "kue utuh", dan bagaimana kita memakan kue utuh.

Ini adalah titik di mana mereka mulai bertengkar. Insinyur ingin dapat mengirimkan kode dalam langkah-langkah kecil dan membuat sesuatu dengan sangat cepat sebagai bagian dari metodologi Agile. Desainer cenderung ingin mengambil langkah maju yang besar secara holistik—mereka ingin memberikan pengalaman yang konsisten. Itu bisa menjadi titik pertikaian bagi kedua kelompok ini.

Apa yang dapat dilakukan desainer untuk membawa pengembang sedikit ke perspektif kita? Bagaimana desainer membuat pengembang memahami bahwa setiap fitur kecil yang dikirimkan adalah tentang pengalaman juga?

Ada kesempatan bagi kedua belah pihak untuk membungkuk di sini. Desainer terkadang mencoba meyakinkan pengembang bahwa kita perlu menunggu dan membangun semuanya, dan kemudian mengeluarkannya sebagai pengalaman yang indah dan lengkap ini.

Tetapi jika siklus pembuatan terlalu lama, produk berisiko mati. Orang-orang mulai kehilangan minat. Mereka mungkin berkata: “Apakah ini benar-benar menciptakan nilai bagi bisnis? Kami menghabiskan banyak waktu, energi, dan sumber daya untuk hal ini, mengapa butuh waktu lama?” Desainer perlu lebih memikirkan siklus bisnis.

Jika Apple mengirimkan telepon—bagian dari perangkat keras yang bermasalah—dapat berpotensi menghabiskan biaya miliaran dolar, tetapi jika perangkat lunak dikirimkan dan ada masalah, kami dapat menambalnya, memperbaikinya, dan mengirimkannya lagi. Mendekati proses dengan cara ini memungkinkan kita untuk terhubung kembali ke siklus kerja pengembangan dengan lebih elegan.

Desainer juga dapat mencoba menjembatani kesenjangan antara kedua kelompok dengan melibatkan insinyur dalam proses desain sejak dini sehingga mereka merasa termasuk dalam fase ide awal, bukan hanya hilir. Desainer mungkin berkata: "Kami datang dengan ide brilian ini, buat untuk kami!" dan itu membuat pengembang merasa bahwa mereka bukan bagian dari proses pembuatan ide. Mereka hanya tangan dan orang lain adalah otaknya.

Hubungan yang paling disfungsional antara desainer dan pengembang terjadi ketika ada pembagian kerja yang jelas. Semakin banyak yang mulai berbaur dan tim-tim itu bekerja sama, semakin baik. Akibatnya, akan ada banyak perspektif dan kepemilikan bersama yang benar-benar merupakan kunci bagi desainer dan pengembang untuk bekerja sama secara efektif.

Tentang Memahami Ruang Satu Sama Lain Lebih Baik…

Apa yang dapat dilakukan tim untuk memahami ruang satu sama lain dengan lebih baik? Haruskah desainer membiasakan diri dengan pengembangan dan sebaliknya?

Pertama, desainer dan pengembang dapat berbicara lebih banyak dengan pelanggan dan belajar tentang ruang masalah bersama . Mereka bisa berbicara dengan tiga sampai empat pelanggan di pagi hari sambil minum kopi; setiap orang dapat belajar dengan sangat cepat dan mencapai pemahaman bersama tentang apa yang menjadi perhatiannya.

Kedua, dalam hal proses kerja, penting bagi desainer dan pengembang untuk memiliki—mungkin bukan kelancaran—tetapi pemahaman tentang bahasa satu sama lain. Saya tidak bermaksud bahwa seorang desainer perlu tahu cara membuat kode, atau bahwa pengembang perlu menguasai tipografi, tetapi setidaknya ada pemahaman bersama.

Jika desainer dapat membingkai hal-hal dalam bahasa yang dipahami pengembang—”ini dan itu tidak berfungsi dan itu buruk untuk bisnis”—maka pengembang akan segera memahami masalahnya. Ini bukan sesuatu yang datang secara alami kepada desainer tetapi mereka harus lebih baik dalam mengkomunikasikan nilai pekerjaan mereka secara kuantitatif , bukan hanya secara kualitatif . Tim penjualan, tim pemasaran, teknik, produk, eksekutif, semua orang itu berbicara dalam angka, mereka berbicara secara kuantitatif .

Yang mengatakan, saya percaya desain membawa sesuatu yang sangat berharga, bahwa ada beberapa hal yang diperhitungkan yang tidak dapat dihitung. Pengalaman pelanggan, kegembiraan, kecintaan pada produk sangat berharga, dan itu sulit diukur.

Meskipun dapat diukur, komponen kualitas akan menghasilkan ROI yang dapat diukur.

Ya, kami dapat mengurangi biaya dukungan pelanggan dengan desain, kami dapat mengurangi churn, kami dapat meningkatkan kecepatan on-boarding. Memiliki metrik seperti itu untuk mengarahkan pandangan Anda membantu desain menyelaraskan upaya mereka dengan tujuan bisnis. Semakin banyak desainer dapat melakukan itu, semakin mereka akan dipahami. Semakin desain itu dinilai dalam perusahaan sebagai keunggulan kompetitif, semakin besar potensi investasi yang lebih berat akan tumbuh.

Tentang Jebakan Kolaborasi Desainer dan Pengembang…

Apa saja jebakan terbesar yang dihadapi desainer dan pengembang yang bekerja sama?

Salah satu perangkap terbesar adalah tidak memiliki bahasa yang sama, tidak memiliki tujuan bersama, dan rasio menjadi sangat tidak proporsional. Terkadang ada tim lintas fungsi dengan satu desainer dan 75 insinyur. Kedengarannya gila, tapi itu cukup umum.

Sebagian besar situasi itu tidak baik. Perancang tunggal itu adalah seorang ekspatriat. Mereka adalah orang asing di negeri asing di mana mereka tidak pernah cocok dengan budaya… dan sistem nilai mereka berbeda dari sistem nilai semua rekan mereka.

Dalam lingkungan itu, membuat kasus untuk fitur UX sangat menantang bagi seorang desainer: "Kita harus memiliki animasi ini dalam produk karena itu akan menciptakan pengalaman yang lebih menarik ..." ketika ada 75 insinyur yang mengatakan: "Itu 250 lebih baris kode dan dua hari kerja ekstra. Apakah itu benar-benar layak?” Dan mungkin tidak. Bagi mereka, itu akan tampak seperti "membeku." Tetapi interaksi mikro animasi dengan desainer UX benar-benar membentuk pengalaman pelanggan. Mereka bukan satu-satunya, tetapi mereka penting.

Ketika Anda memiliki rasio yang tidak merata antara desainer dan pengembang, itu menjadi sangat bermasalah. Namun, ada solusi. Perusahaan seperti Slack memecahkan masalah ini dengan “desain berpasangan.” Jika ada satu desainer untuk 10 insinyur di satu tim, dan rasio yang sama di tim lain, desainer solo itu menghabiskan sekitar delapan jam seminggu untuk bekerja bersama, memberikan solusi satu sama lain: “Begini cara saya memecahkan masalah ini, apakah ini masuk akal bagimu? Apakah ada cara yang lebih baik untuk melakukan ini?” Mereka dapat membantu satu sama lain untuk melepaskan diri dan tidak merasa seperti berada di sebuah pulau.

Tentang Desainer yang Menyampaikan Pentingnya UX…

Bagaimana desainer dapat menekankan pentingnya desain yang berpusat pada manusia dengan pengembang yang tidak benar-benar memahami HCD? Misalnya, bagaimana desainer menyampaikan bahwa menambahkan fitur tidak selalu melayani pelanggan, bahwa pengalaman menggunakan produk lebih penting daripada fiturnya?

Ada beberapa cara efektif untuk melakukannya. Sebagian besar desainer mungkin melakukannya dengan cara yang tidak efektif dengan memberi tahu pengembang secara langsung: “Hei, menambahkan lebih banyak fitur tidak membuat pengalaman menjadi lebih baik. Orang-orang mengatakan mereka menginginkannya, tetapi sebenarnya itu hanya membuat produk menjadi lebih rumit,” dan pengembang cenderung menjawab: “Saya tidak berpikir Anda benar, itu opini. Kami mendengar ini dari pelanggan kami, jadi kami harus mengikuti mereka.”

Yang terbaik adalah tidak menanganinya secara langsung, tetapi melakukannya dengan cara menyamping dan berkata: "Mari kita memahami ruang masalah dengan lebih baik bersama-sama." Saya sudah membeli makan siang untuk kita besok, dan saya telah mengatur untuk menunjukkan kepada Anda lima pelanggan kami menggunakan produk kami.

Saya telah melihat para insinyur menggeliat di kursi mereka ketika mereka melihat pelanggan benar-benar menggunakan produk, dan menyadari: "Kami membuat sesuatu yang cukup sulit untuk digunakan, dan orang-orang menjadi frustrasi karenanya." Insinyur ingin melakukan pekerjaan yang hebat, sama seperti desainer. Seringkali, mereka tidak memiliki kesempatan untuk melihat hasil pekerjaan mereka.

Anda mungkin pernah mendengar Jeff Gothelf berkhotbah bahwa kita harus fokus pada "hasil, bukan keluaran." Itu adalah cara lain kami dapat membingkai ulang pemikiran kami, bahwa hasilnya adalah: "kami mengirimkan lima fitur lagi", vs hasil: "kami mengurangi churn sebesar 10%."

Tentang Masa Depan Kolaborasi Desainer dan Pengembang…

Anda berbicara dengan banyak perusahaan dan melihat banyak tim desain dan pengembang bekerja sama. Alat, lingkungan, dan metodologi berubah. Apa masa depan bagi hubungan desainer/pengembang?

Ada air payau yang berkembang—ketika air asin dan air tawar menyatu—ada perpaduan antara peralatan teknik dan desain. Alih-alih sebuah proses yang terasa seperti lepas tangan di mana semua yang desain ada di sini dan semua yang rekayasa ada di sana, mereka mulai berbaur bersama.

Sejauh itu, kami melihat desainer menghabiskan banyak waktu di Jira, berpikir dalam cerita pengguna, dan mulai berpikir dengan pola pikir teknik juga. Dan sebaliknya, kami melihat para insinyur menggunakan alat seperti InVision Inspect, di mana mereka melihat spesifikasi dan kerusakan sistem desain, dan memahami komponen bagaimana semuanya cocok satu sama lain. Karena alat-alat ini dan perpaduan disiplin ilmu, pemahaman bersama berkembang.

Apakah pengembang atau desainer, Anda dapat mulai memahami perspektif mitra kunci Anda. Ini tidak berarti bahwa Anda harus menjadi pembuat kode yang ahli sebagai seorang desainer. Tapi itu tidak akan membunuh seorang desainer jika mereka tahu sedikit tentang cara menggunakan Git dan cara menulis beberapa HTML dan CSS, mungkin sedikit JavaScript. Itu sebenarnya akan membantu desainer memahami bagaimana hal-hal dibangun dan mendorong kolaborasi desainer dan pengembang yang lebih baik.

Bacaan lebih lanjut di Blog Desain Toptal:

• Cara Mendekati Desain untuk Pengembang
• Diskusi Desain: Penelitian dalam Tindakan dengan Peneliti UX Caitria O'Neill
• Diskusi Desain: Desain Cerdas Emosional dengan Pamela Pavliscak
• Pembicaraan Desain: Mengejar Desain Berbasis Nilai dengan Nick Disabato
• Cara Transisi dari UX Designer ke UX Consultant