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

Kullanılabilirlik Testi Planı: Karar, Katılımcı Sayısı ve Görev Metni

Kullanılabilirlik Testi Nasıl Planlanır? Beş Kullanıcı Kuralının Sınırları

Kullanılabilirlik testinin çoğu hatası test gününde değil, planın yazıldığı yarım saatte yapılıyor. Yanlış kurulmuş bir test de veri üretir; sorun, o verinin hiçbir kararı değiştirmemesi. Aşağıdakiler katılımcı çağırmadan önce netleşmesi gereken kararlar.

Test hangi kararı besleyecek?

Plana "amaçları netleştirin" yazmak kolay. İşe yarayan biçimi şu soruda: bu testin sonucu hangi kararı değiştirecek? Ödeme akışındaki iki adımı birleştirip birleştirmemeye karar verecekseniz test o akışa odaklanır, sonuç da bir yöne işaret eder. Karara bağlanmamış testten çıkan şey ise kimsenin sahiplenmediği bir gözlem listesi olur, birkaç hafta sonra kimse açmaz.

Peki ürün henüz o kadar oturmadıysa? Ortada denenecek bir akış yoksa kullanılabilirlik testi erken demektir; o aşamada keşif görüşmesi daha fazlasını verir.

Beş kullanıcı kuralı nereden geliyor

"Beş kullanıcıdan sonra sorunların çoğu bulunur" cümlesi bir sabit gibi dolaşıyor. Oysa bir varsayımın sonucu ve varsayım değişince sonuç da değişiyor.

Hesap basit: tek bir katılımcının belirli bir sorunla karşılaşma olasılığı p ise, n katılımcıyla o sorunun en az bir kez yakalanma olasılığı 1-(1-p)^n. Nielsen'in yaygın örneğinde p 0,31 alınır; beş kullanıcıda sonuç yüzde 84 civarı çıkar. Karmaşık ya da seyrek kullanılan bir akışta p 0,15'e inerse aynı beş kullanıcı yüzde 56'ya düşer. Sayı sabit değil, ürünün ne kadar homojen kullanıldığına bağlı.

İkinci nokta gruplarla ilgili. Yeni kullanıcı ile günde on kez giren kullanıcı aynı arayüzü farklı görüyorsa beş sayısı grup başına geçerlidir. İki farklı grup, on kişi.

Hedef profile ulaşamıyorsanız

Katılımcıyı hedef kitleden seçmek her zaman mümkün olmuyor. Burada işin ayrımı şu: arayüz düzeyindeki sorunlar profil kaymasına dayanıklıdır, alan bilgisi isteyen akışlar değildir. Butonun bulunup bulunmadığını, hata mesajının anlaşılıp anlaşılmadığını yakın bir profil de gösterir.

Muhasebe ekranını muhasebeci olmayan beş kişiyle test ederseniz göreceğiniz şey ürünün sorunları değil, katılımcıların alan bilgisi eksikliği olur. Bulgular gerçek gibi durur, yönlendirdiği değişiklikler ise gerçek kullanıcıyı yavaşlatır. Böyle bir durumda görev kapsamını profilden bağımsız kısımlara daraltmak, yanlış profille tüm akışı test etmekten iyi sonuç verir.

Görev metni senaryo olsun, talimat değil

Görevde arayüzün kendi kelimelerini kullanmayın. "Ayarlar'dan bildirimleri kapatın" cümlesi kullanıcıya yolu söyler ve tam da ölçmek istediğiniz şeyi ortadan kaldırır. Yerine durumu anlatın: uygulamadan gelen e-postalar rahatsız ediyor, kullanıcı bunu durdurmak istiyor. Yol arama davranışı ancak böyle görünür hale gelir.

Pilot test bu yüzden atlanmayacak adım. Bir görev metninin yanıltıcı olduğunu masa başında fark edemezsiniz, ilk kullanıcının yanlış anlamasıyla anlarsınız. Tek kişilik bir prova bile çoğu bulanık ifadeyi ayıklar.

Ölçümü kuruluma yerleştirin

Başarı oranı, hata sayısı ve görev süresi işin sayılabilen tarafı. Süreyi ekran kaydından elle saymak yerine akışın başına ve sonuna birer olay kaydı koymak çoğu üründe yarım saatlik iş (ölçüm tartışmalarının en kolay kapananı budur). Kaydı test ortamına koyarsanız katılımcı başına sayfa sayfa video izlemekten kurtulursunuz.

Süre karşılaştırması ise ancak zemin sabitse anlamlı. Test ortamınız üretimden belirgin yavaşsa ölçtüğünüz şeyin bir kısmı arayüz değil, bekleme süresi. WebPageTest ya da PageSpeed Insights ile ortamın hızını bir kez ölçüp not düşmek bu gürültüyü açıklamaya yeter; performans testi kullanılabilirlik testinin yerine geçmez, yanına yazılır.

Öznel tarafı da tek soruyla toplayabilirsiniz: görev biter bitmez "bu ne kadar zordu" diye sormak, test sonunda doldurulan uzun anketten daha temiz veri verir. Kullanıcı zorluğu yaşadığı anda hatırlar, yarım saat sonra genelleştirir.

Ekibi odaya alın

Tasarımcı, geliştirici ve ürün sorumlusunun testi canlı izlemesi, aynı bulguyu rapordan okumasından çok daha hızlı sonuç verir. Kullanıcının aynı butonu üç kez ıskaladığını gören bir geliştirici o maddeyi tartışmaya açmaz. İzleyici sayısını sınırlı tutmak ve katılımcıyla aynı odada bulundurmamak yeterli; sonuç toplantısını da testin ertesi günü yapın, izlenim tazeyken karar çıkar.