Most software projects begin with a data model. Someone lists the entities, draws the relationships, and the screens are whatever the tables allow. The result is software that is technically correct and useless at nine in the morning, when a dispatcher has forty deliveries to assign and the tool wants her to create a "shipment record" first.
I do it the other way around. The first artifact is a person's day.
Start with one person, one day
Pick the person whose day the software has to survive. For a transport system, that is the dispatcher and the driver. Not the sponsor, not the IT lead. The person with the tightest loop.
Then write their day as a sequence:
trigger → what they do → what they look at → who they hand off to → where they wait → what decision they make → what goes wrong → how they know it is done
Do this for the most common case and for the exception they mention first. The exception is never optional. It is usually the reason the last tool was abandoned.
What that sequence tells you
Each step of the day translates directly into a design decision.
- The trigger is your entry screen. If the day starts with a phone call, the first screen should accept a phone call's worth of information, not a form with twenty fields.
- What they look at is your default view. For a dispatcher, that means seeing deliveries, drivers, and progress together, with exceptions visible at a glance.
- The handoff is where a second role appears. In the Avian project, the dispatcher's plan becomes the driver's task list. Two people, two devices, one record.
- The wait is where you either show status or lose trust. Nobody minds waiting when they can see why.
- How they know it is done is your acceptance test. For a driver, done is a photo at the door. For the dispatcher, done is the day's board with nothing red on it.
Then, and only then, the data
By the time the day is mapped, the data model is mostly written for you. The entities are the nouns in the sequence. The states are the columns of the dispatcher's board. The permissions are the handoffs. You still have to design it properly, but you are designing something you have already watched being used.
Doing it in this order also protects you from the most common enterprise failure: a beautiful schema that forces people to enter data the tool needs but they do not have yet. The day tells you what is actually known at each step.
A practical test
Before I show a first slice to anyone, I run the operator's day through it, out loud, as that person. If I have to explain a step, the step is wrong. If I have to switch to another tool for a piece of information, the screen is incomplete. If the exception has no home, we are not ready.
If you are commissioning software, ask your builder to walk you through one person's day in the product before they show you an entity diagram. It is a small request, and it tells you almost everything about whether the result will be used.
Map the day, then the data. Software that fits the hours gets used; software that fits the schema gets routed around.