Hata Yapmayı Zorlaştıran Tasarım: Onay Ekranı mı, Geri Alma mı?

Kullanıcı yanlış butona bastığında sorun çoğu zaman dikkatsizlik değil, o iki butonu yan yana koyan karardır. Hata önleme de bu yüzden uyarı metni yazmakla değil, akışı yeniden kurmakla başlar. Aşağıda üç savunma hattı var ve güvenilirlik sıraları şu: hatayı imkânsız kılmak, geri almayı mümkün kılmak, en son olarak onay istemek.

Slips ve mistakes aynı çözümle kapanmaz

Slip, doğru niyetle yapılan yanlış eylemdir: ne yapmak istediğini biliyorsun, elin kayıyor. Mistake ise yanlış niyetin kendisidir: sistemi yanlış anlamışsın, doğru düğmeye basıyorsun. İkisini aynı çözümle kapatamazsın. Slip'i arayüzün yerleşimi üretir, dolayısıyla çözümü de yerleşimdedir; görsel ve fiziksel mesafe, benzer isimlerin ayrıştırılması. Mistake'i zayıf geri bildirim üretir, çözümü sistemin o anda hangi durumda olduğunu göstermesidir.

2018'deki Hawaii yanlış füze uyarısı slip'in ders kitabı örneği. Tatbikat uyarısı ile gerçek uyarı aynı listede, birkaç satır arayla duruyordu. Operatörün dikkatini sorgulamak yerine şunu sormak gerekir: bu iki seçenek neden aynı menüdeydi?

Onay ekranı en zayıf savunmadır

Onay ekranını geri alma mekanizmasından daha zayıf bir güvence sayarım. Sebebi basit: onay ekranı kullanıcının tam o andaki dikkatine bağlıdır, geri alma ise bağlı değildir. Dahası, her işlemde çıkan bir diyalog tam olarak kendisini aşacak kas hafızasını eğitir. Üçüncü kez “Emin misiniz?” gören kişi artık metni okumuyor, Enter'a basıyor.

Diyalog yalnızca nadir ve gerçekten dönüşsüz işlemlerde değerlidir. Her silme işleminin önüne koyarsan değerini kendi elinle düşürürsün. Çalışan tek varyantı, kullanıcıdan kaydın adını yazmasını isteyen türüdür, çünkü o, kas hafızasıyla geçilemez; okumayı zorunlu kılar.

Geri alma bir arayüz özelliği değil, veri katmanı kararıdır

Altındaki yazma yolu tersine çevrilebilir değilse ekrana “geri al” düğmesi koyamazsın. Pratikte üç yoldan biri gerekir:

• İşlemi kuyruğa alıp gecikmeli çalıştırmak. E-posta istemcilerindeki beş saniyelik pencere budur; iptal edilebilirlik o gecikmenin kendisidir.
• Kaydı silmek yerine silinmiş olarak işaretlemek.
• Durum değişikliklerini sırayla loglayıp geri sarabilmek.

Üçü de tasarım toplantısından önce verilmiş olması gereken kararlar. Hazır akışın üstüne sonradan undo yapıştırmak çalışmaz. Maliyeti de görünür: iptal penceresi istiyorsan senkron çağrıyı asenkrona çevirmen ve kullanıcıya “gönderildi” demeyi birkaç saniye geciktirmen gerekir. Bu, arayüz tarafında bir rötuş değil, mimari bir tercih.

Geri alınamayanı ulaşılması zor hale getir

Bazı işlemler gerçekten geri alınamaz. On bin cihaza düşmüş bildirim, tamamlanmış transfer, kamuya gitmiş acil durum uyarısı. Burada kalan tek savunma, işleme giden yolu zorlaştırmaktır. Canlı ve test akışları aynı menüde durmaz; ayrı ekran, ayrı yetki. Yıkıcı işlemin yetkisi dar tutulur. Ve bu tür işlemlerin arkasına mutlaka bir “ne gönderildi, kime gitti” ekranı konur, çünkü hata olduğunda ilk ihtiyaç duyulan şey düzeltme değil, ne olduğunu görmektir.

Bu listede kullanıcıyı eğitmek yok. Eğitim bireye yazılır, akış ise herkese; ikisinin ölçeği aynı değil.