Kendi Tasarımını Test Etmek: Küçük Ekipler İçin Ne Kadar Güvenilir?

Küçük ekiplerde kullanılabilirlik testini çoğu zaman tasarımı yapan kişi yürütür, çünkü başka kimse yok. Buna itirazım yok. İtirazım, bu durumu savunmak için kullanılan "her test hiç test yapmamaktan iyidir" sözüne: kötü kurulmuş bir test sonuç üretmediği için değil, yanlış sonucu güvenle ürettiği için zarar verir.

Kötü test, testsizlikten daha pahalı olabilir

Hiç test yapmadığınızda elinizde belirsizlik kalır. Belirsizlik rahatsız edicidir ve insanı tedbirli tutar; ekranı yayına alırken ikinci kez bakarsınız. Oysa "beş kullanıcıyla test ettik, anladılar" cümlesi tartışmayı kapatır. O cümlenin arkasındaki seans yönlendirici sorulardan oluşuyorsa, ortaya çıkan şey veri değil, tasarımcının kendi varsayımının onaylanmış hali olur.

Ayrımı yapmanın pratik yolu şu: seansta görev verin, fikir sormayın. "Sepete eklemek kolay oldu mu?" sorusunun cevabı neredeyse her zaman evettir, çünkü karşınızdaki kişi sizi kırmak istemiyor. "Şu listedeki ikinci ürünü alıp kargo ücretini öğrenin" dediğinizde ise cevabı siz değil, ekranda olup bitenler verir. Kolay olup olmadığına da siz karar verirsiniz, kullanıcı değil.

Kendi işini test etmenin asıl riski tarafsızlık değil, görev metni

Kör nokta meselesi anlatıldığı kadar büyük değil. Tasarımcı kendi ekranında kullanıcının takıldığını görür, görmemek zor. Sorun daha önce başlıyor: görevleri yazan kişi tasarımı yapan kişiyse, test edilen akışlar da tasarımın iyi çalıştığı akışlar olur. Kenar durumlar listeye hiç girmez.

Kendi tasarımını test eden tasarımcıyı, ekibe iki hafta sonra rapor yetiştiren dış araştırmacıdan daha verimli bulurum; bulgu ile düzeltme arasındaki mesafe sıfırdır. Tarafsızlıkta tersi geçerli, o yüzden tek bir ayrımı korumaya değer: görev metnini yazan ile seansı yürüten kişi aynı olmasın. İki kişilik ekipte bile bu mümkün, görevleri diğerine yazdırırsınız.

Beş kullanıcı kuralının küçük yazısı

Nielsen'in beş kullanıcı önerisi yaygın biçimde "beş kişi yeter" diye aktarılır. Önerinin kendisi tek bir kullanıcı grubu için kurulmuştur. Arayüzünüz ilk kez gelen ziyaretçiyle her gün oturup çalışan operatöre aynı anda hizmet ediyorsa, iki ayrı grup var ve her biri için beş kişi gerekir. Grup sayısı arttıkça seans sayısı doğrusal büyür: üç grupta on beş seans eder, bu da küçük bir ekip için artık "hızlı test" değildir.

Buradan çıkan sonuç testten vazgeçmek değil, kapsamı daraltmak. Üç grubu da yüzeysel yoklayan on beş seans yerine, en çok para bırakan tek grupla beş seans yapıp diğerlerini bir sonraki tura bırakmak daha çok iş görür. Dağıtılmış dikkat, kimseyi anlamamakla sonuçlanıyor.

Bulguları neye göre sıralamalı

Test bitince elinizde genelde sekiz on madde olur ve hepsi aynı listede eşit görünür. Oysa bir tanesi buton metnini değiştirmek, bir tanesi veri modeline dokunmaktır. Listeyi "kaç kullanıcı takıldı" sırasına dizmek ikinci maddeyi başa taşır ve o madde hiç yapılmaz, çünkü bir haftalık iştir. Sonra da test işe yaramadı denir.

Bulguları iki eksende işaretleyin, tek satırda değil:

• Kaç kişi takıldı ve takıldığında görevi tamamlayabildi mi.
• Düzeltmenin dokunduğu yer: metin, arayüz katmanı, iş mantığı, veri yapısı.

Metin ve arayüz katmanındaki her şeyi aynı hafta kapatın, ucuzdur ve sayıca çoktur. Veri yapısına dokunan tek bulguyu ayrı bir karara bağlayın; o artık test bulgusu değil, planlama konusu.

Uzman gerçekten ne zaman gerekir

Görev tamamlama ve kafa karışıklığı ölçmek için uzman şart değil, biraz disiplin yeter. İki yerde yetmiyor. Birincisi erişilebilirlik: ekran okuyucuyla gezinmeyi günlük kullanan biri on dakikada, sizin iki günde bulamayacağınız şeyi söyler. İkincisi kullanıcının kendi işini sizden daha iyi bildiği karmaşık iş akışları, muhasebe ya da klinik ekranları gibi. Orada neyi test edeceğinizi bilmemek, testi yanlış yapmaktan beterdir.