Pareto Prensibi Kullanıcı Deneyiminde Nerede Çalışır, Nerede Yanıltır

Pareto Prensibi kullanıcı deneyimi yazılarında neredeyse bir doğa yasası gibi anılır: özelliklerin %20’si kullanımın %80’ini taşır. Analitik ekranına bakınca gerçekten de buna benzeyen bir dağılım çıkar, o kadarı doğru. Sorun kuralın kendisinde değil, ondan çıkarılan tavsiyede. “Az kullanılanı buda” cümlesi, o kullanım sayısının nereden geldiğini bilmiyorsanız ters teper.

80/20 bir yasa değil, bir gözlem

Vilfredo Pareto 1896’da İtalya’daki toprak dağılımına bakıp toprakların büyük bölümünün küçük bir azınlığın elinde olduğunu not etti. Yönetim danışmanı Joseph Juran bunu kalite kontrole taşıdı ve “hayati azınlık” adını verdi. Aradaki mesafe önemli: Pareto bir dağılım gözlemledi, Juran ondan bir karar kuralı üretti. Bugün UX yazılarında dolaşan şey ikincisi.

Rakamların toplamının 100 etmesi de tesadüf, kuralın parçası değil. Bir tarafta özellik sayısı var, diğer tarafta tıklama sayısı; farklı iki büyüklük. Gerçek dağılımlar 70/20, 90/5, hatta 55/35 çıkar.

Kuralın gerçekten ilginç yanı şu: dağılım kendi içinde tekrarlıyorsa, yani en yoğun %20’lik dilimin içinde de aynı oran geçerliyse, toplamın %4’ü sonucun %64’ünü taşır (0,2 × 0,2 ve 0,8 × 0,8). Üçüncü katmanda %0,8 ile %51’e inersiniz. Ürün ekipleri “çekirdek özellikler” derken çoğu zaman ilk katmanı kastediyor, oysa asıl yığılma daha derinde. Bunu bir kez hesaplamak, hangi ekranın gerçekten omurga olduğunu görmeyi kolaylaştırır.

Analitik neyi ölçüyor

Bir özelliğin kullanım sayısı, o özelliğin değerinin ölçüsü değildir. Menünün üçüncü katmanına gömülmüş bir işlev az kullanılır; bu, kimsenin ihtiyacı olmadığı anlamına gelmez, kimsenin bulamadığı anlamına da gelebilir. Pareto analizini böyle bir veri üzerinde çalıştırınca kendi kendini doğrulayan bir döngü kurulur: gömülü olan az kullanılır, az kullanıldığı için budanır, budandığı için bir daha ölçülmez.

Bir özelliğin değerini tartarken sayfa görüntüleme sayısını destek kayıtlarından daha zayıf bir kanıt sayarım. Görüntüleme, kullanıcının o ekranı bulabildiğini söyler. Destek kaydı ise kullanıcının bir işi yapmaya çalıştığını ve yapamadığını söyler, yani niyeti içerir. Sıralamayı ikisinden yalnızca birine dayandıracaksanız ikincisi daha az yanıltır.

Aynı sorun oranların paydasında da var. “Ana sayfadaki üç banner tıklamaların %75’ini alıyor” cümlesi, sayfada zaten yalnızca dört banner varsa hiçbir şey söylemez. Pareto analizi yapmadan önce sıralanan kümenin kaç elemanlı olduğunu yazın; küçük kümede her dağılım Pareto’ya benzer.

Sıklık ile kritiklik aynı eksen değil

Parola sıfırlama, fatura indirme, hesap kapatma. Bu akışlar kullanıcı başına yılda bir ya da iki kez çalışır, hiçbiri kullanım grafiğinin tepesine çıkmaz. Ama parola sıfırlama çalışmıyorsa kullanıcı ürüne geri dönmez ve bu, ana ekranda geçirilen sürenin tamamını değersizleştirir.

Kuyruktaki maddeleri ayırmanın pratik yolu, kullanım sayısını değil başarısızlık maliyetini sormak: bu akış bozulursa kullanıcı bekler mi, başka yolu dener mi, yoksa ilişkiyi bitirir mi? Üçüncü gruptakiler kullanım sayısı ne olursa olsun ilk %20’ye aittir.

Prensibin gerçekten işlediği yer

Pareto’nun tartışmasız işe yaradığı alan, hangi özelliğin yaşayacağına karar vermek değil, sınırlı araştırma bütçesini dağıtmak.

• Destek kayıtlarını konuya göre kümeleyin. İlk üç başlık genelde yığının yarısından fazlasını taşır ve bunlar çoğunlukla arayüzde tek bir belirsiz etiketten ya da tek bir hata mesajından kaynaklanır.
• Kullanılabilirlik testi senaryolarını en yoğun üç görev yoluna kurun. Beş kişilik bir testte yedi senaryo denemek yerine üçünü derinlemesine izlemek daha çok bulgu verir.
• Yeniden tasarımda önce en çok trafik alan şablonu ele alın, tek tek sayfaları değil. Bir liste şablonunu düzeltmek yüzlerce sayfayı birden düzeltir.

Karar sırasını ise etki ve maliyet ikilisiyle kurun: yüksek etkili ve ucuz olan hemen, yüksek etkili ve pahalı olan planlanarak, düşük etkili olan hiç. “Sonra bakarız” kutusu pratikte hiçbir zaman açılmaz, o yüzden dürüst olun ve eleyin.

Ölçümün kendisi de bir maliyet

Bu analizlerin hepsi, olayların kaydediliyor olmasını varsayar. Gerçekte olay kaydı kendiliğinden gelmez; her özelliğe olay eklemek geliştirme işidir, bakım işidir, isimlendirme disiplini ister. Ekipler de doğal olarak önemli saydıkları yerlere olay koyar.

Buradan şu çıkıyor: elinizdeki Pareto grafiği, ürünün gerçek kullanım dağılımını değil, ekibin altı ay önce önemli saydığı şeylerin dağılımını gösteriyor olabilir. Grafiğe bakmadan önce hangi özelliklerin hiç ölçülmediğini listeleyin. O liste genelde kısa ve açıklayıcıdır.

Sıralamayı çıkarmak için pahalı bir ürün analitiği aracına da gerek yok. Olay kayıtlarını özellik kimliğine göre gruplayıp sayan bir sorgu ve kümülatif yüzdeyi hesaplayan ikinci bir sütun, Pareto diyagramının ihtiyaç duyduğu her şeyi verir. Zorluk sorguda değil, olayların tutarlı isimlendirilmesinde.

Kullanıcı davranışı da sabit durmaz. Bir yılda bir kez çalıştırılan Pareto analizi, geçen yılın ürününü tarif eder. Üç ayda bir tekrarlayın ve sıralamanın nasıl kaydığına bakın; kaymanın yönü, tek başına sıralamanın kendisinden daha çok şey anlatır.