ScienceLogic Design System — Kamala Espig

Design System · Platform Scale 6 Dev Teams 2019–2020

ScienceLogic · Token system · Components · Storybook · Shipped with Colosseum Release

ScienceLogic Design System —
consistency at platform scale.

Six development teams were building a major release. There was no shared component library, no unified visual language, and no time for a comprehensive audit. I built the design system that made the Behavioral Correlation release feel like one product — in parallel with the feature, not after it.

ScienceLogic Design System — component library in Storybook

Component library · Storybook · 2020

The component library as it appeared in Storybook — the engineering team's primary reference. Each component documented with all states, variants, and usage guidelines.

Shipped with BC release 6 teams unified Storybook

6teams building from a shared component library for the first time

↓ Timedevelopment time per component — built once, used consistently across the platform

Unifiedsingle visual language across web, mobile, and responsive from a fragmented baseline

The Problem

Six teams. No shared language. The company's biggest release incoming.

ScienceLogic's SL1 platform had grown across multiple product teams without a unified design system. Each team had developed its own component patterns. Behavioral Correlation was going to put all of them on screen at the same time — and the inconsistency would be impossible to miss.

The design system wasn't a future investment that could wait until after the release. It was a requirement for making the release coherent. The constraint was real: it had to be built in parallel with the feature, not ahead of it.

What made this different

Most design system work happens either greenfield or as retroactive cleanup. This was neither — it was building a system while the product it needed to unify was actively being built around it. Scope decisions mattered enormously.

How I Approached It

Scope to what the release needs. Build it to last.

The first decision was what not to build. A comprehensive system audit across the entire SL1 platform would have taken longer than the release timeline. I scoped the system to the components Behavioral Correlation actually required and established the architectural patterns that future components would follow.

Token system

Spacing, color, and typography architecture with usage examples. Every spacing value, color, and typography decision documented as tokens. Any component built from these tokens is visually coherent with any other — by construction.

Tokens came first. Establishing the token system before building any components meant that consistency was structural — it couldn't be accidentally violated by a team making a local decision. Storybook gave engineers a working reference that matched what was designed.

Component library

Components built from tokens, assembled into patterns. Updating a token updates every component that uses it — no manual propagation.

Storybook

Storybook as the engineering handoff layer. Each component shows every state and variant in context — reducing interpretation errors.

Key Decisions

Three decisions that made the system achieve scope and still scale.

→

Scoped to the release, built for extension

Building only what Behavioral Correlation needed kept the system achievable. But I designed the architecture explicitly for extension — so future components would fit into the system rather than sit alongside it.

→

Tokens before components — consistency as architecture, not enforcement

Starting with the token system meant that visual consistency was embedded in the building blocks. You can't accidentally deviate from a token you're required to use. That's a fundamentally more reliable consistency model than a style guide.

→

Storybook over a design-only library

A Figma library communicates design intent. Storybook communicates implementation. For a multi-team release working in parallel, the gap between those two things was where most inconsistency would have crept in. Storybook closed that gap.

What I Took From This

What building under a release deadline taught me about systems work.

A system shipped alongside the product is worth more than a comprehensive system that comes after. The value of a design system is in what it enables — and it can only enable things while the product is being built.

Tokens before components. Structural consistency is more reliable than documented consistency. You can't guarantee teams follow guidelines — but you can make it architecturally difficult to deviate from tokens.

Storybook changes the handoff conversation. Engineers who can see a working component reference make far fewer interpretation errors than those working from static files.

← PreviousScienceLogic Behavioral CorrelationView case study Next →KPWB Website RedesignView case study