Kullanılabilirliğin Beş Bileşeni Tek Testle Ölçülmez
Kullanılabilirlik listesi her yerde aynı beş maddeyle geçer: öğrenilebilirlik, verimlilik, hatırlanabilirlik, hata yönetimi, tatmin. Listede bir sorun yok. Sorun, bu beşinin tek bir kullanıcı testi oturumunda birden ölçülebileceği varsayımında, çünkü maddelerin en az ikisi tanımı gereği farklı zaman noktalarına bakar.
Aynı oturumda ölçülemeyenler
Öğrenilebilirlik ilk temasla ilgilidir. Bir katılımcıda yalnızca bir kez ölçebilirsiniz; kullanıcı arayüzü gördükten sonra artık öğrenilebilirlik denekliği bitmiştir. Hatırlanabilirlik ise aynı kişiyi aradan zaman geçtikten sonra geri çağırmayı gerektirir. İki hafta sonraki ikinci oturum ayrı bir randevu, ayrı bir bütçe kalemi ve pratikte katılımcıların bir kısmının gelmemesi demektir.
Verimlilik üçüncü bir kurulum istiyor. İlk denemede ölçtüğünüz süre verimlilik değil, öğrenme süresidir. Gerçek verimlilik aynı görevin ikinci ya da üçüncü tekrarında, süre düzleşmeye başladığında ortaya çıkar. Bir raporda "kullanıcılar görevi ortalama 48 saniyede tamamladı" cümlesi görüyorsanız, bunun kaçıncı denemenin süresi olduğunu sormadan hiçbir anlamı yok.
Her bileşenin kendi kurulumu
| Bileşen | Ne zaman ölçülür | Kaydedilen |
|---|---|---|
| Öğrenilebilirlik | İlk temas, tek seferlik | İlk görevi yardımsız tamamlama oranı |
| Verimlilik | Aynı görevin tekrarında | Görev süresi, adım sayısı |
| Hatırlanabilirlik | Aradan zaman geçtikten sonra ikinci oturum | Süredeki kayıp, yeniden sorulan sorular |
| Hata yönetimi | Her oturumda, sürekli | Hata sayısı ve hatadan sonra kurtulma oranı |
| Tatmin | Görev biter bitmez | Tek soruluk zorluk değerlendirmesi |
Tabloda görev sonu anketinin yeri özellikle görev bitiminde. Oturumun tamamı bittikten sonra sorulan "nasıldı" sorusu son görevin izlenimini taşır, ortalamayı değil.
Hata yönetimi tasarımda değil, kodda kırılıyor
Beş bileşen içinde arayüz katmanında en az çözüleni bu. Formun kırmızı çerçevesi ve uyarı ikonu tasarımın işi, ama kullanıcının okuduğu cümle çoğu üründe sunucudan dönen mesajın olduğu gibi ekrana basılmış hali. "Constraint violation" yazan bir uyarıyı hiçbir tipografi kurtarmaz.
Hatadan kurtulma da aynı yerde kırılıyor. Doğrulama yalnızca sunucu tarafında yapılıyorsa kullanıcı formu gönderdikten sonra öğreniyor, sayfa yeniden yüklendiğinde de doldurduğu alanların bir kısmı boşalmış oluyor. Test kaydında bunu şuradan görürsünüz: aynı alanı ikinci kez dolduran katılımcı sayısı. Bu sayı sıfırdan büyükse sorun metin yazımında değil, formun durumu nerede tuttuğunda.
Ölçmek için pahalı kuruluma gerek yok
Görev süresi ve adım sayısı zaten üründe biriken olay kayıtlarından çıkar. Görevin başladığı ve bittiği kabul edilen olaylara birer zaman damgası koymak yeterli. Zor olan kısım ölçüm aracı değil, tanım: "görev bitti" ne demek. Sipariş ekranına ulaşmak mı, ödemenin onaylanması mı, onay e-postasının gitmesi mi. Bu tanım netleşmeden toplanan süreler kıyaslanamaz.
Test ortamı için laboratuvar da gerekmiyor. Kapalı bir oda, gerçek kullanıcı ve az sayıda katılımcıyla sık tekrar, tek seferlik büyük çalışmadan daha çok bulgu üretir; çünkü aradaki her turda tasarımı düzeltip aynı hatayı bir daha görmezsiniz.
İki ölçümü karıştırmamak gerekiyor. Sayfa hızını WebPageTest gibi araçlarla ayrıca ölçün, sonra verimlilik sayılarına dönüp bakın: yavaş yüklenen bir ekranda görev süresi şişer ve bu şişme akış tasarımının hesabına yazılır. A/B testi de kullanılabilirlik testinin yerine geçmez. Hangi varyantın kazandığını söyler, kaybedenin neden kaybettiğini söylemez; o cevap yalnızca birinin ekran başında takıldığı yeri izlemekten çıkar.
Beş bileşeni birden ölçtüğünü söyleyen rapor, büyük ihtimalle birini ölçmüş, dördünü tahmin etmiştir. Hangisini ölçtüğünüzü yazın, kalanı için ölçmediğinizi yazın.