Kullanıcı Testinde Dört Yaygın Hata ve Tavsiyelerin Sınırı

Kullanıcı testi tavsiyeleri neredeyse ezbere döndü: net görev ver, yönlendirme yapma, araya girme, konuşma da gözlemle. Dördü de tek başına doğru. Sorun, aynı oturumda hepsini birden uygulamaya kalktığında birbirlerini kesmeleri; çoğu rehber de tam bu kesişme noktasını atlıyor.

Görev tanımında hedefi söyle, rotayı değil

Katılımcıya "bir ürün satın alın" demenin testi boşa çıkardığı doğru. Ama çare diye önerilen "falanca markanın en yeni modelini bulun ve satın alın" cümlesi ilk kuralı ikinci elle bozuyor. Markayı sen söylediğin anda kullanıcının kendi arama yolunu, filtre alışkanlığını, kategoriden mi arama kutusundan mı ilerlediğini gözlemleme şansını da harcamış oluyorsun. Görev spesifikleştikçe iyileşmiyor; sadece senin çizdiğin rotaya yaklaşıyor.

Denge, görevi kullanıcının kafasındaki ihtiyaç cümlesiyle kurmakta. "Kışın dışarıda koşarken giyeceğin bir ayakkabı arıyorsun, bütçen belli" kadarı hedefi netleştirir, yolu serbest bırakır. Bir de görevin nerede bittiğini baştan tanımla: sipariş özeti ekranı mı, ödeme onayı mı? Bitiş belirsizse başarı oranı diye yazdığın sayı senin oturum sırasındaki kararına bağlı kalır.

Yönlendirici soru: tuzak kelimede değil, biçimde

"Bu özelliği beğendiniz mi?" sorusunun kötü olduğunu herkes yazıyor. Yerine önerilen "bu adımı tamamlarken bir zorlukla karşılaştınız mı?" ise aynı hatayı iki kere yapıyor: cevabı evet ya da hayıra sıkıştırıyor, üstelik zorluk yaşandığını baştan varsayıyor. Kelime değişti, kalıp aynı kaldı.

İşe yarayan basit filtre şu: cevabı tek kelimeyle verilebilen soru, gözlemden çok anket sorusudur. "Şu an ne yapmaya çalışıyordunuz?", "Bu ekranda ne göreceğinizi bekliyordunuz?" gibi sorular kullanıcıyı kendi zihnindeki modeli anlatmaya iter. Bir de soru, cevabın içinde geçmesini istediğin ismi kendisi söylüyorsa yönlendiricidir; sepetten bahsedip "sepete nasıl gittiniz" diye sormak, kullanıcının o kelimeyi hiç aramamış olma ihtimalini kapatır.

Müdahale bir yasak değil, bir bütçe

"Hiç karışma" tavsiyesi kulağa saf geliyor ama oturumun tamamını hesaba katmıyor. İkinci adımda sekiz dakika takılan bir katılımcı, geri kalan dört görevi hiç görmeden oturumu bitirir. Sen de o gün tek bir ekran hakkında veri toplamış olursun.

Bunun yerine müdahaleyi oturumdan önce bütçele. Görev başına bir süre belirle, protokole yaz, süre dolduğunda yardım et ve yardım ettiğin saniyeyi not düş. Sonuçlarda o görev başarısız sayılır, ama kalan görevler kurtulur. Kararı oturum anında vermek, aynı testi farklı katılımcılara farklı koşullarda yaptırmak demek.

Sesli düşünme ile saf gözlem aynı oturumda yürümez

Kullanıcıdan düşündüğünü yüksek sesle söylemesini istemek zengin veri verir, bunu inkâr eden yok. Karşılığında kullanıcı yavaşlar ve davranışını anlatabilir hale getirmek için basitleştirir. Yani süre ve başarı sayıların artık ölçtüğün şeyi temsil etmez.

İkisini aynı görevde toplamaya çalışmak yerine bölmek daha temiz: metrik topladığın görevlerde sus, gerekçe aradığın görevlerde konuştur. Bir de kayıt üzerinden hemen sonra geri dönüp "burada duraksadınız, ne oluyordu?" diye sormak, anlık anlatımın bozduğu ritmi bozmadan aynı bilgiyi verir.

Notu bulguya çevirmek

Tek katılımcıda görülen takılma bir bulgu değil, bir gözlem. Aynı noktada ikinci kişi de duraksadığında bulgu olur. Notları katılımcı katılımcı değil, ekran ekran biriktirmek bu ayrımı kendiliğinden görünür kılıyor.

Ortamı da kaydın parçası say. Test oturumlarını genelde üretimdekine en yakın veriyle kurarım; boş bir demo hesabında liste ekranı üç satır gösterir, gerçek hesapta iki yüz satır olur ve sorunun tamamı o iki yüz satırda başlar. Aynı şey hız için de geçerli: yerel ağda anında açılan bir sayfa, mobil bağlantıda bekleyen kullanıcının sabrını hiç test etmez.

Bu dört hatanın derli toplu anlatımı için: Four Common User Testing Mistakes, Interaction Design Foundation.