Arayüzde Tehlikeli İşlemler: Onay, Gecikme ve Geri Alma
Bir arayüzde tehlikeli işlem, yalnızca silme değildir. Yanlış yere düşen tek bir dokunuş sipariş verir, para gönderir, sözleşme imzalar. Hangi korumayı koyacağınız da işlemin türüne değil, geri alınabilir olup olmamasına bağlıdır. Onay kutusu her yerde doğru cevap değil, hatta çoğu yerde yanlış cevap.
Tehlikeli işlem neye denir
Tanımı silmenin üzerine kurmak yanıltıyor. Daha işe yarar ölçüt şu: kullanıcı, sonucu kendi başına ve makul bir çabayla geri alabiliyor mu? Alamıyorsa işlem tehlikelidir. Bir bankacılık uygulamasında "Krediyi Al" butonu hiçbir şey silmez, ama arkasında imzalanmış bir sözleşme bırakır.
Bu ölçütle bakınca aynı kümeye giren işlemler:
- E-posta göndermek
- Sipariş vermek, ödeme başlatmak
- Bir gönderiyi yayımlamak
- Yasal bir belgeyi onaylamak
- Kullanıcıyı kalıcı olarak engellemek
- Yetki vermek ya da geri almak
Onay istemenin biçimleri
Modal diyalog
Modal, kullanıcıyı durdurup akışı kesen kutudur. En yaygın hatası belirsiz dil: "Emin misiniz?" sorusu kullanıcıya neyin olacağını söylemez. Başlık işlemin kendisini yazsın ("Proje X'i sil"), açıklama sonucu anlatsın, buton da eylemi taşısın. "Onayla" yerine "Sil", "Evet" yerine "97₺ öde". Renk körü kullanıcılar için kırmızı tek başına sinyal sayılmaz, yanına bir ikon koyun.
Bir üst basamak, kullanıcıdan bir şey yazmasını istemek. ConvertKit abone silerken "DO IT" yazdırır, Resend API anahtarını silmeden önce "DELETE" ister. Yazma zorunluluğu tıklama refleksini kırdığı için işe yarar, ama her silmede kullanırsanız o da refleks haline gelir.
Tehlike bölgesi
Ayarlar sayfasının en altına, kırmızı çerçeveli ayrı bir bölüm. Hesap silme, sahiplik devri, tüm verinin dışa aktarılıp temizlenmesi gibi geri dönüşü olmayan işlemler için. Buraya koyduğunuz her fazladan madde bölgenin uyarı değerini düşürür, o yüzden listeyi kısa tutun ve şifre tekrarı ya da ikinci faktör isteyin.
Satır içi onay
Zapier ve Typefully gibi uygulamalarda butona bastığınızda etiketi değişir, ikinci tıklamayı bekler. Kazara tıklamayı önlemek için yeterlidir; bilinçli bir hatayı önlemez, zaten amacı da o değil. Çift tıklamayla geçilebilmesi bu yüzden gerçek bir kusur sayılmaz, yeter ki arkasında bir geri alma ya da arşiv olsun.
İkinci faktör ve passkey
SMS, e-posta, kimlik doğrulayıcı uygulama ya da push bildirimi: para transferi, sahiplik devri, hesap kapatma gibi işlemlerde kullanıcı kimliğini yeniden doğrular. Passkey aynı işi cihazın parmak izi veya PIN'iyle yapar; kod bekleme adımı ortadan kalktığı için hem hızlıdır hem de SIM değiştirme ve oltalama saldırılarına karşı SMS'ten dayanıklıdır.
İkinci kişi onayı
Bir kullanıcı işlemi başlatır, başka biri onaylar. Üretim ortamına dağıtım, büyük tutarlı ödeme, kalıcı veri silme gibi yerlerde kurumsal ürünlerin çoğunun tek gerçek koruması budur. Teknik değil örgütsel bir mekanizmadır, dolayısıyla onaylayıcı sayısı arttıkça değil, onaylayıcının işlemi gerçekten okuduğu ölçüde çalışır.
Onay sormanın işe yaramadığı yer
Kullanıcının bir kutuyu onaylaması, işlemi bilinçli yaptığı anlamına gelmez. İnsan zihni tanıdık kalıba dönmeye eğilimlidir ve zihinsel çabayı olabildiğince kısar; aynı diyalog yeterince tekrarlandığında okunmaz, üzerinden geçilir. Buna alışkanlık körlüğü deniyor ve ölçülebilir bir sonucu var: onay kutusu ne kadar sık çıkarsa koruma değeri o kadar düşer.
Bu yüzden onay mekanizmalarını serpiştirmek değil, seyrekleştirmek gerekir. Günde on kez gördüğü kutu kullanıcıyı korumaz, sadece yavaşlatır.
Sormak yerine: gecikme ve geri alma
Yemek teslimat uygulaması Glovo, siparişi onayladıktan sonra sahte bir ilerleme çubuğu gösterir. Bu birkaç saniye, kullanıcıya adresi ve tutarı bir kez daha görme fırsatı verir, üstelik hiçbir soru sormadan.
Geri alma da aynı fikrin daha dürüst hali. E-postayı "geri almak" aslında gönderimi geciktirmektir: sistem mesajı birkaç saniye kuyrukta tutar, siz o pencerede vazgeçerseniz hiç gönderilmez. Belge düzenlerken ctrl + z, dosyayı çöp kutusuna alma, görev durumunu değiştirme, hepsi bu sınıfa girer. Hesap silme, yasal belge sunma, üçüncü taraf API'ye gönderilmiş istek ise girmez; oralarda gecikme penceresi kurmuyorsanız geri alma vaadi de veremezsiniz.
Geri almanın arkasındaki teknik karşılık yumuşak silme: satırı gerçekten silmez, silinmiş olarak işaretlersiniz. Burada çoğu ekibin sonradan çarptığı bir duvar var. Kullanıcı tablosundaki e-posta sütununda unique index varsa, silinmiş satır o adresi işgal etmeye devam eder ve aynı kişi aynı adresle geri dönemez. Bunu deleted_at IS NULL koşullu kısmi index ile ya da silme anında adresi serbest bırakıp arşiv sütununa taşıyarak çözersin, ayrı bir arşiv tablosu kurmaya gerek yok. Aynı şekilde raporlarını ve sayaçlarını da baştan bu koşula göre yazman gerekir, yoksa silinen kayıtlar aylarca toplamlara karışır.
Hangisini ne zaman
Sık yapılan hata, geri alınabilir işlemi modalla korumak ve geri alınamaz işlemi tek tıklamaya bırakmak. Doğru sıralama tersidir: geri alınabiliyorsa hiç sormayın, geri alma sunun. Geri alınamıyorsa sormak yetmez, kullanıcının kimliğini ya da niyetini ayrıca doğrulayın.
Onayla geri almayı üst üste koymak da çoğu zaman gereksiz. İkisi birlikte kullanıldığında onay adımı hızla anlamsızlaşır, çünkü kullanıcı arkasında güvenlik ağı olduğunu bilir. Birini seçin.
Kalan kısım ölçmekle çözülür. Kaç kullanıcı onay kutusundan sonra vazgeçiyor, geri alma kaç saniye içinde kullanılıyor, destek kayıtlarında "yanlışlıkla sildim" kaç kez geçiyor. Bu üç sayı, en iyi uygulama listelerinin tamamından daha çok şey söyler.