UX Benchmarking: Sabit Görev Seti, Doğru Metrik, Yeterli Örneklem
Benchmarking, bir ürünün kullanıcı deneyimini sabit bir görev seti ve sabit metriklerle, belirli aralıklarla yeniden ölçmektir. Tek seferlik kullanılabilirlik testinden farkı amacında: sorun bulmak değil, sayıyı zaman içinde takip edilebilir hale getirmek. İşin zor kısmı da ölçümün kendisi değil, ölçüm düzeninin turlar arasında sabit kalması.
Ölçüm ne zaman benchmark sayılır
Bir kullanılabilirlik testi size "kayıt formunda insanlar ülke seçicisini bulamıyor" der. Benchmark ise "kayıt tamamlama oranı üç turdur 68, 71, 70" der. Birincisi tasarım kararı üretir, ikincisi kararın işe yarayıp yaramadığını söyler. İkisi aynı oturumda toplanabilir, ama aynı şey değildir.
Bir turu benchmark yapan şey üç koşulun aynı kalması: görev metinleri, başarı tanımı ve katılımcıların nereden toplandığı. Bunlardan biri değişirse elinizde karşılaştırılabilir iki sayı kalmaz, birbirine benzeyen iki ayrı çalışma kalır.
Neyi ölçeceksiniz
Davranış tarafında görev başarı oranı, göreve harcanan süre ve geri dönüş sayısı çoğu ürün için yeterli. Tutum tarafında SUS ya da UMUX-Lite gibi standart bir ölçek işe yarar; kendi yazdığınız beş soruluk anketin geçmiş turlarla karşılaştırılabilirliği yoktur, çünkü kıyaslayacağınız bir referans yoktur.
Teknik tarafta Lighthouse'un tek koşumluk skoru karar vermek için zayıf kalıyor; aynı sayfayı arka arkaya çalıştırınca skorun oynadığını zaten görürsünüz. Trendi izlemek için gerçek kullanıcılardan toplanan alan verisi (LCP, INP) daha sağlam bir zemin, laboratuvar koşumu ise regresyonu erken yakalamak için (tek bir koşumun skorunu rapora yazmayı fazla iyimser buluyorum).
Kaç kişiyle
Keşif testinde beş kişi savunulabilir bir sayıdır, çünkü amaç sorunları görmek. Benchmark'ta aynı beş kişi sizi yanıltır. Beş katılımcıyla bir görevin başarı oranı yalnızca şu değerleri alabilir: 0, 20, 40, 60, 80, 100. Yani "başarı oranını yüzde 72'den 81'e çıkardık" cümlesi bu örneklemde ölçülemez; aradaki fark, tek bir katılımcının tek bir denemesinden küçüktür.
Oran raporlayacaksanız katılımcı sayısı iki haneye, tercihen otuz civarına çıkmalı. Bu da genelde moderatörlü oturumla değil, uzaktan ve moderatörsüz araçlarla mümkün oluyor. Peki bütçe buna yetmiyorsa? O zaman oran raporlamayı bırakıp aynı beş kişiyle nitel kıyas yapmak daha dürüst: hangi adımda takıldılar, o adım geçen tura göre hâlâ duruyor mu.
Rakiple kıyas
Rakip benchmark'ı cazip görünür, çünkü çıktısı bir tablodur ve tablo toplantıda iyi durur. Rakibin sayısını doğru üretmek için görevleri onların ürününde de aynı tanımla çalıştırmanız ve katılımcıları aynı kanaldan toplamanız gerekir. Bunu yapmadıysanız elinizdeki şey kıyas değil, iki ayrı çalışmanın yan yana dizilmesi.
Uzun vadede kendi seriniz rakibin tek seferlik puanından daha çok işe yarar. Rakip sayısı size nerede durduğunuzu bir kez söyler; kendi seriniz her turda değişikliğin yönünü söyler.
Serinin bozulduğu yerler
- Görev metnini "daha net olsun" diye turlar arasında düzeltmek. Yeni metin gerçekten daha iyi olabilir, ama seriyi bölmüş olursunuz. Böyle bir durumda eski metni bir tur daha çalıştırıp iki sayıyı birlikte kaydetmek gerekir.
- Katılımcıyı bu sefer kendi e-posta listenizden toplamak. Listedeki insanlar ürünü zaten biliyor, başarı oranı yükselir, ürün aynı yerde durur.
- Ölçümü yalnızca yeniden tasarımdan sonra yapmak. Öncesi yoksa sonrası kıyas değil, tek bir sayıdır.
Küçük ekip için makul bir düzen
Üç ayda bir tur, dört ya da beş görev, sabit bir anket ve alan verisinden gelen iki performans metriği. Görev setini yılda bir gözden geçirin, tur ortasında değil. Sonuçları tek bir tabloda biriktirin; o tabloda tarih, katılımcı sayısı ve toplama kanalı da bulunsun. Altı ay sonra sayının neden zıpladığını genellikle yalnızca bu üç sütun açıklar.
Kaynaklar