Yönetim paneli tasarımı: Kullanıcının sonraki işi görünür olsun

Paneli açan çalışan ilk iş olarak başka bir dosyaya bakıyorsa, ana ekranın ne işe yaradığını sorgulamak gerekir. Toplam müşteri sayısı, renkli grafikler ve son giriş tarihi ekranda yer kaplayabilir; ancak bugün hangi talebin cevap beklediğini göstermeyebilir. Yönetim paneli tasarımı, işletmenin verisini sergilemek kadar kullanıcının bir sonraki işini bulmasını da sağlamalıdır. Güzel görünen bir özetle kullanılabilir bir çalışma alanı arasındaki fark çoğu zaman burada ortaya çıkar. Kullanıcı neye bakacağını ve ardından ne yapacağını anlayabilmelidir.

Bir servis işletmesinin taleplerini yönettiği varsayımsal bir panel düşünelim. Müşteri temsilcisi yeni başvuruları inceliyor, operasyon sorumlusu işi uygun kişiye atıyor, yönetici de bekleyen işleri izliyor. Aynı veri üç kişiye farklı kararlar için gerekiyor. Bu yazıdaki örnekler bir müşteri projesinin sonucu değil, tasarım kararlarını somutlaştıran kurgu senaryolardır. Amaç her panele aynı bileşenleri yerleştirmek değildir. İş akışını anlamak, bilgi sırasını bu akışa bağlamak ve gerçek kullanım koşullarında kontrol edilebilen bir arayüz hazırlamaktır.

Ana ekranı çizmeden önce günlük işi dinleyin

Kullanıcıya panelde hangi özellikleri istediğini sormak faydalıdır; gün içinde yaptığı işi izlemenin yerini tutmaz. Sabah nereden başlıyor, hangi bilgiyi kopyalıyor, hangi durumda bir meslektaşına soruyor? Örneğimizde temsilci, dün gelen ama henüz aranmayan başvuruları ayrı bir tabloda işaretliyor olabilir. Bu davranış panelde eksik bir görev görünümüne işaret eder. Yeni bir grafik istemek yerine, cevapsız başvuruları güvenilir biçimde ayıran bir liste daha yararlı olabilir. Tasarım önerisini gözlenen iş ihtiyacıyla ilişkilendirin.

Görüşmeyi somut bir kayıt üzerinden yürütün. “Şu talep geldiğinde ne yaptınız?” sorusu, genel alışkanlık anlatımından daha ayrıntılı cevap verir. İşin başladığı anı, kullanılan bilgiyi, kararı ve tamamlanma koşulunu kaydedin. Sık yapılan işlemle nadir ama kritik işlemi ayırın. İkisinin görünürlüğü aynı olmayabilir. Bu incelemeden kısa görev tanımları çıkarın: yeni talebi değerlendirmek, eksik bilgiyi istemek, uygun ekibe aktarmak gibi. Menü isimleri ve ana ekran düzeni bu görevlerin ardından şekillensin.

Özet kutularını karar verebildikleri ölçüde kullanın

Toplam binlerce kayıt bulunduğunu gösteren bir sayaç, tek başına bugün yapılacak işi açıklamaz. Bekleyen başvurular, gecikmiş geri dönüşler veya atama bekleyen işler daha doğrudan bir eylemle ilişkili olabilir. Her özet kutusu için şu soruyu sorun: Kullanıcı bu bilgiyi gördüğünde hangi kararı verecek? Cevap yoksa kutunun ana ekranda bulunması şart değildir. Bir değerin büyük görünmesi onu önemli yapmaz. Özellikle operasyon panelinde görsel hiyerarşiyi, işin önceliği ve kullanıcı rolü üzerinden kurun.

Kutudan ayrıntıya geçişi de tasarlayın. Bekleyen işler sayısına basıldığında aynı tanıma uyan filtrelenmiş liste açılmalıdır. Sayıyla liste arasında kapsam farkı varsa güven azalır. Örneğin özet yalnızca kullanıcının ekibini sayarken liste bütün şirketi gösteriyorsa bunu açıkça belirtin. Tarih aralığı ve yenilenme zamanı gerektiğinde görünür olsun. Eski veriye bakarak yeni bir görev kararı verilmesini önleyin. Paneldeki sayıların anlamı, kaynakları ve açtıkları görünüm birlikte tanımlandığında kullanıcı bilgiyi yeniden hesaplamak zorunda kalmaz.

Tabloda bütün alanları aynı anda göstermeyin

Bir talep kaydının yirmi alanı bulunabilir; liste ekranında yirmisinin de görünmesi gerekmez. Kullanıcının doğru kaydı tanıması ve sonraki adımı seçmesi için gereken alanları öne alın. Talep adı, durum, sorumlu, bekleme süresi ve son işlem gibi bilgiler örneğimiz için başlangıç olabilir. Kesin seçim kullanıcı görevine bağlıdır. Uzun notları, teknik kimlikleri ve nadiren kullanılan ayrıntıları ayrı bir kayıt görünümünde tutabilirsiniz. Böylece liste karar vermeye yardımcı olurken ayrıntıya erişim de korunur.

Sütun başlıklarının ekip içinde kullanılan dille anlaşılır olmasını sağlayın. “Aktif” veya “işlem” gibi geniş kelimeler farklı anlamlara gelebilir. Durumun neyi anlattığını ve kimin değiştirebileceğini açıklayın. Sıralama yapıldığında hangi yönün geçerli olduğu görünür olsun. Sayısal değerlerin birimleri, tarihlerin kapsamı ve boş hücrelerin anlamı belirsiz kalmasın. Görünümü kişiselleştirme gerekiyorsa önce varsayılan düzeni düzgün kurun. İlk girişte işe yaramayan bir tabloyu, kullanıcının sütun ayarlarıyla kendisinin tamir etmesini beklemeyin.

Arama ve filtreler kullanıcının bağlamını korusun

Temsilci bir müşteri adını biliyorsa arama yapmak isteyebilir; cevap bekleyen bütün talepleri görmek istiyorsa filtre gerekir. Bu iki ihtiyacı aynı davranış gibi tasarlamayın. Hangi alanların arandığını ve etkin filtreleri açıkça gösterin. Sonuç bulunamadığında kullanıcı sistemde hiç kayıt olmadığını mı, yoksa seçili koşullara uyan kayıt bulunmadığını mı anlayabilmeli. Filtreyi temizlemek kolay olsun. Bir kayıt ayrıntısına gidip geri döndüğünde önceki aramasını kaybetmesi, özellikle kalabalık listelerde tekrar eden iş yükü yaratır.

Kaydedilmiş görünümler günlük kullanımda değerli olabilir. “Bana atanan ve bugün cevap bekleyen” gibi bir görünüm, aynı filtreleri her sabah kurma ihtiyacını azaltabilir. Bununla birlikte görünümün kapsamını açık tutun: tarih bugünle birlikte ilerliyor mu, belirli bir tarihte mi sabit? Kullanıcı başka bir ekibe geçtiğinde filtre hâlâ geçerli mi? Varsayılan seçimin hangi kayıtları dışarıda bıraktığını gösterin. İşlem yapılacak kayıt grubunun görünmez bir filtre yüzünden yanlış anlaşılması tasarımın çözmesi gereken bir sorundur.

İşlem adları sonuçları anlatsın

“Tamam” düğmesi bazen pencereyi kapatır, bazen kaydı kaydeder, bazen işi bitirir. Aynı panelde bu üç anlamın birbirine karışması hataya davet çıkarır. İşlem etiketini mümkün olduğunca sonuç üzerinden yazın: görevi ata, değişiklikleri kaydet, talebi arşivle gibi. Birincil işlemi görünür kılın; her düğmeyi aynı renkte ve ağırlıkta sunmayın. Kritik bir işlemin yanlışlıkla yapılmasını önlemek için yerleşimi ve açıklamayı birlikte düşünün. Onay penceresi, belirsiz bir düğme adının sürekli kullanılan yaması olmamalıdır.

Toplu işlemlerde seçimin sınırı özellikle önemlidir. Kullanıcı görünen sayfadaki kayıtları mı, filtreye uyan bütün kayıtları mı seçti? İşlemden önce bunu yazıyla açıklayın. On iki kaydı arşivlediğini sanan kişinin binlerce kaydı etkilemesini yalnızca renk uyarısına bırakmayın. Geri alınabilir işlemle kalıcı etkiyi ayırın. İşlem tamamlandığında kaç kaydın değiştiğini ve varsa hangi kayıtların neden değişmediğini bildirin. Başarısız satırları sessizce atlamak, kullanıcının işi bitirdiğini zannetmesine yol açabilir.

Kaydetme, hata ve eşzamanlı değişiklik durumlarını tasarlayın

Form yalnızca boş ve dolu hâllerden oluşmaz. Kaydedilirken, bağlantı kesildiğinde, zorunlu bilgi eksikken ve başka bir çalışan aynı kaydı değiştirdiğinde farklı durumlar yaşanır. Kullanıcı gönderdiği bilginin alınıp alınmadığını anlayabilmelidir. Hata mesajı hangi alanın nasıl düzeltileceğini söylesin ve girilmiş doğru bilgileri gereksiz yere silmesin. Sürekli yeniden deneme düğmesine basmak mükerrer kayıt oluşturuyorsa arayüzün yanı sıra işlemin teknik davranışı da ele alınmalıdır. Tasarım ve yazılımın sınırını burada birlikte konuşun.

İki kişinin aynı talebi düzenlediği senaryoyu özellikle deneyin. Bir temsilci telefon notunu güncellerken operasyon sorumlusu atamayı değiştirmiş olabilir. Sistem son kaydedenin bütün eski veriyi ezmesine izin veriyorsa, iyi görünen bir form bilgi kaybını gizler. Çakışma olduğunda kullanıcıya hangi bilginin güncellendiğini ve ne yapabileceğini anlatın. Seçilecek teknik yöntem uygulamaya göre değişebilir. Tasarımın görevi, kayıt sonucunun güvenilir ve anlaşılır olmasını istemek; testin görevi de bu beklentiyi gerçek senaryoda doğrulamaktır.

Rollere göre görünürlükle gerçek yetkiyi karıştırmayın

Temsilciyle yönetici aynı başlangıç ekranını görmek zorunda değildir. Temsilci kendi bekleyen işlerine, yönetici ekibin iş yüküne odaklanabilir. Fakat bir düğmeyi gizlemek güvenli yetkilendirme sağlamaz. İzin kontrolü sunucuda da uygulanmalıdır. Tasarım çalışmasında hangi rolün hangi bilgiyi görüp hangi işlemi yapabileceğini bir görev tablosuna yazın. “Yönetici her şeyi yapar” varsayımı yerine kritik eylemleri tek tek değerlendirin. Gereksiz kişisel veri görünürlüğünü azaltmak da bu incelemenin parçasıdır.

Yetkisi olmayan kişinin karşılaştığı durumu da planlayın. Bir bağlantıyla açtığı kayıt artık ekibinin kapsamında değilse, boş bir ekran yerine anlaşılır bir sonuç görmelidir. Bazı durumlarda erişim talebi yolu gösterilebilir; bazı kayıtların varlığını açıklamak bile uygun olmayabilir. Kararı işletmenin veri düzeni ve sorumlularıyla birlikte verin. Kullanıcı arayüzünde yardımcı olmak ile hassas bilgi açıklamak arasındaki dengeyi, uygulamanın gerçek erişim kurallarını bilmeden kuramazsınız. Tasarım onayına yetki senaryolarını da dahil edin.

Mobil kullanım ve erişilebilirlik için gerçek görev deneyin

Masaüstündeki tabloyu telefona küçültmek, sahada çalışan bir kişinin işini çözmeyebilir. Kullanıcı telefonda yalnızca kendine atanmış işi açıyor ve durum bildiriyor olabilir. Bu görev için daha sade bir görünüm tasarlanabilir. Buna karşılık karşılaştırma gerektiren yoğun tabloyu kartlara dönüştürürken bilgi ilişkilerini kaybetmemeye dikkat edin. Hangi alanların saklandığı ve ayrıntıya nasıl ulaşıldığı anlaşılır olsun. Cihaz seçimini tahmin etmek yerine, hangi işin nerede yapıldığını kullanıcı görüşmesiyle belirleyin ve örnek görevle sınayın.

Klavye ile ilerleme, görünür odak, anlaşılır alan etiketleri ve renge bağımlı olmayan durum bilgisi de çalışma panelinin temel parçalarıdır. Sadece fareyle yapılan başarılı bir gösterim yeterli değildir. Örnek talebi klavyeyle bulun, açın, değiştirin ve kaydedin. Yakınlaştırılmış ekranda işlem düğmeleri ulaşılabilir mi? Hata sonrasında odak anlamlı bir yerde mi? BiKreatif’in özel yazılım projeleri çalışmasında bu görevleri tasarım, geliştirme ve kabul koşullarıyla birlikte planlamak, panelin günlük kullanımını değerlendirmeyi kolaylaştırır.

Sık sorulan sorular

Yönetim panelinde mutlaka grafik bulunmalı mı?

Hayır. Grafik, bir karşılaştırmayı veya eğilimi anlamaya yardımcı olduğunda değerlidir. Kullanıcının işi bekleyen başvuruları sırayla cevaplamaksa öncelikli bir liste daha faydalı olabilir. Her bileşenin hangi kararı desteklediğini açıklayın. Görsel çeşitlilik uğruna eklenen grafikler, asıl görevin bulunmasını zorlaştırabilir ve ana ekranı gereksiz yere kalabalıklaştırabilir.

Her rol için tamamen ayrı panel mi yapılmalı?

Her zaman gerekmez. Ortak bileşenler korunurken başlangıç görünümü ve izin verilen işlemler role göre düzenlenebilir. Kararı kullanıcı görevleri ve erişim kurallarıyla verin. Aynı veriyi farklı kararlar için kullanan kişiler aynı öncelik sırasına ihtiyaç duymayabilir. Bununla birlikte görünüm değişikliği, sunucudaki yetki kontrolünün yerini tutmaz.

Tabloda kaç sütun olmalı?

Her uygulama için geçerli tek sayı yoktur. Kullanıcının kaydı tanıması, karşılaştırması ve işlem seçmesi için gereken alanları belirleyin. Daha az sütun her zaman daha anlaşılır demek değildir; önemli bağlamı gizleyebilirsiniz. Gerçek veri uzunlukları ve kullanılan cihazla deneyin. Ayrıntıya erişimi koruyarak günlük görevde gereksiz olan alanları geri plana alın.

Boş ekranlarda nasıl bir açıklama gösterilmeli?

Yeni hesapta henüz kayıt bulunmamasıyla filtre sonucunun boş olması farklı durumlardır. İlkinde başlangıç için uygun bir işlem gösterilebilir. İkincisinde etkin koşulları değiştirmek veya temizlemek yardımcı olabilir. Kullanıcının yanlışlıkla kayıtların silindiğini düşünmesini önleyin. Mesaj, neden boş olduğunu ve kişinin güvenle hangi adımı atabileceğini açıklamalıdır.

Panel tasarımının iyi olduğunu nasıl anlarız?

Temsilî kullanıcılarla gerçekçi görevler deneyin. Doğru kaydı bulabiliyorlar mı, işlemin sonucunu anlayabiliyorlar mı, hatadan dönebiliyorlar mı? Süreyi tek başarı ölçüsü yapmayın; yanlış işlem ve yardım ihtiyacını da gözleyin. Bulguyu belirli ekran ve göreve bağlayın. Sonraki tasarım değişikliğinin aynı sorunu çözüp çözmediğini yeniden kontrol edin.