The Charter Document
EP03 — Every design system launch meeting ends with full alignment. Three months later, nobody agrees on anything. The charter is the document that prevents that gap.
Every design system has a launch moment.
A file goes live. A message goes out. Someone sends a calendar invite titled: Design System Kickoff. And in that meeting — everyone agrees on everything. The vision is clear. The purpose is obvious. The team is aligned.
The Design System Kickoff meeting has a remarkable alignment rate. The thirty days after it, considerably less so.
I once asked two people in the same organization — same team, same design system, same week — what the system was actually for.
Consistency and brand identity in the market.
Reduce the complexity of the intake forms.
Neither of them was wrong. That is the problem. One was thinking brand. One was thinking operational efficiency. Both were legitimate answers. Both were completely incompatible as a shared mandate. And nobody had ever written down which one was the actual purpose of the system.
Nine months later, nobody could agree on anything.🥹
- What counts as a component?
- Who approves contributions?
- Is this system for the mobile team or the web team?
The vision that felt obvious in the kickoff meeting turned out to have never been written down.
The Document Nobody Writes 🤦♀️
Here is what most teams skip in the excitement of starting: the charter.
The single document that answers the questions everyone assumes are already answered.
What is this system for?
Who does it serve?
What does success look like?
What is explicitly out of scope?
Four questions. One document. And almost nobody writes it.
A design system without a charter is a conversation everyone is having in a different language.
Without it, the design team builds components for their workflow. The engineering team builds for their workflow. Both workflows are different. Neither team is wrong. Both teams are confused.
A product manager submits a request for a new component. The DS team says no — because it doesn't fit the system. The PM asks: what system? The DS lead points to the design file. The PM points to the production codebase. They are not the same. They were never the same. Because nobody wrote down which one was the authority.
That is not a tooling problem. That is a charter problem.
What a Real Charter Contains
Four sections. Not forty. Four.
Section 1 — The Problem Statement
Not the vision. Not the aspiration. The specific, observable problem this system exists to solve.
Example: "Product teams are rebuilding the same UI components independently, resulting in inconsistent user experiences and duplicated engineering effort across five product squads."
One sentence. Specific. Observable. Not: "We want a world-class design system."
"World-class" is not a success metric. It is what you write in the brief when you haven't decided what success looks like yet. Aspirations do not survive the first sprint.
Section 2 — The Scope
What the system covers. And — critically — what it does not.
I have watched design teams with strong front-end capability fall into a specific trap. Because they could build anything, they said yes to everything. Every squad request. Every edge case. Every one-off component that served a single product and had no business living in a shared system.
The intention was generosity. The result was a system that tried to serve every use case and was optimized for none of them. The very skill that made the team valuable — the ability to actually build what was asked — became the thing that made the system unmaintainable.
Scope creep in a design system doesn't arrive as a bad decision. It arrives as a series of reasonable ones.
Not everyone. These teams. These products. These use cases. Everything else is a future conversation.
Section 3 — The Governance Model
Who owns the system? Who approves contributions? Who has veto power? Who resolves conflicts between design and engineering?
If these questions are not answered in writing before the system launches — they will be answered in meetings. Repeatedly. Expensively.
Section 4 — The Success Criteria
How do you know if the system is working? Not qualitatively. Not "teams seem happier."
"Teams seem happier" is not a success criterion. It is the design equivalent of "the meeting went well." Both statements may be true. Neither one has ever defended a budget.
Specifically: adoption rate across squads, component detach rate, time to implement a new UI pattern, engineering hours saved per sprint. If you cannot measure it — you cannot defend it. And every design system eventually has to be defended.
The Quick Win: Two Pages Before the Next Component
Four sections. Two pages maximum. Shared with engineering lead, product lead, and one stakeholder before any design work begins.
Ask them one question:
"If we built exactly what this document describes — would you use it?"
If yes — you have alignment. If no — you have information. Both are more valuable than a component library nobody agreed to use.
Disagree loudly. Inspire boldly.🤔
And remind me — falsely if needed — that somewhere a design system charter exists and everyone actually read it.
Does your design system have a charter?
Comments ()