A Matrix field is a design system, if you build it like one
The gap between a page builder your client enjoys and one they quietly work around is about a dozen decisions, nearly all made in week one.
Every Craft build ends up with a Matrix field somewhere, and every Matrix field is a small design system whether or not anybody treated it as one.
The ones nobody treated as one are easy to spot from across a room. Forty blocks. Six of them nearly identical. Names like Content Block 2 and New Section (final). And a client who has quietly given up and started using the rich text block for everything, including things it was never meant to do, because at least they understand it.
That outcome isn't caused by a lack of skill. It's caused by a dozen small decisions, nearly all of them made in the first week, none of them individually significant, all of them compounding.
Name blocks after what they are, not what they contain
Two Column Image Text describes a layout. In a year, when the layout is redesigned to put the image above the text on smaller screens, the name becomes a lie that everyone has to remember to ignore.
Feature describes a purpose, and survives being redesigned entirely.
This sounds like pedantry right up until an editor is scrolling a dropdown at four o'clock trying to remember which of three similarly-named blocks is the one that renders correctly on the news template. Names are an interface, and they're the interface people use most often.
Fewer blocks, more options inside them
The instinct when building is to create a block per design variation, because each one is straightforward in isolation. Six months later there are thirty blocks and nobody can find anything, including you.
The better shape is a smaller set of blocks with deliberate options inside them. One Feature block with an image-side setting beats Feature Left and Feature Right. One Card Grid with a column count beats three separate grids. One Callout with a tone option beats four coloured variants.
The maths is straightforward: fewer things to learn, fewer things to keep visually consistent, fewer templates to maintain, and fewer opportunities for two blocks to drift apart because somebody fixed a bug in one and not the other.
If two blocks differ only in where the image sits, they are one block and a setting.
Constrain the things that break the design
A page builder should not be capable of producing something the studio would refuse to sign off. That's the single most useful principle available here and it's the one most often skipped, because building constraints takes longer than not building them.
If the design has three heading sizes, the block offers three — not a free-text size field, not a number input, not a rich text editor with the full range available. If cards work at two, three or four across, offer exactly those three options. If the accent colour has two approved tints, those are the two in the dropdown.
This feels restrictive while you're building it and reads as care when somebody uses it. Nobody has ever thanked a developer for the freedom to set arbitrary margins, and plenty of clients have quietly produced pages that made a studio wince.
Design the empty state and the extreme state
Every block will eventually be used with less content than intended and with considerably more. A card designed for a twelve-word description will receive forty words. A grid designed for six items will get four, and then one.
Decide what happens in both cases while you're building rather than discovering it after launch. Usually it's simple — text truncates or the container grows, a four-item grid centres or left-aligns — but it's a decision, and an undecided one becomes whatever the CSS happened to do.
Write the help text as if you'll be on holiday
Every block gets one line of instruction, written for somebody who wasn't in any of the meetings and joined the client's team last week.
"Used for the three-up section on the homepage. Images crop to 4:3." It takes a minute to write and saves a support ticket every time a new person encounters it. Over four years that's a meaningful number of tickets, and each one is an interruption for someone at the studio.
The same applies to block descriptions in the picker. If a client is choosing between eight blocks, a sentence explaining what each is for turns a guess into a decision.
Order the picker by how often things get used
The block list should not be alphabetical and it should not be creation order. It should be roughly the order of frequency, with the things people reach for daily at the top.
It's a five-minute change at build time. It saves a scroll on every single use, for years.
When to break all of this
One-off pages exist. A campaign landing page that will run for six weeks and never be touched again doesn't need to be composable, and building it from the block library out of principle wastes everyone's money.
Build it fixed, tell the client it's fixed, and move on. The system exists to serve the pages that will live for years, not to be applied uniformly.
Why this is the actual deliverable
Done properly, the studio doesn't hand over a set of pages. It hands over a kit: the studio's own components, in the client's hands, which can only be assembled into things the studio would approve of.
The site stops being a snapshot of a design at a moment in time and becomes a system that holds it. When the client needs a campaign page in month eight, they build it from the parts you designed rather than asking somebody to improvise — and what they build looks like their brand, because nothing else was available.
That's a substantially better thing to have sold, and it's the difference between a website that ages and one that doesn't.