System logic design to support pay estimation calculator for nursing union members


The Australian Nursing and Midwifery Federation (ANMF) is a national union and professional organisation. Several years ago, the Victorian branch of the ANMF commissioned the Diary App to help members keep track of their ever-changing shifts.

One of the concerns of the ANMF is to ensure nurses are paid correctly by educating members about their entitlements, and one way of disseminating this information was to include a pay calculator which would estimate the user’s pay based on their employment and shift details in the Diary App.

My role

  • Defined the scope of the first release based on the available budget
  • Determined the logic for calculating estimated pay based on definitions provided in the EBA
  • Determined the requirements for the interfaces based on the existing app and new calculation requirements
  • Wrote extensive test cases to validate the engine and to guide UAT

Design process and key challenges

The first day I worked on this project, I was left in the meeting room with a hard copy of the relevant enterprise bargaining agreement (EBA; a dense 200-page legal document detailing the rates and allowances at which nurses in public hospitals should be paid)) and a giant piece of paper.

I had been warned that there wouldn’t be enough budget to build a calculator that took into account all the clauses in the EBA, and one of my first tasks was to carve out some of the clauses to include in the first version.

While it was tempting to just say, let’s just include the clauses on the first 30 pages, I thought it would be better to ask the client – how will your members use this feature? One of the ANMF reps at the meeting was someone who sometimes manned the members’ hotline. “People call up and ask about their payslips. There’s so many numbers – they don’t understand all the different items, so they just want someone to check that they’ve been paid right for their shifts.”

On my giant piece of paper, I made notes about each clause in the EBA, and started categorising them. Some were about shifts on different dates, at different times. Some were employer-related, like uniform and laundry allowances. Some addressed unexpected happenings that needed to be compensated for, like overtime or not getting your lunch break. Given the current function of the Diary App was for entering rostered shifts ahead of time, I recommended leaving out any clause that required information that couldn’t be known before a shift happened, since we weren’t equipped to make good estimates on those allowances anyway, and wildly inaccurate figures would be even more confusing for users.

Once the scope was defined, I drafted flow diagrams to demonstrate how various pay components would be calculated, based on my interpretation of the EBA.

Legal documents often give the impression of watertight logic, but it’s amazing how many ambiguities surface when you try to translate it into mathematical formulas. It took several meetings with the SME at ANMF to iron out ambiguities (and agree on assumptions where there was no hard answer known).

To make sure we were really on the same page before I passed the calculation model on to the developers to build, I developed a series of illustrative user scenarios covering a broad range of possible real-life use-cases. These scenarios were a series of detailed calculations in a spreadsheet, generating a user’s expected pay given a series of inputs.

Once the SME signed off the calculation models, the developer started to build the engine while I wrote test cases to validate against, specifying all the inputs and expected outcomes for 74 test cases covering both common use cases and edge cases.

Yes, 74. I also had the pleasure of running all 74 test cases through the greybox build manually.

The pay calculator function is now available to ANMF members.

If you’d like more details about this project or any others in my folio, please contact me.