Konu Başlıkları
Yükleniyor...

UX Benchmark Dokümantasyonu: Hangi Parçayı Sabitlemek Zorundasın?

Benchmark Çalışmasında Protokolü Sabitleme ve Belgeleme Rehberi

Benchmark çalışmalarında dokümantasyon genelde şöyle anlatılır: her şeyi yaz, sonra karşılaştır. Yazmak tek başına karşılaştırılabilirlik üretmez. Yanlış kurulmuş bir protokolü eksiksiz belgelersen elinde iki döngünün de geçersiz olduğunu kanıtlayan düzgün bir arşiv olur. Dokümantasyonun asıl işi şu: aradaki farkın üründen mi yöntemden mi geldiğini altı ay sonra ayırt edebilmek.

Sabitlenen şey belge değil, protokol

İki ölçüm arasındaki fark üç kaynaktan gelebilir: üründeki değişiklik, yöntemdeki değişiklik, örneklemdeki dalgalanma. Benchmark'ın tek amacı birinciyi izole etmek. İkincisini kayıt altına alarak değil, yerinde dondurarak kontrol edersin; belgeleme sadece dondurduğunu kanıtlayan şey. Üçüncüsü ise hiç yok edilemez, ancak hesaba katılır.

Bu yüzden "her şeyi dokümante edin" tavsiyesi eksik. Doğrusu, ikinci döngüde neyin aynen tekrar edileceğini birinci döngüden önce yazmak. Sonradan tutulan not, çalışma bittikten sonra hatırlananlardan ibarettir ve hatırlananlar hep düzgün görünür.

Aynen tekrarlanacak beş şey

  • Görev metinleri. Kelimesi kelimesine, kullanılan sahte veriler ve hesap bilgileri dahil.
  • Görev sırası. Rastgeleleştiriyorsan rastgeleleştirme kuralını yaz, sonucu değil.
  • Screener. Katılımcılar her döngüde farklı kişiler olacak; onları eleyen sorular olmayacak.
  • Metrik tanımları. Hangi ekranda görev bitmiş sayılıyor, süre nereden nereye ölçülüyor, başarısız denemeler ortalamaya giriyor mu.
  • Test ortamı. Moderatörlü mü, uzaktan mı, hangi cihaz, hangi platform, moderatör kaç saniye sonra ipucu veriyor.

Bu listedeki her madde metin dosyasına sığar. Protokol metnini ürünün kod deposunda tutmak, çıktı klasöründe değil (fazladan iş gibi görünür ama iki döngü arasında talimatın değişip değişmediğini bir daha kimseyle tartışmazsın, diff cevabı verir).

Örneklem: benchmark'ın en sessiz zayıf noktası

Kullanılabilirlik testinde beş katılımcının yeterli olduğu tavsiyesi keşif için verilmiştir, ölçüm için değil. Aradaki fark aritmetikte görünür: beş kişiyle ölçülen görev başarı oranı yalnızca 0, %20, %40, %60, %80 ve %100 değerlerini alabilir. Ölçüm çözünürlüğün 20 puan. "Başarı oranı %60'tan %80'e çıktı" cümlesi, tek bir katılımcının farklı davrandığı anlamına gelir ve tasarım değişikliğine dair hiçbir kanıt taşımaz.

Benchmark yapıyorsan katılımcı sayısı keşif testlerindekinin belirgin üstünde olmalı, ve daha önemlisi: her metriğin yanına dağılımı da yaz. Tek bir ortalama, kaç kişiden geldiğini söylemediği sürece okunamaz. Rapora güven aralığı koymak zor değil; koymamak, ölçtüğün farkın gürültü olabileceğini gizler.

Süre hesabını da belgelemek zorundasın

Görev süreleri sağa çarpık dağılır. Katılımcıların çoğu görevi kırk saniyede bitirir, biri altı dakika takılır ve aritmetik ortalamayı tek başına yukarı çeker. İkinci döngüde öyle bir kişi çıkmazsa ortalama düşer, sen de bunu iyileşme sanırsın.

Çare, hangi merkezi eğilim ölçüsünü kullandığını protokole yazmak ve bir daha değiştirmemek. Süre için medyan, aritmetik ortalamadan daha dürüst bir özet verir. Bir de zaman aşımı kuralı gerekir: görevi bırakan katılımcının süresi kaç sayılacak, tamamlanmamış denemeler hesaba katılacak mı. Bu kararı vermezsen, iki döngüde iki farklı kişi iki farklı şekilde verir.

Ankette de aynı disiplin geçerli. SUS kullanıyorsan sorunun metnini ve ölçek etiketlerini değiştirme; skorun 0-100 aralığında olması onu yüzde yapmaz, tek başına bir SUS puanı ancak başka bir SUS puanıyla kıyaslanınca anlam kazanır.

"Küçük bir değişiklik" diye bir şey yok

Sık verilen tavsiye şudur: metrik tanımını değiştirmek karşılaştırmayı bozar ama görev eklemek çıkarmak genelde kabul edilebilir. Bu doğru değil. Listeye altıncı bir görev eklediğinde önceki beş görevin süresi de değişir, çünkü katılımcı artık daha uzun bir oturumun içindedir; yorgunluk ve arayüzü öğrenme etkisi son görevlere biriker. Ortadan bir görev çıkardığında da kalan görevlerin sırası kayar, ikinci görev üçüncü olur ve o görevi yapan kullanıcı artık sistemi bir adım daha tanıyordur.

Yani görev seti üzerindeki her müdahale, metrik tanımını değiştirmekle aynı sonucu doğurur: yeni döngü eskisiyle kıyaslanamaz. Bunu yapmak yasak değil, ürün değişince kaçınılmaz da olur. Yapılması gereken tek şey, o noktada yeni bir taban çizgisi ilan etmek ve eski seriyi grafikte kesmek. Kesmeyip devam ettiren ekipler, kendi ürettikleri eğriyi altı ay sonra sunumda savunmak zorunda kalıyor.

Ham veri neden özetten değerli

Bulguları özetleyip ham veriyi atmak, ölçümü tek kullanımlık hale getirir. Kimliksizleştirilmiş satır bazlı veriyi (katılımcı kodu, görev, süre, sonuç, not) sakladığında üç şey mümkün olur: analizi farklı bir kesitle tekrarlamak, eski döngüde yapılmış bir hesap hatasını fark edip düzeltmek, ve yeni bir metriği geçmişe dönük hesaplamak. Özet rapordan bunların hiçbiri geri üretilemez.

Merkezi bir araştırma deposu bu yüzden dosya düzeni meselesi değil, ölçümün ömrü meselesi. Ekip değişir, araç değişir, iki yıl sonra kimse hangi sürümün hangi sayıyı ürettiğini hatırlamaz. Protokol metni, ham veri ve hesap yöntemi aynı yerde duruyorsa çalışma hâlâ canlıdır; biri eksikse elinizdeki şey bir kıyaslama değil, tarihli bir anıdır.