Form Tasarımı En İyi Pratikleri: Web ve Mobil için 10 Kural
Dönüşüm getiren formlar tasarlamanın 10 kuralı. Notion, Tally ve Mercury kayıt akışlarının gerçek incelemeleri ve gerçekten işe yarayan mobil öncelikli kalıplar.

Form Tasarımı En İyi Pratikleri: Web ve Mobil için 10 Kural
Kötü bir formun maliyeti
Kötü bir form, birini sayfaya getirmek için harcadığınız her dolara kesilen bir strateji vergisidir. Kayıt, ödeme ve onboarding formlarında tamamlama oranları, sürtünme varken ortalama %12 civarındadır. Sürtünmeyi kaldırın, o rakam %50'nin üzerine çıkar.
Fark neredeyse hiçbir zaman metin ya da marka değildir. Tutarlı uygulanan on kuraldır.

Salesforce tarzı 30 alanlı lead formları, biri bir veritabanı şemasını sayfaya yapıştırıp adına form dediği için var. Kullanıcı bunun için kayıt olmadı. Ürün için geldi ve sizin nitelendirme mantığınız lead'i kaybettirdi.
Kural 1: Tek sütun, ekran başına tek görev
Her zaman tek sütun. Çok sütunlu yerleşimler Figma ızgarasında verimli görünür, ama ekranda tamamlama oranlarını öldürür.
Göz soldan sağa okur ve süreklilik bekler. Alanlar iki sütuna bölündüğünde kullanıcı hangi yolu izleyeceğine karar vermek zorunda kalır ve tek bir karakter yazmadan önce bu mikro karar sürtünme yaratır.
Notion'ın kayıt akışı, mobilde her seferinde tek alan öne çıkan, ortalanmış tek bir sütundur. Form hızlı hissettirir çünkü tek şey ister. Kural bu.
Kural 2: Etiket konumu, etiket stilinden daha önemlidir
Etiketler alanın üstüne gelir. İçine değil, yanına değil. Üstüne, her zaman görünür.
Etiket olarak kullanılan placeholder metni, kullanıcı yazmaya başladığı anda kaybolur. O noktada neyi doldurduğunu hatırlamak için alanı temizlemesi gerekir. Mercury'nin onboarding akışı her girdide alanın üstünde kalıcı etiketler kullanır, böylece doldurma sırasında bağlam asla kaybolmaz.

Odaklanıldığında placeholder konumundan yukarı doğru kayan kayan etiketler kabul edilebilir bir orta yoldur, ama erişilebilir olmaları için sıkı kontrast ve dikkatli zamanlama gerekir. Tereddüt ediyorsanız etiketi üste koyun ve orada bırakın.
Etiket yerleşiminin ardındaki UX araştırması, UX araştırma yöntemleri rehberimizde ayrıntılı ele alınıyor.
Kural 3: Alan sırası kullanıcının gerçekliğini izler, veritabanı şemasını değil
Alanlarınızın sırası, mühendislerin veri modelini nasıl yapılandırdığına değil, bir insanın görevi nasıl düşündüğüne uymalı.
Sepeti onaylamadan önce teslimat adresi isteyen bir ödeme formu, bağlam yükünü kullanıcıya bindirir. Barındırılan ödeme formu UX'i için kanonik referans olan Stripe Checkout, formu üç adımda sıralar:
- E-posta (kimsiniz)
- Ödeme (nasıl ödeyeceksiniz)
- Adres (nereye gidecek)
Makul bir insanın yüz yüze kullanacağı sıra bu. Alan sırasını veritabanı belirlediğinde, ülkeden önce posta kodu ya da şirket adından önce iş unvanı soran formlar çıkar.
Kural 4: Satır içi doğrula, asla gönderimde değil
Alanı, kullanıcı ondan ayrıldığı anda doğrulayın, gönder'e bastığında değil.
Gönderimde doğrulama, kullanıcının on alanlı bir formu doldurup butona basması ve bir kırmızı hata duvarıyla karşılaşması demektir. Her hata bir düzeltme görevidir ve her düzeltme görevi kullanıcıyı tamamen kaybetme riski taşır. Blur anında tetiklenen satır içi doğrulama, hatayı kullanıcı ilerlemeden önce gösterir.
Apple ID girişi, e-posta biçimini blur anında doğrular ve gönder butonu aktif olmadan önce hesabın kullanılabilirliğini teyit eder. Bu sıralama iki hata kategorisini birden önler. Bunun arkasındaki etkileşim kalıpları mikro etkileşim tasarımı rehberimizde ele alınıyor.
Kural 5: Mobil öncelikli demek mobil klavyeler demek
Her alan türü doğru klavyeyi çağırmalı. Mobil form tasarımının %80'i bu.
Bir alan telefon numarası istiyorsa ve varsayılan metin klavyesi açılıyorsa, kullanıcı daha bir şey yazmadan form bozuktur. Sayısal alanlarda inputmode="numeric", @ tuşunu öne çıkarmak için type="email", fiyatlar için inputmode="decimal" kullanın. iOS ve Android girdi modlarının tamamını destekler.
Mobilde birincil girdi aygıtı klavyedir. Yanlış olanı belirtmek, doğru tasarlanmış görsel bir formu sinir bozucu hale getirir.
| Alan Türü | Doğru HTML Özniteliği |
|---|---|
| E-posta | type="email" |
| Telefon | type="tel" |
| Tam sayı | inputmode="numeric" |
| Ondalık / fiyat | inputmode="decimal" |
| URL | type="url" |
| Arama | inputmode="search" |
Bu kalıpların oturduğu daha geniş mobil öncelikli temel için duyarlı web tasarımı temellerine bakın.
Kural 6: İlerleme, mikro metin ve uzun form sorunu
Form beşten fazla alan gerektiriyorsa, kullanıcıya akışın neresinde olduğunu gösterin.
Airbnb'nin çok adımlı rezervasyon akışı, boyunca adları olan bir ilerleme göstergesi sunar. %60 tamamladığını görebilen kullanıcılar, hiçbir referans noktası olmayanlara göre ölçülebilir şekilde daha fazla bitirir.

Tally, gömülebilir formlarında farklı bir yaklaşım izler: üstte kalıcı bir ilerleme çubuğuyla her seferinde tek soru. Bu, belgelenmiş kullanıcı testlerinde tek sayfalık uzun formlardan sürekli daha iyi performans gösteriyor.
Mikro metin de aynı işi yapar. "4 adımın 2'si", çıplak bir ilerleme çubuğundan daha dürüsttür. "Kimliğinizi doğrulamak için buna ihtiyacımız var", etiketsiz hassas bir alandan daha yararlıdır.
Kural 7: Hata mesajları talimattır, suçlama değil
Hata mesajlarını suçlama kipinde değil, emir kipinde yazın.
"Bu alan zorunludur" bir suçlamadır. "Devam etmek için e-posta adresinizi girin" bir talimattır. Kullanıcı bir şeylerin ters gittiğini zaten biliyor. İhtiyaç duyduğu şey çözüm.
En iyi hata metni tam durumu ve tam eylemi söyler: "Parola en az 8 karakter olmalı ve bir rakam içermeli." Stripe Checkout bunu tam olarak yapar. Mesaj blur anında çıkar, sorunu adlandırır ve koşul çözüldüğü anda kaybolur.
Oyalanan bir kırmızı durum yok. Sadece çalışıyor.
Kural 8: Otomatik doldurma bir özelliktir, sonradan akla gelen değil
autocomplete özniteliği tarayıcıya neyi dolduracağını tam olarak söyler. Her alanda kullanın.
Doğru autocomplete öznitelikleri olan bir ödeme formu, kayıtlı verisi olan bir telefonda yaklaşık 12 saniyede tamamlanır. Onlar olmadan aynı form iki dakika sürer, çünkü kullanıcı her şeyi elle yazar. Mobil ödeme terklerinin çoğu bu 108 saniyelik boşlukta yaşar ve onu kapatmak hiçbir şeye mal olmaz. UI bileşen kütüphanesi rehberi, bu öznitelikleri tasarım sisteminizin form bileşenlerine nasıl gömeceğinizi anlatır, böylece asla eksik kalmazlar.
| Alan | autocomplete Değeri |
|---|---|
| E-posta | email |
| Ad | given-name |
| Soyad | family-name |
| Telefon | tel |
| Sokak adresi | street-address |
| Şehir | address-level2 |
| Posta kodu | postal-code |
| Kart numarası | cc-number |
| Kart son kullanma tarihi | cc-exp |
Kural 9: Gönder butonu her şeyi belirler
Gönder butonu sözleşmedir. Etiketi, durumu ve konumu, kullanıcının sonrasında olacaklara güvenip güvenemeyeceğini gösterir.
Açıklamasız gri bir buton, kullanıcıya formun bozuk olduğunu ama nedenini söylemez. Bu çıkmaz sokaktır. "Gönder" yazan bir buton ise neyi kabul ettiklerini hiç anlatmaz.
"Hesabımı oluştur", "Ücretsiz denememi başlat" ve "Kurmaya başla" hepsi daha dürüsttür. Butonu yalnızca nedenini arayüzde açıklayabiliyorsanız devre dışı bırakın. Tally, form oluşturucusunda her adımda eyleme özgü buton metni kullanır ve bu, gömülü B2B akışlarındaki ortalamanın üzerindeki tamamlama oranlarına doğrudan katkı sağlar.
Kural 10: Gerçek başparmaklarla, gerçek veriyle, gerçek gecikmeyle test edin
Bir formu hızlı wifi üzerinde masaüstü tarayıcıda test etmek, işe yarayıp yaramadığı hakkında anlamlı hiçbir şey söylemez.
Orta segment bir Android cihazda, 4G bağlantıda, her alanda gerçek uzunlukta verilerle test edin:
- Aksanlı karakter içeren bir isim
- İkinci satırında daire numarası olan bir adres
- 22 karakterlik bir e-posta
- 1 karakterlik bir ad
Gerçek dünya uç durumları, Figma'da temiz görünen formları bozar. Gerçek gecikme, doğrulama çağrılarının girişi engelleyip engellemediğini ya da asenkron çalışıp çalışmadığını ortaya çıkarır. Bu fark tarayıcı simülatöründe görünmez, iki çubuk sinyalli bir telefonda ise felakettir.
Kayıt, ödeme ya da onboarding akışınız için form denetimi mi lazım? Brainy, on kurallık denetimin tamamını gerçek ekranlarda, gerçek verilerle ve gerçek dönüşüm rakamlarıyla yapar.
Tasarımcılar en kötü formları hâlâ nerede yayınlıyor
Bugün canlıdaki en kötü formlar üç kalıbı paylaşıyor:
- Kurumsal satış lead formları: Zorunlu "yıllık gelir" seçicileri olan ve satır içi doğrulaması bulunmayan Salesforce tarzı 30 alanlı nitelendirme ekranları
- İlerlemeyi kaydetmeyen çok adımlı onboarding akışları: 9 adımın 7'sinde gelen bir telefon görüşmesi kullanıcıyı 1. adıma geri gönderir
- Mobil birincil olmadan önce kurulmuş, hiç yeniden yapılmamış ödeme akışları: "masaüstünde gayet iyi çalışıyor" diye her sayısal alan hâlâ
type="text"kullanıyor
Üç durumda da hata durumu tercihleri kontrast gereksinimlerini karşılamamaya meyilli; erişilebilir renk kontrastı kalıpları bu belirli kırılma noktasını düzeltir.
Üçünün ortak noktası: form, sistem için tasarlanmış, onu dolduran kişi için değil. Çözüm de aynı.
On kuralı uygulayın. Mobille başlayın. Veritabanı kendi şemasını kendi halletsin.

SSS
Bir formda kaç alan olmalı?
Sonucun gerektirdiği kadar az. Doğru sayı, bir tane daha çıkarsanız ürünün bozulacağı sayıdır. Eklediğiniz her alan tamamlama oranını düşürür. Sıfırdan başlayın ve yalnızca zorunlu olanı ekleyin.
Çok adımlı mı yoksa tek sayfalık form mu kullanmalıyım?
Beşten fazla alan için çok adımlı neredeyse her zaman tek sayfalıktan iyi performans gösterir. Şart, görünür ilerlemedir. Bu olmadan çok adımlı formlar tek sayfalıktan kötü çalışır, çünkü kullanıcı yolculuğun ne kadar süreceğini bilmez. Adımları adlandırın ve dizide nerede olduklarını gösterin.
Zorunlu alanları işaretlemenin en iyi yolu nedir?
Zorunluları değil, isteğe bağlıları işaretleyin. Alanların çoğu zorunluysa (yukarıdaki kurala göre öyle olmalı), her alanı kırmızı bir yıldızla işaretlemek görsel gürültüdür.
İstisnaları işaretleyin. Bir alanın yanındaki "İsteğe bağlı" anlamlı bir bilgidir. Her alanın yanındaki yıldız değildir.
Kullanıcıyı cezalandırmadan parola gereksinimlerini nasıl ele alırım?
Gereksinimleri kullanıcı yazmaya başlamadan önce gösterin, başarısız olduktan sonra değil. Her koşul sağlandıkça aktifleşen küçük bir kontrol listesi, gönderim sonrası hata duvarından daha iyi performans gösterir. Apple ID ve güncel kimlik doğrulama akışlarının çoğu bu kalıbı kullanır. Geri bildirim canlı, olumlu ve asla cezalandırıcı değildir.
Alan genişliği bir şey anlatır mı?
Evet, ve kullanıcılar bunu okur. Alan genişliği beklenen girdi uzunluğunu işaret eder. Kısa bir alan kısa bir cevap, tam genişlikte bir alan daha uzun bir cevap demektir.
Yerleşim izin veriyorsa alan genişliğini beklenen girdi uzunluğuna uydurun. Tam genişlikte bir posta kodu alanı hata gibi görünür. Sokak adresi için bir metin alanı ise gereğinden fazla görünür. Kapsayıcıyı beklenen içeriğe uydurun.
Mobil form terkine en çok ne yol açar?
Bir numara yanlış klavye türüdür. İki numara çalışmayan otomatik doldurmadır. İkisi de sessiz hatalardır: form doğru görünür, kullanıcı sadece onu verimli şekilde tamamlayamaz.
İkisini de alan başına iki öznitelikle düzeltin. Yatırım 15 dakika. Getirisi aynı sprint içinde ödeme dönüşümünde ölçülebilir.
Need a form audit on your sign-up, checkout, or onboarding flow? Brainy runs the full ten-rule audit on real screens, real data, and real conversion numbers.
Get Started




