Usability testing punya reputasi yang tidak adil sebagai sesuatu yang mahal dan lambat. Ketika orang mendengar "riset pengguna", mereka membayangkan cermin satu arah, moderator dengan papan klip, dan jadwal dua minggu. Versi pengujian seperti itu memang ada dan punya manfaatnya — tetapi itu bukan versi yang paling dibutuhkan sebagian besar tim produk di sebagian besar waktu.
Versi yang paling dibutuhkan kebanyakan tim lebih sederhana: lima pengguna, prototipe Figma atau lingkungan staging, panggilan video, dan 45 menit per sesi. Jika dijalankan dengan baik, cara ini mengungkap sebagian besar masalah usability serius sebelum produk dirilis. Jika dijalankan secara konsisten — bahkan sekali per sprint — hasilnya adalah peningkatan kualitas produk yang terus berlipat, yang tidak bisa ditandingi analitik pasca-peluncuran mana pun.
Berikut cara menjalankannya dari nol.
Lima peserta adalah jumlah yang tepat untuk sebagian besar usability test. Riset Jakob Nielsen menunjukkan bahwa lima pengguna mengungkap sekitar 85% masalah usability, dengan manfaat tambahan yang kian berkurang setelahnya. Menjalankan tiga sesi dengan lima pengguna di tahap berbeda dalam proses desain lebih berharga daripada satu sesi dengan lima belas pengguna.
Kriteria perekrutan lebih penting daripada jumlahnya. Usability test dengan lima orang yang sangat mirip pengguna target Anda akan mengungkap masalah nyata. Tes dengan lima belas orang yang tidak sesuai hanya akan menghasilkan noise. Tetapkan dua atau tiga kriteria penyaringan — peran, konteks penggunaan, tingkat kenyamanan dengan teknologi — dan patuhi kriteria itu.
Cara perekrutan tercepat bagi sebagian besar tim adalah mengirim email ke pengguna yang sudah ada dan telah memberi izin untuk dihubungi. Tawarkan insentif yang wajar — kartu hadiah £20 sudah cukup untuk sesi 45 menit. Usahakan menjadwalkan sesi dalam minggu yang sama; semakin lama jeda antara perekrutan dan pengujian, semakin tinggi tingkat peserta yang tidak hadir.
Kesalahan paling umum dalam menyusun naskah adalah menulis tugas sebagai instruksi: "Klik Pengaturan, lalu buka Notifikasi, dan ubah preferensi Anda menjadi..." Ini memberi tahu pengguna apa yang harus dilakukan, artinya Anda menguji apakah mereka bisa mengikuti arahan, bukan apakah antarmukanya intuitif.
Tulislah tugas sebagai skenario: "Bayangkan Anda terlalu banyak menerima notifikasi dan hanya ingin diberi tahu ketika seseorang menyebut Anda secara langsung. Tunjukkan kepada saya apa yang akan Anda lakukan." Cara ini memberi pengguna tujuan yang realistis dan memungkinkan Anda mengamati bagaimana mereka benar-benar bernavigasi — termasuk di titik mana mereka bingung.
Bagian tersulit dari memoderasi usability test adalah menahan dorongan untuk membantu. Ketika pengguna bingung, setiap naluri menyuruh Anda langsung turun tangan dan menunjukkan di mana harus mengeklik. Padahal kebingungan itulah datanya. Pengguna yang kesulitan sedang memberi tahu Anda bahwa ada yang salah pada antarmukanya — dan begitu Anda campur tangan, sinyal itu hilang.
Minta pengguna berpikir keras sepanjang sesi: "Sambil jalan, ceritakan saja apa yang Anda lihat dan apa yang Anda pikirkan." Ini menghasilkan aliran data yang terus-menerus tentang model mental mereka. Catat bukan hanya kesalahan, tetapi juga keraguan — pengguna yang berhenti tiga detik sebelum mengeklik tombol yang benar tetap telah mengungkap masalah desain, meskipun akhirnya ia berhasil.
Langkah sintesis adalah tempat sebagian besar nilai tercipta — dan tempat kebanyakan tim mengambil jalan pintas. Catatan mentah dari lima sesi bukanlah temuan. Catatan itu baru menjadi temuan setelah Anda melakukan debrief bersama tim, mengelompokkan pengamatan berdasarkan tema, dan menetapkan tingkat keparahan.
Lakukan debrief pada hari yang sama dengan sesi, selagi pengamatan masih segar. Kelompokkan masalah ke dalam tiga kategori: kritis (pengguna tidak bisa menyelesaikan tugas), sedang (pengguna menyelesaikan tugas tetapi dengan kesulitan atau kesalahan yang berarti), dan ringan (hambatan kecil yang tidak menghalangi penyelesaian). Masalah kritis harus diperbaiki sebelum peluncuran. Masalah sedang sebaiknya diprioritaskan di sprint berikutnya. Masalah ringan masuk ke backlog.
Tuliskan temuan dalam satu halaman: tiga masalah kritis teratas, masing-masing dengan bukti dari sedikitnya dua peserta, serta usulan perubahan desain untuk masing-masing. Apa pun yang membutuhkan ruang lebih dari itu sebaiknya ditaruh di dokumen terpisah.