New Components Need Clear Criteria for Entry
If anyone can add a component whenever they need one, the number of components grows while the system becomes harder to use.
Article Design Systems Finance
A Design System Needs an Owner
When a design system is treated as complete at launch, exceptions tend to accumulate while the system itself goes unchanged. A more reliable approach is to appoint an owner, define what triggers an update and formalize both in the maintenance responsibilities.
Key points
- After launch, maintaining a design system means moving beyond the idea that publication marks completion.
- Without active maintenance, the same pattern repeats: exceptions accumulate, and no one updates the system.
- Start by appointing an owner and specifying when updates are required.
- Document this commitment in the maintenance responsibilities, with the design lead accountable.
- From then on, use one acceptance criterion: when an exception arises, is someone responsible for deciding whether to update the system or reject the exception?
01What System Maintenance Must Stop
System maintenance must begin by ending the assumption that the work is complete at launch. If that assumption persists, exceptions will accumulate while no one updates the system.
Keep ongoing responsibilities focused. A manageable scope makes it easier to maintain clear ownership and explicit triggers for updates.
Appoint an owner and specify when updates are required. Without these basics, maintenance still rests on the assumption that the work ends at launch.
02Where Maintenance Boundaries Become Unclear
Ambiguity often enters through well-intentioned additions. In trying to accommodate more situations, teams can inadvertently reinforce the idea that maintenance ends at launch.
Every addition makes boundaries harder to enforce unless it addresses the underlying problem: exceptions are accumulating, and no one is updating the system.
03Define What Falls Outside System Maintenance
A clear list of exclusions is more useful than broad descriptions. Specify what falls outside system maintenance so the team understands that ownership and update requirements are practical commitments.
Keep the list short enough to read in full at launch.
04Use Tools to Keep Maintenance Within Scope
Maintenance responsibilities should enforce boundaries. Ideas that fall outside those boundaries can be considered separately, but should not be treated as system maintenance.
The boundary holds when the design lead owns it and has the authority to say no.
05What to Do When Maintenance Goes Beyond Its Remit
When a boundary is crossed, go beyond correcting the individual output. Revisit the maintenance responsibilities and make the overlooked condition explicit.
Then check again against the same criterion: when an exception arises, is someone responsible for deciding whether to update the system or reject the exception?
Framework
The Four Layers of System Maintenance
From non-negotiable principles to practical tools, each layer answers one question and helps prevent a return to the assumption that maintenance ends at launch.
L1System Owner
This layer defines the non-negotiables of system maintenance.
L2Must refresh
This layer turns maintenance responsibilities into verifiable criteria.
L3The Right to Refuse
This layer defines which aspects of maintenance can adapt to different contexts.
L4Timing
This layer gives users practical guidance for maintaining the system 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 after launch when maintenance is actually needed. Begin with those situations, rather than rephrasing the assumption that launch marks completion.
Action 02
Keep it to one page
Replace lengthy explanations with clear maintenance responsibilities. Keep only what supports a named owner and explicit update requirements.
Action 03
Judge it by one question
At launch, ask one question: when an exception arises, is someone responsible for deciding whether to update the system or reject the exception? Until that can be answered, the decision is incomplete.
Action 04
Name the owner
The design lead is accountable. Without a named owner, maintenance arrangements can be quietly changed when conflicts arise.
Related
All insightsRelated insights
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.
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.