Case Study  /  Mining Fleet Management  ·  Enterprise Standards  ·  2005–06

NextGen Dispatch — Modular Mining

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.

Role
Design Lead
Firm
HFI
Owned
Display types · Standards
Phases
4
Mine control — routes
NextGen Dispatch mine control — haul routes grouped by area, each area headed with its truck shortfall, above a queue status strip
Mine task management
Mine task management — drilling, blasting, washing and mucking laid out per tunnel against a shift timeline, with a resource conflict warning

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.”

12

display types mapped, wireframed and specified — from KPI ticker to underground schematic.

4

phases, April 2005 to January 2006: mapping, wireframes, design, standards.

2

guideline sets — UI and visual — published as a browsable internal standard.

1

design language across DISPATCH and IntelliMine, replacing per-module invention.

The twelve display types
  1. KPI ticker
  2. Messaging
  3. Mine control
  4. Truck utility
  5. Mine view & schematic
  6. Mine task management
  7. Task template
  8. Line-up — employee & equipment
  9. Historical data list & edit
  10. Reporting portal
  11. Configuration
  12. Time categorisation
The Process
  1. Start with display types, not screens

    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.

  2. Audience before persona

    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.

  3. Scenarios as the test

    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.

  4. Iterate in the open

    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.

  5. Test, then write the rules

    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.

  6. Publish where the rules get used

    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 Outcome
Projecthouse standard

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.

Three decisions that carried the work

Twelve types, not five hundred screens

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.

The standard lives in a browser, not a binder

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.

State the gap, don't make them compute it

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.