Mental Model: Kullanıcı Beklentisi Nereden Gelir, Nerede Kırılır

Bir arayüzü ilk kez açan kişi onu sıfırdan öğrenmez; daha önce kullandığı onlarca şeyden topladığı bir tahminle gelir. Mental model bu tahminin adı: sistemin nasıl çalıştığına dair kafada taşınan, çoğu zaman yanlış ama iş gören basit bir kopya. Tasarımın işi bu kopyayla sistemin gerçek davranışını birbirine yaklaştırmak.

Kafadaki kopya neye benzer

Mental model, kullanıcının sistemin iç işleyişi hakkında kurduğu basitleştirilmiş bir açıklamadır. Eksiktir, yer yer kendi içinde çelişir, çoğu zaman da yanlıştır. Buna rağmen iş görür, çünkü kullanıcının ihtiyacı doğru bir açıklama değil, bir sonraki adımı tahmin etmesine yetecek kadar iyi bir açıklamadır.

Asansör düğmesine ikinci kez basan kişi tam olarak bunu yapar: kafasındaki modelde daha fazla giriş, daha hızlı yanıt demektir. Model yanlış, davranış tutarlı. Arayüzde de aynısı olur. Kullanıcı yanıt vermeyen butona ikinci kez basar, formu iki kez gönderir, sonucu sizin sunucunuz toplar.

Beklenti nereden geliyor

Bir beklentinin kaynağı iki yerden biridir ve hangisi olduğu, tasarımda ne yapacağınızı belirler.

Birincisi ürününüzün dışı: işletim sisteminin alışkanlıkları, rakip uygulamalar, fiziksel dünyadan gelen benzetmeler. Sepet ikonunun sağ üstte durması, çarpı işaretinin kapatması, sola kaydırmanın silmesi. Bu beklentiler sizin ürününüzden önce kurulmuştur, binlerce tekrarla pekişmiştir; tek bir arayüzde onları yeniden eğitme şansınız yok.

İkincisi ürününüzün içi: kendi koyduğunuz isimler, kendi tanımladığınız akışlar, yalnızca sizde olan durumlar. Taslak ile yayınlanmamış arasındaki farkı kullanıcı sizden öğrenir, çünkü öğrenebileceği başka bir yer yok.

Metafor aldığı kadar vaat de eder

Gerçek dünyadan alınan benzetmeler öğrenmeyi hızlandırır, bedeli de beraberlerinde getirdikleri beklentilerdir. Sepet dediğiniz anda kullanıcı sepetten istediğini çıkarabileceğini, içine kendisinin koymadığı bir şeyin girmeyeceğini ve kasaya gidene kadar hiçbir şeyin kesinleşmediğini varsayar. Ödeme adımında sepete otomatik eklenen bir sigorta, sizin tarafınızda tek satırlık bir karar, kullanıcı tarafında sözleşmenin bozulmasıdır.

Çöp kutusu da aynı kapıya çıkar. Çöp kutusu adını verdiğiniz yerden geri alma yoksa metafor yanlış vaatte bulunuyordur; o zaman ya geri almayı yazarsınız ya da o düğmeye sil dersiniz.

Uyumsuzluk çoğu zaman kodda başlar

Geri tuşu klasik örnek. Kullanıcı geri tuşuna bastığında bir önceki gördüğü ekranı bekler, uygulamanın kendi navigasyon mantığını değil. Tek sayfalık arayüzlerde bu beklenti genelde şu yüzden kırılır: modal, filtre paneli ya da sekme geçişi tarayıcının geçmişine hiçbir kayıt bırakmadan açılır. Kullanıcı geri tuşuna bastığında modal kapanmaz, sayfanın tamamı terk edilir. Çözüm de tasarım tarafında değil, iki satırlık bir yerdedir: modalı açarken geçmişe bir kayıt eklemek, geri sinyalini dinleyip modalı kapatmak.

İkinci örnek, aynı sayfada birden fazla arama kutusu. Biri site içi arama, diğeri tablo filtresi olduğunda kullanıcı ikisini ayırt etmek zorunda kalır, yanlış kutuya yazdığında da boş sonuç görür ve aradığı şeyin sitede olmadığına karar verir. Kutulardan birini kaldırmak çoğu zaman doğru hamledir (ikisini birden anlaşılır kılmaya çalışan ekiplerin emeğini boşa giden emek sayıyorum).

Modeli test etmeden bilemezsiniz

Sesli düşünme testi burada işe yarar, ama en değerli kısmı genelde atlanır. Kullanıcıya tıkladıktan sonra ne düşündüğünü sormak, sonucu gördükten sonra üretilmiş bir açıklama verir. Asıl bilgi tıklamadan önce çıkar: şimdi buna bassan ne olur? Verilen cevapla ekranda olan arasındaki fark, uyumsuzluğun ölçüsüdür.

Beş kişiyle yapılan böyle bir tur, aynı yanlış tahminin üçünde birden tekrar ettiğini görmeye yeter. Tekrar eden tahmin tesadüf değildir, sizin arayüzünüzün öğrettiği bir şeydir.

Hangi tarafı değiştireceksiniz

Uyumsuzluğu gördükten sonra iki yol var: sistemi beklentiye uydurmak ya da kullanıcıya doğrusunu öğretmek. Bunlar eşit seçenekler gibi sunulur, değildir.

Beklenti ürününüzün dışından geliyorsa öğretmeye kalkışmayın, kaybedersiniz; geri tuşunun ne yaptığını kullanıcıya siz anlatamazsınız, orada değiştirilecek olan sistemdir. Beklenti ürününüzün içinden geliyorsa, yani kendi terimlerinizden ya da kendi akışınızdan doğuyorsa öğretmek gerçekten mümkün. Tek şartla: açıklama kullanım anında, o ekranda, o alanın yanında dursun. Yardım merkezine yazılmış doğru bir açıklamayı, o soruyu soran kullanıcıların küçük bir kısmı okur; geri kalanı tahmin etmeye devam eder.