Chapter 6: System UI/UX

Bab ini memformalkan antarmuka sistem BMP: Module, Workspace, Role, Permission, User, Settings, dan Administration. Bab ini menjelaskan bagaimana konsep-konsep tersebut terlihat, dikelompokkan, dinavigasikan, dan digunakan oleh administrator maupun user bisnis.

Status: 🟡 Draft / Menunggu Finalisasi

6.0 System UI/UX Principles

System UI BMP mengikuti prinsip utama:

System UI menjelaskan sistem kepada manusia tanpa memaksa manusia memahami struktur internal sistem.

UI harus membedakan dengan jelas:

1. Business UI — pekerjaan operasional sehari-hari.
2. System UI — konfigurasi dan administrasi platform.
3. Policy UI — aturan yang mengendalikan perilaku sistem.
4. Master Data UI — data referensi yang dimiliki masing-masing domain.

Keempatnya tidak boleh dicampur menjadi satu launcher atau satu daftar konfigurasi.

Blueprint secara eksplisit menetapkan bahwa Settings Hub menjadi satu permukaan untuk policy, sementara master data tetap berada di modul pemiliknya.

6.1 Dua Dunia UI: Business dan System

BMP memiliki dua pengalaman utama.

Business Home

Untuk user operasional:

Home

├── Search

├── My Attention

├── KPI

└── Operational Queue

Landing menjawab:

"Apa yang perlu saya kerjakan?"

bukan:

"Modul apa yang tersedia?"

Ini sudah menjadi prinsip utama Landing Page BMP.

System Console

Untuk administrator/system user:

System Console

├── Modules

├── Users

├── Roles

├── Permissions

├── Workspaces

├── Settings

└── System & Utility

Akun IT/Sysadmin menggunakan System Console sebagai home, bukan Business Home.

6.2 Strict UI Ownership

Setiap item UI memiliki satu owner.

Contoh:

Sebuah domain tidak boleh memasukkan entitas domain lain ke sidebar hanya karena entitas tersebut berhubungan dengannya.

Aturan ini disebut Strict UI Ownership.

6.3 Module Model

Module adalah unit kemampuan bisnis yang dapat diaktifkan atau dinonaktifkan pada sebuah instalasi BMP.

Module bukan:

• role;
• permission;
• workspace;
• menu item;
• resource individual.

Hubungannya:

Installation

│

├── Modules

│ ├── Sales

│ ├── Purchase

│ ├── Inventory

│ └── ...

│

└── Users

Module enablement bersifat installation-level.

Blueprint menetapkan module sebagai sesuatu yang dapat di-toggle melalui tabel modules.

6.4 Module Catalog

Module bisnis utama BMP:

Daftar tersebut merupakan struktur yang tampil pada rail utama BMP.

System modules:

Ketiganya berada di zona settings dan role-gated.

6.5 Module Enablement UI

Administrator melihat:

Settings Hub

→ Modules

Setiap module ditampilkan sebagai row:

┌────────────────────────────────────────────┐

│ Sales [ ON ] │

│ Customer, Sales Order, Delivery, Invoice │

├────────────────────────────────────────────┤

│ Manufacturing [ OFF] │

│ BOM, Work Order, Production │

└────────────────────────────────────────────┘

Toggle hanya mengontrol availability module pada instalasi.

Toggle tidak berarti:

semua user otomatis boleh menggunakan module.

Urutannya:

Module enabled

↓

Role has permission

↓

User has role

↓

Workspace exposes UI

6.6 Hidden Module

Module tertentu boleh tersedia secara teknis tetapi disembunyikan dari user bisnis.

Contoh yang sudah ditetapkan:

Project / R&D = hidden by default.

UI harus membedakan:

Disabled

dengan:

Enabled but hidden

Karena keduanya memiliki arti berbeda.

6.7 Workspace

Workspace adalah permukaan kerja user untuk sebuah area bisnis.

Workspace bukan database resource.

Workspace menentukan bagaimana user memasuki sebuah domain:

Workspace

├── title

├── navigation

├── shortcuts

├── saved views

├── primary actions

└── relevant KPIs

Workspace merupakan lapisan presentation/navigation, bukan lapisan security.

Blueprint secara eksplisit menetapkan bahwa konfigurasi workspace/flyout hanya bersifat presentasi.

6.8 Workspace vs Module

Perbedaannya:

Satu module dapat mempunyai beberapa workspace.

Contoh:

Sales

├── Sales Workspace

├── Order Workspace

└── Customer Workspace

Workspace tidak boleh digunakan untuk memberikan permission.

6.9 Workspace Layout

Workspace mengikuti pola:

Page Head

↓

Workspace Header

↓

Primary Action

↓

KPI / Attention

↓

Shortcuts / Views

↓

Operational List

Workspace harus segera berguna ketika dibuka.

Tidak boleh menjadi halaman kosong yang hanya menampilkan nama module.

Empty state harus memberikan aksi berikutnya.

6.10 Primary Action

Setiap workspace memiliki satu primary action.

Contoh:

Sales

[+ Create Sales Order]

Primary slot digunakan untuk aksi dominan halaman, biasanya Create.

Primary slot tidak boleh dipakai untuk navigasi.

6.11 Saved Views

Saved View adalah konfigurasi tampilan yang disimpan user.

Contoh:

Sales Orders

[ All Orders ▼ ]

My Views

├── Assigned to Me

├── Pending Approval

└── Recent Activity

Tiga istilah tersebut sudah ditetapkan sebagai vocabulary UI BMP.

Saved View dapat menyimpan:

• filter;
• sort;
• kolom;
• density;
• pagination preference.

Saved View tidak mengubah permission.

6.12 Permission

Permission menjawab:

"Apa yang boleh dilakukan user?"

Bukan:

"Apa yang terlihat di sidebar?"

Model konseptual:

Role

↓

Permission

↓

Resource

↓

Action

Contoh:

Finance

└── Payment Entry

├── Read

├── Create

├── Update

├── Submit

└── Export

Security enforcement dilakukan oleh Ash.Policy.Authorizer; Chapter 6 hanya menentukan representasi UI-nya.

6.13 Permission Matrix UI

Administrator melihat permission dalam bentuk matrix:

UI tidak boleh menampilkan permission sebagai daftar panjang checkbox tanpa grouping.

Grouping:

Sales

├── Sales Order

├── Delivery Note

└── Sales Invoice

Purchase

├── Purchase Order

└── Purchase Receipt

6.14 Export Permission

Export dianggap sebagai aksi tersendiri.

Jika user tidak memiliki permission Export:

Export button = hidden

dan endpoint export juga harus diblokir.

UI tidak boleh hanya menyembunyikan tombol sambil membiarkan endpoint terbuka.

Aturan ini sudah ditetapkan pada Cloak/security convention.

6.15 Role

Role adalah template fungsi kerja.

Role bukan user.

Role bukan permission tunggal.

Role menggabungkan sekumpulan permission yang relevan untuk fungsi tertentu.

Model:

Role

└── Permissions

↓

User

Contoh role:

Owner

Finance

Sales

Warehouse

Production

HR

QA

IT Support

Blueprint telah menambahkan master roles dan junction user_roles.

6.16 Multiple Roles

Seorang user dapat mempunyai lebih dari satu role.

Contoh:

User: Finance Supervisor

Roles:

├── Finance

└── Approver

UI assignment menggunakan multi-select role.

Jangan membuat role gabungan seperti:

Finance + Warehouse + Approver

untuk setiap kombinasi user.

Role harus tetap modular.

6.17 Permission vs Role vs Personalization

Tiga layer harus tetap terpisah:

Permission

↓

Role Default

↓

Personal Customization

Maknanya:

Permission

Apa yang boleh dilakukan.

Role Default

Konfigurasi default berdasarkan fungsi.

Personal Customization

Bagaimana user memilih bekerja.

Pemisahan tiga layer ini sudah ditetapkan pada Interaction Structure.

Personalization tidak boleh menaikkan permission.

6.18 User Administration

Halaman User:

Users

├── User identity

├── Account status

├── Roles

├── Organization

└── Preferences

Contoh:

┌───────────────────────────────────────────┐

│ Ahmad │

│ ahmad@company.local │

│ │

│ Roles │

│ [Finance] [Approver] │

│ │

│ Status Active │

└───────────────────────────────────────────┘

Role assignment dilakukan di sini.

Permission detail tetap dikelola pada Role/Permission UI.

6.19 Account ≠ Persona

BMP menggunakan model account, bukan persona gabungan.

Satu orang dapat mempunyai lebih dari satu akun terpisah.

Karena itu UI tidak boleh mencoba membuat satu user identity yang sekaligus memuat:

Business Employee

IT Administrator

System Administrator

sebagai satu persona yang tidak jelas.

6.20 Business Home vs System Console

Perbedaan visual harus jelas.

Business user

BMP

├── Search

├── Accounting

├── Sales

├── Inventory

└── ...

IT/System Administrator

BMP

├── System & Utility

├── Administration

└── Organization

Akun IT/Sysadmin mendapatkan System Console sebagai home.

6.21 Settings Hub

Settings Hub adalah satu permukaan konfigurasi policy BMP.

Tidak boleh ada:

Sales Settings

Purchase Settings

Inventory Settings

Accounting Settings

System Settings

yang masing-masing menciptakan sistem settings sendiri tanpa struktur bersama.

Sebaliknya:

Settings Hub

├── Sales

├── Purchase

├── Inventory

├── Accounting

├── Manufacturing

├── HR

└── System

Settings Hub menangani policy/configuration, bukan semua master data.

Master data tetap berada pada module pemiliknya.

6.22 Settings Classification

Setiap setting harus diklasifikasikan.

Jangan memindahkan master data ke Settings hanya karena secara visual "terlihat seperti konfigurasi".

6.23 Settings UI

Pola:

Settings Hub

Search settings...

General

├── Company

├── Currency

└── Fiscal Year

Sales

├── Sales Policy

├── Pricing

└── Returns

Inventory

├── Stock Policy

└── Warehouse Policy

Accounting

├── Posting Policy

└── Tax Policy

Settings harus dikelompokkan berdasarkan policy owner.

6.24 Settings Value Model

Policy sederhana menggunakan scalar setting.

Contoh:

setting:

key = sales.allow_negative_stock

value = false

Settings tidak digunakan untuk menyimpan master data kompleks.

Blueprint menetapkan bahwa policy adalah scalar pada tabel settings, sedangkan master data tetap berada di module pemiliknya.

6.25 Organization UI

Organization menangani entitas organisasi, terutama:

Organization

├── Company

├── Departments

└── Organizational structure

Company bukan Settings.

Company bukan User.

Company bukan Role.

Department juga merupakan master tersendiri.

Blueprint v1.7 menetapkan master departments dan relasi employees.department_id.

6.26 Department UI

Department digunakan untuk struktur organisasi.

Contoh:

Organization

└── Departments

├── Production

├── Supply Chain

├── Sales & Marketing

├── Finance & Accounting

├── HRGA

├── Technical Support

└── IT

Department bukan Role.

Contoh:

Employee:

Department = Finance

Role = Finance

tetapi bisa juga:

Employee:

Department = Finance

Role = Approver

6.27 Navigation Visibility

Visibility UI mengikuti tiga kondisi:

Module Enabled

User Authorized

Workspace Visible

↓

Navigation Item Visible

Jika module disabled:

Tidak tampil.

Jika module enabled tetapi user tidak memiliki permission:

Tidak tampil.

Jika user memiliki permission tetapi workspace dikonfigurasi hidden:

Tidak tampil di navigation.

Namun hidden navigation tidak sama dengan security denial.

Workspace hanya presentation.

6.28 Flyout Menu

Flyout merupakan navigational surface.

Menu tree bersifat statis dan difilter berdasarkan role/user permission.

Blueprint menetapkan static menu tree + role filter sebagai implementasi flyout.

Flyout tidak boleh menjadi tempat business logic.

6.29 Breadcrumb

Breadcrumb harus menggunakan pohon navigasi yang sama dengan sidebar.

Contoh:

Home

→ Sales

→ Sales Orders

→ SO-2026-00125

Tidak boleh ada dua hierarchy:

Sidebar hierarchy ≠ Breadcrumb hierarchy

Aturan ini sudah dikunci dalam Interaction Structure.

6.30 Search as System Navigation

Universal Search (Ctrl+K) merupakan navigasi global.

Search mencakup:

Action

Document

Report

Setting

dan menggunakan satu endpoint search.

Contoh:

Ctrl+K

Search...

Actions

Create Sales Order

Documents

SO-2026-00125

Reports

Sales by Item

Settings

Negative Stock Policy

Search result tidak boleh mencampurkan semua jenis hasil tanpa grouping.

6.31 Role-Aware Search

Search hanya menampilkan sesuatu yang memang relevan bagi user.

Jika user tidak memiliki akses:

Setting X

maka setting tersebut tidak boleh muncul sebagai hasil search.

Begitu pula:

• module;
• document;
• report;
• action.

Search adalah bagian dari navigation UX, bukan bypass permission.

6.32 Attention Model

Business Home menggunakan satu feed:

My Attention

yang menggabungkan:

• task;
• notification;
• alert.

KPI dipersempit berdasarkan role user.

Contoh:

Finance

My Attention

├── 3 Payments Pending

├── 2 Journal Entries to Review

└── 1 Reconciliation Discrepancy

Warehouse

My Attention

├── 12 Delivery Notes

├── 4 Stock Reservations

└── 2 Receiving Tasks

6.33 Real-Time System Feedback

System UI dapat menerima update real-time melalui event architecture.

Contoh:

Approval created

↓

Phoenix PubSub

↓

My Attention

↓

Badge/KPI refresh

Channel yang sudah ditetapkan:

user:<id>:notifications

company:<id>:document_updates

company:<id>:kpi_refresh

6.34 Permission-Aware UI

UI harus memberikan feedback yang masuk akal.

Ada tiga keadaan:

Visible + allowed

[Submit]

Visible but unavailable

Digunakan apabila user perlu mengetahui bahwa action ada tetapi kondisi bisnis belum terpenuhi.

[Submit] disabled

Reason: Missing required approval

Not authorized

Action tidak ditampilkan.

Submit

tidak muncul sama sekali.

Jangan menampilkan error authorization setelah user menekan tombol apabila keberadaan action tersebut sendiri sudah diketahui tidak diizinkan.

6.35 Security UI Boundary

Security memiliki tiga lapisan:

1. Cloak

↓

2. Ash Policy

↓

3. Workspace/UI

Cloak = perlindungan data at-rest.

Policy = authorization.

Workspace = presentation.

Blueprint secara eksplisit menetapkan ketiga lapisan tersebut.

Workspace tidak boleh dianggap sebagai security boundary.

6.36 Sensitive Field Presentation

Jika user tidak berhak melihat field sensitif:

Field tidak dirender.

Bukan:

Field dirender lalu di-mask menggunakan CSS.

Bukan juga:

Field dikirim ke browser lalu disembunyikan JavaScript.

API serialization juga harus membuang field tersebut bila role bukan pembaca.

6.37 User Preferences

Preferences adalah konfigurasi personal.

Contoh:

Preferences

├── Density

├── Sidebar state

├── Table columns

├── Saved views

└── Other personal UI settings

Preferences tidak mengubah:

• role;
• permission;
• module enablement;
• company policy.

Persistent UI state disimpan pada user_settings.

6.38 Density

BMP mendukung personal density.

Contoh:

Comfortable

Compact

Namun density tidak mengubah fundamental interaction target.

Contoh:

Desktop table:

44px / 36px row

merupakan pilihan yang sudah ditetapkan untuk Chrome Fix, sementara touch target tetap mengikuti aturan accessibility.

6.39 Responsive Context

BMP memiliki tiga konteks penggunaan:

System UI tidak boleh mendesain ketiganya sebagai tiga aplikasi berbeda.

6.40 Overlay Usage

System UI mengikuti lima tingkat overlay yang sudah ditetapkan:

System administration sebaiknya menggunakan level terendah yang masih mempertahankan konteks.

6.41 System UI Empty State

Empty state tidak boleh sekadar:

No data.

Harus menjawab:

1. mengapa kosong;
2. apa yang dapat dilakukan berikutnya.

Contoh:

No roles have been created.

Create your first role

[ + Create Role ]

Ini mengikuti aturan umum BMP bahwa setiap empty state harus mempunyai CTA ke aksi berikutnya.

6.42 System UI Navigation Map

Struktur keseluruhan:

BMP

│

├── Business Home

│ │

│ ├── Accounting

│ ├── Sales

│ ├── Purchase

│ ├── Manufacturing

│ ├── Inventory

│ ├── HR

│ ├── Asset

│ ├── Quality

│ └── Project

│

└── System Console

│

├── System & Utility

├── Administration

│ ├── Users

│ ├── Roles

│ └── Permissions

│

└── Organization

├── Companies

└── Departments

Settings Hub

├── System Policy

├── Business Policy

└── Module Policy

Struktur ini sengaja memisahkan business navigation dari system administration.

6.43 System UI Relationship Model

Secara konseptual:

Installation

│

┌───────┴───────┐

│ │

Modules Organization

│ │

│ ┌────┴────┐

│ Company Department

│

Workspaces

│

│

User ─────── Roles

│

│

Permissions

│

↓

Resources

│

↓

Actions

Dan:

User

└── Personal Settings

├── Density

├── Saved Views

├── Columns

└── Rail State

Personalization tetap berada di luar authorization model.

6.44 What System UI Must Not Do

System UI tidak boleh:

1. Mengubah permission hanya dengan mengubah visibility workspace.
2. Menyimpan business master data di Settings Hub.
3. Menempatkan module lintas domain ke sidebar domain lain.
4. Menggunakan workspace sebagai security boundary.
5. Menampilkan sensitive field lalu menyembunyikannya dengan CSS.
6. Membuat role baru untuk setiap kombinasi user.
7. Menggunakan launcher besar sebagai pengganti navigation.
8. Membuat halaman konfigurasi tanpa konteks.
9. Membuat satu dropdown yang mencampur navigation, preferences, dan session.
10. Membiarkan search menjadi bypass authorization.

6.45 System UI Consistency Rules

Semua halaman System UI mengikuti pola yang sama:

Page Head

↓

Breadcrumb

↓

Page Title

↓

Description / Context

↓

Primary Action

↓

Content

Contoh:

Administration / Roles

Roles

Define reusable access templates for users.

[+ Create Role]

┌────────────────────────────────────────────┐

│ Role Users Permissions │

├────────────────────────────────────────────┤

│ Finance 4 18 │

│ Sales 6 14 │

│ Warehouse 8 11 │

└────────────────────────────────────────────┘

6.46 System UI Definition of Done

Sebuah halaman System UI dianggap selesai apabila:

• Ownership domain jelas.
• Posisi dalam navigation tree jelas.
• Breadcrumb konsisten dengan navigation.
• Module dependency jelas.
• Workspace ownership jelas.
• Role/permission relationship jelas.
• Permission bukan hanya presentation state.
• Sensitive field tidak bocor.
• Empty state memiliki next action.
• Primary action jelas.
• Search dapat menemukan halaman bila user berhak.
• Unauthorized item tidak muncul.
• Personalization tidak mengubah authorization.
• Responsive context diperhitungkan.
• Keyboard navigation mengikuti Chapter 2.
• Overlay mengikuti lima level BMP.
• Loading dan error state mengikuti consistency pattern.

6.47 Final System UI Principle

System UI BMP harus membuat user memahami:

Apa yang tersedia → apa yang dapat saya lakukan → mengapa saya dapat/tidak dapat melakukannya → di mana saya dapat mengaturnya.

Struktur mental akhirnya:

Module

= capability

Workspace

= working surface

Role

= functional template

Permission

= authorization

User

= account identity

Settings

= policy

Preferences

= personal choice

Tidak boleh ada dua konsep yang memiliki fungsi UI yang sama.

Module ≠ Workspace
Role ≠ Permission
Permission ≠ Visibility
Settings ≠ Master Data
Workspace ≠ Security
Preferences ≠ Policy

Inilah batas konseptual utama System UI BMP.

Bagian Atas Formulir

Bagian Bawah Formulir