Uygulama UX'ini İyileştirme: Ölçüm, Geri Bildirim ve Test Sırası

Bir uygulamanın kullanıcı deneyimini iyileştirmek arayüzü güzelleştirmekle değil, insanların tam olarak nerede takıldığını ölçmekle başlar. Ölçüm, geri bildirim, önceliklendirme, test: bu dört adım sırayla yapıldığında birbirini besler, sıra bozulduğunda ise ekip tahmine dayalı değişiklikleri canlıda dener. En pahalı hata da budur.

Davranış verisi neyi ölçer, neyi ölçmez

İşe olay tanımından başlamak gerekiyor. Olay, kullanıcının yaptığı ve sayılabilen tek bir eylemdir: "kayıt formu açıldı", "doğrulama kodu gönderildi", "sepete ekle'ye basıldı". Bunlar olaydır. "Kullanıcı memnun kaldı" bir olay değildir, ölçülemez, analitik aracına da girmez.

Sıralı olayları arka arkaya dizince huni çıkar. Huninin değeri toplam sayılarda değil, adımlar arasındaki düşüş oranındadır. Kayıt ekranını açan 1000 kişiden 800'ü formu doldurup 240'ı doğrulama kodunu giriyorsa, sorunun yeri artık tartışmaya açık değil: kod adımı. Tasarımın geri kalanını konuşmak o adım düzelene kadar zaman kaybı.

Buna karşılık sayfa görüntüleme ve oturum süresi tek başına hiçbir şey söylemez. Bir ekranda geçirilen uzun süre, içeriğin ilgi çekici olduğu anlamına da gelebilir, kullanıcının aradığı düğmeyi bulamadığı anlamına da. Süreyi ancak bir görevin tamamlanma oranıyla birlikte okursanız yön kazanır.

Geri bildirim kimden geliyor

Anket dolduran, forma yazan, görüşmeye gelen kullanıcı ortak bir özelliğe sahiptir: hâlâ oradadır. Uygulamayı ilk beş dakikada silen kişi ne memnuniyet anketi görür ne de kullanıcı görüşmesine katılır. Dolayısıyla geri bildirim kutusu, ürünü kullanmayı zaten başarmış insanların sorunlarını gösterir. Başaramayanların sorunlarını göstermez, ki asıl büyük kayıp oradadır.

Bu boşluğu kapatmanın yolu niteliksel veriyi terk verisiyle çapraz okumaktan geçiyor. İlk 24 saatte ayrılan kullanıcıların son gördüğü ekranı listeleyin. O liste, hiç kimsenin size söylemediği sorunun adresidir. Ankette çıkan "filtreleme biraz karışık" şikayetiyle aynı ağırlıkta değildir; çok daha ağırdır.

Önceliklendirmede sıklık tek ölçüt değil

Yaygın tavsiye şudur: en çok tekrarlanan sorunu önce çöz. Çoğu durumda doğru, ama sınırı var. Veri kaybettiren, yanlış tutar gösteren ya da kullanıcının verdiği bir kararı sessizce değiştiren hatalar sıklığa bakılmaksızın en başa alınır. Haftada beş kişiyi etkileyen bir tutarsızlık, günde üç yüz kişiyi iki saniye yavaşlatan sürtünmeden önce gelir, çünkü biri güveni bozar diğeri yalnızca canı sıkar.

Sıklık ve etki çarpımına dayalı sıralama, ancak can yakmayan sürtünmeleri kendi aralarında dizerken güvenilir. Listenin başına neyin koşulsuz gireceğini önceden yazılı hale getirmek, her sprint başında aynı tartışmayı tekrar etmekten kurtarıyor.

Prototipi beş kişiyle test etmek

Kullanılabilirlik testinde katılımcı sayısının çok yüksek olması gerekmiyor. Jakob Nielsen'in klasikleşmiş beş kullanıcı önerisi, kullanılabilirlik sorunlarının büyük bölümünün ilk beş katılımcıda ortaya çıktığını söyler. Altıncı kişiden itibaren aynı sorunlar tekrar etmeye başlar.

Yeni bir akışı genelde canlıya almadan önce beş kişilik bir masaüstü testiyle elerim; tıklanabilir bir prototip, tek bir görev cümlesi ve müdahale etmeden izlemek çoğu zaman yetiyor. Testin sonucunda kalan iki makul seçenek varsa, ölçüme oradan sonra geçmek daha mantıklı.

A/B testinin sessiz maliyeti

Buradaki yaygın yanılgı, A/B testinin ucuz olduğunu sanmak. Testi kurmak ucuz, sonucun anlamlı çıkması pahalı. Dönüşümü yüzde 2'den yüzde 2,2'ye çıkaran bir değişikliği rastlantıdan ayırt etmek için grup başına kabaca 80 bin oturum gerekir. Kaba hesap 16 · p · (1-p) / fark² ile yapılır; p = 0,02 ve fark = 0,002 için sonuç grup başına yaklaşık 78 bin çıkıyor.

Günde 500 oturum alan bir uygulamada iki grup için bu, 300 günü aşan bir test demektir. Yani küçük trafikli ürünlerde küçük iyileştirmeleri A/B testiyle doğrulamak matematiksel olarak mümkün değil. O ölçekte doğru araç kullanılabilirlik testi ve huni analizidir. A/B testini büyük fark yaratması beklenen değişiklikler için saklayın: fiyatlandırma ekranı, kayıt akışının tamamı, ana eylem düğmesinin yeri.

Değişikliği yayına aldıktan sonra ölçmeye devam edin

Döngüyü kapatan adım en çok atlanan adım. Bir düzeltme canlıya çıktığında, düzeltmeye gerekçe olan metriğin iki hafta sonra ne olduğuna bakmak gerekiyor. Huninin o adımındaki düşüş azaldı mı, yoksa sorun bir sonraki adıma mı taşındı? İkincisi sandığınızdan sık oluyor; formu kolaylaştırdığınızda daha fazla kişi bir sonraki ekrana ulaşır ve darboğaz yer değiştirir.

Ölçtüğünüz metriği değişiklikten önce yazın, sonra tekrar bakın. Bu kadarı bile, iyileştirme diye yapılan işlerin kaçının gerçekten iyileştirme olduğunu görmeye yeter.