Web Sitesi İhtiyaç Analizi: Formlar, Onaylar ve Veri Toplama

Formlar, onaylar ve veri toplama; bir web sitesinin “etkileşimli” hale geldiği, yani ziyaretçinin davranışını ölçülebilir bir sonuca dönüştürdüğü en kritik katmandır. Dönüşüm hunilerinin kalbi burada atar: randevu talebi, demo başvurusu, teklif isteme, bülten kaydı, bağış, alışveriş, üyelik, destek bileti, geri bildirim… Ne var ki çoğu projede form tasarımı, canlıya yakın sprintlerde “Bu alan da zorunlu olsun mu?” gibi son dakika sorularına sıkışır; onay metinleri ise hukuk ekibinden kopyalanıp yapıştırılan uzun paragraflarla geçiştirilir. Sonuç: uzun, yavaş, güvensiz, erişilebilir olmayan ve dönüşüm kaybı yaratan akışlar.

1) Stratejik mandat: İş hedefi → Form amacı → Alan mimarisi
İhtiyaç analizinde temel soru şudur: Bu form hangi iş sonucunu üretecek?
-
Makro hedef: Demo başvurusu, ödeme, randevu, teklif, üyelik.
-
Mikro hedef: Bülten, şablon indirimi, geri bildirim, bekleme listesi.
-
Alan seçimi ilkesi: “Bu alan olmadan iş hedefi tehlikeye girer mi?” Cevap “hayır” ise alan opsiyonel ya da sonraki adımda sorulmalıdır.
Örnek olay: Bir B2B SaaS projesinde “telefon” alanı ilk adımda zorunluydu; form terk yüksekti. Telefonu ikinci adımda, takvim onayı ekranına taşıdık. Sonuç: Başvuru sayısı arttı; satış ekibi görüşme sırasında telefon doğrulaması yaptı.
2) Kısa akış, derin nitelendirme: İki aşamalı form mantığı
Tüm soruları tek ekranda yığmak yerine;
-
Adım 1 (amaç): Başvuruyu başlatan minimum alanlar (ad, e-posta, tek soru).
-
Adım 2 (nitelik): Persona/segment soruları, kullanım senaryosu, bütçe aralığı (opsiyonel).
-
Zamanlama: “Tamamlanması 2 dakika” gibi dürüst bir süre vaadi güven sağlar.
Örnek olay: Demo formu 8 alandan 3 + 4 (ikinci adım) modeline çekildi. Sonuç: İlk adım tamamlama oranı yükseldi, toplam nitelik kaybı yaşanmadı; satış pipeline’ı daha hızlı aktı.
3) Doğrulama ve hata dili: Empati + yön + hız
-
Anında ama sakin: Yazarken doğrulama (“live validation”) gürültü üretmeden bildirmeli; hata mesajı kısa ve çözüm odaklı olmalı.
-
Yerinde açıklama: “Şirket e-postası kullanın” gibi bağlamsal ipuçları.
-
Kalıcı alan: Hata çıktığında sayfa kaymamalı; sabit bir hata bölgesi olmalı (CLS’e dikkat).
Örnek olay: “Geçersiz e-posta” yerine “Lütfen geçerli bir e-posta girin: ornek@site.com
4) Erişilebilirlik: Herkes için doldurulabilir formlar
-
Doğru etiketleme:
label–alan eşleşmeleri ve ekran okuyucu dostu açıklamalar. -
Odak halkası: Klavye ile gezilebilir; TAB sırası anlamlı.
-
Hata duyurusu:
aria-livebölgeleriyle sesli uyarı. -
Okunabilir metin: 9.–10. sınıf düzeyinde, kısa cümleler.
Örnek olay: Erişilebilir hata mesajlarıyla (ekran okuyucuya dost) kamu başvuru formu tamamlama oranı yükseldi; çağrı merkezi yükü azaldı.
5) Mikro kopya: Korkuyu azaltan küçük cümleler
-
Güvence: “Kart gerekmez”, “İstediğiniz zaman iptal edebilirsiniz”.
-
Şeffaflık: “Sizi haftada 1 e-posta ile bilgilendireceğiz; tek tıkla ayrılabilirsiniz.”
-
Zaman: “2 dakikada tamamlayın” veya “Sadece 3 soru”.
Örnek olay: “Teklif iste” formunda “24 saat içinde cevap” notu eklendi; gönderimler arttı, memnuniyet yükseldi.
6) KVKK/GDPR uyumu: Onay metinleri ve tercih merkezi
-
Aydınlatma: Kısa, açık; detay sayfasına köprü.
-
Onay kutuları: Ayrık onaylar (hizmet/üyelik onayı ≠ pazarlama izni). Ön işaretli olmamalı.
-
Tercih merkezi: Kullanıcı sonradan onay durumunu kolayca değiştirebilmeli.
-
Veri minimizasyonu: “İşlem için gerekli” olan dışında veri toplama yok.
Örnek olay: Pazarlama izni kutusu onaydan ayrılınca bülten listesi küçüldü ama spam şikâyetleri dramatik şekilde azaldı; teslim edilebilirlik (deliverability) iyileşti.
7) Gizlilik ve güven dili: Onayların yanında güven inşa etmek
-
Kısa notlar: “Verileriniz Türkiye/AB içinde barındırılır.”
-
Güvenlik: “TLS 1.3 şifreleme; ödeme sağlayıcısı sertifikalı.”
-
İade/iptal: Ticari formlarda koşullar özetlenmeli, detaya link verilmeli.
Örnek olay: Checkout formunda “Ödeme güvenlidir” yerine “Ödeme sağlayıcımız X, kart bilginiz sistemimizde tutulmaz” dendi; terk oranı düştü.
8) Performans ve Core Web Vitals: Hızlı görünen, hızlı yanıt veren form
-
LCP: Formun ilk ekranındaki değer teklifi ve giriş alanı hızla görünür olmalı.
-
INP: Tıklama ve alan geçişlerinde gecikme ≤ 200 ms (P75) hedeflenmeli.
-
CLS: Hata/yardım metinleri alana yer ayırarak açılmalı, kayma yapmamalı.
-
Üçüncü taraf: Rıza yoksa pazarlama/heatmap/deney skriptleri yüklenmemeli.
Örnek olay: “Tıklayınca yükle” yaklaşımıyla takvim ve harita bileşenleri gecikmeli çağrıldı; form cevap süresi hızlandı.
9) Mobil öncelikli mikro akışlar: Başparmak ergonomisi
-
Alan sırası: En kritik alanlar yukarıda; klavye tipleri (sayı/tarih).
-
Yapışkan CTA: “Gönder” veya “Devam” butonu başparmak hizasında.
-
Otomatik tamamlama: Adres, e-posta, ülke seçimi için yerleşik özelliklerden yararlanın.
Örnek olay: Mobilde numara klavyesi tetiklenince yanlış girişler azaldı; hız ve tamamlama arttı.
10) Çok dilli/çok ülke: Dil, para birimi ve hukuk
-
Dil eşdeğeri: Onay metinleri ve aydınlatmalar anlam eşdeğeri ile çevrilmeli.
-
Para birimi/vergi: Ticari formlarda yerel notasyon ve vergi bilgisi net verilmeli.
-
Hreflang: Doğru varyanttan gelen kullanıcı doğru form diline inmeli.
Örnek olay: Almanca varyantta “vergi dahil” ifadesi açık yazıldı; iade talebi ve sepette itirazlar azaldı.
11) Çok lokasyon/SAB: Yerel sinyaller ve rota/çağrı
-
Şube formu: “Randevu al” yanında “Ara” ve “Rota al” kısa yolları.
-
Açılış saatleri: İlk ekranda görünür; tatil saatleri senkron.
-
Yerel gizlilik: Bölgesel hukuki metin ekleri (ör. yerel veri sorumlusu).
Örnek olay: Sağlık kliniğinde şube formu + WhatsApp kısa yolu ile randevu oranı yükseldi; telefon trafiği dengelendi.
12) B2B/B2C farkları: Nitelendirme ve hız dengesi
-
B2B: İlk adım hafif → takvim/demoda nitelendirme; unvan/şirket büyüklüğü ikinci adım.
-
B2C e-ticaret: Konuk ödeme, yalnız teslimat için zorunlu bilgiler; hesap açma sonra önerilir.
-
Kamu/üniversite: Zorunlu alanların hukuki dayanağı aydınlatmada kısa yazılır.
Örnek olay: B2B’de 7 zorunlu alan → 3 zorunlu + 4 opsiyonel; demo sayısı ve kalitesi birlikte arttı.
13) Dosya yükleme ve karmaşık bileşenler: Yük hafifleten çözümler
-
Belge talebi: Tek adımda hepsini istemek yerine, akış içinde koşullu isteyin.
-
Ön izleme: Dosya yüklendiğinde küçük özet/isim; maksimum boyut ve kabul edilen türler net.
-
Gizlilik: Kişisel belge yükleniyorsa saklama süresi ve erişim yetkisi metinle açıklansın.
Örnek olay: Üniversite başvurusunda belge yükleme adımı “son”a alındı; terk azaldı.
14) Captcha/anti-spam: Güvenlik–kullanılabilirlik dengesi
-
Görünmez/risksiz: Davranışsal filtreler, e-posta doğrulama veya tek tık çözümler tercih edilmeli.
-
Metin destek: Erişilebilir alternatif; görme engelliler için ses veya kolay görevler.
-
Orantı: Basit bülten formuna ağır captcha koymayın.
Örnek olay: Aşırı kaptça kaldırıldı; spam firewall katmanıyla çözüldü; gerçek gönderimler arttı.
15) Onay türleri: Zorunlu, sözleşmesel, opsiyonel pazarlama
-
Zorunlu onay: Hizmet ilişkisi için zaruri (üyelik şartları kabulü).
-
Opsiyonel: E-posta/SMS pazarlama izni; ayrı kutularla.
-
İnce ayrım: “Profil çıkarma/kişiselleştirme izni” gibi ek onaylar açıkça ayrılmalı.
Örnek olay: Pazarlama izni, “bültene özel özetler” vaadiyle açıklanınca kalite yükseldi; tek tıkla ayrılma oranı ölçülebilir hale geldi.
16) Tasarım sistemi: Form bileşen kütüphanesi
-
Standardizasyon: Girdi, seçim, tarih, yükleme, hata bölgesi, onay şeridi, başarı ekranı—tek tasarım dilinde.
-
Varsayılan metin: Bileşenlere gömülü erişilebilir ipuçları ve hata metinleri.
-
RTL/lokalizasyon: Dil yönüne ve yerel notasyona hazır.
Örnek olay: Kurumsal kütüphaneye “güvence şeridi” bileşeni eklendi; dönüşüm akışlarında tutarlılık sağlandı.
17) Başarı ekranı ve bir sonraki adım: “Gönderildi” değil, “Şimdi ne olacak?”
-
Netlik: “Talebiniz alındı. 15 dakika içinde e-posta ile takvim linki.”
-
Köprü: “Bu arada, sık sorulan 3 soruya göz atın” veya “Örnek PDF’i indirin.”
-
Kişiselleşmiş teşekkür: Adı kullanmak; ancak gizlilik sınırlarını aşmamak.
Örnek olay: Başarı ekranında takvim linki gösterilince geri dönüş süreleri kısaldı.
18) Analitik ve telemetri: Olay–parametre–özellik şeması
-
Olaylar:
form_view,field_focus,field_error,form_start,form_submit,form_abandon,consent_grant,consent_update. -
Parametreler:
form_id,step,device_class,language,consent_state. -
Korelasyon: CWV (LCP/INP/CLS) ile form tamamlama ilişkisi.
Örnek olay: “field_error” en çok “telefon” alanında; ipucu metni ve maskeleme eklenince düştü.
19) A/B test ve deneyler: Hafif ve etik
-
Varyasyonlar: Alan sayısı (–2), ipucu metni, buton metni, başarı ekranı.
-
Hafif deney: CLS üretmeyen, gizlilik uyumlu (rıza yoksa deney yok).
-
Rapor: Tıklama değil, tamamlama ve sonrası (randevu, satın alma).
Örnek olay: “Kart gerekmez” mikro kopyası üç pazarda da kazandı; standart oldu.
20) Riskler ve anti-pattern’ler: Ne yapmamalı?
-
Form şişkinliği: “İleride lazım olur” diye alan eklemek.
-
Belirsiz onaylar: Pazarlama izni ile üyelik onayını birleştirmek.
-
Ağır üçüncü taraf: Rıza gelmeden izleme/deney yüklemek; INP’yi ve güveni zedelemek.
-
Erişilebilirlik ihlali: Etiketsiz alanlar, görünmez foskus, kontrast düşüklüğü.
Karşı reçete: Veri minimizasyonu, ayrık onay, rıza-odaklı yükleme, WCAG dostu bileşenler.
21) E-ticaret form akışları: Adres, ödeme, iade şeffaflığı
-
Konuk ödeme: Zorunlu hesap oluşturmayı kaldırın; sonradan önerin.
-
Adres: Otomatik tamamlama, hatasız posta kodu, teslim tarihi görünürlüğü.
-
Ödeme: Yerel yöntemler; güvenlik/gizlilik notları; saklanan kartlar için açık rıza.
Örnek olay: “Konuk ödeme” ve “iade şeridi” ile satın alma oranı arttı; çağrı merkezine iade sorusu azaldı.
22) B2B demo/teklif akışı: Takvim ve nitelendirme
-
Takvim entegrasyonu: İlk adım sonrası hemen slot seçtirin.
-
Segment soruları: “Kullanım senaryosu”, “ekosistem”, “takım büyüklüğü”—opsiyonel.
-
Güven unsurları: Güvenlik/uyumluluk sayfalarına yakın linkler.
Örnek olay: Takvim ilk ekrana taşındığında niyet netleşti; no-show azaldı.
23) Kamu/üniversite/STK: Yasal alanlar ve sade dil
-
Yasal dayanak: Zorunlu alanların kısa gerekçesi.
-
Yardım ipuçları: “Bu belge e-Devlet’ten temin edilebilir” gibi pratik yönler.
-
Erişilebilirlik: Okuma kolaylığı, ekran okuyucu desteği, net hata dili.
Örnek olay: Başvuru akışına 60 sn’lik video + transkript eklendi; tamamlanma %58→%81.
24) RFP ve SLA: Tedarikçiden beklentiler
-
Kabul kriterleri: “P75 LCP ≤ 2,2 sn, INP ≤ 200 ms; CLS ≤ 0,1; rıza yoksa 3. taraf yok.”
-
Gizlilik: Onay kayıtları, tercih merkezi, veri silme akışı; log politikası.
-
Raporlama: Aylık form tamamlama, terk noktası, alan hata haritası.
Örnek olay: SLA’ya “deney SDK’sı etkisi ≤ 150 ms” şartı eklendi; ağır araçlar elendi.
25) Yönetişim, sahiplik ve karar log’u
-
Sahiplik: Form/akış sahibi, hukuk/onay sahibi, analitik sahibi, performans sahibi.
-
Ritüeller: Haftalık “form kliniği”, aylık onay metni gözden geçirme, çeyreklik 3. taraf temizliği.
-
Karar log’u: “Bu alan neden kaldırıldı?”, “Bu onay neden ayrıldı?”—geri alma planıyla kayıt.
Örnek olay: Ekip değişse bile form kalitesi ve uyumluluk çizgisi korunabildi.
Sonuç
Formlar, onaylar ve veri toplama; web sitenizin dönüşüm ve güven altyapısıdır. İhtiyaç analizi aşamasında doğru soruları sorduğunuzda;
-
İş hedeflerini net bir form amacına çevirir, alan mimarisini veri minimizasyonu ilkesiyle kurarsınız.
-
Erişilebilirlik ve mikro kopya ile kaygıyı azaltır; kısa, empatik ve yön gösterici bir dil üretirsiniz.
-
KVKK/GDPR uyumunu ayrık onaylar, aydınlatma ve tercih merkeziyle sağlamlaştırır; güveni arttırırsınız.
-
Core Web Vitals hedefleri, rıza-odaklı yükleme ve hafif bileşenlerle formu hızlandırır; özellikle mobilde tepki süresi dönüşüme dönüşür.
-
Çok dilli/çok lokasyon senaryolarında anlam eşdeğeri onaylar, yerel hukuk ve para birimi/vatandaşlık akışlarıyla net ve doğru bir deneyim sunarsınız.
-
Analitik ve A/B test şeması, gerçek sürtünme noktalarını gösterir; kazanan desenleri bileşen kütüphanesine alır ve ölçeklersiniz.
-
Yönetişim ve SLA ile kaliteyi kişilere bağlı olmaktan çıkarır, kurumsal bir standarda dönüştürürsünüz.
Kısacası, iyi tasarlanmış bir form ve onay ekosistemi; yalnız daha çok başvuru ya da satış demek değildir. Bu ekosistem, kullanıcıya saygı, hıza bağlı ikna, şeffaf ve yasal bir çerçeve ve ölçeklenebilir operasyon demektir. Bugün bir “Form–Onay–Veri Toplama Karar Defteri” açın: amaç → alan listesi (gerekçe) → mikro kopya → erişilebilirlik kuralları → onay metinleri → rıza politikası → CWV hedefleri → analitik şema → deney backlog’u → karar log’u. Böylece sitenizde doldurulan her alan, insanın niyetini hızla ve onurlu bir yoldan değere çevirir.

