Kullanılabilirlik Yatırımının Getirisi ve Bütçedeki Payı

Kullanılabilirlik bütçesi tartışması neredeyse her zaman aynı rakamlarla açılır: bütçenin yüzde onu, testten sonra yüzde 135 iyileşme, yatırımın elli katı geri dönüş. Bu sayıların çoğu tek bir kaynağa dayanıyor ve yirmi yıl öncesinden geliyor. Nereden çıktıklarına ve kendi projende hangisinin hâlâ geçerli olduğuna bakmak, onları slayta kopyalamaktan daha faydalı.

Yüzdeler nereden geliyor?

Dolaşımdaki "kullanılabilirlik çalışması sonrası ortalama yüzde 135 iyileşme" rakamı, Nielsen Norman Group'un 2000'lerin başında derlediği vaka çalışmalarından çıktı. Dönüşümde yüzde 100, trafikte yüzde 150, özellik kullanımında yüzde 202 gibi kalemler de aynı derlemenin alt başlıkları.

Peki o vakalar neye benziyordu? 2003'te yeniden tasarlanan bir site, bugünün en vasat şablonundan bile geriydi: sabit genişlikte düzen, tıklanabilir olduğu belli olmayan bağlantılar, on beş alanlı formlar. Böyle bir tabandan başlayınca iki katına çıkmak zor değil. Bugün hazır bir tasarım sistemiyle kurulmuş bir arayüzde aynı sıçramayı beklemek gerçekçi değil, çünkü kolay kazançların çoğu bileşen kütüphanesinin içinde zaten alınmış durumda.

İkinci soru daha rahatsız edici: bu derlemeye kim girdi? Yayımlanan vakalar işe yaramış projeler. Yeniden tasarımdan sonra dönüşümü düşen, sonra sessizce geri alınan sürümler için kimse konferans sunumu hazırlamıyor. Ortalamayı sadece kazananlardan hesaplarsan çıkan sayı bir beklenti değil, bir üst sınır olur.

Maliyet neden doğrusal artmıyor?

Kaynaklarda geçen bir gözlem var: proje on kat büyüdüğünde kullanılabilirlik maliyeti yaklaşık dört kat artıyor. Bu üstel bir ilişki, kabaca maliyet ≈ büyüklük^0,6 demek (10^0,6 ≈ 3,98). Rakamın kendisi kaba ama yönü doğru: test protokolünü yazmak, katılımcı bulmak, bulguları raporlamak proje iki katına çıktı diye iki katına çıkmaz.

Bunun doğrudan bir sonucu var ve genelde atlanıyor. Maliyet büyüklüğün 0,6 kuvvetiyle, fayda ise aşağı yukarı kullanıcı sayısıyla artıyorsa, "bütçenin yüzde onu" kuralı iki uçta da yanlış çalışır. Üç aylık, tek geliştiricili bir işte yüzde on, yarım günlük bir koridor testine bile yetmez; bir alt sınır vardır ve o sınır orana değil, en küçük anlamlı çalışmaya bağlıdır. Yüz binlerce kullanıcılı bir üründe ise yüzde on fazlasıyla cömerttir, orada sorun bütçe değil, araştırma bulgusunu sürüme sokacak kanalın tıkalı olması.

Sabit oran yerine iki soruyla planla: bu üründe bir hatanın kaç kullanıcıya değdiği, ve bir bulgunun koda girmesinin kaç gün sürdüğü. İkincisi uzunsa daha fazla araştırma bütçesi yalnızca daha kalın bir bulgu arşivi üretir.

Getiriyi kendi verinle ölç

ROI hesabının formülü tartışmalı değil: kazanç eksi harcama, harcamaya bölünür. Zor olan kazancı doğru saymak. E-ticarette dönüşüm farkı doğrudan ciroya yazılır, kurum içi bir panelde ise kazanç zamandır ve çoğu ekip bunu ölçmeden tahmin eder.

Ölçüm için ayrı bir analitik ürün satın alman gerekmiyor. Akışın başındaki ve sonundaki iki uç noktanın istek kayıtlarını oturum kimliğine göre eşleştir, tamamlanma oranını ve aradaki süreyi çıkar; bu bir öğleden sonralık iş ve lisans ücreti ödemezsin. Üstelik sunucu tarafında saydığın için reklam engelleyicinin kestiği olayları da görürsün, ki tarayıcı tabanlı ölçümle aradaki fark bazı kitlelerde şaşırtıcı derecede yüksek çıkıyor.

Kurum içi araçlarda kazancı parasallaştırmanın makul yolu şu: iyileştirilen görevin günde kaç kez yapıldığını, görev başına kazanılan saniyeyi ve o işi yapan kişilerin saatlik maliyetini çarp. Tek bir varsayımı bile belirsizse aralık ver, tek bir sayı verme. Yönetime sunulan üç haneli ROI tahminlerinin çoğu, kaç kişinin o ekranı gerçekten açtığına dair yoklanmamış bir varsayımın üstünde duruyor.

Ya iyileştirme tutmazsa?

Bu soruyu baştan sormak planı değiştirir. Bir yeniden tasarımın etkisini ancak eski sürümle karşılaştırabiliyorsan bilebilirsin, bu yüzden değişikliği bir kerede herkese açmak yerine trafiğin bir bölümüne aç ve iki hafta iki sürümü yan yana ölç. Geri alma maliyetini de hesaba kat: bileşen düzeyinde yapılan bir değişiklik geri alınabilir, veri modeline dokunan bir akış değişikliği pratikte alınamaz.

Beş kullanıcılık testin sorunların büyük bölümünü yakaladığı yönündeki klasik kural burada hâlâ işe yarıyor, ama şu koşulla: beş kişi tek bir kullanıcı grubundan geliyorsa. İki farklı profile hitap eden bir üründe beş kişilik tek bir tur, ikinci grubun sorunlarını hiç görmeden sana rahatlık hissi verir.