JupiterOne

A design system the developers could build from

What we did

Website,

Web App,

Mobile App,

Artificial Intelligence,

Branding,

Visit live site ↗

“Their work helped create the design system and build a more consistent foundation across the product. It established clearer, reusable patterns, improved collaboration between design and engineering, and helped the team move faster while maintaining a high bar for quality.”

Annalisa ValenteHead of Product Design @ JupiterOne

JupiterOne's product had grown faster than its design. We consolidated V1 and V2, rebuilt the information architecture, and built the design system from zero with their engineers, moving it from Figma to Storybook.

A platform that grew faster than its design

JupiterOne's platform had grown quickly, and its experience had not kept up. Two versions, V1 and V2, existed side by side. Features had been built with different interface patterns, and new capabilities kept arriving with patterns that were never integrated into the existing experience.

What we found:

V1 and V2 coexisted, with different navigation, layouts and interaction patterns.
Dense security data was hard to scan, and important information could get buried.
The same information and interactions looked different from module to module.
Color was used inconsistently in a product where people read color as meaning.
Without a shared design system, each new feature risked adding another pattern. The problem wasn't a dated look. The platform had no consistent way of presenting complex security information.

Audit, unify, systemize

We owned the design process end to end and worked with the Head of Product and the engineering teams. We treated the platform as one connected system, not a set of separate screens.

Audit. We reviewed V1 and V2 and mapped the repeated interface patterns.

Unify. We restructured the navigation into one information architecture.
Validate. We prototyped interaction patterns, gathered feedback, and checked feasibility with product and engineering.
Systemize. We built the design system from zero: tokens, components, variants and states. We used Claude to iterate and explore. The product decisions, system architecture and final design were ours.

One product, one interaction language

We merged the competing V1 and V2 experiences into one. We redesigned the sidebar, set consistent page structures, and defined reusable patterns for common interactions, so people who learn one part of the product can find their way through the rest.

What changed:

V1 and V2 became one experience.
The main sidebar navigation was redesigned.
Modules share layouts and interaction patterns.
Recurring components and data-heavy views follow the same rules.
Selected workflows needed approximately 2–3 fewer clicks.
Important information sits closer to where people need it.

Dense data that people can scan

In a security platform, showing the data is half the job. People also need to see what it means. We set a clear visual hierarchy and consistent patterns for tables, filters, status indicators and data presentation, so important findings stand out.

We moved relevant information closer to where it's needed and made movement between related items predictable. Asset management, vulnerabilities, findings and attack surface monitoring each keep their own requirements without feeling like separate products.

Color reserved for meaning

We made the interface mostly neutral and kept semantic color for moments when it communicates something. The brand green stays in the identity, but no longer colors every interactive or informational element.

Red: critical and error states.
Yellow: warnings and conditions that may need investigation.
Green: healthy states and successful outcomes.
Neutral: structure, surfaces, typography and supporting UI. Developers now have clear rules for color in new features.

A design system built to be built from

Without a shared system, new features would keep adding patterns. So we built one from zero and wrote down how it should be implemented.

Design tokens: color, typography, spacing and recurring decisions.
Reusable components: tables, filters, navigation, forms and status indicators.
Component variants: variations for different contexts, without separate implementations.
Documented states: behavior across interactions and scenarios.
Implementation rules: guidance that removes guesswork for developers. We built it in Figma first, then moved it to Storybook, working directly with their developers so the components match what the team builds with.