Sayıların ardındaki mantık
Her alan bir karar ve bir yazma eylemi demektir. Ödeme adımında kullanıcı zaten karar vermiş durumdadır; bu noktadaki her ek soru saf bir gecikmedir.
Alanların çoğu da zorunluluk sanılarak duruyor. Bazıları yıllar önce eklenmiş, bazıları bir defa ihtiyaç duyulmuş; kimse hala gerekli mi diye sormamış.
Form optimizasyonundan farkı kapsamıdır: orada tasarım ve sıralama da vardır, burada tek soru şudur — bu alan silinebilir mi?
Hangi alanlar silinebilir?
| Alan | Durum |
|---|---|
| Şehir / ilçe | Posta kodundan türetilir |
| Kart tipi | Kart numarasından anlaşılır |
| Fatura adresi | Teslimatla aynıysa sorulmaz |
| Şifre | Misafir akışında gerekmez |
| Sipariş notu | İsteğe bağlı olmalı |
| İkinci telefon | Neredeyse hiç kullanılmaz |
Son satır tipik bir örnek. Bir kez yaşanan bir soruna karşı eklenmiş, sonra herkesin doldurduğu kalıcı bir yük haline gelmiş alanlar hemen her ödeme formunda bulunuyor.
Nasıl yapılır?
- Listeyi çıkarın. Kaç alan var, tam sayı nedir?
- Her birini savunun. Bu olmadan sipariş işlenemez mi?
- Türetilebilenleri silin. Sistemin bildiği şeyi sormayın.
- Sonraya erteleyin. Bazı bilgi sipariş sonrası alınabilir.
- Etkisini ölçün. Silmenin tamamlanmaya katkısını görün.
Uygulamada ne oluyor?
En sık gördüğüm durum, alan sayısının hiç sayılmamış olması. Ekip formda kaç alan olduğunu bilmiyor; sayı çıkarıldığında bile şaşırtıcı derecede yüksek oluyor ve tartışma orada başlıyor.
İkinci gözlem, alanların "her ihtimale karşı" tutulması. Nadiren işe yarayan bir bilgi için her müşteriye bedel ödetiliyor; o bilgi gerektiğinde sonradan da sorulabiliyor.
Üçüncüsü, fatura adresinin ayrı sorulması. Çoğu siparişte teslimatla aynı olduğu halde ikinci bir adres bloğu doldurtuluyor; varsayılan olarak aynı kabul etmek bu yükü tamamen kaldırıyor.
Dördüncüsü, şifre alanının ödeme akışına konması. Hesap açma zorunluluğu yaratılmadığında bu alan hiç gerekmiyor; hesap sipariş sonrası tek tıkla oluşturulabiliyor.
Beşincisi, isteğe bağlı alanların zorunlu görünmesi. Sipariş notu gibi alanlar diğerleriyle aynı biçimde durunca kullanıcı doldurması gerektiğini sanıyor.
Altıncısı, silme kararının veri olmadan verilmesi. Hangi alanın gerçekten kullanıldığı sipariş kayıtlarından görülebiliyor; hiç doldurulmayan bir alan tartışmasız silinebilir.
Yedincisi, operasyon tarafının sürece dahil edilmemesi. Depo ya da muhasebe bir alanı kullanıyor olabiliyor; silmeden önce sormak sonradan geri alma zahmetini önlüyor.
Sekizincisi, yasal zorunlulukların atlanması. Bazı bilgiler faturalandırma için gerekli; hepsi aynı gözle değerlendirilemiyor.
Dokuzuncusu, silmenin etkisinin ölçülmemesi. Alan kaldırılıyor ama tamamlanma oranındaki değişim izlenmiyor; kazanç görünmez kalıyor ve bir sonraki iyileştirme için argüman üretilemiyor.
Onuncusu, kurumsal müşterilerin unutulması. Vergi bilgisi gerektiren siparişler için ayrı bir akış kurulduğunda, bireysel müşteri o alanları hiç görmüyor.
On birincisi, alanların zamanla geri gelmesi. Her yeni özellik bir alan ekliyor; düzenli bir gözden geçirme olmadığında form birkaç yıl içinde eski haline dönüyor.
Neyi çözmez?
Alan azaltma, kargo bedeli sorununu çözmez. Kullanıcı maliyet yüzünden vazgeçiyorsa daha kısa bir form sadece daha hızlı vazgeçmesini sağlar.
Sıkça sorulan sorular
Hangi alan kesin silinebilir?
Sistemin türetebildiği her alan: şehir, ilçe, kart tipi. Sistemin bildiğini sormayın.
Nasıl karar veririm?
Sipariş kayıtlarına bakın. Hiç doldurulmayan bir alan tartışmasız silinebilir.
Hesap açtırmalı mıyım?
Ödeme adımında hayır. Hesap sipariş sonrası tek tıkla oluşturulabilir.
Bu kavramın bütün resim içindeki yerini Ürün Sayfası Optimizasyonu 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.
