Foundations That Scale

overview

A product with no shared language, no components, and no room to scale

When Master Lock took over design responsibilities for cLOTO, the product had no design system, no shared language, and no scalable foundation. Every component was hard-coded, every decision undocumented. And the scope of what lay ahead was significant: a platform destined to expand across industrial facilities of every size and complexity — from small operations with tens of machines and users, to large enterprises managing hundreds of isolation points, thousands of users, and multi-layered hierarchies with varying lockout/tagout protocols. Without a robust design system, none of that growth would be possible.

Why It Had to Be Built

A safety-critical product without a foundation is a liability..

In a consumer app, inconsistency could just be a nuisance. In a safety-critical industrial platform, it's a liability. Inconsistent components, ambiguous labels, and unpredictable interactions don't just frustrate users — in an environment where lockout/tagout procedures protect lives, they can lead to errors with real consequences.

...and a scalability risk we couldn't afford to ignore

The practical risks were equally significant: without a shared system, every new feature would require design decisions to be made from scratch, components would drift across platforms, and engineering would inherit a growing inconsistency debt. We began laying the groundwork early, knowing the full build was coming in Phase 2 — so that when the time came, we had a head start rather than a blank page.

Foundational components

Building the visual language from the ground up...

The foundation of the system was built collaboratively, covering the full spectrum of visual fundamentals. We defined:

Layout grids across desktop, tablet, and mobile breakpoints;
Elevation and shadow;
A token-based color system supporting both light and dark modes — designed with industrial conditions in mind. Colors weren't chosen arbitrarily: every color had to meet accessibility contrast standards against its inverse, and secondary, tertiary, and attention-drawing colors were validated to ensure sufficient contrast between text and background. We applied widely recognized color-coding conventions so that warnings, errors, and positive outcomes would be instantly recognizable — even in poor lighting or dusty conditions, leaving no room for second-guessing. All colors were also compared in grayscale to ensure they differed enough in shade for color-blind users to distinguish them.
A token-based typography system scaled across breakpoints — balancing brand expression with legibility under real-world constraints. Fonts had to reflect the Master Lock brand while remaining readable at all times: on older devices with smaller screens, in low-light industrial environments, and through the dust and PPE that field workers contend with daily.

approach:

Color and typography choices being dictated by field conditions

Electrician in hard hat and gloves working on an electrical panel with wires and circuit breakers.

Hand holding clear safety goggles with wristbands on a green and white background.

Hand holding yellow corded reusable earplugs with translucent silicone tips against a black background.

Hand holding a black-cased iPhone showing lock screen with date June 21 and time 8:53.

Lenovo ThinkPad laptop showing 8:38 time and June 21 date, with a purple Yeti cup on the desk.

Hand wearing a white protective glove with a yellow sleeve in a workshop setting.

...with an unexpected font challenge along the way...

The brand guidelines specified a typeface for which Master Lock didn't hold a license. Rather than stalling, we led a focused research effort to identify free alternatives that met our needs, aligned stakeholders quickly, and secured approval to move forward — keeping the project on track without compromising on quality.

solution:

Anton SC paired with Inter became a great free alternative to Trade Gothic Next Pro that allowed us to move along with the development.

Web app typography samples using Anton SC for display and Inter for body text with sizes and weights shown.

...and well-thought-out visuals

Iconography was designed as a cohesive custom set, visually unified across the platform, and complemented by a series of product illustrations centered around padlocks. The product illustrations weren't purely decorative — they served a functional purpose. The cLOTO platform had launched with 2 types of padlocks - a mechanical and an existing connected one. For phase 2, the hardware and firmware teams were tasked with designing a brand new cLOTO padlock from scratch, which the cLOTO software would also need to support
The illustration set had to visually represent all three devices accurately and consistently across the platform, making it an integral part of the design system rather than an afterthought.

Core Components

Cross-platform components — accessible by design, built for the field...

A shared set of components formed the backbone of the system, designed to work seamlessly across both the web platform and mobile apps. Accessibility wasn't an afterthought — it was a core design constraint from the start. Every clickable and tappable element had to be large enough for a worker wearing goggles to see clearly and gloves to tap accurately. The commonly accepted 44x44px minimum touch area — while standard in consumer products — simply wasn't sufficient for a mobile experience used in PPE-heavy industrial environments. We exceeded that baseline across the board. Components included:

Buttons
Badges — for statuses, isolation point types, and more
List items
Input fields
Display fields
Dropdowns
Banners
Tooltips
Progress indicators
Dialogs — with intentional layout differences between platforms: a single button row on web, stacked full-width buttons on mobile

constraint:

A worker wearing goggles and/or gloves must be able to interact with the UI at all times.

Electrician wearing safety gear locking a circuit breaker with a red padlock and tag.

...extended for the web platform...

The web app required a deeper set of components to support its more complex navigation and data-heavy workflows. These included

Breadcrumbs
Headers
Tabs
List tables — including rows, sorting UI, and pagination
Display cards
Navigation bar
Footer

...and refined for native mobile experiences

A few mobile-specific components were designed to reflect native patterns and the constraints of smaller screens, ensuring a fluid and familiar experience on both iOS and Android. These included:

Mobile header
Mobile hero
Mobile list item

Interactive Design System

Bringing the system to life — without a single line of code

One of my most impactful individual contributions was translating the static design system into a fully interactive prototype in ProtoPie — entirely on my own. Key components were prototyped to reflect real interactions: hover and pressed states for buttons and list items, the full dynamic behavior of input fields — including the disappearing placeholder label as a user begins typing, and the appearance of a clear button the moment the first character is entered. This interactive layer served two critical purposes: , and it gave engineers a precise, interactive reference for component behavior before implementation began — significantly reducing back-and-forth and saving meaningful development and QA time.

It enabled high-fidelity, immersive prototyping for usability testing for the whole team;
It gave engineers a precise, interactive reference for component behavior before implementation began — significantly reducing back-and-forth and saving meaningful development and QA time.

To see the system in action, I've put together a video walkthrough that covers the key components and interactions in detail - available to watch below.

documentation

A system is only as strong as its documentation

Building the components was only part of the work. To ensure the system could be used consistently — and maintained as the team grew — I initiated and led the creation of three foundational documentation layers.

...so we documented how every component works, ...

Design system guidelines covered how each component should be used in practice. For example, for buttons, I outlined primary, secondary, tertiary, and destructive hierarchy; all states and their purposes; icon + label + counter placement rules; touch areas; button docking and scroll behavior; and component variants. The same level of detail was applied across every component in the library.

...how shared patterns should behave, ...

Cross-platform functionality guidelines documented how key behaviors worked across the system — covering navigation, search, pagination, filtering, sorting, loading states, empty states, and image functionality. These ensured that shared interactions were defined once and implemented consistently, regardless of platform or feature area.

...and how every word of the copy should be crafted.

Language guidelines established the voice and tone of the platform, alongside rules for capitalization, date and number formatting, punctuation, and pronouns. A product glossary standardized terminology across every surface — decisions like always using "sign in" and "sign out" (never "log"), and "equipment" instead of "machines," ensured the platform spoke with one consistent voice regardless of who was designing or building it.

Adoption & Impact

A foundation built once, adopted everywhere

The design system's reach extended well beyond its origins. When our strategic partner Value Hybrid built out the engineering component library, our team supported the implementation directly — ensuring design intent translated accurately into code. As the cLOTO enterprise platform began taking shape in the summer of 2025, the existing design system was adopted as its foundation — a natural extension that validated the scalability of what we had built. When Master Lock began its own in-house implementation, I personally onboarded the team, walking them through the system's scope, logic, and documentation. What started as a solution to a single product's inconsistency problem had grown into a shared language across multiple teams, platforms, and implementations.

My Role & Leadership Arc

From builder to steward

My involvement with the design system spanned its full lifecycle — from laying early groundwork during Phase 1, through the intensive build-out of Phase 2, and into an ongoing mentorship role in 2025-26 as new designers joined the team. I contributed directly to the majority of core components, created the interactive design system in ProtoPie, initiated and delivered both the design system and language guidelines, and onboarded two separate engineering teams on implementation. As the team evolved around me, my role shifted naturally from hands-on builder to the person who set the standard, maintained quality, and ensured continuity.

Key Contributions

Co-built the foundational visual language: grids, tokens, color, typography, iconography, and illustration
Led or contributed to the majority of core and platform-specific components across web and mobile
Single-handedly built the interactive design system in ProtoPie, enabling immersive testing and precise engineering handoff
Initiated and delivered design system guidelines and language guidelines from scratch
Documented cross-platform UX patterns including search, filtering, sorting, pagination, loading, empty states, and image functionality
Supported component library implementation with Value Hybrid's engineering team
Onboarded the Master Lock in-house engineering team on the design system
Mentored incoming designers on system usage, documentation standards, and maintenance

what I'd do differently

Prototyping components in parallel, not in bulk

Building the interactive ProtoPie system after the static components were already defined meant going back through everything at once. Prototyping each component as it was designed would have caught interaction edge cases earlier and given engineers a reference sooner.