One layer, read
three different ways.
The same rules do a different job depending on who is holding them. A designer gets room to decide. A developer gets output that compiles. A team gets eight screens that agree with each other without anyone policing it.
The rules cover the parts you were never going to enjoy.
Nobody became a designer to decide, for the fortieth time, what an empty table should say. Those decisions are made once and written down, which leaves the ones that actually distinguish a product.
01For developers →Three choices per shell, made on purpose.
A system that only constrains produces identical products, so every shell has to name three expressive decisions and give a reason for each. That is the part a generator cannot do for you, and the part worth your afternoon.
- Density, rhythm and where the eye lands firstyours
- What a screen leads with, and what it refuses to showyours
- Empty, loading, denied and partial statesdecided
- Which actions a settled record may be offereddecided
A screen you can build without reverse-engineering the intent.
The expensive part of a handoff is not the CSS. It is the half-hour spent working out where a number came from, whether that button should exist on a closed record, and what the screen does when the list is empty.
02For teams →The rules you would have enforced anyway, enforced earlier.
Three of them are held in the components themselves, which means they are not advice. A footer takes rows and derives its own total; there is no prop to pass, so the rule cannot be broken by ignoring it.
- Totals derive from the rows they summarisecompiled
- Status values come from a closed setcompiled
- Every route referenced is a route that existschecked
- Loading, empty, error and denied are already drawnchecked
Sofia DelacroixEngineering · Q3 headcount$132,400.00Derived
Amina Berrada$42,000.00
Tomás Novak$51,500.00
Lena Fischer$38,900.00Eight screens that look like one product.
Generated interfaces drift. Not badly on any single screen — badly across eleven of them, built on different days by different people, each defensible and none of them agreeing.
03Whether it fits →Agreement without a design police.
Consistency enforced by review is consistency that lasts until the reviewer is on holiday. Rules held in components and checked by an audit hold whether or not anybody is watching, which is the only kind that survives a second team.
- The same figure means the same thing on every screenacross
- A status chip in one product reads the same in the nextacross
- New joiners inherit the reasoning, not just the fileonboarding
- Review time goes to the argument, not the alignmentprocess
Made for some things, and not for others.
A layer that claims to suit everything suits nothing in particular. This one is aimed at a specific kind of software, and it is worth saying which.
04Back to the top →Made for
Software where a wrong figure is a support ticket and a missing state is a phone call.
- Operational tools — claims, billing, scheduling, fulfilment
- Internal products nobody demos but everybody uses
- Anything with records, states and figures that must agree
- Teams using design agents and getting plausible, wrong output
- One person carrying a product that needs to look like several
Not made for
Work where the judgement it encodes is beside the point, or actively in the way.
- Marketing sites, campaigns and landing pages
- Consumer apps where delight outranks derivation
- Teams who want a component library and nothing more
- Anyone looking for a look rather than a set of decisions
- Production accessibility guarantees — use real primitives
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.