Mobil Checkout: Hangi Tavsiye Hangisini Bozuyor
Mobilde ödeme akışında kaybedilen kullanıcı çoğu zaman ürünü beğenmediği için değil, formu dolduramadığı için gidiyor. Sık verilen tavsiyeler tek tek doğru görünüyor: sepet hep erişilebilir olsun, sipariş özeti hep görünsün, adım sayısı azalsın, misafir ödeme açık kalsın. Sorun şu ki hepsi aynı dar ekrana sığmak zorunda ve bir kısmı doğrudan birbirinin şartını bozuyor.
Sabit sepet, sabit özet, açık klavye
Tipik bir mobil tarayıcıda kullanılabilir yükseklik 640 ile 740 CSS pikseli arasında değişiyor. Üstte sabit başlık çubuğu 56, altta sabit sepet menüsü 56, araya yerleştirilen sipariş özeti kartı 100 piksel alıyor. Klavye açıldığında geriye kalan alan 250 pikselin altına iniyor. Yani kullanıcı adresini yazarken ekranda aynı anda iki form alanı görüyor, gerisi sizin arayüzünüz.
Peki özet gerçekten her an görünür mü olmalı? Ödeme akışına giren kullanıcı sepetini zaten kurmuş durumda, ona lazım olan tek sayı toplam tutar. Onu sabit bir kutuya değil, ödeme butonunun içine yazın: “1.248,90 TL Öde”. Sepete kısayol veren sabit alt menüyü de bu sayfada kaldırın; akışın ortasında geriye açılan bir kapı o.
Misafir ödeme ile cihazlar arası sepet aynı anda olmuyor
Sepetin telefonda başlayıp masaüstünde devam etmesi, kullanıcının hesapla giriş yapmasını gerektirir. Üyeliği zorunlu tutmamak ise sepet terkini azaltan en bilinen hamle. İki tavsiye çoğu rehberde yan yana duruyor, ama biri diğerinin ön koşulunu iptal ediyor.
Çıkış yolu sepeti tarayıcıya değil sunucuya bağlamak: anonim bir oturum belirteciyle sepeti sunucuda tut, kullanıcı sonradan giriş yaparsa iki sepeti birleştir. Hesap açma adımını da ödemenin öncesine değil sonrasına koyun. Sipariş tamamlandıktan sonra “şifre belirleyin, kargonuzu takip edin” demek, ödeme öncesinde kayıt formu göstermekten çok daha az direnç görüyor.
Otomatik doldurmayı bozan şey genelde işaretlemeniz
Kart numarasını tek bir input alanında toplarım. Dört ayrı kutuya bölmek ekranda düzenli duruyor, karşılığında tarayıcının kart doldurmasını ve iOS'un kamerayla kart okuma özelliğini devre dışı bırakıyor; ikisi de o kutucuklara değil, autocomplete="cc-number" taşıyan tek alana bakıyor.
Gerisi birkaç öznitelikten ibaret: son kullanma için cc-exp, güvenlik kodu için cc-csc, kart sahibi için cc-name, sayısal klavye için inputmode="numeric", telefonda type="tel", e-postada type="email". Kendi yazdığınız maskeleme kodu alanın değerini her tuş vuruşunda yeniden yazıyorsa otomatik doldurma sessizce çalışmaz hale gelir. Maskelemeyi her girdide değil, alan odaktan çıkınca uygulayın.
Posta kodunu sormak yerine siz üretin
Yaygın tavsiye şöyle işliyor: kullanıcı posta kodunu yazsın, il ve ilçe kendiliğinden dolsun. Türkiye'de bu ters yönde daha iyi çalışıyor, çünkü beş haneli kodunu ezbere bilen kullanıcı azınlıkta. Kodun ilk iki hanesi ilin plaka numarası olduğundan eşleme zaten tek yönde güvenli: il ve ilçeyi seçtirin, posta kodunu arka planda doldurun. Sokak ve bina bilgisi her koşulda elle yazılacak, zorunlu alan listesini de bununla sınırlayın.
Kargo ücretini geç göstermek sepeti terk ettiriyor
Kargo bedelinin son adımda belirmesi, ödeme akışının en pahalı sürprizi. Konum izni istemek çözüm gibi duruyor ama akışın ortasında açılan bir izin kutusu kullanıcıyı ürkütüyor, reddedildiğinde de elinizde hiçbir veri kalmıyor. IP üzerinden şehir tahmini izin istemeden çalışır ve kargo hesabı için yeterli hassasiyettedir. Ücretsiz kargo eşiğiniz varsa sepette doğrudan söyleyin: “750 TL üzeri kargo ücretsiz, 96 TL kaldı” satırı, ödeme adımındaki sürprizi baştan siliyor.
Ödeme yöntemi listesi kısaldıkça hızlanıyor
Apple Pay ve Google Pay'i formun en üstüne koymanın nedeni popülerlikleri değil: bu yöntemler kart bilgisini de teslimat adresini de cüzdandan getiriyor. Form optimizasyonunun en iyi hali, formu hiç göstermemek. Altına iki üç seçenek yeter. Kullanıcının geçen sefer seçtiği yöntemi hatırlayıp öne almak, listeyi uzatmaktan daha çok işe yarıyor.
Nerede düştüğünü ölçmeden düzeltmeyin
Checkout'u adım bazında ölçmek “üçüncü adımda kaybediyoruz” demekten öteye gitmiyor. Alan bazında ölçün: hangi input odaktan çıktığında doğrulama hatası döndü, kullanıcı hangi alana kaç kez geri geldi, klavye hangi ekranda açılıp kapandı. Suçlu çoğu zaman ödeme adımının bütünü değil, tek bir kırık alan oluyor; onu bulmadan yapılan her yeniden tasarım, aynı hatayı daha güzel bir arayüzle tekrarlıyor.