Teklif formu, web sitesinde ziyaretçinin niyetini somut talebe dönüştüren en kritik alanlardan biridir. İyi tasarlanmış bir form, kullanıcıyı gereksiz sorularla yormaz; hangi bilgilerin neden istendiğini açıklar ve sonraki adımı net gösterir.
Kötü tasarlanmış bir teklif formu ise güçlü bir hizmet sayfasının etkisini zayıflatabilir. Çok fazla alan, belirsiz buton metni, güvensiz görünen tasarım, mobilde zor kullanılan giriş alanları veya anlaşılmayan hata mesajları kullanıcıyı formu tamamlamadan çıkmaya itebilir.
Bu nedenle teklif formu tasarımı sadece görsel bir detay değildir. Dönüşüm odaklı web tasarım yaklaşımında form; içerik, güven, teknik kullanılabilirlik ve satış sürecinin birlikte planlandığı bir karar noktasıdır.
Teklif formunun amacı net olmalı
Her form aynı amaca hizmet etmez. Bir iletişim formu genel soru almak için kullanılabilir. Teklif formu ise daha belirli bir ihtiyaç, proje veya hizmet talebini anlamak için tasarlanır. Bu fark netleşmeden alan sayısını, CTA metnini veya form yerleşimini doğru planlamak zordur.
Teklif formunun amacı, ziyaretçiden ilk görüşme veya ön değerlendirme için yeterli bilgiyi almaktır. Ama bu, bütün proje brifini tek ekranda istemek anlamına gelmez. İlk temas formu kısa kalmalı; detaylar sonraki görüşmede alınmalıdır.
Kısa kural: Teklif formunda sadece ilk değerlendirme için gerekli bilgileri isteyin. Kullanıcının henüz karar vermediği bir aşamada uzun bütçe, dosya, şirket içi detay veya teknik gereksinim listesi istemek form tamamlama isteğini düşürebilir.
Hangi alanlar teklif formunda yer almalı?
Form alanları hizmet türüne göre değişebilir; ancak çoğu kurumsal web sitesi için temel yapı benzerdir. Kullanıcı bilgisi, iletişim kanalı, hizmet ihtiyacı ve kısa açıklama alanı çoğu zaman ilk değerlendirme için yeterlidir.
Örneğin web tasarım veya yazılım projesi için ilk formda bütün teknik gereksinimleri istemek yerine, proje türünü ve kısa ihtiyacı öğrenmek daha sağlıklıdır. Ajans daha sonra görüşme sırasında kapsamı netleştirebilir.
| Alan | Neden gerekli? | Not |
|---|---|---|
| Ad soyad | Talebi kişiselleştirmek için | Tek alan yeterli olabilir |
| Telefon veya e-posta | Geri dönüş yapabilmek için | En az biri zorunlu olabilir |
| Hizmet seçimi | Talebi doğru ekibe yönlendirmek için | Web tasarım, SEO, yazılım gibi seçenekler |
| Şirket adı | B2B taleplerde bağlamı anlamak için | Her projede zorunlu olmayabilir |
| Kısa açıklama | İhtiyacı ilk bakışta anlamak için | Serbest metin alanı kısa tutulabilir |
| KVKK/onay alanı | Yasal bilgilendirme ve izin için | Metni açık ve erişilebilir olmalı |
Alan sayısı nasıl belirlenmeli?
Alan sayısı ne kadar az olursa o kadar iyi demek her zaman doğru değildir. Çok kısa form düşük bariyer sağlar; ancak satış ekibine yetersiz bilgi bırakabilir. Çok uzun form ise daha nitelikli bilgi verir; ancak talep sayısını azaltabilir. Doğru nokta, hizmetin karmaşıklığına ve kullanıcının karar aşamasına göre belirlenmelidir.
Basit bir danışmanlık veya ön görüşme talebi için 4-5 alan yeterli olabilir. Kurumsal web sitesi, özel yazılım veya e-ticaret gibi kapsamlı projelerde hizmet seçimi, şirket adı ve kısa ihtiyaç açıklaması eklenebilir. Fakat bütçe, teslim tarihi, dosya yükleme veya detaylı teknik gereksinimler ilk formda zorunlu yapılmamalıdır.
Örnek kısa teklif formu alan seti:
Ad soyad
Telefon veya e-posta
İlgilendiğiniz hizmet
Projenizi kısaca anlatın
KVKK bilgilendirme onayı
Bu örnek, ilk temas için yeterli veri toplar ve kullanıcıyı uzun brif hazırlamaya zorlamaz. Daha detaylı bilgi gerekiyorsa form sonrası otomatik yanıt, telefon görüşmesi veya toplantı planlama adımı kullanılabilir.
CTA metni kullanıcıya ne olacağını söylemeli
Teklif formunda buton metni sadece Gönder olmamalıdır. Gönder kelimesi teknik olarak doğru olsa da kullanıcıya sonraki adımı anlatmaz. Daha açıklayıcı CTA metinleri hem beklentiyi yönetir hem de formun amacını netleştirir.
İyi CTA metni kısa, aksiyon odaklı ve sayfanın niyetiyle uyumlu olmalıdır. Hizmet sayfasında Projemi Değerlendirin, teklif sayfasında Teklif Talebi Gönderin, danışmanlık sayfasında Ön Görüşme Talep Edin gibi ifadeler daha açıklayıcıdır.
- Zayıf CTA: Gönder
- Daha iyi CTA: Teklif Talebi Gönder
- Danışmanlık odaklı CTA: Projemi Değerlendirin
- Düşük baskılı CTA: Ön Görüşme Talep Edin
CTA'nın yanında küçük bir güven metni de kullanılabilir. Örneğin Talebiniz incelendikten sonra sizinle iletişime geçilir gibi kısa bir açıklama, kullanıcının form sonrası ne beklemesi gerektiğini anlamasına yardımcı olur.
Güven metni ve mikro kopya formu tamamlatır
Teklif formunda kullanıcı çoğu zaman iletişim bilgilerini paylaşır. Bu nedenle formun çevresinde güven oluşturacak kısa metinler bulunmalıdır. Uzun hukuki açıklamalar yerine, net ve sade mikro kopyalar daha etkili olur. KVKK veya gizlilik bağlantıları ayrıca görünür tutulmalıdır.
Mikro kopya, form alanının yanında veya altında yer alan kısa yardımcı metindir. Kullanıcıdan istenen bilginin neden gerekli olduğunu açıklayabilir, örnek girdi gösterebilir veya hata durumunda ne yapması gerektiğini anlatabilir.
Örnek mikro kopyalar:
Telefon numaranız yalnızca teklif talebiniz hakkında dönüş yapmak için kullanılır.
Projenizi birkaç cümleyle anlatmanız ilk değerlendirme için yeterlidir.
Talebiniz hizmet kapsamına göre ilgili ekip tarafından incelenir.
Bu metinler gerçek dışı garanti vermez. Sadece formun neden bilgi istediğini ve kullanıcının ne bekleyebileceğini açıklar. Özellikle UI/UX tasarım hizmeti kapsamında form kurgusu yapılırken bu küçük metinler karar sürtünmesini azaltmak için değerlendirilir.
Hata mesajları nasıl yazılmalı?
Hata mesajları, form deneyiminin en çok ihmal edilen parçalarından biridir. Kullanıcı yanlış veya eksik bilgi girdiğinde sadece Hata oluştu demek yeterli değildir. Mesaj neyin eksik olduğunu ve nasıl düzeltileceğini açıkça göstermelidir.
web.dev'in form rehberi; veri girişi, doğrulama, erişilebilirlik, güvenlik, test ve farklı cihazlarda form kullanımı gibi başlıkları ayrı ayrı ele alır web.dev Learn Forms. Bu yaklaşım, formu sadece görsel bir bileşen değil, uçtan uca kullanıcı deneyimi olarak düşünmek gerektiğini gösterir.
| Zayıf mesaj | Daha iyi mesaj | Neden daha iyi? |
|---|---|---|
| Geçersiz giriş | Lütfen geçerli bir e-posta adresi girin | Hangi alanın nasıl düzeltileceğini söyler |
| Bu alan zorunlu | Size dönüş yapabilmemiz için telefon veya e-posta alanını doldurun | Zorunluluğun nedenini açıklar |
| Form gönderilemedi | Talebiniz gönderilemedi. Lütfen bağlantınızı kontrol edip tekrar deneyin | Sonraki adımı belirtir |
Mobil teklif formu ayrı düşünülmeli
Teklif formlarının önemli bir bölümü mobil cihazlardan doldurulur. Bu nedenle masaüstünde iyi görünen formun mobilde de aynı derecede kullanılabilir olması gerekir. Alanların dar ekranda sıkışmaması, butonun kolay dokunulması ve klavyenin alan tipine göre açılması önemlidir.
MDN Web Docs, web formları kapsamında HTML yapısı, form kontrolleri, doğrulama ve veri gönderimi gibi temel konuları geliştirici seviyesinde açıklar MDN Web Forms. Tasarım tarafında bu teknik temel, doğru alan tipi ve anlaşılır kullanıcı deneyimi olarak karşılık bulur.
- Form tek kolon yapıda rahat okunmalı.
- Etiketler alanın üstünde veya net yanında görünmeli.
- Telefon alanı mobil klavyeyi doğru açacak şekilde planlanmalı.
- CTA butonu parmakla kolay basılabilecek boyutta olmalı.
- Hata mesajları ilgili alanın hemen yanında veya altında gösterilmeli.
- Form gönderildikten sonra net başarı mesajı görünmeli.
Erişilebilirlik ve yasal güven ihmal edilmemeli
Teklif formu erişilebilir değilse bazı kullanıcılar formu hiç tamamlayamaz. Etiketlerin doğru yazılması, odak durumlarının görünür olması, hata mesajlarının anlaşılır olması ve klavye ile kullanılabilirlik temel gereksinimlerdir. W3C'nin WCAG hızlı referansı, erişilebilirlik kriterlerini uygulanabilir başlıklarla kontrol etmeyi sağlar W3C WCAG Quick Reference.
Yasal güven tarafında ise KVKK metni ve açık rıza alanları anlaşılır olmalıdır. Kullanıcı hangi verinin hangi amaçla alınacağını görebilmelidir. Bu alanlar sadece zorunlu bir kutucuk gibi yerleştirilirse güven üretmez; aksine formun mekanik ve dikkatsiz göründüğü hissini verebilir.
Teklif formu nerede konumlanmalı?
Teklif formu her zaman sayfanın en üstünde olmak zorunda değildir. Hizmet sayfasında kullanıcı önce hizmeti anlamak isteyebilir. Bu durumda ilk ekranda kısa CTA, sayfanın orta veya son bölümünde ise gerçek form gösterilebilir. Daha kısa sayfalarda form hero alanının yanında da kullanılabilir.
Kurumsal web sitelerinde genellikle iki yaklaşım çalışır. Birincisi, her hizmet sayfasında kısa CTA ile iletişim sayfasına yönlendirmektir. İkincisi, yüksek niyetli sayfalarda gömülü kısa teklif formu kullanmaktır. Hangi yöntemin seçileceği hizmetin karmaşıklığına, satış sürecine ve gelen taleplerin niteliğine göre belirlenmelidir.
Sonuç: Teklif formu kısa, anlaşılır ve güven veren olmalı
Web sitesinde teklif formu tasarımı, ziyaretçiyi en az çabayla doğru talebi iletmeye yönlendirmelidir. Bunun için alan sayısı gereksiz uzatılmamalı, CTA metni açık yazılmalı, hata mesajları yardımcı olmalı, mobil deneyim test edilmeli ve güven metinleri sade tutulmalıdır.
En iyi teklif formu, kullanıcının aklındaki şu soruları sessizce yanıtlar: Bu bilgiyi neden istiyorsunuz? Formu gönderince ne olacak? Bana nasıl dönüş yapılacak? Bilgilerim güvende mi? Bu sorulara net cevap veren form, tasarımın küçük bir parçası gibi görünse de web sitesinin dönüşüm performansında önemli rol oynar.
Sıkça Sorulan Sorular
Teklif formunda kaç alan olmalı?
İlk temas için genellikle 4-6 alan yeterlidir. Ad soyad, telefon veya e-posta, ilgilenilen hizmet, kısa açıklama ve gerekli onay alanı çoğu talebi değerlendirmek için başlangıç sağlar. Daha detaylı bilgiler form sonrası görüşmede alınabilir.
Teklif formunda telefon zorunlu olmalı mı?
Telefon alanı hizmet türüne göre zorunlu veya isteğe bağlı yapılabilir. Hızlı geri dönüş gereken B2B taleplerde telefon faydalıdır; ancak bazı kullanıcılar önce e-posta ile iletişim kurmak isteyebilir. En az bir iletişim kanalını zorunlu tutmak daha dengeli bir yaklaşımdır.
Teklif formu ana sayfada mı iletişim sayfasında mı olmalı?
Bu karar sayfanın amacına bağlıdır. Ana sayfada kısa CTA veya mini form kullanılabilir, detaylı teklif formu ise iletişim ya da hizmet sayfasında yer alabilir. Kullanıcı hizmeti yeterince anlamadan uzun form göstermek yerine karar akışına uygun konumlandırma yapılmalıdır.
Form hata mesajları nasıl yazılmalı?
Hata mesajları açık, alanla ilgili ve düzeltme odaklı olmalıdır. Geçersiz giriş gibi genel mesajlar yerine Lütfen geçerli bir e-posta adresi girin veya Size dönüş yapabilmemiz için telefon ya da e-posta alanını doldurun gibi açıklayıcı ifadeler kullanılmalıdır.
Mobil teklif formunda nelere dikkat edilmeli?
Mobil teklif formunda tek kolon düzen, büyük dokunma alanları, okunabilir etiketler, doğru klavye tipi, kısa açıklama alanı ve net başarı mesajı önemlidir. Form masaüstünde iyi görünse bile mobilde ayrıca test edilmeli, özellikle hata mesajları ve CTA görünürlüğü kontrol edilmelidir.
