Adjustment tool
Sometimes PayFit clients need to make changes to past payslips, but this is not possible, you cannot change the past, but you can change the present to make up for an error or oversight in the past. This is called an adjustment. This tool facilitates the task of internal teams who used to do this work manually, which could take weeks. Today, this same work takes only a few minutes.
Company
PayFit
Year
2021
Type
Internal tool
Skills
User research
Shadowing
UX / UI
User tests
Team & role
The JetLang Platform team is one of PayFit’s historical teams, at the heart of the machine. They are a very techy team, not used to working with designers. My role on this project was to work on an end-to-end design process, from user research to delivery, in collaboration with the Product Manager and Engineering Manager and a UX Engineer, whom I was training in Design all along.
Let start with a bit of context: What is an adjustment / regularisation?
” Errors in the past that need to be regulated in the present “
Errors can occur on:
• Onboardings
• Contract updates
• Salary
• Pension rates
• Holidays & bonuses
• Expenses
• Time worked
• etc.
Errors can come from:
Customer: Errors can come from admins who have mistaken or forgotten some updates
Administration: The government can submit some legal retroactive updates.
PayFit: we can encounter human errors as long as JetLang code or Tech errors
Some examples
• An employee forgot to enter his holidays on PayFit last month
• The company changes its legal status, there is an impact on employees for the last 4 months
• The government changes the rules for financial measures for one type of company, with retroactive effect
The risk of manual error is high
Dozens of manual tasks for one regularisation: copy/past, read, edit
Each regularisation has its own workflow
More than 50 identified type of regularisations, but it can be unlimited
Some regularisations can be really complex
1 regularisation can last several days and involve 3 or 4 people (CSM, Decla, Product Builders)
My design process
The Double Diamond
Discover
Gathering internal information
Shadowing declaration teams making adjustments
Define
User flows based on shadowings
Low-fidelity wireframes
User tests
Develop
Iterations based on user tests
Quick user tests to validate changes
Deliver
High Fidelity prototypes
Deliver assets
Follow up during development
Discovery
I first went to talk to the stakeholders, to get as much information as possible that we already had, to better understand the context, and to allow me to elaborate a precise research plan.
I then shadowed the declaration teams in France, Spain, Germany and the UK, in charge of making adjustments.
Some insights coming from the shadowing sessions:
→ Each accrual is in fact a change in the value of a pay variable. By changing it, it can have an impact on many other variables.
→ There is a lot of back and forth between different platforms: the back-office, PayFit app, Slack, JIRA, Excel. Everything can be put together.
→There are many human tasks, which lead to many errors. These tasks could be automated.
→The teams do a lot of copying and pasting of values from the platform and excel to make the calculations of the variables impacted by the regularisation. This can take several hours, and there can be errors.
→ The most stressful step is the step of updating the information in the PayFit app, which will directly impact the customer. The information must be correct.
“It would be nice not to go through Excel, if there could be an automatic check it would avoid human error, and generate less stress.”
– Catherine, from the French declaration team
Define
Once the information was gathered, I created user flows, then wireframes, which I quickly tested in user tests.
Based on the shadowing sessions, I created user flows to map the existing, and identify problems.
I then created the first wireframes, in collaboration with the Product Manager, Engineering Manager, and UX Engineer.
After being comfortable with the wireframes, I did 5 user tests, in each country, to make sure we covered all the cases:
2 in France
1 in Spain
1 in Germany
1 in the UK
Develop
The analysis of the user tests allowed me to iterate again to refine the design.
Here are some insights I gathered:
→JSON Format is not understood by the users
→It’s better to start a regularization from an employee perspective
→The page is really useful, and even more adding archived employees and comments
→When checking results, overall, they check if the numbers seem consistent
I then did some quick last user tests to validate big changes.
Deliver
I finally created the following High Fidelity prototypes, deliver assets, and followed up the development process by engineers.
