Tüketici ürünlerinde kötü deneyimin sonucu bellidir: kullanıcı uygulamayı siler. Kurum içi yazılımda böyle bir çıkış yoktur. Çalışan aynı ekranı her gün açar, aynı fazladan adımı her gün atar ve bir süre sonra kendi yöntemini geliştirir: bir Excel dosyası, bir not defteri, bir meslektaşa atılan mesaj.
Bu yüzden kurum içi yazılımda tasarım kararlarını memnuniyet üzerinden değil, işin akışı üzerinden değerlendirmek gerekir. Aşağıdaki sekiz başlık, bu kararların operasyona nerede dokunduğunu anlatıyor.
1. Karmaşık görevlerin adımlara ayrılması #
İş yazılımlarındaki karmaşıklık ekran sayısından değil; roller, izinler, veriler ve istisnaların aynı sistemde buluşmasından kaynaklanır. Uzun bir işlemi tek bir ekrana yığmak, kullanıcıdan hepsini aynı anda düşünmesini ister.
Görevi adımlara ayırmak, her adımda tek bir karar istemek ve kullanıcının nerede olduğunu göstermek hatayı ve yarıda bırakılan işleri azaltmaya yardım eder. Ayrım, veritabanının yapısına göre değil, işin gerçek sırasına göre yapılmalıdır. Sık yapılan basit işlerde ise tersi geçerlidir: adım sayısı artırılmaz, kısa yol sunulur.
2. Bilgiye ulaşma süresi #
Bir çalışanın gününün bir kısmı iş yapmakla değil, işi yapmak için gereken bilgiyi aramakla geçer: bir kaydın durumu, bir belgenin son hâli, bir kişinin iletişim bilgisi.
Navigasyonu kurumun organizasyon şemasına göre değil, çalışanların gün içinde yaptığı işlere göre kurmak bu süreyi belirler. Domino's için tasarladığımız Mahalle intranetinde çok sayıda içerik ve fonksiyonu önce analiz edip benzer ihtiyaçlara göre grupladık; navigasyonu çalışanların görevlerine ve karar anlarına göre tasarladık.
3. Arama ve filtreleme #
Veri büyüdükçe menü yetmez, kullanıcı aramaya ve filtrelere dayanır. İyi bir arama yazım hatasını tolere eder, sonuçları türüne göre ayırır ve son aramaları hatırlar. İyi bir filtre uygulanan ölçütleri görünür tutar, tek hamlede temizlenir ve sık kullanılan birleşimler kaydedilebilir.
Kullanıcı aynı filtreyi her sabah yeniden kuruyorsa ya da listeyi dışa aktarıp başka bir araçta süzüyorsa bu, yazılımın eksik bıraktığı bir işi elle tamamladığını gösterir.
4. Rol bazlı ihtiyaçlar #
Aynı sistemi sahadaki çalışan, merkezdeki uzman ve yönetici farklı amaçlarla açar. Hepsine aynı ekranı göstermek, her birini ihtiyaç duymadığı bilgiyle uğraştırır.
Türk Kızılay'ın QRed platformunda çalışmaya mevcut işlevleri, kullanıcı rollerini ve birbirine bağlı operasyonları ayrıştırarak başladık; modülleri görev odaklı bir bilgi mimarisi altında yeniden düzenledik. Amaç, farklı kullanıcıların kendi görevlerine doğrudan ulaşabilmesiydi. Rol ayrımı yalnız yetki meselesi değildir; her rolün açılış ekranında neyi görmesi gerektiği de bir tasarım kararıdır.
5. Hata önleme #
Kurum içi yazılımda bir hata, yanlış bir kayıt, yanlış bir ödeme ya da yanlış bir sevkiyat demektir ve düzeltmesi çoğu zaman başka birinin zamanını alır. Hatayı sonradan bildirmek yerine baştan zorlaştırmak gerekir.
- Geçersiz veri, alan biçimi ve seçim listeleriyle girişte engellenir.
- Geniş etkili işlemlerde etkilenecek kayıt sayısı gösterilir ve onay istenir.
- Mümkün olan her yerde geri alma sunulur.
- Hata mesajı ne olduğunu ve nasıl düzeltileceğini söyler.
6. Veri yoğun ekranlar #
Tablolar, göstergeler ve raporlar iş yazılımının doğal parçasıdır. Sorun verinin çokluğu değil, önceliğin belirsizliğidir. Kullanıcının ekrana hangi kararı vermek için geldiği belirlenir, veri o karara göre sıralanır ve ayrıntı ihtiyaç duyulduğunda açılır.
Mobilde bu daha da belirleyicidir. SunExpress uçuş ekipleri için tasarladığımız Crew Connect'te kişisel ana ekranda görev ve uçuş bilgilerini öne çıkardık, ayrıntılı bilgiyi ilgili ekranlarla ilişkilendirerek mobilde okunabilir bir düzene taşıdık. Tablolar, aşamalı gösterim ve durum tasarımı konusunu veri yoğun arayüzler yazısında ayrıca ele aldık.
7. Eğitim ihtiyacının azaltılması #
Bir yazılımın kullanılabilmesi için uzun bir eğitim ve kalın bir kılavuz gerekiyorsa bunun bir kısmı tasarımın yapması gereken işin kullanıcıya devredildiğini gösterir. Tutarlı kalıplar, açık etiketler ve yerinde verilen kısa açıklamalar öğrenmeyi ürünün içine taşır.
Tutarlılık burada belirleyicidir. Bir modülde öğrenilen ilerleme biçimi diğer modülde de geçerliyse kullanıcı yeni bir modülü kendi başına çözer. Esas App yazısında birbirinden farklı modülleri ortak bir gezinme düzeninde nasıl buluşturduğumuzu anlattık.
8. Tasarım kararlarının operasyon akışına etkisi #
Bir onay ekranındaki alan sırası, onayın ne kadar çabuk verildiğini etkiler. Bir listenin varsayılan sıralaması, hangi işin önce ele alındığını belirler. Bir bildirimin kime gittiği, işin kimde beklediğini değiştirir. Bunlar arayüz ayrıntısı gibi görünür ama her biri bir iş kuralıdır.
Bu yüzden kurum içi yazılımda tasarım, yazılım ve operasyon kararları ayrı ayrı verilemez. Ekranı tasarlayan kişi işin nasıl yürüdüğünü, işi yürüten kişi de ekranın neyi mümkün kıldığını bilmelidir.
Etki nasıl ölçülür #
Bu yazıda bilerek "şu kadar hızlandı" türünden bir rakam vermedik. Böyle bir rakam ancak önce bugünkü durum ölçülmüşse anlamlıdır. Yenilemeden önce birkaç kritik görev için başlangıç değerleri alınmalıdır: görevin tamamlanma süresi, hata ve düzeltme sayısı, destek talepleri, yazılımın dışında yürütülen geçici çözümler.
Aynı ölçümler yayından sonra tekrarlandığında iyileşme iddia olmaktan çıkar. Ölçüm kurulmamış bir üründe ilk iş çoğu zaman budur. Kurum içi yazılımları kullanıcı deneyimi, teknik mimari ve geliştirme ile birlikte SaaS ve iş yazılımları hizmetimiz kapsamında ele alıyoruz. Yayındaki bir yazılımın nerede zorlandığını görmek için Dijital Deneyim Denetimi uygun bir başlangıçtır.
