Diatom

Building a bespoke design system for a complex B2B web product

In 2020, a migration from Angular to React and the adoption of a new headless CMS created the opportunity to look at selinc.com honestly. The audit revealed just how inconsistent things had become across components, layouts, and content. It was clear that a proper design system wasn't a nice-to-have and was really the only way to move forward with any coherence.

The First Decision: Build or Adopt

The first real decision was whether to adopt an existing open-source system or build our own. Selinc.com is a large, content-heavy B2B site with industry-specific needs that ranges in complexity and content types. We determined that a custom system would give us the flexibility an off-the-shelf solution couldn't.

We went with an atomic design approach, breaking components into Atoms, Molecules, and Organisms and defining foundational styles before building upward. Starting from scratch is daunting at scale, but atomic design made it manageable by establishing clear, logical relationships between components that the team could build on incrementally over time.

Governance: How Diatom Stays Intentional

A design system without governance is just a component library that slowly becomes inconsistent again. From early on, the goal was to make Diatom a system with opinions — one that could grow without losing coherence.

The Figma workspace is structured around that philosophy. Four folders define how work moves through the system:

03 Website

Presentation ready.

Holds stakeholder-facing mockups and concept presentations.

02 Templates

Scalable and efficient.

Pages that require dev resources and can't be assembled through the CMS alone.

01 Components

Works in progress

Where existing components go when they're being reconsidered or redesigned — our current tables revision lives here, as did the global navigation before it was finalized as an Organism.

00 Diatom Design System

The source of truth.

Houses the official component library and documentation, organized into Foundations, Atoms, Molecules, and Organisms.

03 Website

Presentation ready.

Holds stakeholder-facing mockups and concept presentations.

02 Templates

Scalable and efficient.

Pages that require dev resources and can't be assembled through the CMS alone.

01 Components

Works in progress

Where existing components go when they're being reconsidered or redesigned — our current tables revision lives here, as did the global navigation before it was finalized as an Organism.

00 Diatom Design System

The source of truth.

Houses the official component library and documentation, organized into Foundations, Atoms, Molecules, and Organisms.

The folder structure reflects the component lifecycle. When a new component need surfaces in a project, it isn't automatically added to Diatom. The decision goes through an evaluation: if there are no foreseeable use cases beyond that specific project, the component stays contained within it. If there's broader need (or if a previously tabled component is needed again) it gets fully specced, documented, and added to the official system.

The folder structure reflects the component lifecycle. When a new component need surfaces in a project, it isn't automatically added to Diatom. The decision goes through an evaluation: if there are no foreseeable use cases beyond that specific project, the component stays contained within it. If there's broader need (or if a previously tabled component is needed again) it gets fully specced, documented, and added to the official system.

The homepage carousel banner is a useful illustration of the inverse. It exists on the site but deliberately sits outside Diatom. Carousels are a pattern we don't want to proliferate across the site, so keeping it out of the system is itself a design decision. The system's absence of a component can be as intentional as its inclusion.

At 40+ components and growing, Diatom remains fully custom, though I consistently cross-reference other systems for best practices and evolving standards.

The homepage carousel banner is a useful illustration of the inverse. It exists on the site but deliberately sits outside Diatom. Carousels are a pattern we don't want to proliferate across the site, so keeping it out of the system is itself a design decision. The system's absence of a component can be as intentional as its inclusion.

At 40+ components and growing, Diatom remains fully custom, though I consistently cross-reference other systems for best practices and evolving standards.

What Diatom Has Made Possible

The impact of the system becomes clearest when you look at what the team can do now that wasn't possible before.

Before Diatom, there was no established dev handoff process.

Design and development were working without a shared language or baseline. The design system created a common reference point that both teams could work from, which fundamentally changed how design and engineering collaborate on selinc.com.

Marketing landing pages have been the most visible efficiency gain.

Before the system existed, putting together a fully built page ready for review took a day or more.

With Diatom, the same work takes one to two hours, provided content and assets are ready. Pages are assembled from existing components rather than designed from scratch, which also eliminated the inconsistencies and custom CSS classes that accumulated under the old approach.

The system has extended beyond design and dev entirely.

We built a set of modular Pardot landing page templates that program managers use independently for quick-turn campaigns: complete with built-in analytics and lead capture. Non-designers are running campaigns using a system built on Diatom's foundations without needing design or dev resources for every execution.

Accessibility has also been addressed more systematically as a result.

Violations were resolved at the component level by replacing flat PNGs with structured HTML, enabling keyboard navigation, and providing clear visual feedback. WCAG AA compliance became something the system carries forward automatically rather than something that has to be re-litigated on every new page.

Reflection

Looking back, I would approach the early stages differently, and I think that's a sign of how much I've grown.

From a resourcing standpoint, starting with an open‑source design system as a foundation would have reduced the initial burden. At the time, we underestimated the development effort required to build, iterate on, and maintain a fully custom system at the necessary pace.

From a design perspective, my understanding of development-ready components has deepened significantly. I’ve actively invested in that growth—studying other systems in Storybook, researching best practices, and progressively introducing design tokens and variables into the Figma Diatom library.

Through continuous learning and iteration, Diatom has evolved into a system I’m proud of—one that reflects both the technical needs of the product and my own growth as a systems‑focused designer.