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

Pareto Prensibi: 80/20 Kuralını Kendi Verinizde Sınamak

80/20 Kuralı UX ve Önceliklendirmede Nasıl Çalışır?

80/20 kuralı, proje yönetiminde ve kullanıcı deneyiminde en çok tekrarlanan, en az sınanan fikirlerden biri. Sonuçların büyük kısmının nedenlerin küçük kısmından geldiği çoğu yerde doğru; asıl soru, bu dengesizliğin sizin verinizde hangi oranla göründüğü. Rakam 80/20 çıkmayabilir, bazen hiç çıkmaz.

Kural aslında ne diyor

Vilfredo Pareto, İtalya'daki toprakların %80'inin nüfusun %20'sine ait olduğunu fark etmişti; benzer dengesizliği bahçesindeki bezelye baklalarında da gördü. Joseph Juran bunu yönetim literatürüne taşıdı ve az sayıdaki belirleyici nedene "hayati azınlık" adını verdi.

İki sayının toplamının 100 olması tesadüf. %80 sonuçların payı, %20 nedenlerin payı, yani farklı iki şeyi ölçüyorlar. 90/5 de olabilir, 70/30 da. Ezberlenecek olan oran değil, dengesizliğin kendisi.

Sizin verinizde gerçekten var mı?

Basit bir sınama var. Dağılım gerçekten güç yasasına benziyorsa aynı mantık kendi içinde de işler: en üstteki %20 sonucun %80'ini veriyorsa, o dilimin kendi içindeki %20'si (toplamın %4'ü) kabaca %80 x %80, yani %64 vermelidir. Rakamlarınız 64/4 civarına düşüyorsa elinizde ölçekten ölçeğe tekrarlayan bir yapı var demektir.

Peki ya düşmüyorsa? O zaman muhtemelen bir güç yasası değil, tek bir aykırı değer görüyorsunuz: cirosu diğerlerini ezen tek müşteri ya da destek kuyruğunu tek başına dolduran bozuk bir ekran. Bu da değerli bilgi ama farklı bir strateji ister. Güç yasasında kaynağı kalıcı olarak üst dilime kaydırırsınız; aykırı değerde o tek nedeni tamir eder, dağılımın düzleşmesini beklersiniz.

UX tarafında nerede işe yarar, nerede yanıltır

Analitiğe bakan herkes aynı manzarayı görür: sayfaların küçük bir kısmı trafiğin çoğunu alır, özelliklerin küçük bir kısmı etkileşimin çoğunu toplar. Buradan çıkan tavsiye de tanıdıktır. En çok kullanılan yere yatırım yapın.

Peki ya en çok kullanılan yer zaten en çok cilalanmış yerse? Genelde öyledir. Ana akış, ürünün ilk gününden beri üzerinde durulan yerdir ve oradaki marjinal iyileşme her turda küçülür. Kullanıcıyı ürünü bırakmaya götüren anlar ise çoğunlukla kuyrukta yaşanır: yılda üç kez açılan fatura ekranı, parola sıfırlama, veri dışa aktarma. Sıralamayı kullanım sıklığına göre yaparsanız bu ekranlar listenin dibinde kalmaya devam eder.

Yani neye göre sıraladığınız, sıralamanın kendisinden daha belirleyici. Kullanım hacmi bir sıra verir, kaybedilen müşteri başına düşen sorun bambaşka bir sıra. Önceliklendirmeye genelde analitik panelinden değil, destek kayıtlarının serbest metin alanından başlarım; hacim orada küçük görünür ama nedeni okunabilir haldedir.

Uygulama sırası

  1. Nicel veriyi toplayın: sayfa ve özellik kullanımı, destek talepleri, dönüşüm, iptal nedenleri.
  2. Aynı olayları tek bir başlık altında birleştirin. Gruplama yanlışsa sonraki her adım yanlış çıkar.
  3. Kümülatif yüzdeyi çıkarın ve 64/4 sınamasını yapın.
  4. Üst dilime dokunun, sonra ölçün. Değişmeyen sayı, yanlış dilime dokunduğunuzu söyler.

Örneklem büyüklüğüne dikkat edin. Beş destek çağrısından çıkan yüzde, yüzde değildir. Bir de gelirin büyük kısmını taşıyan küçük müşteri grubu meselesi var: onların talepleri kullanım hacminde neredeyse görünmez, gelir tablosunda ise tek başına belirleyici olur. O yüzden aynı veriyi en az iki farklı ölçütle sıralamak, tek bir Pareto grafiğine bakmaktan daha güvenli.

Kaynak daraldığında

Kuralın en dürüst kullanıldığı an, bütçe veya takvim kesildiğinde gelir. Kapsamın hangi parçasının ürünü ayakta tuttuğunu söylemek zorunda kalırsınız ve o an listenin gerçekten kaç maddesinin taşıyıcı olduğu ortaya çıkar. Peki ya yanlış %20'yi seçtiyseniz? Bunun maliyeti seçimin kendisinden değil, ne zaman fark edildiğinden gelir. Kısa aralıklarla ölçüp sırayı yeniden kuran bir ekip, yanlış tahmini birkaç haftada düzeltir; sırayı sezgiyle bir kez kurup sona kadar taşıyan ekip aynı hatayı sürüm boyunca öder.