Bagaimana Pengembang Frontend Dapat Membantu Menjembatani Kesenjangan Antara Desainer dan Pengembang
Diterbitkan: 2022-03-10Dalam sembilan tahun terakhir, hampir setiap desainer yang pernah bekerja dengan saya mengungkapkan kekesalan mereka kepada saya tentang mereka yang sering harus menghabiskan waktu berhari-hari untuk memberikan umpan balik kepada pengembang untuk memperbaiki jarak, ukuran font, visual, serta aspek tata letak yang tidak diterapkan dengan benar. . Hal ini sering menyebabkan melemahnya kepercayaan antara desainer dan pengembang, dan menyebabkan desainer tidak termotivasi bersama dengan suasana yang buruk di antara kedua disiplin ilmu tersebut.
Sering kali pengembang tampaknya masih memiliki reputasi buruk karena terlalu teknis dan bodoh dalam hal mempertimbangkan detail yang dibuat oleh tim desain. Menurut sebuah artikel oleh Andy Budd, “[…] banyak pengembang berada di posisi yang sama tentang desain — mereka tidak menyadarinya.” Namun pada kenyataannya (seperti yang ditunjukkan Paul Boag), “pengembang [perlu] membuat keputusan desain sepanjang waktu.”
Dalam artikel ini, saya akan memberikan saran praktis untuk pengembang frontend untuk menghindari frustrasi dan meningkatkan produktivitas saat bekerja dengan rekan kreatif mereka.
Melihat Melalui Mata Seorang Desainer
Mari sejenak bayangkan Anda adalah seorang desainer dan menghabiskan minggu-minggu terakhir — jika bukan berbulan-bulan — untuk mengerjakan desain situs web. Anda dan rekan tim Anda melalui beberapa revisi internal serta presentasi klien, dan berupaya keras untuk menyempurnakan detail visual seperti ruang putih, gaya font, dan ukuran. (Di era responsif — tentu saja untuk beberapa ukuran layar.) Desain telah disetujui oleh klien dan diserahkan kepada pengembang. Anda merasa lega dan bahagia.
Beberapa minggu kemudian, Anda menerima email dari pengembang Anda yang mengatakan:
“Situs pementasan sudah diatur. Berikut tautannya. Bisakah Anda meminta QA? ”
Dalam sensasi antisipasi, Anda membuka tautan pementasan itu dan setelah menggulir beberapa halaman, Anda melihat bahwa situs tersebut terlihat sedikit tidak aktif. Spasi bahkan tidak mendekati apa yang disarankan desain Anda dan Anda melihat beberapa kekusutan dalam tata letak: tampilan dan warna font yang salah serta interaksi yang salah dan status hover. Kegembiraan Anda mulai perlahan memudar dan berubah menjadi perasaan frustrasi. Mau tidak mau Anda bertanya pada diri sendiri, "Bagaimana itu bisa terjadi?"
Pencarian Alasan
Mungkin ada banyak kesalahpahaman yang tidak menguntungkan dalam komunikasi antara desainer dan pengembang. Namun demikian, Anda terus bertanya pada diri sendiri:
- Seperti apa serah terima desainnya? Apakah hanya ada beberapa file PDF, Photoshop, atau Sketsa yang dibagikan melalui email dengan beberapa komentar, atau apakah ada pertemuan serah terima yang sebenarnya di mana berbagai aspek seperti kemungkinan sistem desain, tipografi, perilaku responsif, interaksi, dan animasi dibahas?
- Apakah prototipe interaktif atau gerak yang membantu memvisualisasikan interaksi tertentu ada?
- Apakah daftar aspek penting dengan tingkat prioritas yang ditentukan telah dibuat?
- Berapa banyak percakapan yang terjadi — dengan desainer dan pengembang di ruangan yang sama bersama-sama?
Karena komunikasi dan serah terima adalah dua poin kunci yang sangat penting, mari kita lihat lebih dekat masing-masing.
Komunikasi Adalah Kunci
Desainer dan pengembang, silakan berbicara satu sama lain. Banyak bicara. Semakin awal dalam proyek dan semakin sering, semakin baik. Jika memungkinkan, tinjau pekerjaan desain yang sedang berjalan bersama di awal proyek (dan secara teratur) untuk terus mengevaluasi kelayakan dan mendapatkan masukan lintas disiplin. Desainer dan pengembang secara alami sama-sama fokus pada aspek yang berbeda dari bagian yang sama dan oleh karena itu melihat sesuatu dari sudut dan perspektif yang berbeda .
Memeriksa lebih awal memungkinkan pengembang menjadi terbiasa dengan proyek sehingga mereka dapat mulai meneliti dan merencanakan ke depan tentang persyaratan teknis dan membawa ide-ide mereka tentang cara mengoptimalkan fitur. Sering check-in juga menyatukan tim pada tingkat pribadi dan sosial , dan Anda belajar cara saling mendekati untuk berkomunikasi secara efektif.
Serah Terima Dari Desain ke Pengembangan
Kecuali sebuah organisasi mengikuti alur kerja yang benar-benar gesit, serah terima awal perusahaan desain dan aset (dari tim desain ke pengembang) kemungkinan akan terjadi di beberapa titik dalam sebuah proyek. Serah terima ini — jika dilakukan secara menyeluruh — dapat menjadi landasan pengetahuan dan kesepakatan yang kokoh antara kedua belah pihak. Oleh karena itu, penting untuk tidak terburu-buru melewatinya dan merencanakan waktu ekstra.
Ajukan banyak pertanyaan dan bicarakan setiap persyaratan, halaman, komponen, fitur, interaksi, animasi, apa saja — dan buat catatan. Jika ada hal yang tidak jelas, mintalah klarifikasi . Misalnya, saat bekerja dengan tim eksternal atau berbasis kontrak, baik desainer maupun pengembang dapat menandatangani catatan yang dibuat sebagai dokumen kesepakatan bersama untuk referensi di masa mendatang.
Komps desain datar dan statis bagus untuk menampilkan aspek grafis dan tata letak situs web tetapi jelas tidak memiliki representasi interaksi dan animasi yang tepat. Meminta prototipe atau demo kerja animasi kompleks akan menciptakan visi yang lebih jelas tentang apa yang perlu dibangun untuk semua orang yang terlibat.
Saat ini, ada berbagai macam alat prototyping yang tersedia yang dapat digunakan desainer untuk aliran mockup dan interaksi di berbagai tingkat kesetiaan. Javier Cuello menjelaskan cara memilih alat prototyping yang tepat untuk proyek Anda di salah satu artikelnya yang komprehensif.
Setiap proyek adalah unik, dan begitu juga persyaratannya. Karena persyaratan ini, tidak semua fitur yang dikonsep selalu dapat dibangun. Seringkali waktu dan sumber daya yang tersedia untuk membangun sesuatu dapat menjadi faktor pembatas. Selanjutnya, kendala dapat datang dari persyaratan teknis seperti kelayakan, aksesibilitas, kinerja, kegunaan dan dukungan lintas-browser, persyaratan ekonomi seperti anggaran dan biaya lisensi atau kendala pribadi seperti tingkat keterampilan dan ketersediaan pengembang.
Lantas, bagaimana jika kendala tersebut menimbulkan konflik antara desainer dan developer?
Menemukan Kompromi Dan Membangun Pengetahuan Bersama
Agar berhasil mengirimkan proyek tepat waktu dan memenuhi semua persyaratan yang ditentukan, menemukan kompromi antara kedua disiplin ilmu sebagian besar tidak dapat dihindari. Pengembang perlu belajar berbicara dengan desainer dalam istilah non-teknis ketika mereka menjelaskan alasan mengapa sesuatu perlu diubah atau tidak dapat dibangun dalam situasi tertentu.
Alih-alih hanya mengatakan, "Maaf, kami tidak dapat membangun ini," pengembang harus mencoba memberikan penjelasan yang dapat dimengerti oleh desainer dan — dalam kasus terbaik — menyiapkan saran untuk solusi alternatif yang bekerja dalam batasan yang diketahui. Mendukung poin Anda dengan statistik, penelitian, atau artikel, dapat membantu untuk menekankan argumen Anda. Juga, jika waktu menjadi masalah, mungkin implementasi beberapa bagian yang memakan waktu dapat dipindahkan ke fase proyek selanjutnya?
Meskipun tidak selalu memungkinkan, meminta desainer dan pengembang duduk bersebelahan dapat mempersingkat putaran umpan balik dan mempermudah penyelesaian solusi yang dikompromikan. Adaptasi dan pembuatan prototipe dapat dilakukan secara langsung melalui pengkodean dan pengoptimalan dengan DevTools terbuka.
Tunjukkan pada rekan desainer Anda cara menggunakan DevTools di browser sehingga mereka dapat mengubah informasi dasar dan melihat pratinjau perubahan kecil di browser mereka (misalnya padding, margin, ukuran font, nama kelas) dengan cepat.
Jika proyek dan struktur tim memungkinkan, membangun dan membuat prototipe di browser sesegera mungkin dapat memberikan pemahaman yang lebih baik kepada semua orang yang terlibat tentang perilaku responsif dan dapat membantu menghilangkan bug dan kesalahan pada tahap awal proyek.
Semakin lama desainer dan pengembang bekerja bersama, semakin baik desainer akan memahami apa yang lebih mudah dan apa yang lebih sulit untuk dibangun oleh pengembang. Seiring waktu, mereka akhirnya dapat merujuk ke solusi yang telah berhasil untuk kedua belah pihak di masa lalu:
“Kami telah menggunakan solusi itu untuk menemukan kompromi di Proyek A. Bisakah kami menggunakannya untuk proyek ini juga?”
Ini juga membantu pengembang mendapatkan pemahaman yang lebih baik tentang detail apa yang sangat spesifik tentang desainer dan aspek visual apa yang penting bagi mereka.
Desainer Mengharapkan Frontend Terlihat (Dan Berfungsi) Seperti Desain Mereka
File Desain Vs. Perbandingan Peramban
Teknik yang berguna untuk mencegah desainer dari frustrasi adalah dengan membuat perbandingan kiri-kanan sederhana antara file desain yang Anda serahkan dan seperti apa keadaan pengembangan Anda saat ini. Ini mungkin terdengar sepele, tetapi sebagai pengembang, Anda harus mengurus begitu banyak hal yang perlu berfungsi di bawah tenda sehingga Anda mungkin melewatkan beberapa detail visual. Jika Anda melihat beberapa perbedaan yang mencolok, cukup perbaiki.
Pikirkan seperti ini: Setiap detail dalam implementasi Anda yang terlihat persis seperti yang dirancang, menghemat waktu dan sakit kepala Anda dan desainer yang berharga , dan mendorong kepercayaan. Tidak semua orang mungkin memiliki tingkat perhatian yang sama terhadap detail, tetapi untuk melatih mata Anda melihat perbedaan visual, putaran cepat Can't Unsee mungkin bisa membantu.
Ini secara nostalgia mengingatkan saya pada permainan yang dulu pernah kami mainkan bernama "Temukan". Anda harus menemukan perbedaan dengan membandingkan dua gambar yang tampaknya serupa untuk mendapatkan poin.
Namun, Anda mungkin berpikir:
"Bagaimana jika tidak ada sistem ukuran font dan jarak yang terlihat dalam desain?"
Nah, poin yang bagus! Pengalaman telah menunjukkan kepada saya bahwa dapat membantu untuk memulai percakapan dengan desainer dengan meminta klarifikasi daripada secara radikal mulai mengubah hal-hal Anda sendiri dan menciptakan kejutan yang tidak diinginkan untuk desainer nanti.
Pelajari Aturan Tipografi Dan Desain Dasar
Seperti yang dinyatakan Oliver Reichenstein dalam salah satu artikelnya, 95% informasi di web adalah bahasa tertulis. Oleh karena itu, tipografi memainkan peran penting tidak hanya dalam desain web tetapi juga dalam pengembangan. Memahami istilah dan konsep dasar tipografi dapat membantu Anda berkomunikasi lebih efektif dengan desainer, dan juga akan membuat Anda lebih fleksibel sebagai pengembang. Saya sarankan membaca artikel Oliver saat ia menguraikan pentingnya tipografi di web dan menjelaskan istilah-istilah seperti tipografi mikro dan makro .
Dalam “Panduan Referensi Untuk Tipografi Dalam Desain Web Seluler”, Suzanne Scacca secara menyeluruh mencakup terminologi tipografi seperti jenis huruf, font, ukuran, berat, kerning, memimpin dan pelacakan serta peran tipografi dalam desain web modern.
Jika Anda ingin lebih memperluas cakrawala tipografi Anda, buku Matthew Butterick "Tipografi Praktis Butterick" mungkin layak dibaca. Ini juga memberikan ringkasan aturan kunci tipografi.
Satu hal yang menurut saya sangat berguna dalam desain web responsif adalah bahwa seseorang harus menargetkan panjang garis rata-rata (karakter per baris) dari 45 hingga 90 karakter karena garis yang lebih pendek lebih nyaman dibaca daripada garis yang lebih panjang.
Haruskah Pengembang Mendesain?
Ada banyak diskusi apakah desainer harus belajar coding, dan Anda mungkin bertanya pada diri sendiri pertanyaan yang sama sebaliknya. Saya percaya bahwa seseorang hampir tidak dapat unggul dalam kedua disiplin ilmu, dan itu baik-baik saja.
Rachel Andrew dengan baik menguraikan dalam artikelnya “Bekerja Bersama: Bagaimana Desainer Dan Pengembang Dapat Berkomunikasi Untuk Membuat Proyek yang Lebih Baik” bahwa untuk berkolaborasi secara lebih efektif , kita semua perlu mempelajari sesuatu dari bahasa, keterampilan, dan prioritas rekan tim kita sehingga kita dapat menciptakan bahasa bersama dan bidang keahlian yang tumpang tindih.
Salah satu cara untuk menjadi lebih berpengetahuan di bidang desain adalah kursus online yang dikenal sebagai "Desain untuk Pengembang" yang ditawarkan oleh Sarah Drasner di mana dia berbicara tentang prinsip tata letak dasar dan teori warna — dua bidang mendasar dalam desain web.
“Semakin banyak Anda belajar di luar disiplin Anda sendiri, sebenarnya lebih baik bagi Anda [...] sebagai pengembang.”
— Sarah Drasner
Pusat Visual
Dengan berkolaborasi dengan desainer, saya belajar perbedaan antara pusat matematika dan visual. Saat kita ingin menarik perhatian pembaca ke elemen tertentu, titik fokus alami mata kita terletak sedikit di atas pusat matematika halaman.
Kita dapat menerapkan konsep ini, misalnya, untuk memposisikan modal atau segala jenis overlay. Teknik ini membantu kita mendapatkan perhatian pengguna secara alami dan membuat desain tampak lebih seimbang:
Kita Semua Dalam Ini Bersama
Dalam lingkungan agensi yang serba cepat dan tidak terlalu gesit dengan tenggat waktu yang ketat, pengembang sering diminta untuk mengimplementasikan frontend responsif yang berfungsi penuh berdasarkan mockup seluler dan desktop. Ini pasti memaksa pengembang untuk mengambil keputusan desain selama proses berlangsung. Pertanyaan seperti, “Pada lebar berapa kita akan mengurangi ukuran font headline?” atau “Kapan sebaiknya kita mengganti tata letak tiga kolom menjadi satu kolom?” mungkin timbul.
Juga, di saat yang panas, mungkin terjadi bahwa detail seperti status kesalahan, pemberitahuan, status pemuatan, modal, atau gaya dari 404 halaman jatuh begitu saja. Dalam situasi seperti itu, mudah untuk mulai menuding dan menyalahkan orang-orang yang seharusnya memikirkan hal ini sebelumnya. Idealnya, pengembang tidak boleh berada dalam situasi seperti itu, tetapi bagaimana jika itu masalahnya?
Ketika saya mendengarkan pendiri dan CEO Ueno, Haraldur Thorleifsson, berbicara di sebuah konferensi di San Francisco pada tahun 2018, dia mempresentasikan dua nilai inti mereka:
"Tidak ada di sini adalah masalah orang lain."
“Kami mengambil sampah yang tidak kami taruh.”
Bagaimana jika lebih banyak pengembang secara proaktif mulai mengolok-olok bagian yang hilang yang disebutkan di atas sebaik mungkin, dan kemudian menyempurnakan bersama dengan desainer yang duduk di sebelahnya? Situs web hidup di browser, jadi mengapa tidak menggunakannya untuk membangun dan menyempurnakan?
Sementara winging bagian yang hilang atau terlupakan mungkin tidak selalu ideal, saya telah belajar dari pengalaman masa lalu saya bahwa itu selalu membantu kami untuk bergerak maju lebih cepat dan menghilangkan kesalahan dengan cepat — sebagai sebuah tim .
Tentu saja, ini tidak berarti bahwa desainer harus dikesampingkan dalam prosesnya. Ini berarti bahwa pengembang harus mencoba dengan hormat bertemu desainer di tengah jalan dengan menunjukkan inisiatif dalam pemecahan masalah. Selain itu, saya sebagai pengembang dihargai jauh lebih oleh tim hanya karena peduli dan bertanggung jawab.
Membangun Kepercayaan Antara Desainer dan Pengembang
Memiliki hubungan yang saling percaya dan positif antara tim kreatif dan teknologi dapat sangat meningkatkan produktivitas dan hasil kerja. Jadi apa yang bisa kita, sebagai pengembang, lakukan untuk meningkatkan kepercayaan antara dua disiplin ilmu? Berikut adalah beberapa saran:
- Tunjukkan mata untuk detail .
Membangun hal-hal persis seperti yang dirancang akan menunjukkan kepada desainer bahwa Anda peduli dan memberikan senyum lebar di wajah mereka. - Berkomunikasi dengan hormat .
Kita semua adalah manusia dalam lingkungan profesional yang berjuang untuk hasil terbaik. Menunjukkan rasa hormat terhadap disiplin satu sama lain harus menjadi dasar untuk semua komunikasi. - Check in lebih awal dan teratur .
Melibatkan pengembang sejak awal dapat membantu menghilangkan kesalahan sejak dini. Melalui komunikasi yang sering, anggota tim dapat mengembangkan bahasa bersama dan pemahaman yang lebih baik tentang posisi masing-masing. - Buatlah diri Anda tersedia .
Memiliki setidaknya jendela opsional 30 menit sehari ketika desainer dapat mendiskusikan ide dengan pengembang dapat memberi desainer perasaan didukung. Ini juga memberi pengembang kesempatan untuk menjelaskan hal-hal teknis yang rumit dengan kata-kata yang dapat dipahami oleh orang yang tidak terlalu teknis dengan lebih baik.
Hasilnya: Situasi Menang-Menang
Harus menghabiskan lebih sedikit waktu di QA melalui komunikasi yang efektif dan penyerahan desain yang tepat memberi tim kreatif dan pengembang lebih banyak waktu untuk fokus pada membangun hal-hal aktual dan lebih sedikit sakit kepala. Ini pada akhirnya menciptakan suasana yang lebih baik dan membangun kepercayaan antara desainer dan pengembang. Suara pengembang frontend yang menunjukkan minat dan pengetahuan di beberapa bidang terkait desain akan lebih terdengar di rapat desain.
Berkontribusi secara proaktif untuk menemukan kompromi antara desainer dan pengembang dan pemecahan masalah sebagai pengembang dapat memberi Anda rasa kepemilikan dan keterlibatan yang lebih luas dengan keseluruhan proyek. Bahkan di industri kreatif yang berkembang pesat saat ini, tidak mudah menemukan pengembang yang — selain keahlian teknis mereka — peduli dan memperhatikan detail visual. Ini bisa menjadi kesempatan Anda untuk membantu menjembatani kesenjangan dalam tim Anda.
Sumber Daya Terkait
- “Cara Memilih Alat Prototipe yang Tepat,” Javier Cuello
- “Panduan Referensi Tipografi Dalam Desain Web Seluler,” Suzanne Scacca
- “Tipografi Praktis Butterick,” Matthew Butterick
- “Bekerja Bersama: Bagaimana Desainer dan Pengembang Dapat Berkomunikasi Untuk Membuat Proyek yang Lebih Baik,” Rachel Andrew
- “Desain Untuk Pengembang,” Sarah Drasner, Frontend Masters
- “Desain Web adalah 95% Tipografi,” Oliver Reichenstein
- "Can't Unsee," Kuis browser untuk melatih indra Anda dalam mengenali detail visual.