Tek Kullanılabilirlik Çalışması Hakkınız Varsa: Kullanıcı Testi mi, Alan Çalışması mı?

Bir projede kullanılabilirlik için tek bir çalışma hakkınız varsa, seçim genelde kullanıcı testi ile alan çalışması arasında sıkışır. Yaygın tavsiye ekibin olgunluğuna bakmanızı söyler: deneyimsiz ekip test yapsın, oturmuş ekip sahaya çıksın. Bu tavsiye yanlış değil, sırası yanlış. Önce takvime bakmak gerekir, çünkü bir yöntemin bulgusu geç geldiğinde ne kadar iyi olduğunun bir önemi kalmaz.

İki yöntem aynı soruyu sormuyor

Kullanıcı testi ile alan çalışmasını yan yana koyup "hangisi daha etkili" diye sormak, aslında iki farklı soruyu yarıştırmak demek. Kullanıcı testi "yaptığımız şey işe yarıyor mu" diye sorar: elinizde bir akış vardır, katılımcıya görev verirsiniz, nerede takıldığını izlersiniz. Alan çalışması "doğru şeyi mi yapıyoruz" diye sorar: kullanıcının kendi ortamında, kendi işini yaparken ne yaptığını izlersiniz, görev vermezsiniz.

Aradaki fark bir yöntemin diğerinden derin olması değil. Test ölçer, saha keşfeder. Ölçmek için ortada ölçülecek bir şey olmalı, kağıda çizilmiş bir ekran akışı bile yeter. Keşfetmek için ise ortada bir şey olmaması gayet normaldir, hatta çoğu zaman tercih edilir; erken bir tasarım fikri sahada gözünüzü bozar, kullanıcının yaptığı işi kendi çözümünüzün gölgesinden izlersiniz.

Asıl filtre olgunluk değil, kapsamın kilitli olup olmadığı

Karar için tek bir soru sorun: kapsam kilitli mi? Ne yapacağınıza karar verdiyseniz, ekranlar çizildiyse, sprint planı çıktıysa kapsam kilitlidir. Bu durumda alan çalışmasının bulgusu size "yanlış problemi çözüyorsunuz" dediğinde onu kullanacak zamanınız yoktur. En iyi ihtimalle bir sonraki sürüm için not olarak durur; bugünkü bütçenizi geleceğe yatırmış olursunuz.

Kapsam kilitli değilse durum tersine döner. Henüz neyi yapacağı belli olmayan bir üründe test edecek bir şey yoktur. Yarım yamalak bir maket üzerinde yapılan test, görev tasarımını değil buton etiketlerini ölçer; çıkan liste gerçektir ama önemsizdir, çünkü o ekranların çoğu iki hafta sonra silinecektir.

Ekip olgunluğu argümanı bundan sonra devreye girer ve doğrudur: daha önce hiç saha araştırması yapmamış bir ekip, gözlem notlarından tasarım kararı çıkarmakta zorlanır, elindeki ham malzeme rapora dönüşmeden dağılır. Ama bu ikincil bir filtredir. Kapsam kilitliyse zaten konu kapanmıştır, ekibin ne kadar deneyimli olduğu seçimi değiştirmez.

Beş kullanıcı meselesi sadece testin meselesi

Kullanıcı testinin sevilen bir özelliği var: bütçesi öngörülebilir. Nielsen'in çokça alıntılanan modeli, her katılımcının sorunların L kadarını bulduğunu varsayarak n katılımcıda bulunan oranı 1-(1-L)^n ile verir. Tipik L değeri olan 0,31 ile beş katılımcı sorunların yaklaşık %85'ini yakalar, bu yüzden beş kullanıcı kuralı bu kadar yayıldı.

Formülün söylemediği iki şey var. Birincisi, sorunlar eşit sıklıkta değildir: yalnızca katılımcıların %5'inin karşılaştığı bir sorun için hesap 1-(0,95)^5, yani %23'e düşer. Beş kişilik test sık sorunları neredeyse tamamen, nadir sorunları neredeyse hiç bulmaz. İkincisi ve seçim açısından önemlisi, bu model sabit bir sorun havuzu varsayar. Alan çalışmasında böyle bir havuz yoktur; her ziyaret sorunun kendisini değiştirir, üçüncü ziyarette fark ettiğiniz bir alışkanlık ilk ikisini yeniden yorumlatır. Beş saha ziyaretinden sonra "bulguların %85'ini gördük" diyemezsiniz, çünkü paydayı bilmiyorsunuz.

Pratik sonuç şu: tek çalışma hakkınız varken öngörülebilirlik başlı başına bir argümandır. Uzaktan yapılan beş oturumluk bir test bir güne sığar. Beş kullanıcıyı kendi iş ortamında yarımşar gün izlemek üç günü bulur, üstüne not çözümleme gelir, üstüne o notlardan ne çıkacağını önceden bilemezsiniz.

Çalışmanın maliyetini değil, bulgunun maliyetini hesaplayın

Seçimin gözden kaçan tarafı burada. Kullanıcı testinden çıkan maddelerin çoğu etikettir, hata mesajıdır, alan sırasıdır, gizlenmiş bir aksiyondur; bunları aynı sprint içinde kapatırsınız, çoğu birkaç satırlık iştir. Alan çalışmasından çıkan bir bulgu ise nadiren böyle davranır. "Kullanıcılar bu işi zaten sizin ürününüzde yapmıyor, tabloya döküp öyle çalışıyorlar" cümlesinin karşılığı bir düzeltme değil, veri modelinin değişmesidir. Doğru bulgudur, değerlidir ve pahalıdır.

O yüzden bütçeyi yaparken çalışmanın kendi maliyetine bakıp durmayın; asıl fatura, bulguyu uygulamanın maliyetidir. Alan çalışmasına ancak çıkacak bulguya göre yön değiştirebilecek durumdaysanız girin. Değiştiremeyecekseniz, elinizdeki parayla iyi bir test yapın ve ürünü gerçekten daha kullanılır hale getirin.

Karar ve bir uyarı

Kapsam kilitliyse kullanıcı testi yapın. Kapsam açıksa ve ekipte gözlemi karara çevirebilecek biri varsa alan çalışması yapın. Kapsam açık ama ekip böyle bir çalışmayı ilk kez yapacaksa, kısa tutup az sayıda ziyaretle sınırlayın ve çıktının bir tasarım kararı değil, bir soru listesi olmasını bekleyin.

Uyarı da şu: bir projede kullanılabilirliğe yalnızca tek bir etkinlik ayrılabiliyor olması, cevaplanması gereken asıl soruyu gizler. Bu genellikle yöntem seçimi sorunu değil, araştırmanın süreç içine yerleşmemiş olmasının belirtisidir. Tek seferlik çalışmayla en iyi ihtimalle o sürümü kurtarırsınız; bir sonraki sürümde aynı kararsızlığa aynı yerden başlarsınız.