Change Blindness: Arayüzdeki Değişikliği Kullanıcı Neden Görmez

Bir kullanıcı eyleminden sonra ekranda bir şey değişir ve kullanıcı bunu görmez. Sorun görme keskinliği değil, dikkatin o anda başka yerde olması. Arayüz tasarımında değişim körlüğünün pratik karşılığı şudur: değişikliğin görünür olması yetmez, kullanıcının bakışının o an nerede olduğuyla ilgilenmeniz gerekir.

Körlük değişimde değil, kesintide

Klasik yanıp sönme (flicker) deneylerinde iki sahne arasına kısa bir boşluk konur ve katılımcılar oldukça belirgin farkları onlarca tekrar boyunca bulamaz. Boşluk kaldırıldığında fark anında görülür. Değişimin kendisi zor algılanan bir şey değil; algıyı bozan, değişimle bakış arasına giren kesinti.

Arayüzde bu kesintinin karşılığı sayfa kaydırma, sekme değiştirme, klavyeden forma odaklanma ya da tek bir tıklamayla ekranın üç ayrı bölgesinin birden güncellenmesi. Kullanıcı bir yere bakarken diğer iki bölge sessizce değişir ve o değişiklik hiç olmamış sayılır.

Arayüzde bunu üreten tipik durumlar

• Tek eylemin ekranın birbirinden uzak bölgelerinde eşzamanlı sonuç doğurması
• Sepet sayacı, bildirim rozeti gibi küçük ve düşük kontrastlı göstergelerin güncellenmesi
• Sayfanın üstünde beliren yüzen çubuklar, kullanıcı aşağı kaydırırken görünür olması
• Hata mesajının formun üstünde, kullanıcının yazdığı alanın çok uzağında gösterilmesi

Sonuncusu en pahalıya patlayan olanı. Kullanıcı gönder düğmesine basar, sayfa aynı görünür, tekrar basar. Sunucu tarafında çift kayıt olarak görürsünüz.

Animasyon çözümün tamamı değil

Kaynak tavsiyelerin çoğu tek bir yere çıkar: değişikliği hareketle işaretle. Hareket işe yarar, ama iki yerde tamamen çöker.

Birincisi, sistem düzeyinde hareket azaltma tercihi açık olan kullanıcılar. prefers-reduced-motion sorgusuna saygı duyan bir arayüzde animasyon ya kısalır ya hiç oynamaz; sinyaliniz animasyondan ibaretse o kullanıcı için sinyal yok demektir.

İkincisi, ekran okuyucu kullanan kullanıcılar. Görsel vurgu onlara hiçbir şey iletmez. Değişen bölgeyi aria-live="polite" taşıyan bir bölge içine almak ya da duruma göre role="status" vermek gerekir; bu, tasarım dosyasında görünmeyen ama uygulamada iki satırla hallolan bir karardır. Değişikliği duyurmayı görsel katmana bırakan bir tasarım, kullanıcıların bir kısmını baştan dışarıda bırakır.

Ekranın kalanını karartma veya bulanıklaştırma önerisi de dar bir çözüm: modal içinde işini görür, sayfa akışında kullanıldığında rahatsız edicidir (bu tekniğin genel bir tavsiye olarak verilmesini abartılı buluyorum).

Breadcrumb bu sorunu çözmez

İz yolu navigasyonu kullanıcının hiyerarşide nerede olduğunu gösterir. Bu ayrı bir problemin çözümü. Değişim körlüğü konum bilgisiyle değil, değişikliğin bakış alanına olan mesafesiyle ilgili. Breadcrumb ekleyerek gözden kaçan bildirimleri görünür yapamazsınız.

Değişikliği bakışın olduğu yere taşıyın

Doğru yaklaşım, kullanıcının odağını değişikliğe çekmek yerine değişikliği odağın olduğu yere getirmek. Tıklanan düğmenin kendisi durum değiştirsin. Silme işleminin geri alma bağlantısı silinen satırın yerinde çıksın, ekranın altında beliren bir kutucukta değil. Form hatası ilgili alanın yanında dursun.

Ekranda birden fazla yer güncellenecekse sıraya sokun. Aynı anda değişen üç bölge, kullanıcı için sıfır bölge değişmiş gibidir.

Bunu ölçmek zor değil

Moderatörlü bir oturumda kullanıcıya eylemi yaptırın, sonra ekranı kapatıp sorun: ne değişti. Bir de görevin ortasında "şu an sepette kaç ürün var" diye sorun. Cevap gelmiyorsa göstergeniz ölçüde küçük ya da yanlış yerde. Göz izleme donanımı olmadan da değişim körlüğünün nerede oluştuğunu bu iki soruyla bulabilirsiniz; asıl bilgi kullanıcının nereye baktığı değil, neyi kaçırdığıdır.