How one of the world’s largest banks rebuilt retail onboarding — and scaled the team that did it from one squad to a programme.

The client is one of the world's largest banks, serving more than forty million customers across over sixty-five countries. Its retail onboarding journey was slow and fragmented — heavily dependent on branch visits and manual back-office work.
I worked with the Global UX team and delivery squads to shape the user experience for global originations and help lay the foundation for the design system the teams would build on. Together with designers, engineers, and product leads, I turned complex onboarding requirements into journeys that were clearer and faster for the customer.
As the work proved itself, I helped scale it from a single cross-functional team into a multi-team programme — more than 150 people across six offices — with shared standards and governance. The thread through all of it was keeping the customer's voice present in a programme large enough to lose it: shaping the end-to-end journey, and making sure the design system was the thing that let delivery move at scale.
A design system earns its place the day a team ships without asking permission.
We started with user research, looking closely at where customers dropped out and what stopped them finishing. Three problems did most of the damage: the journey required a branch visit, it leaned on heavy back-office data entry, and approval and processing times ran long.
So we redesigned the journeys to remove the steps that did not need to exist, replaced manual checks with digital ones, and built a design system that let regions deliver quickly and consistently.
Because the system was built from coded components, anyone could pull real code to prototype and test with the actual elements — which made usability and accessibility testing far more reliable. In a live banking service, that matters. We put ongoing user testing and live-product analytics in place, so each team could keep learning from live use.
A design system only scales if people keep choosing it — including after I step away. So alongside the components and tokens, we built a community of practice: the people, rituals, and shared agreements that carry it forward across every region.
We brought that community together in person for the first time — designers, engineers, and product leads from across the programme — and used the gathering to agree the three models that decide whether a system survives contact with a large organisation:
A design system was how delivery scaled without losing coherence. In my AI work the same question returns at a new altitude: shared, reusable foundations — knowledge, patterns, governance — that let many teams ship without asking permission.
Onboarding conversion moved because the journey was rebuilt end to end, not because a screen got tidier. If that is the shape of the problem in front of you, I would like to hear it.