Bir acente yazılımına ilk kez giren kullanıcı, sol menüye ya da üst gezinme çubuğuna bakarak "nereden başlayacağım?" sorusuna cevap arar. Menünün nasıl gruplandığı, hangi başlıkların kullanıldığı ve hangi ekranın nerede durduğu, yazılımın ne kadar kolay öğrenileceğini belirler. Bu yapının arkasındaki disipline bilgi mimarisi denir.
Bilgi mimarisi, içerik ve işlevlerin kullanıcıların zihnindeki modele uygun biçimde düzenlenmesidir. Acente panelinde bu, müşteri, teklif, poliçe, tahsilat, görev ve rapor gibi alanların mantıklı bir hiyerarşiye yerleştirilmesi anlamına gelir.
Yaygın Hata: Menüyü Veritabanına Göre Kurmak
Yazılım ekipleri menüyü çoğu zaman sistemin teknik yapısına göre kurar: Her veritabanı tablosu bir menü öğesi olur. Kullanıcı ise sistemi tablolar üzerinden değil, işler üzerinden düşünür. Bir acente çalışanının aklındaki soru "poliçe tablosu nerede?" değil, "bu hafta yenilenecek poliçeler nerede?" sorusudur.
İyi bir bilgi mimarisi, kullanıcının yapmak istediği işten yola çıkar. Teknik yapı arka planda kalır; menü, günlük iş akışının bir yansıması olur.
Birinci Adım: İçerik ve İşlev Envanteri
Bilgi mimarisi çalışması, sistemdeki tüm ekranların, raporların ve işlemlerin listelenmesiyle başlar. Bu listede her öğe için şu bilgiler not edilir:
- Öğenin amacı ve hangi işi gördüğü,
- Hangi rollerin bu öğeyi kullandığı,
- Ne sıklıkla kullanıldığı,
- Hangi öğelerle birlikte kullanıldığı.
Bu envanter, menüde neyin üst seviyede, neyin alt seviyede durması gerektiğine dair ilk ipuçlarını verir. Her gün kullanılan bir ekranın üç tık derinlikte saklanması, ayda bir açılan bir ayarın ise ana menüde yer kaplaması envanterle hemen fark edilir.
İkinci Adım: Kullanıcıların Zihinsel Modelini Anlamak
Kullanıcıların içerikleri nasıl grupladığını öğrenmenin en bilinen yöntemi kart sıralama çalışmasıdır. Her ekran ya da işlev bir karta yazılır ve kullanıcılardan bu kartları kendilerine mantıklı gelen gruplara ayırması istenir. Açık kart sıralamada grup isimlerini kullanıcılar belirler; kapalı kart sıralamada ise önceden belirlenmiş gruplar kullanılır.
Acente ortamında bu çalışma şaşırtıcı bulgular ortaya çıkarabilir. Örneğin bazı kullanıcılar tahsilatı müşteri ile birlikte düşünürken, bazıları poliçe ile ilişkilendirir. Bu tür ayrışmalar, bir öğeye birden fazla yoldan erişim sağlanması gerektiğini gösterebilir.
Üçüncü Adım: Ana Grupları Belirlemek
Acente yazılımlarında sık karşılaşılan ana gruplar şu şekilde düşünülebilir:
- Günlük çalışma alanı: Bugünün görevleri, yaklaşan yenilemeler, bekleyen teklifler.
- Müşteriler: Müşteri listesi, müşteri kartı, iletişim geçmişi; CRM işlevlerinin merkezi.
- Teklifler: Trafik, kasko ve DASK gibi branşların her biri kendi sorgu akışıyla.
- Poliçeler: Aktif poliçeler, yenilemeler, belgeler.
- Finans: Tahsilatlar, komisyonlar, hesap hareketleri.
- Raporlar: Yönetim ve operasyon raporları.
- Yönetim: Kullanıcılar, roller, şubeler, entegrasyon ayarları.
Bu gruplar bir şablon değil, başlangıç noktasıdır. Her acentenin büyüklüğü ve çalışma biçimi farklı olduğundan gruplar kullanıcı araştırmasıyla doğrulanmalıdır.
Dördüncü Adım: Adlandırma
Menü başlıkları, kullanıcının kendi dilinden seçilmelidir. Yazılım ekibinin iç jargonu ya da İngilizce teknik terimler, kullanıcıyı tahmin yürütmeye zorlar. Başlıklar kısa, birbirinden açıkça ayrışan ve tek anlama gelen kelimeler olmalıdır. "İşlemler", "Diğer" ya da "Genel" gibi belirsiz başlıklar, zamanla her şeyin atıldığı bir çekmeceye dönüşür.
Derinlik ve Genişlik Dengesi
Menüde çok fazla üst seviye öğe olması taramayı zorlaştırır; çok fazla alt seviye ise kullanıcıyı tıklama zincirine sokar. Genel ilke, sık kullanılan öğeleri sığ, nadir kullanılanları daha derinde tutmaktır. Ayrıca tek bir alt öğesi olan menü grupları gereksiz bir katman oluşturur; bu tür gruplar birleştirilmelidir.
Menünün Ötesinde: Bağlamsal Gezinme
Bilgi mimarisi yalnızca ana menüden ibaret değildir. Kullanıcı bir müşteri kartındayken o müşterinin tekliflerine, poliçelerine ve tahsilatlarına aynı ekrandan ulaşabilmelidir. Bu bağlamsal geçişler, ana menüyü tekrar kullanma ihtiyacını azaltır ve kullanıcıyı işin akışı içinde tutar. Genel arama ise menüyü bilmeyen kullanıcılar için güvenli bir kısayol sağlar.
Rol Bazlı Görünüm
Bir şube çalışanı ile acente yöneticisinin ihtiyaç duyduğu menü öğeleri farklıdır. Yetkisi olmayan bir kullanıcıya erişemeyeceği menüleri göstermek kafa karışıklığı yaratır. Rol bazlı yetkilendirme yalnızca güvenlik değil, aynı zamanda sadelik aracıdır: Kullanıcı yalnızca kendi işiyle ilgili öğeleri görür.
Örnek: Yenileme İşinin Menüdeki Yeri
Yenileme takibi, bilgi mimarisi tartışmalarında sık karşılaşılan bir örnektir. Teknik açıdan yenileme bir poliçe özelliğidir ve poliçeler menüsünün altında durması mantıklı görünür. Ancak acente çalışanı için yenileme, sabah işe başladığında ilk baktığı iş listesinin bir parçasıdır. Bu durumda en işlevsel çözüm, yenilemeleri günlük çalışma alanında bir liste olarak göstermek, poliçe ekranında ise ilgili poliçenin yenileme durumunu belirtmektir. Aynı bilgi iki yerde görünür; ama her biri farklı bir kullanıcı sorusuna cevap verir.
Bu örnek, bilgi mimarisinin tek doğru bir yer bulmaktan çok, kullanıcının hangi bağlamda hangi soruyu sorduğunu anlamakla ilgili olduğunu gösterir. Menü ağacı çizilirken her öğe için "kullanıcı bu öğeyi hangi anda arıyor?" sorusunu sormak, yerleşim kararlarını kolaylaştırır.
Bir başka pratik ipucu da menü değişikliklerini kullanıcılara duyurmaktır. Bir öğe yeni bir gruba taşındığında, eski yerinde kısa bir süre yönlendirme notu bırakmak alışkanlıkların bozulmasından doğan kaybı azaltır.
Mimarinin Sürdürülebilirliği
Yazılım geliştikçe yeni ekranlar eklenir. Her yeni öğe için "bu nereye ait?" sorusu bilgi mimarisi ilkeleriyle cevaplanmazsa, menü zamanla dağınık bir yapıya dönüşür. Bu nedenle mimarinin belgelenmesi ve yeni öğelerin bu belgeye göre yerleştirilmesi önemlidir.
InsureHub'da acente yazılımının gezinme yapısını, acente çalışanlarının gerçek iş sıralamasına göre düzenliyoruz. Menü yapısını kendi ekibinizle birlikte denemek isterseniz demo talebi oluşturabilirsiniz.