Role: UX Designer, Workshop Facilitator & Researcher
Company: Elanza
Year: 2025
Elanza’s SaaS solution helps healthcare organisations find caregivers who are willing to work a specific shift. Using a rule-based system, shifts can gradually be offered to internal staff, freelancers, and temp agencies.
Healthcare organisations also use Elanza to inform the finance department about the payment a caregiver should receive, since Elanza handled the matching process. Salary payments are structured around a base salary, with additional factors such as travel expenses, night shifts, weekend shifts, and other job-related costs. However, agreements with temp agencies can involve completely different payment rules.
Elanza already had a solution to calculate these payments, but one important aspect had not yet been implemented: changing the base salary at a specific moment in time.
When a caregiver received a promotion or when new collective labour agreement rules came into effect, finance employees had to manually update the caregiver’s salary. Any salary change would take effect immediately. This was problematic because employees had to be extremely precise to ensure the correct shifts were paid using the new salary.
Another issue was that salary changes were not visible within Elanza. Finance employees could not see when a salary had changed or what the previous salary had been. This information is important to understand why a specific salary was calculated for a particular shift.
How can we enable finance employees to schedule salary changes for a specific date while also making salary mutations transparent and visible?
Because several factors influence a caregiver’s base salary, I first needed a deeper understanding of the subject before shaping a solution.
I had multiple discussions with my project manager, who had years of experience in both finance and Elanza’s domain. These conversations helped me better understand topics such as:
With this knowledge, I created two rough concepts.
The first concept focused on making salary adjustments directly on the caregiver level. The second concept focused on implementing a versioned collective labour agreement salary structure. In this concept, caregivers would receive a salary label, while finance employees could manage the salary values connected to those labels elsewhere in the system.
Both concepts had advantages and disadvantages.
The first concept was technically easier to implement because Elanza already supported functionality where rules become active within a certain date range. Similar logic was already used for agreements and contracts between caregivers and healthcare organisations.
Another advantage was that finance employees could clearly see that a salary change applied to a specific caregiver, making the changes visible in a logical location within the system.
The biggest downside was the amount of manual work required whenever a collective labour agreement changed. This could involve updating hundreds of caregivers individually, resulting in repetitive work and a higher chance of human error.
The second concept introduced a salary table similar to those commonly used in the healthcare industry, where salary depends on factors such as experience and education level.
Since Elanza already stored information about a caregiver’s role and experience level, having a centralised salary table would make implementing new collective labour agreements much easier.
However, this idea introduced significant technical complexity. It required building a new relationship between caregivers and salary tables elsewhere in the system, while still needing caregiver-level communication about salaries and salary mutations. In practice, this meant many aspects of the first concept still had to be implemented.
Considering these trade-offs, we decided to proceed with the first concept.
With the chosen concept in mind, I started creating rough designs of the feature. Because Elanza already had a design system with reusable components, the relevant section of the page could be built relatively quickly.
From there, I explored different scenarios and how the design needed to adapt to them. Important considerations included:
Each scenario provided an opportunity to challenge the design, question assumptions, and discuss solutions with the team and stakeholders. This led to multiple iterations that gradually improved the overall experience.
Because of limited budget, time, and team size, we decided to launch the solution and gather feedback from users afterward.
Fortunately, Elanza has a highly engaged user base, allowing us to collect feedback quickly and continue iterating on the product.
This project, like many others at Elanza, challenged me to quickly understand complex new domains. Elanza operates within a highly specialised and complex area of the healthcare industry. One of the biggest challenges was learning how to ask the right questions about subjects I did not yet fully understand.
By creating concepts, validating them with stakeholders, and conducting research, I was able to deliver a design that addressed user needs while remaining technically feasible.
At the same time, the project challenged my confidence in my own craft. It forced me to make difficult decisions, but it also helped me become more balanced and realistic about my strengths, limitations, and the value I can contribute to a company.