Kullanıcı Deneyimi Hedeflerini Ölçmek: Sinyal Seçimi ve Süre Tuzakları

Ölçüm planı metrikle başlamaz. Hangi aracı kurduğunuz, kaç olay tetiklediğiniz, panelde kaç grafik durduğu ikincil kalır; asıl soru tasarımın kullanıcıya neyi kolaylaştırdığıdır. Bu sıra ters çevrildiğinde eldeki şey veri değil, gürültü olur.

Metrik hedeften türer

Sayfaya video koydunuz. Oynatma sayısını saymak kolay olanıdır, ama o sayı videonun işe yarayıp yaramadığını söylemez. Videoyu açan kullanıcı sonrasında formu doldurdu mu, fiyat sayfasına geçti mi? Ölçülmesi gereken bu. Oynatma sayısı yalnızca bir ön koşuldur: sıfır çıkıyorsa bir şeyin bozuk olduğunu anlarsınız, yüksek çıkıyorsa hiçbir şey anlamazsınız.

Sıra her zaman aynıdır. Hedefi yazarsınız, hedefin gözlenebilir karşılığını bulursunuz, sonra ölçüm yöntemini seçersiniz. Araçla başlayıp "bu panel neyi ölçebiliyor" diye sorduğunuzda, hazır duran metriklerin tasarım hedefinizi belirlemesine izin vermiş olursunuz.

Sinyal hedefle çelişiyorsa yöntem yanlıştır

Hedef "ziyaretçi aradığı bilgiye hızlı ulaşsın" ise, sayfanın sonuna kadar inilmesi bir başarı sinyali değildir. Tersidir: kullanıcı aradığını üstte bulamadığı için aşağı iniyordur. Scroll derinliği ancak hedef "içerik baştan sona okunsun" olduğunda doğru sinyaldir, hız hedefinde değil.

Aynı karışıklık sayfada kalma süresinde de var. Uzun süre, içeriğin ilgi çektiği anlamına gelebileceği gibi kullanıcının ne yapacağını bulamadığı anlamına da gelir. Sinyali seçerken tek bir soruyu tek tek sormak gerekir: bu sayı artarsa hedefime yaklaşmış olur muyum? Cevap "duruma göre" ise o sinyal ana metrik olamaz.

Hedefi dört adımda sinyale indirmek

1. Hedefi yazın. Özellikten beklenen deneyim nedir: kullanıcı kaydı tek seferde tamamlasın, raporu filtre kurmadan görsün gibi.
2. Gözlenebilir karşılığını bulun. Hedef gerçekleştiyse kullanıcı davranışında ne değişir?
3. Tek ana sinyal seçin. Beş sinyali birden izlemek, çelişince hangisine inanacağınızı bilmemek demektir.
4. Yöntemi belirleyin. Olay takibi, tamamlama oranı, görev süresi; sinyal neyse ölçüm ona göre kurulur.

Süre ölçerken iki tuzak

Birincisi ortalama. Görev süresi dağılımı sağa çok uzun kuyruklu olur, çünkü sekmede açık kalan oturumlar yarım saatlik kayıtlar üretir. Tek bir kullanıcının öğle arası, yüz kullanıcının ortalamasını bozar. Medyan ve 90. yüzdelik birlikte raporlanmalı; ortalama bu veride neredeyse hiçbir şey anlatmaz.

İkincisi daha sinsi: tamamlama süresi yalnızca görevi tamamlayanlardan hesaplanır. Vazgeçenler veri setinde yoktur, dolayısıyla zorlanan kullanıcıları arayüzden kovduğunuzda süre metriği düzelir. Bir yönetim panelinde toplu düzenleme ekranı çıkardık, ortalama işlem süresi belirgin düştü ama günlük tamamlanan kayıt sayısı da düştü; toplu seçimi çözemeyen kullanıcılar ekranı terk ediyor, geride kalan hızlı kullanıcılar ortalamayı güzelleştiriyordu.

Bu yüzden süre tek başına raporlanmaz. Yanına tamamlama oranı konur ve ikisi aynı ekranda okunur. İyileşme ancak süre düşerken tamamlama oranı sabit kaldıysa ya da yükseldiyse gerçektir.

Hata oranı, hatanın tanımı kadar sağlam

"Hata oranı düştü mü" sorusunun cevabı, hatayı neyin ürettiğine bağlıdır. Kullanıcı yanlış kaydı sildiğinde sunucu 200 döner, loglar temiz görünür, raporda hiçbir sorun yoktur. Doğrulama uyarısı almadan yapılan yanlış işlem, sistem açısından başarılı bir isteğe benzer.

Gerçek sürtünme başka yerde iz bırakır: geri alma tıklamaları, aynı formun ikinci kez gönderilmesi, kaydettikten hemen sonra yapılan düzeltme. Bunları saymıyorsanız hata oranınız düşük görünür ve bu düşüklük tasarımdan değil ölçümün körlüğünden gelir.

Pratikte işe yarayan plan kısadır: hedef başına bir ana sinyal, bir de o sinyalin yanıltma ihtimalini kapatan karşı metrik. Daha fazlası rapor üretir, karar üretmez.