Arayüz Metinlerini Sadeleştirmenin Beş Yolu
Arayüzdeki metinler tasarımın süsü değil, kullanım kılavuzunun kendisidir. İyi yazılmış bir buton etiketi kullanıcının ne yapacağını düşünmeden bilmesini sağlar; kötü yazılmış bir yardım kutusu ekranı kalabalıklaştırmaktan başka işe yaramaz. Aşağıdaki beş yaklaşım, metni kısaltmakla sadeleştirmek arasındaki farkı ayırıyor.
Sezgisel dediğimiz şey çoğu zaman öğrenilmiş alışkanlıktır
Kaydet ikonu olarak hâlâ disket kullanılıyor ve buna sezgisellik örneği deniyor. Oysa eline gerçekten disket almış son kuşak bugün kırklı yaşlarında. Bugünün kullanıcısı o şekli disket olduğu için değil, yıllardır kaydet anlamına geldiği için tanıyor. Yani ortada sezgi yok, yerleşmiş bir sözleşme var.
Fark pratikte şuraya çıkar: yerleşmiş bir ikonu etiketsiz bırakabilirsin, yeni bir ikonu bırakamazsın. Yeni bir işlev için tasarlanan simgeyi ilk sürümde etiketiyle birlikte göstermek, metin yer kaplıyor diye etiketi atmaktan daha ucuza gelir. Kullanıcı tıklayıp deneyerek de öğrenir, ama geri alınamayan bir işlemde öğrenmenin bedelini o öder.
Kısaltmadan önce ekranı kimin okuduğuna bak
Aynı ekran, ilk kez giren biri ile her gün oraya bakan biri tarafından farklı okunur. Yeni kullanıcı için bilgi olan cümle, deneyimli kullanıcı için gürültüdür ve her açılışta gözün atlaması gereken bir engel haline gelir.
Bu yüzden "metni kısalt" tek başına bir hedef değil. Doğru soru şu: bu cümle hangi kullanıcı için orada duruyor ve o kullanıcı bu ekrana kaçıncı gelişinde? Cevabı ikisi de olan cümleler kalır, cevabı yalnızca ilk gelen olan cümleler kalıcı yerinden çıkarılır.
Yardım metni kalıcı değil, durumsaldır
İlk kullanımda yol gösteren ipucu onuncu kullanımda ekranı kirletir. Çözüm basit görünür: ipucunu bir kere göster, kullanıcı gördükten sonra kapat. İşin uygulama tarafı çoğu ekipte hafife alınıyor, çünkü "gördü" bilgisini bir yerde tutman gerekir ve o yerin nerede olduğu deneyimi doğrudan belirler.
Bu durumu tarayıcı hafızasına yazarsan, kullanıcı cihaz ya da tarayıcı değiştirdiğinde tanıtım turu sıfırdan başlar. Bir üyelik panelinde ipucu durumunu tarayıcıya yazmıştık; kullanıcılar masaüstünden telefona geçince karşılama turu baştan açıldı. Durumu kullanıcı hesabına bağlamak birkaç satırlık bir alan ekler, karşılığında ipucu gerçekten bir kez görünür.
Kullanıcıya metnin faydasını sormak zayıf bir ölçümdür
"Bu metin yardımcı oldu mu?" sorusu nazik bir soru, ama aldığın cevap davranışı değil kibarlığı ölçer. İnsanlar anlamadıkları bir açıklamaya da evet der, çünkü hayır demek kendini beceriksiz ilan etmek gibi gelir.
Metnin işe yarayıp yaramadığı davranışta görünür. Aynı ekranda kaç kullanıcı geri dönüyor, hangi alan boş bırakılıyor, destek kutusuna hangi soru düşüyor. Bir yardım metnini yazdıktan sonra o ekranla ilgili destek taleplerinin azalması, on tane olumlu geri bildirimden daha fazlasını söyler. Anket sorusu ise en fazla ikinci sırada durur.
Hata metinlerinin sahibi yoksa onları geliştirici yazar
Arayüz metni tek kişinin işi değil derken kastedilen genelde toplantı sayısını artırmak oluyor. Oysa somut mesele daha dar: hata mesajları. Bir formda kaç hata durumu varsa o kadar cümle yazılacak ve bu cümleler sahiplenilmezse kodu yazan kişinin geçici olarak koyduğu metinle yayına çıkar.
Yayına çıkan cümle de çoğu zaman sistemin ne yaşadığını anlatır, kullanıcının ne yapması gerektiğini değil. Geçersiz istek, işlem başarısız, beklenmeyen hata. Hata kataloğunu ekranlardan bağımsız bir liste olarak çıkarmak bu yüzden işe yarıyor: liste görünür olduğu anda kaç tane doldurulmamış cümle olduğu da görünür oluyor.
Kaynaklar