Toast Mesajı Nasıl Tasarlanır? Bildirim ve Arayüz Geri Bildirimi Rehberi

Bir kullanıcı formu gönderir, ürünü sepete ekler ya da ayarı kaydeder; ekranın köşesinde kısa bir kutu belirir ve birkaç saniye sonra kaybolur. Bu kutuya toast mesajı diyoruz. Küçük bir bileşendir, ama yanlış kurulduğunda kullanıcı işlemin olup olmadığını anlamaz. Ekran okuyucu kullanan biri ise hiçbir şey duymayabilir.

Bu rehberde Talha Aslan ve ekibi olarak arayüz geri bildirimini nasıl kurduğumuzu anlatıyoruz. Başarı, hata ve bilgi mesajlarını ayırıyor, süre ve konum kararlarını ele alıyor, ekran okuyucu duyurusunu kavram düzeyinde açıklıyoruz. Sonunda da uygulamaya hazır bir kontrol listesi var.

Adı, kızarmış ekmek makinesinden fırlayan dilimden gelir: aşağıdan ya da yandan kayarak çıkar, sonra kaybolur. Ancak her geri bildirim toast olmamalı. Kullanıcının bir şeyi düzeltmesi, onaylaması ya da okuması gerekiyorsa daha kalıcı bir bileşen seçersiniz.

Nielsen Norman Group, göstergeler, doğrulamalar ve bildirimler üzerine yazısında bu ayrımı net çizer. Doğrulama mesajı kullanıcının kendi girdisine bağlıdır ve eylem ister. Bildirim ise sistem olayını haber verir; eylem isteyen ve pasif olmak üzere iki türü vardır. Toast, pasif bildirimin tipik örneğidir. Bu yüzden kolayca gözden kaçabilir ve kritik bilgiyi tek başına taşımamalıdır.

Toast mesajı, uyarı bandı ve modal pencere arasındaki fark nedir?

Geri bildirim bileşenlerini birbirinin yerine kullanmak, arayüz hatalarının en sık kaynağıdır. Örneğin silme onayını toast ile sormak, kullanıcının kararı görmeden geçmesine yol açar. Aşağıdaki tablo, ekibimizin bileşen seçerken baktığı temel farkları özetliyor.

Kısacası toast, "bilgin olsun" der. Modal ise "durup karar ver" der. İkisini karıştırırsanız ya kullanıcıyı gereksiz yere durdurursunuz ya da önemli bir kararı fark ettirmeden geçirirsiniz.

Arayüz geri bildiriminde hangi mesaj türleri vardır?

Bildirim tasarımına başlamadan önce mesaj türlerini adlandırmak işinizi kolaylaştırır. Her türün tonu, rengi, ikonu ve süresi farklıdır. Ekibimiz tasarım sisteminde genellikle dört tür tanımlar:

• Başarı: İşlem bitti. Örneğin "Adresiniz kaydedildi".
• Hata: İşlem gerçekleşmedi ve kullanıcının bir şey yapması gerekiyor.
• Uyarı: İşlem gerçekleşti ama dikkat edilmesi gereken bir durum var.
• Bilgi: Kullanıcının eylemiyle doğrudan ilgili olmayan nötr haber, örneğin yeni sürümün yüklendiği.

Bazı ekipler bir de bekleme ya da ilerleme durumunu ayrı tür sayar. WCAG de ilerleme ve bekleme durumunu durum mesajı kapsamında anar. Ayrıca her tür için tek bir metin kalıbı belirlemek, farklı ekiplerin aynı sitede farklı dil konuşmasını engeller. Metin tarafı için UX writing rehberimiz iyi bir başlangıç noktasıdır.

Bildirim metninin tonunu nasıl seçersiniz?

Bildirim metni, sitenin genel sesinin küçük bir parçasıdır. Ancak bu küçük parça, kullanıcının en dikkatli okuduğu anlarda karşısına çıkar: bir ödeme yaptığında, bir dosya yüklediğinde ya da bir şey ters gittiğinde. Bu yüzden tonu bilinçli seçmeniz gerekir.

Başarı mesajında sakin ve kısa bir dil yeterlidir. Hata mesajında ise suçlayıcı ifadelerden kaçınırsınız. "Yanlış girdiniz" yerine "Bu alan için 11 haneli bir numara gerekiyor" yazmak, sorunu kullanıcıdan değil koşuldan anlatır. Teknik hata kodlarını da kullanıcıya göstermezsiniz; gerekiyorsa destek ekibi için küçük bir referans numarası eklersiniz.

• Kullanıcıya "siz" diye hitap edin ve aynı hitabı her yerde koruyun.
• Şaka ve espriyi hata anlarında kullanmayın.
• Kısaltma ve iç jargon yerine kullanıcının bildiği kelimeyi seçin.

Böylece bildirim, sitenin geri kalanıyla aynı kişiliği taşır ve güven duygusunu bozmaz.

Yükleme ve ilerleme durumunu nasıl bildirirsiniz?

Bazı işlemler anında bitmez: büyük bir dosya yüklemesi, rapor hazırlama ya da ödeme onayı birkaç saniye sürebilir. Bu sırada kullanıcı hiçbir değişiklik görmezse düğmeye tekrar basar ya da sayfadan ayrılır. Dolayısıyla bekleme durumunu da bir geri bildirim türü olarak ele alırsınız.

Kısa beklemelerde düğmenin içinde küçük bir dönen gösterge yeterlidir. Uzun işlemlerde ise ilerleme çubuğu ve yaklaşık durum metni daha bilgilendiricidir. WCAG Durum Mesajları belgesi de meşgul göstergesini ve ilerleme güncellemelerini durum mesajı örnekleri arasında sayar.

Ekran okuyucu tarafında dikkatli olmak gerekir. İlerleme yüzdesini her değişimde duyurursanız, kullanıcı sürekli bir sayı akışı dinler. Bunun yerine başlangıcı, önemli ara noktaları ve sonucu duyurmak daha rahat bir deneyim sunar. İşlem bitince de sonucu kısa bir toast mesajı ile haber verirsiniz.

Başarı mesajını nasıl yazarsınız?

Başarı mesajı, neyin olduğunu tek cümlede söyler. "İşlem başarılı" gibi genel ifadeler kullanıcıya bir şey anlatmaz; "Fatura adresiniz güncellendi" ise neyin değiştiğini açıkça gösterir. Bu nedenle nesneyi ve sonucu birlikte yazarsınız.

Kısa tutmak da önemlidir. Toast birkaç saniye ekranda kalır, dolayısıyla okuma süresi sınırlıdır. Tek satıra sığan, fiille biten cümleler en iyi sonucu verir. Ünlem işareti, "Harika!" gibi abartılı sevinç ifadeleri ve gereksiz teşekkürler mesajı uzatır.

• Nesneyi adlandırın: "Ürün sepete eklendi", "Bağlantı kopyalandı".
• Gerekirse sonraki adımı verin: "Sepete git" bağlantısı gibi.
• Geri alınabilir işlemde "Geri al" seçeneği sunun.
• Aynı işlem için her yerde aynı ifadeyi kullanın.

Öte yandan her başarılı işlem bildirim gerektirmez. Kullanıcı sonucu ekranda zaten görüyorsa, örneğin bir onay kutusu işaretlendiyse, ek toast gürültü yaratır. Görsel değişikliğin yetersiz kaldığı yerlerde bildirim kullanırsınız.

Hata mesajını toast mesajı olarak göstermek doğru mu?

Çoğu durumda hayır. Hata, kullanıcının bir şey yapmasını gerektirir; birkaç saniye sonra kaybolan kutu ise bu talebi taşıyamaz. Kullanıcı başka yere bakarken hata kaybolursa, işlemin neden tamamlanmadığını hiç fark etmez.

Form hatalarında mesajı ilgili alanın hemen yanında, kalıcı olarak gösterirsiniz. Sorun düzelene kadar orada kalır. Sunucu kaynaklı ya da bağlantı hatası gibi sayfa geneli sorunlarda ise kalıcı bir uyarı bandı daha uygundur. Form tarafındaki genel ilkeleri form tasarımı yazımızda ayrıntılı ele aldık.

Yine de toast ile hata gösterilebilecek dar bir alan var. Örneğin arka planda otomatik kaydetme başarısız olduysa ve sistem yeniden deneyecekse, bunu kısa bir bildirimle haber verebilirsiniz. Ancak bu bildirim kendiliğinden kaybolmamalı; kullanıcı kapatana ya da sorun çözülene kadar ekranda kalmalıdır.

İyi bir hata mesajı üç şey söyler: ne oldu, neden oldu ve şimdi ne yapmalı. "Bir hata oluştu" yerine "Bağlantı kesildi; değişiklikleriniz kaydedilmedi. Yeniden deneyin." yazarsınız.

Bilgi ve uyarı mesajlarını nasıl ayırırsınız?

Bilgi mesajı nötrdür ve kullanıcıdan bir şey beklemez. Uyarı ise bir risk ya da sınır bildirir. Örneğin "Yeni yorum geldi" bilgi, "Depolama alanınızın büyük kısmı doldu" uyarıdır. İkisini aynı görsel dille sunarsanız kullanıcı uyarıyı da önemsiz sanar.

Ayrımı yalnız renge bırakmamalısınız. Renk körlüğü olan bir kullanıcı sarı ile maviyi ayırt edemeyebilir. Bu yüzden her türe farklı bir ikon ve gerekirse açık bir etiket eklersiniz: "Uyarı:" gibi kısa bir ön ek, mesajın niteliğini metinle de söyler.

Uyarıların süresi de farklı olmalıdır. Bilgi mesajı kısa sürede kaybolabilir; uyarı ise kullanıcı okuyup kapatana kadar kalmayı hak eder. Hatta uyarı kullanıcının işini etkiliyorsa, toast yerine sayfanın üst kısmında kalıcı bir bant daha doğru bir tercihtir.

Kısaca kural şudur: kullanıcıdan eylem bekleyen her mesaj, kendiliğinden kaybolmayan bir bileşende yer alır.

Toast mesajı ekranda ne kadar süre kalmalı?

Tek doğru süre yoktur; süreyi metnin uzunluğu ve mesajın önemi belirler. Ancak en sık yapılan hata, süreyi çok kısa tutmaktır. Yavaş okuyan, dikkati dağılan ya da ekranı büyüterek kullanan kişiler kutuyu okuyamadan kaçırır.

WCAG 2.2'nin Zaman Ayarlanabilir (2.2.1) ölçütü, belirli süre sonra kendiliğinden gerçekleşen değişiklikleri zaman sınırı sayar. Belgeye göre geçici bir bildirim, kullanıcı aynı bilgiye başka bir yoldan ulaşabiliyorsa bu kapsamın dışında kalabilir. Başka yol yoksa, kullanıcıya süreyi kapatma, uzatma ya da ayarlama imkânı vermeniz gerekir.

Pratikte ekibimiz şu yaklaşımı izler:

• Bilgiyi yalnız toast içinde bırakmayın; aynı sonuç sayfada da görünsün.
• Fare üzerine geldiğinde ya da klavye odağı kutuya girdiğinde zamanlayıcıyı durdurun.
• İçinde düğme veya bağlantı olan bildirimleri kendiliğinden kapatmayın.
• Hata ve uyarıları kullanıcı kapatana kadar ekranda tutun.

Böylece süre kararı, kullanıcının kontrolüne geçer.

Bildirim ekranın neresinde yer almalı?

Konum kararı, kullanıcının dikkatinin nerede olduğuna bağlıdır. Masaüstünde sağ üst ve sağ alt köşe yaygındır, çünkü sayfa içeriğini kapatmaz. Ancak geniş ekranda göz, işlemi yaptığı yere bakar; köşedeki kutu bu noktadan çok uzakta kalabilir.

Bu nedenle bildirimi işlemin gerçekleştiği bölgeye yakın konumlamayı düşünün. Örneğin bir kart içindeki "Kopyala" düğmesine basıldığında, sonuç düğmenin yanında kısa bir etiketle gösterilebilir. Sayfa geneli işlemlerde ise sabit bir köşe seçip tüm sitede aynı yeri kullanmak tutarlılık sağlar.

Dikkat etmeniz gereken bir nokta daha var: bildirim, önemli içeriğin ya da düğmelerin üstünü kapatmamalıdır. Sepet düğmesinin, sohbet balonunun veya çerez bandının üstüne binen kutu, kullanıcıyı engeller. Üstelik birden fazla sabit bileşen aynı köşeyi paylaşıyorsa, katman sırasını tasarım aşamasında belirlemeniz gerekir.

Konumu bir kez belirleyip tasarım sistemine yazarsanız, yeni sayfalarda aynı kararı tekrar tartışmazsınız.

Ekran okuyucular bildirimi nasıl duyar?

Görsel olarak beliren bir kutu, ekran okuyucu için kendiliğinden bir şey ifade etmez. Kod, bu içeriğin bir durum mesajı olduğunu işaretlemelidir. WCAG 2.2'nin Durum Mesajları (4.1.3) ölçütü tam olarak bunu ister: durum mesajları, odak taşınmadan yardımcı teknolojilere iletilebilecek şekilde kodlanmalıdır. Bu ölçüt AA düzeyindedir.

Bunu sağlayan kavrama "canlı bölge" (live region) denir. Sayfada, içeriği değiştiğinde ekran okuyucunun okuduğu bir alan tanımlarsınız. MDN'nin aria-live belgesi üç değer sayar: off, polite ve assertive. Polite değeri, okuyucunun o anki cümlesini bitirmesini bekler ve çoğu bildirim için doğru seçimdir. Assertive ise araya girer.

Uygulamada sık atlanan bir nokta var: canlı bölge, sayfa yüklendiğinde boş olarak zaten bulunmalıdır. Bildirim geldiğinde kutuyu sıfırdan oluşturup içine metin koyarsanız, bazı ekran okuyucular değişikliği fark etmeyebilir. Dolayısıyla doğru yöntem, sabit ve boş bir kapsayıcıyı önceden yerleştirip yalnız içeriğini güncellemektir.

Erişilebilirliğin genel çerçevesi için WCAG standartları rehberimize göz atabilirsiniz.

Status ve alert rolleri arasında nasıl seçim yaparsınız?

ARIA iki hazır rol sunar ve ikisi de birer canlı bölge işlevi taşır. MDN belgelerine göre status rolü, polite canlı bölgeye denktir; alert rolü ise assertive canlı bölgeye denktir. İkisi de içeriği bir bütün olarak okutur ve ikisi de odağı taşımaz.

Seçim kuralı basittir. Başarı, ilerleme ve bilgi mesajları için status rolünü kullanırsınız. Alert rolünü yalnız kullanıcının hemen bilmesi gereken durumlara saklarsınız: oturum süresinin dolmak üzere olması ya da kaydın başarısız olması gibi. MDN, alert rolünün araya giren yapısı nedeniyle idareli kullanılması gerektiğini ve aynı anda birden fazla uyarının kötü deneyim yarattığını açıkça belirtir.

1. Mesaj kullanıcının işini durdurmayı gerektiriyor mu? Hayırsa status.
2. Mesaj gecikirse kullanıcı zarar görür mü? Evetse alert.
3. Kullanıcının karar vermesi gerekiyor mu? O zaman canlı bölge değil, odak alan bir iletişim penceresi.

WCAG belgesi de alert ya da assertive kullanımını önemli ve zamana duyarlı olmayan içerik için önermez. Kısacası varsayılanınız status olmalıdır.

Bildirime geri al düğmesi eklemeli misiniz?

Geri alınabilir işlemlerde evet. Örneğin bir e-postayı arşivlemek ya da listeden bir öğeyi kaldırmak için onay penceresi açmak yerine, işlemi hemen yapıp toast içinde "Geri al" seçeneği sunabilirsiniz. Böylece kullanıcıyı her seferinde durdurmazsınız, ama hata yaptığında kurtulma yolu da bırakırsınız.

Ancak bu kalıbın bir bedeli var. İçinde düğme olan bir toast artık etkileşimli bir bileşendir. Klavyeyle ve ekran okuyucuyla erişilebilir olmalı, kullanıcı ona ulaşmadan kaybolmamalıdır. Birkaç saniyede kaybolan geri al düğmesi, yavaş hareket eden kullanıcı için hiç yoktur.

Bu nedenle ekibimiz şu kuralı uygular: geri al seçeneği varsa, aynı işlemi geri almanın ikinci bir yolu da bulunmalıdır. Silinen öğe bir "Son silinenler" alanında durabilir ya da geçmiş ekranından geri getirilebilir.

Geri dönüşü olmayan işlemlerde ise geri al vaadi vermezsiniz. Kalıcı silme ya da ödeme gibi adımlar için açık bir onay penceresi doğru seçimdir.

Klavye ve odak yönetiminde nelere dikkat etmelisiniz?

Durum mesajının temel kuralı, odağı yerinden oynatmamaktır. Kullanıcı bir formda ilerlerken bildirim odağı kendine çekerse, kullanıcı nerede kaldığını kaybeder. MDN de status rolü için içerik güncellendiğinde odağın bu alana verilmemesi gerektiğini yazar.

Öte yandan bildirimin içinde bir düğme varsa, klavye kullanıcısı ona ulaşabilmelidir. Bunun için bildirimin sekme sırasında mantıklı bir yerde bulunması ve kendiliğinden kaybolmaması gerekir. Bazı ekipler kullanıcının bildirime atlayabilmesi için bir kısayol sunar; bunu kullanıyorsanız kısayolu açıkça belirtirsiniz.

• Kapat düğmesinin erişilebilir bir adı olsun, yalnız çarpı ikonu yetmez.
• Escape tuşu açık bildirimi kapatabilsin.
• Bildirim kapanınca odak, kullanıcının bulunduğu yerde kalsın.
• Bildirim kutusunda da odak halkası net olsun.

Bu noktaların çoğu genel arayüz ilkeleriyle örtüşür; kullanıcı odaklı arayüz tasarımı yazımızda bu ilkeleri daha geniş ele aldık.

Bildirimde renk, ikon ve kontrastı nasıl kullanırsınız?

Başarı için yeşil, hata için kırmızı, uyarı için sarı ya da turuncu yaygın bir kalıptır. Ancak anlam yalnız renkle verilmemelidir. WCAG, rengin bilgiyi aktarmanın tek görsel yolu olmamasını ister. Bu yüzden her türe ayırt edici bir ikon eklersiniz ve mesaj metni de türü kendi başına anlatır.

Ekipler kontrastı da sık atlar. Açık yeşil zemin üzerine beyaz yazı, gün ışığında telefonda okumayı zorlaştırır. Metin ile arka plan arasındaki kontrastı ölçmeli, ikonun da çevresinden ayrışmasını sağlamalısınız. Koyu tema kullanan sitelerde her renk çiftini ayrıca kontrol edersiniz.

İkonlar dekoratifse ekran okuyucudan gizlersiniz; anlam taşıyorsa bir metin karşılığı olur. Aksi halde okuyucu "resim" gibi anlamsız bir ifade okur ya da türü hiç aktarmaz.

Kontrast seçimlerinin genel mantığını tasarımda kontrast rehberimizde anlattık. Bildirimler için ek kural şudur: kutu, sayfanın geri kalanından gölge ya da kenarlıkla ayrışmalı, ama göz yoracak kadar parlak olmamalıdır.

Animasyon ve hareket bildirimi nasıl etkiler?

Hafif bir kayma ya da solma efekti, bildirimin nereden geldiğini gösterir ve kullanıcının dikkatini yumuşakça çeker. Ancak sert sıçramalar, titreşen kutular ya da uzun animasyonlar dikkati dağıtır. Hareket hassasiyeti olan bazı kişiler için de rahatsız edici olabilir.

Bu yüzden işletim sisteminde "hareketi azalt" tercihini açmış kullanıcılar için animasyonu kapatır ya da basit bir solmaya indirirsiniz. Tarayıcılar bu tercihi CSS tarafında okunabilir bir medya sorgusuyla sunar. Böylece aynı bileşen, her kullanıcının ayarına uyum sağlar.

Animasyon süresi kısa olmalıdır. Kutunun belirmesi uzun sürerse, kullanıcı mesajı okumaya başlamadan önce bekler; kaybolurken uzun sürerse ise sonraki bildirimle çakışır. Ayrıca kaybolma animasyonu, mesajın okunma süresinden düşülmemelidir.

Mikro etkileşimlerin genel kullanımı için mikro animasyon rehberimize bakabilirsiniz. Bildirim özelinde kural basit: hareket bilgiyi destekler, onun yerini almaz.

Aşırı bildirimden nasıl kaçınırsınız?

Her tıklamada bir kutu çıkaran arayüz, bir süre sonra kullanıcıya bildirimleri görmezden gelmeyi öğretir. Önemli uyarı geldiğinde de kimse okumaz. Bu yüzden bildirim, nadir ve anlamlı kaldığında işe yarar.

Ekibimizin kullandığı bazı kurallar şunlar:

• Sonucu ekranda zaten görünen işlemler için bildirim göstermeyin.
• Aynı anda birden fazla toast açmayın; gerekiyorsa sıraya alın.
• Aynı mesaj tekrar tekrar geliyorsa birleştirin: "3 dosya yüklendi" gibi.
• Pazarlama mesajlarını işlem bildirimleriyle aynı bileşende sunmayın.
• Kullanıcı sayfaya girer girmez bildirim göstermeyin; kullanıcı henüz bir şey yapmadı.

Ekran okuyucu tarafında aşırılık daha da yorucudur. Her küçük değişiklik okunursa, kullanıcı asıl içeriği dinleyemez. Dolayısıyla canlı bölgeye yalnız gerçekten bilinmesi gereken metni yazarsınız. Örneğin arama sonuçları her tuş basışında güncelleniyorsa, sonuç sayısını kısa bir gecikmeyle bir kez duyurmak daha rahat bir deneyim sunar.

Mobilde toast tasarımı nasıl farklılaşır?

Mobilde ekran dar ve başparmak alt bölgede hareket eder. Bu nedenle bildirimler çoğunlukla ekranın altında, tam genişliğe yakın bir şerit olarak çıkar. Ancak alt gezinme çubuğu ya da sabit satın al düğmesi varsa, bildirim onların üstünü kapatmamalıdır.

Dokunma hedefleri de önemlidir. Kapat ve geri al düğmeleri parmakla rahatça basabileceğiniz büyüklükte olmalı, birbirine çok yakın durmamalıdır. Kaydırarak kapatma hareketi kullanıyorsanız, aynı işi yapan açık bir düğme de eklersiniz; çünkü her kullanıcı bu hareketi bilmez.

Ayrıca mobilde klavye açıkken ekranın alt yarısı kaybolur. Bu sırada alttan çıkan bildirim görünmeyebilir. Form ekranlarında bu durumu test etmeli, gerekirse bildirimi üste almalısınız.

Yatay ekran, büyük yazı tipi ve sistem genelinde büyük metin ayarı da ayrı senaryolardır. Metin büyüdüğünde kutu taşmamalı, mesaj kesilmemelidir.

Örnek senaryo: e-ticaret sitesinde sepet bildirimleri

Bu bölümdeki akış bir örnek senaryodur, gerçek bir müşteri vakası değildir. Bir giyim mağazasında kullanıcı ürün sayfasında beden seçip "Sepete ekle" düğmesine basıyor.

1. Düğme kısa süre bekleme durumuna geçer; status rolündeki bölge de bu durumu duyurur.
2. İşlem bitince toast mesajı belirir: "Siyah tişört, M beden sepete eklendi." Yanında "Sepete git" bağlantısı vardır.
3. Başlıktaki sepet sayacı da aynı anda değişir; böylece bilgi yalnız toast içinde kalmaz.
4. Kullanıcı beden seçmeden düğmeye basarsa toast çıkmaz. Bunun yerine beden alanının yanında kalıcı bir hata mesajı belirir.
5. Stok o sırada tükendiyse, ürün alanında kalıcı bir uyarı belirir ve sistem alternatif bedenler önerir.

Bu akışta toast yalnız başarıyı haber verir. Hata ve uyarı, ilgili alanın yanında kalıcıdır. Bağlantı içeren toast, fare üzerindeyken ya da odaktayken kaybolmaz. Ekran okuyucu kullanıcısı da aynı sonucu polite bir duyurudan duyar.

Bildirim sistemini nasıl test edersiniz?

Bildirimler gözle bakıldığında sorunsuz durur; sorunlar ancak farklı kullanım biçimleriyle ortaya çıkar. Bu yüzden testi üç katmanda yaparsınız.

İlk olarak klavyeyle test edin. Fareye hiç dokunmadan işlemi tamamlayın, bildirimdeki düğmeye ulaşmayı deneyin ve Escape tuşuyla kapatın. Ardından ekran okuyucuyla aynı akışı dinleyin. Masaüstünde ve mobilde en az birer ekran okuyucu kullanmanız, duyuruların gerçekten okunduğunu görmenin en sağlam yoludur.

Sonra zorlayıcı koşulları deneyin:

• Art arda hızlıca beş işlem yapın; bildirimler üst üste biniyor mu?
• Tarayıcıyı yüzde 200 büyütün; metin taşıyor mu?
• Hareketi azalt tercihini açın; animasyon sadeleşiyor mu?
• Yavaş bağlantıda işlem uzun sürünce bekleme durumu ekranda beliriyor mu?

Bu testleri düzenli bir kullanılabilirlik denetiminin parçası yapmak işinizi kolaylaştırır. Denetim adımlarını UX audit rehberimizde anlattık.

Toast mesajı tasarımı için kontrol listesi

Yeni bir bildirim bileşeni kurarken ya da mevcut olanı denetlerken aşağıdaki listeyi kullanabilirsiniz. Her madde, yukarıdaki bölümlerden birinin özetidir.

1. Mesaj türü belli mi: başarı, hata, uyarı ya da bilgi?
2. Bu bilgi için toast doğru bileşen mi, yoksa satır içi mesaj, bant ya da modal mı gerekiyor?
3. Metin nesneyi ve sonucu tek cümlede söylüyor mu?
4. Hata ve uyarılar kendiliğinden kaybolmuyor mu?
5. Bilgi yalnız toast içinde mi, yoksa sayfada da yer alıyor mu?
6. Fare veya odak üzerindeyken zamanlayıcı duruyor mu?
7. Canlı bölge sayfa yüklendiğinde boş olarak mevcut mu?
8. Varsayılan rol status mu; alert rolünü yalnız acil durumda mı kullanıyorsunuz?
9. Bildirim odağı yerinden oynatmıyor mu?
10. Tür, renk dışında ikon ve metinle de belli mi; kontrast yeterli mi?
11. Bileşen hareketi azalt tercihine uyuyor mu?
12. Ekranda aynı anda tek bildirim mi var?
13. Mobilde sabit düğmelerin ve klavyenin üstünü kapatmıyor mu?

Listenin tamamı yeşilse, bildirim sisteminiz hem görsel hem işitsel olarak tutarlı bir deneyim sunar.

Bildirim sistemini sitenizde kim kurmalı?

Toast bileşenini tek bir sayfada kurmazsınız; bütün sitenin tasarım sistemine işlersiniz. Renkleri, ikonları, metin kalıplarını, süre kurallarını ve erişilebilirlik ayarlarını bir kez tanımlarsınız, sonra bileşen her sayfada aynı şekilde çalışır. Bu nedenle bu iş, tasarım ve geliştirmenin birlikte yürüdüğü bir süreçtir.

Talha Aslan ve ekibi olarak web tasarım hizmetimizde geri bildirim bileşenlerini en başta tasarım sistemine dahil ediyoruz. Mevcut sitenizde bildirimler kaybolup gidiyor, hatalar fark edilmiyor ya da ekran okuyucuda hiçbir şey duyulmuyorsa, bunu birlikte ele alabiliriz.

Sitenizin akışlarını inceleyip hangi işlemde hangi bileşenin kullanılacağını belirliyor, sonra bu kararları kod ve tasarım tarafında uyguluyoruz. Projenizi anlatmak ve teklif almak için web tasarım sayfamızdaki iletişim formunu kullanabilirsiniz.