Hata mesajı yazma: kurallar ve örnekler

Kısaca

Hata mesajı, ürünün kullanıcıyla en gergin anda konuştuğu yerdir. Kullanıcı bir şey yapmak istedi ve olmadı. Mesajın tek işi onu yeniden yoluna sokmaktır.

Bu sayfa mesajın metniyle ilgili. Hatanın ne zaman ve formun neresinde gösterileceğini form tasarımı kalıbında anlattım. Burada o satıra ne yazacağınızı anlatıyorum.

Kuralları NN/g'nin 2023 tarihli hata mesajı yönergelerinden ve GOV.UK Design System'in hata mesajı bileşeninden derledim. Türkçe örnekleri ben yazdım.

Bir hata mesajı ne söylemeli?

Jakob Nielsen'in 10 kullanılabilirlik ilkesinin dokuzuncusu bunu tek cümlede toplar. Mesaj sade dilde yazılmalı, hata kodu içermemeli, sorunu kesin göstermeli ve yapıcı bir çözüm önermeli.

Ben bunu iki soruya indiriyorum. Kullanıcı mesajı okuyunca ne olduğunu anlıyor mu? Bir sonraki adımda ne yapacağını biliyor mu? İkisinden biri eksikse mesaj işini yapmıyordur.

GOV.UK iki yazım biçimi tanımlar. Talimat biçimi kullanıcıya ne yapacağını söyler: "Adınızı yazın". Tanım biçimi kuralı anlatır: "Ad en fazla 35 karakter olabilir".

GOV.UK örneklerinde boş alan için talimat, çok uzun girdi için tanım kullanılır. İkisini de kullanabilirsiniz, yeter ki tutarlı olun.

GOV.UK'nin bir önerisi daha işe yarar: mesajı etiketle eşleştirin. Etiket "Haftada kaç saat çalışıyorsunuz?" ise mesaj "Haftada kaç saat çalıştığınızı yazın" olur. Kullanıcı aynı kelimeleri iki kez görünce mesajın hangi soruya ait olduğunu hemen anlar.

Hata mesajı yazma kuralları

Her kuralın altına kaynağını ve gerekçesini yazdım. Tam künyeler sayfanın sonunda.

1. Mesajı görünür yapın. NN/g, hatayı kalın, yüksek kontrastlı ve kırmızı bir stille göstermeyi önerir. Rengi ya da animasyonu tek işaret olarak kullanmamanızı ister, çünkü renkleri ayırt etmekte zorlanan birçok kullanıcı var.
2. Mesajı hatanın kaynağına, yani alanın yanına koyun. NN/g'ye göre yakınlık, kullanıcının mesajı ilgili alanla ilişkilendirmesine yardım eder. GOV.UK mesajı soru metninden ve ipucundan sonra kırmızıyla gösterir.
3. Ne olduğunu kesin söyleyin. "Bir hata oluştu" gibi genel bir cümle bağlam vermez. NN/g, sorunu kısa ve kesin anlatmayı ister. GOV.UK da "Bu alan zorunludur" gibi genel mesajları kaçınılacaklar listesine koyar.
4. Nasıl düzeltileceğini söyleyin. Nielsen'in dokuzuncu ilkesi, mesajın bir çözümü yapıcı biçimde önermesini ister. WCAG 2.2'nin 3.3.3 ölçütü de düzeltme biliniyorsa önerinin gösterilmesini şart koşar.
5. Kullanıcıyı suçlamayın. NN/g olumlu bir ton ister. Kullanıcıya yanlış yaptığını ima eden "geçersiz", "kuraldışı" ya da "yanlış" gibi kelimelerden kaçınmanızı söyler. GOV.UK listesinde "unuttunuz" da var.
6. Teknik kod ve iç terim yazmayın. NN/g, hata kodlarını ve kısaltmaları yalnızca teşhise yarıyorsa göstermenizi söyler. GOV.UK da "form gönderim hatası" gibi teknik ifadeleri kaçınılacaklar arasında sayar.
7. Özür, "lütfen" ve şaka koymayın. GOV.UK'ye göre "üzgünüz" sorunu çözmez, "lütfen" ise kullanıcıya seçim varmış gibi gelir. NN/g, tekrar eden hatada şakanın çabuk eskidiğini yazar.
8. Kullanıcının yazdıklarını silmeyin. NN/g girdinin korunmasını, kullanıcının baştan başlamak yerine kendi yazdığını düzeltmesini ister. GOV.UK da hata gösterirken hiçbir alanın temizlenmemesini söyler.

GOV.UK'nin kaçınılacak kelimeler listesi İngilizce. Ben aynı mantığı Türkçe karşılıklarına uyguluyorum: "geçersiz", "hatalı", "unuttunuz", "lütfen", "üzgünüz", "hay aksi".

Hata mesajı örnekleri

Aşağıda en sık karşılaştığım hata türleri için birer kötü ve birer iyi mesaj var. İyi olanlar hep aynı kalıbı izler: önce kural ya da talimat, gerekirse bir örnek.

• Boş alan

  Kötü Bu alan zorunludur.

  İyi Adınızı yazın.

• Yanlış biçim

  Kötü Geçersiz telefon numarası.

  İyi Telefon numarasını 10 rakam olarak yazın, örneğin 532 123 45 67.

• Çok uzun

  Kötü Karakter sınırı aşıldı.

  İyi Kullanıcı adı en fazla 20 karakter olabilir.

• Geçmiş tarih

  Kötü Hatalı tarih!

  İyi Randevu tarihi bugünden sonra olmalı.

• Seçim yapılmamış

  Kötü Lütfen bir seçenek seçin.

  İyi Teslimat yöntemini seçin.

• Dosya

  Kötü Upload failed (413).

  İyi Dosya en fazla 10 MB olabilir. Daha küçük bir dosya seçin.

Telefon örneğindeki "örneğin" kısmı için bir not. GOV.UK, ekranda ipucu metninde zaten bir örnek varsa onu hata mesajında tekrar etmemenizi söyler. Örneği mesaja yalnızca ipucunda yoksa koyun.

Hitap da mesajın parçası. "Yazın" mı "yaz" mı diyeceğinize bir kez karar verin ve her mesajda aynı tutun. Bunu arayüzde sen mi, siz mi yazısında ayrıca tartıştım.

Alıştırma: kötü mesajı yeniden yazın

Dört kartın her birinde bir kural çiğneniyor. Kendi halinizi yazıp önerilenle karşılaştırın. Rozetler hangi kuralın düzeldiğini gösterir.

Yeniden yazma alıştırması

1 E-posta alanı

Kötü Şu anki hali

E-posta

!Hata: Geçersiz giriş.

ali.yilmaz@gmail

Önce siz yazın (isteğe bağlı)

İyi Önerilen hali

E-posta

!Hata: E-posta adresinin sonu eksik görünüyor. Adresi [email protected] biçiminde yazın.

ali.yilmaz@gmail

• Düzeldi: Ne olduğunu söylüyor
• Düzeldi: Nasıl düzeltileceğini söylüyor
• Düzeldi: "Geçersiz" kelimesi yok

2 Doğum tarihi alanı

Kötü Şu anki hali

Doğum tarihi

!Hata: ERR_422: date_parse_failed

31.02.1990

Önce siz yazın (isteğe bağlı)

İyi Önerilen hali

Doğum tarihi

!Hata: Doğum tarihi gerçek bir tarih olmalı. Şubat ayı en fazla 29 gün çeker.

31.02.1990

• Düzeldi: Teknik kod yok
• Düzeldi: Türkçe ve sade
• Düzeldi: Ne olduğunu söylüyor

3 Şifre tekrarı alanı

Kötü Şu anki hali

Şifre (tekrar)

!Hata: Şifreleri aynı yazmadınız! Lütfen daha dikkatli olun.

••••••••

Önce siz yazın (isteğe bağlı)

İyi Önerilen hali

Şifre (tekrar)

!Hata: İki şifre birbirini tutmuyor. Bu alana ilk şifreyi aynen yeniden yazın.

••••••••

• Düzeldi: Suçlamıyor
• Düzeldi: "Lütfen" ve ünlem yok
• Düzeldi: Nasıl düzeltileceğini söylüyor

4 Teslimat adresi alanı

Kötü Şu anki hali

Hata: Bir hata oluştu.

Teslimat adresi

Atatürk Mah. 23. Sok. No: 14 Daire: 6 ...

Önce siz yazın (isteğe bağlı)

İyi Önerilen hali

Teslimat adresi

!Hata: Adres en fazla 200 karakter olabilir. Şu an 214 karakter var.

Atatürk Mah. 23. Sok. No: 14 Daire: 6 ...

• Düzeldi: Alanın yanında
• Düzeldi: Ne olduğunu söylüyor
• Düzeldi: Nasıl düzeltileceğini söylüyor

Her kartta gerçek ürünlerde sık gördüğüm türden kötü bir mesaj var. Önce kutuya kendi halinizi yazın, sonra Önerilen hali göster'e basın. Rozetler neyin düzeldiğini gösterir. Örnek mesajları bu sayfa için ben yazdım. JavaScript kapalıysa iki hal de açık durur.

Dördüncü kartta asıl sorun mesajın yeri. Formun tepesindeki genel uyarı, uzun bir formda sorunlu alanı saklar. Önerilen halde mesaj alanın hemen üstünde duruyor ve şu anki karakter sayısını veriyor.

Kullanıcı hatası mı, sistem hatası mı?

Buraya kadarki örnekler kullanıcının girdisiyle ilgiliydi. GOV.UK hata mesajı bileşenini yalnızca bu iş için kullanır. Hizmetin kendisinde bir sorun varsa ya da sayfa bulunamazsa ayrı kalıplara başvurur.

GOV.UK ayrıca hata mesajını "uygun değilsiniz" ya da "yetkiniz yok" demek için kullanmamanızı söyler. Bu durumlar bir giriş hatası değildir. Kullanıcıya ne yapabileceğini anlatan bir sayfa gerekir.

NN/g de mesajın biçimini hatanın etkisine göre seçmenizi önerir. Az etkileşim gerektiren sorunlar için koşullu gösterilen bir etiket, kısa bildirim ya da bant yeter. Modal pencere kullanıcıdan dikkat ve çözüm ister, onu ağır hatalara saklayın.

Sunucu çöktüğünde de aynı iki soru geçerli. "500 Internal Server Error" yerine "Ödemeniz alınmadı, kartınızdan para çekilmedi. Birkaç dakika sonra yeniden deneyin" yazın. Ödeme ekranında kullanıcının ilk merak ettiği şey parasına ne olduğudur.

Benim notum

Audit'lerde en sık gördüğüm hata mesajı "Bir hata oluştu". Bu cümle çoğu zaman geliştiricinin bıraktığı varsayılan metindir. Kimse onu yazmaya karar vermemiştir.

Bu yüzden hata mesajlarını tasarım dosyasında ayrı bir liste olarak tutarım. Her alan için olası hataları sıralar, her birine bir cümle yazarım. Geliştirici bu listeyi alır, varsayılan metin yayına çıkmaz.

GOV.UK bir adım daha öneriyor: mesajın ne sıklıkla görüldüğünü ölçün. Bu veri içeriği iyileştirmeye, A/B testine ya da akışı yeniden tasarlamaya yarar.

Bence sık çıkan bir mesajda önce soruya bakmak gerekir. Nielsen'in beşinci ilkesi de iyi bir hata mesajından daha iyisinin, sorunu baştan önleyen dikkatli bir tasarım olduğunu söyler.

GOV.UK'nin de önerdiği son bir test var: mesajı yüksek sesle okuyun. Bir müşteriye yüz yüze "Geçersiz giriş" demezsiniz. Ekranda da demeyin.

Erişilebilirlik notu

WCAG 2.2'nin 3.3.3 Hata Önerisi (Error Suggestion) ölçütü AA düzeyindedir. Hata otomatik bulunduysa ve düzeltme biliniyorsa, öneri kullanıcıya gösterilmelidir. Tek istisna, önerinin güvenliği ya da içeriğin amacını tehlikeye attığı durumdur.

W3C ölçütün amacını şöyle açıklar: yalnızca hatayı bildirmek, bilişsel ya da görme engeli olan kişileri çözümsüz bırakabilir. Bu kişiler sorunu nasıl düzelteceklerini bilemeyince formu yarıda bırakabilir.

GOV.UK mesajın başına ekranda görünmeyen bir "Error:" öneki koyar ve başka dilde bu öneki değiştirebileceğinizi yazar. Ben Türkçe sayfada "Hata:" kullanıyorum. Bir formu baştan sona nasıl denetlediğimi erişilebilirlik denetimi rehberinde, ölçütlerin tamamını WCAG rehberinde anlattım.

Kontrol listesi

Bir ekrandaki hata mesajlarını yayından önce bu listeyle kontrol ederim. Kendi ürününüzün mesajlarını benim gözden geçirmemi isterseniz UX Audit bunu kapsar.

• Mesaj hatalı alanın yanında duruyor.
• Hata yalnızca renkle değil, metin ve ikonla da gösteriliyor.
• Mesaj ne olduğunu söylüyor.
• Mesaj nasıl düzeltileceğini söylüyor.
• Hata kodu, İngilizce ya da teknik terim yok.
• "Geçersiz", "hatalı", "unuttunuz", "lütfen" ve "üzgünüz" kelimeleri yok.
• Mesaj etiketle aynı kelimeleri kullanıyor.
• Hitap bütün mesajlarda aynı.
• Hata sonrası kullanıcının yazdıkları yerinde.
• Varsayılan "Bir hata oluştu" metni hiçbir yerde kalmadı.