UX/UI Design, Responsive Web-App Development
Self service client portal - pension company
the idea
At the time of writing this, I am employed at a company that manages the pensions of an organization. The company wanted these beneficiaries to have more freedom over their own transactions, and wanted to give the users the ability to manage their own pension, health, and life insurance plans. Up until the last 5 or so years, these beneficiaries had to call and speak with representatives at our company, whom would compete the transactions for them. This meant that every time a user needed to do something as simple as add a dependent to their plan, they had to do it over the phone.
The goal of inventing this self service portal from scratch was to modernize the experience, and to empower our users to have more control over their plans. At the start we had two main sectors of our user base, we had Administrators who would need to manage the plan selections and offerings of their institutions or groups of institutions, and we had the employees themselves, who were a part of the institutions, and needed the ability to manage the plans of themselves and their dependents. This would require us to build two separate but linked self-service portals for the two user groups.
The Mvp
The rollout of these products was done in stages, with only essential functionality being released with our MVP, and a plan for new features to be rolled out in subsequent releases. Before the release of these products we were completing 100% of user transactions over the phone. With each release there was an internal goal set to have XX% of transactions now take place using the self-service systems, increasing the percentage with each major release.
At the point which I was brought on, we were targeting for 90% of transactions to take place through the online portals. I will go into more details about some recent release stages and what features we have added in the next section, but I just want to note that at the time of writing this our users are completing 96% of their transactions using the self-service portals.
recent feature releases
In 2024 we spent a solid portion of the year implementing two major features dubbed “Life Events and Mid Year Changes”.
These features centered around giving our users the ability to implement changes to their plan selections themselves as their lives and beneficiaries changed throughout the year. Previously, if a change had to be made to a users selections outside of Annual Enrollment periods, it had to be done still over the phone with the assistance of one of our representatives. With this release, changes such as a marriage or dissolution of marriage, birth or death of a child, or a multitude of other scenarios centered around changes to a user’s beneficiaries could now be submit in a much simpler way within the portals. We were aware that this previously cumbersome process was adding stress to often already stressful or busy time in our user’s lives, and in bringing this feature into their control, we hoped to ease some stress, and clarify that they are in fact in control of their own lives ups and downs.
At the time of writing this we are spending time releasing a feature that allows our Administrator users to manage their billing entirely online. Previously this process had to be done either via an antiquated and clunky application, via “snail-mail”, or via a phone transaction. These bills that our Administrators manage can vary in purpose greatly, from employee pension and health bills, to institution level property and casualty insurance bills. In bringing this process online we intend to simplify the payment process, limit the number of applications our users must access to manage their work, and also to digitize the process for accessing historical bills invoices.
the process
Our product releases follow an agile methodology, leveraging Scrum to structure our development cycles in sprints. Within this process, I represent the UX team as our primary UX/UI designer and user researcher.
At different stages, I conduct interface development, working closely with business representatives, stakeholders, product owners, and engineers. At other stages, I lead user testing interviews, collaborating with our client relationship managers to gain access to selected users from our client base and evaluate the usability of our products.
We typically operate within two-week sprint cycles, requiring near-constant collaboration and rapid iteration on designs to meet evolving functional requirements and user feedback.
A critical aspect of the release process is both internal and external education. Leading up to a release, I work closely with our external communications team to develop messaging for clients, ensuring they understand upcoming changes and how to navigate them. Internally, I conduct product walkthrough meetings to explain new features and the rationale behind them. Additionally, I focus on ‘socializing’ new releases within the company by hosting walkthrough sessions with key department representatives, ensuring all involved teams remain aligned and informed.
challenges and adjustments
The process definitely wasn’t perfect from the start, and I have learned from previous release mistakes. A constant willingness to learn and grow have driven my evolution in the role, and have led me to become a trusted member of the team and a SME (subject matter expert) along the way.
One of the biggest challenges I faced personally was during the onboarding process. To contribute effectively to the team, I had to not only learn the inner workings of the company’s systems but also understand how an organization offers and manages benefit plans for its employees. I had no prior knowledge of the often opaque insurance process, let alone how a company administers and distributes offerings from a pension fund. To bridge this gap, I leaned on my teammates and actively reached out to business and departmental representatives to educate myself. Over time, I built a strong internal network of people I could turn to when specific issues or questions arose.
Another early challenge was developing an efficient communication strategy, both internally and externally. As a team, we recognized the need to inform users about changes to the system. However, we quickly realized that relying solely on email and public-facing website announcements left some users uninformed. In hindsight, we were designing based on our assumptions rather than direct user feedback.
To address this, we conducted user interviews to gather insights on their experience with the applications. A common theme emerged: users wanted a more guided process for completing transactions, especially when attempting something for the first time. We knew we had to strike a balance between providing assistance and empowering users to navigate the system independently.
From this insight, we developed GPS (Guided Process Support)—a dynamic, on-page support system designed to communicate important messages and instructions to users in a consistent, non-intrusive way. This designated area provided contextual messages, instructional documentation, and relevant links tailored to the process being completed on the screen. The goal was to create a predictable point of reference for assistance while ensuring experienced users could proceed without unnecessary interruptions.
Following the release of GPS, we observed a significant increase in self-service transactions, as well as improved client satisfaction, as reflected in user surveys.