UX Araştırma Yöntemi Seçimi: Hangi Soru Hangi Yöntemi Gerektirir

Araştırma yöntemlerini ezberlemek kimseyi iyi bir araştırmacı yapmıyor. Yöntem seçimi, elindeki sorunun türüne bağlı bir karardır ve yanlış eşleştirme yapıldığında ortaya çıkan şey veri değil, veriye benzeyen bir güven duygusudur. Aşağıdaki ayrım, hangi yöntemin hangi soruyu cevapladığını netleştirmek için.

Söylenen ile yapılan ayrı veridir

Yöntemleri sıralamanın en kullanışlı yolu iki eksene bakmak: kullanıcının ne söylediğini mi yoksa ne yaptığını mı ölçüyorsun, ve sonuç sayı mı yoksa gözlem mi. Nielsen Norman Group'un yaygın kullanılan yöntem haritası da bu iki ekseni kullanır.

Bu ayrım akademik bir zarafet değil, doğrudan bir uyarıdır: anket ve röportaj tutum ölçer, davranış ölçmez. Kullanıcı bir formu neden yarıda bıraktığını hatırlamaz, sonradan makul bir açıklama üretir. Terk sebebini gerçekten öğrenmek istiyorsan kaydı izlemek, ankete on soru daha eklemekten fazlasını verir.

Odak grubu bu yüzden kullanılabilirlik sorunu aramak için zayıf bir araçtır. Grup içinde ilk konuşanın çerçevesi diğerlerini bağlar, sessiz katılımcı çoğunluğa uyar ve elde ettiğin şey altı kişinin ortak fikri değil, bir kişinin fikrinin altı katıdır. Konsept aşamasında dil ve algı yoklamak için işe yarar, arayüz doğrulamak için yaramaz.

Nicel yöntemin söylenmeyen şartı: örneklem

A/B testi rehberlerde en çok tavsiye edilen yöntem, çünkü kulağa nesnel geliyor. Nesnelliğin bir bedeli var ve bu bedel trafikle ödeniyor.

Kaba bir hesap yeterli. Dönüşüm oranı yüzde 3 olan bir sayfada, yüzde 20'lik göreli bir iyileşmeyi (yani 3'ten 3,6'ya) yüzde 95 anlamlılık ve yüzde 80 güçle yakalamak istiyorsan varyant başına on üç bin civarında ziyaretçiye ihtiyacın olur. İki varyant için yaklaşık yirmi altı bin. Aylık beş bin ziyaretçisi olan bir sitede bu tek bir test için beş ayı aşar; o sürede sezon değişir, kampanya girer, trafik kaynağı kayar. Testin ölçtüğü şey artık düğmenin rengi değildir.

Sonuç net: düşük trafikte A/B testi öneren tavsiye ters çalışır. Aynı beş ayı sekiz kullanıcıyla yapılacak moderasyonlu testlere ayırırsan çok daha fazla şey öğrenirsin. A/B testini trafiğin taşıdığı yerde, tek ve küçük bir değişikliği doğrulamak için kullan. Aynı anda üç şeyi değiştirip sonucun hangisinden geldiğini merak etmek, testi yapmamakla aynı kapıya çıkar.

Az kullanıcıyla çok şey bulmanın sınırı

Kullanılabilirlik sorunlarının büyük kısmının beş kullanıcıyla ortaya çıktığı bulgusu doğru, ama iki varsayımı var ve ikisi de sıkça atlanıyor.

Birincisi tek bir kullanıcı grubu varsayar. Ürününü hem son kullanıcı hem de yönetici paneli üzerinden bayi kullanıyorsa bunlar farklı zihinsel modellere sahip iki gruptur; beş kişilik kural her grup için ayrı ayrı işler, yani maliyet segment sayısıyla çarpılır. İkincisi, bulmakla önceliklendirmeyi karıştırma: beş kullanıcı sana sorun listesini verir, o sorunların hangisinin kaç kişiyi etkilediğini vermez. Sıralama için analitik veriye ya da daha geniş bir örnekleme dönmen gerekir.

Test sırasında katılımcıya yüksek sesle düşündürmek ucuz ve etkilidir, ancak konuşma görevi yavaşlatır. Tamamlanma süresini metrik olarak topluyorsan düşünce sesli olduğunda süre karşılaştırılabilir olmaktan çıkar. Süre ölçeceksen sessiz test yap, sorunu anlayacaksan konuştur.

Bilgi mimarisi için iki ayrı soru

Kart sıralama ile tree testing sık sık aynı şeymiş gibi anılıyor. Farklı sorulara cevap verirler ve sırayla kullanıldıklarında değerlidirler.

Kart sıralama üretici bir yöntemdir: kullanıcılar içerikleri kendi anladıkları gibi gruplar, sen de kategori adlarını buradan çıkarırsın. Tree testing ise doğrulayıcıdır: kurduğun menü yapısında, görselsiz bir metin ağacı üzerinde kullanıcı hedefe ulaşabiliyor mu? Yapıyı kurmadan doğrulama, doğrulamadan da yayına alma.

Kart sıralamanın pratikte gözden kaçan bir maliyeti var: kart sayısı arttıkça katılımcının işi hızla ağırlaşır ve veri kalitesi düşer. Elli kartın üzerine çıkıyorsan setı bölmek, tek oturumda hepsini sıralatmaktan daha güvenilir sonuç verir.

Soruyu yönteme bağlamak

Yöntem seçimini kısaltmanın yolu, önce soruyu tek cümleyle yazmaktır. Soru netse yöntem çoğu zaman kendini söyler:

• Kullanıcılar bu ekranda takılıyor mu, nerede? Moderasyonlu kullanılabilirlik testi.
• İki tasarımdan hangisi daha çok dönüşüm getiriyor? Yeterli trafik varsa A/B testi.
• Menü isimleri anlaşılıyor mu? Tree testing.
• İnsanlar bu ürünü hangi bağlamda, hangi başka araçlarla birlikte kullanıyor? Saha gözlemi ya da günlük çalışması.
• Kaç kişi bu adımda düşüyor? Analitik, huni raporu.

Göz takibi bu listede bilerek yok. Donanım ve analiz maliyetiyle getirdiği bilgi çoğu ekip için orantısız kalıyor (pazarlama sunumlarındaki ısı haritalarının çekiciliği bu dengeyi biraz bozuyor). Dikkatin nereye gittiğini merak ediyorsan, ilk adımda tıklama ve kaydırma verisi ile beş kişilik bir test aynı kararı çoğunlukla verdirir.

Bir de her yöntemin ortak şartı var: bulguyu tasarım değişikliğine çeviremiyorsan araştırma yapılmamıştır, rapor yazılmıştır. Test kaydını izleyen kişi ile arayüzü değiştirecek kişi aynı toplantıda değilse bulgular arada kaybolur.