Farm Sensor Dashboard: Interface for Non-Technical Users
A family farm installs soil-moisture sensors in 12 paddocks. Readings arrive every 15 minutes and are stored as raw numbers from 0 to 100. The farm manager, who is 62 and uses reading glasses, checks the dashboard on a phone in bright sunlight. The current screen lists every reading in a dense table with grey text on a light background. The manager has twice missed a dry paddock and irrigated the wrong one. The farm wants an alert when moisture drops below a threshold set per paddock, because sandy soil dries faster than clay. The developer has budget for one interface revision before the growing season starts in 6 weeks.
1. Apply interface design principles to identify the main usability failures and propose a revised display.
Read the worked answer
Failures identified:
- Contrast: grey text on a light background is hard to read in sunlight, which is a real environmental constraint for a phone outdoors.
- Density: a table of raw numbers forces the manager to interpret values, raising cognitive load and error risk.
- No hierarchy: all paddocks look equal, so a dry paddock does not stand out. This matches the two missed alerts.
- No context: raw 0-100 values lack meaning without the per-paddock threshold.
Revised display:
- Show paddocks as large cards, sorted so those below threshold appear first.
- Use a status word plus colour and an icon, not colour alone, so it works for colour-vision differences and in glare.
- Display each reading against its own threshold, such as '18 of 30 minimum'.
- Use high-contrast text and larger type suitable for the manager's eyesight.
- Put a single summary line at the top: number of paddocks needing water.
Justification: Each change targets an observed error, not a preference.
2. The farm wants per-paddock thresholds. Explain how this requirement interacts with the alert design and what could go wrong if it is implemented naively.
Read the worked answer
Per-paddock thresholds are necessary because soil type changes drying rate. A single global threshold would either trigger false alerts on clay or miss early dryness on sand.
Naive implementation risks:
- If thresholds are stored in code, changing them needs a developer, which is impractical mid-season.
- If the dashboard compares each reading to the wrong paddock's threshold after paddocks are reordered, alerts become meaningless.
- If alerts fire on a single low reading, a faulty sensor or a recent irrigation could trigger a false alarm.
Better approach: Store thresholds as editable settings tied to a paddock ID, not a row position. Require a low reading to persist across two consecutive samples (30 minutes) before alerting, and show the last update time so a stale sensor is visible. Provide a simple settings screen the manager can use. Note that the 6-week deadline allows the display revision and threshold settings, but the two-sample rule should be tested against real sensor noise before the season starts.