Channels UI Platform

I had watched the problem develop over several years. Teams repeatedly built similar components and solved the same channel problems in different ways. Corporate banking had developed a mature application framework and integration model. Personal banking had a stronger component library. Individual applications had created further local solutions, often interpreting the bank’s visual identity and shared channel responsibilities differently.

The cost went beyond duplicated engineering. Each local decision made the customer experience less coherent and the next integration harder. Technical debt accumulated while applications became more isolated from one another.

A reorganisation created an opportunity to address this structurally by bringing several shared channel capabilities into one organisation. My product was the UI platform through which customer-facing applications could use those capabilities and behave as parts of the same bank.

I did not begin by choosing one existing foundation and declaring it the winner. I worked with architects, designers and engineers to compare what had already been built, what had proved useful, and which assumptions belonged only to the product or channel that had created them. The corporate channel supplied mature platform concepts; personal banking contributed a more developed component foundation. The product work was to turn those assets into a proposition that neither side experienced simply as the other channel’s technology.

We worked through the product boundary in design sessions, architecture discussions and conversations with the teams expected to adopt it. Which parts of navigation, identity and channel context should every application inherit? Which interaction patterns needed to remain consistent? When was a component genuinely reusable, and when did it belong to a particular workflow? What should product teams be able to rely on without asking the platform team for help?

Every answer moved responsibility between the shared platform and the application. If the platform owned too little, teams would continue rebuilding the same foundations and customers would keep encountering different versions of the bank. If it owned too much, it would constrain specialist products and force teams through a central backlog for decisions that properly belonged to them.

My role was to keep that boundary useful rather than theoretically pure. I sat with engineers shaping the framework and SDK, designers establishing how the shared identity should behave across products, and consuming teams testing what the proposed boundary meant for their own delivery. The aim was to standardise what created trust and continuity for customers while preserving freedom where product difference created value.

The resulting platform combined a shared UI foundation with simplified access to common channel capabilities. It gave teams a stable starting point without attempting to design their applications for them. The underlying product problem was not whether separate systems could connect. It was whether independently owned products could still feel as though they belonged to the same bank.

Teams needed to understand what the platform provided, how to begin using it, which decisions it made for them and what remained theirs to control. If adoption depended on knowing someone in the platform team and arranging a series of meetings, we would become a permanent support function rather than a scalable internal product.

I led the creation of a platform portal that brought the proposition together in one place. It combined onboarding guidance, documentation, examples, design principles and contribution guidance. We treated it as one of the product’s principal interfaces, not as an appendix to the technical work.

I worked with designers and engineers to make the guidance useful in practice. It needed to explain not only what a component or capability did, but when to use it, how it behaved and how it supported the wider customer experience.

Much of my work also involved taking the platform to product teams across the bank. I presented the proposition, worked through integration questions, collected objections and adjusted the roadmap around what we learned. These conversations exposed problems that were easy to miss from inside the platform team. Sometimes a capability was missing. Sometimes our documentation assumed too much. Sometimes resistance reflected a genuine loss of product autonomy rather than poor communication.

Adoption therefore became part of product discovery. The teams questioning the platform were also showing us what it needed to become.

A shared platform could reduce duplication and fragmentation, but a conventional centralised model risked creating another problem. If one team controlled every component and every change, it would quickly become a bottleneck. Product teams would wait, work around the platform or begin creating local alternatives again.

I pushed for an internal open-source model built around shared direction and distributed contribution. The platform team would remain responsible for the product’s direction, architecture, design coherence and release quality. Teams building on the platform would help shape its roadmap and could contribute improvements when their own work exposed a gap in the shared foundation.

My responsibility was to define the customer-side rules around that compromise: which identity, permissions and context the shared platform should preserve; how customers would enter and leave an embedded service; and where inconsistency could be tolerated without breaking the sense of one channel.

We modelled and documented how teams would identify a need, shape the proposal with the platform team, contribute the improvement and share the result more broadly. The intention was collaborative stewardship, not a central review board approving other teams’ work. The platform team protected the value of having one foundation; consuming teams brought the experience and needs that allowed it to evolve.

The technical workflow was only the mechanism. The product decision was that useful work should flow back into the shared platform rather than remain trapped within one application.

This placed the platform between two unhelpful extremes. It was neither a central standards group policing everyone else’s interfaces nor a loose collection of libraries that teams could reinterpret until little remained in common. Teams retained responsibility for their products while participating in the foundation they shared.