Paid time off
(reading time ~ 10 minutes)
An integral part of any payroll system is to ensure not just worked hours are logged within the product, but also any time off, paid or otherwise.
The RUN payroll product I worked on at ADP had Paid Time Off (PTO) functionality, however, the UI had not been updated since its inception, almost a decade previously, before we had a UX team. This particular feature was generating just over 45,000 calls to our service centre, costing ADP nearly $1.5 million a year due to users not being unable to understand how to log time off and being unfamiliar with the terminology used. It should also be noted that only around 14% of users were payroll or HR professionals - the rest were mainly small business owners.
This project was to reimagine how we presented and facilitated the logging and subsequent payroll processing of PTO within RUN to aid the key strategic objective of reducing service calls.
Initial discovery research
As we were reimagining the paid time off journey, we decided to utilise Double Diamond for our discovery. This would enable us to release an MVP and then future iterations we could, if appropriate, follow the Lean UX approach, creating experiments based on our assumptions and the data gleaned from the initial research. The main reason for using a more structured approach to discovery was because we didn't want to reduce functionality to the users.
The above diagram of the Double Diamond process is taken from training material I created and taught at Orgvue.
​
From our initial research we found the following high level insights:
​
-
Most users (> 80%), unless they were payroll professionals did not understand all the terminology used within the PTO pages. This caused a lot of confusion, often resulting in them abandoning their PTO set up or calling service for help.
-
Around a quarter of RUN users did not use the PTO functionality at all as it confused them. One even showed us a piece of paper on a notice board where he logged the time off for his employees.​
Why can't it be simple like this?
RUN Payroll small business owner
-
A survey found that more than 17% of users had searched the internet for a better way to manage time off and around 10% of that list had considered leaving RUN for a competitor with PTO functionality being a key factor.
-
There was a split between users who felt the amount of plans we had (Vacation, Personal, Sick and Sick 2) was too restrictive, whilst others just wanted a single, simple PTO plan where any time off would be recorded.
-
All non professional payroll users could not understand how to configure PTO plans where the employee earned PTO for either every hour worked or every pay period as they would have to do a calculation.
​
We also found:
​
-
Many users skipped setting up PTO in their onboarding experience.
-
Users did not understand the difference between Sick 1 and Sick 2 plans (Sick 2 was created to facilitate a regulatory requirement in California). One user asked if it was Maternity pay.
-
100% of users felt the experience could be significantly improved upon. ​
-
More experienced users such as payroll admins, wanted a simple form based approach to enter the data quickly, where as business owners were primarily weighted to a more hand holding solution.
-
Nearly 20% of users wanted more advanced functionality such as tenure based PTO (increase PTO with increased tenure within the company).
​
It was very clear that there was an opportunity here to improve the experience for our users whilst reducing service calls and creating savings. We could also increase the number of users who utilise the PTO functionality in RUN which would results in less dissatisfaction and whilst small, reduce the clients looking for alternative solutions.
​​
Full journey
Current journey maps
It was important as we conducted the research to understand the significant areas of pain for the users. Therefore I created a series of journey maps that as we discussed the current experience with the users, we could map their feedback against the journey.
Set up PTO plans
Existing solution
This is a screen shot of the company page to set up and maintain the PTO plans before we started this project. ​
Existing solution
Assign PTO plans
This is a screen shot of the employee page to assign and configure (with overrides if necessary) PTO plans for each employee.
Hypotheses
From the research we had conducted in the problem space, we formed a number of hypotheses to begin ideating on and landed on the following to move forward with and start to design.
Dynamic plans
By allowing users to define their own PTO plans, we satisfy the requirements of all of our users - those that want a single plan and those that want multiple.
Simplifying copy
By using terminology more familiar with our users, we will increase the usage of the PTO functionality.
Dynamic UI
By providing a dynamic front end based on the user's persona (and in turn experience), we will generate less service calls regarding PTO.
For this project we expanded our triad to include a UX Writer as the research had shown us that terminology would be very key to our success. Initially we would measure this by usability testing, and later, in production, through increased usage, analytics to detect drop offs and whether the step was skipped in the company and employee setup wizards.
​
Secondly we needed to ensure our solutions architect was fully resourced to our project during the solutions space as a number of technical spikes would be needed to understand how easy it would be to build dynamic PTO plans on the fly (this would be new functionality). We would measure the success of this hypothesis by usability testing and later in production by Pendo thumbs up/down satisfaction scores.
​
Lastly we would provide multiple paths through the PTO journey depending on the persona. Advanced users could enjoy the fast experience of a single page, form based approach, where as less advanced users would be hand held with more help. Our hypothesis is that this would increase the number of clients logging PTO in RUN. We would measure this with new clients setting up PTO and comparing it to the benchmark over the previous year. If successful, we would advertise the improved functionality through in product Pendo popups to existing clients to increase usage.
Ideation and design
In parallel to the ideation and design phase of this project, we conducted further research around the terminology, looking at competitors in the market and examining survey results to obtain an understanding of how we should change the copy.
​
The ideation phase began by mapping out new, reimagined user journeys, or tasks to be done within the two sides of PTO (company and employee). By understanding the existing flows already documented, we could determine if these were fit for purpose based on the research we had performed and create new pathways.
​
We identified the following journeys:
​
-
Configure a PTO plan at the company level (there was no adding new because RUN at this point had 4 default plans which you could either turn on or off and then configure)
-
Assign a PTO plan to a new employee (new employee wizard)
-
Assign a PTO plan to an existing employee (maintenance screens)
-
Modify an existing employee's PTO plan
-
Remove a PTO plan from an employee
​
There were also slight variations of these journeys if the employee or the company operated in California.
​
Importantly, through the research, we found one of the biggest pain points was adding existing employees to a new plan. Whilst we decided this would not be part of the initial MVP, we would later create a bulk add/update feature to assign employees (currently the user had to go into each employee individually and add them).
Technical and time constraints
Our original idea of providing two paths through the journey one for advanced and more hand held approach for less advanced users was not going to be possible. Our solutions architect had deemed that we would miss the release date if we had to create two paths.
​
Therefore it was decided we would just create one approach which was a progressive disclosure pattern. This would allow us to have one form approach, but with the new sections becoming visible as old sections were filled in, combining the best of both approaches.
To aid the developers, I created the following prototype in Axure RP to help demonstrate the intended behaviour.
PTO Progressive Disclosure
Unfortunately after conducting a technical spike, it was deemed that the UI frameworks we were working within would not accommodate the progressive disclosure pattern. We therefore decided as a triad to create the flow as previous/next screens while the UI architects worked on a solution that would string the individual screens together using progressive disclosure. This would be released at a later date, however, the MVP would be individual screens.
Accrual rate
One of the biggest barriers to adoption that was identified in the research was the notion of "accrual rate".
​
Put simply, if the PTO plan was set up so the employee earned PTO either by every hour worked, of by every pay period worked, the accrual rate was the number, or fraction, of hours earned.
​
For example:
The employee is paid every week (pay period is therefore weekly)
For every pay period, the employee earns 1.54 PTO hours (this is 80 hours a year PTO maximum divided by 52 weeks in the year)
​
This got more complicated for hourly paid employees as the employer would have to add in to the calculation how many hours they expected the employee to work each week.
For example, if they were expected to work 40 hours a week and were paid weekly the employee would earn 0.038 PTO hours per hour worked.
​
To solve this, we decided we would build a calculator. The user could either enter a figure or use the calculator to work it out for them. This tested extremely well and received an approval rating of 100% even with the more advanced users who appreciated its existence even if they didn't need it.
The above images show the final version of the calculator pages.
Final design
After a number of iterations with wireframes, we arrived at a design that the triad plus internal stakeholders felt happy with. I then created a user testing protocol and tested with 9 users that reflected the spread of advanced and non advanced users using our product.
Initially we received mostly positive feedback, however only managed a SUS score of 73. Whilst a SUS above 68 indicates an acceptable level, our goal was always to achieve 80 and above, so we therefore needed to make some alterations.
​
Some of the changes are listed below:
​
-
Initial accrual calculator functionality was hidden behind a button. I made a change to make it more visible and default it. Subsequent testing found this to be a very positive amendment.
-
In the company on-boarding flow, if the PTO pages were after Pay Schedule, we would have extra data to be able to help calculate the accruals with defaulted data that had already been entered.
-
When in maintenance mode (i.e. a plan had already been created), users wanted to be able to remove a plan when viewing the plan - not just from the PTO dashboard screen.
-
Users liked the categorisation of PTO plans we had previously (Vacation, Personal and Sick). I made a further change to include a type of PTO when in setup mode. The user could choose the type of PTO plan they wanted, which, whilst it didn't change any underlying data, had a helpful icon next to the plan to help visually identify it. There was also a type of custom.
​
I then tested the changes with the same users and received a SUS score of 83 which allowed us to move the designs on to development.
​
PTO dashboard (initial view)
Results
Unfortunately I left ADP before PTO had finished being coded and released to production, and therefore do not have detailed results. However, I did reach out to a former colleague to find the following brief statistics:
​
-
PTO Service calls after the first full month of general release reduced from 3,750 (average per month) to 83.
-
78% of new clients in the month after release, set up PTO at the company and employee level.
​
Whilst I do not have comprehensive data, both of these data points would indicate that it was a successful project.