Karar Akışında Sludge: Seçeneği Azaltmak Her Zaman İşe Yaramaz
Sludge, kullanıcıyla yapmak istediği şey arasına giren gereksiz sürtünmedir: fazladan onay ekranı, birbirinden ayırt edilemeyen iki plan, sonucu görünmeyen bir adım. Bu sürtünmeyi azaltmak genelde “seçenek sayısını düşür” diye özetlenir, oysa belirleyici olan sayı değil ayırt edilebilirlik. İki seçenek arasındaki farkı tek cümleyle anlatamıyorsanız, listeyi üçe indirmek de kullanıcıyı hızlandırmaz.
Gruplamak kararı her zaman kolaylaştırmaz
Yirmi maddelik bir listeyi dört başlık altında beşerli gruplara böldüğünüzde seçenek sayısı azalmaz, karar sayısı ikiye çıkar. Hick yasasının basit halinde karar süresi log2(n+1) ile büyür. Düz listede log2(21), yaklaşık 4,39 birim. Gruplanmış halde önce dört başlık arasından seçim (log2 5 ≈ 2,32), sonra grup içinde beş madde (log2 6 ≈ 2,58): toplam 4,90. Yani başlıklar okunup üzerinde düşünülüyorsa gruplama akışı yavaşlatır.
Kazanç sadece başlık seçimi düşünmeden, tanıyarak yapıldığında ortaya çıkar. Pratik ayrım şu: “Bireysel / Kurumsal” işe yarar, çünkü kullanıcı hangisine ait olduğunu bilir. “Standart / Gelişmiş” yaramaz, çünkü kendisinin hangisi olduğunu ancak içeriği okuyunca anlar. İkinci durumda gruplama, sadeleştirme değil ek bir engeldir.
En hızlı karar, sorulmayan karardır
Akıştaki her alanı tek soruyla eleyin: makul bir varsayılan var mı? Varsa sormayın, varsayılanı uygulayın ve sonradan değiştirilebilir bırakın. Fatura adresi teslimat adresiyle aynıdır, para birimi ülkeye göre gelir, bildirim tercihleri açık başlar. Bunları tercih ekranına taşımak kullanıcıya kontrol vermez, karar yükü verir.
Geri alınabilirlik de aynı şekilde işler. Geri alınabilen bir adımın önüne onay ekranı koymayın; onay yerine sonucu gösterin ve geri alma bağlantısını yanına bırakın. Onay ekranını gerçekten geri dönüşü olmayan yerlere saklayın, yoksa kullanıcı hepsini okumadan geçmeyi öğrenir ve önemli olanı da kaçırır.
Belirsizlik seçeneklerde değil, adlandırmada birikir
Kullanıcı çoğu zaman seçeneklerin çokluğunda değil, ne anlama geldiklerini bilmediği için takılır. Kargo ücretinin ödeme adımında belirmesi, planın hangi limitle geldiğinin ayrı bir sayfada durması, buton metninin “Devam” olması: üçü de aynı hatanın türevi. Kararın verildiği yerde karar için gereken bilgi bulunmuyor.
Karşılaştırma tablosu bu boşluğu kapatabilir, ama kendisi de bir adımdır. Kullanıcıyı listeden tabloya, tablodan tekrar listeye gönderiyorsanız temizlemeye çalıştığınız tortuyu yeniden üretmiş olursunuz. Tabloyu seçeneklerin yerine koyun, yanına değil.
Nerede takıldığını ölçmeden sadeleştirme yapmayın
Adım bazlı terk oranını görmeden yapılan sadeleştirme tahmindir, çoğu zaman da yanlış adımı hedefler. Her adımın girişine ve tamamlanmasına birer olay kaydı düşürüp adım numarasına göre saymak yeterli; bunun için üçüncü parti bir analitik aracına gerek yok, birkaç satır log ve tek bir gruplama sorgusuyla ilk tabloyu çıkarırsınız. Aradığınız şey basit: hangi adımda giren sayısıyla çıkan sayısı arasındaki fark açılıyor.
A/B testine geçtiğinizde tek bir teknik ayrıntıya dikkat edin. Varyant atamasını oturuma değil kullanıcı kimliğine sabitleyin. Dönen kullanıcıyı her ziyarette başka bir akışa düşürürseniz, ölçmeye çalıştığınız sürtünmeyi kendiniz üretirsiniz ve sonuç arayüzün değil tutarsızlığın etkisini gösterir.