Sayıların ardındaki mantık
Sürtünme, bir tasarım kusuru değil bir ölçüm bulgusudur. Bir yerde kayıp varsa orada sürtünme vardır; kaybın olmadığı yerde tasarım çirkin olsa da sürtünme yoktur.
Bu ayrım önemli çünkü ekipler genelde hoşlarına gitmeyen şeyleri sürtünme sanır. Oysa hangi noktanın gerçekten kaybettirdiğini yalnızca veri söyler.
Sürtünmenin biçimlerine göre alt başlıkları var: arayüz kaynaklı olan UX sürtünmesi, veri girişi kaynaklı olan form sürtünmesi. Burada odak, hepsini bulma yöntemi.
Nasıl bulunur?
| Yöntem | Ne söyler |
|---|---|
| Huni analizi | Nerede kaybediliyor |
| Oturum kaydı | Nasıl kaybediliyor |
| Anket | Neden kaybediliyor |
| Kullanılabilirlik testi | Nerede takılıyor |
| Destek kayıtları | Ne şikayet ediliyor |
İlk üç satır birlikte kullanılmalı. Huni nerede olduğunu söyler ama nedenini söylemez; kayıt nasıl olduğunu gösterir; sebebi ancak kullanıcının kendisi söyler.
Hangi sırayla düzeltilir?
- Hacimle çarpın. Küçük oran, büyük trafikte büyük kayıp.
- Maliyetle bölün. Ucuz ve etkili olan önce.
- Zorunlu adımlara öncelik verin. Herkesin geçtiği yer.
- Tek tek düzeltin. Toplu değişiklik ölçülemez.
- Ölçün. Düzeldiğini varsaymayın.
Uygulamada ne oluyor?
En sık hata, sürtünmenin fikirle belirlenmesi. Toplantıda "şurası kötü" deniyor ve orası düzeltiliyor; oysa veri bambaşka bir noktayı işaret ediyor olabiliyor.
İkinci gözlem, oranın hacimden koparılması. Yüzde iki kayıp küçük görünüyor ama herkesin geçtiği bir adımdaysa, karşılığı en büyük tekil kayıp olabiliyor.
Üçüncüsü, kolay olanın önce yapılması. Ekip düzeltmesi basit şeyleri seçiyor; etkisi büyük ama zahmetli olan sorun yıllarca duruyor.
Dördüncüsü, aynı anda çok şey değiştirilmesi. Beş düzeltme birlikte yayına alındığında hangisinin işe yaradığı hiçbir zaman öğrenilemiyor.
Beşincisi, düzeltmenin ölçülmemesi. Değişiklik yapılıyor, herkes iyi hissediyor ama öncesi–sonrası karşılaştırılmıyor; bazen sonuç daha kötü oluyor.
Altıncısı, her sürtünmenin zararlı sanılması. Bazı sürtünmeler bilinçlidir: onay adımı, ikinci doğrulama, iade formundaki soru. Bunlar hata azaltmak için oradadır.
Yedincisi, cihaz farkının atlanması. Masaüstünde sorunsuz bir adım telefonda ciddi bir engel olabiliyor; ölçüm ayrı yapılmalı.
Sekizincisi, yeni ve tekrar gelen kullanıcının karıştırılması. Siteyi bilen kişi sürtünmeyi hissetmiyor; ortalamaya bakıldığında yeni kullanıcının yaşadığı zorluk görünmez oluyor.
Dokuzuncusu, teknik yavaşlığın sürtünme sayılmaması. Geç açılan bir sayfa, kötü tasarlanmış bir formdan daha çok kaybettirebiliyor.
Onuncusu, destek kayıtlarının hiç okunmaması. Aynı soru yüzlerce kez soruluyorsa o sorunun cevabı arayüzde eksik demek; müşteri hizmetlerine gelen konu başlıkları hazır bir yol haritası sunuyor ve hiçbir maliyeti yok.
On birincisi, düzeltmelerin kalıcı olmaması. Yeni bir kampanya ya da özellik eklendiğinde eski sorunlar geri geliyor; belirli aralıklarla tekrarlanan bir kontrol listesi gerilemeyi engelliyor.
On ikincisi, bulguların bir yerde biriktirilmemesi. Her araştırmada aynı sorunlar yeniden keşfediliyor; oysa tespit edilen noktaların tek bir listede tutulması, hangilerinin çözüldüğünü ve hangilerinin hala beklediğini görünür kılıyor.
Neyi göstermez?
Sürtünmeyi gidermek, talebi büyütmez. İnsanlar ürünü istemiyorsa akışı kolaylaştırmak daha hızlı vazgeçmelerini sağlar sadece.
Sıkça sorulan sorular
Nereden başlamalıyım?
Huni analizinden. Nerede kaybettiğinizi bilmeden neyi düzelteceğinizi seçemezsiniz.
Her sürtünme kötü mü?
Değil. Onay ve doğrulama adımları hata azaltmak için bilerek konur.
Kaç değişikliği birlikte yapabilirim?
Ölçmek istiyorsanız bir tane. Beş değişiklik birlikte yayına alındığında hiçbiri öğrenilemez. Aynı süreçte karşınıza çıkabilecek Quick View, ürün listesinde bir ürünün detaylarını sayfaya gitmeden açılır pencerede hızlıca göstermeyi sağlayan özelliktir.
Bu kavramın bütün resim içindeki yerini Dönüşüm Takibi ve Ölçümleme Rehberi içinde ayrıntılı anlattım.
E-ticaret için ürün görseli, açıklama, güven alanı, beden/kargo/iade, yorumlar ve sepete ekleme oranı optimizasyonu.
