Arayüzde Kullanıcı Hatalarını Önlemek: Kayma ve Yanlış Karar

Kullanıcı hatasını sıfıra indirmek diye bir hedef yok; hangi hatanın hangi önlemle kesildiğini bilmek var. Kayma ile yanlış karar ayrı kaynaklardan gelir, bu yüzden onay penceresi birini yakalarken diğerine hiç dokunmaz. İkisini ayırmadan kurulan önlemler ya gereğinden fazla soru sorar ya da yanlış yerde durur.

Kayma ile yanlış karar

Hata türlerini ayıran klasik ayrım Donald Norman'dan gelir ve pratikte işe yarıyor. Kayma (slip), kullanıcının doğru niyetle yanlış hareketi yapmasıdır. Listede üçüncü satırı silmek isterken dördüncünün yanındaki çöp kutusuna basmak kaymadır: niyet doğruydu, parmak kaydı.

Yanlış karar (mistake) ise niyetin kendisinde. Kullanıcı sistemin nasıl çalıştığını yanlış kurgulamıştır; attığı adım kendi modeline göre tutarlı, sisteme göre yanlış. Bir ayarın yalnızca yeni kayıtlara uygulandığını bilmeyip geçmişi de düzelttiğini varsayarak ilerleyen kullanıcı yanlış karar veriyor, elini kaydırmıyor.

Fark şurada işe yarıyor: kayma bir dikkat sorunudur, arayüz onu hareketin önüne engel koyarak ya da sonrasında geri dönüş bırakarak kesebilir. Yanlış karar bilgi sorunudur, onu ancak kullanıcının modelini düzelten bir şey keser. Ekranda sistemin o anki durumunu göstermek, sonucu önceden göstermek, adlandırmayı sistemin gerçekte yaptığı işe uydurmak.

Onay penceresi neyi yakalar

Yıkıcı işlemlerin önüne konan en yaygın önlem onay penceresi. Ne yaptığına dikkatli bakmaya değer: pencere, niyetle eylem arasına bir duraklama koyar. Kayma tam burada kesilir, çünkü kayan kişi niyetinin dışına çıkmıştır ve sorulduğunda bunu görür.

Yanlış karar kesilmez. Kullanıcı yanlış kaydı silmeyi bilerek istiyorsa "Emin misiniz?" sorusuna gönül rahatlığıyla evet der, çünkü pencere ona yeni bir bilgi vermiyor. Sadece zaten verdiği kararı tekrar soruyor.

İkinci sorun tekrardan çıkıyor. Aynı pencere otuzuncu kez göründüğünde tıklama, eylemin kendi hareketinin parçası haline gelir: kullanıcı artık silme düğmesini değil, "sil ve onayla" ikilisini tek jest olarak öğrenmiştir. Bu noktada pencere kaymayı yakalamayı bırakır, kaymanın içine girer. Onay penceresi günde on kez yapılan işte değil, nadir ve gerçekten geri dönüşsüz olanda yerini bulur.

Silmeyi onay penceresine bağlamam. Kaydı gerçekten silmek yerine bir sütunla işaretleyip listelerden düşürmek geri almayı birkaç satırlık işe indiriyor, pencere ise yalnızca soruyu soruyor ve hatayı geri almıyor.

Geri alma ve önizleme

Geri alınabilir bir işlem kullanıcıdan izin istemek zorunda değil. Silinen satırı listeden düşürüp "geri al" bağlantısını birkaç saniye ekranda tutmak kaymayı da, yanlış kararın bir kısmını da kurtarır: kullanıcı sonucu görür, beklediği şey değilse döner. Soru soran pencere bunu yapamaz, çünkü soru sorulduğu anda kullanıcı sonucu henüz görmemiştir.

Geri alınamayan işlemlerde yeri önizleme alıyor. Toplu güncellemede kaç kaydın etkileneceğini söylemek iyi, ama bunlardan birkaçını adıyla göstermek daha iyi. "412 kayıt güncellenecek" satırı yanlış modeli düzeltmez, isimler düzeltir, çünkü kullanıcı listede beklemediği bir şey görür.

Anlık doğrulama ne zaman konuşmalı

Formda hatayı gönderdikten sonra değil yazarken göstermek doğru yaklaşım, ama uygulaması sık sık ters çalışıyor. Her tuş vuruşunda doğrulayan bir e-posta alanı düşünün: kullanıcı a yazdığında alan geçersiz, a@ da geçersiz, a@ornek da geçersiz. Yani alanı baştan sona doğru dolduran kullanıcı, yazdığı sürenin tamamında hata uyarısı görüyor.

Kural şöyle kurulur: ilk doğrulama alan odağı kaybettiğinde yapılır. Bir kez hata gösterildikten sonra tuş vuruşu başına doğrulamaya geçilir, çünkü artık kullanıcı düzeltme yapıyor ve uyarının ne zaman kapandığını görmek istiyor. Tersi, yani baştan her tuşta bağırıp sonra sessizleşen bir alan, kullanıcıya kendi yazdığı şeyin yanlış olduğunu öğretir.

Bellekte tutulan her şey hata adayı

Kullanıcıdan bir ekranda gördüğünü başka ekranda kullanmasını istediğiniz her yerde hata üretiyorsunuz. Doğrulama kodu, sipariş numarası, kopyalanacak anahtar, hepsi aynı kalıpta. Bilgiyi ihtiyaç duyulduğu adımda, kopyalanabilir biçimde ekranda tutmak bu hataların çoğunu ortadan kaldırıyor.

Aynı şey alan sırası için de geçerli. Kullanıcının elindeki belgede bilgiler hangi sırayla duruyorsa formda da o sırayla sormak, alan başına tek bir göz hareketiyle çalışmayı mümkün kılar. Sırayı değiştirdiğinizde kullanıcı eşleştirme yapmak zorunda kalır ve eşleştirme yapılan her yerde yanlış kutuya yazan biri çıkar.

Tanıdık kalıp, görünür işaret

Kullanıcı yeni arayüze eski arayüzlerden öğrendikleriyle geliyor. Düğme düğmeye benziyorsa basılır, metnin altı çizili ve renkliyse bağlantı sanılır. Bu beklentiye aykırı tasarım, kullanıcıyı her ögeyi deneyerek öğrenmeye zorlar; deneme ile hata burada aynı şeydir. Tıklanabilir ögenin tıklanabilir göründüğü, devre dışı ögenin neden devre dışı olduğunu söylediği bir arayüz kayma sayısını kendi başına düşürür.

Standarttan sapmanın maliyeti her zaman var, faydası bazen. Sapıyorsanız bunun karşılığında ne kazandığınızı söyleyebilmeniz gerekir.

Hangi önlem hangi hatayı keser

Hata türü	İşe yarayan	Boşa giden
Kayma	Geri alma, tanıdık kalıp, hedef alanını büyütmek, yıkıcı düğmeyi sık kullanılanın yanından ayırmak	Her seferinde çıkan onay penceresi
Yanlış karar	Sonuç önizlemesi, durumu ekranda göstermek, işi doğru adlandırmak	"Emin misiniz?" sorusu

Bir hata raporunu ya da destek kaydını okurken ilk sorulacak soru bu tablonun hangi satırına düştüğü. Yanlış satıra önlem yazmak, kullanıcıya bir pencere daha göstermekten başka sonuç vermiyor.