The problem
Kotak Mahindra Bank’s branch network processes more than 60 million transactions a year. On paper, a branch officer’s job is straightforward — help the customer sitting across the desk complete a transfer, open an account, submit a service request. In practice, that officer moved between 10 to 15 different systems to do it, each with its own login and its own patterns. Some were core banking terminals from the 90s; others were newer web tools bolted on top of them.
Branch employees needed 10 to 15 systems to complete customer-facing banking tasks, with 30+ minute customer wait times and high error rates.
Each of those systems carried its own workflow, authentication, transaction logic, permissions, compliance checks, audit trail and interaction patterns. The fragmentation was not only in the software — it ran through the operating definitions underneath it.
Create a shared operational structure that can carry multiple banking services without breaking compliance, auditability, or the core systems that cannot be replaced.
Constraints
- Legacy infrastructure
- The underlying core banking systems could not be replaced. They had to be wrapped.
- Compliance
- Every meaningful transaction action needed traceability. The compliance team held veto power on every screen.
- Operational speed
- Branch employees were serving customers in real time, with roughly five minutes per visit. Any friction in the workflow became wait time in the lobby.
- Scale
- Patterns had to work consistently across 5,000+ staff from day one, while the branches stayed open.
- Progressive migration
- Services moved onto the platform incrementally, so old and new had to coexist without a cutover.
Understanding the system
Before designing anything, I ran facilitated workshops with business, operations and technology leaders — not the “how might we” kind, but the “what does compliance actually require here, what does the core banking system actually return, where does the officer’s workflow break down” kind. Three months of that produced a joint scope document and a service map.
-
Facilitated workshops with business, operations and technology leaders, ending in a joint scope document and service map.
-
Three teams that had worked alongside each other for years did not share a definition of what a transaction was — when it started, when it was final, and who could see it in between.
-
A shared interface was the second problem. The first was a shared vocabulary of states, because without one there was nothing for three teams to agree on and nothing for compliance to sign off.
-
Current-state walkthrough of a single customer visit, timed and counted across the systems an officer touched.
-
Repeated authentication was only part of the delay. Context switching and inconsistent transaction states between systems created additional operational friction.
-
The unit of the design was not a feature or a persona. It was a customer visit, measured from greeting to receipt.
Key decisions
Design around the customer visit, not around the bank's product catalogue
- The obvious structure was to organise the platform the way the bank organises itself — by product line, mirroring the systems being replaced. That would have reproduced the fragmentation inside a single login.
- Timing a customer visit showed the officer's cost was concentrated in the switches between tasks, not inside any one task.
- Structuring by visit made the officer's real unit of work the platform's unit of work. Structuring by product would have optimised each service in isolation and left the switching cost untouched — the exact failure of the system being replaced.
- Navigation, service grouping and the post-login surface were all built around what an officer needs during a visit. The single-SSO decision came out of this: cutting authentication in half was not a UX win in the abstract, it was time returned to every service request.
- Officers complete a customer-facing task without leaving the platform.
Model transaction states before designing any screen
- Each legacy system expressed the progress of a transaction differently, and compliance needed an audit trail that none of them agreed on.
- The workshops surfaced that business, operations and technology each described a transaction's lifecycle differently, including what counted as final.
- A form that greys out fields depending on where the officer is hides the state machine inside the UI, where engineering cannot build against it and compliance cannot audit it. Making states explicit moved that logic somewhere all three teams could see.
- Explicit states — initiated, verification, compliance hold, processing, completed — with exception states for failed, rejected and reversed. Each state got its own screen rather than one form with conditional fields. Every service designed afterwards inherited the model.
- Engineering could build against the states cleanly, compliance could sign off on the audit trail, and the officer could see where a transaction stood without asking anyone.
Standardise the workflow before standardising components
- Six services were being designed in parallel, with more to follow. Component-level consistency would not stop each service inventing its own sequence.
- Across services, the underlying operational sequence was the same even where the banking product was not.
- A component library makes services look consistent. A shared workflow makes them behave consistently — which is what an officer moving between services actually experiences, and what lets a new service be designed without renegotiating its shape.
- One operational spine — identify customer, choose service, capture information, validate, review, process, confirm — became the default sequence for every service, and the basis for the reusable UI patterns layered on top of it.
Scope AI narrowly around policy knowledge, not around the interface
- The officer's real cognitive load was not operating the app. It was remembering policy — which procedure applies to which customer, under which rule.
- Officers were carrying procedural knowledge between systems and asking colleagues rather than consulting documentation mid-visit.
- A general-purpose assistant would have been the more impressive demo and the less useful tool: in a regulated environment, an answer that is plausible but not the bank's own policy is worse than no answer. Constraining the domain was what made it safe to ship.
- Companion answers only from the bank's own services and approved internal knowledge — no open-domain answers. The interaction pattern is deliberately conventional: a linear chat, no experimental AI interface. Tools, a second feature, provides guided templates for staff communication with tone guidance and pre-vetted phrasing, so a junior officer's email to a customer reads like a senior officer's.
- AI carries the policy layer, which let the application itself stay simple.
Design evidence
Each artifact here exists to show a decision, not to show a screen.
Validation
Before hand-off I ran moderated, task-based prototype testing with branch staff — recorded sessions, task-based questioning, and feedback analysis. The tasks were built around the questions that matter operationally rather than around whether people liked the interface:
- Can an officer tell where to begin, without being told?
- Can they complete a representative task unassisted, inside the time a customer is willing to wait?
- Can they tell what state a transaction is in, and who needs to act next?
- Can they recover when something fails?
Some patterns broke under real interaction and were redesigned. That work continues as services move onto the platform.
Outcome
Product and user impact
- Target Authentication steps and average handling time both halved — the objective the programme was designed against.
- Observed Officers complete customer-facing tasks inside the platform rather than moving between systems.
Business and operational impact
- Measured Six core services designed end to end during my tenure, including fund transfer and its cash, physical and cheque sub-types.
- Measured Single sign-on across the platform, replacing per-system authentication.
- Target Live in branches, with a materially larger rollout targeted this year.
System impact
- Measured A shared transaction-state model that every service designed after it inherited.
- Measured A reusable operational workflow that became the basis for the platform's UI patterns and design-system foundation.
- Observed Accessibility standards applied consistently across services — contrast, keyboard and focus order, and screen-reader labelling reviewed before hand-off.
Environment
- Scale 5,000+ branch staff.
- Scale 60M+ transactions a year across the branch network.
Leadership
- Me as Senior UX Lead, with one junior designer, reporting to two VPs of Design.
- Product, Technology, Operations, Compliance, and design leadership. I ran the working sessions directly; the VP handled the higher-level stakeholder rooms.
-
- UX direction
- Problem framing and scope
- Workflow architecture
- Service design
- Transaction state models
- Design reviews
- Design-system consistency
- Moderated validation
- Stakeholder alignment
- Hand-off
Reflection
The interface is the smallest part of an enterprise redesign. Ninety percent of the work is aligning what business, operations and technology each think the problem is — before any of them can agree on what “done” looks like. Once that alignment happens, the design almost writes itself. Once it doesn’t, no amount of polish will save the ship date.
The other lesson: process artifacts — state models, service maps, journey diagrams — do more work in banking projects than pixel-perfect mockups. They are what compliance signs off on. They are what engineering builds against. They are what stakeholders read. In this domain, they are the design output.