Loom for design-system owners: run the system, not the inbox

You are the person everyone asks. Requests arrive in chat, in comments and in the corridor, and the system is only as healthy as your memory of all of them. Loom puts every ask in one queue with an owner and a due date, writes every decision into the record, and tells you each week what needs you.

The real pain today

Everything routes through you. Owners exist on paper, but the questions still come to you, because nobody else is sure they may say yes.

Decisions leave no trace. You agreed a variant in a thread three months ago. Nobody can find the reason, so the argument starts again.

Exceptions never end. A team was allowed to break a rule for one release. A year later others copy it, and you cannot say who allowed it or until when.

You cannot show progress. Leadership asks whether the system is getting better. You have a feeling, not a number.

Your week with Loom

Monday. You open your home in the control area. It lists what Loom asks of you this week: the items past their service level, a deprecation whose removal date has passed, and, if it is still missing, the sign-off of roles and RACI. See the system owner's home

Tuesday. You work the review queue. Each item shows its decision type, its weight and the working days left, and light decisions are already routed to the right area owner. You decide a heavy one against its checklist, with the evidence Loom could gather already filled in, and record one of five outcomes with a reason.

Wednesday. An area owner is on leave. Their items move to their named delegate on their own, and the record says who decided on whose behalf. Accessibility items wait for an accessibility owner: a delegate never carries that authority.

Thursday. The weekly triage. Loom has drafted the agenda from the records: overdue reviews, contested proposals, expiring exceptions and changes released since last time. See the rituals

Thursday, after triage. You check the adoption campaigns: each one shows progress per team from the usage snapshots, a burndown against its plan line and the codemod that helps; Loom drafts the nudges for you to approve. Your home flags a campaign that is behind its plan. See the campaigns

Friday. You plan design debt into the next sprint from the debt ledger: each item comes from an audit finding, an exception or a divergence, with an owner, a size from S to XL (never hours or money), its age and the teams it affects. See the debt ledger You change a rule's severity for one area in the management space. The edit becomes a proposal against the governance records in your repository, reviewed like code. You approve the release notes Loom drafted for the week.

What changes

You stop being the router. The queue routes by weight, the delegate covers absence, and the record answers "who decided this, and why".

Loom measures what you get back, and shows where each number comes from: review time in working days, the share of decisions made inside their service level (items still waiting past it count as missed), exceptions closed on time, and the health score over time. These sit on your home beside the work, so the trend is in front of you every Monday. In the product tour they are sample values; in your organisation they are computed from your own records.

What you never have to do

You never chase who owns a request. You never rewrite a decision from memory. You never discover a year-old exception by accident, because each one expires after at most 90 days and comes back to its owner. You never assemble the triage agenda by hand. Campaigns and the debt ledger are built and tested on sample systems; they have not yet run in a client repository.

The design-system owner's home in Loom's control area: the week's queue, decisions waiting, what agents did and the measured benefit, with sample data.
The design-system owner's home in the product tour. Sample data: Harbor UI, a synthetic system. Open it in the tour.

Coming next

The role homes will read identities live from your git host on every action, not only when a decision is recorded. Loom will also open the pull request for an accepted management change on its own once your GitHub App is registered and installed; today a person opens it from the accepted draft.

Questions

Can I change the defaults?

Yes. Loom starts with a review service level of two working days, exceptions of 90 days at most, deprecations kept for two minor releases with a codemod, agents that only suggest, and a release every two weeks. Each is a setting in your own records.

Who signs off the roles?

The executive sponsor and the system owner, at kickoff. The sign-off records which version of the role model it covers, so a later change shows it as out of date until both sign again.

Start with a conversation about your system.

We read your system, show you what we found, and agree with your team what to fix first.