Pengembang "Memiliki" Kode, Jadi Bukankah Desainer "Memiliki" Pengalaman?

Diterbitkan: 2022-03-10
Ringkasan cepat Kita semua pernah ke sana. Anda menghabiskan waktu berbulan-bulan untuk mengumpulkan persyaratan bisnis, mengerjakan perjalanan pengguna yang kompleks, membuat elemen antarmuka presisi, dan mengujinya pada sampel pengguna yang representatif, hanya untuk melihat produk akhir yang memiliki sedikit kemiripan dengan pengalaman yang diinginkan.

Kita semua pernah ke sana. Anda menghabiskan waktu berbulan-bulan untuk mengumpulkan persyaratan bisnis, mengerjakan perjalanan pengguna yang kompleks, membuat elemen antarmuka presisi, dan mengujinya pada sampel pengguna yang representatif, hanya untuk melihat produk akhir yang memiliki sedikit kemiripan dengan pengalaman yang diinginkan .

Mungkin Anda seharusnya lebih kuat dan bersikeras pada pendekatan yang gesit, meskipun Anda yakin bahwa organisasi itu belum siap? Mungkin Anda seharusnya melakukan pekerjaan yang lebih baik dengan portofolio pola Anda, memastikan bahwa pengembang menggunakan pustaka kode modular Anda daripada membuat lima variasi korsel yang berbeda. Atau, mungkin Anda bahkan harus duduk di sebelah tim pengembangan setiap hari, memastikan apa yang Anda rancang benar-benar terwujud.

Bacaan Lebih Lanjut tentang SmashingMag:

  • Mengapa Anda Harus Menyertakan Pengembang Anda Dalam Proses Desain
  • Kolaborasi Tim Dan Menutup Kesenjangan Efisiensi Dalam Desain Responsif
  • Desainer Dan Pengembang Bermain Bagus
  • Cara Berkomunikasi Secara Efektif Dengan Pengembang

Alih-alih, Anda ditinggalkan dengan campuran elemen UI, dengan semua kehalusan dilucuti. Tidak bisakah mereka melihat bahwa Anda bekerja selama berhari-hari untuk mendapatkan transisi yang tepat, hanya untuk mereka masukkan ke perpustakaan animasi default? Dan dari mana datangnya langkah check-out ekstra itu. Saya yakin pemasaran melemparkannya pada menit terakhir. Anda tahu integrasi akan sulit dan kompromi perlu dilakukan, tetapi kami seharusnya membuat kehidupan pengguna lebih mudah di sini, bukan tim teknologi.

Lebih banyak setelah melompat! Lanjutkan membaca di bawah ini
Ketika banyak orang terlibat dalam sebuah proyek, sangat penting untuk memastikan bahwa mereka memiliki pemahaman yang sama tentang masalah dan solusinya.
Ketika banyak orang terlibat dalam sebuah proyek, sangat penting untuk memastikan bahwa mereka memiliki pemahaman yang sama tentang masalah dan solusinya. (Kredit gambar: Web Berikutnya)

Tentu saja, ada banyak alasan bagus mengapa situs ini seperti ini. Tim yang berbeda dengan berbagai tingkat keterampilan yang bekerja pada bagian yang berbeda dari proyek, banyak perubahan menit terakhir yang memperpendek siklus pengembangan, dan sejumlah tantangan teknis. Namun, mengapa tim pengembangan tidak datang dan meminta saran Anda tentang perubahan UI mereka? Anda tidak mengacaukan kode mereka, jadi mengapa mereka harus mengubah desain Anda? Terutama ketika dampak bisnisnya bisa sangat besar! Anda sudah dekat dan akan dengan senang hati membantu jika mereka baru saja meminta.

Walaupun cerita di atas mungkin fiktif, itu adalah sentimen yang saya dengar dari seluruh penjuru dunia desain, baik internal maupun agensi. Pengalaman yang dibuat dengan hati-hati dihancurkan oleh tim pengembangan yang berat.

Pengalaman ini mengingatkan saya pada sebuah berita yang saya lihat di saluran berita lokal AS beberapa tahun lalu. Sebuah pekan raya daerah mengadakan kompetisi ketahanan di mana orang terakhir yang tersisa dengan tangan mereka di truk pikap memenangkan hadiah. Saya sering berpikir bahwa desain itu seperti permainan "sentuh truk" besar-besaran , dengan tim pengembangan selalu pergi dengan kunci di akhir kontes. Seperti kata terakhir dalam sebuah argumen, orang terakhir yang berhubungan dengan situs memegang semua kekuatan dan dapat mendikte cara kerjanya atau seperti apa tampilannya. Terutama jika mereka mengklaim bahwa pengalaman target tertentu tidak "secara teknis mungkin", yang sering merupakan singkatan dari "sangat sulit", "Saya tidak mau repot melakukannya dengan cara itu" atau "Saya pikir ada cara yang lebih baik untuk melakukannya jadi saya akan menarik kartu dev”.

Sekarang saya tahu saya bersikap tidak adil terhadap pengembang di sini dan saya tidak bermaksud demikian. Ada beberapa teknolog luar biasa berbakat di luar sana yang benar-benar peduli tentang kegunaan dan ingin melakukan yang terbaik untuk pengguna. Namun, seringkali terasa seolah-olah ada tingkat penghargaan yang asimetris antara disiplin ilmu karena keyakinan bahwa desain itu mudah dan oleh karena itu sesuatu yang setiap orang dapat memiliki pendapat, sementara pengembangan itu sulit dan hanya untuk yang diprakarsai secara khusus. Jadi sementara desainer didorong (kadang diharapkan) untuk melibatkan semua orang dalam proses desain, mereka sering tidak diberikan kemewahan yang sama.

Sejujurnya, saya tidak menyalahkan mereka. Lagi pula, saya tahu cukup pengembangan untuk menjadi berbahaya, jadi Anda akan menjadi idiot jika Anda menginginkan pendapat saya tentang struktur basis data dan kinerja kode (selain sebagian besar saya pikir kinerja adalah hal yang baik). Kemudian lagi saya cukup tahu untuk memberi tahu ketika pengembang memalsukan sesuatu dan selalu menyenangkan untuk kembali kepada mereka dengan prototipe kerja dari sesuatu yang mereka katakan tidak mungkin atau membutuhkan waktu berbulan-bulan untuk diterapkan — tetapi saya ngelantur.

Masalahnya adalah, saya pikir banyak pengembang memiliki posisi yang sama tentang desain — mereka tidak menyadarinya. Jadi ketika mereka membuat perubahan ke elemen antarmuka berdasarkan sesuatu yang mereka dengar di konferensi beberapa tahun yang lalu, mereka mungkin kurang konteks penting. Mungkin ini adalah sesuatu yang sudah Anda uji dan diskon karena kinerjanya buruk. Mungkin Anda memilih elemen ini daripada yang lain karena alasan tertentu, seperti aksesibilitas? Atau mungkin pendapat pengembang itu salah, berdasarkan bagaimana mereka mengalami web sebagai pengguna super daripada rata-rata Jo.

Sekarang mari kita luruskan sesuatu di sini. Saya tidak mengatakan bahwa pengembang tidak boleh menunjukkan minat dalam desain atau masukan ke dalam proses desain. Saya sangat percaya pada pasangan lintas fungsi dan berpikir bahwa beberapa solusi kegunaan terbaik berasal dari tim teknologi . Ada juga banyak orang berbakat di luar sana yang mencakup banyak disiplin ilmu. Namun, di beberapa titik pengalaman perlu dimiliki, dan saya tidak berpikir itu harus dimiliki oleh orang terakhir yang membuka file HTML dan "menyentuh truk".

Jadi, jika desainer yang baik menghargai keterampilan dan pengalaman yang dibawa oleh pengembang hebat, bagaimana dengan sedikit keseimbangan? Jika desainer senang pengembang "memiliki kode", mengapa tidak menunjukkan rasa hormat yang sama dan membiarkan desainer "memiliki pengalaman" ?

Komunikasi adalah kuncinya, jadi tersedia.
Semua orang punya pendapat. Namun, itu bukan alasan yang cukup baik untuk hanya menyelam dan mulai membuat perubahan. Kredit gambar: Open Source Way

Melakukan ini cukup sederhana. Jika Anda pernah menemukan diri Anda dalam situasi di mana Anda tidak yakin mengapa sesuatu dirancang dengan cara tertentu, dan berpikir itu bisa dilakukan dengan lebih baik, jangan hanya menyelam dan mulai membuat perubahan . Demikian pula, jika Anda mengalami hambatan teknis dan berpikir itu akan membuat hidup Anda lebih mudah untuk merancang sesuatu dengan cara yang berbeda, bicarakan dengan desainer Anda. Mereka mungkin baik-baik saja dengan perubahan yang Anda sarankan, atau mereka mungkin ingin pergi dan memikirkan beberapa cara lain untuk memecahkan masalah yang sama.

Bagaimanapun, kolaborasi berjalan dua arah. Jadi, jika Anda tidak ingin desainer memulai "mengoptimalkan" kode Anda di server langsung, di luar proses kontrol versi Anda, harap berhenti melakukan hal yang sama pada desain mereka.