Business software
grows the same parts.
A queue somebody works down. A record somebody opens. A decision somebody commits to. Two sides that have to agree. Almost every operational product is some arrangement of those four, which is why they are worth getting right once.
A template hands over a finished arrangement. Take it and your product looks like every other product that took it, because the decisions were made before anyone knew what you were building.
A shell fixes the parts that are the same everywhere — what a queue owes its reader, what a record page may offer — and then requires three expressive choices, with a reason for each.
Four archetypes, and what each one owes its reader.
These are not page layouts. Each is a claim about what a screen of that kind is for, and what it is not allowed to do — which is why the same four survive across claims, billing, clinical and hiring products alike.
01How fixtures work →
Nordvik ShippingCLM-0121 · 2 days leftUrgent$20,600.00
Baltic Freight GroupCLM-0114 · 6 days leftDue soon$32,160.00
Meridian CargoCLM-0108 · 19 days leftAssessed$14,800.00Work queue
A list somebody works down, ordered by what is burning out rather than by what arrived last. Severity orders the list, and the reason for the order is on screen.
Nordvik ShippingCLM-0121 · opened 14 AugAssessed
EvidenceSettleRecord page
One object, its figures traced to where they came from, and only the actions its state permits. A settled record is never offered a button it cannot honour.
Decision surface
Where somebody commits and carries the consequence afterwards. Gated on the evidence being present, and honest about what cannot be undone.
Reconciliation view
Two sides that have to agree, with the gap between them named rather than implied. The difference is a figure in its own right.
The part a shell refuses to decide for you.
Constraint alone makes everything look the same, so each shell asks three questions it will not answer. The answers are where a product stops resembling everybody else’s.
What leads
Of everything on this screen, what does the reader see first, and why that?
A claims desk leads with the deadline. A billing view leads with the amount. Both are defensible; neither is default.
What it refuses to show
What is deliberately absent, and where does a reader go when they need it?
A queue that shows every field is a spreadsheet. Leaving something out is a decision, and it needs a destination.
Its density and rhythm
Is this read all day at speed, or opened twice a week with care?
An operator at forty rows an hour wants a different screen from an approver signing four. Same rules, different shape.
How a shell gets used.
A shell is a paragraph, not a file. It is quoted in a brief, read by the agent, and checked against afterwards.
03Back to the top →Name the archetype, answer its three questions
Four sentences is usually enough, because everything else about that shape is already written down. That is the whole point of having archetypes.
The agent reads the shell before it draws
It arrives already knowing what a queue owes its reader, so the conversation starts at your three choices instead of at the basics.
The audit checks the shell’s own rules
Alongside the rest of the pass. Whether severity really orders the queue, and whether anything was offered an action its state forbids.
Reckon
Ship the screen.
Not the guesswork.
Components are the easy part. What you are missing is the layer that decides what gets computed, what gets shown, and what gets refused.