Peak-End Kuralı: Kullanıcı Neyi Hatırlar, Neyi Yaşar
Kullanıcı bir akışı baştan sona hatırlamaz. Aklında en yoğun bir iki an kalır, bir de işin nasıl bittiği. Peak-end kuralı tasarımda genelde yarısıyla uygulanıyor: bitişe kutlama animasyonu ekleniyor, akışın ortasındaki olumsuz zirve olduğu yerde duruyor. Sıra tersi olmalı.
Kuralın gerçekten söylediği şey
Kahneman, Fredrickson ve ekibinin 1993'teki soğuk su deneyi iki tur içeriyordu. Kısa turda katılımcılar elini 60 saniye 14 derece suda tuttu. Uzun turda aynı 60 saniyenin ardından su yavaşça 15 dereceye çekilerek 30 saniye daha devam etti. Yani uzun tur, nesnel olarak daha fazla rahatsızlık içeriyordu. Buna rağmen katılımcıların çoğu tekrar etmek için uzun turu seçti.
Buradan çıkan sonuç "sona güzel bir şey koy" değil. Hatırlanan deneyim, yaşanan anların toplamı değil; zirve ile bitişin ortalamasına yakın bir şey. Nielsen Norman Group'un konu özeti de kuralı bu çerçevede ele alıyor.
Süre neredeyse hiç sayılmıyor, ama bu izin değil
Deneyin ikinci bulgusu süre körlüğü: 30 saniyelik ek, hatırlanan değerlendirmeye zarar vermedi. Arayüz tarafında bu bulgu sık sık yanlış yere çekiliyor ve "akışı uzatmak sorun değil, nasılsa hatırlamıyorlar" diye okunuyor.
Kritik ayrım şu: deneydeki 30 saniye acılı kısımdan sonra geldi ve katılımcıdan hiçbir şey istemedi. Arayüzde kullanıcının hedefe ulaşmasından önce araya giren her ek ekran, kutlama kılığında olsa bile fazladan bir adımdır ve terk oranında görünür. Hatırlanan deneyimi iyileştirmek için ödediğiniz bedel, akışı hiç bitirmeyen kullanıcılar oluyor. Hedefe varıldıktan sonraki saniyeler serbest, öncesi değil.
Bitiş, sizin "başarılı" ekranınız değil
Ürün ekibi bitişi genelde son adıma koyar. Kullanıcı için bitiş, konuyla temasının fiilen kesildiği yerdir ve bu nokta çoğu zaman ürünün dışındadır: sipariş sonrası gelen kargo e-postası, iptal talebine dönen otomatik yanıt, faturanın PDF hali. Üç ekran boyunca özenilmiş bir akış, biçimlendirilmemiş bir işlem e-postasıyla kapanıyorsa hatırlanan son izlenim o e-postadır.
Teknik tarafta bunun klasik tuzağı iyimser arayüz: bir ödeme akışında başarı animasyonunu sunucu onayını beklemeden tetiklemiştik, banka reddettiğinde kullanıcının son gördüğü şey kutlamanın üzerine binen hata oldu. Başarı durumunu onay gelmeden boyamayın; kazandığınız 300 milisaniye, bozulduğunda akılda kalan tek an haline geliyor.
Önce olumsuz zirveyi kaldırın
İnsan hafızası olumsuz uçlara daha fazla ağırlık verir, dolayısıyla bütçenizin ilk dilimi oraya gider. Olumsuz zirve genelde gösterişli bir yerde değil, sıradan bir detayda durur:
- Doğrulama hatasında temizlenen form alanları, özellikle kart ve adres bilgisi
- Ne yapılacağını söylemeyen hata metinleri ("İşlem gerçekleştirilemedi")
- Kullanıcıda çift ödeme kuşkusu bırakan belirsiz bekleme durumları
- Geri dönüşü olmayan adımlar: silme, iptal, geri alınamayan gönderim
Bunların hiçbiri animasyonla kapatılamaz. Akışın ortasında yaşanan bir olumsuz zirve, sondaki teşekkür ekranıyla dengelenmiyor; yalnızca kullanıcının anlatacağı hikâyeye iki tepe birden ekliyor.
Ölçüm iki ayrı kolonda
Peak-end etkisi funnel metriklerinde görünmez. Tamamlama oranı, adım süresi ve öfke tıklaması yaşanan deneyimi ölçer; hatırlanan deneyim ise işlemden sonra sorulan memnuniyet, geri dönme ve tekrar sipariş davranışında ortaya çıkar. İki kolonu ayrı tutmazsanız bitiş anına yapılan iyileştirmenin karşılığını hiç göremezsiniz.
Pratik kurulum basit: terk oranını adım bazında izleyin, memnuniyeti son temastan sonra sorun. Bir adımda düşüş varsa cevap o adımın içindedir. Düşüş yokken memnuniyet düşükse bakacağınız yer sondaki an, yani çoğu zaman e-posta, bildirim ya da ekibinizin akışın parçası saymadığı bir ekran.