Zihinsel Modeller ve Arayüzün Gerçek Davranışı
Bir arayüzü ilk kez açan kişi boş bir zihinle gelmez. Daha önce kullandığı onlarca uygulamadan devraldığı bir beklenti listesi vardır: arama kutusu yukarıda durur, sepet sağ üstte olur, geri tuşu bir adım geri alır. Zihinsel model dediğimiz şey kabaca bu beklenti setidir. Tasarımın işi de bu modelle sistemin gerçek davranışı arasındaki mesafeyi kapatmaktır.
Model nereden geliyor
Zihinsel model, kişinin geçmiş deneyimlerinden damıttığı bir tahmin makinesidir. Don Norman'ın meşhur kapı örneği bunu en kısa yoldan anlatır: üzerinde tutamak olan bir kapıyı çekmeye, düz bir metal plaka olanı itmeye çalışırız. Kapıda "İTİNİZ" yazısı varsa ve insanlar hâlâ çekiyorsa, sorun insanlarda değil, tutamağın verdiği yanlış sözde.
Ekranda bu söz; ikonla, etiketle, öğelerin sırasıyla verilir. Sağ üstteki dairesel fotoğraf "burası benim hesabım" der. Altı çizili mavi metin "tıklanır" der. Bu sözler tasarımcının niyetinden bağımsız çalışır, çünkü kullanıcı onları sizin ürününüzde değil, önceki on üründe öğrendi.
Mesafeyi tahmin etmeyin, ölçün
Tasarımcının kendi zihinsel modeli, üzerinde aylarca çalıştığı sistemin modelidir. Artık temiz bir gözle bakamaz. Bu yüzden beklentiyi ölçmek gerekir, üç yöntem de ucuzdur:
- Kart gruplama: menü başlıklarını kullanıcıya verip kendi mantığıyla dizmesini istersiniz. Ortaya çıkan gruplar sizin bilgi mimarinizden farklıysa, mesafe oradadır.
- İlk tık testi: görevi verir, yalnızca ilk tıklamaya bakarsınız. İlk tık yanlış gidiyorsa kullanıcı çoğu zaman görevi tamamlasa bile ekranı güvensiz bırakır.
- Ekranı durdurup sormak: görüşmede kullanıcı bir butona basmadan önce "şimdi ne olmasını bekliyorsun" diye sorarsınız. Cevap ile gerçek davranış arasındaki fark, düzeltilecek yerin tam adresidir.
Bir projede menüdeki "Tanımlar" başlığını ekibin hiç tartışmadan koyduğunu, kullanıcıların ise aradıkları her şeyi "Ayarlar" altında aradığını ilk tık testinde gördüm.
Bu testlerin hepsi bir sabah sürer. Bilgi mimarisini yayına aldıktan sonra değiştirmek ise bambaşka bir iştir: eski bağlantılar, yönlendirmeler, dokümantasyon, destek kayıtları. Ölçümü öne almanın gerekçesi burada, kullanıcı nezaketinde değil.
İpucu balonu çözüm değil, teşhistir
Kullanıcı modeliyle sistem örtüşmediğinde ilk akla gelen çözüm açıklama eklemektir: karşılama turu, ipucu balonu, yanına küçük bir soru işareti. Bunlar mesafeyi kapatmaz, üzerini örter.
Maliyet tarafı da simetrik değil. Bir butonun adını düzeltmek bir kereliktir; onun yanına koyduğunuz açıklama balonunu ise her sürümde güncellemek, her dile çevirmek, her ekran boyutunda konumlandırmak zorundasınız. Üstelik balonun faydası kullanıcı başına yalnızca ilk seferdir, yükü her sürümde sizdedir.
Açıklamanın hakkıyla durduğu tek yer, gerçekten yeni bir kavramdır: kullanıcının başka hiçbir üründen devraldığı karşılığı olmayan, alana özgü bir işlev. Standart bir eylemi açıklamak zorunda kaldıysanız, yapılacak iş etiketi değiştirmek ya da öğeyi beklendiği yere taşımaktır.
Tutarlılığı ne zaman bozmak gerekir
"Kullanıcı zamanla yeni modeller öğrenir" cümlesi doğrudur ama her ürün için aynı ölçüde geçerli değil. Öğrenme maliyeti bir kez ödenir, karşılığı her kullanımda toplanır. Günde birkaç kez açılan bir panel için bu hesap hızla artıya geçer, o yüzden kurumsal araçlarda alışılmadık ama verimli kısayollar mantıklıdır. Yılda iki kez girilen bir sitede aynı hesap asla kapanmaz: kullanıcı öğrendiğini ikinci gelişinde unutmuş olur.
Pratik kural olarak şu ayrımı kullanıyorum: tutarlılık varsayılan, sapma gerekçe ister. Gerekçe de "daha modern görünüyor" değil, tek oturum içinde ölçülebilen bir kazanç olmalı. Kullanıcının alışmasını bekleyen bir tasarım kararı, aslında ölçümü gelecek bir tarihe atmış karardır.
Otomatik kayda geçip kaydet butonunu kaldıran ürünlerin yaşadığı şey de bu. Kayıt gerçekten daha güvenilir hale gelir, ama kullanıcının "işim kaydedildi mi" sorusunu cevaplayan görünür işaret ortadan kalkar. Butonu kaldırmak teknik olarak doğru, o işareti yerine koymadan kaldırmak ise eksik iştir.
Kaynaklar