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

Kullanılabilirlik Testinin Doğru Zamanı: Önce, Sırasında ve Sonra

Kullanılabilirlik Testi Zamanlaması ve Beş Kullanıcı Kuralının Sınırı

Kullanılabilirlik testinin en pahalı hali, her şey bittikten sonra yapılanıdır. Lansmandan bir hafta önce bulunan akış hatası artık düzeltilecek bir tasarım sorunu değil, ertelenecek bir karardır. Testi tek bir noktaya sıkıştırmak yerine üç ayrı yere koyun: yeniden tasarıma başlamadan önce, tasarım sürerken ve yayına çıktıktan sonra.

Yeniden tasarımdan önce

Mevcut ürünü test etmeden yeni tasarıma başlamak, hangi problemi çözdüğünüzü bilmeden çözmek demek. Sonuç genelde aynı problemlerin yeni renklerle tekrar kurulması olur. Beş kullanıcı bulun, mevcut arayüzde gerçekten yapılan üç işi görev olarak verin (sipariş takibi, şifre değiştirme, fatura indirme gibi), ekranı kaydedin ve araya girmeyin.

Buradan çıkan liste yeni tasarımın gündemi olur. Elinizde böyle bir liste yoksa yeniden tasarım tartışması estetik tercihlere kayar, çünkü tartışılacak somut bir şey kalmaz.

Tasarım sürerken: kâğıt da sayılır

Erken testin şartı çalışan ürün değil, karar verilebilir bir taslak. Tel kafes, tıklanabilir prototip, hatta kâğıda çizilmiş bir akış test edilebilir. Amaç cilayı ölçmek değil, kullanıcının bir sonraki adımı doğru tahmin edip etmediğini görmek.

Bu aşamada bulunan hata henüz kod değil, bir çizgi. Silmek beş dakika sürer. Aynı hata yayına girdikten sonra veri taşıma, geriye dönük uyumluluk ve yeni test yazma işine dönüşür.

Beş kullanıcı kuralı ne der, ne demez

Jakob Nielsen'in beş kullanıcı önerisi basit bir formüle dayanır: bir turda bulunan problem oranı 1-(1-L)^n, burada L tek bir kullanıcının bir problemi ortaya çıkarma olasılığı. L yaklaşık 0,31 alındığında beş kullanıcı problemlerin yüzde 85'ine, on beş kullanıcı ancak yüzde 99'una denk gelir. Yani ek on kişinin büyük kısmı, ilk beşin zaten bulduğunu tekrar bulmaya gider.

Doğru okuma şu: aynı bütçeyle tek büyük çalışma yerine üç küçük tur yapın, her turun arasında tasarımı düzeltin. Formülün sessiz varsayımı ise tek bir kullanıcı grubu olması. Yönetici panelini kullanan operasyon ekibiyle son kullanıcıyı aynı beş kişilik teste sıkıştırırsanız grup başına iki üç kişi kalır ve oran çöker. Beş sayısı segment başınadır, test başına değil.

Yayından sonra

Analitik nerede kaybettiğinizi söyler, test neden kaybettiğinizi. Üçüncü adımda düşen dönüşüm bir uyarıdır; o adımda kullanıcının ne aradığını yalnızca izleyerek görürsünüz. Yayın sonrası turlarını küçük tutun ve tek bir akışa odaklayın.

Bulguyu takvime bağlamak

Test sonuçlarını ayrı bir rapora yazma alışkanlığı, çoğu ekipte bulguların ölme biçimidir. Bulguyu doğrudan issue olarak açın, ekran kaydının ilgili saniyesini bağlayın, tahmini girin; rapor okunmaz ama issue sprint planına girer.

Testin takvimdeki yeri de aynı mantıkla kurulur: turu planlarken düzeltme için de gün ayırın. Yer ayrılmamışsa test yapılmış, ürün değişmemiş olur.