Case Study 2 of 4
Banker Experience Evolution — Entitlement-Driven Navigation
Redesigning branch-banking navigation around role-based entitlements so each banker persona sees only the workflows relevant to their counter function.
Jira
Figma
TL;DR
- Five kinds of branch staff worked from one navigation shell, with every role's exceptions hardcoded on top, so each release risked breaking a persona nobody was testing that sprint.
- The key call: map where the roles really differ before designing anything, then make roles configuration, not code.
- Result: 40% less redundant configuration, 30% faster releases, 99% adoption with minimal production defects.
1Problem & who it's for
Branch staff across five distinct roles were working from largely the same navigation shell — the same menu structure, the same set of visible transactions, regardless of whether the person logged in was a teller processing a deposit or a wealth manager reviewing a portfolio. Every role's edge cases had been bolted onto a shared UI over time, and each new banker persona added meant another round of hardcoded exceptions rather than a structural fix.
- For branch staff, menu options irrelevant to their role meant more scrolling, more misclicks and longer handle times in front of a live customer — exactly when speed matters most.
- For engineering, five personas' worth of duplicated, hardcoded configuration meant every release touching navigation risked breaking a persona nobody was actively testing that sprint.
2Evidence & inputs
The starting question wasn't "what should the menu look like" — it was "where do these five roles' workflows actually diverge, versus where do we just assume they diverge."
- Divergence mapping: each persona's real transaction set, laid against the existing branch-hierarchy data. A meaningful share of the "role-specific" logic turned out to be shared across roles, duplicated out of caution during earlier releases.
- Usage clusters: which transactions actually got used together in practice, which later decided the menu groupings.
- Branch staff themselves: clickable prototypes and iterative UAT, before engineering handoff and again before rollout.
3Workflow, controls & guardrails
At sign-in, the banker's role and place in the branch hierarchy are matched against JSON entitlement rules. The navigation then shows only that role's accordion sections — Teller Operations, Account Services, Loan Servicing, Customer Due Diligence — each with the context-specific transactions that role is allowed to perform.
- Access is a control, not just a convenience. The entitlement rules were reviewed with engineering, compliance and branch operations so they met security and audit requirements; hiding a transaction from a role had to mean that role could not perform it.
- The failure mode designed against: a navigation change breaking a persona nobody tested. With roles as configuration, a change is one rule edit that can be checked per persona, not five parallel code paths.
4Options considered
5Decision, trade-offs & non-goals
Menus grouped by real usage, not by org chart. The first accordion groupings followed which transaction clusters actually got used together, not how the bank's org chart divided responsibilities on paper — the two didn't always match.
Trade-offs accepted.
- More upfront design time for the entitlement model, in exchange for the 40% redundancy reduction.
- A longer rollout window, with iterative UAT alongside real branch staff instead of a single big-bang release, in exchange for catching usability issues before they reached production at scale.
Non-goals for this phase.
- Fully unifying the sales-executive and branch-manager roles. Their overlap looked highest, but it was left for a later phase rather than widening this one.
- Changing the transactions themselves. The work changed who sees which transaction and where, not how any transaction behaves.
6What I delivered
- Product requirements for role-based UI controls covering all 5 banker personas
- Interactive wireframes and clickable prototypes (built in Replit and Lovable) to validate navigation flows and role-specific UX with branch staff before engineering handoff
- The entitlement rules, agreed with engineering, compliance and branch operations
- An iterative UAT plan run with branch staff before production rollout
A diagram of the approach, not a product screen. The real artefacts are the client's and stay confidential.
7Outcome & metrics
- 30% faster release cycles
- 40% redundancy reduction across banker roles
- 99% adoption rate with minimal production defects
Figures as recorded at the time. Client-identifying detail is withheld under NDA.
8Retrospective
The real unlock was resisting the urge to treat this as five separate redesigns. The entitlement model only works if you build the divergence-mapping step first and treat the personas as configurations of one system, not five products.
What I'd do differently: put branch staff in front of the prototypes even earlier. Engineering sign-off wasn't the same as a teller finding the flow natural, and the usability issues that mattered only surfaced once branch staff actually used it.
What I'd question next: the boundary between sales executive and branch manager, where the overlap looked highest but wasn't fully unified in this phase.