The Sensor Dashboard Nobody Could Use
A team built a web dashboard for a school's greenhouse automation project. It shows soil moisture, temperature, and pump status from eight sensors. The only user is the agriculture teacher, who checks it on a staffroom desktop during lunch. The team ran no user testing and instead added features they found impressive: a live-updating 3D model of the greenhouse, a colour-coded heat map refreshing every 200 ms, and a settings panel with 34 options. In the first week the teacher used the dashboard twice, then stopped and asked the caretaker to check the plants manually. In a brief interview she said: "I can't tell if the pump is on right now, and the page keeps jumping." The team's proposed fix is to add a tutorial overlay explaining the 3D model.
1. Diagnose the usability failure using user-centred design principles, and evaluate the team's proposed fix.
Read the worked answer
The design failed because it was driven by builder interest rather than user tasks. Applying user-centred design:
Task analysis was skipped. The teacher's real question is binary and urgent: is the pump on, and is anything wrong? That is a status-check task, not an exploration task. The dashboard answers a different question - "is this impressive?" - so it does not support the actual goal.
Information hierarchy is inverted. The most important state (pump on/off, alerts) is buried under a 3D model and a heat map. Visibility of system status is the first thing a monitoring interface must satisfy; here it is absent.
Feedback is excessive rather than informative. A 200 ms refresh is roughly five updates per second, far faster than any greenhouse variable changes. It causes the "jumping" the teacher described and makes reading values hard. Feedback should be timely, not maximal.
Feature creep replaced simplicity. 34 settings options impose a configuration burden on a single non-technical user who will never need most of them.
The proposed tutorial is the wrong fix. A tutorial teaches the user to work around a bad design; it does not remove the mismatch. If the interface needs an overlay to explain its central element, the central element is probably unnecessary. Worse, a one-off tutorial will not be remembered weeks later when the teacher next checks.
The correct fix is to redesign around the task: a large pump status indicator, a small set of threshold alerts, and a simple trend line, with the 3D model and heat map removed or hidden behind an optional view.
2. Propose a lightweight user-centred process the team can run in one week, and explain how it would have changed the outcome.
Read the worked answer
Day 1 - contextual interview and task list. Watch the teacher check the greenhouse, ideally at the time she normally does it. Record the questions she actually asks and the decisions she makes from them. Output: a ranked list of three to five tasks, e.g. "confirm pump is running", "spot a dry bed", "decide whether to intervene".
Day 2 - low-fidelity prototype. Sketch the screen on paper or in a simple wireframe, built around those tasks. No code.
Day 3 - think-aloud test with the teacher. Five short scenarios: "the pump has just stopped - can you tell?" Note where she hesitates. Paper is cheap enough to redraw the same afternoon.
Day 4 - revise and build the minimum. Implement only what survived testing. Set the refresh to something meaningful, such as every 10 seconds, and reduce settings to the two or three the teacher would actually change.
Day 5 - verify in the real setting. Have her use it once in the staffroom on the actual desktop, then confirm she would rely on it instead of the caretaker.
How this changes the outcome. The interview would have surfaced the pump-status question before any code was written, making the 3D model's irrelevance obvious. The think-aloud test would have caught the refresh-induced jumping in an afternoon rather than after a week of abandonment. The paper prototype costs almost nothing, so the team loses no build time - it merely spends the first days learning what to build.
The general principle: usability problems are cheapest to fix before implementation, and the cost of discovering them rises sharply with each stage of the lifecycle.