Decision 1: Rebuilding data visibility from operational need, not organisational rank

The most consequential design decision on this project happened before a single screen was built — and it was a decision to push back on the initial brief.

Several features proposed for this platform assumed that admin access should mirror the organisational hierarchy: more senior role means more data visibility. As a principle for permissions architecture, this is intuitive. As a principle for data access in a regulated wealth environment, it creates exposure risk.

I challenged the default and proposed an alternative principle: data access should match operational need, not organisational rank.

A Zonal Admin's operational need is to know whether a relationship event needs attention — not what the underlying financial figures are. An FGMO Admin's operational need is to identify escalation risk at zone level — not to review individual client portfolios. Only the CO Admin has an operational case for full financial data visibility, alongside the governance responsibility that justifies it.

Working with the BA team and admin stakeholders, I mapped each role's actual operational decisions against the data required to make them. This produced a tiered visibility model:

• Zonal Admins see relationship health indicators — activity status, alert response, follow-up gaps — without access to client financial data [verify specific restrictions]

• FGMO Admins see zone-level performance aggregates and escalation queues, with financial data visible at a threshold level rather than in full detail [verify]

• CO Admins have full data visibility plus the access governance tools to manage what lower tiers can see

• All data exports at FGMO and CO level require a logged reason-for-export, creating an audit record for every data extraction event

This pushback added two weeks to the project timeline due to additional stakeholder alignment. I made the case on both compliance and design grounds — compliance because uncontrolled access to HNI financial data creates regulatory risk, design because data that isn't needed creates cognitive noise that obscures the signals that are.

Decision 2: Two approval tracks — designed as parallel systems with distinct decision logic

This platform required two entirely separate approval workflows running simultaneously, each with different criteria, different stakeholders, and different compliance implications:

Track 1 — RM Management Approvals: Requests to add, reassign, or deactivate Relationship Managers. These decisions affect every client that RM manages — a wrong assignment or a delayed deactivation in a wealth management context carries downstream risk across an entire portfolio of high-value relationships.

Track 2 — Customer List Approvals: Requests to add new HNI clients to an RM's managed portfolio. These decisions involve client eligibility criteria, KYC completion status, portfolio fit assessment, and compliance sign-off — each of which needs to be documented for regulatory purposes.

The design challenge: both tracks move through the same admin hierarchy, use the same approval stages, and appear in the same interface. Without clear structural differentiation, an admin could apply RM-management thinking to a customer addition decision — or vice versa — with consequences in either direction.

I designed them as visually parallel but informationally distinct systems. The interface pattern is identical: submitted → under review → approved / returned with reason. The decision checklists, the data surfaces at each stage, and the required documentation fields are completely different — determined by the track type, which is persistently labelled throughout every stage of the workflow. Track type is never implied by content alone; it is always explicitly stated in the screen header.

Every decision in both tracks is logged with timestamp, admin identity, role level, and a mandatory rationale field — creating a complete audit trail visible to CO Admins and available for compliance review.

Decision 3: Exception-first architecture — designing for the outlier, not the average

Every admin dashboard in this platform leads with exceptions before summaries. This was a structural choice specific to the high-consequence nature of HNI oversight.

In high-volume environments, summary metrics are the right starting point — the aggregate tells you where attention is needed. In a low-volume, high-consequence environment, summary metrics can actively obscure the problem that most urgently needs attention. An RM managing fifteen well-maintained client relationships and one at-risk one looks entirely healthy in any aggregate view — until the at-risk relationship becomes a lost one.

I designed a persistent "Attention Required" panel at the top of every admin tier's landing view. It is populated by a prioritised exception surface: delayed RM follow-ups, unanswered client activity alerts, approval requests approaching SLA breach, and flagged relationship gaps. This panel is the first thing every admin sees when they open the platform. Performance summaries, analytics, and trend data sit below it and require a deliberate scroll.

This structure was not in the original brief. It emerged from listening carefully to how Zonal Admins described their day — they were not checking summaries and then finding problems. They were looking for problems, and everything else was secondary. The interface now reflects that.

Decision 4: A dedicated access governance module for CO Admins

The CO Admin view contains a module that has no equivalent at lower tiers: a data access management interface where CO Admins can review, adjust, and audit data visibility settings across the entire admin hierarchy.

In a regulated wealth management environment, the ability to control who sees what is not just an IT function — it is a governance function that belongs in the product. Historically this required IT tickets and multi-day turnarounds. I designed it as a first-class feature of the CO Admin experience: configurable visibility tiers, role-based access logs, and an audit history of every access change with timestamp and initiating admin.

The decision to include this was mine, proposed after reviewing the CO Admin requirements and identifying that access governance was described as a pain point but not included in the original feature scope. Getting it added required a conversation with the product team about scope — a conversation I initiated because I believed the absence of it would create a compliance gap that would surface post-launch.

Decision 5: Direct-to-high-fidelity — and how I managed the risk in a compliance-sensitive product

Skipping wireframes in a compliance-sensitive enterprise product carries specific risks: workflow logic errors and data access decisions are harder to catch once stakeholders have seen polished screens and formed mental sign-offs.

I addressed this through two practices. First, I ran a dedicated data access alignment session with the CO Admin representative and the BA team before any screen design began — the output was a written agreement on data visibility per role, against which every subsequent design decision could be checked. Second, I ran separate feedback sessions per admin tier throughout the process, specifically to prevent a lower-tier admin's preferences from anchoring the design of features they don't use. Zonal Admin feedback is valid for Zonal Admin screens. It is not valid input for CO Admin access governance design.