ScienceLogic · Design System · Case Study

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.

Company
ScienceLogic
My role
Lead Designer
Scope
Token system · Components · Storybook
Timeline
2019–2020 · Shipped with Colosseum Release
Component library in Storybook
The component library as it appeared in Storybook — the engineering team's primary reference. Each component documented with all states, variants, and usage guidelines.
6 teams
Building from a shared component library for the first time
Development time per component — built once, used across the platform
Unified
Single 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.

Diagram
Token system diagram
Token system — spacing, color, and typography architecture with usage examples
The foundation of the system. 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.

Screenshot
Component library screenshot
Component library — atomic hierarchy from tokens to assembled patterns
Components built from tokens, assembled into patterns. Updating a token updates every component that uses it — no manual propagation.
Screenshot
Storybook screenshot
Storybook — live documentation with all states and variants
Storybook as the engineering handoff layer. Each component shows every state and variant in context — reducing interpretation errors.
Key decisions
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
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.