Usability testing adalah mengamati orang sungguhan mencoba menyelesaikan tugas sungguhan di halamanmu, lalu mencatat di mana mereka tersandung. Bayangin kamu menulis petunjuk arah ke Homestay Kabut, lalu memberikannya ke teman yang belum pernah ke Dieng, dan kamu ikut di mobilnya tanpa boleh bicara. Di belokan mana dia ragu, di situ petunjukmu kurang jelas. Kamu sendiri gak akan ragu, karena kamu sudah tahu jalannya: kamu bukan pengguna (you are not the user).
🧪 Tebakan cepat: Tim Bu Sri cuma sanggup menguji 15 orang tahun ini. Lebih baik satu tes besar dengan 15 orang, atau tiga ronde masing-masing 5 orang? Jawabannya ada di bagian "Kenapa 5 orang, dan batasnya".
Skrip tugas: skenario, bukan instruksi
Tugasnya diambil dari persona pelajaran sebelumnya (keluarga dengan anak, cemas soal pembatalan), lalu ditulis sebagai cerita yang realistis:
"Kamu dan keluargamu, 2 dewasa dan 2 anak, mau menginap 2 malam mulai Sabtu 12 Des. Pesan kamarnya, dan cari tahu apakah kamu bisa batal kalau anakmu sakit. Sambil mencoba, ceritakan apa yang kamu pikirkan."
- Tugasnya punya tujuan dan berhenti di titik yang jelas: kamar terpesan, dan pertanyaan soal batal terjawab.
- Gak ada kata dari halamannya. "Klik Pesan kamar" atau "buka aturan batal" sudah menunjukkan jalannya, jadi tesnya gak menemukan apa-apa.
- Satu kalimat terakhir meminta think-aloud: penguji menyuarakan pikirannya sambil mencoba. Jakob Nielsen (2012) menyebutnya alat usability nomor satu, karena kamu mendengar kenapa orang ragu, bukan cuma melihat bahwa dia ragu.
Selama tes, fasilitator gak membantu, gak menunjuk, dan gak menjelaskan. Kalau penguji bertanya "ini maksudnya apa?", balikkan: "Menurut Bapak apa?" Catat apa yang dilakukan dan dikatakan, kalau boleh rekam layar dan suaranya. Yang dipercaya adalah perilakunya, bukan pendapatnya ("bagus kok").
Ronde pertama: apa yang ditemukan
Lima tamu lama Bu Sri menguji halaman pesan. Lab di halaman ini memutar ulang sesi mereka satu per satu.
| Penguji | Yang dia katakan | Hasil | Masalah baru |
|---|---|---|---|
| Pak Hadi (58) | "Plusnya kecil sekali... loh, kok jadi lima orang?" | berhasil | 3 |
| Laras (31) | "Anak saya dihitung gak, ya? Terus nama saya ditanya lagi?" | berhasil | 2 |
| Yoga (24) | "Kodenya gak bisa di-paste? Ya sudah, gak jadi deh." | gagal | 1 |
| Bu Wati (45) | "Bayar di tempat, tapi DP-nya ke mana? Eh, tamunya tiga ya?" | gagal | 1 |
| Nia (27) | "Gratis batal sampai 3 hari... kalau lewat, hangus semua?" | berhasil | 0 |
Lima orang menemukan 7 masalah: berturut-turut 3, 5, 6, 7, lalu tetap 7. Nia, penguji kelima, cuma mengulang yang sudah ketemu. Masalah kedelapan, tanggal penuh yang cuma ditandai merah, baru ketahuan belakangan saat tes dengan tamu yang buta warna.
Kenapa 5 orang, dan batasnya
Jakob Nielsen dan Tom Landauer (1993) memodelkan jumlah masalah yang ditemukan n penguji sebagai N × (1 - (1 - L) pangkat n): N adalah semua masalah di desain itu, L adalah bagian yang ditemukan satu penguji. Di proyek-proyek yang mereka teliti, L rata-rata 31%.
| Penguji | 1 | 2 | 3 | 4 | 5 |
|---|---|---|---|---|---|
| Rumus, L = 31% | 31,0% | 52,4% | 67,1% | 77,3% | 84,4% |
| Ronde 1 Bu Sri (dari 8 masalah) | 37,5% | 62,5% | 75,0% | 87,5% | 87,5% |
Tiap penguji tambahan makin banyak mengulang temuan yang sama. Karena itu Nielsen (2000, "Why You Only Need to Test with 5 Users") menyarankan: daripada satu tes dengan 15 orang, buat tiga ronde dengan 5 orang, dan perbaiki desainnya di antara ronde. Jadi jawaban tebakannya: tiga ronde berisi 5 orang. Ronde kedua juga menguji perbaikannya sendiri. Itu jawaban tebakannya.
Batasnya:
- 85% itu rata-rata, bukan jaminan. Laura Faulkner (2003) menguji 60 orang lalu mengambil kelompok acak berisi 5: ada yang menemukan 99% masalah, ada yang cuma 55%. Dengan 10 orang, yang paling sial menemukan 80%; dengan 20 orang, 95%.
- 5 orang dari satu kelompok pengguna. Kalau penggunanya dua kelompok yang sangat berbeda, misalnya tamu dan Bu Sri sebagai pemilik, Nielsen menyarankan 3 sampai 4 orang per kelompok.
- Untuk mencari masalah, bukan mengukur. Angka seperti "rata-rata waktu memesan" butuh sekitar 20 orang supaya bisa dipercaya (Nielsen).
Severity rating: mana yang diperbaiki dulu
Gak semua masalah sama berat. Nielsen (1994) memberi skala 0 sampai 4: 0 bukan masalah usability, 1 kosmetik, 2 kecil, 3 besar (penting diperbaiki), 4 bencana (wajib diperbaiki sebelum rilis). Nilainya dari tiga hal: seberapa sering terjadi, seberapa besar akibatnya, dan apakah terulang terus.
| Masalah | Penguji | Severity |
|---|---|---|
| Kode dari WhatsApp gak bisa ditempel (Yoga menyerah) | 2 dari 5 | 4 |
| "Gratis batal sampai 3 hari" gak bilang apa yang terjadi setelahnya | 4 dari 5 | 3 |
| Tombol − dan + jumlah tamu terlalu kecil (Bu Wati memesan untuk 3 tamu) | 2 dari 5 | 3 |
| Bilah total menutup kolom nomor WhatsApp | 2 dari 5 | 3 |
| Gak tahu anak dihitung tamu atau gak | 2 dari 5 | 2 |
| Mengira harus bayar DP dulu | 1 dari 5 | 2 |
| Nama yang sama diketik dua kali | 2 dari 5 | 1 |
Masalah yang paling sering belum tentu paling berat: kode yang gak bisa ditempel cuma dialami 2 orang, tapi membuat satu orang gak jadi memesan.
Setelah perbaikan: ronde kedua
Tim memperbaiki keempat masalah bernilai 3 dan 4 (pelajaran WCAG membahas tiga di antaranya), dan menambah kalimat "Setelah itu dikenai biaya 1 malam." di bawah aturan batal. Lima penguji baru mencoba tugas yang sama:
- Yang berhasil naik dari 3 dari 5 jadi 5 dari 5.
- Keempat masalah terberat gak muncul lagi.
- Muncul satu masalah baru dari perbaikannya sendiri: Sinta membaca "dikenai biaya 1 malam" sebagai "bayar sekarang". Tanpa ronde kedua, masalah ini gak akan ketahuan.
Metode lain: heuristic evaluation dan A/B test
- Heuristic evaluation: tim memeriksa halaman sendiri dengan daftar prinsip, tanpa pengguna. Yang paling dikenal adalah 10 heuristic Jakob Nielsen (1994): visibility of system status, match between system and the real world, user control and freedom, consistency and standards, error prevention, recognition rather than recall, flexibility and efficiency of use, aesthetic and minimalist design, help users recognize, diagnose, and recover from errors, serta help and documentation. Murah dan cepat, tapi gak menggantikan pengguna sungguhan.
- A/B test: dua versi ditampilkan ke pengunjung sungguhan, lalu angkanya dibandingkan, misalnya berapa yang memesan dari 2.000 kunjungan. Menjawab "versi mana yang lebih banyak", gak menjawab "kenapa".
⚠️ Jebakan yang sering ketemu
- Menuntun penguji. "Klik yang hijau, Pak" membuat tesnya gak menemukan apa-apa. Beri skenario, lalu diam.
- Percaya pendapat, bukan perilaku. "Bagus kok" sambil gagal memesan berarti gagal.
- Satu tes besar sekali saja. Tiga ronde berisi 5 orang menemukan lebih banyak, dan ikut menguji perbaikannya.
- Memperbaiki menurut jumlah, bukan severity. Masalah yang dialami 2 orang bisa lebih parah dari yang dialami 4.
- Menganggap 5 orang cukup untuk segalanya. Untuk angka yang bisa dibandingkan, butuh sekitar 20; untuk kelompok pengguna berbeda, 3 sampai 4 per kelompok.
TL;DR: Usability testing mengamati orang sungguhan mengerjakan tugas sungguhan, karena kamu bukan pengguna. Skrip tugas berupa skenario dari persona (pesan untuk keluarga, cari tahu soal batal), tanpa kata dari halamannya; penguji think-aloud, fasilitator gak membantu, perilaku lebih dipercaya dari pendapat. Rumus Nielsen dan Landauer (1993): N × (1 - (1 - L) pangkat n), L rata-rata 31%, jadi 5 penguji menemukan sekitar 85% (84,4%); lebih baik tiga ronde berisi 5 orang daripada satu tes 15 orang (Nielsen 2000). Batasnya: Faulkner (2003) mencatat kelompok 5 orang menemukan 55% sampai 99%, butuh 3 sampai 4 orang per kelompok pengguna, dan sekitar 20 orang untuk pengukuran. Severity rating 0 sampai 4 (frekuensi, akibat, keterulangan) menentukan urutan perbaikan. Ronde 2 Bu Sri: berhasil 3 dari 5 jadi 5 dari 5, plus satu masalah baru dari perbaikannya. Metode lain: heuristic evaluation dengan 10 heuristic Nielsen (misalnya visibility of system status, consistency and standards, error prevention) dan A/B test.
