Record Exceptions Before They Become Unwritten Rules
In everyday design work, a verbal agreement to make a one-off exception often leads to the same exception recurring until it becomes the rule in practice.
Article Design Systems Education
New Components Need Clear Criteria for Entry
When anyone can add a component simply because they need one, the system tends to grow in size and lose coherence. A stronger approach requires every proposal to explain why existing components are insufficient, with entry criteria that make this requirement part of the process.
Key points
- Adding components to a working system should involve more than creating one whenever someone asks.
- Left unchecked, the same pattern repeats: more components, less coherence.
- Start with a different requirement: explain why existing components are insufficient before adding a new one.
- Build this requirement into the entry criteria, with a named system owner.
- Assess every proposal against one question: does it explain the limitations of existing components?
01Translating Component Entry Criteria into Practice
Documenting component entry criteria does not mean they are being used. The first step is to require an explanation of why existing components are insufficient before adding a new one.
If putting the policy into practice means merely shortening ‘add a component whenever someone needs one,’ practitioners still face the same result: more components, less coherence.
Explain why existing components are insufficient before adding a new one. Without this requirement, adding components remains a matter of responding to individual requests.
02Where Component Entry Criteria Get Distorted
Component entry criteria are most often distorted when work is divided up. Each department takes away a statement it can readily support, without the corresponding grounds for saying no.
The visible practice remains ‘add a component whenever someone needs one,’ while internally no one can explain why more components are making the system less coherent.
03The Smallest Usable Unit of Component Entry Criteria
The smallest usable unit of component entry criteria is a decision someone can make on the spot. The criteria should support exactly that.
Practitioners using component entry criteria should no longer have to guess what the brand team would think.
04Putting Component Entry Criteria in Practitioners’ Hands
For every proposal, check one real instance to see whether the entry criteria have slipped back into ‘add a component whenever someone needs one.’
Revisions can be useful. The problem arises when no one acknowledges that the criteria for adding components have changed.
05Where Judgment Belongs in Component Decisions
Judgment should stay with the people using the system. Name a system owner, and give practitioners the authority to reject proposals under the entry criteria.
End training with a single question: does the proposal explain the limitations of existing components?
Framework
The Four Layers of Component Entry Criteria
From non-negotiable principles to practical tools, each layer answers one question, keeping component entry criteria from reverting to ‘add a component whenever someone needs one.’
L1Limitations
This layer defines what is non-negotiable when adding components.
L2New Component
This layer turns component entry criteria into conditions that can be checked.
L3Reject
This layer defines how component entry criteria may adapt to different contexts.
L4Merge
This layer puts component entry criteria in users’ hands and makes exceptions explicit.
Note: This diagram is a conceptual framework. It explains a way of thinking and is not statistical data. Source: Qingmei Future Insights.
Recommended actions
Action 01
Start from the site
Identify the moments when component entry criteria are actually needed in everyday use of the system. Start there, rather than by rewording ‘add a component whenever someone needs one.’
Action 02
Keep it to one page
Use entry criteria in place of lengthy explanations. Keep only what supports the requirement to explain why existing components are insufficient before adding a new one.
Action 03
Judge it by one question
For every proposal, ask only: does it explain the limitations of existing components? Without an answer, there is no basis for a decision.
Action 04
Name the owner
Name a system owner. Without one, component entry criteria will be quietly rewritten whenever conflicts arise.
Related
All insightsRelated insights
A System Is Established Only When Other Teams Can Use It
When a system is adopted only within the design team, other teams typically continue working in their own ways.
Packaging Is a Medium, Not Just a Container
When a packaging brief asks only that the pack hold the product and survive shipping, the result often says nothing on the shelf.