Where Drone Data Meets Field Reality
The Short Version
A Palmetto (Heart of Palm) farm did not keep field-activity records. Our team produced multispectral drone imagery but needed to understand ground activity to have better interpretations. So we built a system that would create and organize records along vegetative indexes. Try the live prototype here.
“A product [that provides visibility into field operations, along multispectral readings], would be already paid for.”
— Agronomist (client), upon hearing the concept and seeing the prototype
The Data Gap That Revealed the Product
The project started as drone work and multispectral image processing with PDF deliverables. The client hired our team to conduct an 11 month pilot consisting of periodic multispectral captures: flights that produce vegetative index maps capable of detecting crop stress, disease, and yield anomalies invisible to the naked eye. My role was project manager for this commercial-development hybrid engagement.
The problem: vegetative index maps can be ambiguous and difficult to interpret. A drop in NDVI over a plot could mean unhealthy crops, or it could mean the plot was recently harvested, pruned, or chemically treated. Without knowing what happened on the ground, every interpretation required a conversation, an investigation, or a site visit. To have a better understanding of crop health, we asked the client for historical field records to cross-reference with vegetative indexes. The client did not have any formal records.
The farm supervisor tracked daily work mentally and on their notebook. Records made sense to them, but they were not structured or searchable for the team. This was not negligence, it was the reality of how operations ran before anyone asked for the data.
As we worked on multispectral image analysis, we requested field records in order to better understand what vegetative indexes indicated. The Lead Agronomist made a spreadsheet template for work to be registered and delivered weekly. Without this spreadsheet, there were no records, so to speak. The client handed us this data and I digitized it. We could start to make sense of the multispectral readings and we had a proof of concept for the product. Then we set out to synthesize this manual loop field → paper → scan → spreadsheet → analysis into an operational platform.
| Before | After |
|---|---|
| Field activity recorded on paper: ~3–6 records per day, handwritten by the farm supervisor | Structured digital field records, logged directly from the office desktop and mobile responsive site |
| Data manually transcribed into a spreadsheet: hard to read, errors, omissions, and interpretation gaps at every step | Activity data organized per plot, per activity type, per unit of measure, per worker, ready to cross with drone flight data |
| No aerial view, no vegetative health readings, no structured record of any kind | Aerial interactive map with radiometry layers, control zones and georeferenced notes |
Built on the Fly
This was not a traditional UX project. Operating without a dedicated discovery sprint, research budget, or set timeline, the product had to evolve in parallel with an active client engagement. Because my role spanned beyond design (encompassing commercial relationship management, drone operations coordination, and product definition) there was no room for a formal research phase. Instead, every client session and site visit meant double duty as our primary means of discovery.
Discovery ran across roughly 10 client sessions and 6 farm visits over three months. Recurring conversations surfaced operational frustrations; on-site time made them concrete. Watching how the general manager, agronomist, and supervisor actually coordinated work clarified what the platform needed to do – more information than a brief could have gathered.
There was also a longer backstory. More than a year ago, working on the first precision agriculture engagement (different client, different crop), I had designed and prototyped a multispectral data viewer in Figma: a map-based interface for reading vegetative index data from above, viewing planimetric layers, and navigating the farm per plot. The project did not move past the pilot stage. Budget and software development costs made it unviable. But all the research, prototyping, and thinking about how to interpret spatial data stayed with me. When this project needed a similar capability, the foundation was already there.
Simplicity at the Center
The early concept centered on a full office-to-field task flow: administrators create tasks on desktop, supervisors receive and execute them on mobile. It made sense on a whiteboard and in concept. Client sessions told a different story. The actual urgency was simpler: get field activity into structured digital form to be able to take actions now. A task management layer added coordination overhead the client was not ready to absorb. We made the call to build field recording first and treat task management as a later phase, once the habit of digital logging was established.
Getting the recording form right turned out to be its own design problem. The first version was a catch-all form of categories and general fields. It felt thorough, but in practice, it led to messy data and a fragmented structure. Agricultural work is activity-specific—a harvest is not a fumigation, and a fertilization is not a soil reading. The solution was to surface only the exact fields each task required: stem counts for harvests, product quantity for fumigations, and specific dual-device metrics for soil sampling. By matching the form to the activity, cognitive load dropped and the data got cleaner.
However, activity-specific fields only solved the immediate problem. The deeper challenge was scale: what happens with a different crop or an unanticipated activity? Hardcoding fields would just defer the rigidity, making every future change dependent on engineering.
The answer was a Template Creator. Before designing, I mapped the logical relationships between activities, groups, elements, and units of measure in a Google Sheets table. That structure became Settings > Templates, where administrators can activate preset activity templates or build new ones from scratch—defining the activity name, organizing fields into groups, and assigning units of measure (Liters/Ha, Stems, pH, etc.). Fertilization, for example, can be split into root-based and leaf-based groups, allowing a foliar product like Fitokel to dynamically pull Liters/Ha. Because the core form shell remains the same across all activities, the template simply drives what appears at runtime. The goal was flexibility at scale: adapting to a different farm, crop, or workflow without requiring engineering involvement.
Reading the Land
The recording layer solved the input problem. The harder question was what to do with the output.
The core challenge was that spectral data is ambiguous without field context – a design dimension that took time to surface. Our multispectral team delivered precise, plot-level readings: deficiency percentage, vegetative vigor, NDVI, GNDVI, and NDRE. Those numbers were mathematically real, but what they actually meant depended entirely on what happened on the ground during the measurement window. A plot showing a high deficiency right after a heavy harvest means something completely different than a plot showing that same deficiency with no recent activity. The spectral signatures look identical; the interpretations do not. To bridge this gap, I developed “State”: a two-level health indicator.
Tier 1 (Spectral): Raw deficiency percentages place the plot into a baseline category: Healthy, Moderate, or Critical.
Tier 2 (Contextual): If a recent activity (like a harvest) explains the vegetation drop, the State automatically adjusts—softening a Critical reading to Moderate.
When the two tiers diverge, the platform displays both in a spectral → interpreted format. By seeing the raw signal alongside the contextual reality, the agronomist gets the full story at a glance and can decide exactly how to act.
To make this data truly actionable at scale, we integrated Control Zones (developed by the multispectral engineering team). These are specific sub-areas within a plot that can be flagged and tracked independently across drone flights. A plot can look stable globally, while a single Control Zone within it is critical. This granularity prevents critical localized issues from being averaged out by the rest of the field.
Ultimately, this is a design for attention management under tight, real-world constraints. Agronomists typically visit a farm just once or twice a month, often enduring a seven hour journey each way. They cannot thoroughly walk the entire property in a single day. Multispectral readings allow them to “read” the entire farm before they even arrive – instantly knowing which plots warrant urgent attention, which ones explain their own data through recent activity, and precisely where to spend their limited hours on the ground. The question shifts from “Where do I start?” to “I already know where to go.”
The Platform
The desktop app is the office administrator’s primary workspace, turning complex farm logistics into a clean, predictable workflow:
- Dynamic Forms: Selecting an activity automatically renders the correct form from its matching template.
- Activity Feed: A centralized log of all farm activities, filterable by date, plot, or type, with
.xlsxexport capabilities. - Unified Data: Spectral data, plot-level State indicators, and Control Zone management sit directly alongside operational records.
- Administration: Dedicated modules for managing workers, supervisors, templates, and in-app contextual help.
To ensure a frictionless transition to MVP production, the final delivery package for engineering contained:
- Design System Assets: A foundational CSS token system and a component inventory of 14 reusable elements.
- Functional Prototype: A full-fidelity interactive prototype developed with Claude Code.
- Documentation: A comprehensive Functional Specifications Document (v3.1) covering user roles, the data model, API contracts, and business rules. AI-assisted sections of the FSD were explicitly tagged for independent engineering review and sign-off.
Next Steps
With the MVP now live, we are moving directly into a dedicated user testing phase while simultaneously onboarding our next cohort of clients. Working with new operations will immediately reveal whether the core templates require further adjustments to accommodate different farm structures and workflows. For this initial launch, our validation strategy focuses on answering two critical questions across our primary user roles.
1. The Records Module
Can farm supervisors reliably log field activities (given their digital literacy baseline and frequent offline scenarios) without the system becoming an operational burden?
| Metric | Method | Target |
|---|---|---|
| Time on Task (log one field record) | Moderated usability test, timed | Establish baseline; reduce vs. paper |
| Task Error Rate | Moderated usability test, observed | ≤ 1 critical error per entry |
| System Usability Scale (SUS) | Post-test questionnaire | ≥ 80 (Good / Excellent) |
2. The Radiometry Module
Does the State layer successfully change how agronomists navigate, interpret, and act on flight data before making their seven-hour drive?
| Metric | Method | Target |
|---|---|---|
| Time on Task (view a Plot Panel) | Moderated usability test, timed | Establish baseline |
| Time on Task (view a Control Zone panel) | Moderated usability test, timed | Establish baseline |
| Task Completion (create Control Zone + add note) | Moderated usability test, observed | ≥ 80% completion without assistance |
Closing the Loop
As Phase 1 undergoes live testing, Phase 2 mobile development is kicking off using the finalized specifications and prototypes. The goal is to fully close the operational loop: allowing activity data to be captured directly in the field and synced to the desktop platform the very same day.
The long-term value of this architecture will compound over time. By pairing continuous field logs with historical spectral flight data – indexed tightly by plot and date – the question that sparked this entire project (“Is that stress signature a dying crop or just a recent harvest?”) will finally receive an automated, definitive, data-driven answer.