Usability Mühendisliği: Görevi, Yöntemi ve Sınırları
Usability mühendisliği, bir arayüzün gerçekten kullanılıp kullanılamadığını ölçme işidir. Merkezinde tasarım zevki değil kanıt vardır: kim nerede takıldı, hangi adımı atladı, kaç kez geri döndü. Peki bu kanıt ne kadar sağlam ve ekibin içinde neye dönüşüyor?
Tanım: ölçülebilir kullanım
ISO 9241-11 kullanılabilirliği üç ölçüte bağlar: kullanıcı hedefine ulaşabiliyor mu (etkililik), ne kadar çabayla ulaşıyor (verimlilik), süreçten memnun ayrılıyor mu (memnuniyet). Tanımın işe yarar tarafı, üçünün de belirli bir görev ve belirli bir kullanıcı grubu için sayılabilir olması.
Bu yüzden “site kullanışlı mı” sorusunun cevabı yoktur. “Daha önce hiç kayıt olmamış biri fiyat sayfasına kaç adımda ulaşıyor” sorusunun cevabı vardır, üstelik iki farklı tasarımda karşılaştırılabilir.
Gündelik iş neye benziyor
Usability mühendisinin masasındaki iş çoğunlukla şu sırayla ilerler:
- Test edilecek görevi yazmak: gerçek bir amaç, tek cümle, içinde cevabı barındırmayan bir ifade
- Katılımcıyı bulmak, oturumu yürütmek, kullanıcı takıldığında yardıma koşmamak
- Kayıtları izleyip takılma noktalarını, yanlış varsayımları ve sessiz vazgeçişleri işaretlemek
- Bulguyu ekibin uygulayabileceği biçimde yazmak
- Değişiklikten sonra aynı görevi yeniden ölçmek
Son madde en çok atlanan maddedir. Rapor teslim edilir, ekip bir şeyler değiştirir, kimse aynı görevi bir daha koşmaz. O noktada elde kullanılabilirlik ölçümü değil, kullanılabilirlik hakkında bir görüş kalır.
Beş kişilik bir oturum neyi kanıtlar
Bu alandaki metinlerin çoğu, usability mühendisinin bulgularını “istatistiksel olarak kanıtladığını” söyler. Oysa moderasyonlu bir kullanıcı testi tipik olarak beş ila sekiz kişiyle yapılır. Beş kişinin birinde görülen bir sorun kâğıt üzerinde yüzde yirmi gibi durur; aynı testi başka beş kişiyle tekrarlayın, o sorun hiç çıkmayabilir de üç kişide birden çıkabilir de. Bu örneklem büyüklüğünde yüzde hesaplamak, olmayan bir kesinliği taklit etmektir.
Küçük örneklemin işi başkadır: sorunun var olduğunu göstermek. Bir kişi formda hangi alanın zorunlu olduğunu anlayamadıysa o belirsizlik gerçektir ve düzeltilir, kaç kişide çıkacağını tartışmak zaman kaybıdır. Sayısal iddia istiyorsanız yeriniz farklı: canlı trafik, olay kaydı, A/B ölçümü.
Peki yalnızca A/B ölçümüne güvenilse ne olur? Hangi varyantın kazandığını öğrenirsiniz, nedenini öğrenemezsiniz. Sıralamayı şöyle kurun: küçük örneklemli gözlemle sorunu bulun, düzeltin, etkisini trafik üzerinde doğrulayın. Tersten başlayan ekipler neyi neden kazandıklarını bilmeden optimize eder ve birkaç ay sonra aynı yerde yeniden buluşur.
Bulgunun kodda karşılığı
Bir usability raporunda iki tür cümle bulunur. Birincisi şuna benzer: “Ödeme adımında kart numarası alanı boşluk karakteri kabul etmiyor, katılımcı kartındaki gruplu yazımı aynen girdi ve alanın altındaki hata mesajını göremedi.” İkincisi şuna: “Navigasyon daha sezgisel olmalı.” Birincisi ertesi gün bir iş kaydına dönüşür, ikincisi toplantıda kalır.
Bulguyu yazarken ekranı, adımları, beklenen davranışı ve gözlenen davranışı tek tek koyun, yorumu sona bırakın. Geliştirici üç satırı okuyup işi kapatır; on sayfalık sunum kimsenin sırasına girmez.
UX tasarımcısıyla aynı kişi olabilir mi
Küçük ekiplerde zaten aynı kişi. Asıl sorun rollerin birleşmesi değil, ölçen ile tasarlayan aynı kişi olduğunda kendi kararını savunma eğiliminin devreye girmesi. Bunun ucuz bir çözümü var: test görevlerini tasarımı yapmayan biri yazsın ve oturumu o yürütsün. Görev metnini tasarımcı yazdığında cümle farkında olmadan cevabı içerir, katılımcı da gidip o cevabı bulur.
Kaynaklar