Panduit Design System · Atomic Design

Design
System
from Zero

Building Panduit's first enterprise design system from scratch — applying Atomic Design methodology to create a scalable Pattern Library that unified product teams across a global industrial network infrastructure company.

My Role
Senior Product Designer
Methodology
Atomic Design
Scope
Full Design System
Output
Pattern Library
Design System Atomic Design Pattern Library Component Library Design Tokens Documentation Enterprise UX
05 PAGES 04 TEMPLATES 03 ORGANISMS 02 MOLECULES 01 ATOMS Primary Button Secondary Design Tokens — Color System H1 Heading Bold H2 Section Title Body text — Work Sans Regular 400 code · mono · 12px Typography Scale — Design System Card Component Molecule — Panduit DS View Details PANDUIT DESIGN PATTERN LIBRARY · ATOMIC DESIGN
Methodology
Atomic Design — Atoms → Pages
Deliverable
Full Pattern Library in Figma
Scope
Atoms · Molecules · Organisms · Templates · Pages
Industry
Enterprise · Industrial Network Infrastructure

01 — Strategic Context

Building a Design System
for an Enterprise Giant

Panduit is a global manufacturer of network infrastructure solutions — electrical, data networking, AV, and industrial automation systems. With products across dozens of categories and multiple digital touchpoints, the product teams were operating without a shared design language. Every team was building components independently. There was no system.

The assignment: build the first enterprise-grade Design System and Pattern Library from scratch, using Atomic Design methodology — creating a single source of truth that could scale across product lines and be maintained by distributed teams.

"A design system isn't a component library. It's an agreement — between designers, developers, and product owners — about how the product speaks."
Why Atomic Design was the right choice: Panduit's product ecosystem spans hundreds of UI components across multiple platforms. Atomic Design's five-level hierarchy (Atoms → Molecules → Organisms → Templates → Pages) maps directly to how engineering teams think about component reusability — making adoption significantly easier than a flat component library would have been.
Company Context
Panduit — Network Infrastructure Leader
Global manufacturer and innovator of electrical and network infrastructure solutions. Physical layer infrastructure that connects buildings, data centers, and industrial environments across the world.
Multiple digital product touchpoints
Distributed product teams pre-design-system
No shared component language before this project
Enterprise-grade accessibility requirements
PANDUIT DESIGN PATTERN LIBRARY Open in Figma →
PANDUIT
Design Pattern Library
Atoms Molecules Organisms Templates Pages
The Panduit Design Pattern Library — built in Figma using Atomic Design methodology. Click to explore the full library.

02 — The Challenge

The "Everyone Is
Designing Alone" Problem

Enterprise design systems fail for predictable reasons. The challenge wasn't just building components — it was building the right components in the right order, with the right documentation, so that teams would actually adopt them.

01
No existing shared language
Every product team had its own interpretation of the Panduit brand in UI. Buttons looked different. Typography was inconsistent. Color usage was ad-hoc. There was no inventory of what existed — before I could build, I had to audit.
02
Choosing the right abstraction level
The core design system question: how atomic is too atomic? Building at the wrong level means either too much rigidity (teams can't customize) or too little structure (teams ignore the system). Getting the molecule/organism boundary right required understanding how each team actually built their interfaces.
03
Enterprise accessibility requirements
Panduit's digital products serve enterprise clients with strict accessibility mandates. Every component had to be WCAG 2.1 compliant from day one — not retrofitted. This meant color contrast, focus states, keyboard navigation, and ARIA patterns had to be built into the atomic level, not added later.
04
Making the system adoptable, not just correct
A design system that nobody uses is a documentation project. The real challenge was designing for adoption: clear naming conventions, predictable component APIs, documentation that developers could read without a design background, and enough flexibility that teams didn't feel constrained.
The Fundamental Tension
Consistency vs. Flexibility
A design system's value comes from consistency. But if it's too rigid, teams work around it — defeating the purpose entirely. The entire architecture was designed around this tension: strict at the atomic level, flexible at the organism and template level. Atoms are non-negotiable. Templates are composable.
The "But we're different" Problem
Every team thinks their use case is the exception
Every product team believed their context was unique enough to justify custom components. Some were right — but most weren't. Managing this required showing teams the cost of divergence: duplicated maintenance, inconsistent user experience, and the compounding debt of unsynchronized updates. The design system had to sell itself.

03 — Methodology

Atomic Design — Applied
With Discipline

Brad Frost's Atomic Design framework gave us a shared mental model across design and engineering. But applying it to an enterprise product required making explicit decisions about what belongs at each level — decisions that are easy to get wrong and hard to undo.

Level 01
Atoms
The smallest indivisible UI elements. Cannot be broken down further without losing their function.
Color tokens (primary, secondary, semantic)
Typography scale (H1–H6, body, caption)
Spacing system (4px base grid)
Icons (stroke width, sizing rules)
Buttons (states: default, hover, active, disabled, loading)
Form inputs (text, select, checkbox, radio)
Tags & badges
Every atom is non-negotiable. Teams cannot modify atoms — they can only use them. This is where brand consistency is enforced.
Level 02
Molecules
Simple combinations of atoms that form functional UI units with a single, clear purpose.
Search bar (input + button + icon)
Form field (label + input + error state)
Navigation item (icon + label + active state)
Breadcrumb (multiple links + separators)
Tooltip (trigger + content + positioning)
Card header (title + subtitle + action)
Molecules define interaction patterns. The "form field" molecule includes all four states (empty, focused, filled, error) — teams get the full behavior, not just the layout.
Level 03
Organisms
Complex UI sections composed of molecules and atoms, forming a distinct section of the interface.
Navigation bar (logo + nav items + search + auth)
Data table (headers + rows + sorting + pagination)
Product card grid (multiple cards + filtering)
Filter panel (multiple form molecules)
Modal / dialog (header + content + actions)
Footer (link groups + legal + social)
Organisms are where team customization begins. The data table organism has configurable columns, sorting rules, and action patterns — built in, not bolted on.
Level 04
Templates
Page-level layouts that define content structure without actual content — wireframe-quality organisms in position.
Dashboard layout (nav + sidebar + content area)
Product listing page (filter + grid + pagination)
Detail page (hero + content + related items)
Form page (multi-step or single-step)
Authentication flow
Templates are the design system's handshake with engineering. Each template has a documented layout grid, spacing spec, and breakpoint behavior.
Level 05
Pages
Specific instances of templates with real content — the finished product that users actually interact with.
Product catalog with real Panduit products
Network infrastructure configurator
Account management portal
Technical documentation hub
Error states (404, 500, maintenance)
Pages are where the design system proves its value — when new pages can be assembled from existing templates and organisms in hours, not days.

04 — Design Tokens

Tokens First —
The Foundation

Before a single component was designed, I established the design token system. Tokens are the single source of truth for every visual decision — color, typography, spacing, shadow, radius. They're the mechanism that makes "update once, apply everywhere" actually work.

Color System

TokenValueUsage
color.brand.primary #0066CC CTAs, links, active states
color.brand.secondary #00B4D8 Accents, highlights
color.status.success #2ECC71 Confirmations, valid states
color.status.error #E74C3C Errors, destructive actions
color.status.warning #F39C12 Warnings, pending states
color.neutral.900 #1a1a2e Primary text, dark surfaces

Spacing Scale — 4px Base Grid

4px
xs
8px
sm
16px
md
24px
lg
32px
xl
48px
2xl
64px
3xl
Why tokens before components is non-negotiable: If you build components first and define tokens after, you'll refactor every component when the tokens get formalized. I spent two weeks on token architecture before touching a single component. Those two weeks saved months of rework.
Typography Scale
H1 — 32px / 800
type.heading.h1 · line-height: 1.2
H2 — 24px / 700
type.heading.h2 · letter-spacing: -0.5px
Body — 15px / 400 · Work Sans
type.body.default · line-height: 1.6
Caption — 12px / 400
type.caption · color: neutral.500

05 — Component Library

From Atoms to
Complete Interfaces

The Pattern Library documents every component at every level of the atomic hierarchy — with usage guidelines, state variations, accessibility specs, and code snippets. Here's the scope of what was built.

ATOMS The indivisible building blocks

BUTTONS — 5 variants × 4 states = 20 documented components
Primary
Secondary
Tertiary
Disabled
Destructive
FORM INPUTS — Each with 4 states (default / focused / filled / error)
Search Panduit products...
invalid@email
✗ Please enter a valid email address
Category
TAGS & STATUS INDICATORS
Network Infrastructure ● Active ⚠ Pending ✗ Error NEW

MOLECULES Functional combinations with single purpose

SEARCH BAR MOLECULE
Search
Atoms used: Input + Button + Icon
BREADCRUMB MOLECULE
Home / Network / Copper / Patch Panels
Atoms used: Link × n + Separator

ORGANISMS Complex interface sections

P
PANDUIT
ProductsSolutionsResourcesSupportAbout
Sign In
Home/Resources/ Technical Documentation
Navigation bar organism — uses Logo atom, Nav item molecules, Search molecule, Auth button atom. Fully responsive with mobile hamburger pattern.
PANDUIT DESIGN PATTERN LIBRARY — Complete Figma file Open full library ↗
The complete Panduit Design Pattern Library — browse atoms, molecules, organisms, templates, and pages directly in the embed.

06 — Key Design Decisions

The Architecture Calls
That Defined the System

A design system is mostly decisions. These are the ones that shaped the final architecture — and the reasoning that made each choice defensible.

DECISION 01 — Most Impactful
Tokens before components — non-negotiable sequencing
Every enterprise design system I've seen that was built "components first, tokens later" eventually required a full refactor. The temptation to start with visible outputs (buttons, cards, navbars) is enormous — stakeholders want to see progress. But building components without an established token system means every component uses hardcoded values that later have to be replaced one by one.
What this cost: Two weeks of work before any visual output existed. What this saved: Approximately 40+ hours of component refactoring that would have been required if token architecture came after component build.
DECISION 02 — Most Contested
Strict atoms, flexible organisms — where to enforce vs. where to enable
The biggest internal debate: how much flexibility to give teams at each level. Some stakeholders wanted the entire system to be customizable. Some wanted it completely locked. The resolution was a tiered model: atoms are non-negotiable (no team can modify color tokens or button states), molecules have limited flexibility (layout variants but not visual changes), organisms are composable (teams can combine them differently), templates are starting points.
WRONG APPROACH
Fully flexible system where every component is a suggestion. Produces "design system" that nobody follows because there's no real standard.
VS
CORRECT APPROACH
Strict at the base (atoms/tokens), flexible at the top (organisms/templates). Brand consistency enforced where it matters, team autonomy where it's safe.
DECISION 03 — Most Technical
Building for the developer handoff, not just the designer
A design system's real test is whether developers can implement it without constant design review. Every component in the Panduit Pattern Library was documented with: the component's purpose, its atoms, its state variations, its accessibility requirements (WCAG 2.1 AA), its CSS custom properties (mapped to tokens), and its responsive behavior. The Figma file was structured as a living specification, not a reference document.
The metric that mattered: Could a developer implement a new page using only the Pattern Library, without asking a designer a single question? By the end of the engagement, the answer was yes — for standard pages. That was the target.
DECISION 04 — Hardest Discipline
Saying no to one-off components
Throughout the engagement, product teams requested custom components for "unique" use cases. The discipline of a design system requires evaluating each request against the existing component library before building anything new. In practice: 80% of "unique" requests were solved by composing existing organisms differently. 15% required a new molecule or organism variant. Only 5% genuinely required a new component — and those were added to the system, not built as one-offs.

07 — Obstacles & Resolutions

What Tried to
Derail the System

Obstacle
"We already have our own components"
Multiple teams had invested months building their own component libraries. Asking them to abandon that work for the new system was met with resistance — understandably. The existing components represented real sunk cost and institutional knowledge.
Resolution
Mapped existing team components to the new atomic hierarchy rather than replacing them immediately. Teams could see where their work fit within the system — which reduced resistance and created a migration path instead of a hard cutover.
Obstacle
Accessibility at every level, not just UI
WCAG 2.1 AA compliance isn't a button property — it's a system property. Color contrast, keyboard navigation, focus management, ARIA patterns, and screen reader behavior all have to be designed at the atomic level and maintained through every composed organism.
Resolution
Built accessibility specs into the atom documentation before any component was assembled. Every color token was tested for contrast against both light and dark backgrounds. Every interactive atom documented its keyboard and focus behavior. Accessibility became infrastructure, not a checklist.
Obstacle
The system growing faster than the documentation
As more components were added, documentation became the bottleneck. Teams were using components before the usage guidelines and code specs were written — leading to inconsistent implementations that undermined the system's purpose.
Resolution
Adopted a "documentation-first" policy: no component shipped without a complete spec. Slowed velocity in the short term but eliminated the "implemented wrong" problems that would have required retroactive corrections across multiple codebases.
Obstacle
Naming everything in a way that scales
Naming is one of the hardest problems in design systems. Names that seem obvious to the designer who created a component often don't translate to engineers, to new team members, or to future components that weren't imagined at the time of naming.
Resolution
Adopted a semantic naming convention based on purpose, not appearance. color.status.error not color.red. button.action.primary not button.blue. Semantic names survive rebrands; appearance names don't.

08 — Impact & Learnings

What Building a Design
System Taught Me

5
Atomic levels built with complete component coverage at each tier
1st
Enterprise design system in Panduit's history — no prior shared component language existed
0
Hardcoded values in the final system — every visual decision traced to a named design token
01
A design system is governance, not just craft
Building beautiful components is the easy part. The hard part is the governance model — how decisions get made, how new components get added, who can modify tokens, and how teams stay synchronized over time. I learned that the Figma file is the least important artifact. The decisions about who controls what are the real design work.
02
Semantic naming is an investment in the future
Every name in a design system is a contract. Names that describe appearance (color.blue-600) break when the brand evolves. Names that describe purpose (color.action.primary) survive rebrands, theme changes, and organizational shifts. The extra thinking time spent on naming is the highest-ROI investment in a design system.
03
The real adoption metric is developer autonomy
A design system succeeds when developers can build correct interfaces without asking designers. Not "mostly correct" — correct. That requires documentation that reads like engineering specs, not design rationales. The shift in how I wrote component documentation — from "here's what it looks like" to "here's the contract between this component and its consumers" — changed adoption rates fundamentally.
04
Accessibility at the atomic level eliminates the hardest retrofitting
Every team that retrofits accessibility onto an existing design system faces the same painful discovery: fixing contrast in a button requires finding every button in every product. Building WCAG compliance into atoms means it propagates automatically to every molecule, organism, and template that uses those atoms. The investment compounds upward. Retrofit is always more expensive than foundation.
Explore the Pattern Library
The complete Panduit Design Pattern Library — atoms, molecules, organisms, templates, and pages. Every component documented with usage guidelines, state variations, and accessibility specs.
Open Pattern Library ← Back to Portfolio