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

Kullanılabilirlik Testinde Yöntem Seçimi ve Beş Kullanıcı Kuralı

Kullanılabilirlik Laboratuvarı Şart mı? Kurulum, Yöntem ve Sınırlar

Kullanılabilirlik laboratuvarı, testin kendisi değil testin kabıdır. Asıl iş, doğru soruyu soran bir senaryo yazmak ve kullanıcının ne söylediğine değil ne yaptığına bakmak. Bir yönlü camlı oda bunu kolaylaştırır, yerine geçmez.

Kontrollü ortam neyi sağlar

Tek bir işlevi var: davranışı, bozucu etkenler olmadan kaydedebilmek. Ekran kaydı, ses, fare hareketi ve katılımcının sesli düşünmesi aynı zaman çizgisine oturduğunda kullanıcının nerede durakladığı tartışmaya açık kalmaz. Ekipteki "bence bu ekran gayet anlaşılır" cümlesini bitiren şey kaydın kendisidir.

Bunun için bir yönlü cam ve sabit kamera düzeneği şart değil (laboratuvar fotoğraflarının çoğunu vitrin buluyorum). Ekran kaydı alan bir yazılım, düzgün bir mikrofon ve kapısı kapanan bir oda aynı veriyi verir.

Hangi yöntem neyi ölçer

Yöntem, cevabını aradığınız sorunun türüne göre seçilir.

  • Moderatörlü birebir test: "Neden burada durdu" sorusuna cevap verir. Az katılımcı, derin bilgi.
  • Moderatörsüz uzaktan test: Görev tamamlama oranı, süre, hata sayısı gibi sayılabilir çıktılar için uygun. Katılımcı sayısı arttıkça anlam kazanır.
  • Oturum kaydı ve analitik: Canlı üründe kaç kişinin nerede bıraktığını ölçer, nedenini söylemez.
  • Odak grubu: Kullanılabilirlik testi değildir. Görüş toplar, davranış toplamaz, üstelik katılımcılar birbirini etkiler. Ürün fikrini tartmak için yararlı, arayüz kararı vermek için yanıltıcı.

Pratikte en verimli sıra, analitikte sorunlu adımı bulup o adımı moderatörlü testle açmak. Sayı nereye bakacağınızı, gözlem ne gördüğünüzü söyler.

Beş kullanıcı kuralı ve nerede geçersizleşir

Nielsen'in yaygınlaşmış tavsiyesi bir formüle dayanır: bir katılımcının belirli bir sorunu tetikleme olasılığı L ise, n katılımcıyla ortaya çıkan sorun oranı 1-(1-L)^n olur. L için 0,31 alındığında beş katılımcı sorunların yaklaşık %85'ini, üç katılımcı %67'sini görünür kılar.

Formülün sessiz varsayımı şu: katılımcılar tek ve türdeş bir kullanıcı grubundan geliyor. İki ayrı kullanıcı tipiniz varsa, diyelim yönetim panelini kullanan personel ile son müşteri, karışık seçilmiş beş kişi her grup için üçer kişilik iki turdan daha az bilgi verir. L de bir ortalamadır; yalnızca nadir bir akışta ortaya çıkan sorunun gerçek olasılığı çok daha düşüktür ve o sorun beş kişilik turda görünmez. Yani beş kullanıcı tur başına bir eşik, proje boyunca geçerli bir kota değil.

Kurulumda gerçekten gereken

Küçük ekipte maliyet donanımda değil işgücünde birikir: katılımcı bulmak, senaryo yazmak, kaydı baştan sona izleyip not çıkarmak. Otuz dakikalık bir oturumun analizi rahat bir saat sürer, planı buna göre yapın.

Atlanmaması gereken kalem izin. Ekran ve ses kaydı kişisel veridir; kaydın ne için alındığını, ne kadar süre saklanacağını ve kimlerin izleyeceğini katılımcıya yazılı olarak söylemek gerekir. Kayıtları proje klasöründe süresiz tutmak yerine rapor çıktıktan sonra silinecek ayrı bir yerde tutmak hem hukuken hem pratikte daha temiz.

Bulguyu rapora değil işe çevirmek

Testin çıktısı bir problem listesidir ve liste tek başına hiçbir şeyi değiştirmez. Her bulgunun yanına iki alan koyun: kaç katılımcıda görüldü, düzeltmenin tahmini maliyeti ne. "Etiket metni belirsiz" ile "adres formu doğrulama hatasında girilen veriyi kaybediyor" aynı satırda duramaz; ilki yarım saatlik iş, ikincisi form durumunun baştan kurgulanması demek.

Erken test etmenin asıl kazancı da burada görünür. Prototipte yakalanan akış hatası çizim düzeltmesiyle kapanır, yayındaki bir formda aynı hata veri göçü, geriye dönük uyumluluk ve yeniden test yükü getirir. Test alışkanlığını kurmanın en ucuz yolu laboratuvar değil, tasarım henüz bitmemişken üç kişiyle yapılan otuz dakikalık turlar. WebPageTest gibi araçlarla ölçülen sayfa hızı da bu turların yanında durur, çünkü yavaş açılan bir ekranda ölçtüğünüz şey arayüz değil sabırdır.