UX/UI tasarım / DIJION
Hata mesajı kullanıcıyı nasıl ileri taşır?
Girdi, bağlantı, izin ve belirsiz işlem hatalarını ayırın; kullanıcıya ne olduğunu ve güvenle ne yapabileceğini anlatın.
“Bir hata oluştu” çoğu zaman doğru ama kullanışsız bir cümledir. Kullanıcı neyin değiştiğini, yazdığı bilginin durup durmadığını ve tekrar denemesinin güvenli olup olmadığını anlayamaz. İyi bir hata mesajı, sorunu teknik bir kayıt gibi anlatmak yerine tamamlanamayan işlemi ve mümkün olan sonraki adımı açıklar. Bu rehberdeki metinler örnektir; yayımlanmış bir Dijion ürününden alınmış test sonuçları değildir.
Önce hatanın türünü ayırın
Bir alanın boş bırakılması ile sunucunun yanıt vermemesi aynı çözümü gerektirmez. Kullanıcının düzeltebileceği bir giriş hatasını ilgili alanın yanında gösterin. Bağlantı veya servis hatası bütün işlemi etkiliyorsa işlem düzeyinde açıklayın. İzin reddi durumunda neden izne ihtiyaç duyulduğunu ve mümkünse izinsiz devam yolunu sunun.
Dördüncü bir türü ayrıca düşünün: sonucu bilinmeyen işlem. İstek sunucuya ulaşmış, yanıt telefona dönememiş olabilir. Böyle bir durumda “Başarısız” demek ve aynı işlemi hemen tekrar ettirmek çift kayıt veya çift işlem oluşturabilir. Mesaj, yalnızca sistemin doğrulayabildiği durumu anlatmalıdır.
Ne oldu, ne korunuyor, ne yapılabilir?
Kısa bir hata açıklamasını üç soruyla kurabilirsiniz. Hangi işlem tamamlanamadı? Kullanıcının yaptığı işin hangi kısmı korunuyor? Sonraki güvenli eylem ne? Her mesajda üç cümle gerekmez; ancak tasarımın arkasında üç sorunun da cevabı olmalıdır.
Kullanıcıdan denetleyemediği bir şeyi düzeltmesini istemeyin. Servis geçici olarak kullanılamıyorsa e-posta adresini yeniden yazdırmak fayda sağlamaz. “Tekrar dene” düğmesi de kendi başına açıklama değildir: tekrarın hangi koşulda işe yarayacağı ve mevcut veriye ne olacağı anlaşılmalıdır.
Sekiz durum için örnek hata metni
Tüm sütunlar için tabloyu yatay kaydırabilirsiniz.
| Durum | Örnek metin | Sonraki eylem |
|---|---|---|
| Eksik alan | Adınızı yazın. | İlgili alana odaklan |
| Geçersiz e-posta | E-posta adresini ad@ornek.com biçiminde yazın. | Değeri koru; alanı düzelt |
| Kısa mesaj | Mesajınıza birkaç ayrıntı ekleyin; en az 10 karakter gerekli. | Mesaj alanında devam et |
| Çevrimdışı gönderim | Şu anda bağlantı yok. Mesajınız bu ekranda duruyor. | Bağlantı gelince tekrar dene |
| Servis hatası | Mesaj gönderilemedi. Yazdıklarınız bu ekranda duruyor. | Yeniden dene veya başka kanal kullan |
| İzin reddi | Fotoğraf eklemek için kamera izni gerekli. | Ayarları aç veya fotoğrafsız devam et |
| Hız sınırı | Kısa sürede çok fazla deneme yapıldı. Biraz bekleyin. | Bekledikten sonra yeniden dene |
| Belirsiz sonuç | İşlemin tamamlandığını doğrulayamadık. | İşlem durumunu kontrol et |
“Bu ekranda duruyor” ifadesini yalnızca gerçekten korunuyorsa kullanın. Tarayıcı sekmesini kapatınca silinen bir mesajı “Kaydedildi” diye tanıtmayın. Benzer biçimde, uygulama durum kontrolü sunmuyorsa son satırdaki eylemi kopyalamak yerine ürünün gerçekten desteklediği güvenli yolu açıklayın.
Mesajı düzeltmenin yapılacağı yere koyun
Alan hatası, alan etiketiyle ilişkili ve metin olarak görünür olmalıdır. Birden fazla hata varsa sayfanın üstünde kısa bir özet ve sorunlu alanlara bağlantı yardımcı olabilir. Yalnızca kırmızı bir kenarlık kullanmak, hem hatanın nedenini saklar hem de rengi ayırt edemeyen kullanıcıyı zorlar.
Web formlarında görünür hata metnini ilgili girişle programatik olarak ilişkilendirmek ve durum değişimini uygun canlı bölgeyle bildirmek mümkündür. Native Android ve iOS uygulamalarında ise platformun erişilebilirlik davranışları kullanılmalıdır. Web ARIA örneğini native mobil arayüze olduğu gibi taşımayın; ekran okuyucuyla gerçek akışı deneyin.
Yeniden denemede kullanıcı emeğini koruyun
Hata sonrası kullanıcıdan bütün formu tekrar doldurmasını istememek güçlü bir başlangıçtır. Girişi mevcut ekranda korumak ile diske kalıcı taslak yazmak farklı kararlardır. Hassas bilgi içeren bir formda otomatik saklama, ayrıca mahremiyet ve silme tasarımı gerektirir.
Gönderim sürerken mükerrer tıklamayı sınırlayın. Zaman aşımından sonra otomatik tekrarın güvenli olup olmadığını sunucu davranışıyla değerlendirin. Bir işlemin tek kez uygulanmasını sağlayan mekanizma yoksa sırf daha akıcı görünmesi için arka planda tekrar göndermeyin.
Yayın öncesi kısa kontrol
- Her hata mesajı gerçekten oluşan durumu anlatıyor mu?
- Kullanıcının düzeltebileceği alan açıkça belirtiliyor mu?
- Mesaj, renk dışında metin ve erişilebilir bildirimle anlaşılabiliyor mu?
- Yazılan bilgi başarısızlık sonrasında korunuyor mu?
- Belirsiz sonuçta güvenli bir kontrol veya destek yolu var mı?
- Türkçe ve İngilizce metinler aynı işlemi ve aynı veri davranışını vaat ediyor mu?
Son kontrolü yalnızca ekran görüntüsünde yapmayın. Bağlantıyı keserek, yanlış değer girerek ve ekran okuyucuyla ilerleyerek her mesajın gerçekten doğru zamanda çıktığını inceleyin. Metin, davranış ve kurtarma eylemi birlikte çalıştığında hata kullanıcıyı çıkmaza sokmak yerine ilerletir.