Design systems
A system people will actually use
Governance, without the committee. Thirty minutes.
Christoph Hellmuth ยท Design Engineering Studio
Open with the situation this talk is for. You may already have the library. Figma has components. The repo has a package. The all-hands slide happened. And the product still grows one-off buttons, because using the system is harder than ignoring it.
I am Christoph. Design engineering studio. I led Aurora at Nord, dozens of teams, millions of users. The lesson from that scale, and from smaller teams, is the same. Adoption is the product. The files are the means.
This half hour is about the door, the owner, the docs that stay true, and the rituals that fit in a week. It is not about a governance framework with twelve roles. If your problem is that you have no components at all, hear the inconsistency tax talk first, then come back. This one starts when there is something to adopt, and people do not.
Say the next line and mean it.
The point
A library nobody imports is a folder.
Good taste in a drawer does not change the product.
Let that sit. I have opened the folders. Beautiful. Versioned. Announced. Then you grep the product and the imports are the team that built the library, plus one polite squad, plus a storybook.
The rest of the company is still shipping the old button, because the new one was missing a state, or the doc was wrong, or the contribution path was "ask the design systems Slack" and the Slack was slow.
Governance is the name for how a change gets in, how a change gets out, and how a stranger finds the current thing. If that is a committee, it will lose to a squad with a deadline. The deadline is always real. Your process has to be faster than a fork.
Three words to plant now. Door. Owner. Deprecation. We will earn them. You should be suspicious of any governance story that cannot say who says no, and how a team says yes without a meeting.
Questions at the end. If you have a library already, bring the awkward fact: how many squads imported it last month. If you do not know, that is the fact.
The catalog is the map.
Someone is using the catalog, not wandering the stacks. Public domain. A design system needs the same courtesy. Find the component by its name. See the states. See who owns it. See how to ask for a change.
If your "catalog" is a tour that one designer gives, you have a person, not a map. People go on holiday. Maps stay.
Say: the test, and I will repeat it because it is the whole talk. If they cannot find it, you do not have it.
Then who this is for.
This room
You do not need more components first.
You need one path that a second team can use without you in the room.
Aim this at design systems leads, staff engineers, and the managers who are disappointed that the system "did not take."
The disappointment is common and it is usually misdiagnosed. People say we need better docs, or a bigger library, or a mandate from the VP. Sometimes the docs are bad. Often the docs are long and the door is shut. A mandate without a door produces shadow UI and resentment.
You are past the size where everyone knows which file is real. Say that if it fits. The system has to work for someone who joined last month.
I will not ask you to boil the ocean this quarter. I will ask you to make one contribution succeed, from a squad that does not own the system, and to delete or date one thing that should not be used. Addition without retirement is how libraries become junk drawers.
Agenda, briefly.
Thirty minutes
Door, truth, quarter.
- 01The door
Who can change the system, and how, in less than a page.
- 02Truth
Docs, Storybook, and deprecation that does not drift.
- 03The quarter
Rituals small enough to survive a roadmap.
Read the three. Tell them part three is the one to steal if they get pulled into a meeting halfway through. A Tuesday review, a named owner, a deprecation date.
Move to the door. Do not philosophize about governance definitions.
Part one
The door
Contribution has to be faster than a copy.
One breath. If forking is faster, people fork. They are not rebels. They have a release. Your job is to make the front door the short path, and the copy the expensive one.
Go.
Contribution
Contribution needs a door.
A checklist, an owner, and an answer in days. Not a council.
Describe the door as a thing you could publish this week.
A squad finds a missing state or a missing variant. They open a short checklist. What is the decision. Does a component already do this. What is the name. Which screens. What will we deprecate. They file it where the work already lives, a ticket or a pull request, not a new tool. An owner responds in a few days with a yes, a no, or a smaller yes. The change lands in the file and the repo together. The squad that asked uses it in their flow. You thank them in the notes, because contribution is a social act, not only a merge.
What kills doors: a monthly design system council that needs a slide, a quorum, and a principle. Councils feel serious. They are slower than a fork, so they govern a library the product has already routed around.
What also kills doors: an owner who says yes to everything. That is not kindness. That is how you get eight variants of button. The no has to be available, and it has to come with the path. "Use this one. Here is the state you missed. If you still need a variant, here is the evidence I would need."
Aurora could serve dozens of teams because there was a way in, and a way to refuse. I will not pretend every contribution was smooth. I will say the alternative, each team maintaining a private kit, does not survive headcount.
Write the checklist in their language, not in framework language. Half a page. If it is a handbook, nobody in a sprint will open it.
Land: the door is open when a squad that dislikes process still prefers it to a copy, because the copy will be their bug next month.
Ownership
A committee does not own the button.
CommitteeEveryone, so no one
Decisions wait. The sprint does not. The fork ships, and the committee reviews the past.
OwnerA name, with time
One person or a pair. They can say no. They are not a service desk for every screen.
Be precise about the owner. This is where governance theater starts.
The owner might be a pair: one designer, one engineer, both able to touch the shared parts. I like the pair, because a single designer who cannot merge, or a single engineer who will not open the file, recreates the wall inside the role. If you only have one person, they still need to work in both places, or pair every week with someone who can.
Time: name the hours. A few hours a week is a start at small scale. Dozens of teams need more, and need the squads to contribute, or the owner becomes the bottleneck and people fork "just this once." The door is what keeps the owner from becoming the bottleneck. They review. They do not draw every screen.
Authority: the owner can reject a variant. Their manager will back that in public once, so the organization sees it. If the first no is overturned casually by a roadmap escalation, you do not have an owner. You have a suggestion box.
Not a service desk: product squads still design their flows. The owner does not become the UI department. They keep the shared decisions shared. Feature teams compose. If every screen must be built by the systems team, you have recentralized the product, and you will be the reason the roadmap slips. Then the company will go around you. I have seen that, too.
Say: name who owns the component, on the component. In the doc, in the codeowners, in the Figma description. A name. Not "design systems team." Teams do not answer Slack at 4 p.m. on a Friday. A person does, or a pair with a rotation you wrote down.
Land the pair: committees write principles. Owners merge.
The stacks are the filing system.
The order is the finding. Public domain. A component without a place in the stacks will be duplicated because someone could not see it.
Say: file the component where the product looks. If designers live in a library file and engineers live in a package, both are stacks, and the catalog has to point at both. A third wiki that describes them is optional. The stacks are not.
Short. Then the review that is a checklist, so the owner is not a vibe.
The review
A checklist beats a taste debate.
- 01Is there already a part
Search before you add. The cousin is the usual finding.
- 02Are the states true
Including focus, disabled, error, empty. Not only the mock.
- 03Do the names match
File, repo, and the words the review can say out loud.
- 04What gets retired
A date, a path, an owner. Addition without retirement is hoarding.
Give them a checklist they can paste. This is the review, not a critique of color preference.
Is there already a part: make them show the search. I want the habit to be slightly annoying, because the annoying search prevents the fourth button. If they found a near-match, the work is to extend it or to prove the difference in a sentence. "Marketing wants it rounder" is not a sentence that earns a new component.
States: the governance review asks for the ones the happy mock hides. Error, empty, loading, focus, a long label, a missing permission. If the component cannot show them, it is not ready for the stacks. This is also the accessibility review. Do it here, not in a yearly audit that files tickets nobody owns.
Names: read the API out loud. If you stumble, the next squad will fork. Align with the token names. Action stays action.
Retirement: every yes should threaten an old thing. If nothing is retired, ask why this is a new decision rather than a new costume. Deprecation is a kindness. Leaving three generations of button in the library is how you punish the new hire.
Keep the checklist on one page. Run it in the shared review from the design engineering talk, if they have that ritual. Governance that lives in a separate meeting from the people shipping will describe a product that no longer exists.
Land: taste still has a place, on the undecided. The checklist is for the decided. Mixing them is how seniors burn out in review.
The recipe sits under the sample.
The sample and the recipe are on the same page. Public domain. You should not have to find the formula in another book.
Say: the component and the rule for changing it live together. A contribution guide in a wiki nobody links from the component will not be the recipe. Put the link, or the four checks, on the component.
Into truth. Docs, and the ways they lie.
Part two
Keep it true
A doc that drifts is a second library.
Say the warning. The most confident wrong UI I see is built from a doc that was right in March. People followed the system. The system had moved, or the doc had.
Go.
Docs
Write it where it compiles.
A paragraph beside the component beats a guide that restates it.
I am strict about this, and I want them to be strict.
The source of a component's truth is the component. Props, types, tokens it consumes, stories that show the states. A human sentence belongs in the description there: when to use it, when not to, who owns it. If you also keep a long handbook, the handbook will drift, and the drift will win an argument against the code because the handbook has screenshots.
Storybook, or whatever you use, is a proof. It is not the system. It is how you look at the states without booting the whole product. Valuable. If the stories pass and the product imports a fork, you have a proof of the wrong thing. Check imports. A quarterly count of who depends on the package is a governance metric I trust more than a NPS of the design system Slack.
Docs that are generated from the same names as the code stay boring and true. Docs that are rewritten by hand become a second design language. Agents make this worse if you let them, and better if the source is structured. A model will happily document the folder you wish you had. Point it at the component that exists. Read the page. The bench we published graded 898 generations across four systems. None were AI-native yet. The practical warning: generated docs drift faster than handwritten docs if nobody owns the diff.
Write less. A usage sentence, a do-not, an owner, the states. Link to the token. Stop.
If legal or brand needs a longer guidelines site, fine. It should read from the system, or it should admit it is brand, not product UI. Do not let the brand site specify a button the repo does not have.
Land: if the doc and the component disagree, fix the doc the same day or delete the sentence. A known lie in the system teaches people to ignore the next page too.
Deprecation
Retirement is part of the work.
A date, a replacement, a person. Then remove it.
Teams are brave about adding and shy about deleting. The library grows until finding anything requires the person who remembers.
A deprecation needs three things or it is a comment. The date you will remove it, or the version. The replacement, by name, with a migration note short enough to follow. The person who will actually delete it. Put that on the component. In code, mark it so the build or the lint tells the squad while they still have time. A wiki page titled "legacy" that is not linked from the old component is a confession, not a plan.
Be kind in the note and firm in the date. Kindness is the path. Firmness is how the date survives the sprint that wants an exception.
Keep the scar. When something failed, a token that was a mistake, a variant that created a support incident, write one sentence in the repo or the decision log about why it went away. I call that keeping the scar in the file. The next person will propose the same mistake. The sentence is cheaper than the incident.
About 90 percent fewer reclamations, the Flyeralarm number, came from removing a class of failure, not from adding a nicer version beside it. Retirement is a product decision.
If you can only deprecate one thing this quarter, deprecate the button you told them not to use, and make the recommended one obviously findable. One clean removal teaches the company that the system is alive.
Land: a system that only accumulates is a stack, not a catalog.
The sample and the note travel together.
The note is on the sample, so they cannot be separated in the filing. Public domain.
Say: owner, do-not, and deprecation date travel with the component. If they live in a slide deck from the kickoff, they are already lost.
Into the quarter.
Part three
The quarter
Rituals that fit beside the roadmap.
Promise practical scale. Not a transformation program. A week that repeats.
If they are in a rebrand, the next slide is the warning. Do not skip it.
Timing
A rebrand is a bad week to found this.
Change the values in slots you already trust. Do not invent the slots under a launch date.
This will annoy someone in the room who has a rebrand on the calendar. Say it anyway.
A rebrand wants new color, new type, sometimes a new shape language, on a date that marketing already announced. That pressure is a terrible moment to decide ownership, naming, and which button is real. You will freeze the arguments into the new visual, and you will ship the cousins in the new costume.
If the rebrand is coming, use the weeks before it to name the slots you already have, even the informal ones. Action, danger, surface, the real button, the real field. Then the rebrand is a new map onto those names. That is a hard week, and it is a survivable week. Founding governance during the launch is how you get a beautiful inconsistent product and a tired team.
I have watched teams treat the rebrand as the moment the design system begins. The system begins when a second team can ship without the rebrand team in the room. That is a worse slogan and a better test.
If there is no rebrand, ignore the costume and do the door anyway. Do not wait for a visual excuse. The leaks are already in production.
Land: pour the new paint through the old, named decisions. Where you do not have a name yet, you do not have a decision, and the rebrand will not create one for you. It will create a hex.
Ninety days
One path, then the habit.
- 30Publish the door
Half a page. An owner with hours. One checklist. Say it in the squad meeting.
- 60One contribution from outside
A squad that does not own the system lands a change, and uses it.
- 90One retirement
A dated removal, done. The catalog gets shorter and truer.
Walk the ninety days as acceptance criteria.
Day 30: the door exists in writing, where the teams already look. The owner is named. The hours are real. You have said no to building ten new components in order to look busy. You have picked the one component the door applies to, so the checklist is not theoretical.
Day 60: an outside contribution. This is the proof. If you do the work yourself and call it a pilot, you tested your own patience, not the door. Pick a squad with a real need. Pair with them. Let them hold the pen. Review with the checklist. Merge. They ship it in their flow. Write down what was slow. Fix the slow part before you scale the announcement.
Day 90: remove something. The old button, the duplicate token, the doc page that contradicts the component. Tell the company it is gone. People trust a system that can shrink.
What I would measure, plainly: number of squads importing the shared parts, time to answer a contribution, number of one-off cousins added this month, and whether the deprecated thing is still in the bundle. Four numbers. You can collect them without a research program. If the import count is flat and the cousin count is up, the door is still slower than the copy. Do not add a newsletter. Fix the door.
Lighthouse 34 to 77 is a reminder that discipline shows up in odd places, including performance, when one-offs die. You do not have to use that metric. Use the cousin count. It is closer to the behavior you want.
If leadership wants a bigger program, show them day 60 before you hire a second committee. Evidence first.
The rituals on the next slides are how the ninety days keep going after the pilot glow fades.
Ritual
Tuesday is when it is real.
A short review, both sides, the component on the table. Miss it and the system becomes folklore.
Name a day so it is not "when we can." Tuesday, or whatever day is not already a retro pileup. Forty minutes. Design and engineering. One component or one contribution. The checklist. Decisions written on the component, not in the meeting notes only.
Cancel it if there is nothing to decide. Do not perform the ritual on an empty week. An empty ritual teaches people to skip it when it matters.
The owner runs it. Guests are the squad that has the need, not a standing audience of twelve. Large audiences turn the review into a stage, and people stop bringing the ugly problem.
Once a month, spend the same slot on the numbers: imports, cousins, open deprecations. Twenty minutes. If you cannot bear numbers, you will govern by anecdote, and the anecdote will be the loudest squad.
Say: the unscheduled work is the questions in Slack. The review exists so those questions have a place, and so Slack is not the system of record. Answer fast in Slack when it is a pointer to a name. Bring it to Tuesday when it is a new decision.
This is teamwork. Handoff does not get fixed by a colder spec. It gets fixed by a room, even a video room, that looks at the same part and can change it.
Land: folklore is what you have when the person who remembers is out. Tuesday is how the memory gets written down.
Swatches, side by side.
CSIRO, CC BY 3.0
Swatches you can compare because they are in one view. Credit the picture, it is required: CSIRO, CC BY 3.0. The line on the plate is ours.
Say: put the allowed button beside the one you are retiring, in the doc or in the review, so the difference is visible. People do not deprecate what they cannot tell apart. Side by side is the kindness.
Do not linger on the license. The credit is on the slide. Move to the scar, which is the last practice before the close.
Memory
Keep the scar in the file.
One sentence on why it failed. The next person will propose it again.
Short and serious.
When you remove a pattern that caused a real problem, write why. Not a postmortem novel. One sentence next to the decision. "We do not use a second primary for marketing pages. It trained people to miss the real action. Removed March 2026."
Without the scar, a new lead with good taste will reintroduce it during a campaign, and you will relive the quarter. With the scar, you can still reopen the decision. You will do it on purpose.
This is also how you treat accessibility misses and contrast mistakes. The fix is the token. The sentence stops the revert.
I do not want a culture of blame. The scar names the decision, not the person. If your organization punishes the sentence, people will stop writing it, and you will pay the tuition again. Protect the sentence.
Then honest next steps. You are close to time.
The case is still the source.
Greenwich Letterpress, CC BY 2.0
The case, labeled, still the source. Credit on the plate: Greenwich Letterpress, CC BY 2.0.
Say the test one last time, in the next slides, but preview it: if a new person cannot find the letter, the case has failed, no matter how many letters you bought.
Almost done.
Honest next steps
Publish the door. Invite one squad. Delete one thing.
If you want the door read before you publish it, bring it to the consult.
Monday is small on purpose.
Write the half page. Name the owner and the hours. Pick the squad you will invite, and ask them this week, not after the docs are perfect. Pick the thing you will retire, and put a date on it even if the date is day ninety.
If you want a second pair of eyes, Get a free consultation. Thirty minutes. No pitch. Bring the import count if you have it, or the confession that you do not. I would rather see the checklist draft than a strategy deck.
Do not start a tools evaluation this month. The door is not a platform. You can govern out of the repo and the library you already have.
The other talks cover the cost model, the token names, and the design engineering role. This one was the social system around those. Without it, the names and the role still fail quietly.
Stop. The line is next.
Design Engineering Studio
If they cannot find it, you do not have it.
A door, an owner, a retirement.
christophhellmuth.com
Read the line. Then the three words if you want a second sentence: a door, an owner, a retirement.
Questions. Stay here or go to the prompt. Do not summarize the checklist again unless someone asks.
Questions
Who can say no, and how fast is the door?
If either answer is unclear, that is the work.
Ask the question on the slide and wait. The useful answers are specific: a name, a number of days, a recent no.
If they say the VP says no: that is an escalation path, not an owner. The owner should say no weekly, on variants, so the VP is not in the button business.
If they say the door takes a month: it is not a door. Find the wait. Usually it is a review that wants a slide, or an owner with no hours. Remove one wait this month and measure again.
If they have no library yet: do not invent governance for an empty case. Build one component, with an owner, and the door can be a paragraph. Scale the ritual after the second squad arrives.
If they ask about contribution from many countries and time zones: write the checklist so it can be followed without the meeting. Use Tuesday for the decisions that are actually new. Async for everything the checklist already answers. Aurora's teams were not sitting in one room. The names and the review had to travel.
End on the line. If they cannot find it, you do not have it.
You are at the half hour when this conversation has had a few real questions, not a second lecture.