01A system is leverage, not consistency

There was no budget for a design system when I joined the team, and no one dedicated to maintaining one. Whatever we built had to come from time carved out around existing product work.

At first, the problem looked like consistency. Each product had grown around whichever third-party UI library its team had chosen at the time, so the same company ended up with different visual languages, interaction patterns, motion, and accessibility gaps across products. The bigger pain was the repeated work behind it. A small team kept rebuilding the same foundation and waiting on the same decisions to be made again.

So the system had to do more than make products look aligned. It had to give designers and engineers a shared starting point, reduce the amount of back-and-forth needed to ship basic UI, and make the common parts of product work easier to reuse.

Consistency mattered, but only because it gave the team leverage. If the system could handle the repeatable parts, the visual language, interaction patterns, motion, and accessibility, then the team could spend more time on the parts that actually shaped the product: what problem it solved, how the workflow behaved, and where users needed to go next.

02Design for the organization you have

The constraints were not background details. They changed what the system could be.

Even under one VP, the products were built by separate teams, in separate repos, with different component stacks and different habits. Some of the duplication lived in code. Some of it lived in old Sketch files. Some of it lived in how each team had learned to solve the same product problem on its own. The product surfaces also had little connection to Fortinet's marketing brand, so the system had to bridge product UI and brand direction instead of treating them as separate worlds. A Figma library alone would not have fixed that.

Scale made the problem sharper. Across our VP's scope, roughly three products launch from scratch in a typical year, on top of the ten or more we already had to support. With only a small design team, the system could not depend on designers reviewing every screen or engineers asking us where every button, form, and page pattern should go. It had to help non-designers make reasonable decisions when we were not in the room.

The environment also ruled out the usual design-system playbook. Because this was cybersecurity, no external vendor tools were allowed near internal product work. No Storybook, no ZeroHeight, no analytics platform we could simply plug in. If we needed a source of truth, a component playground, or a way to check whether teams were using the system correctly, we had to build it ourselves.

So the system had to stay close to code, light enough to adopt, and useful without a dedicated team behind it.

03Fewer decisions, not more components

I started where most design systems start: auditing live products, stripping out legacy noise, and rebuilding from the smallest reusable parts up to a core set of components. Buttons, inputs, tables, modals, navigation, the obvious things. That work mattered, but it was not where most of the time was being lost.

The more I sat with engineers, the clearer it became that the slow part was rarely dropping in a component. It was everything around it: how to lay out a settings page, how to structure a form, how to compose a dashboard, what belongs in a wizard versus a table, and where actions should live. Those were design decisions, but they were being made over and over by people who did not really want to be designing.

That was when the system shifted from components to patterns. I started pulling common page types, flows, and recurring product patterns into near-finished guideline pages instead of treating the library as a pile of parts. The goal was to let someone start from a working pattern, swap in their own content, and still end up with something coherent.

I could tell it was working when engineers started answering their own questions with it. Someone building an onboarding stepper, unsure where cancel, back, and next actions should go, could pull up the onboarding pattern and follow it instead of guessing or asking me. That was when I knew the system was doing more than adding components. It was taking small design decisions off the team's plate.

04A system should outgrow its creators

With no dedicated team, maintenance could not be something we solved later. If every screen still needed design review, then we had not really built a sustainable system.

A three-level, multi-theme headless design system. Color, type, spacing, elevation, and motion all moved into a three-level token structure that could theme across Fortinet's product areas. That structure mattered most during the company-wide brand renewal. Because the system already keyed visual decisions off tokens, we could absorb the new brand, support four product themes, and add light and dark mode without redesigning each product surface by hand.

Reusable foundations. The base library grew into 50+ Figma and React components with usage guidelines and interaction patterns. Even before the later AI work, those components cut front-end implementation time by roughly 40% and made day-to-day product work simpler.

Boilerplates for B2B products. The component library solved the parts. It did not solve the pages. So we also built boilerplates for the product surfaces teams kept rebuilding: forms, dashboards, license pages, configuration flows, and other common B2B patterns. Instead of starting from a blank page, engineers could start from a real B2B page shape, with components and patterns already laid out for the use case. They could keep the layout and interaction pattern, then swap in product-specific content.

Design and code in the same place. Since external tools were off-limits, we built our own component playground to keep the Figma and React sides of the system aligned. The playground became the shared surface for the system: components, specs, boilerplates, patterns, changelog, contribution notes, and live theme switching. Teams could install the package and start from a themed, on-brand setup instead of wiring everything together piece by piece.

Accessibility as a system behavior. I did not want accessibility to depend on whether the person building a component happened to know the right contrast ratios, focus behavior, or screen-reader semantics. I tried to move the easy-to-miss parts into the system itself. Color pairings were constrained at the token layer, and components were backed by axe and Playwright checks for keyboard behavior, focus management, and semantics. If a component fails its own accessibility tests, it does not ship.

Maintenance that did not live in my head. I wrote AI agent skills for the repetitive parts of system work: checking token naming changes, reviewing component API variants, generating changesets, syncing with Figma design files, and guiding new designers and engineers toward correct system usage. The design team still reviewed anything that changed a public API, but the routine checks no longer depended on someone remembering every rule.

Contribution without gatekeeping. Over time, the system became less dependent on its original builders. I wrote a contribution skill that helps teams check their own work before asking for review: whether a new token follows the naming system, whether a component API or prop overlaps with existing components, what should be designed as a subcomponent versus controlled through props, and whether the proposed variant has a clear enough use case to belong in the system. It gave contributors a way to check their work against the same standards I would use, and contribute back without waiting for me or a dedicated design-system team to step in.

05Every abstraction has a price

I did not get the scope right at first. My instinct was to give every design element its own tokens, so the system could absorb almost any future theme change. It felt safer to make everything configurable.

That turned out to be the wrong kind of flexibility. At one point, the system had grown to almost 20,000 tokens across 50+ components. The naming convention was not straightforward enough for people to reason through, and even linting or automation could not reliably predict the token someone meant to use. Instead of making the system easier to maintain, the extra abstraction made it heavier, harder to search, and harder to trust.

It took a few rounds of cleanup to bring it back down. That cleanup changed how I think about abstraction. Abstraction only helps when it protects against a real kind of change. Past that point, it just becomes more system to maintain.

06Fit the company, not the ideal

Not every designer gets to work in a culture where design is already valued and the tooling is set to industry standard. The work was not about building the ideal design system I had in my head. It was about building one that fit the company I was actually in: its constraints, its habits, and the way people already made decisions.

You cannot change that overnight. So part of the craft was knowing when to push, and when to make the better path easier to follow. Instead of a heavy contribution process, I kept the system open: if someone hit a token that fell short or a pattern that was missing, they could propose a change. The standards stayed clear, but the gate stayed light.

With no dedicated team to maintain the system, it could only keep growing if other people felt like they had a hand in it. My job was not to control every answer. It was to keep the direction clear enough that other teams could make good contributions without asking for permission every time.

01Designing meant finding the first signals

With no real users to study yet, I had to create a starting point. I treated our own company as the first customer and spoke with the people closest to the problem: leadership, IT, finance, managers, and the engineers setting up models and API access.

I also looked outside the company so I would not overfit the product to our own assumptions. I studied open-source tools in the same space and worked backward from their interfaces: what use cases they seemed to prioritize, which personas they appeared to assume, and what signals they treated as important.

Comparing those two inputs gave me enough confidence to start designing, without pretending the personas were final.

02What the first version taught me

The first version followed what felt like a reasonable setup flow at the time: configure the keys, choose the models, set budgets, add guardrails, and move on. It gave us enough structure to design against and start building.

But by the time we were getting closer to launch, the shape of the AI product landscape had already shifted. The flow was still usable, but it felt too tied to one version of how AI governance would work. A guardrail might need to apply to a model, an MCP server, an agent, or a tool. So I stopped treating setup as one fixed sequence and started breaking it into parts the product could recombine. The user could still start with a guided path, but the structure underneath no longer depended on that path staying the same.

The same thing showed up in the dashboard. My first instinct was to give everyone one shared view with filters. That seemed simpler, but it treated each user as if they were starting from the same question. They were not. Leadership wanted to understand overall usage and risk. Finance needed to understand spend. Managers wanted to know whether their teams were using AI enough to justify the cost. Operators needed the detail behind the traffic.

So the product started closer to each user's job, instead of asking everyone to filter down from the same generic view.

The same data had to answer different questions. Operators needed raw detail: guardrail hits, tool calls, model traffic, and traces they could investigate. Leadership needed a cleaner read on whether AI usage looked healthy, where spend was going, and where risk was starting to concentrate.

That mattered most with metrics. Token volume looked useful at first, but it could be misleading on its own. A team using a stronger model with fewer prompts might use fewer tokens and get better results, while another team using a cheaper model might burn more tokens through repeated back-and-forth. A simple usage ranking could make the wrong team look more active, efficient, or valuable.

So I treated the dashboard less like one report with different filters, and more like a way to translate the same traffic into the right level of evidence for each role.

03The process had to move faster too

The first version also showed me that our process was too slow for how quickly the product was changing. By the time we had designed, reviewed, and started building one direction, the AI landscape had already moved enough to make parts of that direction feel dated.

I did not want design or front-end iteration to become the bottleneck while the product was still trying to find its shape. We needed a faster way to try flows, test behavior, and decide what was worth bringing back into the product.

So I started pushing for that workflow inside the team. I helped get access to Figma Make and worked with my manager and VP to secure Claude access for our team, at a time when other parts of the company still had limited access to these tools.

With that in place, I started building smaller working prototypes in code. I used code to test interaction, not as production code. It helped me check the parts that were hard to judge in Figma alone: setup sequence, changing states, empty states, role-based views, and whether a flow still made sense after the underlying objects changed.

Once the structure felt right, I brought the details back into Figma to refine the visual design, edge cases, and handoff. It was a way to keep testing the product without waiting for every screen to be fully polished first.

04Build on what holds still

The product is still being designed and developed as we prepare for GA. At this stage, I am less focused on which AI pattern becomes the default, and more focused on what still seems true underneath it.

Companies still need to know what their AI systems are doing. They still need to control what those systems can touch, understand where money and risk are going, and give different people different levels of detail.

When the technology keeps shifting, the interface should not pass all of that instability to the user. It should absorb enough of that instability so people can still make clear decisions.