Operations System
Natural stone manufacturing. Factories producing marble and granite surfaces for residential and commercial projects. Complex multi-stage work involving planners, supervisors, operators, machines, and clients with real economic consequences when things go wrong.
Before this system, operations ran on email, WhatsApp, and phone calls. No traceability, no real-time state visibility, no structured recovery when physical failures occurred. The planner was the single source of operational truth. When they weren't available, the factory ran blind.
The brief was to redesign the scheduling and tracking system. Not visually. Behaviorally. Rebuild states, transitions, rules, failure modes, and governance from scratch.
The instinct after two days in the field was to design a better interface. A cleaner dashboard for the planner. A more usable mobile view for the operator.
That would have been wrong. The problem wasn't the interface. It was that the system had no faithful representation of operational reality. No model of what entities existed, what states they could be in, what transitions were valid, and what happened when things failed. Without that model, any interface would be decoration over chaos.
You can make a prettier dashboard on top of a spreadsheet. It's still a spreadsheet.
Model before interface
Design the complete behavioral model: entities, states, transitions, integrity rules, before opening any design tool.
Starting with wireframes in week one, as the PM requested.
Wireframes give the sense of progress. The PM needed something to show. Saying “I don’t have screens yet” in week two is uncomfortable for everyone.
A system with the wrong model produces unexpected behavior that no interface can fix. If the model has gaps, wireframes hide them instead of resolving them. The cost of fixing model gaps after wireframes are approved is three times higher. Two weeks of modeling saved months of redesign.
Task Entity State Machine
One system, two surfaces
The operator experience is a separate mobile layout of the same system. Not a separate app, not a responsive version of the desktop.
Building a separate mobile app for operators, which was the initial assumption.
A separate app feels cleaner. Operators have different needs, different context, different devices. Factory floor work with gloves and time pressure is nothing like planning at a desk. The argument for separation was legitimate.
Two separate systems means two sources of truth, two codebases to maintain, two places where state can drift. The operator and the planner work on the same jobs, the same tasks, the same reality. If the state lives in one system, both surfaces always see the same truth. The mobile layout is radically different from desktop. But it is the same system underneath.
| BEFORE | AFTER |
|---|---|
| Email, WhatsApp, calls for coordination | Single system with real-time state visibility for all roles |
| Planner as single point of failure | Supervisor fallback rule. No job ever without a responsible party. |
| Manual recovery after every failure: 30 min to 2 hrs | Structured recovery pipeline with preview and confirmation |
| No record of who actually executed | Full assignment traceability. Assigned vs actually executed. |
| DELAYED as a lifecycle state causing semantic confusion | schedule_health as separate temporal signal. Clean state model. |
| No audit trail | Every critical action generates an immutable AuditEvent |
Governance Matrix
Involve a senior engineer earlier in the state modeling phase. When I presented the model, several questions revealed gaps I hadn't seen. Earlier collaboration would have caught them sooner. Not because engineering validates design, but because the back-and-forth surfaces edge cases faster than solo modeling.
The most important design work doesn't happen in Figma. It happens in the model. You can have the cleanest interface in the world and fail in production if the states, transitions, and failure modes are wrong. The invisible architecture defines the visible UX.