Book a conversation
Menu

Academy: certify everyone who uses your system, and keep them current

A design system is only as good as the people who use it today. Loom Academy turns your system's own records into training for each role. People prove what they learned by doing the work in their own repository. They earn a certificate, and when the system changes, they get a short note on what changed for them.

New people learn from the last screen they saw

When someone joins a team, they learn the system by copying an old screen or the last pull request. If that screen was off the system, the new work is too. Drift starts in the first week, and nobody chose it.

This is not a failure of the new person. Most teams have no onboarding for their design system at all. The documentation exists, but nobody says which parts matter for your role, and nobody checks that you can apply them.

Training that is written once falls behind

A course about a design system is out of date the day a rule changes. People who completed it keep working from what they learned, with confidence.

Loom does not write the course by hand. Every lesson is built from the records in your repository: components, tokens, rules, patterns, governed flows, exceptions, decisions and deprecations. When a record changes, the lessons built from it change too.

If the training is built from the system, it cannot describe a system that no longer exists.

A path for each role

Each role gets its own path, with the lessons that matter for that role:

  • Designers and content designers: which component to use and why, tokens instead of values, patterns, content tokens and voice, and how to propose what is missing.
  • Developers: the same foundations, plus using Loom with an AI coding agent, exceptions, what is going away, and a first pull request that passes the system's checks.
  • Product managers: the five steps of a change, the review service level, and what is available to reuse.
  • System owners, area owners and accessibility specialists: how decisions are made, what each area covers, and how exceptions work.
  • Ops leads: rituals, the support queue and its service levels, and the messages the system sends.

A general track covers design-system practice that is the same everywhere: UX Ops, governance, contribution, working with AI agents, accessibility and content.

Learning is checked by doing the work

Quizzes have a place, but they do not show that someone can build on the system. Most lessons are done in the person's own repository and tools:

  • A first on-system pull request. The changed lines pass the agent contract checks, the same ones any coding agent's work is held to: system components only, tokens instead of raw values, documented props, and accessibility. No errors and no warnings.
  • A well-formed proposal. A real proposal file with the problem, the evidence and the layer it belongs to.
  • A fixed practice finding. A practice folder holds files seeded with findings your system really reports. The person fixes each one the way they would in a product.
  • A decision. Reviewers write a decision on a practice proposal, with an outcome and a reason.
  • An agent that knows the system. Their AI coding agent is connected to your system through MCP.

Progress is kept in your repository, by handle and team. It holds no names, email addresses or phone numbers.

Try a lesson

Sample lesson · Harbor UI

Tokens, not values: colour and spacing in Harbor UI

Every colour and space comes from a token, so a change reaches every screen.

  • Harbor UI has 18 tokens. Use them by name instead of writing a colour or a pixel value. A raw value cannot be found or changed in one place, and it skips the contrast checks.
  • Start with these: --semantic-text (Body and heading text on canvas or surface), --semantic-text-muted (Secondary text and hints; never for body copy below 14px), --semantic-canvas (Page background), --semantic-surface (Cards, fields and dialogs), --semantic-action (Primary action fill and links) and --semantic-danger (Error text and destructive actions).

Your practice file, academy-sandbox/PriceTag.tsx, has a raw colour. Pick a fix.

/** Practice: this file is seeded with a raw colour. Fix it so the system's checks pass. */
export function PriceTag(props: { label: string }) {
  return <p style={{ color: "#0f1f3d" }}>{props.label}</p>;
}
  1. Write the same colour as rgb() 
    /** Practice: this file is seeded with a raw colour. Fix it so the system's checks pass. */
export function PriceTag(props: { label: string }) {
  return <p style={{ color: "rgb(15, 31, 61)" }}>{props.label}</p>;
}

    Not yet: Hard-coded colour rgb(15, 31, 61) (color).

  2. Use the token --primitive-navy-900 
    /** Practice: this file is seeded with a raw colour. Fix it so the system's checks pass. */
export function PriceTag(props: { label: string }) {
  return <p style={{ color: "var(--primitive-navy-900)" }}>{props.label}</p>;
}

    Passes: no findings. In your repository, loom academy check tokens would record the lesson.

  3. Delete the component 
    export {};

    Not yet: PriceTag is gone: a fix keeps the component working.

Sample data: Harbor UI is a synthetic system. Each fix was checked by Loom's own audit when this page was built, the same check the Academy runs in your repository.

Certificates that stay current

Each path ends in a certificate, such as "Certified contributor (engineering)" for your system. Each certificate has an ID and a page where anyone in your organisation can check it. Certificates for your own system stay inside your organisation, because the pages are published by your own build, on your own hosting. The general-track certificate is not tied to your system, so its holder may share it.

When the system changes, a certificate shows "due for refresh" until the holder reads a short summary of what changed for them: a new component version, a rule that changed, a deprecation with its replacement. The summary is built from the same records, with the date of each change.

A certificate is evidence for a role, not a permission on its own. It shows who is ready to contribute and who is ready to review. Your system owner records the role, as with every other change to governance.

Mistakes become lessons, not blame

When your pull request reviewer sees the same mistake twice from the same person, it suggests the one lesson that teaches the fix, with the command to open it. The suggestion is advice. It never blocks a pull request and never reports anyone.

The Ops lead sees onboarding across teams

The Ops lead sees, per team, who is certified, who is due for a refresher, and who is still learning. Two measures matter most:

  • Time to a first on-system pull request. From the day someone joins to their first pull request that passes the system's checks.
  • Which lessons go with fewer findings afterwards. Findings of each kind per pull request, before and after people completed the lesson that covers them. This shows a pattern, not proof, and the page says so.

These measures sit with the others in your UX Ops space, and they are part of how the value of the system is shown after 90 days.

Coming next

  • Refreshers and suggestions will reach people in Slack, Teams or email, not only in the pull request and the command line.
  • The general-track certificate will have a public verification page hosted by Loom.
  • Reviewer findings will be recorded for each person automatically in CI, instead of with a command.
  • Each certificate will map directly to the permissions in your role model.
  • The Academy will run on its first client's records. Today it runs on sample records and a test repository.
Book a conversation

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.

Book a conversation Start with a free health check