Most dashboards are built for people sitting still. FarmSense is built for people who move—across acres, across uncertainty, across seasons that refuse to behave.
Growers wake up before sunrise, walk fields that stretch further than your eye wants to focus, and make decisions that cost real money if they’re late by even a day. Pest activity doesn’t wait for clean UI. Heat accumulates. Insects develop. Thresholds are crossed quietly.
FarmSense monitors that invisible escalation. It captures real-time sensor data—insect counts, environmental shifts, thermal accumulation—and translates it into signals growers can act on before crop loss becomes visible from the highway.
Our mission for this project sounded deceptively simple: turn entomology, telemetry, and environmental modeling into a system where a grower can open the dashboard and immediately understand three things—what’s happening, how urgent it is, and what to do next. The reality was a dense system of relationships, edge cases, and decisions under pressure.
Here’s how we made a dense agricultural ecosystem feel navigable—and reliable—in real time. Keep reading!
About the Client
FarmSense is a U.S.-based AgTech company focused on data-driven pest management. Their hardware captures insect activity and environmental data. Their software interprets it. Together, they aim to reduce crop loss while lowering unnecessary pesticide use.
The client team included developers who deeply understood the domain logic. Not “we skimmed the documentation” familiarity—actual fluency in insect growth cycles, sensor states, and device telemetry. That changed the rhythm of the project.
We weren’t designing in isolation and then waiting for validation. We were on calls dissecting edge cases: what happens when a sensor goes offline mid-cycle? How should thermal-day accumulation behave when temperature spikes overnight? Which insect thresholds matter per crop?
Direct communication with the engineer became one of the most valuable tools in the project. It shortened feedback loops. It prevented decorative assumptions. It grounded the interface in reality.
The Brief
The goal was to design a comprehensive dashboard for complex agricultural sensor data. We needed an interface capable of holding a high cognitive load without overwhelming users with agricultural jargon or raw telemetry. Some users were comfortable with data. Others cared about one thing: “Do I need to act today?”
At the same time, the UI had to reflect FarmSense’s brand identity. It was a field product, and it needed to feel credible, precise, and durable—like equipment you trust.
Challenges Identified Up Front
Translating scientific and entomological insights into digestible UI elements was the first friction point. Insects develop faster with more heat. That’s obvious to entomologists. In UI, that logic has to become visible, trackable, and urgent without becoming cryptic.
Then came object relationships. Devices belonged to organizations. Organizations had administrators. Sensors lived in fields. Fields were linked to crops. Crops were vulnerable to specific insects. Insects had growth stages driven by thermal days. Each entity had states and thresholds.
Instead of simply designing screens, we were mapping a living system.
And then there were real-world constraints. Pest outbreaks don’t politely escalate; field conditions vary; users might check data in an office chair or while standing between crop rows with limited connectivity. Literacy levels around data vary just as widely.
Research & Functional Architecture
We began with market research and functional analysis. What tools are growers already using? Where do they struggle? What does “too much information” actually look like in agricultural software?
Then we mapped the product architecture. Fields, sensors, device states, insect profiles, crops. We diagrammed relationships like we were building a subway map—making sure no line crossed without reason. At the same time, the client already had an earlier version of the product in place. Part of our work was understanding that existing system—its logic, constraints, and user feedback—and evolving it rather than starting from a blank canvas. The redesign had to respect what already worked while making the structure clearer, more scalable, and easier to navigate.
A heavy iteration loop formed between design and engineering. Much of the logic revolved around what the team called “degree days”—a thermal accumulation model used to predict insect development and activity. Pest thresholds were decision triggers tied to these heat-based growth cycles. In parallel, the system also needed to reflect crop growth stages, since certain phases of plant development can directly influence insect behavior and treatment timing. The engineer would explain how these models interacted—heat accumulation, insect lifecycle stages, crop growth phases. We’d prototype how that logic surfaces in the interface. He’d point out an edge case. We’d refine. This loop repeated until the structure made sense both scientifically and operationally.
Design Takeaways
One insight shaped much of the UI: insects develop faster with more heat. That biological fact became a design driver.
Users needed to see thermal accumulation clearly. More importantly, they needed to sense urgency before an outbreak threshold was reached. We designed visual cues that escalate—not in dramatic red banners, but in calibrated signals that build tension as risk increases.
It’s similar to how you notice your car’s fuel gauge dipping long before the tank is empty. The goal wasn’t panic, it was awareness.
UX & User Flows
We built detailed user flows for critical actions. Managing devices meant handling multiple states: assigning to organizations, marking as broken, sending for repair, decommissioning. Each transition had consequences. The flow had to be predictable.
Creating and visualizing field entities required spatial clarity. Users needed to understand which sensors belonged to which fields and how that tied to crop vulnerability.
Tracking insect activity meant surfacing alerts that were actionable. Not abstract graphs. Decisions.
The UX phase involved multiple iteration rounds. Stakeholders brought different perspectives: engineering feasibility, agronomic accuracy, operational clarity. Each review sharpened the system.
UX Focus
We kept returning to three principles:
- Make complex data simple to act on.
- Define clear paths for both novice and experienced users.
- Maintain clarity under high information density.
High-density dashboards fail when hierarchy collapses. We used modular components, consistent spacing tokens, and restrained typography scales to keep the interface breathable. The goal wasn’t minimalism. It was legibility under stress.
UI Concept & Visual Design
All architecture, wireframes, and UI workflows were executed in Figma. Not as a static canvas, but as a system.
We defined components and states early. Cards for fields. Badges for device status. Alert modules that could scale in intensity without breaking layout. Design tokens controlled color, spacing, and typography so escalation states remained consistent across screens.
The dashboard screens were intentionally data-dense, but structured. Visual hierarchy did the heavy lifting: primary metrics surfaced first, secondary context nested below. No decorative gradients competing with numbers that matter.
Admin Panel & Interaction Design
The admin dashboard managed interconnected entities.
Organizations had separate administrator lists. Devices existed in multiple states: available in a general pool, assigned to organizations, broken and sent for repair, decommissioned for disposal. Insects and crops had dedicated management lists with clear add, edit, and delete actions. Profiles applied specific configurations to insect data.
The UX intent was to unite all entities into a single coherent system. Relationships had to be visible. If a device changed state, its implications needed to ripple logically through the interface.
Hierarchy became our discipline. Clean structure over clever visuals. Clear affordances over experimentation.
Cross-Platform Considerations
FarmSense operates in agricultural environments. That means users might access data from a desktop in an office or from a mobile device in the field.
We designed responsive behaviors that prioritize readability and essential actions. On smaller screens, secondary data compresses gracefully. Core alerts remain prominent. Interaction targets remain generous enough for real-world conditions—not lab-perfect cursor precision.
Context matters. We designed for it.
Final Reflections
FarmSense was ultimately a translation challenge. We took scientific, entomological, and sensor-driven complexity and structured it into workflows that feel usable in real agricultural contexts.
What we learned along the way is, complexity isn’t the enemy. Ambiguity is. Growers are not afraid of data. They live inside uncertainty every season—weather shifts, market pressure, biological variability. What they need is structure that respects their expertise while reducing cognitive friction. A well-designed system doesn’t simplify reality, it doesn’t dumb things down; it makes cause and effect visible.
We also learned that urgency is a design material. Thermal days accumulating over time are not dramatic in themselves. But when tied to pest thresholds, they carry tension. The interface had to express that escalation without theatrics.
Design, at its best, makes expertise usable. In FarmSense, agricultural data stopped being abstract telemetry and became operational clarity.
And that shift—from data to decision—is where product design proves its worth.
Recommended Reading
If you enjoyed this case study, you might also like:
Fireside Case Study: Turning Sterile into Human
Case Study: Orakle. Modern Web Design for Medical Education
Case Study: ABUK—Designing Ukraine’s Leading Audiobook Platform
