Designing a design system for trust

Analysts had to interpret dense data, move between related threat objects, compare coverage levels and decide what to address first. The product also had to keep growing inside two-week sprints on a constrained third-party framework. When I joined as the only designer, the interface reflected the speed the company had been building at.

• Similar controls behaved differently across modules.
• Navigation patterns did not scale as new areas were added.
• Status meaning depended heavily on red and green.
• Components lacked complete interaction and error states.
• Important workflows presented too many decisions at once.
• Design intent and implemented behavior were not always aligned.
• A new AI assistant raised fresh questions about evidence, confidence, latency, permissions and control.

I spent my first week auditing the product and running recorded walkthroughs with people across the company. Two of the four priorities that came out of it, accessibility and consistency, could not be solved screen by screen. This case study is what I built to solve them.

A pre-seed company cannot pause feature work for a redesign, so the system had to earn its place incrementally. Four operating principles, and every shipped workflow improved the foundation while every system decision made the next workflow faster.

Our MITRE ATT&CK coverage matrix used a five-level color scale. Customers began raising valid concerns, particularly those with deuteranopia or protanopia, that the levels were indistinguishable and did not meet ADA and WCAG contrast standards.

The palette I was handed

I audited the full palette in two passes. Every value went through a contrast ratio checker and was annotated with its AA or AAA result and the measured ratio, or left with the bare ratio where it failed. Then I re-rendered the interface under protanopia, deuteranopia and tritanopia filters to find which pairs were perceptually ambiguous rather than merely numerically compliant.

The incremental option was available and tempting: nudge the hues until every swatch passed. It would have closed the tickets without addressing the thing customers were actually describing.

What I changed

With the semantics settled I built reusable components on MUI primitives plus Interpres-specific behaviors: buttons and icon buttons, toggles and checkboxes, inputs, selects and list items, cards and status treatments, tooltips, dialogs and progressive disclosure, navigation and breadcrumbs, and iconography with usage guidance.

Each one was tied to product behavior rather than added for completeness. Breadcrumbs were not decoration, they solved a real investigation problem where an analyst could follow a chain of threat relationships and lose track of where they started.

A system that exists only in Figma is a document. I set the product up locally so I could pull builds, inspect how components were actually constructed, and compare implementation against intent. That gave me Storybook, where I could review components in isolation, inspect awkward states, and watch changes behave inside live screens.

Working with the front-end engineer, that turned handoff from a one-directional delivery into a loop. Design decisions were informed by the component architecture, and implementation decisions were checked against user intent and system consistency.

The report-generation redesign was the first workflow rebuilt on these components, and the composition it produced, a scrollable grouped selection with a persistent action area and indeterminate states, became the pattern every other selection-heavy dialog reused. That is the test a system has to pass: not whether one screen improved, but whether the next one was faster because of it.

Interpres was also building a conversational assistant so analysts could interrogate exposure data without synthesizing it across dashboards by hand. A conventional chat surface was not enough. In security, an answer has to be understandable, traceable and safe to act on, which means the assistant needs a consistent language for explaining how it got there.

One reasoning structure, reused everywhere

The AI layer reused the same visual hierarchy, status semantics, navigation logic and accessible component states as everything else, which is why the assistant reads as part of Interpres rather than a chatbot bolted onto it.

In prototype validation this cut average time to insight from about 45 minutes to 27, and analyst trust rose from 62% to 81% in post-task feedback.

This was a design system for an AI product. AI was not materially used to build the system itself in 2024. The section below is about what I would do differently now.

I did not have formal adoption analytics during the engagement, which is why the outcomes above are scoped to workflows. If the system had continued, I would have stood up a small health dashboard around five measures, none of which is the number of components.

11 · Retrospective

The original system was built for people making an AI product. It was not built through an AI-assisted process. Today I would take the next step and make the system legible to both people and tools, by encoding component intent, supported states, accessibility requirements and usage constraints as structured context rather than as visual examples alone.

The loop I would build

1. An agent retrieves approved components, props, examples and usage rules.
2. It composes the requested workflow from existing patterns rather than inventing new ones.
3. Storybook renders the result across default, loading, empty, error, permission and responsive states.
4. Automated interaction, accessibility and visual tests identify violations.
5. The agent corrects the failures and reruns the checks.
6. A designer and engineer review the result, including whether the pattern suits the user problem at all.