Kematian pada Wireframe. Langsung ke Fidelity Tinggi!

Desain UX adalah disiplin yang menarik. Untuk melakukannya dengan baik, praktisi harus berpengalaman dalam berbagai topik dan keterampilan. Untuk mempraktikkan metodologi desain yang berpusat pada pengguna dan menciptakan solusi inovatif yang mudah digunakan untuk tantangan desain produk sehari-hari, keahlian dan pemahaman praktisi UX melibatkan segalanya mulai dari gambar dasar hingga desain naratif/perjalanan hingga psikologi kognitif.

Ada berbagai macam alat yang digunakan, artefak yang dihasilkan, dan temuan yang ditemukan dalam proses desain UX/UI, dan semuanya ditangkap dalam berbagai macam dokumen atau bahkan prototipe. Artefak roti dan mentega kami yang paling dikenal adalah gambar rangka yang bagus.

Gambar rangka—biasanya kerangka desain monokrom yang dibuat untuk evaluasi cepat—sangat bagus. Mereka memungkinkan kami untuk menerjemahkan masukan dari banyak pihak yang tidak terkait ke dalam satu dokumen yang dapat ditinjau oleh semua orang. Banyak fungsi pekerjaan yang berbeda mengevaluasi gambar rangka; analis bisnis, manajer proyek, eksekutif pemasaran, semua jenis desainer dan pengembang, berbagai vendor dan penyedia layanan lainnya—bahkan audiens target saat pengujian produk. Gambar rangka memungkinkan semua orang untuk melihat bagaimana kebutuhan individu mereka akan ditangani dan memberi seluruh tim kesempatan untuk menyelesaikan semua masalah sebelum pekerjaan berat perlu dilakukan.

Ada pro dan kontra, tetapi dalam kasus tertentu, masuk akal untuk melewatkan fase wireframing sama sekali. Banyak waktu dapat dihemat dengan menangani UX dan desain visual pada tingkat kesetiaan tinggi langsung setelah penemuan atau saat mempersiapkan pembuatan prototipe. Ini akan memberi orang lain kesempatan untuk mengevaluasi fungsionalitas serta tampilan dan nuansa produk secara bersamaan, dari peserta pengujian pengguna hingga klien dan kolega.

Mari kita cari tahu mengapa wireframe terkadang bisa menjadi masalah, saat melewatkannya masuk akal, dan bagaimana mengadaptasi proses tanpa wireframe ke alur kerja.

Masalah dengan Wireframe

Baik di lingkungan air terjun atau gesit, proses desain tipikal melibatkan fase untuk penelitian, definisi, pembuatan ide, pembuatan prototipe, pengujian, dan penyebaran serta banyak titik kontak untuk ditinjau dengan pemangku kepentingan di sepanjang jalan.

Mari kita lihat proses desain untuk contoh ketika desain wireframe bisa menjadi hambatan:

Alasan 1: Klien Tidak Memahami Apa yang Mereka Lihat

Proses desain biasanya dimulai dengan beberapa jenis penelitian masalah. Riset kepustakaan, wawancara pemangku kepentingan, dan wawancara pengguna hanyalah beberapa kegiatan yang dapat dilakukan untuk mendapatkan pemahaman yang lebih dalam. Setelah penelitian, tim desain mulai mengevaluasi sejumlah ide dan konsep untuk menemukan solusi terbaik.

Ketika sebuah konsep lebih disempurnakan, tim desain akan sering berbagi serangkaian gambar rangka dengan klien selama sesi peninjauan.

Masalahnya, wireframe sangat abstrak.

Mereka menggambarkan sesuatu yang mirip dengan benda itu, tetapi bukan benda yang sebenarnya akan dibangun. Pada tahap ini, wireframe akan berisi gambar placeholder dan segala macam TK (akan datang), FPO (untuk penempatan saja), dan TBD (akan diputuskan) seperti contoh di bawah ini.

Mungkin ada detail tentang fungsionalitas, persyaratan bisnis, dan penanganan kesalahan yang akan ditunjukkan dalam daftar anotasi yang sangat banyak. Biasanya, tidak pernah ada cukup waktu untuk menyisir ini dengan sangat rinci, sehingga klien akan dibiarkan membacanya sendiri.

Selama tinjauan wireframe, kami meminta klien kami untuk fokus pada konsep yang dijelaskan dan untuk mengevaluasi apakah itu tampaknya memecahkan masalah bisnis dan pengguna atau tidak. Namun, kami masih mendapatkan pertanyaan tentang hal-hal yang, bagi kami, tampaknya tidak terkait. Klien ingin tahu apakah gambar rangka adalah "salinan akhir" atau apakah mereka dapat melihat contoh foto yang akan ditampilkan dalam gambar pahlawan—atau pertanyaan lain tentang sesuatu yang akan ditangani dalam desain visual, pembuatan prototipe ui, atau pengembangan.

Gambar rangka mungkin terlalu abstrak bagi klien dan bahkan pemangku kepentingan internal untuk dievaluasi secara efektif. Wireframes memberi tahu orang-orang bagaimana desainnya ketika selesai, tetapi mereka masih harus melakukan banyak pekerjaan secara mental untuk membuatnya menyatu di kepala mereka. Klien kami mungkin atau mungkin bukan pemikir visual, dan mungkin terlalu banyak mengharapkan mereka untuk melihat cetak biru dan membayangkan produk atau situs yang sukses.

Ada beberapa klien yang secara khusus meminta untuk meninjau desain visual beranotasi karena lebih mudah bagi mereka untuk menghubungkan titik-titik, berdiskusi dengan bijaksana, dan memberikan umpan balik yang dipertimbangkan dengan baik.

Alasan 2: Mereka Tidak Selalu Cocok untuk Pengujian Pengguna

Mudah-mudahan, beberapa pengujian pengguna telah dijadwalkan ke dalam proses desain, karena ini adalah cara yang baik untuk menguji segala sesuatu mulai dari kelayakan keseluruhan konsep hingga tingkat detail untuk ditampilkan dalam suatu transaksi.

Salah satu cara khas untuk menguji hal-hal semacam ini adalah melalui pembuatan prototipe.

Gambar rangka dapat—dan memang—berfungsi untuk pembuatan prototipe. Tim desain terbatas pada aliran pengujian dan fungsionalitas saja, dan karena tidak memiliki lapisan desain visual, gaya visual yang memengaruhi perilaku pengguna dapat dengan mudah diabaikan.

Apakah ini bijaksana? UX, visual, dan desain salin semuanya saling memengaruhi. Sulit untuk memisahkan mereka dan mengisolasi mereka di lingkungan pengujian. Mirip dengan studi ilmiah, hasil dari satu fungsi yang diuji secara terpisah tidak dapat mengontrol—atau memprediksi bagaimana—ia akan berperilaku di alam liar.

Terkadang, lebih efektif untuk menguji semua hal ini bersama-sama secara holistik.

Contoh kasus: produk atau layanan multibahasa. Bahasa mungkin memiliki tata bahasa, abjad, dan lebar karakter yang berbeda yang dapat memengaruhi keseluruhan desain.

Selain itu, karena konten salinan memengaruhi UX, terjemahan itu sendiri dapat memengaruhi UX.

Misalnya, kami memiliki tugas di mana kami diminta untuk menguji beberapa arsitektur informasi yang berbeda karena bagaimana berbagai konsep perlu dijelaskan dalam bahasa lokal. Kami tidak akan menemukan dampak pada copywriting dan terjemahan tanpa menguji salinan sebenarnya di UI.

Kami menemukan lebih banyak kata yang diperlukan untuk menjelaskan konsep serupa dalam bahasa lokal, dan bahwa kami harus mengubah ukuran dan bentuk tombol secara global untuk mengakomodasi kata-kata verbose yang diperlukan untuk bahasa tersebut. Tanpa memusatkan perhatian pada masalah teks saat menguji komponen visual aktual di UI, kami tidak akan menemukan bahwa tombol diperlukan untuk mengambil lebar penuh layar seluler, yang memengaruhi desain UX kami di masa mendatang.

Takeaway utama: Masuk akal untuk mempersiapkan UI fidelitas tinggi sejak awal, terutama untuk proyek multibahasa.

Alasan 3: Mereka Membuat Kehidupan Neraka untuk Pengembang dan QA

Apa yang pasti terjadi selama fase desain visual adalah bahwa segala sesuatu bergerak. Gambar yang ditumpuk menjadi ubin. Teks di tengah menjadi rata kiri. Ikon pemicu akordeon adalah + dan - , tetapi sekarang menjadi beberapa chevron.

Ini adalah bagian normal dari proses desain visual. Yang juga normal adalah bahwa setiap perubahan yang dibuat dalam desain visual tidak akan tercermin dalam gambar rangka karena gambar rangka telah "ditandatangani".

Ketika semua visual disetujui, saatnya untuk menyerahkan semuanya kepada pengembang. Dalam kebanyakan kasus, mereka akan menerima serangkaian gambar rangka beranotasi yang terperinci dan satu set desain visual yang indah bersama dengan panduan gaya. Sekarang terserah mereka untuk melakukan referensi silang antara kedua dokumen ini dan menghidupkan semuanya.

Ini adalah area di mana proses desain bisa benar-benar gagal. Kami memberi pengembang terlalu banyak dokumen untuk dirujuk dan menyerahkannya kepada mereka untuk menentukan bagian informasi mana yang didahulukan. Hal ini meningkatkan jumlah waktu yang diperlukan untuk panggilan dukungan dan QA, secara alami memengaruhi waktu yang diperlukan untuk membawa produk atau pembaruan ke pasar.

Mengapa tidak memberi pengembang satu dokumen akurat yang mencakup semuanya? Sebagian besar klien juga akan menghargai salinan untuk digunakan sebagai referensi lengkap untuk pekerjaan tersebut.

Solusinya: Lewati Wireframes

Jelas, ada kalanya fase gambar rangka penuh diperlukan, dan ada kalanya tidak. Bahkan ada kalanya langsung ke high-fidelity mengalahkan fase wireframe sama sekali.

Anda dapat mempertimbangkan untuk melewatkan fase wireframe jika salah satu dari ini benar:

Ada bahan referensi yang solid di tempat.

Lihatlah pekerjaan yang ada di tempat. Mungkin sudah ada referensi UI terperinci yang tersedia. Jika Anda membuat pembaruan pada situs web yang ada atau menambahkan fitur baru ke aplikasi yang sudah ada, lihat situs web dan aplikasi saat ini untuk menemukan pola dan gaya untuk digunakan kembali.

Akan lebih baik lagi jika Anda memiliki akses ke file sumber untuk pekerjaan yang ada. Beberapa fitur dan elemen mungkin hilang dalam terjemahan, sehingga untuk berbicara, selama proses pengembangan, dan Anda dapat merujuk ke file sumber untuk melihat bagaimana fitur itu seharusnya dilakukan.

Selain (atau jika tidak ada) produk atau situs yang sudah ada, periksa apakah ada panduan gaya atau pustaka pola. Klien mungkin telah membayar beberapa pekerjaan branding dan desain visual, dan sumber daya ini dapat digunakan kembali untuk proyek Anda.

Gunakan sebanyak mungkin gaya dan pola yang dapat Anda temukan sehingga keluaran fidelitas tinggi Anda akan seakurat mungkin.

Anda telah menjadwalkan banyak pembuatan prototipe dan pengujian berulang di sepanjang jalan.

Hemat upaya Anda selama berminggu-minggu membuat prototipe dan pengujian. Jika Anda mengatur dokumen Anda dengan hati-hati untuk pertama kalinya dan memanfaatkan gaya, pola, dan simbol berulang dengan cerdas, Anda dapat dengan mudah membuat pembaruan inkremental dalam fidelitas tinggi dan mempublikasikannya langsung ke alur kerja pembuatan prototipe Anda. Tidak perlu wireframing.

Sebagai nilai tambah yang besar, Anda dapat membunuh dua burung dengan satu batu. Anda bisa mendapatkan umpan balik visual dan UI di samping umpan balik UX Anda dan membuat semua perubahan ini sekaligus.

Peserta tes Anda sangat literal.

Sama seperti klien dan rekan kerja Anda yang terkadang membutuhkan contoh nyata, begitu juga dengan target audiens proyek Anda.

Satu pertunjukan baru-baru ini membuat saya merancang layar keuangan untuk audiens target yang melek huruf rendah. Pemahaman membaca bukanlah satu-satunya masalah—konsep abstrak seringkali sangat sulit untuk diatasi. Target audiens ini biasanya perlu mendiskusikan konsep keuangan dengan menggunakan contoh-contoh konkret; jika tidak, mereka tidak dapat benar-benar mengikuti percakapan.

Untuk memahami konsep keuangan, peserta tes di audiens ini perlu merasa seperti mereka benar-benar bertransaksi. Dan untuk memahami cara kerja produk, itu perlu terlihat dan terasa seperti aplikasi nyata.

Lupakan wireframe untuk audiens seperti ini! Anda akan menghabiskan banyak waktu untuk menjelaskan apa itu—dan audiens Anda tidak akan fokus pada tugas tersebut, atau bagaimana perasaan mereka tentang tugas tersebut karena mereka tidak dapat memahami penggunaan sesuatu yang begitu asing dalam kehidupan mereka.

Klien Anda memiliki waktu dan/atau anggaran yang terbatas.

Jarang ada waktu, sumber daya, dan anggaran yang semuanya menguntungkan Anda. Anda sering dapat menemukan diri Anda mencoba untuk mengurangi ruang lingkup dan harga, atau berebut untuk melihat di mana Anda dapat berhemat dan menyimpan dan tetap memberikan layanan yang hebat kepada klien Anda.

Jika Anda memiliki klien yang tidak mampu (atau yang tidak mungkin membeli) pemeriksaan UX lengkap, bolehkah saya menyarankan untuk memotong waktu wireframing? Buat beberapa secara internal jika perlu, tetapi tetap jalankan proyek untuk klien Anda. Uji desain nyata dan nyata dan minta klien Anda bereaksi terhadap pekerjaan yang sebenarnya.

Cara Membunuh Fase Wireframe

Bagian ini agak subjektif, karena akan tergantung pada alur kerja pribadi Anda dan kebutuhan spesifik klien Anda.

Karena itu, ini adalah "templat" proses yang awalnya dapat Anda coba adaptasikan dengan alur kerja Anda, dan kemudian sesuaikan saat Anda berlatih lebih banyak dengan cara ini.

Langkah 1: Mulailah dengan proses penelitian dan penemuan Anda yang biasa.

Wawancara, observasi lapangan, penelitian pustaka, analisis persaingan—apa pun yang biasa Anda lakukan (atau sudah dijadwalkan), selesaikan fase ini seperti biasa.

Langkah 2: Buat sketsa sedikit di sepanjang jalan.

Saat Anda melakukan penelitian, Anda mungkin mendapatkan beberapa ide untuk tata letak dan pola yang berguna, alur yang menarik, dan sejenisnya. Rekam ini seperti biasa. Saya suka membuat sketsa thumbnail di buku catatan saya, dengan catatan tertulis di sebelahnya. Anda mungkin lebih suka membuat sketsa di papan tulis atau mengambil tangkapan layar dari pola UI yang menarik. Apa pun yang membantu Anda mengingat ide-ide bagus, lakukanlah.

Langkah 3: Siapkan dokumen fidelitas tinggi Anda

Buka alat desain pilihan Anda dan atur dokumen Anda dengan benar. Pilih beberapa ukuran artboard dan mulailah membuat bentuk, grup, dan simbol yang dapat diulang.

Luangkan waktu untuk menyimpan palet warna merek sebagai contoh individu, membuat dan mengatur gaya tipe, dan membuat bayangan dan filter standar yang dapat Anda terapkan di semua bentuk sesuai kebutuhan.

Luangkan banyak waktu untuk mendapatkan simbol Anda dengan benar. Anda mungkin memiliki tombol yang, bergantung pada statusnya, dapat memiliki empat warna berbeda. Manfaatkan penggantian simbol—jika bisa—sehingga Anda dapat dengan mudah menerapkan warna dan label teks yang berbeda sesuai kebutuhan.

Jika ada ikon khusus yang digunakan, simpan sebagai simbol individu pada artboard persegi (atau bentuk apa pun yang sesuai). Dengan begitu, akan mudah bagi Anda untuk menskalakannya ke atas dan ke bawah sambil tetap mempertahankan jarak dan perataan yang tepat.

Langkah 4: Mulai mendesain.

Babak pertama Anda mungkin sedikit sulit karena Anda terbiasa bekerja dengan cara ini dan melihat di mana panduan gaya Anda bertahan (dan di mana tidak). Selain membuat solusi untuk pola yang belum memiliki gaya yang ditentukan, diharapkan untuk melakukan sedikit penyesuaian untuk mendapatkan semua gaya dengan benar.

Sepanjang proses ini, lakukan dengan "arahan penyalinan" yang baik atau dengan salinan asli jika Anda memilikinya. Jangan membuat judul yang mengatakan, “Judul halaman ada di sini.” Beri pemirsa gambaran tentang apa yang akan terjadi di sini jika itu nyata.

Demikian juga, jangan membuat daftar nama yang semuanya bertuliskan John Smith dengan nomor telepon 555-1212. Gunakan generator daftar acak atau plug-in untuk membuat nama dan nomor yang berbeda, atau buat kumpulan data apa pun yang perlu Anda tampilkan. Ini mungkin tampak seperti berlebihan, tetapi ini memungkinkan Anda memecahkan masalah dengan tata letak dan lebar karakter, dan membantu pemirsa Anda memahami bahwa kelima entri itu semuanya berbeda.

Langkah 5: Ketahui kapan harus berhenti mendesain.

Ada beberapa detail yang tidak boleh Anda urus saat ini karena akan memakan waktu terlalu lama. Mungkin memilih gambar yang tepat untuk dijadikan pahlawan, atau mendesain ikon khusus untuk menunjukkan status unduhan. Ini adalah beberapa kasus di mana Anda mungkin memilih untuk menggunakan gambar atau ikon placeholder dan menguji citra atau ikonografi nyata di kemudian hari.

Anda harus membuat panggilan tentang apa yang sesuai di sini, karena itu akan tergantung pada tujuan proyek, serta seberapa jauh Anda melakukannya.

Perhatikan bahwa ini mungkin bergantung pada apa yang dibutuhkan peserta uji pengguna Anda untuk mengevaluasi pekerjaan dengan benar. Untuk audiens target melek huruf rendah yang saya sebutkan di atas, tidak ada yang terlalu detail. Untuk setiap peserta, saya membuat varian prototipe dengan nama asli dan nomor telepon yang digunakan di seluruh sehingga aplikasi benar-benar terasa seperti "milik mereka". Semakin sedikit yang harus mereka asumsikan, semakin mudah bagi mereka untuk mengikuti, dan semakin baik hasil saya.

Langkah 6: Nikmati umpan balik dan hasil tes berkualitas tinggi.

Publikasikan desain Anda langsung ke alat prototyping pilihan Anda dan bawa ke lapangan untuk pengujian. Anda sekarang bisa mendapatkan umpan balik lebih dari sekedar fungsionalitas. Anda dapat mengungkap potensi masalah visual, seperti masalah dengan kontras warna atau keterbacaan, dan Anda dapat menemukan masalah dengan arah penyalinan atau terjemahan. Anda juga dapat menghilangkan perasaan positif atau negatif yang mungkin dimiliki pengguna tentang tampilan dan nuansa atau branding.

Ini semua adalah hal-hal yang Anda mungkin akan mendapatkan umpan balik ketika Anda sampai ke fase desain visual. Mengapa tidak mendapatkan semua umpan balik itu sekarang? Beberapa umpan balik pada visual dapat secara langsung memengaruhi UX, dan sebaliknya, jadi ada baiknya untuk menyelesaikan semua ini pada saat yang sama jika Anda bisa.

Membungkus

Tidak diragukan lagi ada banyak kasus di mana fase gambar rangka penuh diperlukan untuk keberhasilan proyek. Desain yang kompleks, seperti aplikasi web responsif, memerlukan fokus khusus dan terpisah pada gambar rangka. Ini akan menghemat waktu dan uang untuk menyelesaikan semua persyaratan bisnis, kasus tepi dan penanganan kesalahan pada tahap gambar rangka, daripada jika lapisan visual penuh telah dikonsep dan diterapkan.

Namun, dalam kasus yang tepat, langsung ke fidelitas tinggi dapat meningkatkan proses Anda:

• Meningkatkan umpan balik pemangku kepentingan . Klien, pengembang, desainer lain, dan peserta uji dari audiens target dapat melihat dengan tepat apa yang akan mereka dapatkan, memungkinkan mereka untuk memberikan umpan balik berkualitas lebih tinggi.
• Percepat alur kerja pembuatan prototipe Anda . Tidak hanya desain Anda yang siap untuk langsung diuji, Anda juga bisa mendapatkan umpan balik tentang beberapa hal sekaligus: UX, salinan, dan visualnya.
• Kirimkan satu dokumen ke klien dan pengembang . Hilangkan kebutuhan untuk referensi silang dan periksa berbagai dokumen untuk memahami cara kerja tombol. Ini juga merupakan cara yang bagus bagi klien Anda untuk mendiskusikan pekerjaan dengan pemangku kepentingan internal mereka untuk memberi Anda lebih banyak umpan balik.
• Hemat waktu dan uang . Dan itu selalu merupakan hal yang baik!

Berikan pendekatan ini kesempatan lain kali Anda memiliki proyek di mana Anda memiliki beberapa bahan desain yang ada untuk dirujuk, atau di mana itu akan membuat perbedaan besar bagi audiens Anda jika pekerjaan itu dalam kesetiaan rendah atau tinggi.

• • •

Bacaan lebih lanjut di Blog Desain Toptal:

• eCommerce UX – Tinjauan Praktik Terbaik (dengan Infografis)
• Pentingnya Desain yang Berpusat pada Manusia dalam Desain Produk
• Portofolio Desainer UX Terbaik – Studi Kasus dan Contoh yang Menginspirasi
• Prinsip Heuristik untuk Antarmuka Seluler
• Desain Antisipatif: Cara Membuat Pengalaman Pengguna yang Ajaib