Slip mi Mistake mi: Kullanıcı Hatasının İki Türü ve Ters Çözümleri
Kullanıcı yanlış düğmeye bastığında karşınızda tek bir sorun yoktur, iki ayrı sorundan biri vardır. Don Norman'ın The Design of Everyday Things'de yerleştirdiği ayrımla: hedef doğru ama hareket kaydıysa slip, hareket kusursuz ama hedef yanlışsa mistake. İkisi aynı arayüz düzeltmesiyle çözülmez. Birine iyi gelen düzeltme çoğu zaman diğerini büyütür.
Slip: doğru plan, yanlış el
Slip'te kullanıcı ne yapmak istediğini biliyordur. Arşivlemek ister, silme ikonuna basar. Formu kaydetmek ister, yanındaki iptale tıklar. Niyetle sonuç arasındaki mesafe bir piksel kadardır.
Buradaki asıl sürpriz şu: slip acemi hatası değildir. Tersine, bir işi yeterince tekrarlayanın hatasıdır. Tekrar eden eylem dikkati bırakır, otomatikleşir, ve otomatik eylem yönünü kontrol etmeden ilerler. Klavye kısayolunu ezberlemiş bir kullanıcı, menüde tek tek arayan kullanıcıdan daha hızlı yanlış şeyi siler. Ürününüz olgunlaştıkça ve kullanıcılarınız ustalaştıkça slip oranı düşmez, artar.
Mistake: yanlış plan, doğru el
Mistake'te eller isabetlidir, kafadaki model bozuktur. "Arşivle" düğmesinin dosyayı yedeklediğini sanan biri tam olarak istediği düğmeye basar ve yine de istemediği sonucu alır. Sistem ona hiçbir aşamada yanlış bir şey yaptığını söylemez, çünkü teknik olarak yanlış bir şey yapılmamıştır.
Bu yüzden mistake, tekrar denemekle düzelmez. Kullanıcı aynı hatalı modeli ikinci kez uygular, üçüncü kez uygular, sonunda ürünün bozuk olduğuna karar verir. Slip kullanıcıyı kendine kızdırır, mistake size.
İki çözüm ters yönlere çeker
Mistake'in ilacı öğretmektir: sonucu söyleyen etiketler, doğru zihinsel modeli kuran bir ilk kullanım akışı, işlemin ne yaptığını gösteren önizleme. Slip'in ilacı ise dikkatten bağımsız güvenlik ağıdır, çünkü slip yapan kullanıcı zaten dikkatli davranmayı düşünmemektedir.
Ve burada sinsi bir denge var. Öğretmek uzmanlaşmayı hızlandırır, uzmanlaşma otomatikleşmeyi getirir, otomatikleşme de slip üretir. Onboarding'i iyileştiren ekip birkaç ay sonra toplam hata sayısının pek düşmediğini görür; düşen mistake'tir, yerini slip almıştır. Bu bir başarısızlık değil, beklenen devir. Yeni ürün mistake ile boğuşur, olgun ürün slip ile. Yol haritasını da buna göre kurmak gerekir: destek taleplerinde "bunu nasıl yapacağım" azalıp "bunu geri alabilir miyim" çoğalmaya başladığında, yatırımı eğitimden geri almaya kaydırma vaktidir.
Onay penceresi neden işe yaramıyor
Slip'e karşı ilk refleks hep aynı: "Emin misiniz?" kutusu koymak. Ama o kutu da tekrarlanan bir eylemdir ve tekrarlanan her eylem otomatikleşir. Silme akışında onay her seferinde çıkıyorsa kullanıcı "Evet"e okumadan basmayı öğrenir. Ekran slip'i durdurmaz, slip'i bir tık ileri taşır.
Doğru cevap geri almadır. Gmail'in gönderimi geri al penceresi bunun en bilinen örneği: soru sormaz, sonucu birkaç saniye askıda tutar. Fark önemli, çünkü slip'in tanımı gereği kullanıcı hatayı eylem anında değil, sonucunu gördüğü anda fark eder. Onay penceresi soruyu farkındalığın olmadığı anda sorar, geri alma ise cevabı farkındalığın oluştuğu anda verir.
Onay kutusunun yeri, işlem hem geri alınamaz hem de seyrekse oradadır: hesabı kalıcı silme, sunucuyu sonlandırma, ödeme onaylama. Günde on kez tekrarlanan bir işlemin önüne konmuş onay, güvenlik değil gürültüdür ve gürültü olduğu için de güvenlik sağlamaz.
Ölçerken de ayırın
Çoğu ekip tek bir "hata oranı" metriği tutar. O metrik iki farklı olguyu toplayıp ortaladığı için hangi düzeltmenin işe yaradığını görünmez kılar: eğitim iyileşince mistake düşer, slip yükselir, toplam sabit kalır ve ekip yaptığı işin boşa gittiğini sanır.
Ayırmak için pahalı bir araca gerek yok. Geri alma bağlantısına basılma oranı, işlemden hemen sonra yapılan iptaller ve saniyeler içinde geri dönülen ekranlar slip'i sayar. Yardım araması, destek talebi, aynı akışın üst üste tekrarlanması ve işlem sonrası uzun duraklama mistake'i sayar. Bu iki sayacı ayrı tutan bir ekip, hangi ay hangi tarafa bütçe ayıracağını tartışmak zorunda kalmaz; veriden okur.