Worker timesheets

Context

All temporary placements started on the Engage platform require timesheets to record the time worked each week. These are typically created by an agency worker after the weekend, sent for approval and then the worker is paid once approved. The process is long-winded and at risk of errors and delays at each point.

If there are any queries about the timesheet it can mean a delay of hours or days, potentially meaning the worker is not paid that week. Rejected timesheets need to be resubmitted with the correct attendance data.

Agencies & clients unfortunately do not always trust workers to complete their own timesheets. This can be because workers overstate the hours or days worked, submit unapproved expenses or simply because the client wants to retain control over workers access.

Timesheet approval process

1. A worker completes a paper timesheet and sends it to their agency
2. The agency worker inputs the times into Engage and sends it to the client for approval
3. The client approves the timesheet and generates an invoice for the agency
4. The invoice is sent for payment by the client
5. Once the agency receives payment, the worker is paid

Problem

The whole process of submitting and approving a timesheet is slowed significantly by requiring multiple actors to complete tasks. This can lead to a lot of unnecessary chasing, errors and delays in sending payments to workers.

Our solution only works on desktop, so it is impossible for timesheets to be edited or submitted away from a desk.

Objectives

Create a timesheet solution that enables workers – on any device – to complete and submit their own timesheets for approval.

Mirror the functionality of the current timesheets app, while reducing the reliance on agencies for timesheet completion.

Process

We knew from previous testing that the current timesheets app was working successfully, however it was only usable on desktop. Our focus as a team had two objectives:

• Create a timesheet solution that works on mobile & tablet devices
• Preserve the same design language as the current solution

We identified quite quickly that having a large number of form elements constantly visible on mobile would be both cluttered and increase the risk of errors and mistakes during data entry.

Setting elements to scroll horizontally would work well for a single week, but would involve lots of scrolling, hidden elements and challenging error handling when longer periods were used.

We settled on a concept where form elements for each day would be placed inside a drawer that was opened on tap, with a summary view when closed. This would give us greater control over which rows were open by default, disabling non-working days and auto-filling with known data.

This concept was experimented on, with multiple ideas created, discussed and iterated. Some ideas were tried as a simple form within each drawer, where others were tried as more of a conversation and logical flow through the required inputs.

Internal testing

Several of the options were turned into quick prototypes in Axure for testing internally with other business departments. We were initially looking to gain insight into the speed and error levels of data entry, as well as some feedback on the progressive disclosure of information.

Feedback told us that the prototype was quick and mostly error free for data entry, but users requested more visibility on running totals of days worked, total pay and the progress and saved state of the form.

We decided to add a sticky progress bar at the bottom, indicating to the user when their inputs were saved, what the running pay total was and progress on how far through the timesheet they were.

This was again turned into a more refined prototype for testing. Feedback was positive, with the team feeling confident in the proposed solution.

External testing

After making some more adjustments to the UI, we contacted a couple of businesses who requested worker timesheets to test data entry with some workers.

This took the form of parallel testing with the existing workflow. Workers were still expected to fill in paper timesheets, but we also gave them access to the digital version to fill in. This allowed us to have physical artefacts to check the data against, as well as real-world usage of the app.

After these tests were completed, a few more small adjustments were made and it was decided to roll the app out to more clients.

Results

Within hours of the first clients going live, there was a steady stream of submitted timesheets. Very few errors or customer service issues were raised and the roll-out seemed to progress smoothly. Over time, worker timesheet usage increased to roughly 30% of all timesheets submitted, reducing client and agency workloads.

Almost immediately we discovered a change in behaviour. Previously, most timesheets would be submitted after the weekend, with the agency chasing any missing timesheets on Mondays and Tuesdays. We noticed that timesheets were being filled in day-by-day, throughout the week. This gave us some ideas about how we may iterate on the solution, potentially allowing approval on single timesheet lines, meaning workers could be paid at the end of every day or shift.

We were considering expanding on the initial rollout by making the form even smarter. Because we have existing vacancy data, we are considering pre-filling the expected working times, speeding the process up even further for workers who work their expected hours.