A fleet-management system running mines around the world had grown screen by screen. We reduced it to twelve display types, then wrote the standards that decided every screen after us.
Two of the twelve display types. Left: mine control — haul routes grouped by area, each area stating its own shortfall (Have 24, Need 23) with a live queue for shovels, dumps and the maintenance shop along the bottom. Right: task management — drilling, blasting, washing and mucking laid out per tunnel against the shift clock, headed by a standing warning line: “LHD 230 is allocated to overlapping tasks.”
display types mapped, wireframed and specified — from KPI ticker to underground schematic.
phases, April 2005 to January 2006: mapping, wireframes, design, standards.
guideline sets — UI and visual — published as a browsable internal standard.
design language across DISPATCH and IntelliMine, replacing per-module invention.
Before a wireframe existed we mapped what kinds of display the system actually needed — push monitoring, spatial map, schematic, task management, line-up, historical data edit, time categorisation, configuration, KPI ticker — each with its users, purpose and requirements written down. Twelve types covered a product with hundreds of screens.
An audience definition set out who the system serves — dispatchers, mine controllers, equipment and maintenance staff, engineers auditing bad data, underground crews — and which of them shared a display type. That mapping is what let twelve types cover the whole product.
A scenario workshop produced usage scenarios and the data behind them, so wireframes were argued against real dispatch situations — a truck down, a machine double-booked across two tasks, an emergency message that must not scroll off the screen — rather than against a feature list.
Design iterations ran near-weekly through the second half of 2005, each dated and sent to the client for review. The working folder is the method: small increments, frequent exposure, notes back every round.
The usability test ran in November 2005; the guidelines were finalised after it. Rules written before evidence encode opinion — running the test first meant the standard said what the testing supported.
Navigation rules, main form controls, standard templates and general rules went into Usability Central — a browsable internal site — rather than a PDF that ages quietly on a shared drive.
“Lay out the screen to optimize the efficiency of visual access… Use the grid to maintain consistency across the various screen layouts for the different screen types.”Visual Guidelines v1.0 · 21 October 2005
The UI and visual guidelines, the navigation rules and the display-type templates were adopted as Modular Mining's own — the way interface got built there afterwards, by people who were never on this engagement. The standards outlived the project that produced them, which is the only real test of a standards programme.
Specifying the display type meant every future screen inherited a decided layout, navigation model and control set. Designing screens one at a time doesn't outlast the engagement that paid for it.
Publishing into Usability Central made the rules searchable, linkable and updatable by the client's own team. A standard nobody can find is a standard nobody follows.
Every area heading reads Have 24, Need 23. The dispatcher's real question is whether they are short and by how much — so the screen answers that, instead of printing two numbers and leaving the subtraction to a person under time pressure.