Mobil Uygulama Tasarımı Çok Rollü Kurumsal Onay Süreçleri İçin Nasıl Kurgulanır?

Çok rollü tasarımda rol matrisi nasıl oluşturulmalı?

Rol matrisi, yalnızca organizasyon şemasındaki unvanları listeleyerek değil; her kullanıcının hangi kaydı başlatabildiğini, hangi bilgiyi görebildiğini, hangi kararı verebildiğini ve hangi istisnada devreye girdiğini tanımlayarak oluşturulmalıdır. Tasarım kapsamındaki rol sayısı, ekran varyasyonlarını ve test edilecek senaryoları doğrudan etkiler. Aynı “yönetici” unvanı farklı departmanlarda farklı limitlere sahipse bunları tek rol kabul etmek, onay akışındaki gerçek farklılıkları gizleyebilir.

Rol sayısı iş davranışına göre belirlenmelidir

Keşif sırasında süreç sahibi, IT ekibi ve ilgili iş birimleri birlikte çalışarak gerçek kullanıcı davranışlarını çıkarır. Talep açan çalışan, ilk kontrolü yapan yönetici, son onayı veren yetkili, vekil kullanıcı ve yalnızca görüntüleme hakkı olan kişi ayrı davranış setleriyle ele alınmalıdır. Tasarım teklifinde de yalnız kişi sayısı değil, her rolün kaç temel senaryoda yer aldığı açıkça yazılmalıdır. Böylece “kaç kullanıcı rolü ve onay senaryosu ele alınacak?” sorusu ölçülebilir bir kapsam maddesine dönüşür.

• Talep oluşturan ve düzenleyen kullanıcı rolleri
• Kontrol eden ve düzeltme isteyen yöneticiler
• Nihai onay veya ret yetkisine sahip roller
• Belirli süreyle vekâlet alan kullanıcılar
• Yalnız izleme veya raporlama erişimi olan roller

İyi tasarım, mümkün olduğunca az tasarımdır. - Dieter Rams

Rol bazlı mobil ekranlarda bilgi mimarisi nasıl kurulmalı?

Rol bazlı mobil ekranlarda bilgi mimarisi, herkese aynı içeriği gösterip yalnızca birkaç butonu gizlemek yerine kullanıcının o anda vermesi gereken karara göre kurulmalıdır. Çalışan için talebin durumu, eksik belge ve sonraki adım öne çıkarken yönetici için karar özeti, gerekçe, risk veya bağlı kayıtlar daha önemli olabilir. Son onay yetkilisi ise geçmiş kararları ve kritik istisnaları daha üst seviyede görmelidir.

Aynı kayıt farklı rollerde farklı öncelik taşımalıdır

Bilgi hiyerarşisi oluşturulurken mobil uygulama tasarımında UX yaklaşımı ile kurumun iş kuralları birlikte değerlendirilmelidir. Ortak veri modeli korunabilir; ancak alanların sırası, eylem butonları, açıklamalar ve hata mesajları role göre değişebilir. Böylece çalışan, yönetici ve onay yetkilisi aynı kayda baktığında gereksiz ayrıntılarla karşılaşmadan kendi görevini anlayabilir. Tasarım sistemi de bu farklılıkları ayrı ekranlar çoğaltmak yerine kontrollü bileşen varyasyonlarıyla yönetmelidir.

• Rolün karar vermesi için gereken temel özet
• Gösterilecek veya maskelenecek hassas alanlar
• Birincil ve ikincil eylemlerin öncelik sırası
• Bekleme nedenini açıklayan durum mesajları
• Geçmiş işlemleri anlaşılır biçimde sunan kayıt özeti

Kurumsal onay akışları hangi senaryoları kapsamalı?

Kurumsal onay akışları yalnızca talep oluşturma ve onaylama şeklindeki ideal yolu değil, kararın gerçekten değiştiği bütün temel senaryoları kapsamalıdır. Standart akış ile istisna akışları ayrı senaryolar olarak tanımlanmalı ve her birinin başlangıç, bekleme, karar ve kapanış durumları belirlenmelidir. Tek aşamalı onay, çok seviyeli sıralı onay, paralel kontrol, limite bağlı yönlendirme veya ek belgeye göre değişen süreçler bu kapsamın parçaları olabilir.

İş kuralları ekran sayısından önce modellenmelidir

Bu nedenle kurumsal uygulama tasarımının planlanması sırasında önce süreç haritası ve durum modeli oluşturmak daha sağlıklıdır. Örneğin belirli bir koşulda ikinci onaycı devreye giriyorsa veya lokasyona göre onay zinciri değişiyorsa, bu kural tasarım ve test kapsamını etkiler. Teklifleri yalnız ekran adedi üzerinden karşılaştırmak, kurallar arasındaki bu farkı görünmez bırakabilir. Daha doğru karşılaştırma; senaryo sayısını, istisna yoğunluğunu ve karar noktalarını birlikte incelemektir.

• Standart tek veya çok aşamalı onay yolları
• Eş zamanlı değerlendirme gerektiren paralel kontroller
• Limit veya koşula göre değişen yönlendirmeler
• Belge veya açıklama eksikliğinde bekleyen durumlar
• İptal, zaman aşımı ve yeniden değerlendirme senaryoları

Ret düzeltme ve vekâlet akışları nasıl prototiplenmeli?

Ret, düzeltme ve vekâlet işlemleri ayrı bir “istisna listesi” olarak bırakılmamalı; ana onay akışının gerçek parçaları olarak tıklanabilir prototip içinde gösterilmelidir. Ret gerekçesinin zorunlu olup olmadığı, düzeltme sonrasında kaydın hangi adıma döneceği, önceki onayların korunup korunmayacağı ve vekilin hangi tarihler arasında hangi işlemleri yapabileceği prototipte açıkça görülebilmelidir.

Prototip yalnız görünümü değil karar mantığını sınamalıdır

Düzeltme isteyen yönetici hangi alanı işaretleyebiliyor, çalışan yapılan talebi nerede görüyor, yeniden gönderimde eski yorumlar korunuyor mu ve vekâlet bittiğinde bekleyen işler kime dönüyor gibi sorular senaryo üzerinden test edilmelidir. Bunun için örnek kayıtlar ve gerçekçi durum geçişleri kullanmak, yalnız statik ekran incelemekten daha değerlidir. Böylece “ret, düzeltme ve vekâlet işlemleri nasıl prototiplenecek?” sorusunun yanıtı teklif içinde somut teslimlere bağlanır.

• Ret nedeni ve zorunlu açıklama davranışı
• Düzeltme sonrası geri dönüş veya devam noktası
• Yeniden gönderimde eski kararların görünürlüğü
• Vekâlet başlangıç ve bitiş koşulları
• Vekil değiştiğinde bekleyen kayıtların yönlendirilmesi

Yetki ve veri görünürlüğü mobil UX içinde nasıl çözülmeli?

Yetki ve veri görünürlüğü, yalnızca arka uç güvenlik kuralı olarak değil kullanıcı deneyiminin görünür bir parçası olarak tasarlanmalıdır. Kullanıcı hangi işlemi neden yapabildiğini veya yapamadığını, kritik bir eyleme basmadan önce anlayabilmelidir. Hassas alanların rol bazında gizlenmesi, düzenleme yetkisinin açıkça belirtilmesi ve yalnız yetkili kişilerin görebileceği karar geçmişinin sınırlandırılması bu yaklaşımın temelidir.

İşlem geçmişi rolün ihtiyacı kadar ayrıntı göstermelidir

kurumsal mobil uygulamalardaki özellik ve entegrasyon gereksinimleri değerlendirilirken yetki modeli de veri kaynaklarıyla birlikte düşünülmelidir. ERP, CRM, insan kaynakları veya belge sisteminden gelen bir alan uygulamada görünüyorsa, hangi rolün bu bilgiyi okuyacağı ve değiştireceği tasarım dokümanında tanımlanmalıdır. Denetim izi ise arka uç loglarının kopyası olmamalı; mevcut kararı anlamaya yarayan, gerektiği kadar ayrıntılı ve rol bazında sınırlandırılmış bir geçmiş sunmalıdır.

• Yetki dışı işlemlerin önceden anlaşılır olması
• Hassas verilerin rol bazında gösterilmesi
• Kritik eylemlerde gerekçe veya ek doğrulama
• İşlem geçmişinin uygun ayrıntı seviyesinde sunulması
• Entegrasyon verileri için görüntüleme ve düzenleme ayrımı

Mobil bildirim kurallarını kim tanımlayıp onaylamalı?

Mobil bildirim kuralları tek başına UX ekibi veya yazılım ekibi tarafından belirlenmemelidir. Süreç sahibi iş açısından hangi olayların kritik olduğunu, IT ekibi teknik tetikleyici ve kanal koşullarını, UX ekibi ise mesajın kullanıcı davranışına etkisini tanımlamalıdır. Nihai kural setinin sahibi ve onaylayanı proje başında belirlenirse geliştirme sırasında “hangi durumda kime bildirim gidecek?” tartışmaları önemli ölçüde azalır.

Bildirimler iş kaydı ve eylem ihtiyacıyla ilişkilendirilmelidir

“Onay bekliyor”, “belge eksik”, “talep geri gönderildi”, “vekil atandı” veya “işlem süresi yaklaşıyor” gibi olaylar aynı önemde değildir. Her olay için hedef rol, kanal, öncelik, tekrar davranışı ve bildirime dokunulduğunda açılacak kayıt tanımlanmalıdır. Push bildirimi, uygulama içi bildirim kutusu ve kayıt detayındaki durum geçmişi birbirini tamamlamalıdır. Bu sayede mobil bildirim akışı tasarımı, rastgele mesaj üretmek yerine gerçek iş sorumluluklarını destekleyen bir kurala dönüşür.

• Bildirimi tetikleyecek iş olayı
• Mesajı alacak rol veya kullanıcı
• Kullanılacak kanal ve öncelik seviyesi
• Hatırlatma ve tekrar gönderim koşulları
• Bildirimin bağlanacağı uygulama içi kayıt

Rol bazlı ekranları hangi gerçek kullanıcılar test etmeli?

Rol bazlı ekranları, yalnızca proje yöneticileri veya süreç sahipleri değil, günlük işi gerçekten yapan temsilci kullanıcılar test etmelidir. Her kritik rol için farklı deneyim seviyelerinden katılımcılar seçmek; terminoloji, bilgi yoğunluğu, hata anındaki davranış ve karar verme biçimi hakkında daha güvenilir içgörü sağlar. Amaç istatistik üretmekten çok, prototipte tanımlanan iş kurallarının gerçek çalışma koşullarında anlaşılır olup olmadığını görmektir.

Test grubu rol çeşitliliğini ve kritik işleri temsil etmelidir

Talep açan çalışan, ilk kontrolü yapan yönetici ve nihai onay yetkilisi temel gruptur; ancak süreç finans, insan kaynakları, saha operasyonu veya başka bir uzman birime dokunuyorsa bu roller de teste dahil edilmelidir. Seyrek kullanan kişiler özellikle değerlidir, çünkü arayüzün sürekli kullanım alışkanlığı olmadan anlaşılır kalıp kalmadığını gösterir. Kurumsal UX araştırması, yalnız karar vericilerden görüş almak yerine gerçek kullanıcıların görevleri tamamlayabildiği senaryo testleriyle desteklenmelidir.

• Süreci sık kullanan operasyonel çalışanlar
• Farklı yetki seviyesindeki yöneticiler
• Nihai veya istisnai karar veren yetkililer
• Seyrek kullanım nedeniyle hata riski yüksek kişiler
• Entegrasyonlu adımlardan sorumlu iş birimi temsilcileri

Onay süreci prototipi hangi ayrıntıda hazırlanmalı?

Onay süreci prototipi, yalnız ana ekranlar arasında geçiş yapılan görsel bir sunum düzeyinde kalmamalı; satın alma kararını etkileyen iş kurallarını test edecek kadar ayrıntılı hazırlanmalıdır. Her kritik rol için başlangıç ekranı, bekleyen işler, kayıt detayı, karar eylemleri, hata ve boş durumları ile işlem sonrasındaki geri bildirim gösterilmelidir. Bununla birlikte gerçek yazılım geliştirmesini taklit edecek kadar gereksiz ayrıntıya girmek de kapsamı verimsizleştirebilir.

Prototip derinliği riskli karar noktalarına göre seçilmelidir

mobil uygulama geliştirme sürecinin planlanması ile tasarım prototipi arasındaki sınır açık tutulmalıdır. UX prototipi API davranışını kodlamaz; ancak kullanıcıya gösterilecek durumun, eylem koşulunun ve hata geri bildiriminin nasıl çalışacağını tarif eder. Özellikle ret, yeniden gönderim, yetki yetersizliği, bağlantı problemi, eksik belge ve vekâlet gibi riskli noktalar prototipte görünür olmalıdır. Teklifte hangi akışların yüksek doğrulukta hazırlanacağı ayrıca belirtilmelidir.

• Her kritik rol için temel başlangıç ekranları
• Bekleyen işler ve kayıt detayındaki karar noktaları
• Hata boş durum ve işlem sonrası geri bildirim
• İstisna akışlarının tıklanabilir senaryoları
• Yüksek doğrulukta test edilecek kritik ekran seti

Tasarım çıktıları geliştirme ekibine nasıl aktarılmalı?

Tasarım çıktıları geliştirme ekibine yalnızca yüksek doğrulukta ekran dosyaları olarak aktarılmamalıdır. Rol, durum, eylem, validasyon, bildirim ve istisna kuralları ekranlarla birlikte teslim edilmelidir. Geliştirici hangi koşulda hangi bileşenin görüneceğini, alanın ne zaman düzenlenebileceğini, işlem tamamlandığında hangi durumun oluşacağını ve hata halinde kullanıcıya ne gösterileceğini tasarım paketinden anlayabilmelidir.

Devir teslim tasarım sistemi ve davranış kurallarını birleştirir

Tasarım sistemi bileşenleri, varyasyonlar, boş ve hata durumları, rol matrisi, akış prototipleri ve temel kabul kriterleri aynı referans setine bağlanmalıdır. Responsive davranışlar, erişilebilirlik notları ve gerekli mikro etkileşim açıklamaları da kapsam dahilindeyse açıkça işaretlenmelidir. Böylece geliştirme ekibi görünümü tahmin etmek veya eksik iş kuralını yeniden yorumlamak zorunda kalmaz. “Tasarım çıktıları hangi ayrıntıda teslim edilecek?” sorusu da dosya formatından çok uygulanabilirlik düzeyi üzerinden cevaplanmış olur.

• Rol ve yetki matrisi ile durum tablosu
• Tıklanabilir akış ve ekran prototipleri
• Tasarım sistemi bileşenleri ve varyasyon kuralları
• Validasyon hata ve bildirim açıklamaları
• Geliştirici notları ve temel kabul kriterleri

Kurumsal mobil UX teklifinde hangi işler ayrı yazılmalı?

Kurumsal mobil UX teklifinde keşif, rol matrisi, süreç modelleme, prototip, kullanıcı testi, tasarım sistemi ve geliştirici aktarımı ayrı iş paketleri halinde yazılmalıdır. Bu ayrım, teklifleri yalnız toplam bedel üzerinden değil kapsam, sorumluluk ve teslim derinliği açısından karşılaştırmayı mümkün kılar. Çok rollü kurumsal mobil uygulama tasarımı için iş kuralı sayısı, istisna yoğunluğu, kullanıcı testinin kapsamı ve entegrasyon bağımlılıkları teklifin gerçek içeriğini belirleyen başlıca unsurlardır.

Teklif karşılaştırması mevcut onay akışı üzerinden yapılmalıdır

uygulama tasarımı tekliflerini karşılaştırma yaklaşımı burada doğrudan uygulanabilir. Kurum, mevcut onay akışını, kullanıcı rollerini, bilinen istisnaları ve varsa örnek ekranları sağlayıcılarla paylaşmalıdır. Sağlayıcı ise hangi görüşmeleri yapacağını, kaç rol ve senaryoyu prototipleyeceğini, hangi gerçek kullanıcıların teste katılacağını, bildirim kurallarının kim tarafından onaylanacağını ve geliştiriciye hangi ayrıntıda teslim yapacağını teklif içinde netleştirmelidir. Böylece kurumsal uygulama UX projesi ölçülebilir teslimlerle satın alınabilir.

• Keşif görüşmeleri ve mevcut süreç analizi
• Rol matrisi ve uçtan uca akış modelleme
• İstisna senaryoları ve tıklanabilir prototipler
• Gerçek kullanıcı testleri ve revizyon kapsamı
• Tasarım sistemi ve geliştirici devir teslim paketi