Keeping iPension coherent across products and teams
Three years keeping a distributed pension software suite consistent from design to delivery.
Context
iPension is a modular software suite spanning all three pillars of the Swiss pension system. Its product landscape connects portals, core business applications, and services with other systems around them. During my time on the product, the suite included more than twelve applications across desktop and mobile.
The product was being built by a large distributed organization across Switzerland, Vietnam, and Mauritius. The design team itself was small compared with the wider engineering and delivery organization, which made consistency difficult to maintain as the suite grew.
I worked on iPension for about three years, until I left ELCA. I joined as a UI/UX Designer, but over time a large part of my job became keeping the design work coherent across products, teams, and implementation.
My role
I worked closely with designers in Switzerland and Vietnam, while supporting delivery teams across Switzerland, Vietnam, and Mauritius.
My work went beyond designing individual flows. I defined shared standards and processes, owned and maintained the UI library, reviewed design and implementation quality, onboarded designers joining the project, and ran UX and UI training for colleagues across all three countries.
I also became a regular point of reference for BAs, engineers, QC, delivery, and product stakeholders when questions came up around interaction behavior, UI patterns, or design decisions.
The product was larger than any one workflow
iPension was not one application with one main journey. Different parts of the suite handled different pension workflows, user groups, documents, financial processes, and administrative tasks.
That meant a good solution inside one application could easily become a new inconsistency somewhere else.
A large part of the work was therefore not about finding a clever solution for one screen. It was about making sure the same interaction problem did not get solved twelve different ways.
Keeping the suite coherent
We maintained a shared UI library long before “design system” became the common label for this kind of work.
The library covered reusable components, interaction patterns, visual rules, icons, and other design assets used across a suite containing thousands of screens and hundreds of UI components.
I owned and maintained that foundation and worked with BAs and technical teams on information architecture, concept models, functional specifications, wireframes, and prototypes when new parts of the product were introduced.
The same standards extended beyond components and layout. I also worked on UX content, French and German translations, and accessibility so the experience remained coherent across applications, languages, and users.
Design, implementation and delivery
A shared library only helped if the implemented product behaved consistently, not just the design files.
I stayed involved through development, reviewing UI behavior and implementation with engineers and working with QC on test cases, UI review reports, usability checks, and accessibility.
When recurring implementation problems appeared, I also ran training sessions with designers and development teams. The goal was not to make everyone a designer. It was to give people enough understanding to make better decisions before something reached a design review.
That reduced repeated UI implementation mistakes and the amount of engineering time spent fixing them afterwards.
Working across three countries
The product was being delivered across Switzerland, Vietnam, and Mauritius, while the design team remained relatively small.
Designers also joined and left the project over time. I helped onboard new designers, reviewed their work, clarified existing patterns, and gave them enough product context to contribute without having to rediscover the same decisions from scratch.
I also worked directly with BAs, engineers, QC, delivery, and product stakeholders. Over time, UX became part of those discussions rather than something that happened after requirements were already finished.
What became reliable
Design could support multiple teams across three countries without becoming a delivery bottleneck.
New designers joined an established set of patterns, standards, and ways of working instead of starting from zero. Engineering and QC also had a clearer reference for expected UI behavior and implementation quality.
The training reduced recurring implementation mistakes and the rework that followed them, saving developers a meaningful amount of time across delivery.
Over time, UX became a trusted point of reference across product, BA, engineering, QC, and delivery. The client consistently gave positive feedback on both design quality and delivery.
Reflection
I didn't think of this as building a design capability at the time. We had a large product, teams across three countries, designers coming in and out, and a lot of software to ship. Someone had to keep the work coherent.
Over time, that became a bigger part of my job than designing individual screens.
Looking back, this was probably where I learned what leading a design function actually meant.