Form doğrulama hata mesajları nasıl yazılır

Bir kişi e-posta adresini girer, sonraki alana geçer ve yararlı bir düzeltme görür. Başka bir kişi neredeyse aynı cümleyi henüz yazarken görür ve neyi yanlış yaptığını düşünür. Sözcükler aynı olabilir. Deneyim aynı değildir.

Form doğrulama hata mesajlarını tasarlamayı beklenmedik ölçüde zorlaştıran da budur. Daha sıcak bir cümle, sabırsız bir tetikleyiciyi kurtaramaz; kesin bir açıklama da yanlış yanıta işaret ediyorsa yardımcı olamaz. Asıl iş, sistemin ne bildiğine, ne zaman konuşması gerektiğine ve kişinin sonra ne yapabileceğine karar vermektir.

Yararlanılacak sağlam kanıtlar vardır, ama hepsi tek bir evrensel örüntüyü işaret etmez. E-ticaret araştırmaları, kamu hizmeti rehberleri ve kayıt formu deneyleri, kesintiye ve erken geri bildirime farklı ağırlıklar verir. Bu farkı anlamak, kusursuz olduğu iddia edilen hata mesajları listesi toplamaktan daha yararlıdır.

Gerçek kullanıcılar doğrulama hakkında ne söylüyor?

Edward Scott’ın Ocak 2024 tarihli Baymard’ın alan içi doğrulama testleri raporunda, L.L.Bean’deki bir katılımcı e-posta adresindeki @ işaretini atlamıştır. Sonraki alana geçtikten sonra geri bildirim görünmüş, katılımcı birkaç saniye içinde düzeltmiştir. Etsy’de başka bir katılımcı, henüz dokunmadığı adres alanına girdiğinde hatayla karşılaşmış ve arayüzün daha yanıt vermeden kendisini azarladığını hissetmiştir. REI farklı bir toparlanma örneği sunmuştur: katılımcı eksik üçüncü rakamı ekleyince kart güvenlik kodu hatası kaybolmuştur.

Bu geçmiş gözlemler, “alan içi doğrulama kullanıyor” ifadesinin neden eksik bir tanım olduğunu gösterir. Mesajın göründüğü ve kaybolduğu an, sözcükleri kadar önemli olabilir.

Kendi form incelemelerimizde bu gözlemleri şu soruya dönüştürürdüm: mesaj, kişinin bitirdiğini düşündüğü bir eyleme mi yanıt veriyor? Devam’a tıklamak bu niyeti açıkça ifade eder. Bir alandan çıkmak bazen eder. İmleci boş bir alana yerleştirmek ise genellikle etmez. Arayüzün kesinti için bir nedeni olmalıdır; o anda kurala uymayan bir değerin bulunması tek başına yetmez.

Yararlı bir karşı örnek, Luke Wroblewski ve Etre’nin 2009 kayıt formu çalışmasından gelir. Yirmi iki katılımcı altı sürümü denemiştir. Kontrol grubuna kıyasla en iyi alan içi doğrulama sürümünde başarı oranında %22 artış ve tamamlama süresinde %42 düşüş bildirilmiştir. Bir katılımcı, hatalarını ilerledikçe öğrenmeyi tercih ettiğini söylemiştir. Yine de tanıdık yanıtların yanındaki yeşil onaylar, sistemin gerçekte neyi doğruladığı konusunda kafa karışıklığı yaratmıştır.

Çalışmanın en yararlı dersi belirsizlikle ilgilidir: kullanılabilir bir kullanıcı adı seçen kişi, sistemin elindeki bilgiye ihtiyaç duyar; kendi adını yazan kişi ise sistemin güvencesine ihtiyaç duymayabilir. Onay simgelerini formun her yanına eşit dağıtmak yerine, bilinmeyeni çözen geri bildirime öncelik verirdim.

GOV.UK neden farklı bir zamanlama seçiyor?

GOV.UK doğrulama örüntüsü, kişi alandan çıkınca doğrulamak yerine devam etmeyi veya göndermeyi denemesini beklemeyi önerir. Girilen yanıtları korumayı, üste bir hata özeti yerleştirmeyi, odağı bu özete taşımayı ve ilgili alanların yanında hataları belirtmeyi de tavsiye eder. Daha erken doğrulama, bunu destekleyen kullanıcı araştırması gerektirir.

E-ticaret örnekleriyle bu farkı görünür tutmak yararlıdır. Tek sorulu kısa bir adımda gönderim üzerine düzeltme nispeten yereldir: yanıt hâlâ önünüzdedir. Uzun bir ödeme akışında ise kişi gönderdiğinde hatalı alan çok geride kalmış olabilir.

Bir atölye rezervasyon akışını inceleseydim, görevin yapısıyla başlardım. Tek sorulu tarih sayfasında Devam, kullanılamayan seçimi açıklamak için makul bir noktadır. İletişim bilgileri, erişilebilirlik ihtiyaçları, koltuk sayıları ve fatura bilgilerini içeren sayfada sona kadar beklemek, form içinde daha uzun bir geri arama yaratabilir. Bu, her yerde canlı doğrulamayı otomatik olarak haklı kılmaz. Seçici erken geri bildirimi denemeye değer kılar.

Rehberlik ile hata arasında da fark vardır. Parola kontrol listesi, kişi yazarken her eksik koşulu başarısızlık saymadan gereklilikleri açıklayabilir. Tarih ipucu, bir değer girilmeden önce rezervasyon aralığını açıklayabilir. Yararlı yardım gönderimi beklemek zorunda değildir; erken yardım da kırmızı uyarı gibi görünmek zorunda değildir.

Hangi alanın hangi tetikleyiciyi kullandığını yazın. Aksi takdirde “alan içinde doğruluyoruz” ifadesi, üç kişinin uyguladığı üç farklı davranışı gizleyebilir.

Sistemin gerçekten gerekçelendirebildiği düzeltmeyi yazın

“Geçerli bir e-posta adresi girin” çoğu zaman konuşmanın başlangıcı olması gerekirken sonu olur. Burada geçerli ne demektir? Eksik, hatalı biçimlendirilmiş, kullanılamayan ve doğrulanmamış farklı durumlardır. Bunları eş anlamlı saymak, kendinden emin duyulan ama sonraki eylemi açıklamayan mesajlar yaratır.

Kurgusal bir atölye formunda boş iletişim alanı “Rezervasyon onayınız için bir e-posta adresi girin” diyebilir. Girilen metinde @ işareti yoksa “@ işareti içeren bir e-posta adresi girin” gözlenebilir sorunu açıklar. İki cümle de posta kutusunun var olduğunu veya kişiye ait olduğunu doğrulamaz. Bunun için ayrı bir doğrulama adımı gerekir.

Olası her yazım hatası için son derece özel mesaj yazmak cazip gelebilir. Doğrulama mantığı bunları güvenilir biçimde ayıramıyorsa buna direnirdim. Kişi alışılmadık ama meşru bir alan adı kullanıyorsa alan adının yanlış yazıldığını söyleyen cümle yararsızdır. Sistem emin değilse isteğe bağlı bir öneri, kesin ret yanıtından daha iyi olabilir. Metin onaylanmadan önce ekip bu ayrım üzerinde anlaşmalıdır.

Atölye örneği için küçük bir mesaj envanteri şöyle olabilir. Her satır bir koşulla başlar; çünkü aynı alan birkaç farklı mesaja ihtiyaç duyabilir.

Son satır bilinçli olarak üründen bir cümleden fazlasını ister. Durum kontrolü talimatı, yalnızca hizmet bunu yapmak için kullanılabilir bir yol sunuyorsa uygundur. Sunmuyorsa tasarımın mühendislik ve destek ekibiyle kararlaştırılmış başka bir çözüm yoluna ihtiyacı vardır. Metin, eksik kararı “Lütfen tekrar deneyin” ile gizlemek yerine açığa çıkarmalıdır.

Başarısızlıktan sonra uzun formda gezinmeyi mümkün kılın

Rezervasyon sayfasının altına yakın Devam’a bastığınızı düşünün. Üstteki iki alanda artık hata vardır, ancak görünüm alanında hâlâ düğme görünür. Ekran dışında bir yerdeki kırmızı kenarlık yeterli değildir. Kişi eylemin başarısız olduğunu anlamalı ve ilgilenilmesi gereken yanıtlara dönebilmelidir.

Atölye örneğimizde bir özet, koltuk sayısı ve tarih sorunlarını adlandırabilir; her kayıt ilgili alana bağlanabilir. Alan içi metin ise düzeltme sırasında yanıtın yanında kalır. Bu tekrarın amacı vardır: özet gezinmeye, yerel mesaj düzenlemeye yardımcı olur. İki konumda farklı ifadeler kullanmak gereksiz bir anlam çevirisi işi ekler.

Özet seçici de olmalıdır. İlgili kontrolleri geçen iletişim e-postasının hata listesinde yeri yoktur. Düzenli bir sıfırlama durumu yaratmak için formun tamamı da temizlenmemelidir. Önceki yanıtı görmek, kişinin ne olduğunu anlamasına ve yalnızca gerekeni değiştirmesine yardımcı olur. Hassas bilgilerin tutulması ayrı bir ürün ve güvenlik kararı gerektirir; her alanın her zaman saklanacağını vaat etmeyin.

Statik tasarım incelemesinin etkileşim incelemesine dönüşmesi gereken yer burasıdır. Özet bağlantısını klavyeyle izleyin. Odağın nereye geldiğini, alan etiketinin sabit başlığın altında görünür kalıp kalmadığını ve alana ulaşıldığında açıklamasının erişilebilir olup olmadığını kontrol edin. Sonra düzeltip yeniden gönderin. Ekran görüntüsü kırmızı kutuyu gösterebilir; sayfadaki bu yolun çalıştığını kanıtlayamaz.

Mobilde aynı diziyi klavye açıkken inceleyin. Mesaj masaüstü çerçevesine harika sığıp telefonda klavyenin altında kalabilir. Uzun hatalar okunamaz kadar küçülmek yerine satıra yayılmalıdır. Kişiyi tamamlamak için gereken talimata yakınlaştırmak zorunda bırakmaktansa düzeltmeye bir satır daha ayırmayı tercih ederim.

Gerçekler değiştiğinde mesaj da değişmeli

Yaygın bir inceleme hatası, yalnızca iki kareyi onaylamaktır: normal ve hatalı. Sorunlu bölüm çoğunlukla aradadır. Kişi yanıtı düzenler, ilk sorun kaybolur, kırmızı mesaj ise kalır. Onun açısından düzeltme başarısız olmuş olabilir.

Atölye formunda dört koltuk istendiğini ve yalnızca iki kaldığını varsayın. Adedi ikiye değiştirmek, ilgili kuralın yeniden kontrolünü tetiklemelidir. Tarihi değiştirmek farklıdır: kuralın dayandığı envanteri değiştirir. Önceki oturuma ilişkin uyarı, yeni oturuma bağlı kalamaz. İlişki, kırmızı kenarlığın görünümünden daha önemlidir.

Teslimatta üç ek durum isterdim: kontrol ediliyor, bu adım için kabul edildi ve kontrol edilemiyor. “Müsaitlik kontrol ediliyor…” ile “İki koltuk mevcut” aynı değildir; ikisi de rezervasyon onayı değildir. Bu ayrımlar, istek beklenenden uzun sürdüğünde veya kontroller arasında oturum dolduğunda arayüzü dürüst tutar.

Daha az görünür bir uç durum da vardır. Kişi tarihi iki kez değiştirir ve ilk müsaitlik isteği ikinciden sonra tamamlanır. Eski yanıt yenisinin üzerine yazarsa arayüz yanlış soruya kusursuz okunaklı bir yanıt sunabilir. Tasarım notları sonuçların geçerli seçimle eşleşmesini şart koşmalıdır; bunun nasıl sağlanacağını mühendislik seçebilir.

Hareket veya yükleme sunumlarını incelerken bu durum ayrımını akılda tutun. Amaç geçişi hareketli göstermek değildir. Kişinin eski sonucu yeni sanmasını önlemektir. Sistem şu anda kontrol edemiyorsa tarafsız açıklama, yanıtı geçersiz işaretlemekten daha doğrudur.

Hizmet arızası, yanlış yanıtlanmış bir soru değildir

Rezervasyon akışındaki en pahalı ifade hatası, hiç yanlış olmayan yanıtı kişiye düzelttirmek olabilir. Başarısız istek; girdinin reddedildiği, sunucunun kullanılamadığı veya sonucun bilinmediği anlamına gelebilir. Bu olasılıklar farklı sonraki adımlar gerektirir.

Kişi Rezervasyon Yap’a bastıktan sonraki zaman aşımını düşünün. İstek hizmete ulaşmamış olabilir. Tamamlanmış, fakat yanıtı kaybolmuş da olabilir. Hangisinin olduğunu bilmeden “Rezervasyonunuz başarısız oldu” demek fazla kesindir. Hemen ikinci gönderim zararsız olabilir veya mükerrer kayıt yaratabilir. Ürünün bu belirsizlik hakkında açık bir karara ihtiyacı vardır.

Örneğimizde mesajı parlatmadan önce çözüm yolunu bir mühendisle incelerdim. Hizmet, istek referansı kullanarak sonucu alabiliyor mu? Tekrarlanan istek güvenli biçimde özgün sonucu döndürüyor mu? Destek ekibi denemeyi bulabiliyor mu? Sayfada hangi yanıtlar kalıyor? Bu sorular, doğru sonraki eylemin durum kontrolü, güvenli yeniden deneme veya referansla desteğe başvurma olup olmadığını belirler.

Bu, hata metnine teknik iç işleyişi koymak için gerekçe değildir. Okurun ağ arızaları hakkında derse ihtiyacı yoktur. Bilinenlerin dürüstçe ifade edilmesine ve çalışan bir sonraki adıma ihtiyacı vardır. Destek kullanabiliyorsa istek referansı yararlı olabilir; açıklanmayan hata kodu ise kişinin yorumlayacağı başka bir sorundur.

Form doğrulamada iyi uygulamalar çözüm yolunu da kapsar

OpenDesign’da desteklenen bir HTML önizlemesi, ekibin normal alanı, hatayı ve düzeltilmiş durumu karşılaştırmasına yardımcı olabilir. Gerçekçi değerler ve uzun bir mesaj kullanın, dar görünüm alanını inceleyin ve değiştirilmesi gereken öğe hakkında yorum yapın. Sonra aynı diziyi çalışan arka uç, klavye akışı ve ekran okuyucu duyurularıyla test edin.

Küçük bir inceleme oturumu, sıfatlar üzerine bir tur daha çalışmaktan daha çok şey gösterebilir. Birine dört atölye koltuğu ayırtmak gibi somut bir görev verin ve kapasite çakışmasıyla karşılaşmasına izin verin. Ne olduğunu düşündüğünü ve sonra ne yapacağını sorun. Önce amaçlanan anlamı açıklamayın; bu, keşfetmeye çalıştığınız belirsizliği ortadan kaldırır.

Düzeltmeden sonra ne yaptığını, mesaj hakkında söyledikleri kadar dikkatle izleyin. Uyarıyı tekrar tekrar okuyorsa belki uyarı temizlenmemiştir. Hizmet zaman aşımından sonra geçerli e-postasını değiştiriyorsa arayüz suçu yanlış yere yüklüyor olabilir. Formu baştan başlatıyorsa çözüm yolunu bulmak asıl görevden zor olabilir.

Canlı hizmette yinelenen gönderimler ve düzeltme döngüleri, nereye bakılacağını gösterebilir. Nedeni otomatik olarak açıklamazlar. Yüksek hata sayısı kafa karıştırıcı talimatları, aşırı kısıtlayıcı kuralı, mevcut olmayan kontenjanı veya uygulama kusurunu yansıtabilir. Olay dizisini gözlenen davranışla birleştirin; sırf formu teşhis etmek için ham kişisel yanıtları toplamayın.

Örneği onaylamadan önce şu kısa diziyi adım adım izlerdim:

1. Eksik yanıt girin ve geri bildirimin ne zaman göründüğünü gözleyin.
2. İki hatayla gönderin ve özetten her iki alana ulaşın.
3. Bir yanıtı düzeltin ve ilgisiz değerlerin kaldığını doğrulayın.
4. Atölye tarihi gibi bağımlı bir yanıtı değiştirin ve yeni sonucu inceleyin.
5. Kullanılamayan bir hizmetle karşılaşın ve çözüm yolunu izleyin.

Son kontrol başarılı sonuçtur. Onay, düzeltilmiş tarihi ve adedi gösteriyor mu? Kişi rezervasyonun var olup olmadığını anlayabiliyor mu? Kırmızı metin kayboldu diye form toparlanmış sayılmaz.

İyi form doğrulama hata mesajları, kişinin yorumlama yükünü azaltır. Sektör örnekleri yararlıdır; çünkü yorumlamanın nerede bozulduğunu gösterirler: yanıt bitmeden önce, düzeltme yapıldıktan sonra veya arayüz bildiğinden fazlasını bildiğini iddia ettiğinde. Akıl yürütmeyi alın, kendi görevinizde deneyin ve cümlenin gerçekten sağlayabildiğiniz davranışı izlemesine izin verin.