In Oracle HCM Payroll application, Tax Calculation Card is where employee’s income tax, earnings and deductions get calculated. Since we have customers from all over the world, I redesigned this function for countries including Canada, UK and Mexico. I collaborated with local PMs to collect use cases for those countries.
I was the sole designer on Canada tax withholding card, Mexico tax withholding card, UK court orders & student loans card, UK statutory deductions card, UK benefits and pensions card and UK pensions automatic enrolment card.
Understanding the user group
The end users, who rely on this function to complete day-to-day tasks are payroll specialists. They are the professionals in the tax domain which I’m not quite familiar with. So right after the project kick off, I connected with the PMs to gather usage scenario and context, as well as end users’ task flow. Also I read through secondary research to get a better understanding of the tax terms and concepts. Below is a summary of some typical use cases:
- Collect new hires’ tax related information and enter into the application. (Tax withholding card is created automatically through new hire onboarding process)
- Manage employees’ tax related information when there’s any changes.
- Retrieve historical data of tax calculation cards for audit or employee requests.
Make it easier and faster for payroll specialists to manage employees’ tax calculation card.
Make the flow consistent as possible across different countries to minimize development efforts.
Redesign the entire interface to keep up with HCM new design patterns.
Problems with the current experience
The current system is overly complicated which makes create or edit tax calculation card extremely time consuming. Although the payroll specialists are using it everyday, the average time of creating for 1 employee takes about 5 minutes. Also with so many tax terms, as well as the “rules” on the current interface, the learning curve is steep. Users have to go over a 30 pages manual before getting proficient with this job.
After observations and interviews, below is an example I illustrate of how users typically interact with the current interface:
TRU: Calculation card must be associated with a TRU (tax reporting unit), which determines which rates and rules to calculate.
Job Assignment: Calculation card can be associated with employee’s job assignment. If users have job assignments from different countries, they will need different calculation cards.
Revamp the experience
A few elements (calculation component, component details…) are segregated on the interface. Actions (edit, create…) are visually cluttered makes it difficult to understand which item I’m taking action on. To simplify the flow, I tried to rearrange the elements and validated their relationships with PM:
When payroll specialists are going to create a calculation card, the first thing they want to identify is which TRU should be linked. After this step, they can pull up employees’ personal tax data and input into the system. The layout of the page should follow users’ task flow. So I got rid of the 2 tabs and consolidated information on 1 page. As for calculation component, all data should be transparent to users, not segregated. Visually it should show all component data in 1 bucket:
UK court orders & student loans card redesign
View and edit all data at once for 1 component
(component details + data details + job assignments)
Group data in drill-down page when it gets overwhelmed
In the example of UK Statutory deductions card, there’s much more data entry in 1 component. We show the most important information in the overview, and present the entire data in drill-down page.
A couple things I learned about localization
Tax calculation card is a function Oracle provides for customers in different countries. Our goal is to minimize development efforts across countries, so the visual design and interaction flows are consistent. The development teams from different countries seemed isolated. I played like a node, to help teams connect with each other and look for reusable code.
The content on the page can be different for different countries. However the actionable components, like “Save”, “When does this change start”, are always the same. When designing, account for translation is important. The shorter the word in English can be much longer in other languages.
Even in English language countries, there are some minor differences in spelling. For example Canada spells labor as labour; UK spells enroll as enrol in their legal documents. The date format can be different too, for example in UK it is dd/mm/yy.
Regarding culture differences, the icon can speak of different meanings. In this use case, we have pencil icon for edit action. This is pretty common in US market. However we also want to deliver borderless “Edit” button, with the word spell out, for countries where pencil icon is not understandable for end users. This is customer configurable.