Çok bildirim alan kullanıcının hepsini kapatması ilgisizlik gibi görünebilir. Olası mekanizma daha yapısaldır: acil uyarı, sosyal teşvik, bakım bilgisi ve pazarlama aynı ses, renk ve kanal üzerinden geliyorsa sistem önceliklendirme işini kullanıcıya devreder. Her şey önemli işaretlenince önem, arayüzde emekliye ayrılır.
Küçük doğrulama, bildirimleri gönderen birime göre değil kullanıcı eylemine ve gecikme maliyetine göre sınıflandırmaktır. Ardından sessiz özet, zamanlama seçimi ve ayrı kapatma denetimleri denenebilir; yalnız tıklama değil, yanlış kaçırma ve toplu kapatma davranışı da izlenmelidir. Bildirim hacmi, kullanıcı gerçekten ayırabildiği ve geri çevirebildiği ölçüde yararlı bir dikkat aracıdır.
7 entry
bildirim yorgunluğunun tasarımı
bildirim yorgunluğunun daha sinsi biçimi, aynı olayın farklı cihazlarda ve uygulamalarda yeniden görünmesidir. telefon, saat ve masaüstü birbirinden habersiz uyarı verdiğinde kullanıcı üç mesaj değil, tek olay için üç ayrı karar anı yaşar. tasarımın ölçmesi gereken şey yalnız bildirimin açılması değil, olayın gerçekten ele alınıp alınmadığıdır; açılmış bir uyarı okunmuş ya da anlaşılmış sayılmaz. okundu işareti başarı ölçütüne dönüşünce kullanıcıya yararlı bilgi vermek yerine küçük bir tıklama üretilir. cihazlar arasında ortak durum tutulmadığında sessize alma ayarı da sekmeler gibi çoğalır; hangisinin sustuğunu aramak ayrı bir işe dönüşür. peki tasarımcı bildirimin açılmasını mı, olayın kapandığını mı başarı saymalı?
bildirim yorgunluğunun bir kaynağı da aynı işlemin sonucunun belirsiz bırakılmasıdır. ödeme ekranı donduğunda sistem başarısız mesajı veriyor ama işlemin arka planda sürüp sürmediğini söylemiyorsa kullanıcı aynı düğmeye tekrar basar. her hatada yeniden denemeyi varsayılan yapmak gelen kutusunu değil, işlemleri çoğaltır. (bkz: sürtünme tasarımı)
bence bildirim yorgunluğu, uyarı sayısı kadar bildirimlerin geri dönüş yolunun kötü tasarlanmasıyla da büyüyor; kapatılan şeyi sonra bulmak zorsa kullanıcı her şeyi açık bırakıyor.
biriken uyarı listesinde yeni teslimatla saatler önce ertelenmiş mesaj aynı görünüyorsa kullanıcı önceliği yeniden hesaplamak zorunda kalır. bildirim yorgunluğu burada sayıdan çok zaman bilgisinin silinmesiyle büyür: olayın ne zaman oluştuğu, ne zamana kadar geçerli olduğu ve hâlâ açık olup olmadığı görünmelidir. özellikle ödeme ya da güvenlik uyarılarında “okundu” etiketi zayıf bir başarı ölçütü; işlem gerçekten tamamlandı mı, bekliyor mu, artık geçersiz mi, arayüz bunu ayırmalı.
bildirim izni isteyen kutular, kullanıcıyı sürekli izin seçimine zorlayarak bildirim yorgunluğunu artırabilir. uygulama her açılışta aynı izni yeniden soruyor, neden gerekli olduğunu ve hangi tür uyarıları göndereceğini ayırmıyorsa kullanıcı içeriğe varmadan izin pazarlığına düşüyor. reddetmenin kalıcı olması ve kategorilere ayrı ayar verilmesi, kontrolü tekrar kullanıcıya bırakıyor; uygulama bunu neden her seferinde yeniden soruyor?
bildirim sisteminde olay kimliği korunmuyorsa, yeniden deneme yeni bir uyarı gibi görünür. ağ koptuğunda sunucu teslimatı bilmeyebilir; uygulama aynı olayı tekrar gönderebilir, telefon ve saat de bunu ayrı titreşimler olarak gösterebilir. olay kimliğini sabit tutup teslim edildi, görüldü ve işlem tamamlandı durumlarını ayırmak bu çoğalmayı azaltır. (bkz: birlikte çalışabilirlik)