Boş Durumlar ve Hata Mesajları Nasıl Tasarlanır?

Boş durumlar ve hata mesajları, ürün ekiplerinin en son düşündüğü ama kullanıcıların en sık karşılaştığı ekranlardır. Yeni açılmış bir hesap boştur, filtre bazen sonuç döndürmez, bağlantı kopar, form eksik gönderilir. Bu anlarda ekranda ne yazdığı, kullanıcının devam edip etmeyeceğini belirler. Bu yazı iki konuyu birlikte ele alıyor: boş durum türleri, hata mesajı ilkeleri, WCAG gereklilikleri ve Türkçe örnek mesajlar.

Boş durum ve hata neden aynı yazıda?

İkisi de beklenen içeriğin ekranda olmadığı anlardır ve ikisinde de kullanıcının ilk sorusu aynıdır: "Bir şey mi bozuldu, yoksa burada gerçekten bir şey yok mu?" NN/g'nin boş durum rehberinin ilk ilkesi tam olarak budur: sistem durumunu iletin. Alanı boş bırakmak yerine kısa ama açık bir açıklama yazın; böylece kullanıcı içeriğin hiç olmadığını mı yoksa hâlâ yüklendiğini mi anlayabilir 2. Aynı yazı, tamamen boş varsayılan durumların kafa karışıklığı yarattığını ve uygulamaya olan güveni zedelediğini vurgular 2.

Hata mesajları için de benzer bir temel ilke vardır. Nielsen'in dokuzuncu sezgisel ilkesi, hata mesajlarının sade dille yazılmasını, hata kodu içermemesini, sorunu kesin olarak belirtmesini ve yapıcı biçimde bir çözüm önermesini ister 6. Beşinci ilke ise en iyi tasarımın sorunu baştan önleyen tasarım olduğunu hatırlatır 6.

Boş durum türleri ve her birinde ne söylenmeli?

Her boş durum aynı değildir. Ekranın neden boş olduğuna göre mesaj ve eylem değişir:

NN/g, boş durumların aynı zamanda öğrenme fırsatı olduğunu belirtir: "Sık kullandıklarınızı yıldızlayın, burada listelensin" gibi bir ifade hem alanın neyle dolacağını hem de özelliğin nasıl kullanılacağını öğretir 2. Üçüncü ilke ise ana görevlere doğrudan yol sunmaktır; kullanıcıyı boş durumu dolduracak eyleme bir buton ya da bağlantıyla götürmek 2.

Son iki satırdaki durumlar aslında hata durumlarıdır, ama çoğu üründe boş liste görünümüyle karıştırılır. "Henüz kayıt yok" ile "Kayıtlar yüklenemedi" arasındaki fark, kullanıcının verisinin silindiğini sanıp sanmamasıdır. Bu ikisi tasarımda ayrı durumlar olarak ele alınmalıdır.

Hata mesajı ilkeleri: görünürlük, iletişim, verimlilik

NN/g'nin 2023'te güncellediği hata mesajı rehberi ilkeleri üç başlıkta toplar 1.

Görünürlük. Mesajı hatanın kaynağına yakın gösterin; kullanıcının mesajı ilgili alanla ilişkilendirmesi kolaylaşır. Belirgin ve yüksek kontrastlı göstergeler kullanın, ama hatayı yalnız renk ya da animasyonla anlatmayın. Mesajın ağırlığını hatanın etkisine göre seçin: küçük sorunlar için alan altı metin, bildirim ya da şerit; ciddi sorunlar için iletişim kutusu. Hatayı erken göstermeyin; kullanıcı henüz yazarken hata göstermek düşmanca bir kalıptır 1.

İletişim. Teknik jargon yerine kullanıcının tanıdığı kelimeleri kullanın. "Bir hata oluştu" gibi genel mesajlar yerine sorunu kesin olarak tarif edin. Yalnız sorunu söylemekle yetinmeyip çözüm önerin. Kullanıcıyı suçlayan ifadelerden kaçının ve mizahı dikkatli kullanın; tekrar görülen şaka çabuk bayatlar 1.

Verimlilik. Sık yapılan hataları önceden yakalayın. Kullanıcının girdiğini koruyun ki yeniden yazmak zorunda kalmasın. Mümkünse olası düzeltmeleri seçilebilir öneriler olarak sunun. Gerekiyorsa sistemin nasıl çalıştığını kısa bir açıklama ya da bağlantıyla anlatın 1.

GOV.UK Design System da aynı yönde somut kurallar verir: mesaj ne olduğunu söylemeli ve nasıl düzeltileceğini anlatmalı, sade ve olumlu bir dille doğrudan konuya girmeli, alan etiketindeki ifadeyi kullanmalıdır 5. Hata mesajı gösterilirken hiçbir form alanı temizlenmemeli; kullanıcı neyin yanlış gittiğini görüp önceki cevabını düzenleyebilmelidir 5. Sayfanın üstündeki hata özeti ile alan altındaki mesajın aynı ifadeyi kullanması da önerilir 5.

WCAG ne istiyor: 3.3.1 ve 3.3.3

Hata mesajları erişilebilirlik açısından da tanımlı gerekliliklere sahiptir.

• 3.3.1 Hata Tanımlama (A düzeyi): Bir giriş hatası otomatik olarak tespit edilirse, hatalı öğe belirlenmeli ve hata kullanıcıya metinle açıklanmalıdır 3. W3C'nin açıklama belgesi, renk ya da yazı stiliyle hata göstermenin yasak olmadığını, ancak hatanın ayrıca metinle de tanımlanması gerektiğini belirtir 3.
• 3.3.3 Hata Önerisi (AA düzeyi): Bir giriş hatası otomatik olarak tespit edilir ve düzeltme önerileri biliniyorsa, içeriğin güvenliğini ya da amacını tehlikeye atmadıkça öneriler kullanıcıya sunulmalıdır 4. Belgenin örneklerinden biri, ay adı beklenen bir alana "12" yazıldığında kabul edilen değerleri göstermek ya da girdiyi "Aralık" olarak yorumlamaktır 4.

Güvenlik istisnası pratikte önemlidir. Örneğin bir giriş ekranında hangi bilginin yanlış olduğunu ayrıntılı söylemek, hesabın varlığını ele verebilir. Bu durumda "E-posta adresi ya da şifre hatalı" gibi bir mesaj, öneri vermeden de hatayı metinle tanımlar. Web formlarının genel erişilebilirliği kapsamlı bir konudur; bu yazı ürün ekranlarına odaklanıyor. Mobil uygulamalarda hata mesajlarının ekran okuyucuyla nasıl duyurulacağına mobil uygulama erişilebilirliği yazısında değindik.

Türkçe örnekler: zayıf ve daha iyi mesajlar

Aşağıdaki örnekler gerçek bir ürüne ait değildir; ilkeleri somutlaştırmak için yazılmıştır.

GOV.UK, İngilizce mesajlar için "valid" ve "invalid" kelimelerinin bir şey katmadığını, "please" kelimesinin seçenek ima ettiğini, "sorry" kelimesinin ise sorunu çözmeye yardım etmediğini belirtir; "oops" gibi esprili ifadeleri de önermez 5. Türkçede "geçersiz" ve "hatalı" için aynı mantık geçerlidir. "Lütfen" ise Türkçede farklı bir nezaket yükü taşır; tamamen yasaklamak yerine mesajın başında asıl talimatı geciktirip geciktirmediğine bakın ve kararı stil rehberinize yazın. Türkçe arayüz metninin hitap, ek ve yazım kurallarını Türkçe arayüz metni rehberinde ayrıntılı anlattık.

Bir hata mesajını adım adım yazmak

Her hata mesajı için aynı sırayı izlemek, ekip içinde tutarlılık sağlar:

1. Hatayı önleyebilir misiniz? Tarih seçici, biçim maskesi ya da varsayılan değer hatayı hiç oluşturmayabilir 6.
2. Ne oldu? Sorunu kullanıcının diliyle, tek cümlede söyleyin 1.
3. Nasıl düzeltilir? Biliniyorsa doğru biçimi, sınırı ya da seçenekleri verin 4.
4. Nerede gösterilecek? Alanın hemen yanında, gerekiyorsa sayfa üstündeki özetle aynı ifadeyle 5.
5. Ne zaman gösterilecek? Gönderimde ya da alan tamamlandıktan sonra; yazarken değil 1.
6. Erişilebilir mi? Mesaj metin olarak var mı ve alanla programatik olarak ilişkilendirildi mi 3?
7. Girdi korunuyor mu? Kullanıcının yazdığı hiçbir şey silinmemeli 5.

Mesaj kataloğu: tutarlılığın en kolay yolu

Hata ve boş durum metinleri dağınık yazıldığında aynı sorun farklı ekranlarda farklı adlarla anılır. Bunu önlemenin en pratik yolu, tüm mesajları tek bir katalogda toplamaktır: durum, tetikleyici, mesaj metni, eylem ve varsa destek referansı. Katalog, tasarımcıların ve geliştiricilerin aynı listeye bakmasını sağlar; yeni bir hata türü eklendiğinde önce katalogda var olan bir ifadenin yeterli olup olmadığı kontrol edilir.

Form alanlarının kendisini, etiketlerini ve doğrulama zamanlamasını uygulama form tasarımı yazısında ele aldık. Ürününüzün tüm hata ve boş durum metinlerini bir katalog hâlinde yazmak ya da gözden geçirmek isterseniz UX yazımı hizmetimize göz atabilirsiniz.