Bir ziyaretçi iletişim formunu doldurup gönderdiğinde bir alanın eksik veya biçimin beklenenden farklı olduğu anlaşılabilir. Kötü tasarlanmış bir dönüşte sayfa yalnızca “hata oluştu” der, önceki bilgiler silinir ve kişi her şeyi yeniden yazmak zorunda kalır. Daha iyi bir web formu hatayı görünür kılar, düzeltilecek alanı açıkça söyler ve geçerli bilgileri korur. Bu rehber, Caddebostan Web Tasarım kapsamında bir iletişim veya teklif formunda hata anından yeniden gönderime kadar olan kullanıcı deneyimini planlamaya odaklanır. Bölgeye özel kullanıcı davranışı, işletme verisi veya başarı sonucu iddiasında bulunmaz; aynı akış farklı işletmelerin gerçek alanlarına göre uyarlanmalıdır.

Form tasarımı yalnızca gönder düğmesinin rengi ya da alan sayısı değildir. Kullanıcıdan istenen bilginin neden gerekli olduğu, hangi biçimde girileceği, yanlış girişin nasıl gösterileceği ve düzeltme sonrası ne olacağı birlikte tasarlanır. Önce formun hangi işi tamamladığı belirlenir: fiyat talebi, geri arama isteği, toplantı başvurusu veya genel soru birbirinin aynısı değildir. Kişi gerekli bilgiyi vermeden işin ilerleyemediği durumlarda alanı işaretleyebilirsiniz; ancak gereksiz ayrıntı istemek, hem kullanıcıyı yorar hem de alınan bilginin güvenilirliğini azaltır. Web tasarım ve yazılım hizmeti değerlendirilirken bu akışın kapsamı, tasarım ve geliştirme teslimlerinden ayrı ayrı sorulmalıdır.

Hata mesajı sorunu değil, düzeltme yolunu anlatmalı

“Geçersiz giriş” ifadesi kullanıcıya neyin yanlış olduğunu söylemez. “Telefon numarası eksik” veya “E-posta adresinde @ işareti bulunmalı” daha açıklayıcıdır; mümkün olduğunda kullanıcıyı kabul edilen biçime yönlendirir. Yine de her alan için tek bir biçime zorlamak gerekçelendirilmelidir. Uluslararası telefon numaraları, farklı adres yazımları ve kurumsal e-posta biçimleri düşünüldüğünde, gereğinden katı bir doğrulama doğru bilgiyi de reddedebilir. İşletme hangi formatı gerçekten kullanacağını, geliştirici de bu kuralın nerede kontrol edileceğini birlikte netleştirmelidir.

W3C’nin WCAG 2.2 kaynakları, otomatik belirlenen giriş hatasının metinle tanımlanmasını ve kullanıcının anlayacağı biçimde aktarılmasını ele alır. Bu ölçütler tek başına bir sitenin erişilebilir veya mevzuata uygun olduğunu kanıtlamaz. Tasarım ekibine, hata mesajının yalnız renk değişimi ya da simgeyle bırakılmaması gerektiğini hatırlatan bir kontrol çerçevesi sunar. Mesaj, hatalı alanla ilişkilendirilmeli; ekran okuyucu ve klavye kullanan kişiler de aynı düzeltme bilgisini alabilmelidir. Bu amaç için kullanılacak teknik çözüm, sitenin altyapısına ve test kapsamına göre seçilir.

Birden çok hata varsa sayfanın en üstünde kısa bir özet ve alanların yanında açıklama birlikte düşünülebilir. Özet, kaç sorunun düzeltilmesi gerektiğini ve ilgili alanlara nasıl gidileceğini anlatır. Alan yanındaki mesaj ise o girdiye özel çözüm önerir. Sayfa yeniden yüklendiğinde odak beklenmedik biçimde başka yere taşınmamalı; kullanıcı hata listesini bulamıyorsa tekrar tekrar formu taramak zorunda kalmamalıdır. Görsel vurguyu yalnız kırmızı renge bağlamayın. Metin, konum ve gerektiğinde simge birlikte kullanıldığında renk algısı farklı olan kullanıcılar için de sorun daha anlaşılır olur.

İşletme, geliştiriciye yalnızca alan adlarını değil, her alanın kabul koşulunu ve istisnasını da vermelidir. Örneğin telefon alanı uzantı kabul ediyor mu, mesaj uzunluğu için üst sınır var mı, dosya ekinin türü ve boyutu nedir? Bu kararlar tabloya yazıldığında hata mesajları gerçek kuralla eşleşir. Böylece tasarım örneğinde kabul edilen bir değerin canlı sistemde reddedilmesi gibi önlenebilir sürprizler, yayından önce bulunabilir. Her kuralı kullanıcının anlayacağı bir cümleye çevirmek de içerik sahibinin sorumluluğudur.

Geçerli bilgiyi koruyarak düzeltme isteyin

Gönderim reddedildiğinde kullanıcının yazdığı geçerli alanlar formda kalmalıdır. Yalnızca sorunlu bilgiyi silip tekrar istemek çoğu durumda gereksiz emek yaratır. Özellikle uzun açıklama, proje kapsamı veya adres yazılmışsa, küçük bir telefon biçimi hatası nedeniyle bütün içeriği kaybetmek güveni zedeler. Geliştirme ekibi her alanı düzeltme öncesi ve sonrası kontrol etmeli; tarayıcı geri düğmesi, mobil ekran, dosya eki ve oturum süresi gibi farklı koşulları da senaryoya katmalıdır. Hassas bilgi isteniyorsa bunun saklanma ve silinme süreci de tasarım kararının parçasıdır.

Alan açıklamaları, yanlış girişi daha gönderilmeden azaltabilir. Örneğin telefon alanı için örnek biçim gösterilebilir; ancak örnek, kullanıcının ülke kodunu veya farklı yazım alışkanlığını reddeden gizli bir kurala dönüşmemelidir. Tarih alanında “önümüzdeki hafta” gibi yoruma açık istek yerine hangi gün ve saat diliminin istendiği anlatılır. Zorunlu alanlar önceden belirtilmeli, isteğe bağlı alanlar da aynı görsel ağırlıkla sunulmamalıdır. Formun neden belirli bilgileri istediğini kısa bir açıklamayla söylemek, kullanıcıdan alınan verinin amacını görünür kılar.

Tekrarlı bilgi girişini azaltmak da önemlidir. Birden fazla adımdan oluşan süreçte kullanıcı daha önce verdiği bir bilgiyi yeniden yazmak zorunda kalıyorsa, bunun teknik veya hukuki bir gereği olup olmadığı değerlendirilmelidir. WCAG 2.2’nin 3.3.7 ölçütü belirli durumlarda daha önce girilmiş bilginin yeniden istenmesini önlemeye yöneliktir; bu ölçütün kapsamı her form için aynı değildir. Rehber burada uygunluk sertifikası vermez. Formun amacına göre alanı taşıma, seçili bilgiyi gösterme veya kullanıcının yeniden girmesi gereken noktayı açıkça açıklama seçenekleri test edilmelidir.

Gönderim durumlarını birbirinden ayırın

Formun “gönderiliyor”, “alındı” ve “işletme tarafından inceleniyor” durumları aynı anlamı taşımaz. Kullanıcı düğmeye bastığında tekrar tıklama ihtimali olabilir; arayüz işlemin sürdüğünü göstermeli ama gereksiz yere düğmeyi tamamen erişilemez hâle getirmemelidir. Başarılı yanıt, yalnız sunucu isteğinin tamamlandığını değil, işletmenin hangi sonraki adımı atacağını da anlatmalıdır. Site gerçekte bir e-posta gönderiyor, kayıt oluşturuyor veya ekibe görev açıyorsa bu iddia test edilmelidir. Teknik kabul kontrolü için form bildirimi ve e-posta teslim kontrolü rehberindeki teslim ayrımı faydalı bir tamamlayıcıdır.

Bir web formunun ekranda başarı mesajı göstermesi, e-postanın doğru kişiye ulaştığını garanti etmez; bunun gibi, e-posta kabulü de işletmenin kullanıcıya dönüş yaptığını göstermez. Bu yüzden kullanıcı metni, arka uç kaydı ve ekip içi sorumluluk birbiriyle tutarlı olmalıdır. Bir hizmet randevusu alınıyorsa, bekleyen talep ile onaylanmış saat ayrılmalıdır; randevu formunda uygunluk ve kesin onay akışı bu daha özel ihtiyacı inceler. Bu yazının odağı ise zaman seçimi değil, hata sonrası bilgi kaybını ve belirsiz düzeltme adımını önlemektir.

Yayın öncesi senaryo turu yapın

Formu yalnızca doğru bilgilerle bir kez doldurup başarı mesajını görmek yeterli test değildir. Boş zorunlu alan, yanlış biçimli e-posta, çok uzun metin, Türkçe karakter, yapıştırılan telefon numarası, geri dönüş ve tekrar gönderim ayrı ayrı denenmelidir. Mobil ekranda klavye alanı kapatıyor mu, hata metni görünür kalıyor mu, düzeltme sırasında sayfa başa mı dönüyor, klavye ile hata alanına ulaşılabiliyor mu gibi sorular test senaryosuna yazılmalıdır. Bir kullanıcı deneyimi turunda görev tamamlanırken gözlem yapılabilir; bu bir istatistik iddiası değil, arayüzdeki sürtünmeyi bulma yöntemidir.

Hata metinleri tasarım dosyasında örnek cümle olarak kalmamalıdır. Her alan için “hangi koşul hata üretir, kullanıcı ne görür, mevcut veriler korunur mu, başarıya nasıl döner” sorularına yanıt verin. Geliştirici, tasarımcı ve işletmeden bilgi veren kişi aynı test senaryosunu çalıştırmalıdır. Ekipte biri yalnız teknik kayıtları, biri görünür mesajı, biri de kullanıcının anlayacağı sonraki adımı doğrulayabilir. Mesaj içeriği işletme politikasına dayanıyorsa, son onay sahibi belirlenmelidir; web tasarım ekibi işletme adına fiyat, süre veya uygunluk sözü üretmemelidir.

Canlıya geçmeden önce hangi verinin saklandığını, ne kadar süreyle tutulduğunu, kimin eriştiğini ve hata raporuna kişisel bilgi düşüp düşmediğini de kontrol edin. Test sırasında gerçek müşterilerin bilgilerini kullanmayın. Gerçekçi senaryolar sentetik verilerle oluşturulabilir; ekip ekran görüntüsü veya kayıt paylaşırken kişisel verileri maskelemelidir. Formun hata mesajı, kullanıcıya gereğinden fazla bilgi göstererek sistem iç yapısını açığa çıkarmamalıdır. Güvenlik gerekçesiyle ayrıntı sınırlanıyorsa, kullanıcıya yine de güvenli ve uygulanabilir bir sonraki adım verilmelidir.

İçerik ve arayüz birlikte gözden geçirildiğinde, hata düzeltme deneyimi formun geri kalanından kopuk kalmaz. Web sitesi form tasarımı: alan seçimi hangi bilgilerin isteneceğine; harita bileşeninde alternatif metin ve hata akışı ise dış bileşen başarısız olduğunda adres bilgisinin nasıl korunacağına odaklanır. Caddebostan Web Tasarım hizmetini incelerken formun hata metinleri, veri koruma davranışı, mobil kullanım ve teslim sonrası değişiklik sorumluluğunu teklif içinde ayrıca netleştirin. İyi bir kabul ölçütü, ziyaretçinin neyi düzelteceğini anlayıp formu yeniden yazmadan tamamlayabilmesidir.

Sık Sorulan Sorular

Formdaki hata mesajı hangi bilgiyi vermelidir?

Hatanın hangi alanla ilgili olduğunu ve düzeltmek için ne yapılabileceğini açıkça söylemelidir. “Eksik bilgi” yerine “Telefon numaranızda bir rakam eksik görünüyor” gibi doğrulanabilir, yargılamayan bir ifade seçin. Sistem kesin nedeni belirleyemiyorsa varsayım yapmayın; kullanıcıya güvenli bir düzeltme yolu gösterin.

Hatalı alan dışında doldurulmuş bilgiler silinebilir mi?

Teknik olarak zorunlu bir neden yoksa geçerli girdiler korunmalıdır. Böylece kullanıcı yalnız sorunlu alanı düzeltir. Oturum zaman aşımı veya güvenlik kararı veriyi etkiliyorsa bu durum önceden açıklanmalı, hangi bilginin neden tekrar isteneceği anlatılmalıdır. Hassas verileri saklamadan da düzeltme deneyimi tasarlanabilir.

Hata yalnızca alanı kırmızıya boyayarak gösterilebilir mi?

Renk tek başına yeterli yönlendirme sağlamaz. Alanın adıyla bağlantılı bir metin açıklaması ekleyin; gerekiyorsa özet listede aynı soruna bağlantı verin. Böylece renkleri farklı algılayan, ekran okuyucu kullanan veya küçük ekranda formu inceleyen kişi de problemi anlayabilir.

Her alanın anında doğrulanması gerekir mi?

Hayır. Anlık kontrol, kullanıcıya düzeltme fırsatı verebilir; fakat her tuşta hata göstermek dikkat dağıtabilir ve geçerli yazımı yarıda kesebilir. Alanın tamamlanma anı, kayıttan çıkış veya gönderim gibi uygun noktayı seçin. Kuralı kullanıcıya önceden açıklayın ve doğrulamayı gerçek iş gereksinimine göre kurun.

Tarayıcının yerleşik doğrulaması yeterli midir?

Bazı basit kurallarda yararlı başlangıçtır; ancak mesajların açıklığı, görünürlüğü ve farklı cihazlardaki davranış test edilmelidir. Yalnız yerleşik uyarıya güvenmek yerine hata metnini, odak sırasını, mobil görünümü ve tekrar gönderimi kontrol edin. Teknik çözümün WCAG uygunluğu sağladığını ayrıca değerlendirin.

Gönder düğmesine tekrar basılmasını nasıl ele almalıyım?

İşlem sürerken görünür bir durum mesajı ve makul bir bekleme davranışı sağlayın. Aynı başvurunun iki kez kaydedilme ihtimali varsa sunucu tarafında da yinelenen istek ele alınmalıdır. Kullanıcıya kesinlikle kaydedildiğini söylemeden önce kayıt adımının başarıyla tamamlandığı test edilmelidir.

Form başarılı olduktan sonra ne göstermelidir?

Başvurunun alınıp alınmadığını, bundan sonra ne olacağını ve kullanıcıya hangi kanaldan dönüş yapılacağını gerçek iş sürecine uygun biçimde açıklamalıdır. İnceleme veya randevu henüz kesinleşmediyse kesin onay izlenimi yaratmayın. Mesaj metnini işletmenin gerçekten uygulayabileceği işlem adımlarıyla eşleştirin.

Formu yayından önce kim test etmelidir?

Tasarımcı ve geliştiricinin yanında, işletme adına yanıt verecek sorumlu da senaryoyu denemelidir. Boş, hatalı, uzun ve geçerli girdiler; klavye ve mobil kullanım; hata sonrası veri korunması ve başarılı teslim ayrı kontroller olmalıdır. Erişilebilirlik uzmanı veya gerçek kullanıcı testi gerekiyorsa kapsamı ve bütçeyi proje başında kararlaştırın.