In the construction industry, one the largest problems faced by administration is billing reconciliation; how can we accurately pay our drivers for their work? In a single job, this can be answered with something called a timesheet, which is simply a detailed record of a driver's job and payload.
An example of a timesheet.
While timesheets are effective and commonly used, drivers often do multiple different jobs with different pay rates, meaning that foremen and supervisors would often have several timesheets to process at days end, making reconciliation very manual and error prone.
This is where aggregated timesheets come in; an aggregated timesheet is a templated format used to standardise different timesheets and aggregate the hourly rate and pay into a single actionable digit, making it easy to reconcile and pay drivers.
As of late 2021, while Tread supported timesheets with different payment structures it didn't support aggregated timesheets. This meant that foremen and billers using the platform would have to manually track down different digital timesheets associated with their driver and manually calculate the final rate either on an external tool or via pen & paper.
This immediately posed 2 major problems:
Foremen would have to take a frustrating large amount of time to breakdown their timesheets resulting in very low compliance rates, hovering at just under 60%.
Drivers are historically very tech adverse and often make mistakes when logging timesheets. This means that nearly >75% of logged sheets required correction from the foreman.
For primary research, the product manager and I conducted several interviews with drivers, foremen, and administrators to get a deeper understanding on how timesheets works in a day to day capacity and the pain points associated with such a rigid and error prone method of data tracking. From here we were able to define a few major insights that we believe we can target and action on.
Every job and timesheet is different, requiring foremen and billers to constantly adjust values on the fly.
Timesheets require too much detail and attention to fill, resulting in a lot of mistakes that need to be fixed.
When filling a timesheet, a foreman needs to reference some sort of data to make sure the job is accurate
Truck drivers generally struggled using technology and have a hard time accurately logging in a rush
After researching the problem space and interviewing a few clients, I wanted to develop some personas for clearly define who the target users are and what pain points we want to actually tackle in our solution. This gave us the foundation for future iterations and helps ground our solutions.
As workflows within the construction business are often convoluted and interconnected, I wanted to clearly map out the golden flows for each of the key personas when it comes to creating and approving a timesheet. This exercise was done to clearly understand where our identified pain points would fall into in the workflow and better identify the core steps our final solution needed to include.
A foreman’s golden path would involve adding some adjustments to an aggregated timesheet, checking that all details on the jobs are accurate then signing off on the timesheet. In the real world, this is often done on paper where each job’s times would be written down on a timesheet which would be signed off at the end of the day.
Diagram showing the golden path for a foreman
Unlike the foreman’s flow, the billers flow is all about getting information as fast as possible. Their goals include double checking the driver’s job times are accurate and accounted for, and figuring out how much time they need to pay the drivers for. In the real world, this is done by cross-referencing jobs with tickets and manually calculating the final rate based on the times written on the timesheets.
Diagram showing the golden path for a biller
Unlike the other personas, the entire workflow of the driver is centred around one concept: Make it as easy as possible to fill in any details related to timesheets. In the real world, this is often done on paper and is done at the end of a job usually at the request of the foreman.
Diagram showing the golden path for a driver
With our workflows mapped out, the next step before ideating on solutions was to understand what limitations or reusable assets we’d have within our platform and how that might affect our final solution. I held several meetings with PMs and senior engineers to work out any major limitations, and we quickly identified 2 major ones.
The way our database was built meant that a solution that allowed foremen to adjust individual jobs would be too costly for the engineering team to implement in time. This meant that any changes to the timesheet would have to be done globally.
Data structure limitations meant that foremen cannot directly update and change any job details made by drivers, meaning that obvious issues and problems have to be resolved on the driver app and cannot be remotely overwritten by foremen.
With the task flows mapped out and any constraints clearly defined, the next step was to start ideating on solutions. I started with very rough sketches to map the key functions of each task flow and wanted to explore some different layouts. To validate the decision making and validity of these sketches, I would frequently run these sketches by the team PM and the Customer Success team.
Figure showing rough sketches for timesheets on the admin tool
Figure showing rough sketches for timesheets on the driver app
After consulting the teams, there were components that we felt strongly about incorporating into the final design. For the admin tool, the general feedback was that time and sign off need to be the most visible details on the page as they are the main details that foremen and billers will be editing.
Figure showing details from sketches that were integrated into higher fidelity designs
For the mobile app, it included making key objects as visible as possible, things such as editable start and end time fields, larger job cards, and bigger time call outs.
Figure showing details from sketches that were integrated into higher fidelity designs
After fleshing out the general layouts, I went through several iterations of medium and high fidelity designs before settling on a final version that was tested and validated by the team at large.
Figure showing the aggregated timesheet iterations from medium fidelity to final design
Figure showing the positive and negative feedback related to the aggregated timesheet experience
Figure showing the designs for the main timesheet page on the driver app from medium fidelity to final design
Figure showing the designs for the timesheet details page on the driver app from medium fidelity to final design
Figure showing the positive and negative feedback related to timesheets on the driver app
After weeks of iterating and feedback, the final design was settled upon and engineering began building and releasing the solution. The initial feedback from clients was a positive one, aggregated timesheets had long been a missing core feature on the Tread platform, and its availability finally allowed clients to use Tread as a platform that could not only dispatch work but also record and bill it.
By providing an aggregated timesheet experience that was not only intuitive but reflective of their day to day tasks, we were able to improve foremen compliance in logging timesheets from 60% to >90%.
By drawing clear attention to their tasks and simplifying the overall timesheet experience, drivers were able to more accurately track their actions, resulting in timesheets requiring correction dropping from >75% to 38%.
But despite the positive feedback, it was clear that significant amounts of improvement needed to occur before clients were able to reliable use timesheets to track and bill jobs. The following points were quickly identified as the major pain points that we’d need to resolve in an upcoming version 2.
Due to each job being unique, adjustments needed to be tied to jobs rather the timesheet at large.
Foremen found that it was annoying to sign off in bulk, and much prefer signing off on individual jobs.
While foremen liked the additional details, they were overwhelmed at the amount of information
Rates often varied between jobs and needed to be calculated on a per job basis rather than in bulk
As designers we're trained to always keep the target audience in mind and champion the user, but in reality during the waves of ideation and creation its hard to keep those initial pain points and goals in mind. In the few months I spent working on this project, it was a sobering reminder everytime I reviewed iterations with clients that I'm not building something for my company, I'm building something for them and that I need to strive to ground my designs with frequent feedback and user testing sessions.
The first thing that clients will always tell you when it comes to information is that more is better. "I need to see more", "I need these details on the screen", "I need to be able to edit all of them". However if their wish were to be fulfilled, the final solution will almost always be a mess of details with no semblance of hierarchy or flow resulting in slower workflows and a lot more confusion. Designers are taught the principle that sometimes less is more, and its up to us to champion that philosophy and prove its worth and value to our clients.
