Kullanıcı Deneyimi Testi: Hangi Yöntem Hangi Soruyu Cevaplar

Kullanıcı deneyimi testi diye tek bir şey yok. Beş kişiyle yapılan görev testi ile yüz bin oturumluk bir A/B testi aynı adla anılıyor, oysa farklı sorulara cevap veriyorlar. Yöntemi seçmeden önce cevabını aradığın sorunun ne olduğuna karar ver; bu adım atlandığında elde edilen veri doğru çıksa bile yanlış okunuyor.

Önce soru, sonra yöntem

Nitel testler "neden" sorusunu cevaplar: kullanıcı neden o butonu görmedi, neden formu yarıda bıraktı. Nicel testler "ne kadar" sorusunu cevaplar: iki tasarımdan hangisi daha fazla tamamlanma getiriyor, aradaki fark gürültü mü değil mi. Birini diğerinin yerine koyamazsın. Beş kişinin üçü bir alanı doldururken tereddüt ettiyse elinde ciddi bir tasarım sorunu var; aynı beş kişinin üçü A varyantını seçtiyse elinde hiçbir şey yok.

Beş kullanıcı neyi bulur, neyi bulmaz

Küçük grupla başlama tavsiyesi doğru, ama gerekçesi genelde eksik aktarılıyor. Nielsen Norman Group'un beş kullanıcı savunması kullanılabilirlik sorunlarının çoğunun ilk birkaç katılımcıda yüzeye çıktığına dayanır. Burada bulunan şey sorunun varlığıdır, yaygınlığı değil. Beş kişilik bir test "kullanıcıların %40'ı bu adımda düşüyor" cümlesini kurmana izin vermez; yalnızca o adımda düşmenin mümkün olduğunu ve nasıl olduğunu gösterir.

Beş kişi aynı zamanda tek bir kullanıcı profilidir. Ekranı büyüteçle kullanan biri, klavyeyle gezinen biri ya da üç bar çeken bir bağlantıdaki biri bu beşin içinde yoksa, o deneyimler hakkında hiçbir şey ölçmemiş olursun.

A/B testi küçük trafikte çalışmaz

Kaynak listelerde A/B testi, anket ve görev testiyle yan yana, "şu yöntemleri dene" sırasında geçiyor. Bu sıralama yanıltıcı, çünkü A/B testinin ön koşulu canlı ve yeterli trafik. Dönüşümü %3'ten %3,6'ya çıkaran bir iyileştirmeyi tespit etmek istiyorsan, %80 güç ve %5 anlamlılık için kabaca 16 · p(1−p) / Δ² kadar örnek gerekir: 16 × 0,03 × 0,97 / 0,006² ≈ 13.000 kullanıcı, kol başına. İki kol için 26.000. Haftada bin ziyaretçi alan bir sayfada bu test altı ayda sonuç verir, o da tasarım bu süre boyunca hiç değişmezse.

Elimde beş katılımcı varsa, o beşini görev testine ayırmayı aynı beş kişiyle iki varyantı karşılaştırmaktan açık ara güvenilir bulurum. Maliyet tarafı da aynı yöne işaret ediyor: A/B testi iki tasarım değil, iki kod yolu, bir bayrak mekanizması ve güvenilir bir ölçüm hattı demek. Prototipte bulunabilecek bir sorun için bu altyapıyı kurmak boşa emek.

Görev metni testin yarısıdır

"Ürünü sepete ekle" diye başlayan bir görev, kullanıcıya aradığın cevabı söyler ve testi bozar. Bunun yerine bağlam ver: "Bir arkadaşına doğum günü hediyesi arıyorsun, bütçen 500 lira, hediye paketi istiyorsun." Katılımcı o an kategoriyi mi kullanır, aramayı mı, filtreyi mi, işte ölçtüğün şey bu. Görevi yazarken ürünün arayüz dilinden tek kelime geçmemesi iyi bir kontroldür.

Test sırasında konuşmayı da kes. "Şuraya bakmayı denediniz mi" diye soran bir moderatör, o oturumun verisini çöpe atmış olur. Katılımcı tıkandığında on saniye bekle; tıkanmanın kendisi bulgudur.

Sonuçla ne yapılır

Her bulgu düzeltme gerektirmez. Bir katılımcının tek seferlik şaşkınlığıyla üç katılımcının aynı yerde durması farklı ağırlıktadır, ve ikisini aynı listeye yazdığında liste kullanılamaz hale gelir. Bulguları tekrar sayısına ve engelin boyutuna göre ayır: görevi tamamlamayı imkânsız kılan şey ilk sıraya, yavaşlatan şey ikinciye, rahatsız eden şey en sona.