Cara Menjalankan Kritik Desain UI

Kritik itu mudah. Sepertinya setiap orang memiliki pendapat, tetapi, seperti yang ditunjukkan oleh penulis Harlan Ellison, “Anda tidak berhak atas pendapat Anda. Anda berhak atas pendapat Anda yang terinformasi.” Namun, untuk mendapatkan informasi, membutuhkan eksplorasi. Kritik desain adalah bagian penting dari setiap eksplorasi produk.

Kritik desain — di mana pembuat mendiskusikan dan menjelaskan kreasi dengan anggota tim dan/atau klien lainnya — bukan tentang mendesak perancang atau mendorong mereka untuk membenarkan setiap keputusan yang mereka buat. Itu hanya kritik. Kritik desain yang baik dimaksudkan untuk mengeksplorasi desain , menemukan di mana ia bekerja dan di mana ia dapat ditingkatkan. Jika dilakukan dengan baik, kritik desain memungkinkan semua orang di tim merasa seolah-olah mereka telah didengar dan memungkinkan klien untuk memberikan umpan balik yang berharga.

Bacaan Lebih Lanjut tentang SmashingMag:

• Kritik Desain Web: Cara
• Menghadapi Ketakutan Anda: Mendekati Orang Untuk Penelitian
• Bagaimana Menanggapi Secara Efektif Terhadap Kritik Desain
• The Rainbow Spreadsheet: Alat Penelitian Lean UX Kolaboratif

Jika Anda adalah orang yang menjalankan kritik, mendapatkan kritik yang membangun seringkali menjadi tantangan, terutama dengan kelompok yang tidak memiliki pengalaman dengan format kritik desain. Dalam lingkungan yang gesit, Anda akan sering memiliki pembuat kode, manajer proyek, manajer produk, dan orang-orang dari disiplin ilmu lain yang duduk untuk memberikan umpan balik, dan Anda perlu tahu cara cepat membuat mereka mempercepat ekspektasi jika Anda ingin mencapai tempat dengan cepat .

Prinsip Untuk Menjalankan Kritik UI yang Hebat

Dari pengalaman saya sendiri, saya telah menemukan bahwa kritik desain untuk antarmuka pengguna (UI) perlu dilakukan di seluruh proses desain dan pengembangan produk, setidaknya setiap minggu, dan mungkin bahkan setiap hari pada waktu-waktu tertentu. Mereka menjaga desain produk tetap pada jalurnya , dan menjadi lebih kritis dalam lingkungan produk UX yang interaktif atau ramping, di mana desain melalui beberapa iterasi sebelum diterapkan. Menjalankan kritik desain UI adalah sebuah tantangan, yang mengharuskan Anda tidak hanya menjelaskan keputusan, tetapi juga mendengarkan dengan cermat ide-ide lain.

Menetapkan prinsip yang jelas — bukan “aturan” — di awal setiap kritik adalah keharusan. Tidak seperti aturan, yang bersifat dogmatis dan terasa membatasi, prinsip membantu setiap orang memahami harapan tetapi tetap memungkinkan diskusi bentuk bebas yang diperlukan.

Yang utama di antara harapan ini adalah agar semua orang setuju mengapa Anda benar-benar mengkritik apa yang Anda lihat. Jason Ulaszek merekomendasikan:

Mulailah dengan bertanya tentang tujuan atau maksud di balik desain yang Anda kritik. Mengapa kami meminta informasi ini? Harapan apa yang telah ditetapkan yang memungkinkan kita untuk memintanya? Apa yang akan kita lakukan dengannya? Jika kita dapat menjawab pertanyaan-pertanyaan itu, maka kita beralih ke pembahasan berbagai opsi untuk menginterpretasikan kebutuhan elemen dan masing-masing kelebihan dan kekurangan dari setiap opsi.

Untuk membantu Anda mematuhi pedoman ini, saya sarankan untuk mengikuti prinsip standar yang mungkin Anda terapkan pada kritik desain apa pun, baik yang melibatkan desain UI atau tidak:

• Menunjukan rasa menghargai. . Mungkin terdengar klise, tetapi jika semua orang yang mengkritik tidak menghargai pendapat dan keterampilan orang lain di meja, maka kritik itu akan dengan cepat berubah menjadi permusuhan.
• Tentukan peran. . Sebelum memulai, klarifikasi siapa yang akan mengambil peran apa selama kritik. Yang terbaik adalah mencampuradukkannya dari kritik ke kritik sehingga tidak ada yang merasa ditinggalkan, dan optimal jika ketiga peran utama adalah orang yang berbeda (tetapi itu tidak selalu praktis).
  • pembawa acara . Ini adalah orang yang bertanggung jawab untuk mempresentasikan desain dan pemikiran di baliknya. Orang ini menjawab semua pertanyaan atau mengarahkannya ke orang lain di kritik yang bisa menjawabnya.
  • moderator . Jika memungkinkan, yang terbaik adalah jika peran ini dilakukan oleh seseorang yang tidak bertanggung jawab langsung atas desain, seringkali manajer proyek atau produk. Moderator memastikan bahwa semua orang tetap pada topik dan semua orang didengar.
  • Pencatat . Orang ini berfokus pada merekam apa yang dibahas dan sangat penting untuk memastikan bahwa kesimpulan (prinsip lain, tercantum di bawah) didefinisikan dengan jelas di akhir kritik. Pencatat tidak boleh ditinggalkan dari diskusi, meskipun peran mereka mungkin condong ke arah anggota lain dari tim untuk mengklarifikasi apa yang mereka katakan.
• Nyatakan tujuan proyek dan kritik di depan. . Ingatkan semua orang dengan cepat tentang tujuan proyek dan apa yang akan dicakup oleh kritik khusus ini. Jauhkan kritik terfokus pada tugas yang ada, daripada membiarkan ruang lingkup merayap ke pertimbangan lain yang akan menggagalkan tujuan utama diskusi.
• Tinjau audiens. . Untuk menegaskan bahwa orang yang dikritik bukanlah audiens target untuk produk tersebut, ingatkan semua orang tentang siapa mereka.
• Hindari datang dengan "jawaban." Peserta akan merasakan keinginan yang kuat untuk memecahkan masalah dan memunculkan “jawaban” dalam sebuah kritik. Namun, solusi terbaik jarang muncul dalam pertemuan yang sebenarnya. Inti dari kritik adalah untuk menyelidiki masalah dan mendiskusikan berbagai solusi potensial untuk diambil dan dipertimbangkan oleh perancang.
• Setuju dengan takeaways. . Setelah semuanya dikatakan dalam kritik, pencatat perlu meninjau tugas-tugas takeaway untuk semua orang yang berpartisipasi untuk memastikan bahwa semua orang berada di halaman yang sama untuk kritik berikutnya.

Sayangnya, terlalu sering, kritik desain UI sangat fokus pada visual dan tidak cukup pada sifat desain yang interaktif, apalagi temporal. Untuk kritik desain UI, tambahkan elemen berikut:

• Mengidentifikasi media presentasi. . Seiring dengan mengidentifikasi audiens, tinjau platform dan teknologi yang digunakan untuk membuat produk. Apakah ini aplikasi iPhone? Sebuah situs? Apakah Anda menggunakan AngularJS? C#? Pastikan ini semua dipertimbangkan sehingga Anda menghindari mengusulkan solusi yang tidak akan berhasil.
• Garis besar alur proses. . Anda perlu tahu peta jalan. Untuk desain UI, itu akan menjadi alur proses untuk pengalaman pengguna. Ini mungkin datang dalam bentuk storyboard, peta perjalanan, atau cara lain untuk menggambarkan proses, tetapi semua orang harus terbiasa dengannya sebelum mempertimbangkan UI.
• Demo produknya, tetapi tunjukkan lebih dari sekadar memberi tahu. . Saya tidak bisa cukup menekankan yang satu ini: Pengalaman pengguna yang hebat memiliki lebih banyak tampilan daripada memberi tahu. Pengguna akhir perlu tahu persis bagaimana produk bekerja dengan penjelasan minimal. Demo Anda juga harus membutuhkan penjelasan sesedikit mungkin. Seperti kata pepatah, UI yang bagus seperti lelucon: Jika Anda harus menjelaskannya, itu tidak terlalu bagus.

Mengajukan Pertanyaan yang Tepat

Banyak pertanyaan dan pernyataan bertentangan dengan kerja sama yang kuat dalam kritik desain. Berikut adalah beberapa pertanyaan yang saya temukan sebagai dialog terbuka untuk menjelajahi desain dengan cara yang kolaboratif, bukan agresif, yang dapat Anda sarankan kepada tim Anda.

“Bagaimana Anda Menemukan Solusi Itu?”

Tempat yang bagus untuk memulai kritik atau percakapan apa pun adalah bertanya kepada perancang bagaimana — bukan mengapa — mereka melakukan sesuatu. Menanyakan mengapa segera menempatkan mereka pada posisi defensif, sementara bertanya bagaimana mengundang penjelajahan asal konsep tanpa perlu pembenaran.

Pertanyaan "mengapa" mendorong kita untuk mencoba membuktikan sesuatu itu "benar", daripada menjelaskannya sebagai satu kemungkinan. Menurut Aaron Morton:

"Mengapa" memunculkan sebuah cerita, penjelasan mengapa sesuatu itu benar. Jika Anda bertanya mengapa tidak ada yang berjalan seperti yang Anda inginkan, kemungkinan besar Anda akan membuat cerita, yang mungkin benar atau tidak. Ini adalah wilayah berbahaya dalam membuat Anda merasa buruk.

Alih-alih menanyakan "mengapa", pertimbangkan untuk mengajukan pertanyaan "bagaimana" untuk memperoleh cerita tentang proses penciptaan, daripada membela keberadaannya. Dari sana, Anda kemudian dapat menanyakan kemungkinan apa yang dipertimbangkan perancang sebelumnya, dan baru kemudian mengeksplorasi alternatif yang mungkin tidak mereka pertimbangkan. Tetapi dengarkan baik-baik apa yang telah dicoba oleh perancang sebelum menawarkan saran. Mereka mungkin telah mengabaikan sesuatu, tetapi jangan masuk ke percakapan dengan asumsi demikian.

“Dari Mana Anda Mendapatkan Ide Untuk Melakukannya Dengan Cara Itu?”

Thomas Edison terkenal berkata, "Jenius adalah satu persen inspirasi dan sembilan puluh sembilan persen keringat." Tapi dia sebagian besar mencuri satu persen dari Nikola Tesla. Kemudian lagi, Picasso berkata, “Artis yang baik meminjam, seniman yang hebat mencuri” (tetapi dia mungkin mencuri kalimat itu).

Ide utama dari buku presiden Pixar Animation Ed Catmull, Kreativitas, Inc adalah bahwa memiliki tim yang hebat lebih penting daripada memiliki ide yang hebat:

Mendapatkan orang yang tepat dan chemistry yang tepat lebih penting daripada mendapatkan ide yang tepat.

Kami jarang membayangkan ide dalam ruang hampa, dan memikirkan dari mana kami mendapatkan inspirasi dapat mendorong inovasi kami sendiri. Lebih baik lagi, menyatukan inspirasi kita dalam pengaturan tim dapat menelurkan ide-ide baru.

Sebuah kata peringatan: Berhati-hatilah untuk tidak terdengar menuduh atau merendahkan — yaitu menyiratkan bahwa mereka mencuri ide. Padahal, Anda ingin desainer mendorong pemahaman mereka sendiri tentang motivasi untuk ide-ide mereka dan dari mana asalnya, tanpa menekan inovasi.

“Kapan Itu Perlu Terjadi?”

Sama seperti dalam komedi, waktu adalah segalanya dalam desain temporal, dan peristiwa perlu terjadi pada waktu yang tepat dan dalam urutan yang benar. Namun, ketika kita mendesain, urutan itu tidak selalu jelas sampai kita harus duduk dan menjelaskannya.

UI yang hebat seperti cerita yang hebat, dan itu berarti Anda harus mengatur kecepatannya dengan hati-hati. Berapa banyak informasi yang cukup untuk memulai dengan formulir? Apakah Anda menampilkan data dalam konteks yang tepat untuk dipahami pengguna? Apakah ini saat yang tepat untuk mengungkapkan kesimpulannya?

Jason Kunesh, CEO Public Good, sebuah startup yang membantu organisasi nirlaba terhubung dengan orang-orang melalui berita, memberi tahu saya:

Bagi pelanggan kami, interaksi yang hebat pada saat yang tepat adalah perbedaan antara penggemar senang produk atau layanan dan kehilangan kesempatan untuk terhubung. Mengubah interaksi biasa menjadi hubungan yang langgeng bergantung pada serangkaian interaksi kecil dan positif serta pesan yang datang ketika orang siap untuk itu.

Bagian dari proses kritik harus menghilangkan kerutan dalam waktu antarmuka dengan menanyakan di setiap kesempatan apakah ini saat yang tepat untuk melakukan suatu tindakan, mengajukan pertanyaan, atau menyajikan data.

“Bisakah Kita Menggunakan Gerakan untuk Menambahkan Isyarat Visual?”

Pertanyaan ini akan mengejutkan banyak desainer yang terbiasa dengan sifat statis yang telah mendominasi desain UI selama bertahun-tahun. Namun, gerakan, animasi, dan transisi menjadi norma dalam desain pengalaman. Gerakan akan segera menjadi penting untuk dipertimbangkan dalam desain seperti warna.

Menurut pakar animasi UI Rachel Neighbors:

Dengan munculnya desain datar dan UX tersandung yang menyertainya, kami telah melihat betapa berbahayanya menghilangkan isyarat visual dari komponen situs. Animasi dapat digunakan untuk efek sebaliknya.

Gerakan atau perubahan bisa sesederhana perubahan opacity atau warna, atau lengan monyet yang membentang di halaman, atau matahari terbit saat pengguna menyelesaikan tugas. Bertanya tentang menambahkan gerakan saat ke saat dalam desain UI akan sering mendorong desainer untuk mengubah perspektif mereka dengan cara yang baik. Dorong desainer untuk berpikir di luar momen diskrit dan mendiskusikan desain tepat waktu, bukan hanya dalam ruang.

“Bagaimana Kita Bisa Membuatnya Lebih Sederhana?”

Kesederhanaan itu sulit. Sepertinya menambahkan selalu lebih mudah daripada mengambil, dan banyak UI menderita dari apa yang saya suka sebut sindrom "kepingan salju dalam badai salju": Tentu, setiap kepingan salju itu unik, tetapi Anda tidak akan pernah menyadarinya dalam badai salju. Dalam desain UI, kita terlalu sering melihat antarmuka yang penuh dengan tautan, tombol, kontrol, dan gambar. Klien akan sering berpikir bahwa mereka perlu memasukkan semua yang mungkin dibutuhkan audiens, sampai-sampai Anda tidak dapat menemukan apa pun yang benar-benar Anda butuhkan.

Saya mengajukan pertanyaan sederhana kepada Steve Krug, penulis Don't Make Me Think :

Saya pikir itu pertanyaan yang sangat berguna. Saya akan berpikir itu adalah pelajaran yang diserap semua orang sekarang, tetapi saya tahu mereka belum. Saya selalu ingin mengatakan bahwa apa pun di halaman atau layar yang bukan bagian dari solusi — untuk tujuan nyata pengguna — adalah kebisingan dan kandidat untuk dibuang ke laut.

Pada setiap langkah dalam sebuah desain, kita perlu bertanya pada diri sendiri, Bagaimana kita bisa menciptakan sesuatu yang membutuhkan lebih sedikit pemikiran namun tetap memiliki kekuatan yang sama? Dalam sebuah kritik, ini paling baik diungkapkan dengan menanyakan bagaimana membuat sesuatu menjadi lebih sederhana. Sangat penting untuk menjaga kejelasan dalam desain , tetapi melakukannya dengan lebih sedikit klik, lebih sedikit teks, dan tidak banyak bidang formulir. Turun ke minimum yang diperlukan untuk menyelesaikan pekerjaan, dan pengguna Anda akan berterima kasih.

"Apa yang terjadi selanjutnya?"

Kritik desain yang hebat memiliki banyak kesamaan dengan wawancara yang hebat: Keduanya tentang eksplorasi. Salah satu pewawancara terbesar, Studs Terkel, mengatakan:

[Wawancara] bukanlah sebuah inkuisisi; itu adalah eksplorasi, biasanya eksplorasi ke masa lalu. Jadi saya pikir pertanyaan yang paling lembut adalah yang terbaik, dan yang paling lembut adalah, "Dan apa yang terjadi kemudian?"

Menerapkan ini ke desain UI, kita selalu perlu meminta desainer untuk memikirkan apa yang terjadi selanjutnya. Pertanyaan ini mengajak mereka untuk berpikir melampaui apa yang mereka anggap sebagai akhir. Pengguna harus selalu memiliki tempat untuk dituju selanjutnya.

Salah satu tantangan terbesar untuk membayangkan UI apa pun adalah mempertimbangkan semua jalur yang mungkin, bukan hanya "jalur bahagia" yang kami inginkan untuk diambil pengguna. Apa yang terjadi setelah mereka mengklik tombol? Apa yang terjadi jika ada kesalahan? Apa yang terjadi setelah mereka mengirimkan formulir? Tanyakan apa yang terjadi selanjutnya sampai Anda mempertimbangkan setiap skenario yang mungkin, jika tidak, Anda berisiko membiarkan pengguna menggantung, yang selalu merupakan pengalaman buruk.

Jangan Hanya Bertanya untuk Menjawabnya

Saat menanyakan pertanyaan-pertanyaan ini — atau pertanyaan lain dalam hal ini — jangan tanyakan hanya agar Anda dapat menjawabnya sendiri. Sangat menjengkelkan ketika seseorang mengajukan pertanyaan kepada Anda untuk tidak mendengar jawaban Anda atau untuk memahami pemikiran Anda tetapi hanya untuk mendengar suara mereka sendiri.

Jika Anda salah satunya, segera hentikan. Ajukan semua pertanyaan Anda dengan pikiran terbuka lebar untuk jawaban yang diberikan. Kemudian, susun tanggapan Anda berdasarkan jawaban tersebut, bukan jawaban yang ingin Anda dengar.

Seperti Apa Kritik UI yang Baik?

Kritik akan sangat bervariasi tergantung pada keterampilan, tujuan dan tanggung jawab peserta. Namun, kritik yang baik selalu berfokus pada aspek-aspek tertentu dari produk dan secara menyeluruh mengeksplorasi solusi yang disajikan.

Kritik UI tidak hanya berfokus pada tampilan produk saat ini, tetapi juga pada cara kerjanya dari waktu ke waktu dan apakah ini paling sesuai dengan kebutuhan pengguna. Daripada mempertimbangkan kebutuhan pengguna, peserta akan sering bertanya-tanya mengapa sesuatu tidak dilakukan seperti yang mereka harapkan. Jason Ulaszek dari UX for Good setuju, memberi tahu saya tentang kritiknya sendiri:

Tetap objektif dalam diskusi kita dan mempertimbangkan model mental individu yang ditugaskan menggunakan desain [yaitu pengguna] sangat penting dalam cara kita mendiskusikan solusi.

Ingatlah selalu bahwa — seperti animasi berbasis sel, di mana film akhir senilai satu detik bisa memakan waktu berminggu-minggu atau berbulan-bulan untuk diproduksi — sementara kita mungkin menghabiskan berjam-jam menderita selama satu menit detail di antarmuka, itu mungkin hanya blip di radar pengguna.

Steve Krug mengatakan ini ketika saya bertanya kepadanya tentang ini:

Kami berpikir, "literatur hebat" (atau setidaknya "brosur produk"), sementara realitas pengguna jauh lebih dekat dengan "papan reklame dengan kecepatan 60 mil per jam." Sangat sulit bagi desainer UI untuk menyadari seberapa cepat orang memperbesar — ​​atau melewati — antarmuka yang telah mereka kembangkan dengan susah payah, dan betapa sedikit yang benar-benar mereka ambil.

Kritik UI yang baik melambat untuk mempertimbangkan setiap elemen, tetapi menyadari bahwa ini bukan cara pengguna akan melihat desain. Jika peserta dalam kritik Anda tidak memiliki pelatihan formal untuk berbicara langsung tentang warna, tipografi, atau desain pengalaman, mereka masih dapat mempertimbangkan faktor-faktor penting ini dalam semua desain UI:

• Konsistensi . Apakah desain dan implementasinya konsisten di seluruh produk? Ini termasuk warna, tipografi, kontrol, citra, dan elemen desain apa pun (statis atau interaktif) yang digunakan lebih dari sekali dalam antarmuka.
• Konteks . Apakah Anda secara konsisten menghormati konteks pengguna saat mereka menggunakan produk? Terus-menerus mengajukan pertanyaan ini adalah kuncinya karena Anda mungkin tidak berada dalam konteks itu, tetapi hanya mensimulasikannya, saat merancang atau menguji.
• Suara . Apakah merek dan desain memiliki suara yang jelas, konsisten, dan dapat dikenali?
• Transisi . Apakah Anda menggunakan transisi dari status ke status untuk perubahan signifikan di UI? Desain modern jauh lebih dari sekadar visual. Pertimbangkan bagaimana semua elemen antarmuka bergerak dan berubah selama interaksi pengguna.
• Kesederhanaan . Apakah desainnya sesederhana mungkin untuk menyelesaikan pekerjaan?

Menghindari Kritik Bermusuhan

Kritik dapat — dan sering kali — dilakukan dengan cara yang garang, di mana anggota tim, untuk alasan apa pun, cenderung mengkritik pekerjaan tanpa mendengarkan proses pemikiran yang masuk ke dalam penciptaannya. Mereka membawa bias mereka sendiri ke desain, daripada mempertimbangkan pengguna, dan mereka sering kali hanya mencoba menunjukkan betapa pintarnya mereka.

Anda selalu dapat mengetahui kapan kritik menjadi terlalu agresif: Perancang cenderung menjadi berduri tentang keputusan mereka, daripada menjelaskan bagaimana mereka sampai pada mereka dan mendiskusikan alternatif. Kunci untuk menghindari kritik agresif adalah dengan menetapkan prinsip-prinsip yang jelas dan mengajukan pertanyaan terbuka dan konstruktif. Ingatlah bahwa idenya adalah untuk memperkuat desain secara kolaboratif , bukan untuk memenangkan pertarungan desain.

Saya menemukan kritik agresif tidak membantu dan biasanya berbahaya. Kritik antagonis memaksa desainer ke dalam sikap defensif, mengakar mereka dalam apa yang telah mereka lakukan, daripada memberdayakan mereka untuk mengembangkannya. Desain — untuk sebagian besar — ​​intuitif dan tidak selalu mudah memenuhi syarat, apalagi terukur.

Namun, bukan berarti kritik tersebut murni tentang pendapat sang desainer; ini tentang opini desainer yang terinformasi dengan baik yang diperoleh melalui studi bertahun-tahun. Produser web Phillip Djwa dari Agentic merasa bahwa kuncinya adalah…

… berbicara dari pengalaman saya, dan tidak mencoba untuk menggeneralisasi. Misalnya, saya akan bertanya, "Saya ingin tahu apakah spanduk pembuka cukup mengomunikasikan merek?" alih-alih, "Wow, orang tidak akan pernah mengerti nilai merek apa yang kita miliki."

Kata Akhir: Kritik Bukanlah Pengujian Kegunaan

Sangat mudah untuk menipu diri sendiri dengan berpikir bahwa Anda berbicara untuk audiens, baik melalui penggunaan persona atau bias Anda sendiri. Tidak peduli berapa banyak persona yang Anda buat atau kritik yang Anda lalui, Anda bukanlah audiens Anda . Steve Krug memberi tahu saya:

Ini adalah salah satu alasan mengapa saya pikir setiap desainer harus meluangkan waktu untuk melihat orang mencoba menggunakan apa yang mereka buat (alias tes kegunaan).

Sama seperti tingkat laser versus tingkat gelembung, pengujian kegunaan lebih tepat dan akurat daripada kritik internal, tetapi juga umumnya lebih memakan waktu dan mahal. Kritik desain reguler sangat berharga untuk menjaga proyek tetap pada target tetapi tidak pernah dapat menggantikan keluar di lapangan dan pengujian dengan pengguna kehidupan nyata. Jika tidak, yang Anda lakukan hanyalah berbicara pada diri sendiri.