Konu Başlıkları
Yükleniyor...

Kullanılabilirlik Testi Hangi Soruyu Cevaplar, Hangisini Cevaplamaz

Kullanılabilirlik Testi mi A/B Testi mi? Doğru Soruya Doğru Yöntem

Kullanılabilirlik testinin asıl işlevi tasarımı onaylamak değil, ekipteki tartışmayı bitirmek. Ama her tartışmayı bitiremez: beş kişilik bir oturum sorunu bulur, iki tasarım arasında tercih ölçmez. Hangi sorunun hangi yöntemle cevaplandığını ayırmak, testten çıkan sonucun ne kadar güvenilir olduğunu doğrudan belirler.

Onay değil, karar mekanizması

Bir tasarım toplantısında herkesin kendi kullanım alışkanlığını genel doğru sanması olağan. Test bunu tek hamlede keser: kullanıcı ekranın karşısına oturur, kimse tahminini savunmak zorunda kalmaz. Ekip açısından asıl fayda burada, bulguların listesinde değil.

Bu yüzden oturumu ekiple birlikte izlemek, sonradan rapor dağıtmaktan çok daha işe yarar. Raporu okuyan kişi bulguyu yorumlar, hatta gerekirse yorumla eritir; oturumu izleyen kişi kullanıcının duraksadığı üç saniyeyi görür ve o üç saniye tartışılmaz.

Beş kişi ne söyler, ne söylemez

Kullanılabilirlik testi bir sorun bulma aracıdır. Az katılımcıyla çalışır, çünkü aynı engele arka arkaya çarpan iki kişi o engelin gerçek olduğunu göstermeye yeter.

Tercih ölçmek bambaşka bir iş. Beş katılımcının üçü A tasarımını seçtiğinde elinde bir bulgu yok: tek sayıda katılımcıda beraberlik zaten imkânsız, yani ‘çoğunluk A dedi’ cümlesi hangi tasarımı koyarsan koy çıkacak bir cümle. Hangisinin daha çok dönüşüm getirdiğini öğrenmek istiyorsan A/B testi kurup trafiği beklemen gerekir, oturum odasında bu sorunun cevabı yok.

Ayrım pratikte şöyle işler: ‘neden yapamıyorlar’ sorusuna kullanılabilirlik testi, ‘hangisi daha çok satıyor’ sorusuna A/B testi cevap verir. Hız ölçümü ise üçüncü bir alet. PageSpeed Insights ya da WebPageTest sayfanın kaç saniyede açıldığını söyler, kullanıcının hangi adımda vazgeçtiğini söylemez; ikisini aynı başlık altında toplayan test planları genelde hiçbirini doğru yapmaz.

Üstten gelen tuhaf isteğe ne demeli

Doğrudan itiraz işe yaramaz, tartışma zevk meselesine döner ve orada kazanan olmaz. İsteği reddetmek yerine test kuyruğuna al. Fikir gerçekten kötüyse ilk iki katılımcıda görünür, iyiyse zaten haklı çıkar ve sen bir şey kaybetmiş olmazsın.

Aynı yaklaşım kötü haber taşırken de geçerli. ‘Bu akış çalışmaz’ kişisel görüştür, ‘üç katılımcıdan ikisi kupon alanını göremedi’ bulgudur. İkincisini kimsenin sahiplenmesi gerekmez, o yüzden kimse savunmaya geçmez.

Test etmeye değmeyen şeyler

Her şeyi test etme. Düzeltmesi testten ucuz olan bir şeyi test etmek zaman kaybıdır: buton etiketi belirsizse toplantıyı uzatma, etiketi değiştir, sonra bak.

Test, geri alması pahalı kararlarda değerli. Akışın sırası, ödeme adımı, kayıt formunda zorunlu tutulan alanlar. Bir projede boş arama sonucu ekranını test ettiğimizde iki katılımcı da sorguyu düzeltmek yerine geri tuşuna bastı, aylardır kayıtlarda duran çıkış tepesinin sebebi buymuş.

Deneyim tahmin isabetini artırır ama sıfırlamaz. Kullanıcının yaptığı şey çoğu zaman tasarımcının aklına gelmeyecek kadar basit olur, sürpriz bu yüzden çıkar.