Mobil formlarda terk nedenlerini alan amacı, ekran yerleşimi, hata mesajları ve gönderim sonucuyla inceleyin. Kullanılabilirlik kontrol listesi.
Bir form masaüstünde düzgün görünürken telefonda doldurması zor olabilir. Klavye açıldığında düğme kaybolabilir, zorunlu alanın amacı anlaşılmayabilir veya kullanıcı hatayı düzeltince önceki bilgiler silinebilir. Daha kısa form tek başına çözüm değildir; kişinin doğru başvuruyu yorulmadan tamamlayabilmesi gerekir. Önce hangi bilgilerin neden istendiğini ve her adımda ne olduğunu inceleyin.
Her alanın başvuruda ne işe yaradığını yazın
Alanları satış veya operasyon ekibiyle tek tek gözden geçirin. Bilgi ilk değerlendirme için mi gerekiyor, sonraki görüşmede mi alınabilir, yoksa yalnızca alışkanlık nedeniyle mi soruluyor? Gereksiz zorunlulukları kaldırırken talebin doğru ekibe gitmesi için gereken bilgiyi koruyun. “Kısa olsun” hedefi, kişinin aynı bilgiyi telefonda yeniden anlatmasına yol açmamalıdır.
Örnek senaryo: Bir teknik servis formunda cihaz türü gerekli, ancak tam fatura adresi ilk görüşme için gerekmiyor. Cihaz türünü tutup adresi sonraki aşamaya almak mantıklı olabilir. Bu varsayımsal karar, her işletmede aynı alanların silinmesini önermez; bilginin kullanılacağı işlemi esas alır.
Ekranı klavye açıkken de değerlendirin
Formu yalnızca daraltılmış tarayıcı görüntüsüyle değil, kullanılan telefonlarda gerçek giriş yaparak inceleyin. Alan başlığı görünür kalıyor mu, sıradaki alan bulunabiliyor mu, sabit menü veya iletişim düğmesi formun üstüne geliyor mu? Uzun hizmet seçenekleri ve Türkçe karakterler gerçek içerikle denenmelidir.
Bir başvuruyu tek elle tamamlamayı, alanlar arasında ilerlemeyi ve yanlış seçimden geri dönmeyi kontrol edin. İlgisiz otomatik kaydırmalar veya sürekli açılan katmanlar kişinin yerini kaybetmesine neden olabilir. Form üzerindeki hareketler, markanın genel animasyon dilinden daha sakin tutulabilir. Öncelik, ziyaretçinin yazdığı bilgiyi ve sıradaki işi görmesidir.
Etiket, açıklama ve hata mesajını birlikte tasarlayın
W3C'nin form rehberi, kontrollerin anlaşılır etiketlere ve gerekli açıklamalara sahip olmasını ele alır. Bir alanın adı yalnızca yazı yazınca kaybolan yer tutucuya bırakılmamalıdır. Zorunlu bilgi ve beklenen biçim, kullanıcının ihtiyaç duyduğu yerde açıklanmalıdır.
Hata mesajı hangi bilginin düzeltilmesi gerektiğini söylemelidir. W3C'nin bildirim rehberi, başarısız ve başarılı sonuçların açık biçimde bildirilmesini önerir. “Bir hata oluştu” yerine ilgili alan ve düzeltme yolu gösterildiğinde kişi tekrar denemek için daha net bir başlangıç bulur. Gönderim gerçekleşmediyse gerçekleşmiş gibi bir teşekkür mesajı göstermeyin.
| Durum | Sorulacak soru | Kontrol sonucu |
|---|---|---|
| Alan seçiliyor | Ne yazılacağı anlaşılabiliyor mu? | Etiket ve kısa açıklamayı doğrulayın. |
| Klavye açılıyor | Aktif alan ve ilerleme yolu görülebiliyor mu? | Örtüşen sabit öğeleri kontrol edin. |
| Eksik bilgi var | Hata ve düzeltme yolu bulunabiliyor mu? | İlgili alana açık geri bildirim verin. |
| Gönderim sürüyor | Tekrar gönderim davranışı anlaşılır mı? | Durumu ve bekleme sonucunu kontrol edin. |
| İşlem tamamlanıyor | Kullanıcı sonraki adımı biliyor mu? | Gerçek sonuca uygun onay gösterin. |
Terki ve başvuru kalitesini birlikte takip edin
Değişiklik öncesinde formun hangi adımında sorun gözlendiğini kaydedin. Gönderim başlangıcı, başarı ve hata gibi davranışları kişisel alan içeriklerini toplamadan ölçülebilecek şekilde planlayın. Analitik sisteme serbest metin, telefon veya e-posta değerlerini gelişigüzel aktarmayın.
Düzenleme sonrasında yalnızca başvuru sayısına bakmayın. Uygun talep oranı, eksik bilgi nedeniyle yeniden iletişim ihtiyacı ve operasyon ekibinin geri bildirimi de önemlidir. Bir alanı kaldırdıktan sonra sayı artıyor ama başvurular yanlış ekibe gidiyorsa tasarımı yeniden değerlendirin. İyi mobil form hem ziyaretçinin işini hem işletmenin sonraki adımını kolaylaştırır.