This note turns the central question into concrete decisions, checks, boundaries, and ownership.
Components answer form; content models answer responsibility
A component library can define how a card, banner, accordion, or quote appears. It cannot decide whether an item is a service, programme, article, project pattern, event, or policy. That distinction belongs to the content model. Start by naming the things the organisation publishes and the relationships among them. For each type, define required fields, optional fields, owner, review interval, and archive behaviour. When this work is skipped, visually identical cards carry incompatible content and editors invent structure page by page.
Inventory before taxonomy
Export or crawl the current routes and record title, purpose, audience, owner, traffic context, inbound links, freshness, and intended action. Do not begin by forcing every page into a new menu. First identify repeated responsibilities and accidental duplication. Two pages with similar names may answer different questions; five pages with different names may perform the same weak job. Mark material to keep, merge, rewrite, archive, or redirect. The inventory creates evidence for decisions that otherwise become political preferences.
Give every route one primary job
A route can support several reader needs, but it needs one primary responsibility. A service route may explain fit and process. A case pattern may illustrate constraints and decisions. An article may teach a reusable method. A contact route may collect enough context for a useful reply. Write each job with an active verb and identify what the page should not attempt. A route that tries to introduce the brand, list every service, display all proof, teach the subject, collect email, and close a sale will usually accomplish none of those tasks clearly.
Model relationships that create useful navigation
Relationships are more valuable than manually maintained ‘related content’ boxes. A service can relate to relevant project patterns, notes, standards, and a project stage. An article can relate to a capability and a checklist. Define those connections in the model so navigation can be generated consistently. Avoid relationships that exist only because two items share a broad tag. A visitor reading about migration should see redirect planning and ownership guidance, not every item labelled ‘web design’.
Design fields around editorial decisions
A flexible rich-text field feels convenient but pushes every structural decision onto individual editors. Prefer fields that reflect stable meaning: summary, audience situation, constraint, evidence, process step, caveat, related route, and review date. Do not over-model incidental presentation details that may change with design. The goal is to make correct content easier to produce and incorrect combinations harder. Test the model by entering the longest realistic title, missing optional images, multiple authorship conditions, and a genuinely short item.
Use representative content, not idealised placeholders
Design with the material the organisation is likely to maintain, including uneven summaries, legacy terminology, long legal names, absent photography, and content that requires qualification. Perfect placeholder text conceals fragile layouts. Select representative extremes from the inventory: the longest heading, the densest comparison, the oldest item that remains useful, and the route with the most dependencies. If a visual direction only works with carefully balanced fictional copy, it is not yet a robust system.
Plan migration as part of the model
Every retained legacy route needs a destination, and every destination needs a content responsibility. Record canonical URLs, redirect type, query parameter handling, attachment paths, metadata, and internal links. A redirect to the homepage is rarely equivalent to a useful destination. For merged pages, specify which source contributes which material. For archived content, determine whether it remains accessible, is removed, or is replaced by a clear historical notice. Migration decisions should be reviewable before launch, not reconstructed from server logs afterward.
Test a normal publishing cycle
Before approving the model, rehearse a realistic update: publish an article, revise a capability, retire a programme, replace an image, and correct a policy date. Observe who needs access, which fields are confusing, whether previews reveal mistakes, and how changes are reviewed. Record the time and failure points. A content system is maintainable only when an ordinary update can be completed without the original designer interpreting the interface. The rehearsal often exposes more useful requirements than another round of component polish.
Define absence and expiry as real states
Content systems often model the ideal published item and ignore what happens when an image is unavailable, an event has passed, a service is paused, a person leaves, or a relationship points to an archived route. Define those states explicitly. Decide which fields disappear cleanly, which notices appear, and which relationships must be reassigned. Avoid substituting generic stock imagery simply to preserve a card ratio. An absent asset should not break hierarchy, and expired content should not silently masquerade as current. State handling is part of the model because editors will encounter these conditions long after the original design review.
Set validation rules that protect meaning
Validation should prevent contradictions, not merely require every field. A publication date may be required for an article but inappropriate for an evergreen capability. A call to action needs both a label and valid destination. A project pattern marked representative must not be presented as a client case. Define allowed lengths where layout is genuinely sensitive, but do not solve every design weakness by imposing tiny text limits. Provide useful error messages and examples. Editors should understand why a rule exists and how to correct the item without asking a developer to decode a schema name.
Design preview around editorial questions
A preview should reveal more than the final colours. Show missing optional fields, long headings, scheduled status, related content, metadata, mobile ordering, and any legal or accessibility note associated with the item. Make draft and public states unmistakable. If the system supports several locales, preview fallback and incomplete translation states. Ask an editor to identify what will publish, where it will appear, and which route owns the canonical version. When a preview cannot answer those questions, publication becomes an act of faith rather than a controlled change.
Measure model quality after ordinary use
After launch, review which fields remain empty, which are copied mechanically, which validation rules are bypassed, and which relationships editors misunderstand. Compare planned update frequency with actual practice. If a content type exists only to support a visual module nobody maintains, simplify it. If editors repeatedly place structured facts in rich text, the model may be missing a meaningful field. Treat the model as an operating agreement that can be revised with evidence, while protecting URLs and migration assumptions that external visitors already depend on.
Turn the method into a reviewable record
Apply the ideas in Build the Content Model Before the Component Library to one real route, decision, or update rather than discussing the entire website in the abstract. Record the current condition, the audience question, available evidence, responsible owner, proposed change, risk, and acceptance check. Attach screenshots or route lists where they clarify the record, but do not substitute visual evidence for an explanation. Ask a reviewer who did not prepare the record to identify the decision and reproduce the check. If they cannot, revise the language or evidence. Keep the record with the project source so a future maintainer can distinguish an intentional rule from an accidental implementation detail. This small discipline reduces repeated debate and makes later corrections safer.
Use a stop condition, not endless refinement
Define what would make the recommendation inappropriate, incomplete, or unsafe. A missing content owner, unverifiable claim, inaccessible interaction, unmapped legacy route, unknown data destination, or absent recovery path may be a reason to pause. Write who can resolve the condition and what evidence allows work to continue. This prevents schedules from converting uncertainty into silent assumptions. It also protects creative work: once the named conditions and acceptance checks pass, the team can stop polishing details that do not improve the audience decision. Review the condition after an ordinary publishing cycle, because real use may reveal a different constraint from the one imagined during design.
The useful standard is a decision somebody else can understand, test, and maintain.
Questions to carry into the project
- Which decision is this work meant to improve?
- What evidence is available now, and who can verify it?
- Which owner can maintain the result after launch?
- What condition should stop, revise, or reverse the release?