Yürütme ve Değerlendirme Uçurumu: Farkı ve Arayüzdeki Karşılığı

Kullanıcı ekranda tıkandığında iki farklı şey olmuş olabilir: ya ne yapacağını bulamamıştır, ya da yaptığı şeyin işe yarayıp yaramadığını anlayamamıştır. Don Norman bunları yürütme ve değerlendirme uçurumu diye ayırır. Ayrım akademik bir incelik değil; ikisinin çözümü farklı, ve arayüz tavsiyelerinin çoğu tam burada karışıyor.

Eylemin iki yakası

Yürütme uçurumu eylemden önce oluşur. Kullanıcının kafasında bir niyet vardır, sistemde ise belirli butonlar, alanlar, komutlar. Bu ikisi arasındaki mesafe açıldıkça deneme sayısı artar. Tipik belirtisi şu: kişi doğru ekranda, aradığı özellik orada, yine de tıklamıyor.

Değerlendirme uçurumu eylemden sonra oluşur. Sistem bir durumdadır ama ekran o durumu anlatmıyordur. Kullanıcı formu gönderir, görünürde bir şey değişmez, tekrar gönderir. Aynı siparişin iki kez düşmesi genelde dikkatsizlik değil, kapatılmamış bir değerlendirme uçurumudur.

Geri bildirim yürütme tarafını kapatmaz

Bu iki kavramı anlatan metinlerde sık rastlanan bir karışıklık var: “kaydedildi”, “hata oluştu” gibi mesajlar yürütme uçurumu başlığı altında sayılıyor. Oysa bu mesajlar kullanıcı zaten tıkladıktan sonra çıkar. Hangi butona basacağını bilmeyen kişiye faydası yok, çünkü o mesajı hiç görmüyor.

Pratikteki sonucu da belli: ekip daha fazla bildirim ekler, terk oranı yerinde kalır. Kayıp, ekrana girip işlemi hiç başlatmayan kullanıcıda.

Yürütme tarafında ne işe yarar

En basiti butonun adını yazmak. Tek başına ikon, kullanıcının o simgeyi başka bir üründe görmüş olmasına bel bağlar; disketi kaydetmek diye okuyan kuşak da azalıyor.

İkinci büyük kaynak pasif butonlar. Buton gri, sebebi yazılı değil, kullanıcı hangi alanı doldurunca aktifleşeceğini bilmiyor. Sebebi butonun yanına tek cümleyle yazmak, ekranı baştan tasarlamaktan daha çok iş görür ve bir öğleden sonra sürer.

Aç/kapa anahtarları ilginç bir vaka: “Açık” etiketi hem mevcut durumu hem basınca olacak şeyi anlatabilir, yani aynı etiket iki uçurumu birden bulanıklaştırır. (Metinsiz anahtarları hâlâ fazla iyimser buluyorum; kullanıcı testinde ilk takılan yer oluyor.)

Değerlendirme tarafı arayüzde bitmez

Arayüz yalnızca elindeki durumu gösterebilir. İstek kuyruğa yazıldıktan hemen sonra 200 dönen bir uç nokta varsa, ekranda görünen “Kaydedildi” doğru bilgi değil: iş hâlâ kuyrukta, kullanıcı bunu bilmiyor ve sayfayı yenilediğinde kaydının kaybolduğunu düşünüyor. Burada metni güzelleştirmek bir şey çözmez. İki gerçek seçenek var: durumu raporlayan bir uç nokta eklemek, ya da etiketi olduğu gibi yazmak (“Kuyruğa alındı”). İkincisi daha dürüst ve neredeyse bedava.

Uzun süren işlerdeki sonsuz spinner da aynı hatanın görsel hali. Sistemin bir şey yaptığını söyler, ne yaptığını ve ne kadar kaldığını söylemez, kullanıcı da beklemekle yeniden denemek arasında karar veremez.

Hangisinden başlamalı

Kaynak metinler ikisine aynı önem atfediyor, ama sıra sorulursa cevabım değerlendirme tarafı. Durumu okuyabilen kullanıcı doğru eylemi deneme yanılmayla bulur, her denemesi ona bilgi verir. Durumu okuyamayan kullanıcı denediğinde de öğrenmez; aynı hatayı tekrarlar, sonra sizi arar.

İstisnası geri alınamayan işlemler. Ödeme, silme, dışa aktarma gibi yerlerde deneme yanılmanın bedeli yüksek olduğu için yürütme tarafı önce kapanmalı: eylemin adı net olsun ve sonucu basılmadan önce söylenmiş olsun.