UX Araştırmalarında Doğrulama Yanlılığını Kırmak
Doğrulama yanlılığı UX araştırmasını en çok veri toplarken değil, veriyi okurken bozar. Sonucu baştan bilen bir ekip kayıtlarda da analitikte de aradığını bulur, üstelik dürüstçe bulur. Bunu engellemenin yolu daha fazla veri toplamak değil; neye bakacağını, bakmadan önce yazmak.
Yanlılık soruda değil, yorumda saklanır
Yönlendirici soru en görünür hata, bu yüzden de en kolay düzeltileni. "Bu özellikten ne kadar memnunsunuz?" yerine "bu akışı bana anlatır mısınız" demek bir eğitim meselesi, bir hafta içinde ekibe öğretilir.
Asıl sorun sonra çıkıyor. Kaydı izleyen kişi ne aradığını bilerek izliyor. Kullanıcı üç saniye duraksadığında bu duraksama, hipoteze uyuyorsa "kafası karıştı", uymuyorsa "okuyor" diye not ediliyor. Peter Wason'ın 1960'ta tarif ettiği davranışın aynısı: insanlar kuralı çürütecek örneği değil, doğrulayacak örneği seçiyor. Araştırmacının farkı, elinde ekran kaydı olması.
Analitik tarafsız değil, metriği siz seçiyorsunuz
"Nitel bulguyu nicel veriyle destekle" tavsiyesi burada yarım kalıyor. Analitik panelinde onlarca metrik duruyor ve hangisine bakılacağına karar veren şey yine hipotez. Ortalama süre hipotezi desteklemiyorsa çıkış oranına, o da tutmazsa segment kırılımına geçilir. Kimse veri uydurmaz; sadece uyan tabloda durulur.
Bunun bir de aritmetiği var. 0,05 anlamlılık eşiğiyle yirmi ayrı metriğe bakarsanız, arada gerçek hiçbir fark olmasa bile ortalama bir tanesinin "anlamlı" çıkmasını beklersiniz: 20 × 0,05 = 1. Yirmi metriğe bakıp birini raporlamak, veriye dayanmak değil, yanlılığı sayısallaştırmaktır.
Bakmadan önce yazın
Varsayım listesi yapmak işe yarar ama tek başına yetmez; varsayımı yazmak onu ortadan kaldırmaz, yalnızca denetlenebilir hale getirir. Denetim ancak şu üç şey testten önce sabitlenirse mümkün olur: hangi metriğe bakılacağı, hangi yönde değişim beklendiği, hangi fark kararı değiştirecek kadar büyük sayılacağı. Veri geldikten sonra bu listeye dokunmayın.
Bir e-ticaret projesinde ödeme adımındaki buton metnini sorun sanıp başlamıştık; kayıtlarda asıl duraklamanın kargo ücretinin ancak son ekranda görünmesinden kaynaklandığı çıktı.
Kör test her yerde mümkün değil
A/B testinde kullanıcı zaten kördür, hangi varyantı gördüğünü bilmez. Kör olmayan taraf araştırmacıdır. Dolayısıyla A/B testini "kör yöntem" diye rahatlatıcı bir kutuya koymak yanlış; orada körleştirilmesi gereken kişi analizi yapandır.
Moderatörlü kullanılabilirlik testinde durum daha kötü. Çoğu ekipte tasarımı yapan kişi kendi tasarımını modere ediyor, sonra da kendi notlarını analiz ediyor. Tam körleştirme pratikte zor, ama şu ayrım her ekipte kurulabilir: tasarımı yapan kişi ile bulguyu raporlayan kişi aynı olmasın. Bu tek kural, yöntem eğitiminden daha fazla iş görür.
Triangülasyon ancak kaynaklar bağımsızsa işe yarar
Anket, mülakat ve kullanılabilirlik testini üst üste koymak kendiliğinden güvence vermez. Üçünü de aynı hipotezle aynı kişi tasarladıysa, aynı yanlılık üç kez ölçülmüş olur ve sonuçların birbirini tutması yanlış bir güven duygusu üretir. Tutarlılık burada doğruluk kanıtı değil.
Değerli olan bağımsızlık. En güçlü kaynak da genellikle sizin sormadığınız veridir: destek talepleri, site içi arama sorguları, satış ekibine gelen itirazlar, uygulama mağazası yorumları. Bunlar sizin hipotezinizden habersiz birikir. Bir bulguyu doğrulamak istiyorsanız, dördüncü bir test kurmadan önce bu kayıtlara bakın; hipotezinizi orada göremiyorsanız, sorun muhtemelen kullanıcıda değil hipotezde.