Operations software is judged in a specific way: not on how impressive it looks in a demo, but on whether someone under pressure reaches for it instead of the spreadsheet and the phone. That shapes every decision in the prototype.
Lead with the decision, not the data
The first screen should answer the question the team actually opens the tool to ask — what needs attention right now. A landing page full of charts nobody acts on is the most common failure mode in operations software, and it is invisible until real users arrive.
Make status legible at a glance
Operations users scan before they read. Colour, position and grouping carry more of the meaning than labels do, and the difference between fine, watch this, and act now has to survive being seen from across a room on a wall display.
Treat alerting as a design problem
An alert that fires too often gets muted, and a muted alert is worse than no alert because everyone believes it is still working. Thresholds, grouping, acknowledgement and escalation belong in the prototype, not in a later phase.
Put geography in only where it earns its place
Maps are useful when the question is genuinely spatial — where the vessel is, which section of road, which stand at the airport. Where the question is about status or sequence, a map is decoration that costs load time and mobile performance.
Assume the integrations will be messier than promised
The data model has to survive fields that are sometimes null, timestamps in two zones, identifiers that do not match between systems, and a feed that goes quiet for an hour. Designing for that from the start is far cheaper than retrofitting it once a pilot exposes it.
