Master Lock cLOTO Design System

The design system behind Master Lock’s first major web product — and the work it took to get engineering to ship from it.

Role: Product Designer
Team: 3 Designers
Timeline: 2025 — present
Status: In production · Powering cLOTO at launch

Context

Master Lock has made lockout/tagout hardware for over a century. cLOTO is the company’s first major web product — software for the safety teams that run lockout/tagout every day. Three designers were building the whole thing from scratch, alongside a growing engineering team.

The problem

Without a shared system, three patterns kept recurring.

Designers re‑styling the same patterns from screen to screen.

Engineers re‑implementing components because every handoff looked different.

And inconsistent behavior across breakpoints and states — because nobody had written down what was supposed to happen.

A system that lived in Figma but didn’t reach the codebase wasn’t going to fix any of that.

My role

One of three designers building and maintaining the system. My contributions run across foundations, components, the icon library, the voice & tone layer, and the “release files” we hand to engineering.

Release files are implementation‑ready artifacts that document each feature’s workflow, breakpoints, responsive behavior, and the conditions and logic underneath.

I partner closely with engineering on what makes it into code, how it stays in code, and how new patterns get proposed and deprecated.

How we approached it

Three principles shaped the work:

Make the system the source of truth. Designers, engineers, and PMs reference the same components, tokens, and release files — so the team can settle visual debates and focus on shipping the product.
Document behavior, not just appearance. A button is the straightforward part. A button at three breakpoints, in five states, with two loading variants, anchored to a footer that doesn’t move on scroll — that’s the substantive work. Components and release files cover both.
Extend the system past visual design. Color carries domain meaning — like Isolation Point Type Colors, specific to lockout/tagout. Voice and tone has documented rules. Icons get deprecated, not duplicated.

The work isn’t finished when the components ship. It’s finished when engineering stops re‑implementing them.

Selected artifacts

Master Lock cLOTO Design System library overview showing five Figma files: Core UI Components, Foundational Components, Design System Guidelines, Language Guidelines, and Design Components. — The library at a glance. Five files: Core UI Components, Foundational Components, Design System Guidelines, Language Guidelines, and Design Components. Click to zoom & pan

The color system. Primitives, semantic tokens for backgrounds, content, and borders, plus a domain-specific Isolation Point Type Colors set used to label energy sources in lockout/tagout work. Click to zoom & pan

The icon library, which I helped design and maintain. Grouped by use — Action and Menu, System, Controls, Nav Bar, Alert, Isolation Points, User Profile — with a deprecated section so retired icons aren’t accidentally reused. Click to zoom & pan

Button Guidelines documentation covering sizing, hierarchy, button states, UI elements, touch areas, button dock and scroll behavior, types, and loading state. — Button guidelines. Sizing rules, visual hierarchy, the eight states, touch-area sizing for mobile, dock-and-scroll behavior on long forms, and loading state — written down so a designer or engineer doesn’t have to guess. Click to zoom & pan

Voice and tone documentation covering active versus passive voice and contractions, with do and don't visual treatments. — Voice and tone documentation. Rules for active versus passive voice, contractions, capitalization, dates and numbers, and pronouns — so the product speaks consistently across screens and writers. Click to zoom & pan

Annotated User List flow showing the live screen with column logic, sort behavior, and pagination callouts on top, and a clean version of the screen below. — A release file in practice. The User List screen with column logic, sort behavior, pagination, and edge cases documented inline. Engineering builds from this. Click to zoom & pan

Loading error state for the Users screen with a Try Again call to action and an annotation indicating the loading behavior reuses the same pattern as the locks screen. — The Users page loading error. The annotation tells engineering to reuse the loading behavior already documented for the Locks page — rather than spec a new one. Click to zoom & pan

Validation

Before launch, I tested the User Management flow with 10–20 participants in unmoderated Useberry studies. Participants completed the core tasks without stalling, and the screens didn’t need rework.

That’s the outcome you want before a B2B product meets its first customers — confirmation, not surprise. It also tells you something about the system itself: when the components, tokens, and release files do their job, the work is shippable on the first take.

Outcomes

The system became the source of truth for cLOTO.

Designers compose screens from components and tokens instead of redrawing them. Engineering builds from release files instead of asking the same questions twice.

The back‑and‑forth between design and engineering got shorter as the library and the release files matured.

We launched cLOTO on this system — the first product to ship under the new design language.

On a complex B2B product, the value isn’t saving an hour on a button. It’s reallocating that hour to the part of the workflow where a missed step has real consequences for the people on the floor.

What I learned

A design system only matters if engineering uses it. That means documenting behavior — not just appearance — and treating adoption as a design problem, not an engineering one.