A consistent website as pages and departments grow: how to use reusable components

A growing website falls apart through accumulation, not through a single mistake. Every department adds its own page, every page solves the same problems from scratch, and after two years six types of button and four ways of titling a service coexist. The cost isn't aesthetic: it's that every new page reopens decisions already made, and no one knows anymore which version is the right one.

A component system closes those decisions once and for all. It isn't a style guide to consult: it's a set of pieces already decided, with notes on when they're used, what can change about them, and who's responsible if they change.

The symptom isn't ugliness, it's time

Before building anything, it's worth recognizing whether the problem actually exists. The signs are operational, not visual.

• The same information appears in three different forms depending on who made the page.
• Every new page starts with a discussion about how it should be built, instead of what it should say.
• No one touches the old pages anymore, because no one knows what will break.
• A trivial change, like updating a button's text everywhere, requires opening thirty pages by hand.

If none of these symptoms shows up, you don't need the system yet: it becomes worth it once the site starts costing time with every addition.

The four decisions worth fixing first

You don't start with the rare cases. You start with what appears on every page, because that's where inconsistency shows and costs the most.

• Headings: how many levels exist and what they're for. A page has a single main heading; subheadings describe the section's content, they don't serve as slogans. It's the most boring rule and the most useful.
• Buttons: how many forms exist and what they mean. Usually three are enough: the page's main action, a secondary alternative, and a text link. If a page needs two main actions, the problem isn't visual: it's that the page has two goals.
• Images: allowed proportions, what a product photo, a people photo, or a project photo needs to show, and what happens when the photo is missing. The missing-photo case needs to be decided once, not improvised page by page.
• Forms: what fields look like, required-field markers that are always the same, where errors appear, what someone sees right after submitting. This is the part where inconsistency doesn't just look bad: it loses you requests.

Common, variant, exception: how to decide

The question that keeps coming up isn't how to build a component, but whether a request is genuinely special. Three cases, in order of frequency.

1. It's the same component and only the content changes. No decision needed: use it.
2. It's a predictable variant, meaning the same piece with an option already allowed, for example a listing with an image and one without. The variant gets added to the component and written down, not rebuilt from scratch.
3. It's a genuine exception: it's needed just once, on just one page, for a reason you can explain. You build it, note where it is, and review it after a few months. If in the meantime it's been copied twice, it wasn't an exception, and it's time to promote it to a variant.

A small catalog, with limits noted alongside

A useful catalog doesn't just list components: it says when they're used and when they aren't. Illustrative example for a growing company website.

The limits column is the one that saves time: it answers in advance the question "can I use this here too?", which is the question that makes systems fall apart.

Who decides, who updates, who can say no

A system with no one responsible for it lasts only as long as whoever built it stays around.

• One person alone decides whether a request is a variant or an exception. They can consult whoever they want, but the decision isn't collective: otherwise it never arrives, and people proceed on their own.
• Whoever writes the content knows which components they can use and with what text, maximum lengths included. That's where components break: a fifteen-word heading in a space designed for six.
• Every change to a shared component gets communicated to whoever manages the pages, because it changes everywhere, even where no one was looking.
• Where the catalog lives is written down somewhere. If it only lives in the vendor's head, you start over the moment they're replaced.

The test: one simple page and one difficult one

A system can only be judged by building two real pages on top of it, deliberately chosen at opposite extremes.

1. A simple page, for example the company's about page: it needs to come together without inventing anything. If a new piece is already needed here, the foundations are missing.
2. A difficult page: the one sales actually uses, with comparisons, proof, attachments, and multiple possible actions. This is where the cases no one foresaw come out.
3. Note every time a component had to be forced to make it fit. That list is the list of variants to add.
4. Redo the test after the fixes, on the same two pages, to see whether the forced fits are gone.

What this guide doesn't cover

This guide covers the visual system: the pieces pages are built from and the rules for using them. How to organize topics when there are many services — that is, which pages exist, what they're called, and how they link together — is a matter of site structure and comes before this. Who actually updates the content after delivery, and with what tools, is also a separate discussion.