Müştəri portalı UX dizaynı giriş səhifəsi və şəxsi kabinetdən daha geniş mövzudur. Yaxşı portal istifadəçinin roluna, təşkilati kontekstinə və yerinə yetirmək istədiyi işə uyğunlaşdırılmış əməliyyat mühitidir. Müştərinin sifariş və sənədləri izləməsi, əməkdaşın sorğunu emal etməsi, administratorun səlahiyyət və qaydaları idarə etməsi eyni məhsulun hissəsidir, lakin onların informasiyaya ehtiyacı, risk səviyyəsi və növbəti addımı fərqlidir.
Bu səbəbdən portalı “login olan vebsayt” kimi yox, rol, icazə, status və iş axınlarından ibarət məhsul kimi layihələndirmək lazımdır. POLADO-nun UI/UX və məhsul dizaynı xidməti məhz bu tip mürəkkəb interfeyslərdə informasiya arxitekturasını, əsas ssenariləri və vahid dizayn sistemini hazırlamağa yönəlir.
Portal dizaynına ekranlardan deyil, rol və işlərdən başlayın
“Müştəri”, “əməkdaş” və “administrator” çox geniş etiketlərdir. Dizayn üçün daha faydalı sual budur: istifadəçi hansı obyekt üzərində hansı hərəkəti, hansı məhdudiyyətlə yerinə yetirir?
- Müştəri istifadəçisi: hesabındakı sifarişin, müraciətin, müqavilənin və ya fakturanın vəziyyətini yoxlayır; sənəd yükləyir; əlavə məlumat verir; komandasını dəvət edir.
- Daxili əməkdaş: daxil olan sorğuları bölüşdürür, məlumatı yoxlayır, çatışmayan sənədi tələb edir, qərar hazırlayır və müştəri ilə yazışır.
- Administrator: təşkilatları, istifadəçiləri, rolları, konfiqurasiyanı, inteqrasiyaları və audit qeydlərini idarə edir.
Hər rol üçün “görə bilər”, “yarada bilər”, “redaktə edə bilər”, “təsdiqləyə bilər”, “ixrac edə bilər”, “idarə edə bilər” kimi icazələri ayrıca model edin. RBAC yanaşmasında istifadəçilər birbaşa pərakəndə icazələrə yox, səlahiyyətlər toplusu olan rollara bağlanır; bu, giriş hüquqlarının nəzərdən keçirilməsini və idarəsini sadələşdirir. Ən az səlahiyyət prinsipi isə rolun yalnız işini görmək üçün lazım olan imkanlara malik olmasını tələb edir. ([csrc.nist.gov](https://csrc.nist.gov/projects/role-based-access-control?utm_source=openai))
Rol matrisi hazırlayın
UX komandası və biznes sahibi ilkin mərhələdə sadə matris hazırlamalıdır: sətirlər obyektlərdir (sifariş, sənəd, müraciət, istifadəçi, ödəniş), sütunlar rollardır, xanalar isə icazələrdir. Lakin matris təkbaşına kifayət etmir. Hər icazə üçün kontekst də müəyyənləşdirin:
- İstifadəçi yalnız öz təşkilatının məlumatını görə bilərmi?
- Bir təşkilatda bir neçə təsdiq edən şəxs ola bilərmi?
- İki fərqli şəxsin təsdiqi tələb olunan əməliyyatlar varmı?
- İstifadəçi öz rolunu və ya öz girişini dəyişə bilərmi?
- Görünməyən məlumatın mövcudluğu belə məxfi sayılırmı?
Bu sualların cavabı həm backend icazə modelinə, həm də interfeysdə görünən menyu, düymə, filtr və bildirişlərə təsir edir. Vacib qayda: düyməni gizlətmək təhlükəsizlik nəzarəti deyil. Server tərəfi hər əməliyyat üçün səlahiyyəti yoxlamalı, interfeys isə istifadəçiyə nəyin mümkün olduğunu aydın göstərməlidir.
Rol əsaslı naviqasiya: menyu deyil, tapşırıq xəritəsi
B2B customer portal UX-da eyni sol menyunu hər kəsə göstərmək tez-tez qarışıqlıq yaradır. Müştəri “İstifadəçilərin idarəsi”, əməkdaş isə “Marketinq kampaniyaları” bölməsini görməyə ehtiyac duymaya bilər. Naviqasiyanı modul siyahısından yox, yüksək tezlikli tapşırıqlardan qurun.
Müştəri üçün əsas giriş nöqtələri adətən “Aktiv işlər”, “Sənədlər”, “Mesajlar”, “Fakturalar” və “Komanda” olur. Əməkdaş üçün “Növbəm”, “Təsdiq gözləyənlər”, “Riskli hallar”, “SLA yaxınlaşanlar” daha faydalıdır. Administrator üçün isə “İstifadəçilər və rollar”, “Konfiqurasiya”, “İnteqrasiyalar” və “Audit jurnalı” məntiqlidir.
İdarə paneli hər ölçünü bir ekrana yerləşdirmək cəhdi olmamalıdır. Əsas ekranda istifadəçinin bu gün qərar verməsi və ya hərəkət etməsi lazım olan məlumatı göstərin. Məsələn, müştəri üçün “2 sənəd imza gözləyir”, əməkdaş üçün “5 müraciət bu gün cavab tələb edir”, administrator üçün “3 istifadəçinin dəvəti vaxtı bitib” kimi vəziyyət kartları daha dəyərlidir.
Status, sənəd və təsdiq axınlarını görünən edin
Portal təcrübəsinin keyfiyyəti çox vaxt “status haradadır?” sualına cavabdan asılıdır. “Emal olunur” kimi ümumi etiket əvəzinə istifadəçi prosesin mərhələsini, son yenilənmə vaxtını, növbəti məsul şəxsi və özündən gözlənilən addımı görməlidir.
Məsələn, müqavilə təsdiqi üçün aşağıdakı məlumat faydalıdır:
- Hazırkı mərhələ: hüquqi yoxlama, maliyyə təsdiqi və ya müştəri imzası;
- Son hərəkət və tarixi;
- Növbəti hərəkəti etməli olan rol;
- Bloklayıcı səbəb və lazımi sənəd;
- Mümkünsə gözlənilən xidmət müddəti barədə aydın məlumat.
“Göndərildi” düyməsindən sonra istifadəçini boş səhifəyə qaytarmayın. Uğurlu vəziyyət ekranı müraciət nömrəsini, izləmə linkini, prosesin növbəti mərhələsini və lazım gəldikdə əlaqə kanalını göstərməlidir. Eyni prinsip rədd edilmiş, vaxtı keçmiş və ya əlavə məlumat tələb edən hallar üçün də keçərlidir. Sistem səhvini biznes qərarı ilə qarışdırmayın: “Fayl yüklənmədi” ilə “Sənəd təsdiqlənmədi” fərqli mesaj, fərqli bərpa addımı tələb edir.
Boş vəziyyətlər məhsul məntiqinin hissəsidir
Yeni müştərinin hələ sifarişi, sənədi və ya mesajı olmaya bilər. Sadəcə “Məlumat yoxdur” yazısı onu növbəti addımsız qoyur. Faydalı boş vəziyyət üç elementi cavablandırır: burada normalda nə görünəcək, niyə hələ görünmür və istifadəçi indi nə edə bilər. Məsələn: “Hələ aktiv müraciətiniz yoxdur. Yeni müraciət yaratmaq üçün…” Bu yanaşma xüsusilə ilk istifadə və rol dəyişimi zamanı vacibdir.
Təsdiq axınlarında sürət və nəzarəti balanslaşdırın
Admin dashboard UX təkcə cədvəl və filtr deyil. Administratorun hər qərarı risk yarada bilər: istifadəçini silmək, rolu yüksəltmək, ödəniş qaydasını dəyişmək və ya məlumat ixrac etmək geri dönməz nəticələrə malik ola bilər. Riskli hərəkətlər üçün təsdiq dialoqunda konkret təsiri yazın: “Bu istifadəçi təşkilatın bütün fakturalarını görə biləcək.” Qeyri-müəyyən “Əminsiniz?” mətnindən uzaq durun.
Təsdiq mexanizmi prosesin özündə də düşünülməlidir. Məbləğ, region, sənəd növü və ya risk səviyyəsinə görə fərqli marşrutlar yarana bilər. Dizayn bu qaydaları gizlətməməli, istifadəçiyə səbəb-nəticəni izah etməlidir. Eyni şəxsin həm sorğu yaratması, həm də yekun təsdiqi verməsi qadağandırsa, bu məhdudiyyət həm sistem səviyyəsində, həm də UX mətnində aydın olmalıdır.
Mobil davranışı əvvəlcədən müəyyən edin
Portalın “responsive” olması yalnız cədvəlin kiçilməsi demək deyil. Müştəri telefonda sənəd statusunu yoxlamaq və ya şəkil çəkməklə fayl əlavə etmək istəyə bilər; əməkdaş isə çoxsütunlu növbə idarəetməsini masaüstündə daha səmərəli yerinə yetirər. Buna görə hər tapşırıq üçün cihaz prioritetini müəyyən edin.
- Mobil üçün: status yoxlama, bildirişə keçid, sənəd yükləmə, qısa təsdiq və mesajlaşma.
- Masaüstü üçün: kütləvi əməliyyatlar, mürəkkəb filtr, uzun cədvəllər, müqayisə və konfiqurasiya.
- Hər iki mühit üçün: eyni status adları, eyni icazə məntiqi və davamlı istifadəçi konteksti.
Klaviatura ilə istifadə, görünən fokus, kifayət qədər toxunma hədəfləri, ardıcıl yardım və əlçatan giriş axını məhsulun keyfiyyət meyarları olmalıdır. WCAG 2.2 bu mövzularda fokusun görünməsi, minimum hədəf ölçüsü, ardıcıl yardım və əlçatan autentifikasiya kimi meyarları əhatə edir. ([w3.org](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/?utm_source=openai))
Bir dizayn sistemi iki interfeysi birləşdirir
Müştəri portalı və daxili əməliyyat paneli ayrı məhsul kimi görünə bilər, amma çox vaxt eyni sifariş, sənəd, status və istifadəçi obyektləri üzərində işləyir. Ayrı-ayrı komponentlər və terminlər qurulduqda uyğunsuzluq yaranır: müştəri “Yoxlanılır”, əməkdaş isə eyni mərhələni “Pending review” kimi görür.
Ortaq dizayn sistemi rəng, düymə və ikon kitabxanası ilə məhdudlaşmamalıdır. O, statusların lüğətini, cədvəl davranışını, sənəd kartlarını, formanın xəta qaydalarını, təsdiq dialoqlarını və bildiriş nümunələrini əhatə etməlidir. Bu, veb platformanın hazırlanması mərhələsində dizayn qərarlarının komponentlərə və tətbiq qaydalarına çevrilməsini asanlaşdırır; sonrakı dəyişikliklərdə isə texniki dəstək və konsaltinq prosesi daha idarəolunan edir.
İnkişafdan əvvəl UX discovery lazımdırmı?
Aşağıdakı suallardan bir neçəsinə “bəli” deyirsinizsə, ekran dizaynına keçməzdən əvvəl discovery mərhələsi məqsədəuyğundur:
- Eyni təşkilatda bir istifadəçi bir neçə rola sahib ola bilərmi?
- İcazələr prosesə, məbləğə və ya məlumat kateqoriyasına görə dəyişirmi?
- Müştəri və əməkdaş eyni işin fərqli hissəsini görürmü?
- Təsdiq, eskalasiya və geri qaytarma ssenariləri yazılı şəkildə müəyyən edilməyibmi?
- Sənədlər, audit izləri və status tarixçəsi biznes və ya tənzimləmə baxımından vacibdirmi?
- Mövcud portalda istifadəçilər tez-tez dəstəyə “haradan tapa bilərəm?” və ya “niyə edə bilmirəm?” sualı ilə müraciət edirmi?
Discovery nəticəsi sadəcə wireframe paketi olmamalıdır. Yaxşı nəticə rol matrisi, prioritet istifadəçi axınları, informasiya arxitekturası, məzmun və status modeli, səhv/boş vəziyyətlər, prototip və inkişaf üçün qəbul meyarlarını birləşdirir. Portal ideyanızı işlək, təhlükəsiz və aydın məhsul planına çevirmək üçün POLADO komandası ilə konsultasiya planlaşdıra bilərsiniz.