An internal banking platform built for Unit Trust transactions needed to expand — supporting bonds, structured deposits, structured notes, and insurance. The problem wasn't just adding new product journeys. The platform's core logic, screen structure, and actions were all shaped around how Unit Trusts were transacted. That model didn't scale.
A platform-level redesign across seven two-week sprints. The goal was not to make every product behave the same, but to create a system that feels coherent even when product rules differ — with a stronger overview structure, a scalable action hierarchy, and shared patterns that could support future growth.
The core challenge was scale. The platform had been built around Unit Trust behaviour — from the order structure to the overview page and the action buttons. As new investment products were introduced, those patterns began to break. Three issues became clear.
The project was scoped across seven two-week sprints, beginning with a full audit and assessment of the platform to understand what could scale, what needed redesign, and where the Unit Trust model would fail once more products were introduced.
This early phase focused on two things. First, understanding the impact of the new products with the business team — each product introduced different transaction rules, lifecycle needs, and display requirements. Second, reviewing the existing platform from a system perspective to assess which patterns could be extended, which needed a full redesign, and how a more scalable structure could be introduced without losing familiarity.
These discussions confirmed that the redesign needed to happen at platform level, not only at screen level.
Four principles guided the redesign.
The redesign focused on three key areas.
The original overview behaved like a long order feed — all order types in one scrollable page under separate sections. As more product types and order states were added, this became harder to scan and prioritise.
The redesign shifted the page toward a more structured workbench. Work was grouped first by transaction family — Buy or Switch orders, Sell orders, Order instructions — then narrowed further by lifecycle state. This created a stronger navigation model and a clearer mental model for future growth.
The redesign did not force all products into one generic table, nor did it split the experience into separate product silos. Instead, it introduced a common structural pattern across product sections, while allowing product-specific fields and transaction details where needed.
This was especially important because some products supported bulk actions while others did not. The interface needed to stay consistent without pretending all products followed the same logic. The shared structure helped the platform feel familiar even as transaction behaviour became more varied.
The action pattern was redesigned to create a clearer hierarchy. The previous design had accumulated tertiary buttons in inconsistent places as more products and states were introduced — making actions harder to scan and weaker in priority.
The redesigned approach separated primary, secondary, and utility actions more explicitly. This made the next step easier to understand and gave the platform a more scalable action model across different lifecycle states.
The work developed through repeated iterations across the seven-sprint timeline — briefing sessions with the business team, internal design critiques, regular reviews with the design head, walkthroughs to validate decisions, and check-backs with business stakeholders.
One example of negotiation involved checkboxes and bulk actions. These were originally kept only for Unit Trust, since other products didn't support the same behaviour. Later, they were added back to unify the display logic from a system perspective — agreed after negotiation, particularly after a separate scope intended to change the sell interaction model was dropped.
The redesign moved the platform away from a Unit Trust-shaped workflow and toward a more scalable investment transaction platform. Instead of extending legacy patterns one product at a time, the work created a stronger foundation for handling more product types and more complex transaction journeys.
The biggest learning was that scaling a banking platform is not only about adding new flows. It also requires redesigning the underlying structure that helps users find work, understand status, and take action with confidence.
It also reinforced that consistency does not mean forcing every product into the same flow. It means building a system that stays coherent while allowing product-specific rules where they are needed.