Maintaining Raceday Control
As a major sports betting provider, as well as a provider of race results to many media outlets and TV channels, one of Tabcorp's key business areas is the monitoring of horse and greyhound racing.
Tabcorp had a large team of race day operators responsible for this task, and the software they had been using up until this point was built in the 1960s. It's exactly what you'd think; a DOS-based, highly manual system that relied heavily on bespoke, complex knowledge and a significant portion of manual paperwork.
A very manual process
The first step of the process was to understand the work that Tabcorp's Raceday operators actually engaged in.
We spent two days with the operators, in their control center, watching them work. Their workflow involved a mountain of manual paperwork - printouts from each morning that were constantly scribbled upon to record results. This was a clear point of opportunity, as it was a source of frustration and also a common problem area for inconsistency or auditing.
Plotting a course
It wasn't enough to understand the workflow of our operators - we also needed to communicate that knowledge back to the business for validation, and have a tool we could come back to when planning our new solution.
We created an expansive user flow diagram that identified key decision points and issues the operators would run into during their day. This was validated with the operators themselves repeatedly through the process.
Replacing the paperwork
As I went through the discovery phase I constantly sketched possible solutions for the operators we were observing. This served as a visual aid to explain where our thinking was, and also a prompt to get them thinking about the solution that they would like to see.
We began the project with rapid mid-fidelity prototyping. Bi-weekly meetings with both the project manager and a few select operators allowed us to rapidly iterate on our designs, adding or modifying features as they recommended.
It was an ad-hoc, informal user-testing process, but one that paid dividends for the work we were doing.
Both the operator staff and their managers identified a key issue with their current workflows - there simply wasn't any accountability or audit trail for when work was shared between multiple staff members.
For example, if a staff member needed to take over responsibility for tracking a race, they would literally take the piece of paper off the desk of the previous staff member.
We designed an alerting panel that was always present for the user and could be easily filtered to information relevant to them.
Check the Roster
It became clear early on that for users to collaborate and work together, they'd need to know each other's responsibilities and workloads.
Managers weren't keen on a new rostering tool - they already had a system that worked for them. Instead, we made staff responsible for entering their shift information, and the system would assign races for them to be responsible for.
This gave both managers and staff the balance and flexibility they were looking for, whilst maintaining a relatively light technical solution.
Much of the race data that the team used came from external sources but needed to be approved before being entered into the system.
Previously staff would check the external printouts against the ones available to the Raceday team.
This led to opportunities for manual error, so instead, we designed a digital system that imported both sets of data and identified and discrepancies or errors.
A common aesthetic language
We wanted the new system to be easy to learn for the existing Raceday staff, some of which had been using the existing system for years.
Each screen, regardless of the functions available, shared similar layouts, styling, and colour.
The feedback from our test group was highly positive, as they were able to quickly find and understand information after learning the basic rules that all screens followed.
Software development is a marathon, not just sprints
The Raceday Control project will take years to be implemented, but the research and design work we did has dictated much of the product direction.
In particular, the early research we did to understand the operators was a major breakthrough in the project - it allowed us to understand just how broadly this system could impact a workflow that had been around for decades, and the importance of treading lightly when it came to influencing that workflow.