Creating a report that helps Dutch companies to save on taxes
Participating in discovery research, leading internal workshops, creating user flows, wireframes, prototyping, high-fidelity design
The work-related costs scheme (werkkostenregeling – or WKR) enables Dutch companies to spend part of their total taxable wage on allowances, benefits in kind and provisions for employees without tax liability.
As part of the localisation effort for the EMEA market, our team was assigned to develop an application that would allow companies to easily track their costs and outstanding tax within WKR in Netsuite ERP system.
Note: to honour the non-disclosure agreement I’ve omitted any confidential or internal information. All the work and opinions presented in this case study are my own and do not necessarily reflect the views of the company.
The Netsuite support team has developed their own simple application to support WKR. The initial plan was to take over and improve this app. But after a quick UX audit and reviewing the collected user feedback, we decided to start from scratch. The key insights were:
- The solution didn’t work properly in some scenarios.
- The app provided very low user experience.
Our application needed to address both of these issues.
To sort our thoughts, I’ve led a collaborative workshop with the product team using the KUA (Knowns-Unknowns-Assumptions) exercise and the affinity mapping.
Knowns, Unknowns, Assumptions, then sorted into clusters.
In a nutshell – the compliance requirements were pretty clear but we needed to find out more about how the WKR is implemented and processed in actual companies.
The WKR scheme introduces 4 main expense categories: Intermediary Costs, Zero Valuation, Targeted Exemption, and Other work-related costs. The employee expenses that fit one of the first three categories are free of tax.
The expenses in the last category – Other work-related costs are subjected to WKR budget. The amount inside the budget is tax-free but everything exceeding the budget is charged by 80% tax rate. The budget is calculated from the total fiscal salary the company paid to their employees.
The calculation terms used to calculate the WKR budget and the tax rate for exceeding the budget are subjects to change for each fiscal year.
The WKR scheme within the company accounting.
I have used the research that the support team have done to pick a primary persona from our internal repository.
Fiona – the Financial Manager is a senior member of the accounting department responsible for accounting processes and reporting the financial insights to the company’s top management. One of her responsibilities is to make sure that all expenses are correctly allocated within the WKR scheme so the excess tax is kept at minimum.
In collaboration with the whole team, I’ve prepared the basic set of user goals and user flows that we planned to validate and extend based on the insights from customer interviews.
Initial user goals and primary user flow (covering first two goals).
Since recruiting users in Oracle takes awfully long, I used the time to put together a few low-fidelity mockups that we could show participants to get early feedback.
Early drafts of the application.
Lisa, our awesome researcher, led two semi-structured user interviews with the goal to better understand how customers comply with WKR today and to validate our early assumptions. We have learnt valuable insights:
- Our original requirements defined budget calculation incorrectly based on monthly salary instead of annual salary.
- The 4 main WKR categories are not enough. Companies track their expenses within many custom subcategories.
- Customers were used to view the WKR categories in a different order – one that was more common in government articles.
- The need for manual entry of fiscal salary wasn’t confirmed. Instead, participants were more interested in forecasting of the budget for the rest of the current year.
(This required further validation.)
After updating our user goals and flows, I started working on more detailed wireframes incorporating the latest findings. Since consistency is very important in a huge system like Netsuite, the page layouts are strongly influenced by existing design patterns in Netsuite.
Wireframes within the primary user flow.
Wireframes for a simple Configuration page.
I have compiled the latest mockups into a clickable prototype that we tested with two other customers. These sessions confirmed previous findings but also brought a few new ones. Key insights were:
- While calculating the WKR budget for the whole year was correct, financial managers also appreciate if they see accumulated budget up to each month before and after spending.
- From the current layout of the report table, it’s not clear that only one of the categories is subjected to WKR budget.
- It was also confirmed that users don’t need to manually enter the fiscal salary but rather need a way to forecast the budget for the whole year.
- For audit purposes, Financial Manager needs to be able to drill down into the underlying transactions for each WKR category.
Improving the report layout
I have explored several versions of the layout for the report table based on the feedback from all user sessions. After a few rounds of internal reviews, we decided to continue with the following version.
New layout of the report table.
Forecasting budget for the year
Since the last two customers confirmed that the forecasted budget for the whole year is essential information to them, we decided to include simple forecasting in the first version of the application.
The initial wireframe of the budget forecasting.
Drill-down to list of transactions
To cover the need to review the underlying transactions, we wanted to link the report values to an existing Netsuite feature for searching transactions. Unfortunately, the devs quickly found out that this feature isn’t flexible enough. As much as I don’t like adding redundant features to the system, we had to build a simple transaction list ourselves.
Wireframe of transaction drill-down.
We have managed to recruit two more customers for final validation. These sessions mostly confirmed that we are heading in the right direction but also helped us to better understand the goals of the budget forecasting. Following that, we chose to extend the forecasting with an option to also enter a monthly estimate spending for the category subjected to the WKR budget.
Smarter functionality – that would forecast automatically, possibly leveraging machine learning would be considered in the future versions.
From the customer interviews, we knew that customers expect to map accounts and expense items to WKR categories but also need to be able to override it per transaction. However, we had to consider many complexities – the limitations of the system, the performance of loading the data into the report and handling of historic transactions and transactions imported into the system externally.
Data sourcing explained in user flow and using examples.
Even though the application was developed to comply with Netherlands laws, it would be used by international companies. As a designer, I had to ensure that:
- The design will work with different languages, especially Dutch.
- The application will work in a multi-currency environment.
- The date and number formats follow the local system preferences.
- The terminology used is aligned with local standards.
- All custom data inputs enable entering translations.
Examples of localisation considerations in the application design.