Bilgi Mimarisi Hataları: Görev Başarısı Neden Düşer, Nasıl Ölçülür
Bir kullanıcı aradığı sayfaya ulaşamadığında ilk şüpheli genelde arayüz olur: menü kalabalık, arama kutusu küçük. Oysa hata çoğu zaman bir seviye daha derinde, içeriğin hangi kategoriye konduğu ve o kategoriye ne isim verildiği kararındadır. İki karar da tasarımdan önce verilir, yanlış verildiğinde de hiçbir arayüz rötuşu onları kurtarmaz.
Bulunamayan içerik ile yanlış adlandırılmış içerik aynı hata değil
Görev başarısızlığını ikiye ayırmadan ilerlemek zor. Birinci durumda kullanıcının aradığı sayfa sitede yoktur. İkinci durumda sayfa vardır, mantıklı bir yerdedir, ama adı kullanıcının kafasındaki kelimeyle örtüşmez. “Abonelik iptali” arayan birinin karşısına “Hesap Yönetimi” çıkıyorsa içerik kayıp değil, etiket yanlış.
Bu ayrım ölçüm biçimini de değiştirir. Eksik içeriği bir içerik envanteri çıkararak görürsün: hangi sorulara karşılık gelen sayfa yok, listede boşluk olarak durur. Adlandırma sorununu ise ancak kullanıcının kendi kelimelerini toplayınca görürsün. Kart gruplama seansı, destek kayıtları ve site içi arama sorguları bunun için var.
Başarı oranı yükseldi, bilgi mimarisinin payı yükseldi
Bu konuda dolaşan sayı seti 2000’lerin ortasına ait ve kaynağı çoğu yerde verilmez: görev başarı oranı 2004’te %66, 2009’da %81; aynı aralıkta bilgi mimarisi kaynaklı başarısızlık %14’ten %10’a inmiş. Rakamları olduğu gibi yutmak yerine aralarındaki orana bakmak daha öğretici.
2004’te toplam başarısızlık 34 puan, bunun 14 puanı IA kaynaklı: yüzde 41. 2009’da toplam başarısızlık 19 puana düşmüş, IA payı 10 puan: yüzde 53. Yani bilgi mimarisi hataları mutlak olarak azalırken, geride kalan başarısızlıkların çoğunluğu haline gelmiş. Kolay kazanımlar toplandıkça (buton boyutu, form doğrulama, sayfa hızı) geriye en inatçı katman kalıyor, o da içeriğin nasıl bölündüğü.
Hatanın yerini bulmanın üç yolu
Ağaç testi en doğrudan olanı. Kullanıcıya arayüz değil, sadece kategori ağacı gösterilir ve bir görev verilir; çıktı, hangi dalda yanlış döndüğünü kategori kategori söyler. Arayüz devre dışı olduğu için sonucu renk, boşluk ya da ikon seçimi bulandırmaz.
İkincisi ilk tık testi. Önemli olan ilk tıkın doğru olup olmadığı, çünkü ilk tıkı yanlış olan kullanıcı nadiren toparlıyor: ağacın başka bir dalını denemek yerine aramaya ya da çıkışa yöneliyor. Üçüncüsü bedava ve en çok atlanan: site içi arama logu. Sıfır sonuç dönen sorguları frekansa göre sıraladığında, menüde olmayan ama herkesin aradığı şeyin listesini elde edersin. Bir e-ticaret projesinde bu listeyi ilk kez açtığımda en üstteki iki satır “kargo takip” ve “fatura” idi; ikisi de sitede vardı, ikisi de menüde yoktu.
Ağacı değiştirmenin faturası
Kategori ağacını yeniden kurmak bir tasarım kararı gibi görünür, uygulamada ise adres kararıdır. Kategori yolu URL’de geçiyorsa her taşıma eski adresi kırar; arama motorundaki konumu ve dışarıdan gelen bağlantıları korumak için 301 yönlendirme tablosu gerekir. Bu yüzden ağaç değişikliğini küçük parçalara bölmek ve her parçanın yönlendirmesini aynı sürümde yazmak işe yarar. “Sonra toparlarız” denen yönlendirmeler toparlanmıyor.
Nerede durmalı
Görev başarısı tek başına yetersiz bir metrik: kullanıcıyı altı tık dolaştıran bir ağaç da sonunda %100 başarıya ulaşabilir. Ölçerken yanına tamamlama süresini ve ağaçta kaç kez geri dönüldüğünü koy. Ağaç testinde kullanıcıların büyük kısmı doğru dala ilk denemede giriyorsa, ağacı daha fazla oynatmanın getirisi hızla azalır; o noktada bütçeyi yapıdan içeriğin kendisine kaydırmak daha doğru.