Industrial asset management is a scheduling problem wearing a database's clothes.
Machines, operators, sites and contracts all move independently. A machine finishes early, a site floods, an operator calls in sick — and every one of those events changes what is available, where, and to whom.
The tooling that existed treated this as a records problem. Rows in tables, forms to edit them, and a search box. It answered what do we own perfectly well and can I have this on Tuesday not at all.
The people asking that second question were rarely at a desk. They were on a site, on a phone, with one hand free and patchy signal.
The product was answering the wrong question
If the interface could answer availability in seconds rather than minutes, it would replace the phone calls the software was actually competing with.
I followed how availability questions get answered today.
Rather than starting from the existing screens, I spent time with dispatchers and site managers watching the real process — which turned out to route around the software almost entirely.
The pattern repeated across sites: the system held the data, and a person held the answer.
The phone was the interface
Availability questions were answered by calling the person who knew, not by opening the platform. The software was a system of record that nobody consulted in the moment.
A whiteboard held the truth
Most yards kept a physical board that was more current than the database, because updating it took two seconds and updating the record took two minutes.
Data entry happened later
Field changes were logged at the end of the day from memory, which meant the platform was reliably a few hours out of date exactly when accuracy mattered most.
The platform did not need more data. It needed to answer one question before the phone did.
That reframed the whole product. It is not a database with a UI on top — it is a way to answer can I have this machine, here, on Tuesday in a few seconds.
Everything else in the interface got measured against that: does this make the answer faster, or does it just make the record more complete?
A platform organised around time and availability rather than records.
The rebuild put a timeline at the centre and let everything else hang off it. Records still exist, but they are what you open after the schedule has told you what you needed to know.
Interaction was tuned for the conditions the software is actually used in: large targets, states readable at a glance, and nothing destructive that cannot be undone.
Timeline as the primary object
The schedule is the home screen, not a report you generate from one.
Assets run along the vertical axis and time along the horizontal, so availability is a shape rather than a query. A gap in a row is an available machine — no filtering, no interpretation.
Because the timeline is the default view, the most common question in the business is answered by the screen that opens first.
Status you can read without reading
A colour and shape system that resolves in peripheral vision.
Every asset state — available, booked, in transit, in service, overdue — has a distinct fill, edge and density, so the pattern is legible before any label is.
Colour never carries meaning alone; it is always paired with a second cue, which keeps it working for colour-blind users and on a sunlit phone screen.
Undo as a first-class action
Every change is reversible, because field mistakes are inevitable.
Rather than guarding actions behind confirmation dialogs — which get dismissed reflexively — changes apply immediately and stay reversible for a window afterwards.
This made people willing to update the system in the moment, which is the only way the data ever becomes current.
A system, not a set of screens
Tokens and components so new modules ship without redesigning the basics.
The design system defines states, density and spacing once. Subsequent modules compose from it, which is why the platform still looks like one product several years and many features later.
The schedule became the product.
SAM now runs as the operational backbone for scheduling and asset tracking across the fleet. The timeline view replaced the phone calls it was competing with — which was the actual goal, rather than replacing the previous software.
The design system built alongside it means new modules ship without a design pass on every screen, and the visual language has held as the product has grown.
What I would keep from this one
The most useful thing I did on this project was not a screen. It was spending a week finding out that the software was losing to a whiteboard, and taking that seriously instead of treating it as user error.
Industrial tools are judged against the workaround, not against other software. If your interface is slower than a phone call, people will keep making the phone call — and they will be right to.