Hataları Affeden Arayüzler: Ne Zaman Düzelt, Ne Zaman Sor
"Geçersiz telefon numarası" uyarısı çoğu zaman kullanıcının hatası değildir; numaranın başındaki sıfırı silme işini kullanıcıya devretmenin sonucudur. Hataları affeden arayüz fikri bu kadar basit: girdiyi geldiği gibi kabul et, temizlemeyi kendin yap. Zor olan kısmı sınırını bilmek, çünkü her düzeltme sessizce yapılamaz.
Affetmek, hata mesajını güzelleştirmek değil
"Telefon numaranızı başında sıfır olmadan girin." Bu cümle rehberlik gibi görünür, aslında bir itiraftır: baştaki sıfırı kırpmak tek satırlık bir iştir ve o satırı yazmak yerine kullanıcıdan yazmasını istemişsinizdir. Kart numarasındaki boşluklar, IBAN'daki tireler, kopyala-yapıştır sırasında e-postanın sonuna yapışan boşluk için de aynısı geçerli.
Affedici bir alan girdiyi olduğu gibi alır, normalleştirmeyi kendi üstlenir. Kullanıcının klavyede hangi biçimi tercih ettiği sizin veri modelinizin sorunudur; ona taşıtmayın.
Sessiz düzeltme ile tahmin arasındaki çizgi
"Otomatik düzeltme" tek bir şey gibi anlatılır ama iki ayrı şeydir ve karıştırıldığında zarar verir.
Birincisi kayıpsız normalleştirme: baştaki ve sondaki boşluğun kırpılması, "0532 123 45 67"nin rakamlara indirgenmesi, büyük-küçük harfin eşitlenmesi. Tek bir doğru sonuç vardır, tahmin yoktur. Sessizce yapılabilir, çünkü kullanıcıya bildirilecek bir belirsizlik yok.
İkincisi tahmin: "İstanbl"ı "İstanbul"a çevirmek, posta kodunu şehirden türetmek, iki "Athens"tan birini seçmek. Burada bir olasılık hesabı ve sıfırdan büyük bir yanılma payı var. Tahmini sessizce uygulamak hatayı ortadan kaldırmaz, sadece kullanıcının göremeyeceği bir yere taşır: form sorunsuz gönderilir, kargo yanlış şehre gider.
İşleyen kural şu: kayıpsız olanı sessizce yap, tahmini göster ve geri alınabilir bırak. Google arama kutusu bunu yıllardır aynı biçimde çözüyor — düzeltilmiş sorguyu çalıştırır, ama "bunun yerine şunu arayın" satırını da bırakır. Tahminini uygular, tahmin olduğunu saklamaz.
Doğrulamayı ne zaman göstermeli
Anlık doğrulama iyi bir fikir olarak anlatılır, uygulanışı çoğu zaman kötüdür. Her tuş vuruşunda kontrol eden bir e-posta alanı, kullanıcı daha adının ikinci harfindeyken "geçersiz e-posta" yazar. Kullanıcı hata yapmamıştır; henüz bitirmemiştir.
Daha az can sıkan sıralama: alandan ilk çıkışta doğrula, yalnızca bir kez hatalı bulunduktan sonra yazarken doğrulamaya geç. Böylece ilk yazışta rahat bırakılır, düzeltirken ise hatanın kapandığını anında görür.
Gönderdikten sonra topluca hata dökmek en pahalı seçenek. Kullanıcı formu doldururken sahip olduğu bağlamı çoktan kaybetmiş oluyor ve onu yeniden kurmak zorunda kalıyor.
Tek yol dayatan formlar
Adres formlarındaki tanıdık zincir: önce il, sonra ilçe, sonra mahalle. Posta kodunu bilen biri için bu üç adımın üçü de gereksiz. Aynı veriye birden fazla giriş yolu bırakmak — posta kodundan doldurma, haritadan seçme, serbest metni ayrıştırma — hata oranını düşürür, çünkü kullanıcının elindeki bilginin biçimiyle formun beklediği biçim çoğu zaman örtüşmez.
Bunun bir maliyeti var: her ek yol, ayrıştırılacak ve test edilecek yeni bir giriş biçimi demek. Yolları çoğaltmadan önce gerçekte hangi biçimin geldiğine bakın; sunucu tarafında reddedilen girdilerin kaydı bunu kullanıcı testinden çok daha ucuza söyler.
Soru sormanın doğru anı
"Athens" hem Yunanistan'da hem Georgia'da bir şehir. Sistem birini seçip devam ederse kullanıcı seçim yapıldığını fark bile etmeyebilir. Doğru hamle belirsizliği belirsiz olduğu anda göstermek: iki seçenek, tek tıkla karar, akışa geri dönüş.
Denge burada kuruluyor. Her belirsizlikte soru sormak akışı boğar, hiç sormamak sessiz yanlışlar üretir. Ayrım noktası bedelin geri alınabilirliği: yanlış tahmin kullanıcının fark ettiği anda düzeltilebiliyorsa tahmin edin, ödeme ve silme gibi geri dönüşü olmayan yerlerde sorun.
Kaynak