Konu Başlıkları
Yükleniyor...

Intranet Portallarında Kullanıcı Deneyimini Ölçmek

Zorunlu Kullanıcı: Kurum İçi Portallarda Deneyim Ölçümü

Kurum içi bir portalın kullanıcısı, deneyimden memnun olmasa da her sabah oraya giriyor. İzin formu orada, bordro orada, duyuru orada. Bu tek fark, dışarıya açık bir ürün için geçerli olan ölçüm alışkanlıklarının çoğunu intranet tarafında işlevsiz bırakıyor.

Terk etme seçeneği olmayan kullanıcı

Açık web'de kötü bir arayüzün cezası hızlıdır: kullanıcı sekmeyi kapatır, oturum süresi düşer, dönüşüm düşer. Sinyal kendiliğinden gelir. Intranette bu döngü yok. Çalışan formu bulamazsa portalı terk etmez, bulana kadar dolaşır, bulamazsa yan masaya sorar.

Sonuç şu: giriş sayısı, oturum süresi ve sayfa görüntüleme intranet tarafında memnuniyet ölçmez. Hatta ters okunur. Uzayan oturum süresi, aradığını bulamayan bir kullanıcının izidir. Aynı kişinin bir görevi tamamlamak için gezdiği sayfa sayısı artıyorsa, bu ilgi değil sürtünmedir.

Portalın gerçek maliyeti de portalın içinde görünmüyor. İnsan kaynakları ekibine gelen “şu belge nerede” soruları, ekip sohbetlerinde paylaşılan doğrudan bağlantılar, birimlerin kendi arasında dolaştırdığı kopya dosyalar; bunların hepsi portalın bulunabilirlik sorununun dışarı taşmış hali. Ölçüme buradan başlamak, analitik panelinden başlamaktan daha çabuk sonuç veriyor.

Arama, portalın asıl arayüzü

Menü yapısı üzerinde günlerce tartışılır, oysa çalışanların çoğu belirli bir belgeyi aramak için gelir ve doğrudan arama kutusuna yönelir. Arama logu da nadir bulunan türden bir veri: kullanıcının kendi kelimeleriyle, kendi ihtiyacını yazdığı yer.

Bakılacak üç şey var ve üçü de mevcut altyapıda zaten kayıtlı:

  • Sonuçsuz sorgular: hangi kelime portalda karşılıksız kalıyor.
  • Arka arkaya düzeltilen sorgular: kullanıcı aynı ihtiyacı ikinci, üçüncü kez farklı kelimelerle yazıyorsa isimlendirme tutmuyor demektir.
  • Sonuç listesinden hiçbir bağlantıya tıklanmadan çıkılan aramalar.

Bir intranet projesinde arama loglarını ilk kez açtığımızda, en çok aranan terimin ana sayfada zaten bağlantısı duran bir form olduğunu görmüştük. Sorun bulunabilirlik değil, adlandırmaydı: form resmi adıyla duruyordu, insanlar günlük adıyla arıyordu. Eş anlamlı sözlüğü yazmak yarım gün sürdü.

Kişiselleştirmenin faturası kime çıkıyor

Rol tabanlı kişiselleştirme her intranet listesinde ilk sıralarda yer alıyor, ama tasarım kararının uygulamaya bedeli konuşulmuyor. Rol sayısı r, ayrı görünürlük kuralı olan içerik türü sayısı d ise, doğrulanması gereken durum sayısı kabaca r×d ile büyür. Sekiz rol ve on iki içerik türü doksan altı kombinasyon eder, ve bunların her biri bir yayın hatasında yanlış kişiye yanlış belgeyi gösterme ihtimali taşır.

Aynı listelerde bir tavsiye daha var: yayın yetkisini dağıt, her birim kendi içeriğini yayınlasın. İkisi bir arada uygulandığında test yükü sabit kalmıyor, çünkü kuralı bilmeyen kişi sayısı da artıyor. Dağıtık yayın modeli iyi bir fikir, fakat rol matrisi sadeleştirilmeden açılırsa portalın ilk ciddi güvenlik olayı içeriden ve kazayla çıkar.

Pratik çıkış yolu, rolü kişiselleştirmenin tek dayanağı yapmamak. Herkese aynı sayfayı gösterip sık kullanılanları kullanıcının kendisine seçtirmek, hem doğrulama yüzeyini küçültüyor hem de rol tanımı değiştiğinde bakım gerektirmiyor. Rol bazlı ayrım, gerçekten görülmemesi gereken içerikle sınırlı kalmalı.

Yumuşak göstergeler kaçış kapısına dönüşmesin

Intranet yatırımlarının getirisi anlatılırken çalışan memnuniyeti, işbirliği, bağlılık gibi başlıklar sıralanıyor. Bunlar gerçek etkiler, fakat hepsinin ortak özelliği yanlışlanamaz olmaları. Tamamı yumuşak göstergelerden oluşan bir başarı tanımıyla hiçbir portal başarısız sayılamaz.

Yanına sayılabilir en az bir ölçüt koymak gerekiyor, ve bunun karmaşık olması şart değil. Beş sekiz kişilik bir grupla yapılan görev tabanlı test, portalın en sık üç işini kaç kişinin kaç saniyede tamamladığını verir. Aynı testi altı ay sonra aynı görevlerle tekrarlayın: tamamlama oranı ve süre iki ölçüm arasında karşılaştırılabilir hale gelir. Görev listesini değiştirirseniz karşılaştırma da gider, o yüzden görevler sabit kalmalı.

Kurum içi bir portalda kullanıcı zaten geliyor. Ölçülecek şey onu getirip getiremediğiniz değil, geldiğinde aradığını bulup bulamadığı.