Arayüz Standartlarında Tutarlılık: Neyi Korumalı, Neyi Sorgulamalı

Tutarlılık üzerinde herkesin anlaştığı bir ilke, ama neye göre tutarlılık olduğu çoğu zaman atlanıyor. Kendi ürününüzün içinde mi, işletim sisteminin kuralına göre mi, kullanıcının o gün en çok vakit geçirdiği uygulamaya göre mi? Bu üçü sık sık birbiriyle çelişir ve asıl tasarım kararı hangisine uyulacağını seçmektir.

Standart dediğimiz şey nerenin standardı

Diyalog kutusunda onay ve vazgeç butonlarının bulunması yıllardır kural sayılır. Peki hangi sırayla? Windows onay butonunu solda, macOS sağda konumlandırır; iOS ile Android’in uyarı kutuları da birbirini tutmaz. Yani “butonları her zaman alışılmış yerine koyun” tavsiyesi, platform sınırını geçer geçmez kendi kendini çürütür.

Web bu çelişkiyi daha da görünür hale getiriyor, çünkü aynı sayfa iki işletim sisteminde birden açılıyor. Burada işletim sistemini taklit etmeye çalışmak yerine ürün içi tutarlılığı korumak daha çok iş görür: kullanıcı sizin sayfanızdayken karşılaştırdığı şey yine sizin diğer sayfanız oluyor. Kaçınılması gereken, aynı ürünün iki ekranında iki farklı onay düzeni kullanmak.

Etiket, buton konumundan daha çok iş görür

“OK” yazan bir buton hiçbir şey anlatmaz, sadece bir şeyi kabul ettiğinizi söyler. Kullanıcı uyarı metnini okumadan geçtiyse, neyi kabul ettiğini de bilmez. Butonun üzerinde eylem yazdığında bu sorun kendiliğinden kapanır: Kaydet, Sil, Aboneliği İptal Et. Vazgeçme seçeneği de “İptal” yerine yapılan işi söylerse daha iyi, çünkü abonelik iptali ekranında “İptal” butonu tam ters anlaşılabilecek bir kelime.

İyi seçilmiş varsayılan ayarlar bu yükün büyük kısmını üstlenir. Kullanıcıların çoğu varsayılanı değiştirmez, dolayısıyla bir diyalog kutusunun asıl tasarımı seçeneklerin dizilişi değil, hiçbir şeye dokunulmadığında ne olacağıdır.

Onay penceresi mi, geri alma mı

Yıkıcı işlemleri onay kutusu yerine geri alınabilir bir akışla çözerim. Onay kutusunu kullanıcı üçüncü kez gördüğünde okumayı bırakıyor, refleks halinde geçiyor ve koruma diye eklenen adım tek işlevini kaybediyor. İşlemi yapıp ekranın altında birkaç saniye duran bir geri alma bandı göstermek hem daha az kesintiye yol açar hem de gerçekten yanlış tıklayan kişiyi kurtarır.

Maliyeti de sanıldığı kadar yüksek değil: kaydı gerçekten silmek yerine silinme zamanını damgalayıp sorgularda filtrelemek, çoğu ekranda birkaç satırlık iş. Kalıcı silmeyi arka planda çalışan bir temizliğe bırakırsınız. Buna karşılık geri alma penceresi bittikten sonra tetiklenen bildirim, fatura, dışa aktarma gibi yan etkileri geciktirmeniz gerekir; asıl tasarım kararı orada veriliyor.

Odak, klavye ve kontrol hissi

Kullanıcının arayüz üzerinde gerçek bir fiziksel denetimi yok, ama kontrol hissi küçük davranışların toplamından oluşuyor. Bir modal açıldığında odağın modalın içine geçmesi, Esc tuşunun kutuyu kapatması, sekme tuşunun arka plandaki bağlantılara kaçmaması, kutu kapandığında odağın onu açan butona geri dönmesi gerekir. Bunların hiçbiri görünür bir özellik değil; ancak eksik olduklarında fark ediliyorlar.

Klavyeyle gezinen ve ekran okuyucu kullanan ziyaretçiler için bu davranışlar süs değil, kullanılabilirliğin kendisi. Arka planın kaydırılmaya devam ettiği bir modal, fare kullanan birinin gözünden küçük bir kusur, klavye kullanan biri içinse çıkışı olmayan bir oda.

Kademeli gösterim tutarlılığı bozar mı

Peki gelişmiş ayarları katlanır bir bölüme saklamak, kullanıcının beklediği düzeni bozmuş olmuyor mu? Olmuyor, çünkü bozulan şey yerleşim değil beklenti. Kullanıcı aradığı ayarı bulduğu sürece onun ikinci seviyede durması sorun çıkarmaz. Tutarlılığı bozan asıl davranış başka: aynı işlemin iki ekranda iki farklı biçimde durması, bir yerde açılır menü, öbür yerde ayrı bir pencere olması.

Tutarlılığı ölçmenin ucuz yolu

Bir arayüzün ne kadar tutarlı olduğunu anlamak için kullanıcı testine gerek yok, saymak yeterli. Üründe kaç farklı buton tipi var, kaç farklı onay biçimi kullanılıyor, hata mesajları kaç ayrı yerde ve kaç ayrı üslupla gösteriliyor. Sayılar büyüdükçe kullanıcının öğrenmesi gereken kural sayısı da büyür. Yeni bir bileşen eklemeden önce sorulacak soru, mevcut bileşenlerden birinin bu işi görüp göremeyeceği.