The shape
┌───────────────┐
┌──────│ THE CLIENT │──────┐
│ │ (the hub) │ │
┌────▼───┐ └───┬───────┬───┘ ┌───▼────┐
│ Jobs │ │ │ │Invoices│
└────────┘ ┌───▼───┐ ┌─▼────┐ └────────┘
│ Files │ │People│
└───────┘ └──────┘
One object is the centre of gravity. Everything else is reached through it, and the hub's page is where a person spends their time.
Finding the hub
The hub is the noun people say when they describe their work. Not the noun with the most rows — the one that other things belong to.
Ask what someone means when they say "let me pull that up". In a construction business it is the project. In a law firm it is the matter. In a clinic it is the patient. In an agency it is the client. Almost every business has one, and almost every internal tool built without asking gets it wrong — because a developer looking at the schema sees six equally-important tables.
The consequence of getting it wrong is not subtle: people navigate constantly, because the thing they hold in their head is not a place they can go.
What follows once you know it
- The hub gets a real page, not a row in a list. It is where people spend time, so it earns tabs or sections rather than a form.
- Spokes appear on the hub, in summary, with counts — jobs, invoices, files — so the hub answers most questions without leaving it.
- Spoke records link back, always, so someone who arrives at an invoice from search can get to the client in one click.
- Search prioritises hubs. When someone types a name, the client should rank above the invoice that mentions it.
- Global lists still exist — all invoices, all jobs — because cross-hub questions are real. They are just not the primary path.
The failure this prevents
Without a hub, the work of assembling context falls on the person, every time. They open the client list, find the client, note the name, go to jobs, filter by that name, go to invoices, filter again. Nothing is broken and the whole day is made of it.
That assembly work is also where mistakes come from: filter on the wrong similar name once, and the conclusion is wrong with no error anywhere.
Where it goes wrong
- No hub at all. Navigation is the table list. The most common shape for software built from a schema.
- The wrong hub — usually the highest-volume table rather than the one people think in.
- A hub page that is just a form. The central object of the business gets an edit form for its own fields and no view of anything attached to it.
- Spokes with no way back, so arriving from search strands you.
- Two competing hubs with no stated relationship, so people are never sure which one to open.
- Everything on the hub page, which turns the most important screen in the product into a data dump. The hub summarises spokes; it does not contain them.
Exemplars
Salesforce is the pattern at its most explicit — the Account record is the hub, and the entire product is organised as things related to it.
GitHub's repository is a hub that nobody would describe as one, and it is a good demonstration of the tabs-plus-counts approach: code, issues, pull requests, actions, all hanging off one object with a permanent identity.
Practice-management software across law, medicine and accounting converges on the same shape — matter, patient, client — which is strong evidence that the hub is discovered from the business rather than invented in the design.
The extractable rule: the hub is a noun your customer already says. If you have to explain it to them, you picked the wrong one.