Kısa yanıt
Teklif formu dolmuyorsa önce ziyaretçinin doğru hizmet sayfasına ulaştığını, ne istediğinin anlaşıldığını ve formun telefonda tamamlanabildiğini kontrol edin. Zorunlu alanları iş ihtiyacına göre seçin. Gönderimden sonra hem kayıt hem bildirim oluştuğunu doğrulayın. Daha kısa form her koşulda daha iyi değildir; gereksiz sürtünmeyi kaldırmak hedeflenmelidir.
Dört adımda uygulama rotası
BAŞLANGIÇ → SONUÇ- 01Uyumu kontrol et
Kaynak içerikle hizmet sayfasını karşılaştır.
- 02Formu dene
Telefonda ve hata durumunda doldur.
- 03Kaydı doğrula
Ekip tarafında sonucu bul.
- 04Karşılaştır
Gönderim ve talep niteliğini birlikte izle.
Önce ziyaretin doğru sayfaya geldiğini kontrol edin
Web sitesinde trafik görmek, ziyaretçinin teklif istemeye hazır olduğu anlamına gelmez. Bir kişi fiyat araştırıyor, bir başkası hizmetin kendi ihtiyacına uygun olup olmadığını anlamaya çalışıyor olabilir. Teklif formu dolmuyorsa önce ziyaretin geldiği içerikle açılan sayfanın aynı konuyu anlattığını kontrol edin. Özel bir hizmeti tanıtan reklamın genel ana sayfaya gitmesi fazladan arama işi çıkarabilir.
Kontrole son dönemde en çok ziyaret alan tek bir hizmet sayfasıyla başlayın. Tüm siteyi aynı anda değiştirmek yerine o sayfanın bağlantısını, metnini, formunu ve ekip tarafındaki bildirimini inceleyin. Böylece sorunun nerede başladığına ilişkin daha somut notlar toplarsınız.
İlk üç kontrol: teklif, kapsam ve sonraki adım
- Teklif anlaşılır mı? İlk ekranda ne sunduğunuz ve kimin için uygun olduğu belli olsun.
- Kapsam yeterince açık mı? Kullanıcı sizden ne isteyeceğini anlayacak kadar örnek ve açıklama görsün.
- Gönderimden sonra ne olacak? Formun görüşme talebi mi, fiyat isteği mi, kesin sipariş mi olduğunu belirtin.
Örneğin “Sizi arayalım” ile “Projeniz için teklif isteyin” farklı beklentiler oluşturur. Buton metnini sonraki gerçek işlemle eşleştirin. Ekibinizin uygulamadığı bir yanıt süresini güven vermek için sayfaya eklemeyin. Kullanıcının bekleyeceği bilgi ile sizin göndereceğiniz bilgi aynı olmalı.
Örnek: proje dosyası zorunlu olduğunda talep neden yarıda kalır?
Bir yazılım işletmesi ilk görüşme formunda ayrıntılı proje dosyası yüklenmesini zorunlu tutuyor olsun. Bazı ziyaretçiler henüz kapsamı birlikte konuşmak istediği için dosya hazırlamamış olabilir. Bu kişiler ilgili müşteri olsalar bile ilk adımı tamamlayamaz. Sorun dosyanın teknik olarak yüklenmesi değil, ilk görüşmeden önce istenen hazırlıktır.
İşletme gerçekten dosyasız değerlendirme yapabiliyorsa kısa ihtiyaç özetiyle başlangıç sunabilir. Teknik çizim veya ürün ölçüsü zorunlu olan başka bir işte ise bu alanı kaldırmak değerlendirmeyi aksatabilir. Dolayısıyla bütün formları aynı kalıpta kısaltmak yerine her alanın sonraki işte nasıl kullanıldığını açıklamak gerekir.
Değişiklik sonrası yalnızca gönderim adedi incelenmesin. Ekip daha çok ama hizmete uymayan talep alıyorsa açıklama veya hedef kitle sorusu yeniden ele alınmalıdır. İlgili başvurunun ölçütünü önceden yazmak, değerlendirmeyi kişisel izlenimden daha tutarlı hale getirir.
Bu senaryo açıklama amacıyla hazırlanmıştır; gerçek müşteri sonucu veya ürün testi değildir.
Dördüncü ve beşinci kontrol: alanlar ve mobil kullanım
Her zorunlu alan için “İlk değerlendirmede bunu gerçekten kullanıyor muyuz?” diye sorun. Proje tanımını okumadan işlem yapamıyorsanız kısa bir ihtiyaç alanı gerekli olabilir. Fakat ilk görüşmede kullanılmayan ayrıntıları zorunlu tutmak formu uzatır. Amaç her formu aynı sayıda alana indirmek değil, her alanın işlevini açıklayabilmektir.
Formu küçük ekranlı bir telefonda doldurun. Alan adları, klavye açıldığında da anlaşılır kalıyor mu? Bir hata oluştuğunda hangi alanın düzeltilmesi gerektiği görünüyor mu? E-posta adresi için uygun klavye ve görünür alan etiketi gibi temel ayrıntıları atlamayın. web.dev’in form açıklaması, geliştiriciler için formun tarayıcıdaki işleyişini anlatır.
Son iki kontrol: kayıt oluşuyor mu, doğru kişiye gidiyor mu?
Butona bastıktan sonra teşekkür mesajı görmek tek başına yeterli değildir. Deneme talebinin sistemde oluştuğunu ve görevli kişiye ulaştığını doğrulayın. Bildirim e-postası gelmiyorsa formun veriyi kaydedip kaydetmediğini ayrıca inceleyin; kayıt ve bildirim farklı adımlar olabilir.
Aynı formu iki kez göndermeyi, zorunlu bir alanı boş bırakmayı ve geçersiz e-posta yazmayı deneyin. Kullanıcı hata aldığında bütün yazdıklarını kaybediyorsa düzeltme yapmak zahmetli hale gelir. Bu sorunları ekran görüntüsü, cihaz bilgisi ve tekrarlama adımlarıyla kaydedin. Geliştiriciye yalnızca “form çalışmıyor” demek yerine somut bir örnek iletmiş olursunuz.
Form hatası ile teklif belirsizliğini ayırın
| Belirti | Denenecek kontrol | Düzeltme türü |
|---|---|---|
| Alan doldurulunca hata devam ediyor | Beklenen biçim ve hata açıklaması | Doğrulama ve mesaj düzeni |
| Telefonda son buton kullanılamıyor | Klavye, kaydırma ve ekran boyutu | Arayüz düzeltmesi |
| Form hiç başlamadan çıkılıyor | Hizmet kapsamı ve istenen hazırlık | İçerik veya alan gerekliliği |
| Teşekkür var, talep bulunamıyor | Kayıt ve bildirim adımlarını ayırma | Sunucu veya iletişim akışı |
Bir hata ekranını kullanıcıya nasıl düzelteceğini söyleyen bir açıklamayla destekleyin. Yazdıklarını silip baştan başlamaya zorlamak yerine mümkün olduğunda geçerli alanları koruyun. Formun hangi koşulda kabul edildiği de anlaşılır olmalıdır.
Tasarım işini ölçülebilir bir düzeltmeye dönüştürün
Bir geliştirme çalışması yaptıracaksanız teslim ölçütünü “daha modern görünüm” ile sınırlamayın. Hangi form hatasının giderileceğini, mobilde hangi adımın kolaylaşacağını ve talebin hangi kayda ulaşacağını yazın. Bize ait Hızlı Yazılım’ın web tasarım ve form geliştirme çalışmaları için de aynı somut kapsamı kullanabilirsiniz.
Değişiklikten önce ve sonra aynı ölçüm tanımıyla ilerleyin. Daha az form gönderimi bazen daha nitelikli başvuru anlamına gelebilir; sayının yanında başvuruların hizmete uygunluğunu da inceleyin. Sonraki adımda gelen taleplerin takibini düzenleyerek sayfadaki iyileştirmenin ekip tarafında karşılık bulmasını sağlayın.
Geliştiriciye tekrar edilebilir bir hata kaydı iletin
Kullanılan cihazı, tarayıcıyı, sayfa adresini ve hangi adımlardan sonra sorun oluştuğunu yazın. Gerçek müşteri bilgileri yerine deneme verisi kullanın. Hatanın her seferinde mi yoksa belirli dosya ve alanlarda mı oluştuğunu ayırın. Böylece ekip sorunu aynı koşullarda deneyebilir.
Düzeltme tamamlandığında ilk hata senaryosunu yeniden uygulayın. Sadece ana sayfanın açılması veya buton renginin değişmesi form sorununun giderildiğini göstermez. Değişen alanları kısa bir yayın notuyla ekibe bildirin.
0 / 4 adım kontrol edildi · Bu seçimler yalnızca açık sayfada tutulur.
Sık sorulan sorular
Formun kaç alan olması gerekir?
Evrensel bir sayı yoktur. Her alanın ilk işlem için gerekli olup olmadığını ve ziyaretçinin o bilgiyi o aşamada verip veremeyeceğini değerlendirin. İsteğe bağlı alanı zorunluymuş gibi göstermeyin.
WhatsApp bağlantısı formun yerine geçer mi?
Bazı işler için uygun bir iletişim yolu olabilir. Ancak talebin kayda alınması, sorumlusunun belli olması ve müşterinin ne bekleyeceğinin açıklanması yine gerekir. Kanal değiştirmek takip sorumluluğunu kaldırmaz.
Form gönderimi dönüşüm sayılabilir mi?
Tanımlanmış ölçümde sayılabilir. Bununla birlikte ilgili müşteri veya satışla aynı anlamı taşımaz. Test ve yinelenen kayıtların rapora nasıl dahil edildiğini de açıklayın.
Yöntem ve kaynak notu
Örnek senaryolar ve karar tabloları, konuyu açıklamak için hazırlanmış çalışma önerileridir. Ölçülmüş müşteri sonucu veya bağımsız ürün testi olarak sunulmaz. Platform ve ürün koşulları değişebileceğinden uygulama öncesinde ilgili resmi belgeyi ve kendi hizmet kapsamınızı kontrol edin.