Templates Should Preserve Decisions, Not Eliminate Every Difference
When a template dictates every detail, people tend either to copy it verbatim or abandon it altogether.

When every page is designed from scratch, pages may look broadly consistent while every change has to be made in multiple places. A stronger approach is to define reusable components first, build pages from them, and document those decisions in a component inventory.

When working on components, the first task is not to refine how we describe designing every page from scratch. In page design, the order of decisions matters more than the wording: it determines whether pages merely look consistent while every change still demands multiple edits.
If the team starts by rewriting the language, it may assume the components have been updated while the underlying problem remains: pages only look consistent, and every change still takes multiple edits.
Define reusable components first, then assemble pages from them. Until that happens, the process is still driven by designing every page from scratch.
Some decisions must wait. Discussing channels, visuals, or messaging before defining reusable components and building pages from them simply preserves the old page-by-page approach under a new name.
Those later decisions matter, but they must follow the earlier choice. Otherwise, the team will keep treating the symptoms: pages that only look consistent and changes that have to be made in multiple places.
The sequence has three steps: define reusable components and build pages from them; document them in a component inventory; only then adapt the outward-facing expression.
Reverse that order and component work may look busy while remaining driven by page-by-page design.
The component inventory should make the sequence clear. Anyone reading it should know what has been decided and what is not yet open to change.
Before starting a new page, use the component inventory to check whether campaign demands have disrupted the sequence.
The design lead owns this. When an exception breaks the rules, update the component inventory rather than improvising a change in a group chat.
The review asks one question: does this new part of the page genuinely require a component that does not already exist? If the team can answer it, the sequence is being put to use.
From non-negotiable principles to tools people can use in practice, each layer answers one question. This prevents component work from reverting to designing every page from scratch.
This layer defines what cannot be compromised in the component system.
This layer turns component decisions into criteria that can be checked.
This layer defines what can change across different contexts.
This layer puts components in the hands of the people using them and sets out the exceptions.
Note: This diagram is a conceptual framework. It explains a way of thinking and is not statistical data. Source: Qingmei Future Insights.
Identify where components are actually used in the page design process. Do not begin by rewording the habit of designing every page from scratch.
Use a component inventory in place of a longer explanation. Keep only what supports the decision to define reusable components first and assemble pages from them.
Before starting a new page, ask only this: does its new content genuinely require a component that does not already exist? If you cannot answer, you have not made the decision yet.
The design lead. Without someone responsible for maintaining them, components will be quietly changed whenever conflicts arise.
When a template dictates every detail, people tend either to copy it verbatim or abandon it altogether.
If a design system is considered complete as soon as it is published, exceptions accumulate and no one updates the system.
If anyone can add a component whenever they need one, the number of components grows while the system becomes harder to use.