Freelance Arayüz Tasarım Uzmanı ile Rol ve Yetki Ekranları

Rol ve yetki ekranı, bir kişiye hangi menülerin gösterileceğinden daha geniş bir tasarım problemidir. Kimin hangi kaydı görebileceği, hangi işlemi yapabileceği ve bir değişikliğin ne zaman geçerli olacağı birlikte tanımlanmalıdır. Arayüz bu kuralları anlaşılır kılar; güvenlik denetimini ise sunucu tarafındaki yetkilendirme uygulamalıdır. Bir düğmeyi gizlemek erişim kontrolü değildir.

Ekran çizmeden önce işlem matrisi hazırlayın

Varsayımsal bir teklif yönetimi ürününde üç rol düşünelim: satış çalışanı, ekip yöneticisi ve sistem yöneticisi. Bu örnek gerçek bir müşteri sonucu değildir. Rol adlarından hareketle herkesin yetkisini tahmin etmek yerine somut işlemleri listeleyin.

• Satış çalışanı kendi teklifini oluşturabilir ve taslak durumundayken düzenleyebilir.
• Ekip yöneticisi kendi ekibinin tekliflerini inceleyebilir; hangi işlemleri onaylayacağı ürün kuralıyla belirlenir.
• Sistem yöneticisi kullanıcı erişimini yönetebilir; bu rolün ticari onay yetkisi ayrıca kararlaştırılır.

Her kural için işlem, kayıt kapsamı ve koşul yazın. “Teklif düzenleyebilir” ifadesi eksiktir: tüm teklifleri mi, kendi kayıtlarını mı, yalnız taslakları mı? Yetki matrisi bu belirsizliği ekran tasarımından önce görünür hale getirir.

Rol, kayıt kapsamı ve durum birbirinden ayrı kararlardır

Aynı rol farklı ekiplerde farklı kayıtları görebilir. Ayrıca kullanıcının düzenleme yetkisi olsa bile tamamlanmış bir kaydın değiştirilmesi yasak olabilir. Bu durumları tek bir “yetkiniz yok” mesajında birleştirmek, sorunun kaynağını gizler.

Örneğin “Bu teklif onaylandığı için düzenlenemiyor” mesajıyla “Bu ekibin tekliflerine erişiminiz yok” mesajı farklı sonraki adımlar doğurur. İlkinde yeni sürüm oluşturma yolu bulunabilir; ikincisinde erişim talebi gerekebilir. Hangi bilgilerin gösterilebileceğini güvenlik ve ürün sorumlularıyla belirleyin. Kullanıcının erişemediği gizli kaydın varlığını hata mesajıyla açıklamak da istenmeyebilir.

Gizlemek mi, devre dışı bırakmak mı?

Kullanıcının işiyle ilgisiz bir yönetim aracını göstermemek ekranı sadeleştirebilir. Buna karşılık kullanıcının normalde yapabildiği, fakat mevcut durumda tamamlayamadığı işlem açıklamayla devre dışı bırakılabilir. Burada tek bir evrensel kural yoktur; kullanıcı görevi ve bilgi güvenliği birlikte değerlendirilir.

Devre dışı düğmenin nedenini yalnız fareyle görünen bir açıklamaya bırakmayın. Klavyeyle ve dokunmatik cihazla da anlaşılabilen bir durum metni sağlayın. Kullanıcı bir onay bekliyorsa kimden yanıt beklediğini ve işlemin hangi aşamada olduğunu, paylaşılması uygun bilgilerle açıklayın.

Rol değiştirirken sonucu önceden gösterin

Bir yöneticinin başka bir kişinin rolünü değiştirdiğini düşünün. Onay ekranı yalnız “Emin misiniz?” demek yerine hangi erişimlerin ekleneceğini veya kaldırılacağını açıklamalıdır. Etkinin hemen mi, yeniden girişte mi oluşacağı ürünün teknik davranışına göre belirtilmelidir.

Toplu değişiklikte seçili kişi sayısını ve kapsamı gösterin. İşlem bazı kullanıcılar için başarısız olursa hepsine başarılı mesajı vermeyin. Başarılı ve başarısız kayıtları ayırın; yeniden denemenin ne yapacağı açık olsun. Son yönetici hesabının yetkisini kaldırma gibi kritik durumlar için ürün kuralları ayrıca tanımlanmalıdır.

Tasarım dosyasında yalnız başarılı durumu teslim etmeyin

Geliştiriciye aktarılacak ekran listesi en az şu durumları değerlendirmelidir:

• Yetkili kullanıcı ve başarıyla yüklenen kayıtlar.
• Henüz kullanıcı eklenmemiş boş liste.
• Yetki değişikliği devam ederken bekleme durumu.
• Sunucunun işlemi reddetmesi veya oturumun sona ermesi.
• Kısmen tamamlanan toplu işlem.
• Kullanıcı ekran açıkken erişiminin başka bir yönetici tarafından değiştirilmesi.

Her durumda gösterilecek metni, kullanılabilir işlemleri ve kullanıcının geri dönebileceği yolu belirtin. Örneğin eski yetkiyle açık kalmış bir form kaydedilirken sunucu talebi reddedebilir. Arayüz bunu açıklamalı ve girilen verinin korunup korunmadığını dürüstçe göstermelidir.

Kontrolü rol adıyla değil görevle yapın

“Satış rolü çalışıyor mu?” yerine “Satış çalışanı başka ekibin teklifini düzenlemeye çalıştığında ne oluyor?” gibi somut senaryolar kullanın. Tasarım değerlendirmesi, sunucu yetkilendirme testlerinin yerine geçmez; ikisi aynı kurallara dayanmalıdır.

Selçuk Aker ile UI/UX tasarım çalışması planlarken rol listesinin yanında işlem ve kayıt kapsamlarını da paylaşabilirsiniz. Böylece ekran sayısı konuşulmadan önce durumlar ve teslim beklentileri belirlenebilir.