Yeni İnternet Kullanıcısını Zorlayan Şey: Görünmeyen Sistem Durumu
İnternete yeni başlayan biri sistemi anlamadığı için takılmıyor; sistem ona ne olduğunu söylemediği için takılıyor. Destek kayıtlarındaki şikâyetlerin büyük kısmı bilgisizlikten değil, arayüzün elinde olan bilgiyi saklamasından doğuyor. Yani sorunun çoğu tasarım tarafında çözülebilir durumda, kullanıcı eğitiminde değil.
Sistem durumu biliyor, söylemiyor
Şifre alanına doğru şifreyi yazan ama CAPS LOCK açık olduğu için giremeyen kullanıcı teknik olarak hiçbir şeyi yanlış yapmıyor. Klavyenin kipini işletim sistemi biliyor, tarayıcı biliyor, formu çizen sayfa da öğrenebiliyor. Kullanıcıya dönen cevap ise "şifre hatalı" oluyor: elindeki tek ipucu, onu yanlış yere götüren ipucu.
Tarayıcıda bu üç satırlık bir iş. Parola alanındaki tuş olayını dinler, event.getModifierState('CapsLock') sonucuna göre uyarıyı gösterirsiniz. Bir müşteri panelinde bu uyarıyı ekledikten sonra "şifrem kabul edilmiyor" taleplerinin gözle görülür bir kısmının kaybolduğunu gördüm.
Zihinsel model çakışması
Çevirmeli bağlantı döneminin klasik destek çağrısı şuydu: evde telefonla konuşulurken internete bağlanamayan kullanıcı, modemin de aynı hattı kullandığını bilmediği için ekrandaki "bağlanılamadı" ile salondaki konuşma arasındaki bağı kuramıyordu. Bu bir bilgi eksikliği değil, yanlış kurulmuş bir modeldi.
Örnek eskidi, kalıp eskimedi. Pencereyi kapatmanın programı durdurmadığını bilmeyen kullanıcı, uygulamayı yeniden açtığında beklediği pencereyi göremez ve "çalışmıyor" der. Webde ise durum tam tersine döner: sekmeyi kapatmak kaydedilmemiş formu gerçekten siler. Aynı eylem iki ortamda zıt sonuç verdiği için kullanıcı kendi deneyiminden doğru genellemeyi çıkaramaz. Buradaki iş kullanıcıyı eğitmek değil, uygulamanın hangi durumda olduğunu ekranda tutmaktır: çalışıyor mu, kaydedildi mi, bağlantı duruyor mu.
Maliyeti kullanıcıya bindiren talimat
Yeni kullanıcıya telefonda ya da yardım metninde verilen "şu klasörü sil", "ayarları sıfırla" türü talimatlar, karşı taraf ne yaptığını anlamadan uyguladığı için risklidir. Yazılımla donanım arasındaki ayrımı bilmeyen biri, talimatın hangi adımda geri dönüşsüz hale geldiğini de bilemez. Geri alınamayan işlemi onayla, önizlemeyle ya da gerçek bir geri alma ile sarmak geliştiricinin işidir. Kullanıcıdan dikkat beklemek çözüm sayılmaz.
Hata mesajı, yardım sayfasından önce gelir
Yeni başlayanlar için rehber yazmak yaygın çözüm, ama kendi içinde bir çelişki taşıyor: yardım sayfasını bulmak için sorunu adlandırmak gerekir. Hatanın ne olduğunu anlamayan kullanıcı doğru aramayı yapamaz, dolayısıyla tam kendisi için yazılmış sayfaya hiç ulaşmaz. Rehber, arayüzün söylemediği şeyin telafisidir; önce arayüz konuşmalı.
İşe yarayan hata mesajının ölçütleri kısa:
- Olayın geçtiği yerde söyler, kullanıcıyı başka sayfaya göndermez.
- Nedeni sistemin bildiği kadar açık yazar. "Geçersiz giriş" değil, "parola en az 8 karakter olmalı, 6 karakter girdiniz".
- Sonraki adımı kullanıcının kendi yapabileceği bir eylem olarak verir; destek kanalı en son sırada durur.
- Teknik ayrıntıyı atmaz, ikinci plana alır. Destek tarafı o hata koduyla çalışıyor, kullanıcının ilk ekranında ise yeri yok.
Yeni kullanıcıyla test yapmanın en hızlı yolu da burada. Kişiye bir görev verin, konuşmayı bırakıp ekranı gözle taradığı anları not edin. O anların çoğu, arayüzün söylemeyi atladığı bir durumun üstüne denk gelir.