UX Bilgi Testleri Neyi Ölçer, Neyi Ölçmez

UX bilgi testleri terminoloji sorar: F-modeli nedir, between-subjects neye denir, SUS kaç maddeden oluşur. Bu soruların hepsini doğru bilen biri, elindeki ekranda hangi adımın neden terk edildiğini hâlâ göremeyebilir. Testin işe yarayan tarafı skorun kendisi değil, yanlışların hangi kavramın etrafında kümelendiğini göstermesi.

Skor bir yetkinlik ölçüsü değil

Bilgi testi, tanıma sorusudur. Şıklardan doğru olanı seçmek, o kavramı sıfırdan bir arayüz kararına çevirebilmekle aynı şey değil. Bilişsel yükün ne demek olduğunu bilen bir tasarımcı, formu yine on dört alanla teslim edebilir; çünkü orada karar veren şey bilgi değil, pazarlamanın istediği alanlara hayır diyebilme durumu.

Yine de testi tamamen çöpe atmak gerekmez. Bir ekipte on kişi aynı soruyu yanlış cevaplıyorsa, o kavramın ekipteki ortak dilde eksik olduğunu öğrenmiş olursun. Testin değeri bireysel skorda değil, dağılımda.

En sık sorulan konular, bir de gerçekte söyledikleri

Otorite ilkesi

İnsanların otorite işaretlerine uyma eğilimi gösterdiği doğru, ama bundan çıkan tavsiye çoğu yerde yanlış uygulanıyor. Sayfanın altına altı tane güvenlik rozeti dizmek otorite üretmiyor; sadece görsel gürültü üretiyor. Ayırt edici ölçüt basit: rozet tıklanabiliyor ve tıklayınca üçüncü taraf bir doğrulama sayfasına gidiyorsa işlevi var, gitmiyorsa bir görselden ibaret. Kullanıcı bunu bilinçli olarak test etmese bile, doğrulanabilir olan işaret ile dekoratif olan işaret farklı sayfalarda farklı davranmaya başlar.

F-modeli

F şeklinde tarama davranışı, Nielsen Norman Group'un göz izleme çalışmalarıyla popülerleşti ve testlerin değişmez sorusu oldu. Sorunlu kısım, bunun bir hedef sanılması. F-modeli iyi bir tasarımın sonucu değil, okuyucunun metinde aradığını bulamadığı için tarama moduna geçmesinin belirtisi. NN/g'nin kendi değerlendirmesi de bu yönde: desen, içerik yerleşimi zayıf olduğunda güçleniyor.

Yani "en önemli şeyi sol üste koy" tavsiyesi eksik. Daha doğrusu, her paragrafın ilk iki kelimesini bilgi taşıyacak şekilde yazmak. Tarama davranışını yok edemezsin ama tarayan göze her satırda bir tutamak bırakabilirsin.

Ters piramit

Sonucu başa almak, dijital metinde neredeyse istisnasız işe yarar. Gazetecilikten gelen bu yapının web'de daha da güçlü olmasının sebebi, kullanıcının sayfayı terk etme maliyetinin sıfır olması. Kaynak metnin "tıklanma oranını artırır" iddiası ise ayrı bir konu; ters piramit tıklamadan sonrasını, yani kalma süresini etkiler.

Dışsal bellek ve mobil bileşenler

Kullanıcı kısa süreli belleğini korumak için not alır, sekme açık bırakır, ekran görüntüsü çeker. Arayüz bu işi kendi üstlenirse (girilen veriyi hatırlamak, adımı geri alınabilir tutmak, seçilenleri görünür yerde biriktirmek) o dışsal belleğe ihtiyaç kalmaz. Bunun tersi de doğru: yirmi maddelik bir mobil carousel, kullanıcıyı gördüğü şeyi aklında tutmaya zorlar ve dördüncü karttan sonra kimse ne gördüğünü hatırlamaz (bu bileşen ayrıca kodda bakımı en pahalı olanlardan biri, erişilebilirliğini düzgün kurmak listeye çevirmekten uzun sürer).

Between-subjects'in test sorularında görünmeyen faturası

Testlerde şu şekilde sorulur: her katılımcının yalnızca bir varyasyonu gördüğü tasarım hangisidir? Doğru cevap between-subjects, ve genelde "karşılaştırma daha objektif olur" diye eklenir. Objektif olmasının sebebi, kullanıcının ikinci varyasyonda görevi zaten öğrenmiş olmasının etkisini ortadan kaldırması.

Sorunun sorulmayan kısmı maliyet. Within-subjects tasarımda aynı kişi bütün varyasyonları gördüğü için n katılımcı yeter; between-subjects'te her varyasyon kendi grubunu ister, yani k varyasyon için n×k kişi. Grup başına beş kişilik mütevazı bir kullanılabilirlik testinde dört varyasyon karşılaştırmak yirmi katılımcı demek. Bu yüzden "daha objektif" olan yöntem, çoğu şirket içi projede pratikte uygulanamayan yöntemdir. Varyasyon sayısını ikiye indirmek, tasarımı düzgün kurmaktan daha belirleyici oluyor.

Within-subjects'i seçtiğinde ise sıra etkisini dengelemek zorundasın: yarı katılımcı A'yı önce, yarısı B'yi önce görmeli. Bu tek satırlık bir plan değişikliği ve maliyeti sıfır, ama atlanınca elde ettiğin sonuç öğrenme etkisinin gölgesinde kalır.

SUS ve test sonrası ölçekler

System Usability Scale on maddeden oluşur, beşli katılım ölçeğiyle doldurulur ve 0-100 arası tek bir sayı üretir. Bu sayı yüzde değil, sık yapılan hata da tam burada: 72 aldın diye "kullanıcıların %72'si memnun" diyemezsin. SUS literatüründe yüzlerce çalışmanın ortalaması 68 civarında kabul edilir, dolayısıyla anlamlı olan tek şey bu referansa ve kendi önceki sürümüne göre konum.

Tek bir ölçümün de söylediği fazla bir şey yok. SUS'u ilk kez uyguladığında elde ettiğin sayı bir başlangıç çizgisidir, bulgu değil. Değeri, aynı görev setiyle ikinci kez ölçtüğünde ortaya çıkar.

Empati haritası neden testlerde kolay, uygulamada zor

Empati haritası, Dave Gray'in XPLANE'de geliştirdiği basit bir şablon: kullanıcının ne söylediği, ne düşündüğü, ne yaptığı ve ne hissettiği dört alana yazılır. Test sorusu olarak zahmetsiz. Uygulamada zorlaşmasının sebebi, alanların gerçek görüşme kayıtlarından değil ekibin varsayımlarından doldurulması. İçine kullanıcıdan gelmiş tek bir cümle koyamıyorsan, elindeki empati haritası değil, ekibin kendi tahminlerinin duvara asılmış hali.

Ekibine test hazırlayacaksan

Terim sorma, karar sordur. "F-modeli nedir" yerine, gerçek bir ekran görüntüsü koy ve "bu sayfada tarama davranışı hangi bilgiyi kaçırtır" diye sor. Soruların çoğu mevcut ürününüzden gelsin; hazır soru havuzları ekibin gündelik olarak karşılaştığı problemlere değmiyor.

Sonuçları kişi bazında değil soru bazında paylaş. Kimin kaç aldığı ortaya döküldüğünde test bir performans değerlendirmesine dönüşür ve bir daha kimse dürüst cevap vermez. Hangi sorunun ekipçe kaçırıldığı ise doğrudan bir sonraki iç eğitimin konusu olur, ki testin tek somut çıktısı budur.