Kullanıcı Deneyiminin İşletmeye Katkısı ve Ölçülebilir Tarafı
Kullanıcı deneyimi tartışması çoğu şirkette arayüz güzelliğinde tıkanır. Oysa kötü deneyimin faturası başka kalemlerde ödenir: artan destek talebi, yarım kalan sepet, iade edilen ürün. Bu rakamlar muhasebede zaten duruyor, sadece UX etiketiyle toplanmıyorlar.
Katkı nerede görünür
Bir e-ticaret sitesinde ödeme formundaki zorunlu "şirket unvanı" alanı, bireysel müşterinin yarısını orada durdurur. Kargo ücretinin son adımda ortaya çıkması aynı işi yapar. Bunlar tasarım zevkiyle ilgili değil, sıralamayla ilgili sorunlar ve düzeltilmeleri genellikle bir sprint bile sürmez.
Deneyimin işletmeye katkısını görmek isteyen ekibin ilk yapması gereken şey yeni bir araştırma başlatmak değil. Destek kayıtlarını okumaktır. Aynı soru ayda otuz kez soruluyorsa, o soru bir arayüz hatasının faturasıdır ve kaç dakika müşteri temsilcisi zamanına mal olduğu hesaplanabilir. UX'in getirisini savunmanın en kolay yolu, tasarımı satmak yerine bu maliyeti göstermektir.
Beş kullanıcının matematiği
Kullanılabilirlik testinde kaç kişiyle çalışılacağı, bütçenin en çok tartışıldığı yerdir. Jakob Nielsen'in yaygın olarak bilinen hesabı, bir katılımcının ortalama olarak sorunların yaklaşık %31'ine denk geldiğini varsayar. Beş kişiyle bulunan sorun oranı bu durumda 1-(1-0,31)^5, yani kabaca %85 çıkar. On beş kişiye çıkınca oran %99,6'ya yükselir.
Aradaki fark kulağa büyük geliyor ama yanıltıcı. On beş kişilik tek tur, tek bir tasarımın hatalarını neredeyse eksiksiz çıkarır ve orada biter. Beş kişilik üç tur ise ikinci turda değişmiş, üçüncü turda yeniden değişmiş bir tasarımı sınar. İkinci turda karşınıza çıkan sorunlar, birinci turda düzelttiğiniz şeyin yarattığı yeni sorunlardır ve tek turluk testte bunları görme ihtimaliniz yoktur. Aynı bütçeyi bölmek, hepsini bir kerede harcamaktan iyidir.
Bu hesabın sınırı da var. %31 oranı ortalama bir değer, karmaşık ve rol bazlı sistemlerde katılımcı başına bulunan sorun payı düşer. Muhasebe yazılımı gibi kullanıcı tipi çok ayrışan ürünlerde her rol için ayrı beşli tur gerekir, tek havuzdan seçilen beş kişi değil.
Dıştan içe çalışmak
Kararı toplantı odasında verip sonra kullanıcıya onaylatmak yaygın bir alışkanlık. Ters yönde çalışmak, yani önce gerçek kullanım ortamına bakmak, çoğu zaman daha ucuz bitiyor çünkü yanlış özelliği geliştirme riskini baştan kesiyor. Pratikte şu sıra işe yarıyor:
- Kullanıcının işi nasıl yaptığını kendi ortamında izleyin, anket yerine gözlem.
- Gördüğünüz zorlukları çözüm önermeden yazın, çözümü erken söylemek gözlemi bozar.
- Kâğıt üzerinde ya da tıklanabilir bir taslakla en riskli akışı kurun.
- Beş kişiyle test edin, düzeltin, tekrar test edin.
Küçük ekiplerde bu döngüyü her sprintte döndürmek gerçekçi değil. Sürekli araştırma, ürünü hâlâ arayan erken aşama şirketleri için doğru. Akışı oturmuş bir üründe ise sürekli araştırma yerine sürüm öncesi kısa koridor testleri ve düzenli okunmuş destek kayıtları daha iyi sonuç veriyor.
Neyi izlemeye değer
Memnuniyet anketleri kolay toplandığı için popüler, ama tek başına yönlendirici değil. Davranışa bakan üç ölçüm çok daha fazlasını söyler: görevin tamamlanma oranı, tamamlanana kadar geçen süre ve kullanıcının yaptığı hata sayısı. Bunlar on kişilik bir testte bile karşılaştırılabilir sayılar üretir.
Standart bir puan isteyenler için SUS anketi hâlâ en pratik seçenek. On maddelik anket 0-100 arası bir puan verir ve literatürde yerleşmiş ortalama 68 civarındadır. Puanın kendisinden çok, aynı ürünün iki sürümü arasındaki farkı görmek için kullanışlıdır. Hotjar, Maze ya da GA4'ün huni raporları da aynı işi tamamlar, yeter ki ölçüm başlamadan önce neyin başarı sayıldığı yazılı olsun.
Ölçüm süreci belgelenmediğinde her tasarımcı kendi yöntemiyle çalışır ve iki sürüm arasındaki sonuçlar karşılaştırılamaz hale gelir. Sürecin kıymeti buradadır: tasarımı iyileştirmez, iyileştirmenin gerçekten olup olmadığını görmenizi sağlar.