Kullanılabilirlik Testi: Hangi Yöntem Hangi Soruyu Cevaplar
Kullanılabilirlik testi pahalı bir iş değil, yanlış yöntemi seçmek pahalı. Beş kişilik bir görev testi bir haftada sonuç verir; aynı soruyu A/B testine sorduğunda aylarca veri beklersin. Yöntemi soruya göre seçmek, test sayısını artırmaktan daha çok kazandırır.
Ölçtüğün şey sistem değil, o görev
Kullanılabilirliğin ölçülebilir olduğu doğru, ama ölçüm sistemin değil bir üçlünün özelliğidir: kullanıcı, görev, bağlam. Aynı ödeme akışı kartını daha önce kaydetmiş bir müşteride sorunsuz çalışır, ilk kez sipariş veren birinde üçüncü adımda tıkanır. Protokolde önce görevi ve kullanıcı grubunu yaz, puanı sonra konuş. Aksi halde elinde bağlamı belirsiz bir sayı kalır ve o sayıyla ne yapılacağını kimse bilmez.
Beş kullanıcı kuralının aslı
"Beş kullanıcı sorunların %85'ini bulur" cümlesi Nielsen ve Landauer'in modelinden geliyor. Bir kullanıcının rastgele bir sorunu fark etme olasılığı L ise, n kullanıcıdan en az birinin fark etme olasılığı 1-(1-L)^n olur. L'yi 0,31 alırsan beş kullanıcıda sonuç 0,84 çıkar. Formül doğru, varsayımı zayıf: her kullanıcının her sorunu bulma şansını eşit sayıyor.
Kitlen ayrı gruplara bölünüyorsa (mobil ile masaüstü, yeni ile deneyimli) bu eşitlik bozulur; mobilde çıkan sorunu masaüstü kullanıcısı hiç görmez. Yani beş kişi toplamda değil, ayırt ettiğin her grup için beş kişi. Tek seferde otuz kişiyle test etmek yerine beşerli turlar yap ve arada düzelt, çünkü ikinci turda görünen sorunlar birinci turun altında kalmış olanlardır. Ekran kaydı ve bir not defteriyle başla, ilk beş oturumu yapmadan test yazılımı satın alma; o turda çıkanların çoğu araçla değil dikkatle bulunuyor.
A/B testi kullanılabilirlik testi değildir
A/B testi hangi sürümün kazandığını söyler, neden kazandığını söylemez. Üstelik trafik ister. Dönüşümü %2'den %2,4'e çıkaran bir değişikliği güvenle yakalamak için kol başına kabaca 20 bin ziyaretçi gerekir; günde 200 ziyaretçi alan bir sitede bu, testin altı aydan uzun sürmesi demektir. O altı ayda tasarım zaten iki kez değişmiş olur.
Kural basit: nedenini bilmediğin sorun için görev testi, birbirine yakın iki iyi seçenek arasında karar için A/B. Küçük trafikte A/B'ye ayıracağın süreyi beş kullanıcılı iki tura harca, daha çok şey öğrenirsin.
Kart sıralama ve Lighthouse: sınırını bilerek kullan
Kart sıralama
Menü yapısı ve adlandırma sorunlarında işe yarar, arayüzün akışı hakkında bir şey söylemez. Katılımcı sayısı yirminin altına indiğinde kümeler oynaklaşır, aynı veriden iki farklı menü ağacı çıkarabilirsin. Sonucu birebir menüye çevirme; hangi başlıkların kullanıcının kafasında aynı kutuya girdiğini gösteren bir ipucu olarak oku.
Lighthouse
Erişilebilirlik denetimi kural tabanlıdır: etiket var mı, kontrast yeterli mi, başlık sırası bozuk mu diye bakar. Etiketin anlamlı olup olmadığını ölçemez. Üzerinde yalnızca "Devam" yazan bir düğme tam puan alır, ama kullanıcı o düğmenin ne yapacağını bilmiyorsa test yine başarısızdır. Ücretsiz ve otomatik olduğu için her yayın öncesi çalıştır, çıktısını kullanılabilirlik raporunun yerine koyma.
Bulguları nasıl sıralarsın
Her not eşit değil. Görevi tamamlamayı engelleyen bir sorun tek kişide çıksa bile ilk sıraya yazılır. Beş kişinin de yavaşladığı ama sonunda geçtiği yer ikinci sıradadır. "Rengi hoşuma gitmedi" listeye girmez. Bir sorunun kaç kişide görüldüğü ciddiyetini değil yaygınlığını gösterir, ikisini aynı sütunda toplama.
Düzeltmeden sonra aynı görevi yeniden ölçmezsen testin yarısını yapmış olursun. Tamamlama süresi ve yardımsız tamamlama oranı, takip edeceğin iki sayı olarak yeter.
Kaynak