The execution backbone behind enterprise banking operations.
Banking operators were running a bank through five disconnected systems and an inbox. I led the UX of TASK — a centralized operational orchestration layer that collapsed cross-module workflows into one priority-driven execution surface, eliminated high-priority task leakage, and got adopted across the entire SBS banking suite as the operational layer beneath every other product.
Platform Evolution
TASK didn't replace a task tracker. It replaced the email chains, the spreadsheets, the institutional memory, and the five-system Monday morning ritual that operators had been holding the bank together with. It became the operational layer that every other SBS product now sits on top of.
The Impact
I led the UX vision and operational interaction design for TASK — a centralized workflow execution infrastructure for enterprise banking. The brief said "task management tool." What we shipped was the operational backbone that the rest of the SBS banking suite now runs on top of. The same TASK engine I designed here became the routing and notification layer powering the Product & Pricing platform and the other components across the suite.
Before TASK, banking operators were holding the bank together through institutional memory. Tasks lived in one module, escalations in another, approvals in a third, and the connecting tissue was email and spreadsheets. By the time an operator figured out what needed attention, half of it had already breached SLA. TASK collapsed all of that into a single, priority-driven execution surface — and made the workflow itself the communication layer.
The Stakes
Banking back-office operations look like productivity work from the outside. From the inside, they're a continuous high-volume risk management exercise. Every task carries an SLA. Every SLA breach is a compliance issue. Every compliance issue eventually becomes an audit finding, a regulatory penalty, or a reputational hit.
Operators were running mission-critical compliance operations through email threads and shared spreadsheets. High-priority tasks were silently leaking between systems. Operators were holding the bank's execution layer together with muscle memory and effort that didn't scale.
“Every morning I open four different systems just to figure out what's overdue. By the time I find the critical ones, half of them have already breached SLA.”
— Operations Team Lead
The cost of the broken status quo wasn't just slowness. It was the unmeasured cost of every missed escalation, every late discovery, every "I thought you were handling it." Designing TASK meant designing the system that prevented those failures from continuing to be invisible.
The Trap
The brief asked for a task management tool. Six weeks of stakeholder interviews, operator shadowing, and workflow mapping made it clear that the actual problem was much bigger than the brief. The traps were everywhere.
Trap 1 — The kanban temptation
The obvious solution was a kanban board with banking branding. It would have shipped fast and demoed well. It would also have failed instantly. Enterprise banking operations aren't card columns — they're interrupt-driven, escalation-heavy, cross-departmental, and bound by compliance rules a generic productivity tool can't enforce. A kanban board would have replaced one form of fragmentation with another.
Trap 2 — Per-module task queues
Several stakeholders proposed letting each banking module own its own task queue. It would have respected the existing org structure and minimised cross-team coordination. But operators don't think in modules — they think in priorities. A loan exception, a payment recall, and a compliance check all compete for the same attention at the same moment. Splitting them across module-specific queues recreates the exact problem we were trying to solve.
Trap 3 — Email as the orchestration layer
The third trap was the most insidious because it was the existing reality. Email had become the de facto orchestration layer. Operators followed up on tasks in their inboxes, escalated in threads, and held context in unread folders. The trap was thinking email was a coordination tool that needed to be replaced. It wasn't — it was the leakage symptom of having no real coordination tool at all.
Turning Point
The moment that turned the project came during an operator shadowing session. I was watching a senior operator work through their morning queue. To resolve a single payment escalation, they switched between five separate applications, scrolled through an email thread, opened a shared spreadsheet, asked a colleague over chat for context, then circled back to update their senior. The whole sequence took eighteen minutes. The actual decision took thirty seconds.
In the same session, a different operator told me something that reframed everything: *"After I do a task, I update my senior. Then I wait for feedback. Then I come back to do the same task with the feedback. Then I update my senior again. Then I come back again."* That sentence wasn't describing a workflow. It was describing the absence of one.
Platform Evolution
The problem wasn't that operators needed better task management. It was that the conversation about a task lived somewhere other than the task itself. Every escalation, every clarification, every approval had been exiled to email, chat, and meetings. Bring the conversation back to the task, and the workflow re-assembles itself.
From that moment, the design direction became clear: TASK couldn't be a tracker. It had to be the substrate where work happened and conversation happened simultaneously. The task itself had to become the communication layer.
The Work
Four architectural moves shaped TASK. Each one followed from the turning point. Together, they turned a proposed productivity tool into the operational backbone of the SBS banking suite.
01 · Single-pane workflow continuity
One dashboard. Every task, from every banking module, in one prioritised view. Operators no longer switched applications to figure out what needed attention — the system told them, ranked by SLA proximity and risk tier.
Cross-module orchestration as a first-class design principle. Modules became sources, not destinations.
02 · Embedded collaboration on the task itself
Comments, notifications, and approval flows live inside each task — not in email, not in a separate chat tool. The conversation about a task happens where the task lives. Every decision is traceable. Every handoff is auditable. The task itself becomes the communication layer.
This was the answer to the turning point. The senior-back-and-forth loop collapsed from five steps into one continuous thread.
03 · Side-panel execution
Operators resolve tasks without leaving the queue. View diffs, approve, reject, escalate, attach evidence — all from a side panel that opens over the dashboard. The application-switching overhead that defined legacy operations disappeared.
Designed for keyboard-first power users who navigate by muscle memory. Speed without sacrifice.
04 · Routing transparency
Every task surfaces *why* it was routed to a particular operator — their role, their workload, their permissions, the rule that matched. The black-box effect that kills trust in algorithmic systems was designed out from the start.
Trust through transparency. Operators don't need to understand the routing engine — they need to see that it has reasons.
Underneath the four moves sat a single design principle: the workflow itself is the source of truth. Not the email about the workflow. Not the spreadsheet tracking the workflow. Not the meeting where the workflow was discussed. The task carries its own state, its own history, its own conversation, its own next action. Everything else is downstream of that.
The Hard Call — Killing the Color System
My initial proposal included a domain-coded color system — different color themes for different functional areas (payments green, compliance amber, customer ops blue, etc.). The logic was sound: instant visual recognition of what kind of task an operator was dealing with. The design was elegant. The compliance team pushed back hard.
Compliance flagged it as visually clinky — too much chromatic noise on a dashboard where operators already deal with cognitive overload, SLA pressure, and high-density information. In their words: the colour was carrying meaning that should have been carried by structure. They were right.
I let it go. The final design uses a single neutral palette with priority and SLA proximity as the only signals that carry visual weight. Type, spacing, and hierarchy do the work of differentiation. The result is calmer, denser, faster to scan — and aligns with the accessibility-first principles that govern the rest of the SBS platform.
Platform Evolution
Senior design work includes recognizing when a design you fought for is wrong. The clinky-color system would have shipped. It would have looked striking in screenshots. It also would have hurt operators every day for years. Killing it was the right call.
System Architecture
The architecture team owned the allocation engine, lifecycle system, and routing logic. I owned the workflow UX, the operational interaction patterns, and the priority visibility model that translated their complex backend logic into intuitive human execution. The collaboration was tight — every UI signal needed a backend hook, every backend rule needed a visible explanation.
Routing logic transparency
Operators always see *why* a task was routed to them. Role match, workload balance, permission scope, escalation rule — all surfaced contextually. We designed the algorithmic decisions to be inspectable, not invisible.
Targeted visibility
TASK inherits the bank's existing role-based access. Operators only see operationally relevant work — no more, no less. The system enforces the org chart, not the other way around.
“The routing logic was the hardest part to get right. But once operators could see why a task landed on their queue, trust in the system went from zero to default.”
— Backend Architect
How I Led It
TASK started as a proposal that leadership initially saw as a productivity tool. The job of UX leadership on this project was to reframe it — to product, to engineering, to compliance, to executives — as operational infrastructure. The reframing happened through one demo moment that changed the conversation.
In the senior stakeholder demo, I walked through a single payment escalation flow end-to-end: routing, side-panel execution, embedded comments between the operator and their senior, audit-traceable approval. At the moment I showed the embedded comment thread *inside the task itself* — the back-and-forth that had previously lived in email — leadership got it. The room shifted. The project stopped being "a task tracker" and started being "the orchestration layer."
“The PoC changed the conversation. Before that, leadership saw this as a task tracker. After the demo, they understood it was operational infrastructure.”
— Engineering Lead
How I led the project
Operator shadowing → use case prioritization
Spent significant time embedded with banking operators, watching how they actually worked — the system-switching, the inbox-checking, the senior-update loops. The five-system observation and the "update senior, get feedback, repeat" insight came from this fieldwork.
Senior design at this level is grounded in shadowing, not surveys. Watching beats hearing.
Proof-of-concept demo that secured executive buy-in
Built an interactive PoC for the embedded-collaboration model before any production work began. The demo collapsed a multi-week alignment debate into thirty seconds of "oh, *that's* what we're building."
Tangible artifacts move organizations. Decks rarely do.
Cross-functional workshops across operations, product, compliance
Facilitated alignment sessions that brought operators, product managers, compliance officers, and the architecture team into the same room to map fragmented workflows into a single orchestration schema.
Pre-alignment is a UX deliverable. The design work that happens before design work happens is often the most important.
Acted as the bridge between operational reality and architectural logic
Worked directly with the architecture team to ensure the backend lifecycle systems correctly populated the frontend priority queues without latency — and that every routing decision the engine made was inspectable in the UI.
Trust patterns that only exist in the UI are decoration. Trust patterns enforced from the data model up are governance.
Set the patterns the rest of the suite later adopted
The interaction patterns established in TASK — task-as-source-of-truth, embedded collaboration, side-panel execution, transparent routing — became the operational language of the broader SBS banking suite. The Product & Pricing platform adopted TASK as its routing and notification backbone. Other modules followed.
Senior design leadership means raising the craft of every adjacent surface — by setting patterns others choose to adopt.
Knew when to kill my own designs
The colour-coded domain system was my initial proposal. When compliance pushed back, I revised. Senior design includes being wrong gracefully.
Owning a decision includes the decision to unmake it.
Platform Evolution
TASK was the second SBS-wide adoption from my work, after the Product & Pricing platform. Both followed the same pattern: design at the system level, not the screen level — and the platform consumed it as infrastructure, not as a feature.
Reflection
Platform Evolution
TASK proved that in enterprise banking, the most strategic UX work isn't making screens look better. It's designing the execution infrastructure that everything else runs on.
The real impact of TASK wasn't the velocity numbers, as good as they were. It was that the rest of the SBS suite started consuming TASK as a primitive. Product & Pricing routed approvals through it. Other banking modules adopted its notification model. The patterns it established — the task as the source of truth, the conversation living with the work, the routing logic being inspectable — became the operational language of the broader platform.
“I used to dread Monday mornings because of the task backlog chaos. Now the system tells me exactly what needs attention and why. I trust it.”
— Senior Compliance Officer
What I took away
Systems thinking beats screen thinking
A beautiful interface cannot fix a broken workflow. The most leveraged UX decisions on this project happened at the architectural level — before a single pixel was placed.
Workflow orchestration beats task management
The difference between managing tasks and orchestrating workflows is the difference between a productivity tool and enterprise infrastructure. The brief said the former. The work was the latter. Saying yes to the bigger problem was the project's most important leadership move.
Operator empathy beats stakeholder summary
The five-system shadowing observation and the "update senior, repeat" insight came from being in the room with operators. No stakeholder summary would have surfaced either. Shadowing is non-negotiable for enterprise design.
Killing your own design is a senior skill
The colour-coded system was elegant on paper and wrong in context. Compliance was right to push back. Senior UX work includes the maturity to let go.
Setting patterns is multiplier work
TASK's real impact wasn't the dashboard — it was that other products in the SBS suite adopted its interaction patterns. Design leadership at scale means building things that other designers choose to consume.
Enterprise UX creates the most strategic value when it stops being about how interfaces look and starts being about how organizations execute. Leading TASK taught me that the deepest design work is the kind that becomes invisible — absorbed into the platform as the way work simply happens.