Nicel Kullanılabilirlik Testinde Örneklem ve Hata Payı

Nicel testte tartışma genellikle "kaç kullanıcı yeterli" sorusu etrafında dönüyor, oysa cevap ölçtüğünüz şeye ve o sayıyla ne yapacağınıza bağlı. Görev başarı oranını rapora yazmak ile iki tasarımdan hangisinin daha iyi olduğuna karar vermek, aynı örneklemle karşılanmaz. Aradaki farkı görmezden gelen her "kabul edilebilir hata payı" tavsiyesi, aslında bir varsayımı gizliyor.

Sabit bir "kabul edilebilir hata payı" yok

UX yazılarında sık sık belirli bir yüzdenin çoğu proje için yeterli olduğu söylenir. Bu rakamlar tek başına anlamsız, çünkü hata payı bir yöntem tercihi değil, örneklem büyüklüğünün ve gözlenen oranın doğrudan sonucu. Aynı çalışmada başarı oranının hata payı ile görevi tamamlama süresinin hata payı bile birbirinden farklı çıkar.

Doğru soru şu: elimdeki sayı, alacağım kararı değiştirecek kadar keskin mi? Bir arayüzün tamamen kırıldığını görmek için hassas ölçüme ihtiyacınız yok. İki varyant arasında birkaç puanlık fark aramak ise bambaşka bir iş.

Örneklem büyüdükçe aralık ne kadar daralır

Görev başarısı gibi bir oranın belirsizliği örneklemin kareköküyle azalır. Aralığı yarıya indirmek için kullanıcı sayısını dörde katlamanız gerekir. Somutlaştırmak için, üç durumda da ölçülen başarı oranı %80 olsun ve %95 güven aralığına (Wilson) bakalım:

• 5 kullanıcının 4'ü başardı: gerçek oran kabaca %38 ile %96 arasında.
• 20 kullanıcının 16'sı başardı: %58 ile %92 arasında.
• 80 kullanıcının 64'ü başardı: %70 ile %87 arasında.

Üç satırın da ürettiği tek sayı aynı: %80. Beş kullanıcıyla ulaştığınız aralık pratikte hiçbir şey söylemiyor, çünkü hem "kullanıcıların çoğu başaramıyor" hem de "neredeyse herkes başarıyor" yorumu bu aralığın içinde kalıyor. Yirmi kullanıcıda aralık hâlâ geniş ama artık bir yön gösteriyor. Seksene çıkmanın maliyeti ise, kazandığı on yedi puanlık daralmaya değip değmediğine göre kararlaştırılır.

Bir metriği panoya ya da sunuma koyacaksam tek sayı yerine aralığın iki ucunu birden yazmayı tercih ederim. Yüzde seksen yazan bir kutu, kimse sormadığı sürece kesin bir bulgu gibi dolaşmaya başlıyor.

Beş kullanıcı ölçüm örneklemi değil

"Beş kullanıcı yeterli" kuralı nicel ölçüm için değil, sorun keşfi için ortaya atıldı. Mantığı da tamamen başka: bir sorunun tek bir kullanıcıda görülme olasılığı yüksekse, birkaç kişide o soruna rastlama şansı hızla artar. Bu, kaç kişinin görevi tamamladığına dair bir yüzde üretme yetkisi vermiyor.

Nicel ve nitel testi aynı oturumda yürütmek sorun değil, hatta ekonomik. Karışıklık, keşif oturumundan çıkan sayının rapora metrik olarak girmesiyle başlıyor. Beş kişilik oturum size hangi adımın kullanıcıyı durdurduğunu gösterir; o adımın kullanıcıların yüzde kaçını durdurduğunu göstermez.

Ne ölçtüğünüz, kaç kişi ölçtüğünüzden önce gelir

Oran ölçüyorsanız (başarı, hata, tamamlama) belirsizlik yukarıdaki gibi davranır. Süre ölçüyorsanız durum daha kötü: görev süreleri sağa çarpık dağılır, tek bir kullanıcının takılıp kalması ortalamayı tek başına kaydırır. Süre metriklerinde ortalama yerine medyanla çalışmak, aynı örneklemden daha kararlı bir sayı çıkarır.

Karşılaştırmalı testlerde ise gereken örneklem, aradığınız farkın büyüklüğüne bağlı. Yirmi puanlık bir farkı görmek görece kolay, üç puanlık farkı görmek için gereken kullanıcı sayısı çoğu ekibin bütçesinin dışında. Böyle bir durumda testi küçültüp yine de "anlamlı fark bulunamadı" yazmak, sonucu bilgi olmaktan çıkarır.

Pratikte ne yapmalı

• Testten önce hangi farkın sizi harekete geçireceğine karar verin. Karar eşiği yoksa örneklem hesabı da yapılamaz.
• Küçük örneklemli oturumları sorun bulmak için kullanın, sayı üretmek için değil.
• Raporda her orana güven aralığını ekleyin. Aralık utandırıcı derecede genişse, bulguyu değil raporlama biçimini düzeltin.
• Süre metriklerinde medyan ve dağılımı birlikte verin.

Bariz sorunları hızlı bulmak için büyük örnekleme ihtiyaç yok, bu doğru. Ama bu, küçük örneklemden çıkan yüzdeleri kesin veri gibi kullanma izni değil. İki iddia sık sık birbirine karıştırılıyor ve karışıklığın bedelini, sayılara dayanarak alınmış yanlış tasarım kararları ödüyor.