Bir formu gönder düğmesine bastıktan sonra sayfanın en üstünde kırmızı bir kutu belirir: "Formda hatalar var." Kullanıcı aşağı kaydırır, hangi alanın sorunlu olduğunu arar, düzeltir, tekrar gönderir ve bu kez başka bir alan için aynı uyarıyı alır. Acente ofisinde müşteri karşıdayken ya da telefondayken yaşanan bu döngü, hem zaman kaybı hem de profesyonellik algısı açısından maliyetlidir.
Form doğrulaması, girilen verinin doğru biçimde ve eksiksiz olduğunu kontrol eden mekanizmadır. İyi kurgulandığında kullanıcı hatayı yaptığı anda fark eder ve akışı bozulmadan düzeltir. Kötü kurgulandığında ise doğrulama, kullanıcı ile sistem arasında bir tartışmaya dönüşür.
Doğrulamanın Zamanlaması: Ne Çok Erken, Ne Çok Geç
Doğrulama mesajının ne zaman gösterileceği, mesajın içeriği kadar önemlidir. Üç temel yaklaşım vardır:
- Gönderim anında doğrulama: Tüm kontroller form gönderildiğinde yapılır. Uygulaması kolaydır ama kullanıcı hatalarını toplu ve geç öğrenir.
- Tuşa basıldıkça doğrulama: Her karakterde kontrol yapılır. Kullanıcı daha yazmayı bitirmeden "geçersiz numara" uyarısı görür; bu da gereksiz bir baskı yaratır.
- Alandan çıkışta doğrulama: Kullanıcı alanı doldurup bir sonrakine geçtiğinde kontrol yapılır. Çoğu teklif formu için dengeli yaklaşım budur.
Pratikte bu yaklaşımlar birlikte kullanılır. Alan bazındaki biçim kontrolleri alandan çıkışta yapılır; kullanıcı hatalı alanı düzeltmeye başladığında ise uyarı, düzeltme tamamlanır tamamlanmaz kaldırılır. Böylece kullanıcı hatanın giderildiğini anında görür. Sunucu tarafında yapılması gereken kontroller, örneğin bir kaydın sistemde zaten bulunup bulunmadığı, gönderim aşamasında ya da ilgili adımın sonunda devreye girer.
Mesajın Yeri: Hatanın Hemen Yanında
Hata mesajı, ilgili alanın hemen altında ya da yanında yer almalıdır. Sayfanın tepesindeki genel bir uyarı tek başına yeterli değildir; kullanıcıyı hatayı aramaya zorlar. Uzun formlarda gönderim sonrası bir özet gösterilecekse, bu özetteki her madde ilgili alana götüren bir bağlantı içermeli ve odak ilk hatalı alana taşınmalıdır.
Mobil cihazlarda bu kural daha da önem kazanır. Klavye açıkken ekranın yarısı kapanır; mesaj alanın üstünde kalırsa görünmez. Mobil uygulamada hata mesajlarının alanın altında, klavyeyle çakışmayacak biçimde konumlanması gerekir.
Mesajın Dili: Suçlamadan, Yönlendirerek
"Geçersiz giriş" mesajı kullanıcıya bir şeyin yanlış olduğunu söyler ama neyin yanlış olduğunu ve nasıl düzeltileceğini söylemez. İyi bir doğrulama mesajı üç soruya cevap verir: Sorun ne, neden önemli ve ne yapmalıyım?
Zayıf ve güçlü mesaj örnekleri
- Zayıf: "Hatalı veri." Güçlü: "Kimlik numarası 11 haneden oluşmalıdır; girilen değer 10 hane."
- Zayıf: "Tarih geçersiz." Güçlü: "Poliçe başlangıç tarihi bugünden önce olamaz."
- Zayıf: "Alan zorunlu." Güçlü: "DASK teklifi için bina inşa yılı gereklidir."
Mesajlarda teknik terimlerden, büyük harflerle yazılmış uyarılardan ve ünlem işaretlerinden kaçınmak gerekir. Kullanıcı bir hata yaptığında sistem onu azarlamamalı, yol göstermelidir.
Uyarı ile Engel Arasındaki Fark
Her kontrol, kullanıcının ilerlemesini engellemek zorunda değildir. Bazı durumlar kesin hatadır; bazıları ise yalnızca dikkat gerektirir. Örneğin eksik bir kimlik numarası teklifin oluşturulmasını engeller. Ancak alışılmışın dışında görünen bir değer, örneğin oldukça eski bir araç model yılı, hata değil olası bir yazım yanlışı sinyalidir.
Bu ikinci tür durumlar için engelleyici hata yerine bilgilendirici uyarı kullanmak doğru olur: Kullanıcı değeri kontrol eder, doğruysa devam eder. Her şüpheli durumu engel olarak tasarlamak, kullanıcıların sistemi atlatmak için uydurma değerler girmesine yol açar ve veri kalitesini düşürür.
Branş Akışlarında Doğrulama
Trafik, kasko ve DASK teklifleri farklı sorgu akışlarına sahiptir; dolayısıyla doğrulama kuralları da birbirinden ayrılır. Trafik ve kasko akışlarında plaka, ruhsat ve araç bilgilerine yönelik kontroller öne çıkarken DASK akışında adres ve bina bilgilerinin tutarlılığı önemlidir. Bir branşa özgü kuralın diğer branş formunda tetiklenmemesi, kullanıcıyı ilgisiz uyarılarla karşılaşmaktan korur.
Sigorta şirketinden dönen yanıtlar da bir tür doğrulamadır. Şirket tarafı bir teklifi reddettiğinde veya ek bilgi istediğinde, bu yanıt ham bir sistem mesajı olarak değil, kullanıcının anlayabileceği ve üzerinde işlem yapabileceği bir açıklama olarak sunulmalıdır.
Erişilebilir Doğrulama
Hata durumunu yalnızca alan çerçevesini kırmızıya boyayarak göstermek, renk ayrımında zorlanan kullanıcılar için yeterli değildir. Hata durumu bir simge ve metinle de belirtilmelidir. Ekran okuyucu kullanan bir kullanıcı için hata mesajı ilgili alanla programatik olarak ilişkilendirilmeli ve hata oluştuğunda duyurulmalıdır. Bu düzenlemeler, aslında tüm kullanıcılar için mesajı daha görünür hale getirir.
Örnek Akış: Telefonda Teklif Alırken
Müşteri telefonda kimlik numarasını okurken acente çalışanı numarayı yazar ve bir sonraki alana geçer. Alan, uzunluğun eksik olduğunu hemen alanın altında belirtir; çalışan müşteriden son haneleri tekrar ister ve düzeltir, uyarı anında kaybolur. Ardından araç model yılı alanına alışılmadık bir değer girilir; sistem bunu engel olarak değil, "lütfen kontrol edin" notuyla gösterir. Çalışan değeri müşteriyle teyit eder ve devam eder. Form gönderildiğinde tüm biçim hataları zaten çözülmüş olduğundan yalnızca sunucu tarafı kontroller çalışır. Müşteri telefonda beklerken hiçbir "formda hatalar var" sürprizi yaşanmaz.
Bu küçük senaryo, doğrulamanın üç bileşeninin birlikte çalıştığını gösterir: doğru zamanlama, alanın yanında konumlanan net mesaj ve hata ile uyarı arasındaki ayrım. Bu üç bileşenden biri eksik olduğunda kullanıcı ya gereksiz yere durdurulur ya da hatayı çok geç fark eder.
Doğrulama Kurallarını Yaşayan Bir Liste Olarak Yönetmek
Doğrulama kuralları zamanla değişir: Sigorta şirketlerinin gereksinimleri güncellenir, yeni ürünler eklenir, mevzuat değişir. Bu yüzden kuralların ve mesajların tek bir yerde, düzenli olarak gözden geçirilecek biçimde tutulması önemlidir. Destek taleplerinde sıkça geçen "neden kabul etmiyor?" soruları, hangi mesajın yeniden yazılması gerektiğini gösteren değerli bir kaynaktır.
InsureHub'da doğrulamayı, kullanıcının işini durduran bir kapı olarak değil, onu doğru veriye yönlendiren bir rehber olarak tasarlıyoruz. Acente yazılımında form akışlarının nasıl çalıştığını görmek için demo talebi oluşturabilirsiniz.