Ujian kebolehgunaan mempunyai reputasi yang tidak adil sebagai mahal dan perlahan. Apabila orang mendengar "penyelidikan pengguna," mereka membayangkan cermin satu hala, seorang moderator dengan papan klip, dan garis masa dua minggu. Versi ujian itu memang wujud dan ada kegunaannya — tetapi ia bukan versi yang paling diperlukan oleh kebanyakan pasukan produk pada kebanyakan masa.
Versi yang paling diperlukan oleh kebanyakan pasukan lebih ringkas: lima pengguna, prototaip Figma atau persekitaran staging, panggilan video, dan 45 minit bagi setiap sesi. Jika dilakukan dengan baik, ia mendedahkan majoriti masalah kebolehgunaan yang serius sebelum produk dilancarkan. Jika dilakukan secara konsisten — walaupun sekali setiap sprint — ia menghasilkan peningkatan kualiti produk yang terkumpul dan tidak dapat ditandingi oleh sebarang analitik selepas pelancaran.
Inilah cara menjalankannya dari awal.
Lima peserta ialah bilangan yang sesuai untuk kebanyakan ujian kebolehgunaan. Kajian Jakob Nielsen mendapati lima pengguna mendedahkan kira-kira 85% masalah kebolehgunaan, dengan pulangan yang semakin berkurangan selepas itu. Menjalankan tiga sesi dengan lima pengguna pada peringkat berbeza dalam proses reka bentuk lebih bernilai daripada satu sesi dengan lima belas pengguna.
Kriteria perekrutan lebih penting daripada bilangannya. Ujian kebolehgunaan dengan lima orang yang sepadan rapat dengan pengguna sasaran anda akan mendedahkan masalah sebenar. Ujian dengan lima belas orang yang tidak sepadan hanya menghasilkan bunyi bising. Tentukan dua atau tiga kriteria saringan — peranan, konteks penggunaan, tahap keselesaan teknikal — dan patuhinya.
Laluan perekrutan paling pantas bagi kebanyakan pasukan ialah mengirim e-mel kepada pengguna sedia ada yang telah memberi kebenaran untuk dihubungi. Tawarkan insentif yang sederhana — baucar hadiah £20 sudah memadai untuk sesi 45 minit. Usahakan menjadualkan sesi dalam minggu yang sama; semakin lama jarak antara perekrutan dengan ujian, semakin tinggi kadar tidak hadir.
Kesilapan penulisan skrip yang paling biasa ialah menulis tugas sebagai arahan: "Klik Tetapan, kemudian pergi ke Pemberitahuan, dan tukar pilihan anda kepada..." Ini memberitahu pengguna apa yang perlu dilakukan, bermakna anda menguji sama ada mereka boleh mengikut arahan, bukan sama ada antara muka itu intuitif.
Sebaliknya, tulis tugas sebagai senario: "Bayangkan anda menerima terlalu banyak pemberitahuan dan anda hanya mahu menerima makluman apabila seseorang menyebut nama anda secara terus. Tunjukkan kepada saya apa yang akan anda lakukan." Ini memberi pengguna matlamat yang realistik dan membolehkan anda memerhati cara mereka sebenarnya menavigasi — termasuk di mana mereka keliru.
Bahagian paling sukar dalam memoderatorkan ujian kebolehgunaan ialah menahan keinginan untuk membantu. Apabila pengguna keliru, setiap naluri menyuruh anda masuk campur dan menunjukkan di mana hendak mengklik. Tetapi kekeliruan itulah datanya. Pengguna yang bergelut sedang memberitahu anda ada sesuatu yang tidak kena pada antara muka — dan sebaik sahaja anda campur tangan, anda kehilangan isyarat itu.
Minta pengguna berfikir dengan lantang sepanjang sesi: "Semasa anda meneruskan, ceritakan sahaja apa yang anda lihat dan apa yang anda fikirkan." Ini menghasilkan aliran data berterusan tentang model mental mereka. Catat bukan sahaja kesilapan tetapi juga keraguan — pengguna yang berhenti tiga saat sebelum mengklik butang yang betul tetap mendedahkan masalah reka bentuk, walaupun akhirnya berjaya.
Langkah sintesis ialah tempat kebanyakan nilai dicipta — dan tempat kebanyakan pasukan mengambil jalan pintas. Nota mentah daripada lima sesi bukanlah dapatan. Ia menjadi dapatan apabila anda mengadakan taklimat balas sebagai pasukan, mengelompokkan pemerhatian mengikut tema, dan menetapkan tahap keterukan.
Adakan taklimat balas pada hari yang sama dengan sesi, semasa pemerhatian masih segar. Kelompokkan masalah kepada tiga kategori: kritikal (pengguna tidak dapat menyelesaikan tugas), sederhana (pengguna menyelesaikan tugas tetapi dengan kesukaran atau kesilapan yang ketara), dan kecil (geseran yang tidak menghalang penyelesaian). Masalah kritikal perlu dibaiki sebelum pelancaran. Masalah sederhana patut diutamakan dalam sprint seterusnya. Masalah kecil masuk ke dalam backlog.
Tulis dapatan dalam satu halaman: tiga masalah kritikal teratas, dengan bukti daripada sekurang-kurangnya dua peserta bagi setiap satu, dan satu cadangan perubahan reka bentuk bagi setiap satu. Apa-apa yang memerlukan ruang lebih daripada itu patut diletakkan dalam dokumen berasingan.