Dependant's Pass/ Long-Term Visit Pass application
Background
Employers (HR professionals) and employment agencies (EAs) have been using the EP Online (EPOL) system from the Ministry of Manpower to apply for work passes. My project office was set up to build a new work pass system to improve the current experience and replace EPOL.
One of the main work pass transactions that HR and EA do on EPOL is the application for a Dependant’s Pass or Long-Term Visit Pass (DP/LTVP). These are legal stay passes that allow the spouses, children and parents of Employment Pass or S Pass holders to stay in Singapore. These passes have qualifying criteria which only if met, can the foreigner be considered for the pass.
My role
Interaction designer
-
Designed the user flows and interactions
-
Conducted usability testing to assess usability for key tasks in the form
-
Worked on content, copy, alerts and validations
-
Worked with PO, BAs, developers and QE during development to ensure design implementation and to work on other edge scenarios that were surfaced
Challenges users faced with the legacy system
User research was conducted by a different designer before I took over the project. The research surfaced the following challenges with the Dependant’s Pass and Long-Term Visit Pass forms in the legacy system:
-
As the Dependant’s Pass and Long-Term Visit Pass are both legal stay passes for dependants, users sometimes apply for the wrong pass. E.g. An employer applies for a Dependant’s Pass for a parent of a foreign worker, when in fact, the employer should have applied for a Long-Term Visit Pass based on the qualifying criteria. Applying for the wrong pass results in a rejection outcome and also wasted time and money for the employer.
-
Users need to fill in the steps in the form sequentially. If they hadn’t completed step 1, they could not move on to step2. This does not give them the flexibility or choice to fill in other parts of the form.
-
Users are asked to fill in information that are not relevant or that they do not have on hand.
From these research findings, we derived this problem statement:
How might we create an application form that is easy to fill and sets users up for a successful outcome?
Design strategy
To solve the problem statement, we adopted three strategies for the design:
-
Remove the burden for users to recall which pass type they should apply for and let the system direct the users to the correct legal stay pass. This would help to reduce the user’s cognitive load and direct them to the right application based on the dependant relationship to the main pass holder.
-
Give the user the flexibility to fill in the information sequentially or non-sequentially so that they can complete the form quicker.
-
Guide the user in filling in only relevant questions and don’t show non-essential questions.
UI design
Step 1 of the application form is the ‘Identification’ step. In this step, the system will identify if the candidate is suitable for a Dependant’s Pass or Long-Term Visit Pass based on the answers given by the user.
The form design uses progressive disclosure to only show users the next relevant question based on the answers given in previous questions. This reduces the user’s cognitive load as they can focus on one question at a time, and helps them fill in the form quicker as they are only shown the necessary questions.
The first question we ask is the foreign identification number or the application number. When the user enters the FIN or application number, the system would check if we have this candidate’s records in our database and display their identification information. This gives the user the confidence that they are submitting the application for the right person.
One of the pain points users faced was that they would apply for the wrong pass type when using the legacy system e.g. applying for a Dependant’s Pass when they should be applying for a Long-Term Visit Pass, as the forms were separate and the criteria similar for both legal stay passes. However, the relationship of the dependant to the main pass holder was a key deciding factor in which pass they were eligible for. With this in mind, we included a question on relationship, to let the system determine which pass type the user should be applying for. This design decision frees up the burden of recall from the user, and saves cost of administrative fees by preventing the user from mistakenly applying for the wrong pass.
I also designed system validations such as the warning message displayed in the above visual, to inform the user on the likelihood of a successful or unsuccessful outcome. This sets the user up for success and gives them the opportunity to amend their application details where needed.
After the user has filled in the necessary questions in the ‘Identification’ step, the system would inform the user on the pass they would be applying for based on details given.
When the user clicks the ‘Continue’ button, the system would route the user to the correct application form, in this example, the Dependant’s Pass application form.
In step 2, ‘Application’, the user would see that the title of the form has changed according to the relevant pass that the system has identified for the user.
The first accordion is expanded by default for the user and the user needs to fill in the candidate’s key passport details so that the system can check if the passport details are stored in the system database. If the candidate’s passport records are found, the user can skip answering certain questions (and consequently eliminating the possibility of data entry errors), and the user also does not have to submit a scanned copy of the passport. This helps the user save time and makes it easier for them to fill in the form.
If the candidate’s passport records are not found in the system, the user is prompted to upload a copy of the passport for the ministry’s verification of identity. After the scanned copy of the passport has been uploaded, the system shows the user a preview of the passport next to the application questions. This preview helps the user to fill in the passport details as they have the visual to check against to ensure that they have not made any data entry errors.
After entering the dependant’s the passport details, the user has the flexibility to fill in the other questions non-sequentially.
Accordions are used in the design to show/hide sections where needed.
Validations have been built on clicking the “Continue button” to check if the required questions in each section has been filled in before submission.
Step 3 of the form is the Summary which helps the user check through all the information they have entered. We retained the concept of a Summary step from the legacy system as our users were used to checking all the information they had entered before proceeding to payment.
An enhancement we had built in the new Summary design was to have edit functions for each section. On clicking “Edit”, the user is brought to that specific section in step 1 or 2 to correct any errors they spot while checking.
Step 4 is the payment step where the user needs to make payment for the application. As each application costs SGD 105, we wanted to prevent errors and set the user up for a successful outcome.
The transaction ends with an acknowledgement page which gives the user system feedback that the ministry has received their application. We include key information like how soon the user can expect an outcome for their application. We also built a function where the user can download the acknowledgement and summary of the application for reference.
