Hata Mesajı Tasarımı: Yaygın Tavsiyelerin Hangisi İşe Yarıyor

Hata mesajı tavsiyeleri birbirini kopyalaya kopyalaya kısa bir listeye dönüştü: alanın yanına koy, kırmızı yap, kullanıcıyı suçlama. Hiçbiri yanlış değil, hiçbiri koşulsuz da doğru değil. Hangisinin ne zaman geçerli olduğu formun boyuna, hatanın kaynağına ve kullanıcının o an ne yaptığına göre değişir.

Yakınlık kuralı uzun formda bozulur

"Mesajı ilgili alanın yanına koy" tavsiyesi kısa formlarda tartışmasız çalışır. Sorun, aynı tavsiyenin yanına iliştirilen ikinci tavsiyeyle çelişmesi: hatayı kullanıcı eylemini tamamlayana kadar bekletirseniz, gönderim anında beş alanın üçü birden hatalı çıkar ve ilk hata ekranın dışında kalır. Kullanıcı kırmızı bir şey olduğunu bilir, nerede olduğunu bilmez.

Uzun formda ikisini birden yapmak gerekir. Üstte hatalı alanların listesi, her biri kendi alanına giden bir bağlantı olarak; alanların yanında ayrıca kendi mesajları. Gönderimden sonra odağı bu özete taşıyın, klavye ve ekran okuyucu kullananlar için tek fark yaratan şey budur. Özeti canlı bölge olarak işaretlemezseniz ekran okuyucu hiç okumaz, yani "sadece renge güvenmeyin" iddiasının kodda karşılığı aria-live ya da role="alert"tir, kırmızı kenarlık değil.

Zamanlama: alandan çıkışta mı, gönderimde mi

Kaynakların çoğu "erken gösterme" der. Kaba bir kural, ikiye ayırmak lazım.

Biçimi nesnel olan alanlarda, yani e-posta, posta kodu, kart numarası gibi doğruluğu tek başına belli olanlarda, alandan çıkışta doğrulayın. Kullanıcı hatayı bağlam hâlâ aklındayken düzeltir. Parola kuralları, kullanıcı adı müsaitliği, birbirine bağlı alanlar için gönderimi bekleyin; bunlarda erken uyarı henüz bitmemiş bir girdiyi cezalandırmak olur.

Yazarken karakter karakter doğrulama neredeyse her zaman kötüdür. Tek istisnası olumlu geri bildirim, mesela parola gücü göstergesi. Kullanıcının hiç dokunmadığı bir alan da sayfa açılışında kırmızı olmamalı.

Dil: kibarlık ile bilgi arasındaki takas

"Kullanıcıyı suçlamayın" tavsiyesi fazla tekrarlandığı için amacından saptı. "Geçersiz işlem" ifadesinin sorunu suçlayıcı olması değil, hiçbir şey söylememesi. Yumuşatmaya çalışırken sebebi büsbütün kaybeden mesaj da aynı derecede işe yaramaz: "Bir şeyler ters gitti" cümlesi kibar ama kullanıcıyı destek hattına yollar.

İşe yarayan sıra şu: ne oldu, neden oldu, şimdi ne yapılacak. Üçüncüsü yoksa mesajı yazmaya değmez. Sunucu kaynaklı hatalarda kullanıcıya kısa bir referans kodu gösterin, destek kaydında o kodu aramak günler kazandırır.

Hata metinlerini kodun içine string olarak serpiştirmeyin, tek yerde toplayın; aynı durumun üç ekranda üç farklı cümleyle çıkmasının sebebi neredeyse her zaman budur.

Espriye gelince, ölçülü kullanılırsa 404 gibi düşük riskli sayfalarda sorun çıkarmaz. Ödeme üçüncü kez başarısız olduğunda şakacı bir ton kullanıcıyı yalnızca sinirlendirir.

Girdiyi koruyun, düzeltmeyi kullanıcıya bırakın

Hata sonrası formu boşaltmak hâlâ karşılaşılan bir davranış ve savunulacak yanı yok. Girdi kalır, odak ilk hatalı alana gider, imleç metnin sonunda durur. Parola ve kart alanları istisnadır, temizlenmeleri normal.

Kestirme öneriler faydalıdır ama sessizce uygulanmamalı. "gmial.com yerine gmail.com mu?" diye sorun, kendiliğinden düzeltmeyin; alan adı benzerliğine bakan düzeltme mantıkları kurumsal e-posta adreslerinde şaşırtıcı sıklıkta yanılır.

404 ve sayfa seviyesi hatalar

Bulunamayan sayfayı ana sayfaya yönlendirmek en kolay çözüm ve kullanıcının niyetini çöpe atıyor. Adres çubuğundaki yolu koruyun, slug'daki kelimeleri site içi aramaya doldurun, en yakın birkaç sonucu listeleyin. Sayfanın gerçekten 404 durum kodu döndürdüğünü de kontrol edin, 200 dönen özel hata sayfaları arama motorlarında yıllarca ölü bağlantı olarak yaşar.

Ölçmek

Hata mesajı çalışması ölçülebilir bir iştir, izlenim meselesi değil. Alan bazında terk oranına, aynı oturumda aynı hatanın kaç kez tetiklendiğine, hatayı gördükten sonra gönderimi tamamlayanların oranına bakın. Bir mesajı yeniden yazdıysanız ve tekrar tetiklenme sayısı düşmediyse, sorun cümlede değil, o alanın kendisindedir.