Case Study / Product Design + UX / Private Banking
Reframing Private Banking
Portfolio Analysis Workspace
Case study introduction
The brief looked like ~7 screen adaptations. The real problem was a connected product system.
The work was part of a broader Azqore private-banking back-office product modernisation, delivered through Capgemini, centred on a Portfolio Management System used by Relationship Managers to inspect portfolio positions, performance, movements and related analysis across client portfolios. This case study focuses on this wealth-management back-office product’s portfolio-analysis interfaces, UX design and the interaction model that connected them. What looked like a screen-led UI refresh became a broader product-design problem: preserve portfolio context, support many task paths and keep dense analysis coherent within one workspace.
- Context:
- Private banking portfolio management back-office system
- Engagement:
- Capgemini with Azqore
- Role:
- Senior UX Consultant · primary hands-on Product Design + UX
- Focus:
- interaction architecture · scope selection · filters & dense data · implementation support
- Collaboration:
- Product · Design · Domain SMEs · Engineering
- Confidentiality:
- NDA-safe synthetic reconstruction; proprietary structure, terminology and data are re-authored.
01 / 06
Beyond the Screen Brief
The initial project brief was framed as roughly seven screen adaptations. The first UI pass looked plausible, but product-review questions exposed interaction logic the screen brief could not answer.
I stepped back from surface treatment to redefine the working context, scope and structure before returning to detailed UI.
If RM work crossed screen boundaries, what had to stay constant?
02 / 06
One Workspace, Many Paths
The design response was a contextual workspace: establish portfolio scope first, then navigate across Overview, Holdings, Performance and Transactions without losing the working context. Shared filters, charts, tables and drill-downs supported different investigations across these functions.
These four areas were functional anchors, not prescribed workflows. RM task journeys could branch, intersect and revisit the same information without requiring a dedicated screen for every path.
The central design question became: what needed to persist as the task changed?
Before analysis could begin, what exactly was the scope?
03 / 06
Establish the Right Scope
A portfolio reference was only the starting point. The system first fetched the associated context, then let the RM inspect and select the relevant nested entities and relationships.
Separate single- and multi-selection variants became one adaptable selector. Done confirmed the selection within the control; Validate committed the broader scope and loaded the analysis context.
The explicit Validate step reflected a real system boundary, not a decorative form pattern.
Once the scope was right, the next challenge was consistency across dense analytical work.
04 / 06
One Interaction Language
One workspace had to support many analysis permutations. Filters and dense tables could not remain a collection of one-off solutions.
Reusable Filter Patterns
Filtering requirements were grouped into reusable behaviours: search, choice, range and include-or-exclude.
In this PMS context, one filter instance works as Include or Exclude; multiple instances can be layered when needed, with selected values kept visible as removable states.
Hierarchical Data Tables
Expandable hierarchy already existed; the redesign made its depth easier to read. Indentation, disclosure, typography, row treatment and contextual actions gave each level a clearer information hierarchy.
The contribution was not inventing hierarchy, but modernising how it behaved and communicated depth inside the workspace.
These shared interaction patterns then needed to be validated against real implementation constraints.
05 / 06
From Prototype to Implementation
The low-fidelity prototype deliberately focused on interaction structure: persistent context, functional switching and the main analysis area could be reviewed before detailed data and visual polish.
Once the interaction model was agreed, the work moved into the shared banking visual foundation, technical review and implementation support.
Shared Design Foundation
Earlier in the wider modernisation, I helped study, curate and adapt the mandated Société Générale Design System (SGDS), an in-house, Bootstrap-based design system, alongside the design team.
PMS/IPMS extended that foundation with more advanced scope-selection, filtering and dense-data interaction patterns.
Implementation Constraints
I worked with technical leadership and engineering to assess front-end feasibility and interaction behaviour. Where necessary, richer design states were simplified to fit the implementation environment, including chart rollover behaviour constrained by AMCharts.
Delivery status: Design-approved and supported through implementation during my involvement.
Full final production completion was outside my verification window.
06 / 06
What Changed
Across problem framing, interaction design and technical review, the work converged on a more coherent portfolio-analysis model. Four connected changes define the design direction supported during my involvement.
My contribution was to connect the original screen-led brief to a coherent, reusable interaction model and support its feasibility through implementation.