Kullanıcı Hatalarını Önlemek: Onay Diyaloğu Neden Yetmez
Kullanıcı hatalarını azaltmanın ilk adımı, hangi hatayla uğraşıldığını bilmek. Yanlış tuşa basmakla yanlış hedefi seçmek aynı sorun değil ve aynı çözümle kapanmıyor. Arayüzdeki hata önleme kararlarının çoğu bu ayrımı atladığı için, en sık kullanılan araç olan onay diyaloğu genellikle yanlış yere konuyor.
Kayma ile hata farklı şeyler
Kayma (slip), niyet doğruyken eylemin yanlış gitmesi. Kullanıcı ne yapacağını biliyor, elini yanlış yere koyuyor. Otomatikleşmiş işlerde ortaya çıkıyor ve çoğunlukla deneyimli kullanıcıda görülüyor; arayüz tanıdıklaştıkça ona ayrılan dikkat düşüyor.
Hata (mistake) ise niyetin kendisinde. Kullanıcı sistemin nasıl çalıştığını yanlış modelliyor ve tam olarak istediği şeyi yapıyor, ama istediği şey yanlış. Kayma dikkatle ilgili, hata anlamayla. Bu yüzden kaymaya karşı korumanın yolu kullanıcıyı daha çok bilgilendirmekten geçmiyor; ya alanı daraltıp hatayı oluşturmamak gerekiyor ya da sonucu ucuza geri alınabilir kılmak.
Geçersiz seçeneği baştan kapat
Uçuş formunda dönüş tarihinin gidişten önce olması mümkün olmamalı. Takvimde o günler tıklanamaz durumdaysa kullanıcı yanlış tarihi seçemiyor. Alan serbest bırakılıp sonradan doğrulanıyorsa kullanıcı hatayı yapıyor, uyarıyı okuyor, geri dönüyor, baştan seçiyor.
Tarihi takvimde kapatmayı, girildikten sonra kırmızı uyarı göstermekten daha güvenilir bulurum: ilkinde hata hiç oluşmuyor, ikincisinde kullanıcının onarması gereken bir durum oluşuyor.
Bunun bir sınırı var. Kısıtlama, yalnızca geçersiz küme gerçekten sabitse işe yarıyor. Kural bağlama göre değişiyorsa, mesela kampanyaya göre değişen teslimat bölgelerinde, seçeneği kapatmak kullanıcıyı çıkışsız bırakıyor: neden kapalı olduğunu göremiyor, deneyebileceği bir yol da kalmıyor. Orada seçenek açık kalmalı ve sistem nedeni söylemeli.
Onay diyaloğu kaymayı durdurmuyor
"Emin misiniz?" penceresi bu başlığın varsayılan cevabı. Oysa kayma tanımı gereği otomatikleşmiş davranışta ortaya çıkıyor ve her seferinde beliren bir diyalog kısa sürede o otomatizmin parçası oluyor. Kullanıcı okumadan onaylıyor, çünkü onaylamayı öğrendi.
Diyalog ancak nadir ve gerçekten geri alınamaz işlemlerde anlamlı: hesap kapatma, ödeme onayı. Sık tekrarlanan işlemlerde doğru araç geri alma. Silinen öğeyi anında yok etmek yerine birkaç saniyelik "geri al" bandıyla göstermek, kullanıcıyı hiç durdurmadan hatayı ücretsiz hâle getiriyor.
Geri almanın maliyeti tasarımda değil veri modelinde. Kaydı fiziksel olarak silen bir uçtan sonra geri alma yazılamıyor; silme işleminin en baştan işaretleme olarak kurulması, sonra da o işaretin ne zaman temizleneceğine karar verilmesi gerekiyor. Ekranda karşılığı olmayan bir karar, ama arayüzdeki geri alma tamamen ona bağlı. Tasarım kararını uygulamaya götürürken sorulacak soru bu: bu işlem geri alınabilir mi, yoksa sadece öyle mi görünüyor?
Biçim zorlamasını sisteme yıkın
Telefon numarasını "boşluksuz ve başında sıfır olmadan" isteyen form kendi işini kullanıcıya yaptırıyor. Boşlukları, parantezleri ve ülke kodunu temizleyip tek biçime indirmek arka planda birkaç satır tutuyor. Aynısı kart numarası, IBAN ve tarih için geçerli. Kullanıcının girdiği biçimi kabul edin, saklanacak biçime kendiniz çevirin.
Otomatik tamamlama ve akıllı varsayılanlar da aynı ailenin parçası: kullanıcının yazacağı karakter azaldıkça yazım hatası ihtimali düşüyor. Varsayılanlarda tek kural, değerin hem değiştirilebilir kalması hem de onaylanmış gibi görünmemesi. Kimsenin bakmadığı bir varsayılan, kullanıcının kararı olarak kaydediliyor ve sonra raporlarda tercih diye okunuyor.
Sıra
Hata önleme kararlarını şu sırayla verin: geçersiz durumun oluşmasını engelleyin, engelleyemiyorsanız sonucu geri alınabilir yapın, ikisi de mümkün değilse uyarın. Çoğu arayüz bu sırayı tersten kuruyor; uyarıdan başlıyor ve orada kalıyor.