Usability testing memiliki reputasi yang tidak pantas untuk mahal dan lambat. Ketika orang mendengar "user research," mereka membayangkan cermin satu arah, moderator dengan clipboard, dan garis waktu dua minggu. Versi pengujian itu ada dan memiliki kegunaannya — tetapi ini bukan versi yang paling dibutuhkan oleh sebagian besar tim produk sebagian besar waktu.
Versi yang paling dibutuhkan tim adalah lebih sederhana: lima pengguna, prototipe Figma atau lingkungan staging, panggilan video, dan 45 menit per sesi. Dilakukan dengan baik, ini mengungkap mayoritas masalah usability serius sebelum mereka diluncurkan. Dilakukan secara konsisten — bahkan sekali per sprint — itu menghasilkan peningkatan kualitas produk yang meningkat yang tidak dapat direplikasi oleh analitik pasca-peluncuran apa pun.
Berikut adalah cara menjalankannya dari awal.
Lima peserta adalah jumlah yang tepat untuk sebagian besar tes usability. Penelitian Jakob Nielsen menetapkan bahwa lima pengguna mengungkap sekitar 85% masalah usability, dengan hasil yang menurun setelah itu. Menjalankan tiga sesi lima pengguna pada titik berbeda dalam proses desain lebih berharga daripada satu sesi dengan lima belas.
Kriteria untuk merekrut lebih penting daripada jumlahnya. Tes usability dengan lima orang yang cocok dengan pengguna target Anda akan mengungkap masalah nyata. Tes dengan lima belas orang yang tidak cocok akan menghasilkan kebisingan. Tentukan dua atau tiga kriteria penyaringan — peran, konteks penggunaan, tingkat kenyamanan teknis — dan pertahankan mereka.
Rute perekrutan tercepat untuk sebagian besar tim adalah mengirim email kepada pengguna yang sudah ada yang telah memberikan izin kontak. Tawarkan insentif sederhana — kartu hadiah Rp 200 ribu cukup untuk sesi 45 menit. Targetkan untuk menjadwalkan sesi dalam minggu yang sama; semakin lama jarak antara perekrutan dan pengujian, semakin tinggi tingkat ketidakhadiran.
Kesalahan scripting paling umum adalah menulis tugas sebagai instruksi: "Klik Pengaturan, lalu navigasi ke Notifikasi, dan ubah preferensi Anda menjadi..." Ini memberi tahu pengguna apa yang harus dilakukan, yang berarti Anda menguji apakah mereka dapat mengikuti arahan, bukan apakah antarmuka intuitif.
Tulis tugas sebagai skenario sebagai gantinya: "Bayangkan Anda telah menerima terlalu banyak notifikasi dan Anda ingin hanya menerima peringatan ketika seseorang menyebutkan Anda secara langsung. Tunjukkan kepada saya apa yang akan Anda lakukan." Ini memberi pengguna tujuan yang realistis dan memungkinkan Anda mengamati cara mereka benar-benar bernavigasi — termasuk di mana mereka bingung.
Bagian paling sulit dari moderasi tes usability adalah menahan keinginan untuk membantu. Ketika pengguna bingung, setiap naluri mengatakan untuk terjun dan menunjukkan di mana mengklik. Tetapi kebingungan adalah data. Pengguna yang berjuang memberi tahu Anda ada yang salah dengan antarmuka — dan saat Anda campur tangan, Anda kehilangan sinyal.
Minta pengguna untuk berpikir keras sepanjang sesi: "Saat Anda pergi, cukup beritahu saya apa yang Anda lihat dan apa yang Anda pikirkan." Ini menghasilkan aliran data berkelanjutan tentang model mental mereka. Catat bukan hanya kesalahan tetapi keraguan — pengguna yang berhenti selama tiga detik sebelum mengklik tombol yang benar masih telah mengungkap masalah desain, bahkan jika mereka akhirnya berhasil.
Langkah sintesis adalah di mana sebagian besar nilai diciptakan — dan di mana sebagian besar tim memotong sudut. Catatan mentah dari lima sesi bukan temuan. Mereka menjadi temuan ketika Anda debrief sebagai tim, kelompokkan pengamatan berdasarkan tema, dan tetapkan peringkat keparahan.
Lakukan debrief pada hari yang sama dengan sesi, saat pengamatan masih segar. Kelompokkan masalah menjadi tiga bucket: kritis (pengguna tidak dapat menyelesaikan tugas), sedang (pengguna menyelesaikan tugas tetapi dengan kesulitan atau kesalahan signifikan), dan minor (gesekan yang tidak mencegah penyelesaian). Masalah kritis perlu diperbaiki sebelum peluncuran. Masalah sedang harus diprioritaskan dalam sprint berikutnya. Masalah minor masuk ke backlog.
Tulis temuan dalam satu halaman: tiga masalah kritis teratas, dengan bukti dari setidaknya dua peserta masing-masing, dan perubahan desain yang diusulkan untuk masing-masing. Apa pun yang memerlukan lebih banyak ruang daripada itu harus di dokumen terpisah.