Kullanıcı Testi Neden Gerekli ve Kaç Kişiyle Yapılır?
Kullanıcı testi, ürünün nasıl kullanılacağına dair tahminleri gerçek davranışla değiştirir. Tasarım ekibinin apaçık bulduğu akış, testte çoğu zaman daha ilk katılımcıda tıkanır ve bunu ancak birinin denemesini izleyerek görürsünüz. Asıl mesele test yapıp yapmamak değil: kaç kişiyle ve neyi ölçmek için yapıldığı.
Test, varsayımın çöktüğü yeri gösterir
Ekip bir arayüzü aylarca kurar, her ekranı yüzlerce kez görür ve sonunda akışı ezberler. Ezberlenen akış kolay görünür. Kullanıcı testinin yaptığı iş bu ezberi bozmaktır: ürünü ilk kez gören biri sizin hiç düşünmediğiniz yerden başlar, beklemediğiniz düğmeye basar, tıkanır.
Somut hali şöyle. Bir e-ticaret sitesinde sepete ekleme oranı iyiyken ödeme adımında düşüş varsa, analitik size düşüşün nerede olduğunu söyler, nedenini söylemez. Beş kişiye “şu ürünü kartla satın al” dediğinizde üçünün de aynı noktada durup fatura adresi alanını aradığını görürsünüz. Sebep on dakikada ortaya çıkar.
Beş kullanıcı sayısı nereden geliyor
Nielsen Norman Group'un çok alıntılanan kuralı bir formüle dayanır: n kullanıcıyla bulunan sorun oranı 1-(1-L)^n. Buradaki L, tek bir kullanıcının ortalamada keşfettiği sorun yüzdesi ve ölçümlerde yaklaşık 0,31 çıkıyor. Bu değerle beş kullanıcı sorunların yaklaşık %84'ünü, on beş kullanıcı neredeyse tamamını ortaya çıkarır.
Kuralın asıl söylediği şey sayı değil, sayının nasıl bölüneceği. On beş kişiyi tek turda harcamak yerine beşerli üç tur yapmak daha çok iş görür, çünkü ilk turda bulduğunuz sorunları düzeltip ikinci turu düzeltilmiş ürünle yaparsınız. Aynı hatayı on beş kez doğrulamanın kimseye faydası yok.
Sınırı da net. Beş kişi sorun bulmak için yeterlidir, ölçmek için değil. “Görev tamamlama oranımız %72” gibi bir sayı üretecekseniz güven aralığının bir anlamı olsun diye 20 civarı katılımcı gerekir. Ayrıca birbirinden gerçekten farklı iki kullanıcı grubunuz varsa, diyelim yönetici panelini kullananlar ve son müşteriler, beş sayısı her grup için ayrı geçerlidir. Toplamda beş değil.
Testin karşılığını verdiği yerler
Faydaları uzun listeler halinde saymanın anlamı yok, çoğu aynı şeyin farklı adı. Birbirinden gerçekten ayrı olan dördü şunlar:
- Sorunu geliştirme sırasında bulmak, canlıya çıktıktan sonra bulmaktan kat kat ucuz. Aynı düzeltme tasarım aşamasında bir saat sürer, yayından sonra bir sprint yer.
- Hangi özelliğin çöp olduğunu görürsünüz. Kimsenin dokunmadığı ekranı silmek, çoğu zaman yeni özellik eklemekten daha çok değer üretir.
- Erişilebilirlik ancak gerçek kullanımla anlaşılır. Klavyeyle gezen ya da ekran okuyucu kullanan bir katılımcı, otomatik denetim aracının temiz raporladığı sayfada dakikalarca kaybolabilir.
- Geri bildirim ekibin dışından gelir. Arayüzü yapan kişi kendi arayüzünü tarafsız değerlendiremez.
Doğal ortam mı, laboratuvar mı
Bu ikisi eşit ağırlıkta seçenek değil. Varsayılan doğal ortam olmalı: katılımcı kendi cihazında, kendi bağlantısıyla, kendi masasında çalışsın. Ekran paylaşımıyla uzaktan yürütülen bir oturum, laboratuvarın verdiği gözlemin büyük kısmını zaten veriyor ve kurulum maliyeti neredeyse sıfır.
Laboratuvarın gerekçesi iki durumla sınırlı: göz takibi gibi özel donanım gerekiyorsa, ya da test edilen ürün henüz duyurulmamışsa ve kaydın kontrollü ortamda kalması gerekiyorsa. Bunun dışında kontrollü oda katılımcıyı gözlem altında olduğunu bilen birine dönüştürür ve davranışını bozar.
Kullanılabilirlik testi bir SEO ölçümü değil
Kullanılabilirlik testini hemen çıkma oranı ya da sayfada kalma süresiyle aynı tabloya koymam. Beş kişilik bir oturum istatistik üretmez, hemen çıkma oranı ise binlerce ziyaretin toplamıdır. Aynı ölçekte olmayan iki şey.
Aradaki ilişki dolaylı ve tek yönlü. Testte gördüğünüz navigasyon sorununu düzeltirseniz zamanla analitikteki sayılar da düzelir. Ters yönde işlemez: analitik size sorunun adresini verir, teşhisini vermez. Testi arama motoru sıralaması yükselsin diye yapmak, ateşi düşürmek için termometre okumaya benzer.
Kaynaklar