01
Observe real work
Operational evidence
Service Desk workflows exposed hidden handoffs: Risk decisions were not consistently visible to the team responsible for the next action.
← Back to Case Studies
Investment Banking • UX Audit • Workflow Architecture • Prototype Design
Refactoring a complex money-processing tool around people, permissions, and control
An internal money-processing tool had evolved around technical constraints rather than the teams responsible for moving, reviewing, and approving funds. We audited the full operating model before refactoring the experience into a clearer low–mid fidelity prototype.
- ✓Mapped every stakeholder, permission, and cross-team dependency
- ✓Made approval and rejection states visible across departments
- ✓Reduced repeated checks and fragmented information access
- ✓Created an actionable product direction within legacy constraints
Context
Internal money processing within investment banking
Challenge
Fragmented workflows, unclear permissions, and hidden cross-team dependencies
Role
UX audit · Product strategy · Workflow architecture · Prototype design
Outcome
A role-aware refactoring concept grounded in operational reality
Outcome first
Business Outcomes
The work gave the organisation a structured basis for improving a business-critical system without separating interface decisions from operational risk, governance, or technical feasibility.
↑
Reduced operational ambiguity
Responsibilities, statuses, and next actions became easier to understand across Service Desk, Risk, and Operations.
↑
Strengthened control between teams
Approval dependencies were made explicit so one department’s decision could reliably trigger the next team’s work.
↑
Focused refactoring investment
Observed user friction and business risk created a clear priority order instead of a broad visual redesign.
↑
Improved readiness for scale
The proposed model supports increasing payment volume while reducing manual checking and avoidable coordination.
The business problem
The Challenge
The legacy tool supported a high-consequence process: identifying incoming payments, matching them to clients, reviewing risk, and routing exceptions between teams. Yet essential context was distributed across dense tables, separate panels, email, and individual knowledge.
Service Desk could not always see when Risk had rejected a payment. Risk users had to leave the main workflow to access client details or supporting evidence. Statuses, comments, logs, and actions did not consistently reflect the real relationship between departments.
The challenge was therefore not cosmetic. Refactoring had to improve productivity and clarity while preserving data dependencies, approval authority, and the technical behaviour of a live internal system.
"The interface could only improve once the operating model behind it — people, permissions, decisions, and handoffs — was made visible."
Operational Reality
◆
Fragmented ownership
Several teams touched the same payment without one shared view of its status or next owner.
◆
Hidden dependencies
A Risk decision could alter Service Desk work without generating a clear notification or state change.
◆
Slow investigation
Client data, comments, logs, and evidence required extra navigation and repeated checking.
◆
Legacy constraints
The experience had to improve without disrupting established processing logic and technical integrations.
Framing
Discovery & Product Definition
The audit combined business objectives, stakeholder interviews, role and permission mapping, observed workflows, interface review, and accessibility analysis. This connected visible usability issues to the operational rules causing them.
Key insight
Most friction came from coordination, not individual screens. Users needed the system to communicate what another team had decided, what evidence was available, and who could act next.
The refactoring therefore centred on workflow visibility and permission-aware actions rather than a surface-level visual refresh.
Stakeholder Mapping
Defined Service Desk, Risk, Operations, client, and banking actors together with their responsibilities and information needs.
Permission & Approval Logic
Mapped who could review, approve, reject, assign, refund, or escalate — including dependencies between departments.
Workflow Audit
Reviewed queues, payment detail views, handoffs, exception states, comments, logs, and supporting links with users.
Technical & Accessibility Review
Documented legacy constraints, low-contrast status signals, unlabeled actions, and layout inconsistencies that affected safe use.
Product strategy
Key Product Decisions
The proposed experience was organised around the decisions internal teams make, with each interface change tied to an operational or governance need.
Decision 01
Make cross-team decisions visible
Why it matters
Service Desk needed immediate confirmation when Risk rejected a payment rather than discovering it through manual checks.
Business impact
- ✓Clear rejection status
- ✓Less duplicate investigation
- ✓Faster customer follow-up
Decision 02
Keep essential context in the working view
Why it matters
Comments, logs, client links, and source information were part of the decision, not secondary reference material.
Business impact
- ✓Reduced navigation
- ✓Better-informed decisions
- ✓Stronger traceability
Decision 03
Align actions with permissions
Why it matters
Approve, reject, refund, and operations handoff actions had to reflect each role’s authority and the payment’s current state.
Business impact
- ✓Safer actions
- ✓Clearer ownership
- ✓More predictable handoffs
Decision 04
Refactor progressively around the legacy system
Why it matters
The proposal needed to improve hierarchy and workflow without assuming that core processing logic or integrations could be replaced at once.
Business impact
- ✓Feasible implementation path
- ✓Lower operational disruption
- ✓Prioritised delivery scope
System design
Defining the Solution
We translated the audit into a role-aware money-processing journey that brings the right context, controls, and handoffs into each decision point.
01
Map Stakeholders
02
Define Permissions
03
Trace Handoffs
04
Prioritise Friction
05
Prototype the Workflow
A structured path from operational evidence to a feasible refactoring concept.
Validating the workflow
Exploring the Experience
The audit connected real working practices with stakeholder needs, permissions, technical constraints, and accessibility findings — turning observed friction into a focused refactoring direction.
- 01Observe real work
- 02Map stakeholders
- 03Expose friction
- 04Define controls
- 05Prototype change
Keep decision context visible
02Keep decision context visible
Controls & accessibility
The audit showed where essential payment and client information could be surfaced directly in the working view, reducing repeated navigation and investigation time.
03
Expose accessibility risk
Inclusive operations
Contrast testing identified colour-only signals and low-visibility actions that could undermine safe, accurate work in a high-consequence financial process.
Define the right objectives
04Define the right objectives
Strategic alignment
Business goals connected system performance, automation, productivity, and workflow efficiency to a focused refactoring direction.
05
Map permissions and handoffs
Stakeholder model
Role, payment state, and cross-team approval determined who could review, comment, approve, reject, or route each case.
From evidence to a feasible refactoring direction
Selected evidence linking operational friction with business objectives, stakeholder responsibilities, and control requirements.
In the product
Final Product Experience
The low–mid fidelity prototype shows how the audited system could evolve without losing the operational density internal teams need. The result improves hierarchy and access to context while retaining the underlying payment-processing logic.
Screen 01
A clearer operational queue
Payments remain scannable at volume, while filters, assignment, status, matching information, source data, and client details are organised around daily review work.
- ✓Role-relevant filters and assignment
- ✓Payment status visible in context
- ✓Client information available from the queue
Screen 02
Decision context without leaving the workflow
Expandable payment rows expose suggested bank-account matches and additional information directly where the user evaluates the transaction.
- ✓Inline account suggestions
- ✓Clearer status and ownership
- ✓Less switching between views
Screen 03
A focused workspace for controlled action
The payment detail view groups deposit data, task state, matching evidence, comments, and logs so authorised users can review and route the case with confidence.
- ✓Actions aligned to the payment state
- ✓Evidence and history kept together
- ✓Cross-team handoff remains traceable
Role & ownership
Our Contribution
End-to-end product leadership — from discovery and strategy through workflow definition and delivery support.
◆Business Objective Framing
◆Stakeholder Research
◆User & Permission Mapping
◆Cross-Team Workflow Analysis
◆UX & Accessibility Audit
◆Technical Constraint Mapping
◆Product Strategy
◆Information Architecture
◆Low–Mid Fidelity Prototyping
Business outcomes
What Changed
✓A screen-level redesign became an operating-model refactoring
✓Stakeholder permissions and approval dependencies were explicitly mapped
✓Cross-team decisions became visible within the payment workflow
✓Client context, comments, logs, and matching evidence were brought closer to action
✓Accessibility and visual inconsistencies became defined product requirements
✓The organisation gained a feasible direction for progressive modernisation
The project turned a fragmented legacy experience into a clear, evidence-based direction for a more productive, controlled, and scalable internal money-processing system.
Lessons & principles
Strategic Takeaways
01
Internal tools are operating models
When several departments share a workflow, interface quality depends on how clearly responsibility and authority are represented.
02
Permissions shape the experience
Role access is not a technical afterthought. It determines what users can understand, decide, and safely complete.
03
Audit before refactoring
Observed work reveals the dependencies and workarounds that a screen-by-screen redesign would otherwise preserve.
04
Legacy modernisation needs focus
A strong concept improves the highest-risk decisions first while respecting the technical reality of the current platform.
Refactoring a complex internal product?
The highest-value improvements often sit between teams, permissions, business rules, and technical constraints — not inside a single screen.
We help organisations audit complex workflows and turn operational evidence into a clear, feasible product direction.
No long-term commitments. No generic frameworks. Just clear direction.