Bagaimana Pengembang Frontend Dapat Memberdayakan Pekerjaan Desainer

Artikel ini sebagian besar ditujukan untuk Anda, Pengembang Frontend tersayang, yang senang mengimplementasikan antarmuka pengguna tetapi berjuang dalam menyelaraskan harapan dengan desainer yang bekerja dengan Anda. Mungkin Anda disebut sebagai "Pengembang UI" atau "Insinyur UX." Terlepas dari judul yang Anda bawa, pekerjaan Anda (dan juga pekerjaan saya) terdiri dari lebih dari sekadar menghembuskan kehidupan ke dalam file desain. Kami juga bertanggung jawab untuk mengisi kesenjangan antara alur kerja desain dan pengembangan . Namun, saat melintasi jembatan itu, kami dihadapkan pada banyak tantangan.

Hari ini, saya ingin berbagi dengan Anda tips praktis yang telah membantu saya berkolaborasi secara lebih efisien dengan desainer dalam beberapa tahun terakhir.

Saya percaya itu tugas kita, sebagai Pengembang UI, untuk tidak hanya membantu desainer dalam perjalanan mereka untuk mempelajari cara kerja web, tetapi juga untuk mengetahui realitas mereka dan mempelajari bahasa mereka.

Memahami Latar Belakang Desainer UX

Sebagian besar desainer UX (juga disebut sebagai Desainer Web atau Desainer Produk) di luar sana mengambil langkah pertama mereka di dunia desain melalui alat seperti Photoshop dan Illustrator. Mungkin mereka adalah Desainer Grafis : tujuan utama mereka adalah membuat logo dan identitas merek dan merancang tata letak untuk majalah. Mereka juga bisa menjadi Desainer Pemasaran : mencetak baliho, mendesain spanduk, dan membuat infografis.

Ini berarti bahwa sebagian besar desainer UX menghabiskan hari-hari awal mereka mendesain untuk dicetak, yang merupakan paradigma yang sama sekali berbeda dari media mereka saat ini, layar. Itu adalah tantangan besar pertama mereka. Saat berurusan dengan cetakan, desainer peduli dengan perataan piksel, tetapi pada area yang tetap (kertas). Mereka tidak harus bersaing dengan tata letak dinamis (layar). Memikirkan tentang pemecahan teks atau status interaksi juga bukan bagian dari pekerjaan mereka. Desainer juga memiliki kebebasan penuh atas warna, gambar, dan tipografi tanpa kendala kinerja.

Untungnya, ada banyak upaya dari komunitas desainer UX otodidak, untuk mengajarkan dasar-dasar pengembangan, mendiskusikan apakah desainer harus belajar membuat kode dan memahami cara terbaik melakukan hand-off kepada pengembang. Hal yang sama juga berlaku untuk sisi pengembangan (lebih lanjut tentang itu sebentar lagi). Namun, masih terjadi gesekan antara kedua bidang tersebut.

Di satu sisi, desainer mengeluh setiap kali implementasi tidak sesuai dengan desain mereka atau merasa disalahpahami ketika ditolak oleh pengembang tanpa penjelasan yang jelas. Di sisi lain, pengembang mungkin menerima begitu saja bahwa desainer mengetahui sesuatu yang teknis padahal itu mungkin tidak benar. Saya percaya kita semua bisa melakukan lebih baik dari itu.

Merangkul Cara Berpikir Baru

Situs web dan aplikasi yang kami buat akan ditampilkan pada berbagai ukuran layar. Setiap orang akan menggunakannya di beberapa perangkat. Tujuan bersama kami adalah untuk menciptakan pengalaman yang akrab di seluruh perjalanan mereka.

Ketika kita, sebagai pengembang, berpikir bahwa desainer sedang pilih-pilih tentang perataan piksel, kita perlu memahami mengapa demikian. Kita perlu menyadari bahwa itu melampaui kesetiaan dan konsistensi. Ini tentang jumlah semua bagian yang bekerja bersama. Ini kohesi. Kita harus menerimanya dan melakukan yang terbaik untuk mencapainya. Mempelajari dasar-dasar prinsip-prinsip desain adalah titik awal yang baik . Pahami pentingnya memilih warna yang tepat, cara kerja hierarki, dan mengapa ruang putih penting.

Catatan : Ada kursus online yang dikenal sebagai "Desain untuk Pengembang" dan buku berjudul "Pemfaktoran Ulang UI" — keduanya bagus untuk membantu Anda memulai. Dengan ini, Anda akan dapat mengimplementasikan antarmuka pengguna dengan detail yang tajam dan mendapatkan pengaruh yang signifikan saat berkomunikasi dengan desainer.

Memperbesar Kesadaran Desainer Anda

Anda mungkin menerima begitu saja bahwa desainer mengetahui web sebanyak Anda. Yah, mereka mungkin tidak. Sebenarnya, mereka tidak harus melakukannya! Merupakan tanggung jawab kami, sebagai pengembang, untuk terus memperbarui mereka dengan keadaan web saat ini.

Saya telah bekerja dengan dua sisi spektrum ini: Desainer yang berpikir bahwa apa pun dapat dibuat (seperti filter kompleks, perilaku gulir baru, atau input formulir khusus) tanpa memikirkan kompatibilitas browser. Kemudian, ada desainer dengan asumsi tentang "keterbatasan web yang rendah" dan hanya berasumsi sendiri bahwa ada sesuatu yang tidak mungkin untuk diterapkan. Kita perlu menunjukkan kepada mereka kemungkinan sebenarnya dari desain web dan tidak membiarkan keterbatasan menghambat keterampilan mereka.

Ajari Mereka Kode, Bukan Cara Membuat Kode

Ini tampaknya kontradiktif tetapi bersabarlah: mengetahui cara membuat kode adalah inti dari pekerjaan pengembang. Kami bekerja di industri yang bergerak cepat dengan hal-hal baru yang bermunculan setiap hari. Ini akan menjadi permintaan munafik dari kami untuk menuntut desainer untuk belajar bagaimana membuat kode. Namun, kami dapat membantu mereka untuk memahami kode.

Duduk di sebelah desainer yang bekerja dengan Anda selama 15 menit dan ajari mereka bagaimana mereka dapat melihat sendiri apakah spesifikasi suatu elemen sudah benar dan bagaimana mengubahnya. Saya menemukan Firefox Page Inspector sangat ramah pengguna untuk ini.

Saat ini, sangat menyenangkan untuk memvisualisasikan tata letak, men-debug animasi CSS, dan mengubah tipografi. Tunjukkan pada mereka taman bermain kode yang siap digunakan seperti Codepen untuk mereka jelajahi. Mereka tidak perlu mengetahui semua spesifikasi CSS untuk memahami cara kerja paradigma tata letak. Namun, mereka perlu mengetahui bagaimana elemen diciptakan dan berperilaku untuk memberdayakan pekerjaan sehari-hari mereka.

Sertakan Desainer Dalam Proses Pengembangan

Undang desainer untuk bergabung dengan Anda dalam pertemuan stand-up, untuk menjadi bagian dari proses QA dan duduk bersama Anda saat Anda menyempurnakan detail visual dalam implementasi Anda. Ini akan membuat mereka memahami batasan web dan, segera, mereka akan mengenali mengapa fitur membutuhkan waktu untuk diterapkan.

Minta Desainer Untuk Mengikutsertakan Anda Dalam Proses Desain Mereka

Anda akan menyadari bahwa mereka melakukan lebih dari sekadar "membuat sesuatu menjadi cantik". Anda akan mempelajari lebih lanjut tentang proses penelitian dan bagaimana pengujian pengguna dilakukan. Anda akan menemukan bahwa untuk setiap proposal desain yang mereka tunjukkan kepada Anda, beberapa penelitian lain sebelumnya dibatalkan. Saat desainer meminta perubahan, tanyakan alasan di baliknya, sehingga Anda dapat mempelajari lebih lanjut tentang keputusan yang dibuat . Pada akhirnya, Anda akan mulai memahami mengapa mereka pilih-pilih tentang ruang putih dan keberpihakan, dan mudah-mudahan, Anda juga akan segera!

Saya merasa penting untuk memperlakukan pengembangan frontend sebagai bagian inti dari proses desain, dan desain sebagai bagian inti dari proses pengembangan. Mengadvokasi pola pikir di mana setiap orang mendapat kesempatan untuk terlibat dalam siklus desain dan pengembangan akan membantu kita semua untuk lebih memahami tantangan satu sama lain dan juga untuk menciptakan pengalaman hebat.

Kita Mungkin Menggunakan Alat Yang Berbeda, Tapi Kita Harus Berbicara Dengan Bahasa Yang Sama

Sekarang kita mulai memahami alur kerja satu sama lain sedikit lebih baik, saatnya untuk langkah selanjutnya: berbicara dalam bahasa yang sama.

Melihat Melampaui Editor Kode

Setelah Anda mulai memperhatikan lingkungan Anda, Anda akan lebih siap untuk mengatasi masalah. Kenali bisnis lebih baik dan bersedia mendengarkan apa yang dikatakan desainer. Itu akan membuat Anda menjadi anggota tim dengan kontribusi yang lebih kaya untuk proyek. Berkolaborasi di bidang di luar keahlian kami adalah kunci untuk menciptakan percakapan yang bermakna dan rasa saling percaya.

Menggunakan Sistem UI Sebagai Kontrak

Minta desainer untuk berbagi sistem desain mereka dengan Anda (dan jika mereka tidak menggunakannya, tidak ada kata terlambat untuk memulai). Itu akan menghemat kerumitan memilih sendiri warna yang digunakan, mencari tahu margin atau menebak gaya teks. Pastikan Anda sudah familiar dengan Sistem UI sebanyak mereka.

Anda mungkin sudah akrab dengan konsep berbasis komponen. Namun, beberapa desainer mungkin tidak melihatnya dengan cara yang sama seperti Anda. Tunjukkan pada mereka bagaimana komponen dapat membantu Anda membangun antarmuka pengguna dengan lebih efisien. Sebarkan pola pikir itu dan juga ucapkan selamat tinggal pada nama yang mirip tetapi tidak sama: header vs hero, info harga vs pemilih harga . Saat sepotong antarmuka pengguna (alias 'komponen') dibuat, gunakan nama yang sama sehingga dapat direfleksikan dalam file desain dan kode. Kemudian, ketika seseorang berkata, "Kita perlu mengubah widget undangan proposal," semua orang tahu persis apa yang sedang dibicarakan.

Mengakui Sumber Kebenaran Sejati

Terlepas dari kenyataan bahwa antarmuka pengguna pertama kali dibuat dalam file desain, sumber kebenaran sebenarnya ada di sisi pengembangan. Pada akhirnya, itulah yang sebenarnya dilihat orang, bukan? Saat desain diperbarui, ada baiknya untuk meninggalkan catatan tambahan tentang status pengembangannya, terutama dalam proyek yang melibatkan banyak orang. Trik ini membantu menjaga komunikasi tetap lancar, jadi tidak ada orang (termasuk Anda) yang bertanya-tanya: “ Ini berbeda dari versi live. Apakah ini bug atau belum diimplementasikan? ”

Menjaga Utang Di Bawah Kontrol

Jadi, Anda tahu semua tentang utang teknis — itu terjadi ketika biaya untuk menerapkan sesuatu yang baru tinggi karena jalan pintas yang kami ambil di masa lalu untuk memenuhi tenggat waktu. Hal yang sama bisa terjadi di sisi desain juga dan kami menyebutnya hutang desain .

Anda dapat memikirkannya seperti ini: Semakin tinggi inkonsistensi UX & UI, semakin tinggi hutang (teknis dan desain). Salah satu inkonsistensi yang paling umum adalah memiliki elemen yang berbeda untuk mewakili tindakan yang sama. Inilah sebabnya mengapa desain yang buruk biasanya tercermin dalam kode yang buruk . Terserah kita semua, baik sebagai desainer maupun pengembang, untuk memperlakukan utang desain kita dengan serius.

Menjadi Dapat Diakses Tidak Berarti Harus Jelek

Saya sangat senang melihat bahwa kami, sebagai pengembang dan desainer, akhirnya mulai menghadirkan aksesibilitas ke dalam pekerjaan kami. Namun, banyak dari kita masih berpikir bahwa mendesain produk yang mudah diakses itu sulit atau membatasi keterampilan dan kreativitas kita.

Izinkan saya mengingatkan Anda bahwa kami tidak menciptakan produk hanya untuk diri kami sendiri. Kami menciptakan produk untuk digunakan oleh semua orang , termasuk mereka yang menggunakan produk dengan cara yang berbeda dari Anda. Mempertimbangkan bagaimana elemen individu dapat lebih mudah diakses sambil menjaga alur pengguna saat ini tetap jelas dan koheren.

Misalnya, jika seorang desainer benar-benar percaya bahwa membuat input pilihan yang disempurnakan diperlukan, berdiri di sisi mereka dan bekerja sama untuk merancang dan mengimplementasikannya dengan cara yang dapat diakses untuk digunakan oleh banyak orang dengan beragam kemampuan.

Memberikan Umpan Balik Berharga Untuk Desainer

Tidak dapat dihindari bahwa pertanyaan akan muncul ketika melalui desain. Namun, itu bukan alasan bagi Anda untuk mulai mengeluh tentang kesalahan para desainer atau tentang ide-ide ambisius mereka. Para desainer tidak ada di sana untuk mendorong Anda mental, mereka hanya tidak selalu secara intuitif tahu apa yang Anda butuhkan untuk melakukan pekerjaan Anda. Sebenarnya, di masa lalu, Anda juga tidak tahu tentang hal ini, jadi bersabarlah dan rangkul kolaborasi sebagai cara belajar.

Semakin Awal Umpan Balik, Semakin Baik

Waktu untuk umpan balik sangat penting. Alur kerja umpan balik sangat bergantung pada struktur proyek, jadi tidak ada solusi satu ukuran untuk semua untuk itu. Namun, jika memungkinkan, saya yakin kita harus mengarahkan alur kerja umpan balik berkala — mulai dari tahap awal. Memiliki pola pikir kolaborasi terbuka ini adalah cara untuk mengurangi kemungkinan pengulangan besar yang tidak terduga di kemudian hari. Ingatlah bahwa semakin Anda memberi desainer umpan balik pertama Anda, semakin tinggi biaya yang harus mereka keluarkan untuk mengeksplorasi pendekatan baru jika diperlukan.

Jelaskan Ide Abstrak Secara Sederhana

Ingat ketika saya mengatakan bahwa kinerja bukan urusan pekerjaan desainer sebelumnya? Jangan panik ketika mereka tidak mengetahui cara membuat SVG yang dioptimalkan untuk web. Ketika dihadapkan dengan desain yang membutuhkan banyak font berbeda untuk dimuat, jelaskan kepada mereka mengapa kita harus meminimalkan jumlah permintaan, bahkan mungkin memanfaatkan Variable Fonts. Selain memuat lebih cepat, ini juga memberikan pengalaman pengguna yang lebih konsisten. Kecuali jika desainer ingin belajar, hindari menggunakan terlalu banyak istilah teknis saat menjelaskan sesuatu. Anda dapat melihat ini sebagai kesempatan untuk meningkatkan keterampilan komunikasi Anda dan memperjelas pikiran Anda.

Jangan Biarkan Asumsi Berubah Menjadi Keputusan

Beberapa pertanyaan tentang spesifikasi desain hanya muncul saat kita mengotori kode. Untuk mempercepat, kita mungkin merasa tergoda untuk membuat keputusan berdasarkan asumsi kita. Tolong, jangan. Setiap kali Anda mengubah asumsi menjadi keputusan, Anda mempertaruhkan kepercayaan yang diberikan tim desain kepada Anda untuk mengimplementasikan UI. Kapan pun ragu, jangkau dan klarifikasi keraguan Anda . Ini akan menunjukkan kepada mereka bahwa Anda peduli dengan hasil akhir seperti halnya mereka.

Jangan Lakukan Penyelesaian Sendiri

Ketika Anda diminta untuk mengimplementasikan desain yang terlalu sulit, jangan katakan "Tidak mungkin" atau mulai menerapkan versi alternatif yang murah sendiri. Hal ini langsung menimbulkan gesekan dengan tim desain ketika mereka melihat desain mereka tidak diimplementasikan seperti yang diharapkan. Mereka mungkin bereaksi dengan marah, atau tidak mengatakan apa-apa selain merasa kalah atau frustrasi. Itu semua dapat dihindari jika kita menjelaskan kepada mereka mengapa sesuatu itu tidak mungkin, secara sederhana dan menyarankan pendekatan alternatif. Hindari perilaku dogmatis dan terbuka untuk berkolaborasi dalam solusi baru .

Beri tahu mereka tentang teknik Graceful Degradation dan Progressive Enhancement dan buat bersama solusi ideal dan solusi fallback. Misalnya, kita dapat meningkatkan tata letak dari flexbox ke CSS Grid. Hal ini memungkinkan kami untuk menghormati tujuan inti dari suatu fitur dan pada saat yang sama memanfaatkan teknologi web dengan sebaik-baiknya.

Ketika datang ke animasi, mari kita menjadi nyata: jauh di lubuk hati Anda sangat senang untuk mengimplementasikan animasi wow berikutnya sebanyak para desainer untuk membuatnya. Perbedaan antara kami dan mereka adalah bahwa kami lebih sadar akan batasan web. Namun, jangan biarkan hal itu membatasi keterampilan Anda sendiri! Web berkembang dengan cepat, jadi kita harus menggunakannya untuk kebaikan kita.

Lain kali Anda diminta untuk menghidupkan prototipe, cobalah untuk tidak menolaknya terlebih dahulu atau melakukan semuanya sendiri. Lihat itu sebagai kesempatan untuk mendorong diri sendiri. Animasi adalah salah satu bagian yang paling dipilih dalam pengembangan web, jadi pastikan untuk menyempurnakan setiap bingkai utama dengan desainer Anda — secara langsung atau dengan membagikan tautan pribadi yang disinkronkan.

Pikirkan Melampaui Keadaan Ideal — Bersama

Inilah masalahnya: ini tidak semua tentang Anda. Salah satu tantangan desainer adalah untuk benar-benar memahami penggunanya dan mempresentasikan desain dengan cara yang paling menarik untuk dijual kepada Manajer Produk. Terkadang mereka lupa tentang apa yang berada di luar keadaan ideal dan pengembang juga melupakannya.

Untuk membantu menghindari kesenjangan ini terjadi, sejajarkan dengan desainer persyaratan skenario:

• Skenario terburuk
  Skenario di mana kemungkinan terburuk terjadi. Ini membantu desainer untuk mengatakan tidak pada konten tetap dan membiarkannya mengalir. Apa yang terjadi jika judul memiliki lebih dari 60 karakter atau jika daftar terlalu panjang? Hal yang sama berlaku untuk kebalikannya, skenario kosong. Apa yang harus dilakukan pengguna saat daftar kosong?
• Status interaksi
  Peramban lebih dari sekadar melayang dan mengeklik. Ada banyak status: default, arahkan kursor, fokus, aktif, nonaktifkan, error… dan beberapa di antaranya dapat terjadi secara bersamaan. Mari beri mereka perhatian yang tepat.
• Status pemuatan
  Saat membuat barang secara lokal, kita mungkin menggunakan tiruan dan lupa bahwa hal itu sebenarnya membutuhkan waktu untuk dimuat. Beri tahu desainer tentang kemungkinan itu juga dan tunjukkan kepada mereka bahwa itu adalah cara untuk membuat orang merasa bahwa segala sesuatunya tidak butuh waktu lama untuk dimuat.

Mempertimbangkan semua skenario ini akan menghemat banyak waktu untuk bolak-balik selama fase pengembangan.

Catatan : Ada artikel bagus dari Scott Hurff tentang cara memperbaiki antarmuka pengguna yang buruk yang akan membawa kita selangkah lebih dekat ke produk yang dapat diakses.

Rangkul Permintaan Perubahan

Pengembang dikenal tidak terlalu senang dengan seseorang yang menemukan bug dalam kode mereka — terutama jika itu adalah bug desain yang dilaporkan oleh seorang desainer. Ada banyak meme di sekitarnya, tetapi pernahkah Anda merenungkan bagaimana bug tersebut dapat memperburuk kualitas pengalaman serta hubungan Anda ketika bug desain ini diabaikan begitu saja? Itu terjadi perlahan, hampir seperti tertidur. Sedikit demi sedikit, lalu sekaligus. Desainer mungkin mulai berkata, " Ini hanya detail kecil kecil, " sampai ketidakpedulian dan kebencian menumpuk dan tidak ada yang dikatakan. Kerusakan kemudian sudah dilakukan.

Situasi ini ada dua: baik untuk rekan-rekan Anda dan untuk pekerjaan Anda. Jangan biarkan itu terjadi. Kerjakan apa yang mewarnai reaksi Anda. Seorang desainer yang 'pilih-pilih' bisa merepotkan, tetapi juga bisa menjadi interpretasi dangkal seorang insinyur tentang perhatian dan antusiasme. Ketika seseorang memberi tahu Anda bahwa implementasi Anda belum sempurna (belum), kesampingkan ego Anda dan tunjukkan kepada mereka bagaimana Anda mengenali kerja keras mereka dalam menyempurnakan hasil akhir.

Keluar dari Rekaman Sekali-sekali

Kita semua memiliki tugas untuk disampaikan dan peta jalan untuk diselesaikan. Namun, beberapa karya terbaik tidak direkam. Itu tidak akan masuk ke papan TO DO dan tidak apa-apa. Jika Anda menemukan desainer yang memiliki hubungan baik dengan Anda, masuklah ke ruang kerja mereka dan jelajahi eksperimen baru bersama. Anda tidak pernah tahu apa yang bisa datang dari sana!

Kesimpulan

Ketika Anda mau belajar dari tim desain, Anda juga belajar cara berpikir yang berbeda. Anda akan mengembangkan pola pikir kolaborasi Anda dengan area lain dari pengalaman Anda sambil menyempurnakan mata Anda untuk menciptakan pengalaman baru. Hadir untuk membantu dan terbuka untuk belajar, karena berbagi adalah hal yang membuat kita lebih baik.

Artikel ini tidak akan mungkin tanpa umpan balik dari banyak orang hebat. Saya ingin berterima kasih kepada desainer Jasmine Meijer dan Margarida Botelho karena telah membantu saya untuk berbagi perspektif yang seimbang tentang kesalahpahaman antara desainer dan pengembang.

Bacaan Terkait di SmashingMag:

• “Desain Untuk Pengembang” oleh Mason Gentry
• “Bekerja Bersama: Bagaimana Desainer dan Pengembang Dapat Berkomunikasi Untuk Membuat Proyek yang Lebih Baik” oleh Rachel Andrew
• “Bagaimana Pengembang Frontend Dapat Membantu Menjembatani Kesenjangan Antara Desainer dan Pengembang” oleh Stefan Kaltenegger
• “Podcast Manakah yang Harus Didengar oleh Desainer dan Pengembang Web?” oleh Ricky Onsman