Case study · Fortinet
Designing the system, not the screens
Fortinet runs at roughly one designer for every fifty engineers. I founded its cloud design system so PMs and engineers could design for themselves, reaching 100% adoption under our VP and tripling delivery speed in the first year.
Overview
The only way to scale design here was to stop shipping screens and build the system that lets everyone else design. I owned the tokens, components, tooling, and governance that turned design from a bottleneck into shared infrastructure, working across three roles when there was no room for handoffs: designer, product manager, and at times design engineer.
The challenge
Scale without people. Far more products than designers, with five or more launching 0→1 at once. The system had to let non-designers ship coherent UI with almost no guidance.
A fractured org. Even under one VP, teams worked in silos. Separate repos, components duplicated in Sketch, no shared visual language, uneven accessibility, and no link to Fortinet's marketing brand. There was no single source of truth for tokens, components, or documentation.
A locked-down environment. In cybersecurity, no external vendor tools were allowed near internal content. No Storybook, no ZeroHeight, no analytics. Anything the system needed, we had to build ourselves.
Research & insights
I started by auditing live products, stripping legacy noise, and rebuilding from atomic elements up to a core set of must-have components. Then I sat with designers and engineers to find where time was actually lost in handoff and code reuse, and mapped the recurring UI blocks, templates, and patterns into shared standards.
The real gap wasn't missing components. It was missing the leverage to act effectively with limited resources. So I dived deep into different companies' design blogs and adopted the headless multi-theme design token method, which made us one of the first batch of companies in the field to do it. With my manager, a very experienced design engineer, we consolidated a token structure and naming convention that cut restyling to near zero and themed across every Fortinet brand.
What I built
System architecture. Tokens for color, type, spacing, elevation, and motion, with a naming convention that cut restyling to near zero and themed headlessly across every Fortinet brand. This let R&D move from writing raw CSS and JavaScript to composing products from shared tokens and components. Since no vendor tools were allowed near internal content, my manager and I built our own component playground to keep design and code always in sync.
Component library. 50+ components with accessibility and multi-theme support built in, documented with usage guidelines and interaction patterns.
One package to drop in. The tokens, component library, and live theme switching all ship as a single installable package, so a team can pull in the whole design system and start building in a themed, on-brand setup right away.
Agentic governance. I wrote two sets of AI agent skills. One helps designers and engineers use the system correctly, the other maintains it, checking token and component API variants and running automated changesets and release pipelines. Governance that scales without headcount.
Adoption as culture. Workshops and office-hours mentoring, treating adoption as something earned through shared ownership rather than mandated. Created presentations and video tutorials for leadership.
Impact
What it taught me
Fit the system to the company you're in. Not every designer gets to work in a culture where design is already valued and the tooling is set to industry standard. The most important thing I learned is that the job isn't to execute one beautiful system. It's to build a design system and a way of working that fit the company you are actually in, its culture, its constraints, and how its leadership already thinks. You can't change that mindset overnight, so part of the craft is knowing when to flow with it and earn leverage from the inside.
Shared ownership, guardrails instead of gates. With no dedicated team to maintain it, the system could only survive if the whole org felt ownership of it. So instead of a heavy contribution process, I lowered the barrier: anyone who hits a token that falls short or a missing pattern can propose a change. The automated checks I built, the agent skills that validate tokens and component variants, are what let me keep contribution open without losing consistency. I held the vision and the standards; everyone else helped shape what filled them.