Shared Parental Leave (SPL) Scheme
UI/UX Design · Public Portal & Officer Intranet
Nov 2023 – Mar 2025
Overview
The Shared Parental Leave (SPL) Scheme is part of Singapore’s Government-Paid Leave System (GPLS), a platform that enables employees and employers to manage and submit government-supported leave claims.
Updates to the SPL policy required the rollout of a new scheme to replace the existing 2013 version, introducing revised eligibility rules and claim workflows. This meant the GPLS platform needed new experiences across both the public portal and an internal officer intranet used for processing and managing submissions.
The goal was to translate complex policy requirements into clear, structured digital workflows that support multiple user roles.
In this project, I designed high-fidelity user interfaces and workflows for both the public-facing portal and the internal officer system, ensuring the experience remained consistent, intuitive, and aligned with the existing GPLS platform.
Team
Product Owners
Business Analysts
Engineers
My Role
UX / Interaction Design
UI Design
Prototyping
Developer Handoff
User Stories & Documentation
The Challenge
The updated Shared Parental Leave (SPL) scheme introduced new policy rules and eligibility scenarios that needed to be integrated into the existing GPLS platform. This process involved multiple stakeholders and user groups — including employers, parents, and MSF officers — while coordinating data across interconnected systems such as ICA and LifeSG.
The challenge was to translate these complex policy requirements and cross-system dependencies into clear, structured workflows and interfaces that could support different user roles while ensuring SPL claims could be submitted, reviewed, and processed accurately and efficiently.
SPL Claim Process
Employers & Employed Parents
Parents first configure their SPL Sharing Arrangement (SA) in LifeSG. Employers then verify eligibility and leave sequence before submitting claims through the GPLS portal. MSF officers review and process these claims through the internal Appian system.
Self-Employed Parents
Self-employed parents follow a similar process but submit their claims directly through the GPLS portal instead of through an employer. MSF officers then review and process these cases through the Appian backend.
Design Approach
Understanding the System
When I joined the project, I began with knowledge transfer sessions with frontend and backend engineers to understand the end-to-end workflows of GPLS. I also consulted QA engineers, who had a strong understanding of how the different schemes and processes worked across the platform.
To familiarise myself with the product, I reviewed the existing GPLS designs in Figma and studied the workflows for the 2013 SPL and other leave schemes. This helped me understand the established interaction patterns and ensured the new SPL flow would remain consistent with the rest of the platform.
Based on these workflows, I designed high-fidelity UI screens in Figma that translated the policy requirements and system logic into structured interfaces for employers, employed parents, self-employed parents (SEPs), and officers.
Iterative Design with Product and Engineering
The team worked in two-week Agile sprints, where user stories and designs were discussed during backlog refinement and sprint planning sessions. Throughout the process, the designs evolved iteratively as policy requirements and workflows were clarified. To keep sprint discussions productive, I prepared UI designs and drafted related user stories ahead of backlog refinement and sprint planning sessions, checking in with engineers beforehand to ensure the proposed interactions were technically feasible.
Supporting Development and Implementation
Once designs were ready for implementation, I continued collaborating with engineers during development to clarify interaction behaviours and address any questions that arose. I supported the implementation process by ensuring that the intended design logic and workflows were clearly understood before deployment.
Key Design Decisions
Designing for Multiple Users and Interconnected Systems
Design Challenge
Sharing arrangement data could originate from multiple sources aside from LifeSG, including ICA data broadcasts or officer-created cases, requiring the system to reconcile and process these records consistently.
Claims could also originate from different entry points, including employer submissions, self-employed parent claims, or officer-created cases. The system also needed to support adjustment scenarios where claims or sharing arrangements required updates after initial submission.
Design Decision
To manage this complexity, I mapped the end-to-end flow across systems and user roles to understand how information flows between LifeSG, GPLS, and the officer processing system in Appian.
The interface design was structured so each user type — employers, employed parents, self-employed parents, and officers — sees only the actions relevant to their role, while maintaining consistent data across systems and supporting adjustment scenarios when SA cases and claims required updates.
Outcome
The SPL workflow supports multiple user scenarios while maintaining a clear and predictable process for each stakeholder. This ensured that information submitted through LifeSG, GPLS, or officer-created cases could be reliably processed.
Aligning the New SPL Scheme with Existing Leave Schemes
Design Challenge
The GPLS platform already supports multiple government-paid leave schemes. Introducing the updated SPL scheme required ensuring the new flow remained consistent with existing system patterns while accommodating updated policy requirements.
Design Decision
I reviewed existing leave scheme designs within GPLS and reused established interaction patterns where possible, ensuring the new SPL flow remained familiar to employers and parents already using the system.
Outcome
Maintaining consistency across schemes reduced the learning curve for users and allowed the updated SPL process to integrate seamlessly into the GPLS platform.
Translating Policy Rules into User Flows
Design Challenge
The SPL scheme included various policy rules and eligibility requirements that needed to be translated into structured digital workflows. These included scenarios involving adoptive parents, single parents, and rules tied to the child’s date of birth (DOB), formal intent to adopt (FIA), estimated due date (EDD), and the four-week post-birth window for adjusting sharing arrangements.
Design Decision
I worked closely with product owners and engineers to translate these policy requirements into structured user flows and interface logic. I designed conditional fields and validations so the interface would dynamically request only the information required for each scenario.
Outcome
This ensured the system could capture the required policy data while keeping the submission flow clear and straightforward for users.
Interface Design
Public claim submission
The public-facing portal guides employers and self-employed parents through submitting SPL claims based on the configured sharing arrangement. The interface was structured around milestone-based steps to help users verify eligibility, confirm leave sequences, and submit claims with the required information. You can explore the experience here:
Officer processing interface
MSF officers process submitted claims through the Appian intranet. This interface was designed to surface key claim details, eligibility conditions, and supporting information in a structured layout, allowing officers to quickly review submissions and take appropriate actions such as approval, adjustments, or follow-up checks. Interface details have been blurred for confidentiality, but the screens are included to illustrate the officer processing workflow.
Impact & Reflection
Designing within a complex government ecosystem
This project pushed me beyond my previous experiences, requiring me to understand the GPLS platform end-to-end while also considering how it interacted with other government systems. The ecosystem itself also evolved throughout the project. For example, the SPL Sharing Arrangement (SA) component was eventually moved from GPLS to LifeSG, requiring the team to continually adapt the system flows and interactions.
Through this process, I developed a stronger systems-thinking approach when designing features that span multiple platforms and stakeholders.
Becoming a bridge between teams
As the project progressed, I became one of the reference points for understanding the overall SPL claim flow. While frontend and backend teams were often focused on their respective areas, I had developed a broader view of how the entire workflow operated across systems.
This allowed me to help clarify flows and scenarios when questions arose, ensuring that design logic remained consistent across both the public portal and the internal officer system.
Designing with deeper scenario thinking
During this project, I also began writing user stories alongside my UI designs. This practice helped me think more critically about different scenarios and edge cases that could arise during claim submissions and adjustments.
It also improved communication with product owners and engineers, as the design intent and interaction logic were already captured in the accompanying user stories, helping align discussions during sprint planning and development.
This experience strengthened my ability to design within complex, evolving systems while balancing user needs, policy requirements, and technical constraints.
