Here's the rewritten version with hyphens removed and phrasing adjusted where needed:

Decision 1: Three landing experiences, not one filtered dashboard

The conventional enterprise approach to multi role platforms is a single dashboard architecture where access permissions determine visibility. I rejected this model for one specific reason: the structure of useful information differs by role, not just the content.

A Zonal Admin's most useful landing screen is a prioritised task queue: pending approvals first, flagged RMs second, then zone summary metrics. An FGMO Admin's most useful landing screen is a ranked zone performance grid: which zones are up, which are down, and what has changed since last week. A CO Admin's most useful landing screen is a national exposure summary with one click drill down.

These are not the same structure with different data. They are different structures that reflect different jobs. I designed three distinct landing experiences. Each opening page, primary navigation order, and default data view was role specific, while maintaining a shared visual language so the platform felt coherent to anyone who needed to operate across levels.

The trade off: this tripled the landing page design complexity and required more alignment time with stakeholders to get role specific hierarchy right. I addressed this by running separate review sessions with a representative from each admin tier rather than combined sessions. Combined sessions tend to converge on the most vocal role's preference, which in this case was Zonal Admins, the most numerous group.

Decision 2: The approval workflow as an accountability system, not a form

The existing MSME addition process had no structure. An RM submitted a request, it entered a shared email thread, and someone approved it when they got to it. There was no tracking, no documented rationale, no audit trail, and no compliance defensibility.

I designed the approval workflow as a three stage accountability system. At each stage, Zonal review, FGMO confirmation, and CO final approval for large accounts, the approving admin sees a structured checklist of verification criteria, a mandatory decision field (Approve, Return with reason, or Escalate), and a free text rationale field required on every decision, not just rejections.

Every decision is logged with a timestamp, admin name, role level, and rationale, creating a complete audit trail visible to CO Admins. This was not in the original brief. It emerged from a review session where a CO Admin described a recurring problem: MSME applications were being rejected at Zonal level for inconsistent reasons, and because no reason was documented, the same types of valid applications were being rejected repeatedly by different Zonal Admins applying different implicit criteria.

The audit trail turned the approval workflow from a routing system into a knowledge system. Over time, the logged rejection reasons become a reference for what good applications look like, reducing inconsistency without requiring top down rule updates.

Decision 3: Data visualisation calibrated to decision speed, not data completeness

Each admin tier needed different chart types because they make different kinds of decisions at different speeds.

Zonal Admins needed counts and lists: number of pending approvals, names of overdue RMs, and count of active MSMEs by status. I used data tables and status tagged lists rather than charts because their decisions are immediate: action or no action. Charts do not help when the answer is binary.

FGMO Admins needed ranked comparisons. I used horizontal bar charts for zone performance rankings specifically because they make relative position legible at a glance. A table of numbers forces mental comparison. A ranked bar chart makes the same comparison instant.

CO Admins needed trend lines and exposure maps. Their decisions are longer cycle, strategic rather than reactive, so temporal trends matter more than point in time snapshots. I used line charts with a configurable time window (7 days, 30 days, or quarter) that defaulted to 30 days based on their stated reporting cadence.

The unifying principle: match the visualisation type to the decision speed of the user, not to the data structure of the underlying system.

Decision 4: Focus mode for the approval workflow

High density dashboards create a well documented problem for consequential decisions: peripheral information activates divided attention. When a Zonal Admin is approving or rejecting an MSME addition, a compliance relevant decision with downstream consequences, I wanted them focused on that decision, not scanning the rest of the dashboard.

I designed a Focus Mode for the approval workflow, a full screen overlay that removes all navigation chrome, shows only the application detail and the decision checklist, and requires an explicit decision before returning to the dashboard. This was a deliberate cognitive choice: consequential decisions deserve dedicated screen states, not modals dropped on top of a busy interface.

Decision 5: Direct to high fidelity as a deliberate strategy

With a compressed timeline and daily access to admin stakeholders within the bank, I made a deliberate call to skip low fidelity wireframing and validate at high fidelity from the start. The risk this introduced, building in the wrong direction at high cost, was mitigated by running short, focused review sessions of 45 minutes with one representative from each admin tier every week throughout the design process.

This meant three parallel feedback tracks running simultaneously. The overhead was real, but it surfaced role specific issues before they compounded. In a more sequential process, a Zonal Admin's feedback in week 3 might invalidate FGMO design decisions made in week 1. The parallel track structure caught those conflicts early.