GrainGuard:
IoT Grain Monitoring System for Independent Farmers
GrainGuard is an integrated monitoring system that enables independent farmers to proactively manage storage conditions and detect risks before loss occurs. Designed with a Washington-based farmer facing $30,000 in annual preventable losses, it was built specifically for the constraints of small-farm realities. (Sponsored by Microsoft)
Product Designer
My Role
1 Product Designer (Me)
1 Software Engineer
1 Hardware Engineer
1 Data Analyst
Team
3 Months (2025)
Duration
User Research
Data-Driven UX Design
Rapid Iteration
Design System
Key Contribution
01 Real-World Stakes
For independent farmers, grain quality depends on manual checks—labor-intensive, reactive, and often too late to prevent loss. Commercial monitoring systems exist, but they are designed for large-scale operations and priced beyond small-farm realities.
At a small-farm scale, this creates a no-win situation: absorb ongoing labor and spoilage costs, or invest in systems that are financially unrealistic.
❌ Solution 1: Manual Check
❌ Solution 2: Large-farm system
Labor cost: $1200+ /Bin/Year
Grain lost: $1900+ /Bin/Year
System cost: $3500+ /Bin/Year
💭 Desired Solution:
“I’m not technical—I just need something simple, low-cost, and reliable that tells me before it’s too late.”
Together with a Microsoft industry sponsor and a Washington-based farmer, we began designing a monitoring system built specifically for small farms — starting with one core question: how to turn invisible storage conditions into decisions a non-technical farmer can act on immediately?
02 Framing the Invisible Problem
Ambiguity — When Uncertainty Had No Structure
Before designing sensors or interfaces, I first clarified what the farmer's question actually meant in operational terms — because there were no defined indicators, thresholds, or criteria for action.
Translating Vague Concerns into System Structure
To define that structure, I examined how storage decisions were actually made in practice. Through interviews, contextual inquiry, and workflow mapping, I mapped the existing decision flow — how farmers assessed conditions, coordinated with workers, and chose when and how to act.
As a result, I identified that the original question — “What’s happening in my bin?” — was not a single need, but a compound request embedded in different operational concerns.
Understanding the Current Decision Flow
From “What’s happening?” to Actionable Information
15 bins to manage
Across 4 distributed locations
Limited on-site staffing
“What’s happening in my bin?”
Request for “Quantity”
Why this matters
Farmers manage multiple bins across distributed locations. Without visibility into stored volume — and how it changes over time — they cannot effectively plan transport, balance storage, or prepare for peak seasons.
What information is needed
To support these decisions, the system must answer:
How much grain is stored in total?
How much is stored per bin?
How is the fill level changing over time?
These signals provide both a current snapshot and a forward-looking trend.
How it translates into the system
LiDAR sensors measure fill level continuously.
The dashboard presents real-time volume and historical trends to support logistics decisions.
Request for “Quality”
Why this matters
Grain can deteriorate due to environmental conditions or pest infestation. Without early detection, spoilage spreads and leads to irreversible loss.
What information is needed
To understand storage health, we examined the primary causes of grain deterioration:
Temperature fluctuations
Excessive humidity
Insect infestation
To detect insect outbreaks early, CO₂ spikes were identified as a measurable indicator of rapid insect activity.
How it translates into the system
Sensors monitor temperature, humidity, and CO₂ levels continuously.
The dashboard prioritizes anomalies and pushes real-time alerts to support timely intervention.
Defining Clear Criteria for Success
The ultimate goal was not simply to measure storage conditions, but to reduce spoilage, minimize unnecessary manual inspection, and enable earlier intervention.
Once measurable signals were defined, we established performance benchmarks to verify the system could reliably support those outcomes in practice.
±5%
Fill level measurement accuracy within ±5% of calibrated volume.
≤ 120 s
Risk anomalies must be surfaced within 120 seconds of threshold breach.
≥30%
Reduce routine manual inspection frequency by ≥30% in stable operating periods.
03 Designing for Intervention
From Information to Action
My initial prototype treated alerts as informational signals embedded within the interface. During usability testing, users could see anomalies but were unclear which required immediate attention or how to respond.
This revealed a structural gap: visibility alone did not lead to action. The system had to define when intervention was required and who was responsible for resolving it.
Alert State Model — Clarifying Responsibility
To operationalize intervention, I formalized alerts as system states with clear transitions. Once triggered by validated anomaly events, an alert enters an Active state and remains so until manually resolved after inspection. This model establishes explicit ownership and prevents risk from being dismissed through passive normalization.
Making Risk Visible
Alert Center: From History List to Control Panel
The Alert Center functions as the system’s operational control panel. It consolidates active risk signals, surfaces them by priority and type, and provides contextual interpretation to support timely intervention.
Drag to compare before and after
❌ Before:
Primarily a historical alert list grouped by type, offering visibility but limited prioritization or action support.
✅ After:
A structured control panel that prioritizes active risks, centralizes context, and supports triage and resolution tracking.
Structured Alert Types
Anomalies are organized into 5 clear categories to support quick recognition and triage.
My Tanks: Designing a Scannable Monitoring View
My Tanks serves as the primary surface for daily monitoring. Each tank card was redesigned to integrate storage status and key condition signals into a single scannable unit, while keeping detailed inspection accessible when needed.
Drag to compare before and after
❌ Before:
Bin cards showed basic metrics only — farmers had to navigate away from the monitoring grid to understand whether a condition was actually dangerous, breaking their scanning flow.
✅ After:
Each card now surfaces condition signals directly, enabling users to identify risk without leaving the monitoring grid.
Deep Inspection Layer
Selecting a tank opens a detailed view with historical trends and anomaly context for validation and investigation.
04 Designing for Operational Clarity
System-Level View
The dashboard provides a consolidated operational view of the system. Capacity, active risk signals, temporal trends, and geographic distribution are organized into a single surface to support high-level planning before deeper inspection.
System Status
Aggregate Capacity
Primary System Action
Active Risk Summary
Geographic Distribution
Temporal Trend
Object-Level Representation
At the bin level, storage is spatial rather than statistical — farmers think in terms of physical fullness, not abstract numbers. I explored multiple visual forms before adopting a layered structure that mirrors the physical tank. Each layer corresponds to a capacity threshold, making fill level immediately interpretable.
❌ Linear Progress Bar:
👨🌾 Farmer feedback: “I like that there’s a fill bar - it’s helpful. But it still feels a bit abstract. It’s hard for me and my on-site staff to relate it to how full the bin actually is.”
❌ Tank Shape with Percentage:
The bin silhouette made the storage level more recognizable. However, directly visualizing the exact percentage added cognitive load without meaningfully changing how farmers made decisions.
✅ Final Version -- Segmented Tank Representation:
The bin is divided into four 25% capacity segments. Visual state changes occur only after volume crosses the midpoint of each segment, creating five stable occupancy states and preventing unnecessary visual fluctuation.
0-12.5%
12.5-37.5%
37.5-67.5%
67.5-87.5%
87.5-100%
Cross-Unit Organization
Farmers often oversee bins distributed across multiple sites. During usability testing, location emerged as the natural organizing principle, while remaining storage and device power level were consistently cited as the most relevant signals for prioritization. Every organizational decision - location grouping, sort order, signal priority - came directly from how farmers already think about their operation.
Grouping by Location
Tanks are organized by site to reflect how farms operate physically.
Sorting by Operational Signals
Tanks can be reordered by remaining storage or device power level, supporting operational prioritization across tanks.
05 Integrated System
End-to-End System Flow
GrainGuard integrates on-site sensors, local displays, and a centralized web dashboard through a cloud backend, forming a continuous monitoring loop. Real-time data flows from physical tanks to actionable interfaces, enabling farmers to interpret storage conditions, respond to anomalies, and coordinate operations across locations with clarity.
Sensor:
Measures fill level, CO₂, humidity, and temperature inside bins.
Local Display:
Shows real-time readings directly on site.
Cloud Backend:
Stores and processes sensor data for reliable access.
Website:
Visualizes trends and alerts for multi-bin management.
Building a Scalable Design Foundation
To support consistency across dashboards, tank views, and alerts, I established a design system built on reusable components introduced earlier, alongside foundational elements such as color, typography, iconography, and interaction patterns. This structure ensured visual coherence and scalability as the platform expanded.
Final Design
The final system translates sensor data, alert logic, and user actions into a cohesive operational interface. From real-time monitoring to alert handling and decision-making, each interaction is designed to support clear ownership and timely intervention—turning fragmented signals into actionable workflows.
Validation in Real-World Context
Validation was conducted in a simulated grain storage environment - a physical setup replicating real bin conditions - allowing the team to verify end-to-end data flow from sensor readings to dashboard alerts in a controlled real-world context.
Within a tight 3-month timeline spanning design, hardware integration, software engineering, and usability testing, our team delivered a fully functional prototype under Microsoft industry sponsorship. Following the demonstration, the partner farmer indicated readiness to move toward deployment, validating that the system had addressed a real operational need.
