A good tool is not a way of working
Documentation platforms, Figma libraries and code checks are good tools, and design teams should use them. Some teams run them very well. But a tool does not decide who owns a rule, who reviews a change or what happens when a deadline meets a standard.
When five designers share a library with no agreed way of working, the system falls apart quickly. Each person makes a reasonable choice. Nobody sees the whole. After a few months the library describes one product and the code describes another.
This is not a failure of the people involved. It is a missing structure. The organisation never decided how the system is run, so every decision is made again, by whoever is closest.
A design system is not a library. It is an agreement about how a team works, kept up to date.
Loom gives the way of working its own place
Loom's control area has an Ops space for exactly this: the team and its roles, the rituals, one support queue, onboarding, the messages the system sends, and what happens when someone leaves. Everything in it is drawn from records in your repository, and every change to it is a reviewed pull request. Partial What does not work yet: it has not run on a client's records, and messages are drafted for an owner to approve, not sent.
Ops at a glance
Real screen, sample records
Every area has an owner, and the owner has a name
We start by agreeing who holds which part of the system. There is a system owner, an owner for each area, and a small guild of three to seven people across design, engineering, content and accessibility. Each role is a record in your repository, so anyone can see who decides what. Working
A team of three or fewer gets no standing meetings by default. Roles scale with the team, not the other way round.
# loom/owners.yaml (sample record)
system: Harbor UI
owner: Head of design
areas:
foundations: Design-system lead
components: Front-end lead
brand: Content design lead
guild: [Design-system lead, Front-end lead, Accessibility specialist, Content designer]
Nothing waits without a name on it
Every request, proposal and exception sits in one review queue. Each item shows its owner, its due date and the working days left, or how long it is overdue. The default service level is three working days, and your organisation sets its own. Working
This changes the conversation. The question is no longer "has anyone looked at this?" It is "who has it, and when is it due?"
One support queue
Real screen, sample records
Rituals are prepared, not improvised
A design system needs a small number of regular meetings: a weekly triage, a release review, a quarterly look at health. They work when they are short and prepared. Loom drafts each agenda from the queue and the health measures, and prepares a calendar invite and a message for your team. Partial
Rituals on a calendar
Real screen, sample records
What does not work yet: posting to a real Slack or Teams workspace. Notifications in Slack and Teams are planned. Concept
Weekly triage, drafted by Loom (sample)
1. Overdue: date range picker request (Components owner)
2. Due this week: color.text.danger proposal (Foundations owner)
3. Expiring in 14 days: raw colour in the checkout banner
4. Health: drift up 3 items since last week; adoption not measured
The system speaks with one voice
Release notes, migration notices, a monthly digest and a short report for leadership are drafted from the same records, so they never contradict each other. An owner approves each one before it goes out. Partial What does not work yet: sending them; today an owner copies the approved text.
Comms centre
Real screen, sample records
Exceptions are allowed, and they end
Real products need exceptions. The mistake is to let them become permanent without anyone deciding so. Every exception in Loom records the rule, the reason, who asked, who granted it and an expiry date, at most 90 days later. When it expires, the issue comes back to its owner. Working
# loom/exceptions/checkout-banner.yaml (sample record)
rule: no-raw-colour
where: Checkout banner
reason: Campaign artwork, ends with the campaign
requested_by: Growth team
granted_by: Foundations owner
expires: 2026-11-08 # at most 90 days
Disagreement is measured before it is argued
Design, engineering and product often see the same system differently, and each view is partly right. In a paid discovery, each discipline answers the same questions in a team survey. Answers are encrypted in the respondent's browser, and no group smaller than five people is shown on its own. The result shows where the views differ, so the conversation starts from evidence. Partial
What does not work yet: the survey has run with synthetic answers only, and collecting responses is manual.
The system owner sees the whole picture
The owner's first view shows four groups of measures: adoption, drift, flow and quality. Where there is no source for a measure, it says "not measured" instead of guessing. Working
What leaders should do
If you lead a design organisation, treat the design system as a service your teams depend on, with owners, service levels and a budget. If you fund it, ask how it is run, not only what it contains. The tools matter. The way of working matters more.
Tools carry out what an organisation decides. We help you decide it, and keep it decided.
Questions
Is this a consulting service or a product? Both. Our experts set up the way of working with your team. Loom keeps it as records in your repository and does the routine work around it.
Do we have to change our tools? No. Loom works with the tools you have: your repository, Figma and your documentation platform, if you use one.
Is this heavy for a small team? No. Every change follows the same four steps: propose, review, accept and release. A team of three or fewer gets no standing meetings by default.