Less to look at, so you know what to do next.
An approach to operational dashboard design, built from scratch for a pre-launch pharma ERP, proven on two operator roles and built to extend to the rest. With no dashboard planned, users landed on a module list that told them nothing.
TraxCM is an ERP for UK and EU pharmaceutical wholesale distributors. V1 had no homepage planned. Every operator, purchasing, sales, the warehouse, landed on the same module list and had to already know what they were looking for.
Underneath that were two problems, not one. The work was manual: operators moved each order along the pipeline by hand. And there was no glance-view of pipeline status, so chasing the next stalled thing meant opening module after module to reconstruct where everything stood.
This build targets the first problem. It surfaces the decision an operator should act on next, so the work no longer starts with a hunt. The second, a true live status view of the whole pipeline, is the next layer, named here rather than quietly skipped.
Navigation was never the operator's problem. Knowing the next move was.
An operator should not have to read data and infer what to do. The dashboard owes them the decision, not the raw material.
The signals came from walking each operator's pipeline stage by stage, not a brainstorm: at every step, what decision is made, and what does "stuck" look like? The walk, grounded in the live system, caught what an initial list missed.
Something landed that needs your response.
Act on it now.
Something stopped moving when it shouldn't have.
Step in before it escalates.
Work only you can start.
Originate it.
Inbound alone makes an order-taker. Stalls and proactive work make an operator.
One test earned each tile a place: and so what do I do? It cut thirteen candidate signals to ten.
Same method, two roles, two surfaces that share a skeleton but not a shape.
A method that bends to fit two opposite jobs is a method, not a one-off.
The warehouse manager is the third operator, still unbuilt, and the framework already shapes his surface. Built the same way, every operator's dashboard stays coherent: one kind of surface, learned once.
Pre-launch, so no usage numbers, and I will not fake them. What the work produced is concrete: two PRDs a team could build from, riskiest choices flagged as assumptions, a working prototype, and the framework.
At launch, three things, each tied to a decision.
| Metric | What it tells me |
|---|---|
| Action-from-tile rate | Whether the dashboard replaced the module hunt, or just sits beside it |
| Proactive vs reactive stall ratio | Whether tiles catch problems before the customer does |
| Per-tile engagement | What to promote above the fold, and what to cut |
Usage would not just score the dashboard. It would redesign it.
Five choices rested on things I could not verify pre-launch, so I marked each as an assumption with a way to test it. That lets a reviewer attack the design with evidence, not vibes. Hiding what you do not know is the weaker move.
In a young product, references go stale fast. When my documentation disagreed with how the system actually behaved, the system was right. I built from live behaviour and updated the doc after.