Overview
Making a field plan a farmer can read in one look
Verge plans the route a tractor drives across a field — tracks, headlands, turns, the order it works in. The maths was solid. What a farmer met on screen was every control at once, with no way to tell which ones mattered.
1 / 3 · Setup
About the project
A results screen that had grown. Straight planning and curved planning showed different controls, everything was packed into one panel, and there was no route from the handful of settings that matter to the many that usually do not.
The harder part is that there is no best plan. Time, fuel, coverage, track count, soil loss and wheel traffic all pull against each other, and a farmer weighs them differently depending on the field and the machine. Putting every control on screen hands that trade-off to someone who is about to get in a tractor.
- Services
- Product Design
- Industry
- Agriculture and farm equipment
- Engagement
- Ongoing
- Period
- Jan 2026 – now
What we solved
A plan is already generated when you arrive, balanced by default, with a few goal-based alternatives instead of every combination. The technical controls are all still there as overrides; they are just not the first thing you meet.
Plan From became a workflow rather than something buried. Two saved plans can look identical as thumbnails and differ in row spacing or heading in ways that change the whole job, so it has search, a preview showing the field and the equipment, and a way to detach a derived plan when it needs to go its own way.
How the results page got here
It took five passes to get from a control panel to something you can read. The order matters, so here it is.
A dense technical control surface
The first version dropped you out of a simple setup straight into everything at once — every metric, every customisation, no structure to any of it. People reached a plan and could not tell what it was worth or how to change it.
Lead with a usable default, not analysis
The early redesigns still treated results as a place to compare and tune: metric bars, adjust-for controls, even a weighted score to point at the balanced option. We moved to showing that balanced plan by default instead, with alternatives framed as goals — fastest, least soil loss — and the depth kept for the people who need it.
Plan-defining choices early, refinements late
Goals that define the plan, like fewest tracks or fastest completion, moved to the start of the flow. The things you can only judge by looking at the map — heading, headlands, tram lines, extending tracks, shifting rows, redrawing a boundary — stayed with the result, so nobody has to predict them upfront.
Results became somewhere you work
A plan is generated by the time you arrive, on smart defaults, and it answers as you change it rather than sending you back to regenerate. Plan From shows the reference plan beside the new one and disconnects when the new plan has moved far enough to be its own thing — one results experience either way.
Contextual, progressive, scalable
Start with intent and a strong default, show the result immediately, put adjustments where you can see what they do, and disclose the rest only when it becomes relevant. Drawing follows the same rule: you enter it because you are trying to do something, not because it is a feature on a toolbar.
Where we stand now
Forage harvest is the piece in progress. It is three jobs that depend on each other — mow, rake, harvest — and rather than making a farmer plan each one and hold the dependencies in their head, one action generates all three from the mowing setup. In V1 only mowing is editable and the other two follow from it.
Comparing them is the part we keep testing. An operation selector switches which plan the map shows, and picking more than one drops to a summary rather than stacking every layer of every plan, which looks like a lot and tells you nothing.
The rest is designing against real constraints rather than around them. Every screen has to work at roughly 600 by 500 pixels because that is what some of these machines have, the build sits on Angular Material so custom work goes where it earns its place, and a big field can take up to a minute to process, which the interface has to be honest about instead of implying an instant answer.
The open questions are worth being open about. Splitting a field into zones raises real architecture questions — who owns the geometry, what a guidance line belongs to, how routes cross a shared headland, what undo means afterwards — and none of those are settled yet.
What we built
Split UI
Split a field into parts that each get their own plan, or split only the inner working area and keep one shared headland around the outside. You choose which before you draw, and selection plus apply-to-one or apply-to-all makes it clear whether a change lands on one part or the whole field.
Drawing on maps and reference lines
Draw, import, save and reuse an alignment line, align tracks to it, or use it to split a field. Drawing opens because you are trying to do something rather than sitting on a toolbar as a mode, and the map quietens around it so the line is the thing you can see.
Results
One balanced plan, an accordion opening a section at a time rather than a wall of settings, and time, tracks and distance sitting under the map where the decision gets made.
Plan From
Build a new plan on an existing one, with search and a preview so two similar base plans can be told apart, and detach when the new one needs to stop following the old. The same surface carries the seasonal work: mowing, raking and harvesting generated together, an operation selector on the map, and a summary when more than one is shown.