VineOps: Autonomous vineyard rover platform
Lead product designer on the v2 redesign of an autonomous rover platform for California vineyards. Translated onboard rover data into operational decisions for vineyard managers and crew. End-to-end UX across iPad and mobile.
2024
Year
14 Mo [pt]
Duration
AgriTech + AI
Category
Figma | Figjam | Miro
Stack
Problem
A major agricultural equipment manufacturer had built an autonomous rover for California vineyards. The hardware was advanced — onboard cameras, GPS, autonomous navigation — but the software platform that would turn rover data into operational decisions hadn't shipped. A first version had been built by an external design agency, but hadn't been tested with real operators and wasn't tightly coupled to the hardware roadmap. The manufacturer needed a v2 designed embedded in the team, with direct access to engineering, the product manager, and California vineyard customers. Four problems needed solving: - Mission complexity. The v1 flows had too many steps and unclear paths. Vineyard managers couldn't tell what they were doing or why. - Connecting human and rover work. Most operations are sequential: the rover does part 1 (scouting), a human does part 2 (harvesting). v1 didn't make this handoff visible. - Task assignment with no structure. There was no clear model for who owned which jobs — rover, manager, or crew. - AI scoping. The manufacturer wanted predictive analytics, but the original ambition (a super-agent that knew everything) wasn't engineerable for v2. Project under NDA — manufacturer and product name anonymized.
Solution
I led the v2 redesign as sole product designer, partnering with the PM (a former California farmer) and one developer. We shipped in September 2025. The manager iPad app runs operations across multi-farm organizations. Managers start by setting grading thresholds, since the AI can't generate useful insights until it knows what "ready to harvest" means for their crop. The home page then surfaces farms, vehicles in the field, and harvest readiness as data builds up. Managers create vehicle jobs (scouting, spraying), the rover executes, and insights appear in a map view with heatmaps tied to the grading config. From there, managers create crew jobs or export a heatmap PDF. The crew mobile app turns those decisions into low-friction tasks for field workers. Tasks surface by location and priority; crew members read the brief, navigate, execute, and log progress back to the manager. I delivered the foundational designs and the team shipped this surface after the iPad release. The interaction model: AI as actor, UI as oversight. Managers set intent and review insights; the system acts and reports. The UI surfaces what needs human judgment (exceptions, overrides, decisions) without drowning users in operational detail. What we deliberately cut from v2: real-time video and collision avoidance, teleoperation, embedded self-service site planning, and the broader AI agent. Each became a smaller, shippable design, covered below.
Trade-offs & decisions
Three things we wanted in v2 didn't make it. Each was replaced with a smaller, shippable design — and each replacement is a more interesting story than the original ambition.
Real-time video and collision avoidance → a position-verification UI
The team wanted live camera feeds and onboard collision avoidance so managers could supervise the rover in motion and the rover could self-correct around obstacles. The hardware roadmap wasn't ready for either. Cutting them entirely would have left a safety gap: how does the manager know it's safe to start an autonomous operation?
The stopgap was an alternative pre-flight path. Before initiating autonomous scouting, the user steps through specific UI cues that confirm the rover is in the expected position, oriented correctly, and clear of obstacles in line-of-sight. Slower than real-time avoidance, but defensible — and it's the kind of design decision that exists because of a hardware constraint, not despite it.
Position verification UI
Embedded self-service site-plan creation → an activation-waiting state
Site plans are GIS maps of the vineyard — rows, blocks, varieties, boundaries. They're typically created by an external GIS company using drone imagery, then handed to the equipment manufacturer. We spent about a month exploring whether the app could let users create their own site plans in-product. It was too complex for the release timeline and would have pushed the engineering scope past what we could ship.
Instead: after a user creates their account and selects their organization, the app enters a deliberate "waiting for activation" state while the external party finishes the site plan in the background. Once it's ready, the account activates and the user lands on the home page. It's an honest seam in the experience — there is a real wait — but framing it as a state rather than a missing feature turned a UX gap into a clear status the user could understand.
Activation message and initial design site-plan creation
A "super AI agent" → harvest readiness, scoped to one decision
The original ambition was a multi-domain AI that surfaced temperature, humidity, disease detection, and harvest readiness all at once, with proactive recommendations across the board. The underlying ML platform actually supports most of this. The engineering effort to surface and reconcile all of it in the UI for v2 didn't.
For v2 we shipped harvest readiness only, scoped to a single decision the user already cared about: when and where to harvest. The system fills with data as the user creates jobs — empty on day one, useful by week three, indispensable by month two. And because the manager configures their own grading thresholds (Class 1, Class 2) before insights surface, the AI's outputs are tied to the manager's definition of "ready," not a generic prediction.
The crew mobile app didn't ship at the same time as the iPad app. The heat map PDF export was the bridge — managers could print out the AI's recommendations and assign crew manually until the mobile app was live. A stopgap shaped by a release sequence, not a missing feature.
Farm manager: AI insights, grading configuration, jobs and heat map
Farmer mobile app main screens
System architecture
Manager decision flow
AI-as-actor, UI-as-oversight roles
Crew app flow
Impact
Testers across two rounds
Prototype blocks tested
flagged confusion → drove redesign priorities
Prioritized action items shipped to backlog
Testing & Iteration
Testing was embedded throughout the design process, not added at the end. The PM (a former California farmer with direct relationships to vineyard operators) ran multiple rounds of unmoderated testing in Maze, with different participants each round. I designed the test plans, analyzed findings, and translated them into iteration decisions.
The fourth round, closest to release, ran with 10 participants across 24 prototype blocks. Three examples of what we learned:
Testers couldn't tell the system was autonomous. The most consistent finding across rounds: participants described the app as a generic fleet management tool, not an autonomous scouting platform. One tester said, "I think we need to make it more obvious throughout the application that this is meant to be an autonomous data gatherer." The value proposition was failing at the UI layer. We rewrote the guided tour, added explicit autonomy framing to empty states, and reworked the home page copy before release.
The dashboard-to-results navigation was wrong. Multiple testers reached for actions from the map dashboard, then had to backtrack into the Jobs section to do anything. One said, "Intuitively, I wanted to do that from the dashboard that shows me a map of the farm, but I actually had to go to Jobs." Completion rates were 100% on most tasks, but misclick rates ran from 33% to 77%, signaling friction we wouldn't have caught from success data alone. We restructured the flow so insights and actions surface directly from the map.
Grading terminology landed as jargon. "Need to set up grading classes…what does that mean? What is grading?" Internal vocabulary built up with the agronomy team didn't survive contact with new users. We reworked the labels, added contextual help, and rewrote the grading config onboarding.
Nine prioritized action items came out of the final round, scored by impact and effort. High-impact, low-effort items shipped first (copy clarity, CTA labels, grading terminology). Higher-effort items like the mission-results restructure and inline action shortcuts were scoped into the same release. One item, reworking the collapsible dashboard sections, was deliberately parked: the discoverability cost was real but smaller than the rebuild cost, and other findings had clearer ROI.
Designing for autonomous systems is a different discipline. The interaction model isn't "user gives command, system executes" — it's "user sets intent, system acts, user oversees." Most of the design work was building trust in the system's autonomous behavior without burying the user in operational detail.
The value proposition has to land at the UI layer, or it doesn't land at all. Testers consistently described the app as a generic fleet management tool until copy, onboarding, and empty states were rewritten to reinforce the autonomous nature of the product. The visual design alone couldn't carry the model.
High success rates can hide bad UX. Every task in the final testing round had 100% completion, but misclick rates ran from 33% to 77%. Without watching the navigation overlays and reading open feedback, we would have shipped a product that "worked" but felt frustrating. Quantitative completion data was the least useful signal in the dataset.
Ambition gets scoped at the seams. Real-time video, collision avoidance, teleoperation, embedded site-plan creation, and the broader AI agent didn't ship in v2. Each had a smaller, defensible alternative — a position-verification UI for safety, a "waiting" state for activation, a heat map PDF for crew handoff. The hard part of senior design isn't drawing the ambitious version; it's designing the honest stopgap and explaining why it was the right call 🫠.
Hardware + software design is a coordination problem. The biggest challenge wasn't UI — it was syncing release timelines, firmware capability, and UX expectations across three teams.
Next Steps
v2 shipped in September 2025 with the manager iPad app. The crew mobile app shipped separately afterward using foundational designs I delivered. The platform's broader AI capabilities — temperature, humidity, disease detection — remain on the roadmap as the data layer matures.
Project under NDA — additional context available on request.
See Also
prototype blocks tested