Design the system before the pages

Pages reveal the system

When every page begins as a blank canvas, familiar decisions are made again and again. Navigation, hierarchy, card behavior, image treatment, spacing, responsive rules, and accessibility become local debates instead of shared foundations.

A system changes the starting point. It gives the team a small set of explicit content patterns, components, and visual roles so that each page can focus on its particular story.

Begin with recurring intent

Do not start by inventorying rectangles. Start by finding repeated jobs in the experience:

• Introduce one clear promise.
• Help a reader compare related services.
• Present credible proof with its context.
• Explain a sequence without losing the order.
• Route someone into a deeper article or case study.
• Close a page with one appropriate next action.

Intent gives a component a reason to exist. It also makes the catalog legible to writers, designers, developers, and agents who need to choose a pattern without reverse-engineering its markup.

Reuse decisions, not just code

The useful unit of reuse includes when a pattern belongs, what content it accepts, how it responds, and which accessibility behavior it protects. Code without that contract only moves ambiguity into another file.

A durable component definition should answer:

1. What reader or business need does this pattern serve?
2. What content is required, optional, or prohibited?
3. Which variations are meaningful enough to name?
4. What happens on a narrow screen or with long content?
5. What keyboard, semantic, motion, and contrast behavior is guaranteed?
6. Does it add client JavaScript, a network request, or server behavior?

These answers turn a visual pattern into a dependable product capability.

Keep content free of implementation choices

Structured content should describe meaning: a heading, summary, action, image, metric, question, or cited result. It should not choose a utility class, arbitrary color, breakpoint, or HTML fragment.

That boundary is not bureaucracy. It is what allows the same content to survive a redesign, lets the build reject unsafe or incomplete data, and keeps an automated author from creating a fragile one-off page that only looks correct in one screenshot.

When an author needs a real presentation difference, give it a semantic name such as “compact,” “image-first,” or “inverse.” The component owns how that intent becomes markup and layout.

Let the theme carry the visual language

Components should consume roles rather than literal brand values. A primary text color, subtle surface, focus treatment, heading family, spacing scale, and container width can change the character of an entire site without editing page content or component structure.

This separation is especially useful during early design. A team can test a restrained monochrome direction and a more expressive branded direction against the same content model. Differences become explicit theme decisions instead of unrelated CSS scattered through pages.

Design the content model beside the component

A component can only be as durable as its data shape. If a project card needs a title, context, summary, image, and destination, make those fields visible and validated. Do not accept a general blob and hope each page uses it consistently.

Strict fields create productive pressure. They reveal when two visually similar cards actually serve different jobs, when optional content creates an unstable layout, and when a requested variation belongs in the theme rather than the content.

The schema also becomes documentation. People and tools can discover the complete valid surface without reading the renderer.

Compose representative pages early

A component gallery proves individual patterns. Representative pages prove the relationships between them.

Build a small set of real page types before polishing every variation:

• A homepage with a clear hierarchy and mixed section rhythm.
• A service page with explanation, process, comparison, and conversion.
• A collection index and a long-form detail page.
• A proof-heavy work or case-study page.
• An internal catalog for every supported component and state.

These compositions expose repeated spacing, heading, and transition needs that isolated component work can miss.

Keep exceptions visible

Some pages need something genuinely new. Treat that as a system decision with a name, a clear boundary, and a reason to exist.

Before adding a component, ask whether an existing pattern can express the intent, whether the need will recur, and whether the proposed interface can be documented and tested. If the answer is still yes, create the component through the same manifest, schema, accessibility, runtime, and review contract as everything else.

Visible exceptions can mature into reusable patterns. Invisible exceptions accumulate as maintenance debt.

Test the system with the next page

The test of a system is not whether the current site looks consistent. It is whether the next useful page can be created with fewer new decisions and no loss of quality.

Track the questions authors still need to ask, the overrides designers repeatedly request, and the defects that appear across component boundaries. Those signals tell you where the system is too vague, too rigid, or missing a genuine pattern.

A good system is not finished. It is understandable enough to evolve deliberately.