Rebuilding the foundation of a security platform

The problem wasn't just the UI

The product worked, but there was no shared foundation underneath it. Customers noticed the inconsistencies. One told us that part of the app was dark and part was light.

For engineers, the problem was even more obvious. Every new feature meant choosing between two sets of components, and some legacy pages had almost no traffic but still needed to be maintained.

Start with the foundation

A typical redesign replaces screens one at a time. I took a different approach and rebuilt the components, patterns and interaction rules that every screen would use.

The goal wasn't simply to make the UI look consistent. It was to make the product easier and cheaper to change.

That meant a migration, not just a redesign.

How we migrated without a big-bang release

Rebuilding everything at once would have put our most-used pages at risk. I used Pendo data to rank pages by traffic and split the migration into three phases.

1. Phase 1: High traffic, with work already underway

   CCM, UVM, Home, Settings and Integrations. Home was the most visited page, and sessions there were several times longer than anywhere else in the product. I migrated it without changing its layout first, then held the redesign for later to avoid hurting engagement.

2. Phase 2: Medium traffic

   Compliance status, evidence uploads and the Question Result page. These areas needed more care, particularly the Question Result page, where users often spent long sessions.

3. Phase 3: Long-tail pages and cleanup

   We moved the remaining low-traffic pages onto the new system, then decommissioned the legacy codebase.

One of the biggest savings came from work we decided not to do. Three legacy areas had almost no usage, so I proposed retiring them rather than spending time migrating them. The proposal was approved.

Each phase had to meet the same exit criteria before we moved on:

• Zero P1 bugs
• Fewer than three P2 bugs
• No significant drop in session time compared with baseline
• A stakeholder demo
• A ticket to decommission the old page within 30 days

That last requirement was important. Without it, old and new implementations could easily have stayed around indefinitely.

The migration also gave us an opportunity to rethink two navigation decisions. Settings and Integrations moved under a single Configuration menu, while Ask J1 moved into the header so it could be accessed from anywhere in the product.

A design system the whole team could use

The brief wasn't to create a library that only designers understood. I wanted something the entire product team could build with.

I treated the design system as a shared contract between design and engineering. One token file defined colour, typography, radius and spacing across light and dark themes. All 58 components used those tokens, which meant changing themes was a single class change. The part-dark, part-light experience the customer had described was no longer something we'd need to fix page by page.

A few rules made the biggest difference:

• Use tokens, not raw hex values. This keeps colours consistent across themes.
• Use existing components. Don't rebuild buttons, selects or tables out of divs when a component already exists.
• Keep component styling and layout separate. Props control a component's appearance; classes handle layout.
• Use a shared spacing unit. Page sections should have a consistent rhythm.

The system also captured product decisions, not just visual styles.

In a security product, colour carries meaning. I defined four verdict tiers (act now, elevated, monitor and low) with specific visual treatments for each. I also made sure that the absence of a finding didn't compete for attention. For example, “not in KEV” appears muted, while the accent colour is reserved for actual risk.

We made the system available as a package, with a compiled bundle for environments that couldn't access a registry. Storybook became part of sign-off, and I opened pull requests alongside engineers rather than handing over designs and waiting for implementation.

That meant product managers and engineers could prototype with the real components instead of trying to recreate them from mockups.

When the foundation solved a real product problem

A customer reported that CCM coverage was being represented inconsistently. Rather than patching the visuals on that one screen, I used the new foundation to address the underlying interaction and implemented the fix myself.

In PR #1795, I changed coverage and pass rate from two unrelated bars into a single status bar showing what was passing, failing or not measured.

It was a small change, but it made the information easier to interpret and gave us a consistent way to represent the same status elsewhere.

This was a good example of how the work came together: customer feedback informed the product decision, the design system made the change straightforward, and I could take it through implementation and release.

Designing a system that AI can build with

I also packaged the same design system contract as a Claude skill. The idea was to help a model build with JupiterOne's actual components, tokens and rules instead of generating an interface that looked and behaved like a different product.

That gave design, engineering and AI-assisted prototyping a shared language.

The skill targets Figma output. Claude imports components from the existing kit rather than rebuilding them, and interactive states map to named Eclipse tokens.

Your new security AI assistant

The same foundation also made it possible to build the AI assistant directly into the product.

Because the assistant panel used the existing components, it felt like part of JupiterOne rather than a separate experience bolted onto it.

AI for cybersecurity: designing around the graph →

What we measured

Before the major changes, we established a baseline using customer surveys and product analytics.

These are before-and-after measures, not the results of a controlled experiment. They show the outcomes we observed around the redesign, rather than proving that the redesign alone caused the changes.

What changed

The biggest change wasn't just how JupiterOne looked. It was how the team could build it.

We went from patching inconsistencies across two codebases to having a shared foundation we could extend. Designers and engineers could work from the same components and rules, and AI-assisted development had that same foundation to build on.

That gave us a more maintainable product and a better way to keep improving it without adding to the fragmentation that had caused the problem in the first place.