HEART Framework: UX Metriğini Hedeften Türetmek
HEART, Google'ın 2010'da yayımladığı bir UX ölçüm çerçevesi: Happiness, Engagement, Adoption, Retention, Task Success. Çoğu özetin atladığı yer, bu beş metriğin yanında duran Goals-Signals-Metrics süreci. Çerçevenin asıl işe yarayan yarısı orada: metrik listeden seçilmez, hedeften türetilir.
Beş metrik, kısaca
- Happiness: memnuniyet ve tutum. Anket, NPS, uygulama içi puanlama, destek talepleri.
- Engagement: gönüllü kullanımın sıklığı ve yoğunluğu.
- Adoption: belirli bir pencerede ürünü ya da yeni bir özelliği ilk kez kullananlar.
- Retention: önceki pencerede aktif olanların bu pencerede de aktif kalma oranı.
- Task Success: başlanan görevin tamamlanma oranı, süresi ve hata sayısı.
Tarifler bu kadar basit. Zor olan kısım, hangisini ölçmeyeceğinize karar vermek.
Önce hedef, sonra sinyal, en sonra metrik
Rodden ve arkadaşlarının makalesi HEART'ı tek başına bırakmaz, yanına Goals-Signals-Metrics adında üç adımlı bir süreç koyar. Hedef: bu akış neyi başarırsa başarılı sayılacak. Sinyal: hedefe yaklaşıldığında kullanıcı davranışında hangi gözlenebilir değişiklik olur. Metrik: o sinyal hangi orana dönüşür.
Beş harfi alıp süreci bırakmak en sık yapılan hata. Ortaya beş metriği de gösteren, ama hiçbiri bir karara bağlanmayan bir panel çıkıyor. Bir özellik için tek bir hedef seçin, ona bir sinyal, sinyale bir metrik bağlayın. Kalan dördü panelde durabilir, kararı onlar vermez.
Her projeye beş metrik gerekmez
Kullanımı zorunlu kurumsal bir sistemde engagement yanıltıcıdır, çünkü insanlar mecbur oldukları için giriyor. Orada task success ile hata oranı konuşur. Kullanıcının kendi isteğiyle geldiği bir üründe ise retention en sert testtir; arayüz değişikliğinin gerçekten tuttuğunu iki hafta sonra o söyler. Adoption'ı tek başına UX'e yazmayın: kampanya açtığınız hafta yükselir, ürün aynı üründür.
Sayım değil oran
Bu metriklerin çoğu ham sayı olarak tutulduğunda deneyimi değil kullanıcı tabanının büyümesini ölçer. Haftalık tamamlanan görev sayısı artarken tamamlama oranı düşüyor olabilir, ilk grafiğe bakan ekip işlerin yolunda gittiğini sanır. Payda hep görünsün: kaç kullanıcı üzerinden, hangi zaman penceresinde.
Pencereyi de baştan sabitleyin. "Aktif kullanıcı" tanımını sürümden sonra değiştirirseniz eski retention rakamlarıyla karşılaştırma yapamazsınız; iyileşme sandığınız şey tanım değişikliği olur.
Ölçüm koda dokunur
Görev başarısını ölçecekseniz başlangıç olayını da loglayın, çünkü elinizde yalnızca "tamamlandı" eventi varsa payda yoktur, oran da yoktur; yarıda bırakanlar hiçbir yerde görünmez. Süre için de aynısı geçerli, bitiş zaman damgası tek başına bir şey anlatmaz.
Olayları isimlendirirken ekranın konumunu değil kullanıcının yaptığı işi yazın. checkout_step_2 gibi bir isim arayüz değişince anlamını kaybeder ve üç ay sonra o metriğin neyi saydığını kimse hatırlamaz.
Araçlar neyi ölçer
Davranış tarafında Google Analytics, Mixpanel, Amplitude; oturum kayıtları ve ısı haritaları için Hotjar; happiness için uygulama içi kısa anket ya da NPS. Lighthouse'u bu listeye koymayın: sayfa performansını ve bazı erişilebilirlik kontrollerini ölçer, kullanıcının görevini tamamlayıp tamamlamadığını değil. Yüksek bir Lighthouse skoru kötü kurgulanmış bir akışı kurtarmaz.
Kaynaklar