Kullanıcı Testinde Doğrulama Yanılgısı ve Beş Kullanıcı Kuralı
Kullanıcı testini tasarımı doğrulamak için yapan ekipler, testten çıkan ilk ciddi bulguyu genellikle yöntemin hatası olarak yorumlar. Bu konudaki yaygın tavsiye kelimeyi değiştirmek yönünde: doğrulama deme, araştırma de. Kelime değişince davranışın da değiştiğinden pek emin değilim.
Sorun kelimede değil, bulgunun kime neye mal olduğunda
“Doğrulama” kelimesini yasaklamak ucuz bir müdahale, popülerliği de biraz buradan geliyor. Ama bir ekip test bulgusunu görmezden geliyorsa bunu kelime seçimi yüzünden yapmıyor. Bulgu genelde üç hafta önce onaylanmış bir akışı işaret eder; kabul etmek yeniden çizim, yeniden tahminleme ve birine tarihin kaydığını söylemek demektir.
Bulguyu ciddiye alan ekiplerde ortak olan şey sözlükleri değil, testin zamanı. Tasarım kilitlendikten sonra gelen bulgu pahalı olduğu için tartışmaya açılır, kâğıt prototip aşamasında gelen bulgu ucuz olduğu için itirazsız kabul edilir. Testi öne çekmek, terminoloji düzenlemekten çok daha fazla iş görür.
Her testin sorun bulması beklentisi de bir tuzak
Nielsen'ın sık alıntılanan uyarısı, hiç sorun bulmayan bir testin muhtemelen kötü yürütüldüğünü söyler. Yerinde bir uyarı, ama tersine çevrildiğinde kendi sorununu üretiyor: her oturumdan bulgu çıkması bekleniyorsa gözlemci bulgu üretmeye başlar.
Sonuç tanıdık. Kırk maddelik bir liste, içinde “katılımcı ikonu bir saniye geç fark etti” ile “kullanıcı ödeme adımını tamamlayamadı” yan yana duruyor. Liste uzadıkça okunmaz hale gelir ve sürümü gerçekten bloklayan iki madde, kalabalığın içinde kaybolur.
Beş kullanıcı formülü ne ölçer, ne ölçmez
Yaygın kural, beş kullanıcının sorunların yaklaşık %85'ini ortaya çıkardığını söyler. Arkasındaki model basit: bir sorunun tek bir kullanıcı tarafından fark edilme olasılığına L denir, n kullanıcıyla bulunma oranı 1-(1-L)^n olur. Ortalama L değeri %31 alındığında beş kullanıcı için 1-0,69^5, yani %84 civarı çıkar.
Modelin gizlediği iki varsayım var. Birincisi, L bütün sorunlar için aynı kabul edilir; oysa nadir ama ciddi sorunların L'si düşüktür, dolayısıyla beş kullanıcı “sorunların %85'i” değil, “kolay fark edilen sorunların %85'i” demektir. İkincisi, tek ve türdeş bir kullanıcı kitlesi varsayılır. İki ayrı segmentle çalışıyorsanız ve beş kişiyi bölüyorsanız bir tarafta iki kişi kalır; aynı formül o segment için %52 verir, yani yarısı.
Buradan çıkan pratik sonuç, beş sayısını kutsamak yerine segment sayısıyla çarpmak. Üç farklı kullanıcı tipiniz varsa beş değil on beş kişilik bir bütçe konuşuyorsunuz, ya da hangi segmentin bu turda kapsam dışı kaldığını açıkça yazıyorsunuz. (Nielsen Norman Group, Why You Only Need to Test with 5 Users)
Bulgu listesini nasıl kurmalı
Test raporunu genelde tek bir kolonla sıralarım: bu bulgu sürümü bloklar mı, bloklamaz mı. Şiddet-sıklık matrisleri kulağa daha bilimsel geliyor, ama o tabloyu toplantıda açan pek olmuyor.
İkinci kolon uygulama maliyetidir ve onu tasarımcı değil, işi yapacak kişi doldurur. “Buton etiketi değişecek” ile “adım sırası değişecek, ödeme servisiyle konuşan kod da değişecek” aynı listede eşit ağırlıkta görünmemeli. Bu iki kolonla karar toplantısı yarım saat sürer; puanlama tartışması iki saat sürer ve sonunda yine aynı iki maddeye gelinir.
Uygulanmayacak bulgular da kaydedilir, ama “sonraki sürüm” etiketiyle görünür bir yerde durur. Aynı bulgu üç test üst üste çıkıyorsa artık bulgu değil, karardır: ekip o sorunla yaşamayı seçmiştir. Bunu açıkça yazmak, listeyi her turda yeniden şişirmekten iyidir.