Beş Kullanıcıyla Test: O Sayı Nereden Geliyor, Nerede Bozuluyor
Küçük ölçekli kullanılabilirlik testlerinin savunusu genelde tek cümleye indirgenir: beş kullanıcı yeter. Cümlenin arkasında gerçek bir hesap var, ama hesabın dayandığı varsayım çoğu ekibin çalışma koşulunda tutmuyor. Sayının nereden geldiğini bilmek, onu ne zaman kullanacağınızı da söylüyor.
Beş sayısı nereden geliyor
Hesap basit. Bir kullanıcının herhangi bir kullanılabilirlik sorununa denk gelme olasılığına L derseniz, n kullanıcıyla bulunan sorun oranı 1-(1-L)^n olur. Çalışmalarda L için sıkça kullanılan ortalama 0,31'dir. Bunu koyduğunuzda beş kullanıcı sorunların yaklaşık %85'ini açığa çıkarır. Sayı buradan çıkıyor.
Kritik olan L'nin kendisi. 0,31 bir ortalama, sabit değil. Sorunların çoğu ana akışta değil de nadiren girilen yollarda toplanmışsa gerçek L çok daha düşük olur. L'yi 0,10 alın: beş kullanıcı %41 verir. Aynı yöntem, aynı bütçe, yarısından az kapsama.
Formülün ikinci varsayımı daha sessiz ve daha sık bozuluyor: tek ve türdeş bir kullanıcı kitlesi. Ürününüzü hem son kullanıcı hem yönetici rolü kullanıyorsa bunlar iki ayrı popülasyondur, iki ayrı L'leri vardır. Beş kişilik tek bir grupla ikisini birden örneklediğinizi sanmak, formülün söylemediği bir şeyi ona söyletmektir. Rol başına beş demek gerekir, ki bu da maliyeti ikiye katlar.
Yüzde neyin yüzdesi
Bir nokta daha atlanıyor. %85, bulunabilir sorunların sayıca yüzdesidir, ağırlıklı önemi değil. Beş kullanıcının kaçırdığı %15 içinde ürünü satın alma adımında kilitleyen tek bir sorun varsa, o oturumda iyi bir gün geçirmiş sayılmazsınız. Bulunan sorunları ciddiyetine göre sıralamak, kapsama yüzdesini konuşmaktan daha fazla iş görür.
Ucuz testin asıl kazancı hız değil, zamanlama
Küçük testlere "ucuz" demek yanıltıcı, çünkü tasarrufun büyük kısmı testin kendisinden gelmiyor. Kağıt prototiple yapılan bir oturumda akışın yanlış kurulduğunu gördüğünüzde, düzeltmenin bedeli birkaç sayfayı yeniden çizmektir.
Aynı bulgu yayına girmiş bir üründe çıkarsa fatura başka kalemlere yayılır: veri modelinde değişiklik, yazılmış migration, geriye dönük uyumluluk, elde birikmiş kaydın taşınması, yeniden test. Ekran tasarımı o işin en ucuz parçasıdır. Küçük testlerin değeri, bulguyu bu fatura kesilmeden önce masaya koymasında.
Bu yüzden test döngüsünü prototipin olgunluğuna göre seçin. Akış ve bilgi mimarisi tartışmalıyken kağıt yeter. Etkileşim detayı, mikro kopya ve hata durumları konuşuluyorsa tıklanabilir prototip gerekir, çünkü kağıt üzerinde kullanıcı hata durumunu yaşayamaz, yalnızca hayal eder.
Yılda bir kez geniş bakış
Kısa döngüler bir kör noktayla gelir: hep aynı ekranlara, hep aynı sorularla bakarsınız. Ürüne bütün olarak bakan, yılda bir yapılan geniş bir inceleme bunu telafi eder. Üç parçası işe yarıyor.
- Ürünle günlük ilişkisi olmayan birinin uzman değerlendirmesi. Ekipten biri bunu yapabilir ama aylardır o ekranlara bakmıyor olması gerekir.
- Rakip incelemesi. Amaç özellik listesi çıkarmak değil, aynı kullanıcı görevinin başka bir yerde kaç adımda bittiğini görmek.
- Kıyaslama ölçümü. Görev tamamlama oranı, görev süresi, hata sayısı gibi birkaç metriğin yıldan yıla takibi.
Kıyaslama kısmı kulağa en bilimsel gelen, pratikte en kolay çürüyen parçadır. Geçen yılki ölçümü farklı bir görev tanımıyla, farklı bir katılımcı profiliyle ya da farklı bir başarı ölçütüyle yaptıysanız elinizdeki iki sayı karşılaştırılabilir değildir. Ölçüm protokolünü yazılı tutun ve ertesi yıl harfi harfine tekrarlayın. Protokolü değiştirmeniz gerekiyorsa, o yıl her iki yöntemi de uygulayıp aradaki farkı kaydedin; yoksa serinin o noktadan sonrası yeni bir seridir.
Küçük testler yönü düzeltir, yıllık inceleme nerede durduğunuzu söyler. Biri diğerinin yerine geçmiyor, ama sıkışıldığında feda edilen hep ikincisi oluyor.