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.






Internal tool


User research



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


Gathering internal information

Shadowing declaration teams making adjustments


User flows based on shadowings

Low-fidelity wireframes

User tests


Iterations based on user tests

Quick user tests to validate changes


High Fidelity prototypes

Deliver assets

Follow up during development


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


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


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.


I finally created the following High Fidelity prototypes, deliver assets, and followed up the development process by engineers.