Rehber

Form tasarımı dönüşümü nasıl etkiler?

Formda kayıp küçük sürtünmelerin birikmesinden doğar. Hangi alanlar gereksiz, hata nasıl gösterilmeli, Türkiye'de rıza kutuları nasıl kurulmalı, etkisi nasıl ölçülür?

Fratres Editör · 11 Kasım 2026

Form tasarımı, bir formda hangi bilgilerin hangi sırayla isteneceği, alanların nasıl etiketleneceği, hatanın nasıl bildirileceği ve gönderimin nasıl tamamlanacağına dair kararların toplamıdır. Dönüşümü üç yoldan etkiler: kullanıcıdan istenen emek, hatayı fark edip düzeltme kolaylığı ve güven. Araştırmalar uzun akışların terk nedeni olduğunu, kurallara uyan formların ilk denemede belirgin biçimde daha çok tamamlandığını gösteriyor.

Form dönüşümü nerede kaybettirir?

Kayıp çoğu zaman tek bir büyük hatadan değil, küçük sürtünmelerin birikmesinden doğar. Ödeme akışlarını yıllardır test eden Baymard Institute, ABD'li çevrim içi alışverişçilerle yaptığı ankette terk nedenlerini sıralıyor. "Sadece bakıyordum" yanıtı dışarıda tutulduğunda katılımcıların %18'i siteden hesap açması istendiği için, %17'si akış çok uzun veya karmaşık geldiği için alışverişi bıraktığını söylüyor. %19'u kart bilgisini siteye emanet etmediğini belirtiyor. Üç neden de form tasarımının alanına giriyor: istenen emek, akışın belirsizliği ve güven.

Hata deneyimi de aynı yöne çalışıyor. Nielsen Norman Group, Seckler ve arkadaşlarının çalışmasını aktarıyor: Kullanılabilirlik ilkelerine uyan formlar ilk denemede %78 oranında hatasız gönderildi, ilkeleri çiğneyen formlarda bu oran %42'de kaldı. Tamamlama süresi de kısaldı. Sonucu değiştiren şey formun görüntüsü değil, hatanın önlenmesi ve kolay düzeltilmesi.

Bu sayılar e-ticaret ve kontrollü test ortamından geliyor. B2B teklif formu, randevu formu ya da üyelik formu farklı davranır. Yine de üç kayıp noktası her formda vardır ve ölçüm planını bu üçüne göre kurmak işe yarar.

Hangi alanlar gerçekten gerekli?

Baymard'ın 2024 ölçümüne göre ortalama ödeme akışında 11,3 form alanı bulunuyor. Kurum, çoğu sitenin toplamda 8 alanla işi bitirebileceğini söylüyor. Aynı çalışmada sitelerin %89'u ad için birden fazla alan kullanıyor. web.dev de ad ve soyadı ayrı saklamak için açık bir neden yoksa tek bir "Ad soyad" alanı öneriyor.

Bir alanın kalıp kalmayacağını şu üç soruyla tartın:

Bu bilgi olmadan işlem tamamlanır mı? Tamamlanıyorsa alan isteğe bağlıdır ya da hiç gerekmez.
Bilgi sonradan toplanabilir mi? Şirket büyüklüğü ya da ilgi alanı gibi sorular ilk görüşmede de sorulabilir.
Bilgiyi kim kullanıyor? Hiçbir raporda ya da satış adımında kullanılmayan alan yalnız emek ister.

B2B talep formlarında hesap farklıdır. Alanları azaltmak gönderim sayısını artırabilir ama satış ekibinin talebi elemek için ihtiyaç duyduğu bilgiyi de azaltır. Bu yüzden kararı yalnız form dönüşümüne bakarak değil, nitelikli talep oranıyla birlikte verin. Formdan gelen kaydın sonraki hayatı için CRM veri kalitesi yazısına bakabilirsiniz.

Zorunlu üyelik ayrı bir engeldir. web.dev, misafir olarak ödemeyi varsayılan yapmayı ve hesap açmayı satın almadan sonra önermeyi tavsiye ediyor.

Etiket, klavye ve hata mesajı nasıl kurulmalı?

Kullanıcı formu çoğu zaman bir kez görür ve telefondan doldurur. NN/g'nin önerileri bu yüzden basit kurallara dayanıyor: tek sütunlu düzen, alanın hemen yanında duran etiket, yer tutucu metin (placeholder) yerine kalıcı etiket, zorunlu ve isteğe bağlı alanların açıkça ayrılması, biçim kurallarının hata çıkmadan önce söylenmesi.

Teknik tarafta tarayıcıya doğru ipucunu vermek, kullanıcının yazacağı karakter sayısını azaltır. web.dev rehberi şu ayarları öneriyor:

E-posta ve telefon için type="email" ve type="tel" kullanın. Telefonda doğru klavye açılır.
Kart ve hesap numarası gibi alanlarda type="number" yerine inputmode="numeric" tercih edin.
Her alana uygun autocomplete değerini verin. Tarayıcı adı, adresi ve e-postayı kendisi doldurur.
Gönder düğmesini form eksik diye pasif bırakmayın. Yinelenen siparişi önlemek için ilk tıklamadan sonra kilitleyin.
Tarayıcıdaki kontrolün yanında sunucu tarafında da doğrulama yapın.

Hata mesajı ise zamanlama işidir. Baymard, Ocak 2024'te sitelerin %31'inde anlık alan doğrulamasının (inline validation) hiç bulunmadığını raporladı. Önerisi, alanı kullanıcı terk ettiğinde kontrol etmek, yazarken erken uyarı vermemek ve hata düzeltilir düzeltilmez mesajı kaldırmak. Mesaj neyin yanlış olduğunu ve nasıl düzeleceğini söylemeli, hatalı girdiyi silmemeli.

Erişilebilirlik dönüşümün parçasıdır

WCAG 2.2 formları doğrudan ilgilendiren ölçütler içerir. Girdi amacının yazılımca tanınması (1.3.5) otomatik doldurmayı da kolaylaştırır. Gereksiz tekrar girişi ölçütü (3.3.7), aynı süreçte daha önce verilen bilginin yeniden istenmemesini ister. Erişilebilir kimlik doğrulama ölçütü (3.3.8), giriş adımında bilişsel bulmaca dayatmayı sınırlar. Hedef boyutu ölçütü (2.5.8) dokunulacak öğeler için bazı istisnalarla en az 24 x 24 CSS pikseli şart koşar. Bu ölçütleri karşılayan form, engelli kullanıcı için erişim, diğer herkes için daha az hata demektir. Ayrıntılar web erişilebilirliği ve WCAG 2.2 yazısında.

Türkiye'de durum: Rıza metinleri ve telefon ekranı

Türkiye'de formun hukuki tasarımı 2026'da değişti. Kişisel Verileri Koruma Kurulu'nun 18 Şubat 2026 tarihli, 2026/347 sayılı ilke kararı 24 Mart 2026'da kamuoyuna duyuruldu. Kararın forma yansıyan dört sonucu var:

Aydınlatma, veri işlenmeden önce yapılır. Metin gönderimden önce görünür olmalı.
İşlem açık rızaya dayanıyorsa aydınlatma metni ile açık rıza metni farklı başlıklarda, ayrı metinler olarak sunulur. Aynı sayfadaysalar alt alta durur ve her biri için ayrı beyan alınır.
Aydınlatma metni için onay istenmez. Yalnız okunduğuna dair geri bildirim alınır.
İşlem başka bir hukuki sebebe dayanıyorsa yalnız aydınlatma yapılır, ayrıca rıza metni sunulmaz.

Tasarım açısından bu, birçok formdaki tek "okudum, onaylıyorum" kutusunun gözden geçirilmesi demek. Gereksiz kutu hem hukuki belirsizlik hem de fazladan emek yaratır. Kurul metinlerin sade ve kısa olmasını da istiyor. Bu bölüm genel bilgi verir, hukuki danışmanlık yerine geçmez.

İkinci yerel gerçek ekran boyutu. StatCounter verisine göre Ekim 2026'da Türkiye'de web trafiğinin %78,61'i mobil cihazlardan geldi. Ölçüm StatCounter kodunu taşıyan sitelere dayanır ve sizin oranınız sektöre göre değişir. Yine de formu önce telefonda tasarlamak için yeterli bir işaret. Telefon alanının boşluklu, başında sıfır olan ya da +90 ile yazılan numaraları kabul etmesi, kullanıcıyı tek bir yazım kalıbına zorlamaktan iyidir.

Formu adım adım nasıl iyileştirirsiniz?

Envanter çıkarın. En çok trafik alan formların her alanını listeleyin, yanına bu bilgiyi kimin ve hangi adımda kullandığını yazın.
Sadeleştirin. Kullanılmayan alanları kaldırın, ertelenebilenleri sonraki adıma taşıyın, ad alanlarını birleştirmeyi değerlendirin.
Etiketleri ve alan türlerini düzeltin. Her alana kalıcı etiket, doğru type, inputmode ve autocomplete değeri verin.
Hata akışını yeniden yazın. Alan terk edildiğinde kontrol edin, mesajı alanın yanında gösterin, düzeltilince kaldırın.
Rıza ve aydınlatma öğelerini ayırın. Metinleri hukuk danışmanınızla 2026/347 sayılı karara göre gözden geçirin.
Gerçek cihazda test edin. Formu bir telefonla, bir de yalnız klavyeyle doldurun. Sekme sırası, dokunma alanı ve otomatik doldurma çalışıyor mu, not edin.
Tek değişkenle karşılaştırın. Alan sayısını, düğme metnini veya adım sayısını ayrı ayrı test edin. Aynı anda üç şeyi değiştirirseniz hangisinin işe yaradığını bilemezsiniz.

Form reklam trafiği alan bir sayfadaysa reklam açılış sayfası yazısındaki ilkeler de geçerli. Formu ürün deneyiminin bütünüyle birlikte ele almak gerekiyorsa bu iş UI/UX çalışmasının doğal parçasıdır.

Etki nasıl ölçülür, nerede yanılırsınız?

Google Analytics 4'te gelişmiş ölçüm (enhanced measurement) açıksa iki olay kendiliğinden toplanır. Google'ın yardım sayfasına göre form_start, kullanıcı bir oturumda forma ilk kez dokunduğunda, form_submit form gönderildiğinde tetiklenir. Form adı ve kimliği gibi parametreleri raporda görmek için özel boyut tanımlamanız gerekir. Google, bu olaylarla kişisel veri toplanmamasını şart koşuyor.

Dört gösterge çoğu form için yeterli:

Başlatma oranı: Sayfayı görüp forma dokunan ziyaretçi payı. Düşükse sorun formdan önce, teklifte veya sayfadadır.
Tamamlama oranı: form_submit sayısının form_start sayısına oranı. Formun kendi sürtünmesini gösterir.
Alan bazında hata: En çok hata mesajı çıkan alan hangisi? Bunu özel bir olayla toplayın, girilen değeri değil yalnız alan adını kaydedin.
Nitelikli sonuç: Satış ekibinin uygun bulduğu talep veya tamamlanan sipariş oranı.

Gönderim olayı, kaydın sunucuda başarıyla oluştuğunu kanıtlamaz. Asıl dönüşümü başarılı kayda ya da teşekkür ekranına bağlayın. Olay adlarını tutarlı kurmak için GA4 olay yapısı yazısı yol gösterir.

Sık yapılan hatalar

Yer tutucuyu etiket yerine kullanmak. Yazmaya başlayınca kaybolur, kullanıcı neyi doldurduğunu unutur.
Bilgiyi iki kez istemek. web.dev, iletişim bilgisini ikinci kez yazdırmak yerine doğrulama kodu göndermeyi öneriyor.
Şifre alanına yapıştırmayı engellemek. Aynı rehber, parola yöneticilerinin önerdiği güçlü şifrelerin kabul edilmesini istiyor.
Hataları sayfanın en üstünde toplu göstermek. Kullanıcı sorunlu alanı aramak zorunda kalır.
Tamamlama oranını tek başarı ölçüsü yapmak. Form kısaldıkça talep sayısı artıp kalite düşebilir.
Testi masaüstünde bitirmek. Trafiğin çoğu telefondan geliyorsa sorunların çoğu da orada çıkar.

Yarın tek bir formla başlayın

En çok gönderim alan formunuzu açın ve her alanın yanına o bilgiyi kimin kullandığını yazın. Sahibi çıkmayan alanları işaretleyin. Ardından GA4'te aynı formun son 30 günlük form_start ve form_submit sayılarını yan yana koyun. Elinizde hem kaldırılabilecek alanların listesi hem de değişiklikten sonra karşılaştıracağınız bir başlangıç oranı olur. İlk testi bu listeden en az emek isteyen değişiklikle yapın. Bu ölçüm düzenini diğer sayfalara yaymak isterseniz dönüşüm oranı optimizasyonu aynı yöntemi bütün huniye uygular.