Bilgi Mimarisi Menü Tasarlamak Değildir

Bilgi mimarisi denince ilk yapılan şey genellikle sitemap açmaktır.

Ana sayfa. Ürünler. Ayarlar. Profil. Raporlar.

Sonra menü sadeleştirilir ve iş bitti sanılır.

Navigasyon bilgi mimarisinin bir parçasıdır. Kendisi değildir.

Ben bilgi mimarisini daha temel bir problem olarak görüyorum:

Kullanıcı sistemde neyin ne olduğunu, neyin neyle ilişkili olduğunu ve hangi bağlamda hangi bilgiyi kullanacağını nasıl anlıyor?

Önce entity, sonra menü

Bir ürünün ana entity’leri net değilse navigasyonu temizlemek kozmetiktir.

Örneğin Ordovia’da:

Görev nedir? Planlanan zaman nedir? Proje nedir? Ritüel nedir? Not nedir? Günlük bağlam nedir?

Bunların ilişkileri netleşmeden “Görevler” ve “Planlama” sekmelerinin yerini değiştirmek temel problemi çözmez.

Kullanıcı aynı şeyi iki ayrı yerde farklı anlamda görüyorsa bilgi mimarisi kırılmıştır.

Bookcrumb: kitap listesi değil, karar bağlamı

Bookcrumb kitap öneriyor gibi görünebilir.

Fakat ürünün asıl bilgi yapısı “kitaplar” değildir.

Reader Profile + Mood / Theme / Tempo + Reading History → Recommendation Context → Reading Route → Books / Notes / Memory

Burada bilgi mimarisi öneri modelinin kendisini anlaşılır hâle getirir.

Kullanıcıya tek tek her değişkeni dashboard olarak göstermek gerekmiyor. Fakat sistem bu değişkenlerin rolünü bilmek zorunda.

İyi IA, backend modelini menüye aynen taşımak değildir.

Doğru context’i doğru karar noktasına taşımaktır.

Lumoria: bilgi fazlalığını karar akışına dönüştürmek

Seyahat planlamasında çok veri vardır:

Konum. İlgi. Süre. Yürüme tercihi. Hava. Mesafe. Açılış saatleri.

Bunların hepsini kullanıcıya ayrı filtre olarak verirseniz “güçlü” bir arayüz üretmiş olabilirsiniz.

Ama kullanıcı hâlâ şunu sorar:

“Bugün ne yapayım?”

Lumoria’daki önemli karar, origin’i şehir merkezi değil kullanıcının gerçekten kaldığı yer olarak context’in başlangıcı yapmak.

Sonra diğer sinyalleri tek rota kararına bağlamak.

Burada bilgi mimarisi sadece bilgiyi düzenlemez; karar üretme sırasını belirler.

IA’nın beş katmanı

Ben bir ürünü incelerken şu beş katmana bakarım.

1. Vocabulary Aynı kavram her yerde aynı isimle mi kullanılıyor?

2. Entity model Sistemde gerçekten hangi nesneler var?

3. Relationships Bu nesneler nasıl bağlı?

4. Context Kullanıcı hangi anda hangi ilişkiye ihtiyaç duyuyor?

5. Navigation / retrieval Bu bilgiye nasıl ulaşılıyor?

Takımlar çoğu zaman doğrudan beşinci katmandan başlıyor.

Sonra ilk dört katmanın belirsizliği menüye yansıyor.

Arama problemi bazen sınıflandırma problemidir

Kullanıcı aradığını bulamıyorsa refleks olarak arama geliştirilir.

Fuzzy search. Yeni filtre. Tag. Sort.

Bunlar bazen gereklidir.

Ama yanlış kategorize edilmiş veriyi daha güçlü search ile buldurmak problemi çözmek değildir.

Önce şunları sorarım:

• Kullanıcı neyi hangi isimle arıyor?
• Sistem aynı şeye ne diyor?
• Entity doğru yerde mi?
• Bir içerik birden fazla bağlama mı ait?
• Kullanıcı fiziksel konumu mu, semantik ilişkiyi mi hatırlıyor?
• Retrieval yolu ürünün domain modelini yansıtıyor mu?

Menü sade, sistem zengin olabilir

İyi IA’nın sonucu her zaman daha çok navigasyon değildir.

Çoğu zaman tam tersi.

Backend’de zengin ilişki ağı olabilir. Context engine çok sayıda sinyal kullanabilir. Domain modeli ayrıntılı olabilir.

Ama kullanıcı önünde yalnızca bir sonraki doğru karar görünür.

Bu nedenle “kullanıcıya her şeyi gösterelim, güçlü görünsün” yaklaşımına mesafeliyim.

Karmaşıklığı saklamak değil, doğru yerde çözmek gerekir.

Sonuç

Bilgi mimarisi menü tasarlamak değildir.

Bilginin:

• ne olduğunu,
• hangi isimle anıldığını,
• neyle ilişkili olduğunu,
• hangi bağlamda önemli olduğunu,
• nasıl geri çağrıldığını

tasarlamaktır.

Navigasyon bunun görünen yüzüdür.

Sistem yanlış sınıflandırılmışsa en temiz navbar bile ürünü anlaşılır yapamaz.