Employers have a portal in the scheme where they are required to perform their legislative duties.

One of these duties is to submit long service leave applications on behalf of their employees.

The long service leave application process is currently extremely manual, involving a paper form that gets scanned uploaded to a portal. Then a staff member will manually input the details into the CRM system, and gets processed from there.

The ambition of this project was to digitise the forms, to reduce manual input and decline rates due to inability to validate.

Create a workflow and method allow users of the portal to:

Since we did not have scope for discovery sessions with users; we had to look to business SMEs for initial discovery.

Talking to staff who regularly interacted with our users (both employers and employees) was incredibly insightful. This included members from the call center, leave processing, and engagement teams who were able to deliver a comprehensive list of needs for a prototype and initial journey of the process.

As we were planning on taking this to users, it was great for forming our initial hypothesis about the requirements.

‍

Extremely siloed and undocumented processes made validations/requirement gathering difficult

In addition, there were 20 internal stakeholders involved in this process to either gain SME knowledge or approvals.

‍

My strategy for navigating this:

• Involving everyone in the process was crucial for gaining support and ensuring the solutions were well-received.
• Have the Figma file set-up right, which enabled changes to be made instantly. Stakeholders said they really appreciated seeing this.
• Visual communication is everything! Having interactive workshops was a good way to gain consensus regarding requirements.

Our employer base is extremely varied, ranging from companies with 10,000+ employees to 1.

Designing this interface meant we had to accommodate flows that could handle the range of applications also while reducing data redundancy.

We had 2 initial options for the flow:

1. Initiate flow on selection of employee: This would means that it would be a singular flow for each application.

2. Initiate flow on selection of application type: This would allow for a more streamlined flow for bulk applications.

Both approaches would work but we needed to look at user data to confirm what would be the ideal approach.

• We know that 60% of the applications are for in-service applications
• The amount of leave applications submitted daily fluctuates between 1-30

This means the flow had to take a versatile approach, hence I went with option 2 due to the ability to create multiple of the same types of application.

The rest of the set up was simple, however some UX challenges when designing forms were:

• For complex forms, ensuring that edge cases are captured and there is resolution for the user who encounters it but does not clutter the interface.
• Most best practice says that progressive disclosure is ideal, however this does not apply to specialised form UX. Our users need to go through this as quickly as possible and use the form multiple times per session.

We tested the prototypes with a range of employer profiles across the country

Six employers across four states, including Payroll, CFO, and HR officers from organizations with 20 to 500 employees, participated in one-hour remote sessions.

These sessions involved discovery discussions on current workflows and task-based prototype testing.

Generally the prototype was accepted, most of the feedback being around other parts of the system that were not in scope or remit for the project.

The System Usability Scale (SUS) had an average score of 70.3 indicates above-average usability, reflecting a positive user experience.

Creating an in-service application (1/3 application types)

We needed a new leave application homepage where users could easily search, sort by type and application status.

Due to digitising, we needed quick actions to allow cancellations, in addition to easy access to employee information.

This is an run through of 1 type of application, there are two other application types (cessation and entitlement).

‍

Conflicting application error

The ability to digitise this process has ensured an enhanced experience for both our users and staff.

By reducing the constant back-and-forth and leaving more flexibility to the user on how they would like to control the process by removing the paper form has had a tremendous impact.

Despite restrictions and legislative boundaries, we were able to achieve improved outcomes for both the business and users.