The design director had a PhD in human science.
Not design. Human science. Which is a legitimate field with legitimate applications — none of which are running a design system team at a technology company. But the credential was impressive, the title was correct, and the interpretation of design thinking that followed was entirely consistent with someone who had studied human behavior without ever having to ship a component under deadline pressure.
The interpretation was this: design thinking means designers support developers. Not partner with. Not lead alongside. Support. A new development squad was brought on board. New hires. And the design team — the people who had been building the system — were repositioned as a service function for what the developers needed. Not the other way around. Not together. The system that had been the point of the entire engagement became subordinate to the squad that was supposed to be adopting it.
That decision was made by one person. With a title that implied authority. In the absence of any framework that defined what design leadership was authorized to decide, what required practitioner input, and what the escalation path was when a strategic direction contradicted the system’s purpose.
There was no decision framework. So the most politically positioned person filled the vacuum. The system did not survive the decision. I did not stay to watch it fail completely. That was my last straw. I left.
A decision framework does not prevent bad leaders from making bad decisions. It makes the damage visible before it becomes irreversible. I found that out too late to save the system. Not too late to know what to build next time.
Why Design System Decisions Have No Legitimate Owner
Most organizations have adopted the language of modern software development. Agile. Design thinking. Cross-functional teams. Iterative delivery. The vocabulary is current. The org chart underneath it is not.
Designers report to directors from non-design backgrounds. Design directors exist with political constraints that prevent them from exercising the authority the title implies. Product managers control sprint priorities that determine what the design system team works on regardless of what the design system actually needs. Engineering leads make architectural decisions that the design system has to accommodate rather than inform.
We like to pretend we have adopted a new and modern way of working. In reality it is adhocracy. Decisions get made by whoever is available, whoever is loudest, or whoever has accumulated enough political capital to act without being questioned. The decision framework fails not because nobody designed one. It fails because the organizational conditions that make a framework viable were never actually built.
We adopted the language of modern software development. We kept the org chart of 1987. A decision framework built on that foundation is not governance. It is theater with a RACI matrix.
This is the uncomfortable context that most decision framework conversations skip. They describe the framework as if it operates in a vacuum — as if the org structure it depends on is neutral, rational, and already aligned to the system’s purpose. It is almost never any of those things.
What a Decision Framework Actually Requires
A decision framework for a design system is not a governance document. It is not a RACI chart. It is not a committee with meeting cadence. It is the answer to three questions that everyone touching the system should be able to answer the same way.
Question 1 — Who decides what?
Not by role. By decision type. A component inclusion decision is different from a token architecture decision, which is different from a deprecation decision, which is different from a strategic direction decision. Each type of decision has a different set of people who should be involved, a different level of authority required to finalize it, and a different consequence if it is made wrong.
Without this mapping, every decision defaults to whoever has the most organizational gravity at the moment it needs to be made. That person is rarely the right person. They are simply the most available or the most assertive.
Question 2 — What information does a decision require?
A decision made without the right information is not a decision. It is a guess with authority attached. Every decision type in the framework should have a defined information requirement — what data, what practitioner input, what stakeholder context is necessary before the decision can be legitimately made.
The design director who repositioned designers as developer support did not have the wrong title. She had the wrong information. Nobody in the room had the practitioner context to challenge the interpretation. The information requirement for that decision was not defined. So it was made on credential and conviction alone.
Question 3 — When does a decision escalate?
Some decisions can and should be made locally — at the team level, without escalation. Others have consequences that extend beyond the team and require a broader mandate before they are finalized. The framework defines the threshold. Below it: decide locally, document it, move on. Above it: escalate, surface the information, get the right people in the room.
Without a defined threshold, every decision either escalates unnecessarily — creating bottlenecks and eroding team autonomy — or nothing escalates — creating the conditions for a design director with a PhD in human science to redefine the entire strategic direction of the design system without a single practitioner input.
Three Rules for a Framework That Holds
Rule 1 — Document the Decision Criteria Before the Decision Arrives
Every recurring decision type in the design system should have a written brief: what type of decision this is, who is authorized to make it, what information is required, and what constitutes a blocking issue that triggers escalation. Two sentences per criterion.
Store it where the team works. Notion for teams that need something lightweight and immediately shareable — free tier covers everything a decision criteria document requires. Confluence for organizations already in the Atlassian stack. The format is secondary. The discipline of writing the criteria before they are needed is primary — because criteria written after a contested decision are advocacy, not governance.
A decision framework written after the bad decision is a record of what should have existed. It is not a framework. It is a post-mortem with aspirations.
Rule 2 — Make Decisions Traceable
Every significant design system decision should have a record: what was decided, who made it, what information was available at the time, and what the dissenting view was if one existed. Not a formal document. A comment in a ticket. A note in the changelog. A timestamp in a shared log.
Linear and Jira both support decision comments inside tickets — free for small teams, standard for most engineering organizations. GitHub handles this natively in pull requests and issues for teams already living in the repository. The tool matters less than the discipline: every decision that would generate a question six months later should have an answer that does not require finding the person who made it.
The design system that cannot explain its own decisions is not a governed system. It is a set of opinions that accumulated over time without anyone noticing they were building policy.
Rule 3 — Define the Escalation Path Before You Need It
The escalation path is the most important and most consistently absent element of every design system decision framework. It defines what happens when a local decision cannot be resolved locally — who gets called in, what information they need, and how long the resolution should take before the decision is forced.
For most teams the escalation path is informal — whoever has the relationship, whoever is senior enough to get a meeting, whoever is willing to absorb the political cost of raising the issue. That is not an escalation path. That is a personality-dependent process that disappears when the personality leaves.
Loom makes the escalation brief asynchronous — a three-minute recording that summarizes the decision, the options, the information available, and the specific question that needs to be resolved at the next level. Free tier covers twenty-five videos. The person receiving the escalation arrives informed. The decision does not require a meeting to establish context before the actual conversation can begin.
An escalation path that depends on relationships is not a path. It is a favor. And favors run out at exactly the moment you need them most.
The Quick Win: Map Your Last Three Contested Decisions
This week: identify the last three design system decisions that generated disagreement, confusion, or a conversation that should not have been necessary. For each one, answer three questions.
Who actually made the decision — and was that the right person? What information was missing when the decision was made? And if the same decision arrived tomorrow, would the outcome be different depending on who happened to be available?
If the answer to the third question is yes — you do not have a decision framework. You have a decision lottery. The outcome depends on the draw, not the criteria.
Take the most contested of the three. Write the criteria for how that decision should be made. Two sentences: who is authorized, what information is required. Share it with one other person on the team and ask if they would reach the same conclusion given those criteria. That disagreement, if it exists, is your decision framework version one. The criteria that resolves it is the first entry.
The Argument
The design system decision framework fails for two reasons, not one. The first is that it was never built — decisions defaulted to whoever had the most political capital and the least accountability. The second is that it was built inside an org structure that never actually modernized — agile on the surface, adhocracy underneath, with designers reporting to leaders who do not have the domain knowledge to protect the decisions the framework is supposed to make. Fixing the framework without fixing the structure is maintenance without a foundation. The framework holds when the org earns it. Build the criteria anyway. Name the escalation path anyway. Document the decisions anyway. Because the alternative is leaving the system’s direction to whoever walks into the room with the most confidence and the least doubt. I have seen what that produces. I did not stay to watch it finish.
Disagree loudly. Inspire boldly.
And remind me — falsely if needed — that somewhere a design system decision was made by the right person with the right information and nobody had to leave to prove it was wrong.
Before you go, entertain this for a second
Who made the last significant decision about your design system — and could they defend the criteria they used to make it?
