Beş Yaygın Arayüz Hatası ve Somut Düzeltmeleri
Kullanıcı deneyimi sorunlarının çoğu tasarımın büyük kararlarında değil ayrıntıda saklanır: hata mesajının ne zaman göründüğü, form yeniden yüklendiğinde yazılanların durup durmadığı, tarihin hangi sırayla gösterildiği. Aşağıdaki beş sorun hem çok sık görülür hem de düzeltmesi birkaç saatlik iştir. Her birinde önce hatanın nereden çıktığına, sonra yerine ne konacağına bakıyoruz.
Raporlama menüsü kimin sözlüğüyle yazılmış?
Bir raporlama menüsü aslında iki iş birden yapar. Birincisi kullanıcıyı rahatsız eden içerikten kurtarmaktır, ikincisi moderasyon ekibine sınıflandırılmış veri üretmektir. Çoğu menü ikinci işe göre yazılır ve karşınıza "topluluk kurallarının ihlali" gibi maddeler çıkar. Kullanıcı o sözlüğü bilmez; ne seçeceğini kestiremediği için hiçbirini seçmez.
Soruyu kullanıcının kafasındaki haliyle sormak yeter: "Bu gönderiyi neden görmek istemiyorsun?" Altına da hem ağır hem hafif gerekçeler koyun. Hafif seçeneği atlamanın sinsi bir yan etkisi var: sadece "taciz", "nefret söylemi", "yanıltıcı bilgi" sunarsanız, içerikten basitçe sıkılmış kullanıcı da bunlardan birini işaretlemek zorunda kalır. Böylece hem kullanıcı yanlış şey söylemiş olur hem de moderasyon verisi ağır kategoriler lehine şişer. "Bu içerik ilgimi çekmiyor" satırı, veriyi temiz tutmak için oradadır.
Bir de eylemin kapsamını yazın. Kullanıcı yalnızca bu gönderiyi mi gizliyor, o hesabın tamamını mı susturuyor? İkisi çok farklı kararlar ve arayüz hangisi olduğunu söylemiyorsa kullanıcı ikisini de yapmaktan çekinir.
Form hata verdiğinde yazılanları geri ver
En pahalı form hatası doğrulama kuralının kendisi değil, doğrulama sonrası kaybolan veridir. Sunucuya gönderilip yeniden basılan bir sayfada alanları eski değerleriyle doldurmak birkaç satırlık iştir; yapılmadığında kullanıcı on beş alanı yeniden yazmak yerine sekmeyi kapatır. Tek istisna şifre alanlarıdır, onları temizlemek doğrudur.
İkinci mesele doğrulamanın ne zaman çalıştığı. Anlık doğrulamayı genelde alandan çıkışta tetikleyip kullanıcı yeniden yazmaya başladığı anda hatayı temizleyerek kurarım. Her tuş vuruşunda doğrulayan bir arayüz, e-posta adresinin ilk üç harfinde "geçersiz adres" yazar ve kullanıcıya daha ilk saniyede yanlış bir şey yaptığını söyler.
Tarayıcının hazır verdiklerini de kullanın. type="email" ve type="tel" mobilde doğru klavyeyi açar; autocomplete değerlerini (name, email, street-address, one-time-code) doğru yazmak, kayıtlı adres bilgisinin tek dokunuşla dolmasını sağlar. Bunlar üçüncü parti bir kütüphane gerektirmiyor.
Son olarak zorunlu alan sayısına bakın. Her required alan için "bu bilgiyi bugün ne yapıyoruz" sorusunun bir cevabı olmalı. Cevap "ileride lazım olabilir" ise o alan zorunlu değildir.
Tarih biçimi: tahmin etmek yerine belirsizliği kaldırın
03-04-2024 yazan bir alan iki farklı tarihtir. Amerika'da 4 Mart, Avrupa'nın büyük bölümünde 3 Nisan okunur. Bu belirsizliğin boyutu hesaplanabilir: ayın ilk 12 günü her iki sırayla da geçerli bir tarih verir, 13 ve sonrası kendini ele verir. Yılın 12 ayında 12'şer gün, yani 365 günün 144'ü, kabaca yüzde 39'u iki türlü okunabilir. Geri kalanı zaten sorunsuzdur.
Yaygın çözüm, kullanıcının IP adresine bakıp biçimi otomatik seçmek. Bu tavsiyeyi zayıf buluyorum: VPN, seyahat, yurt dışında yaşayan kullanıcı ve şirket ağı çıkışları tahmini kolayca bozar, üstelik yanlış tahmin sessizce yanlış tarih üretir. Tarayıcının Accept-Language başlığı daha iyi bir sinyaldir çünkü kullanıcının kendi ayarıdır, ama o da tahmindir.
Biçimi doğru tahmin etmeye çalışmak yerine belirsizliği ortadan kaldırmak daha sağlam. Gösterimde ay adını yazıyla verin: "4 Mar 2024" hiçbir bölgede yanlış okunmaz. Girişte takvim seçici kullanın, seçilen tarihi alanın hemen altında yazıyla tekrarlayın. Sunucuda tek bir biçim tutun, ISO 8601 ve UTC bunun için var. Kullanıcıya biçim seçtirme fikri kulağa esnek gelse de ayarı bulmayan kullanıcı için hiçbir şeyi çözmez.
Geri bildirim olayın olduğu yerde görünsün
Sayfanın en üstünde toplanan kırmızı hata listesi klasik bir kalıptır ve uzun formlarda işe yaramaz. Kullanıcı listeyi okur, aşağı kaydırır, hangi alandan bahsedildiğini arar. Mesaj ilgili alanın hemen altında dursun, alanın kenarlığı da renk değiştirsin. Renk tek başına yeterli sinyal değil, metin de olmalı.
Gönderim başarısız olduğunda odağı ilk hatalı alana taşıyın. Bu, klavyeyle veya ekran okuyucuyla gezen kullanıcı için tek fark yaratan davranıştır. Hata mesajını aria-live="polite" bir bölgeye yazmak da ekran okuyucunun mesajı sessizce atlamasını engeller.
Uzun süren işlemlerde de aynı kural geçerli. İşlem üç saniyeden uzun sürüyorsa düğmeyi pasif hale getirip durumu yazın; kullanıcı hiçbir şey olmadığını düşünüp ikinci kez tıkladığında karşınıza çift kayıt çıkar.
İlerleme göstergesi ancak dürüstse yardım eder
Çok adımlı bir akışta kullanıcının aklındaki soru sabittir: kaç adım kaldı? Gösterge bu soruya cevap verdiği anda bir söz de vermiş olur. Sözü tutmayan gösterge, hiç göstergesi olmayan akıştan daha kötüdür: üçüncü adımdan sonra beklenmedik dördüncü bir ekran çıkarsa kullanıcı kalan adımlara da güvenmeyi bırakır.
Pratikte üç kural yeter. Adım sayısı baştan belliyse numaralandırın. Belli değilse yüzde göstermeyin, adımların adını yazın ("Adres", "Ödeme", "Onay"); ad listesi büyüdüğünde yalan söylemez. İki adımlı bir akışta ise gösterge koymayın, ekranın üstünde yer kaplayan gereksiz bir süstür.
Ortak payda
Bu beş sorunun tek bir kaynağı var: arayüz, sistemin iç modelini kullanıcıya dayatıyor. Moderasyon kategorileri raporlama menüsüne, veritabanının tarih sütunu ekrana, sunucunun istek döngüsü doğrulama anına aynen yansıtılmış. Düzeltmelerin hepsi aynı yönde çalışır, sistemin bildiğini kullanıcıdan saklamak yerine kullanıcının bildiğini sisteme çevirmek.
Kaynak