Kullanıcı Deneyimi Testleri: Hangi Yöntem Hangi Soruya Cevap Verir

Bir tasarım tartışmasını bitirmenin iki yolu var: insanlara sormak ya da ne yaptıklarına bakmak. İkisi farklı sorulara cevap verir, çoğu ekip de yanlış olanı seçtiği için testten kullanılabilir bir şey çıkmaz. Seçim aslında göründüğünden dar, çünkü elinizdeki trafik hangi yöntemi kullanabileceğinizi büyük ölçüde baştan belirliyor.

Söylediği mi, yaptığı mı?

Yöntemleri ikiye ayırmak çoğu tartışmayı kısaltır. Tutumsal yöntemler (anket, görüşme) insanların ne düşündüğünü toplar. Davranışsal yöntemler (kullanılabilirlik oturumu, A/B testi, analitik) ne yaptığını kaydeder. Aynı kişinin iki yöntemde farklı cevap vermesi bir çelişki değil; biri niyeti, diğeri sonucu ölçüyor.

Burada en çok yanlış anlaşılan yöntem tercih testi. "Hangi tasarımı beğendiniz?" sorusu estetik tercihi ölçer, görev başarısını değil. Peki ya beğenilen tasarımda iş daha yavaş tamamlanıyorsa? Bunu tercih testi hiçbir zaman söylemez, çünkü kimseye görev verdirmiyor.

A/B testinin trafik faturası

A/B testi tavsiyelerinin neredeyse hepsi "yeterli örneklem toplayın" deyip orada duruyor. Yeterli olanın ne kadar olduğunu söylemiyor. Rakam koyalım: dönüşüm oranınız %3 ve bunu %3,6'ya çıkaran bir değişikliği, yani göreli %20'lik bir iyileşmeyi yakalamak istiyorsunuz. Alışılmış eşiklerle (%95 güven, %80 güç) varyant başına kabaca 14.000 ziyaretçi gerekir, iki varyant için 28.000.

Günde 200 ziyaretçi alan bir sayfada bu dört aydan uzun sürer. O sürede kampanya değişir, sezon döner, trafik kaynağı kayar; test başladığı sitede bitmez. Daha küçük farkları ölçmek isterseniz ihtiyaç hızla büyür, çünkü gereken örneklem farkın karesiyle ters orantılı: aradığınız farkı yarıya indirdiğinizde örneklem dörde katlanır.

Trafiği yetmeyen bir sayfada ben genelde A/B testi kurmak yerine hunideki düşüşü sunucu kayıtlarından çıkarırım. Hangi adımda kaç kişinin kaybolduğunu görmek için iki versiyonu karşılaştırmak gerekmiyor, bir haftalık kayıt yetiyor ve kaybın neredeyse hep tek bir adımda toplandığı görülüyor.

Az kişiyle çok şey

Kullanılabilirlik testi düşük trafikte de çalışır, çünkü istatistik değil gözlem üretir. Beş katılımcının sorunların büyük kısmını ortaya çıkardığı yolundaki yaygın tavsiye (Nielsen Norman Group kaynaklı) pratikte tutuyor, ama bir şartla: katılımcılar tek bir kullanıcı tipinden geliyorsa. Hem ilk kez gelen ziyaretçiye hem de her gün giren bayiye hizmet eden bir panelde beş kişi yetmez, her gruptan ayrı beş kişi gerekir. Peki ya üç farklı rolünüz varsa? O zaman "beş kişi" tavsiyesi sessizce on beşe çıkar ve bütçe hesabınız baştan yanlıştır.

Oturumun kendisinde işi bozan birkaç alışkanlık var:

• "Kolay mıydı?" diye sormak. Katılımcı nezaketen evet der. Görevi verip susmak daha çok şey söyler.
• Pilot yapmadan başlamak. Görev metninin anlaşılmadığını ilk oturumda fark ederseniz o oturumu zaten kaybettiniz.
• Takıldığı yerde yardıma koşmak. Tam da ölçmek istediğiniz an orasıdır.

Yolculuk mu, tek ekran mı?

Yolculuk odaklı tasarım moda bir başlık olduğu için çoğu yerde duvara asılan bir poster olarak kalıyor. İşe yaradığı alan dar ama gerçek: ekranların arasındaki dikişler. Kayıt sonrası giden doğrulama e-postası, ödeme sağlayıcısından hatayla dönen kullanıcının karşılaştığı boş sepet, mobilde başlayıp masaüstünde devam eden bir başvuru formu. Bunların hiçbiri tek bir ekranın kusuru değil, dolayısıyla ekran ekran yürütülen bir testte hiç görünmezler.

Ölçüt basit. Sorun iki adımın arasındaysa yolculuk haritası işe yarar; sorun tek bir ekranın içindeyse harita zaman kaybıdır.

Neyle başlamalı

Trafiğiniz A/B testi için yetmiyorsa, ki çoğu site için yetmiyor, beş kişilik bir kullanılabilirlik oturumuyla başlayın ve hipotezinizi oradan çıkarın. Yetiyorsa bile sırayı bozmayın: A/B testi hangi versiyonun kazandığını söyler, neden kazandığını söylemez. Göz izleme ise kurumsal bütçe dışında karşılığını nadiren veriyor, fare hareketinden üretilen "dikkat haritaları" da göz izleme değil tahmindir.