Cloud Job Management

Overview

Tabula Live is set to fully replace the existing Proof of Placement and job management system. The old system has its warts, but it's a well-established player: since inception it's had over 90 million hectares of work put through it. It shaped and led the agricultural job management industry and is the foundation Tabula's success was built on. Replacing it is hard, but there was a clear gap for the next generation.

Goals and objectives

The goal: design and build a next-generation job management system that could be built on and heavily used for the next ten years. Key objectives:

• Must be scalable
• Must be specific
• Must collect as much information as possible
• Must work on mobile, tablet, and desktop

Problem statement

The project was prioritised because the existing system was getting delicate. Ten years of technology change had taken its toll. It didn't affect daily use, but changing anything introduced risk, not ideal for such an important product.

Job management is just one slice of Tabula Live, which will eventually take over all of Tabula's operations: reporting, device management, GPS tracking, proof of placement, and guidance.

My role

UX/UI/Product Designer. I covered:

• Customer interviews
• Interface design
• User experience
• Documentation

Key insights

• We needed to do more than spreading and spraying
• Not all jobs have the same components
• Customisation mattered more than expected
• More and more operators were doing job management on mobile
• Every contractor said they weren't good with technology
• Customers knew the job management process better than most Tabula staff

Process

Research made the pain points clear:

• TMO, the existing tool, was built for one well-defined customer, spreading contractors, and served them very well
• A job could be created from several places, each with a different workflow
• Job creation was complex even for simple jobs
• The workflow and UI weren't intuitive for new or sporadic users
• It didn't scale well
• It catered to power users who'd climbed a steep learning curve

One of the toughest pain points was internal, not customer-facing. Several designers had attempted this complex problem before me, and each attempt had worn down the team. A new designer (me) turning up to redesign it again didn't fill them with hope. So I pulled together research and presentations and got everyone in a room to align. The slide decks took time, but the shared mindset afterwards was invaluable. Cue the whiteboard scribbles.

User experience

I had a few clear goals for the UX:

• Create a job from wherever makes the most sense
• Scale and be ready for different industries with different needs
• Make the simple easy and the complex possible
• Collect high-quality data for better decisions later

The redesign delivered on each. Jobs could be created from where users actually live, the main map, as well as the Jobs tab. Each job starts by selecting an activity, spreading or spraying to begin, but extendable to pest control, surveying, fuel transport, and more.

Key challenge: variable rate jobs

We had a complex way of handling variable-rate jobs (fertiliser applied at different rates across an area, later shipped as "multi-rate"). Analytics showed it was barely used, and the consensus was it shouldn't be a priority.

Then, halfway through, the government introduced a scheme requiring farmers to report all synthetic fertiliser applied, just as COVID-19 pushed fertiliser prices 5 to 10x higher. The insight: farmers want their fertiliser to go further. So we decided to make it easy for farmers to control exactly how much fertiliser goes where.

Multi-rate job creation

This became a focused project to add multi-rate to job creation, serving two key user stories:

• As a farmer, I want to define the amount of fertiliser I have upfront, then divide it across paddocks, because I've already bought it and want to use it efficiently.
• As a farmer, I want to set the rate applied to a set of paddocks, so I have enough grass to feed my animals.

So the system had to either calculate the total or set it for a selected group of paddocks. An early mockup let users create block-groups to assign a rate or total. It made sense, but it was the wrong call: it broke "make the simple easy," forcing every farmer to add a block group even when there was only one.

The second, implemented iteration spent far more time on workflow and clicks, and I'm proud of how it turned out. Key improvements over the old system:

• Flick between "by total" and "by rate" without losing data
• Stay in the simple workflow (all blocks the same rate or total), then go deeper by selecting "Multi-Rate Job"
• Rate shown visually by shading the block (lighter = less, darker = more)
• Start an order normally, add blocks with a rate, then move into multi-rate; the existing blocks and rates wrap up into the first block group
• With two or more groups, opening the dropdown greys out the other groups on the map, so it's clear which one you're editing