Opportunity
Applied Agentic AI was the biggest bet the company had made, and that's the specific orbit where I sat. Their products are all internal tools. Dense, data heavy, used all day by people doing a job. They ship white labeled, so every new client meant rebuilding the look by hand.
The other half of the picture is the constraints, and they shaped my approach. They were early in their product design and design practices, and also going very wide across industries. There were real limits on staffing and on appetite to invest. So inside of those constraints - my opportunity was to stand up and run an engine, empower the existing design teams, and as importantly - lift people who weren't designers, all in a manner that didn't need a deep headcount to land its impact.
Context
There wasn't one design system to fix. There were a lot of them, cloned and forked, with almost no consistency between them. The designers weren't the problem. They were doing good work without much to work with. What they needed was something that freed up their judgment instead of eating their days, and something that plugged into the tools they were already working in.
Same for the POs and the directors above them, all of whom had a stake in getting an idea to something real. That's what I built toward, and five product teams moved over ahead of any mandate.
When people can take an idea from a conversation to something standing the same day, they move toward it on their own. The flip side is that without a usable design system - fragmentation also compounds just as fast.
Architecture/ stack
I put shadcn primitives at the core and built up from there. For a vacuum starting point that was the right call. It's adaptable, and these models consume it better than anything else available. You likely already have solid primitives, so that particular choice wouldn't repeat here.
The naming contract is what I'd point engineering at. I took the standard names instead of inventing a Genpact scheme, so nobody negotiated names at the start of a project. Everything lived in git rather than local directories.
It runs both directions. Someone who thinks in Figma starts there and pushes out to code, then fine tunes in Cursor or Claude Code. Someone who thinks in code goes the other way. Both stay grounded in the same source of truth, and it holds because the naming is identical on both sides.
Defining coverage
I spent time with the product teams first. Mostly dashboards, dense data, and a handful of workflows that were non negotiable.
That set the range. What I care about is whether the atoms are right, so teams can build what they need without stepping outside the system. How many variants a thing needs is judgment, and I brought an experienced POV there.
An early signal I'd sized it wide enough came from the brand team in London picking it up on their own to workshop with prospective clients. I hadn't built for them.
Tokens/ theming
Color alone only goes so far. If that's all a team can change and they need something more involved - they copy a component and edit it, and now it lives outside the system. And the wheels begin to fall off.
So all foundations - color, spacing, type, radius and motion all run through tokens, with no hardcoded values inside a component. Leave one and that spot won't move when everything else does.
Flexibility without forking.
Execution
Mechanics of the governance of the system itself: Evolution and work happens in one place, teams install from another, nothing moves between without clearing a check. Standard design system practice
Decisions authored as .md and skills as they are made, numbered and dated, because centralizing around the reasoning is a key to evolving all of this forward and not losing context into a singular thread.
Adoption still ran through me more than it should have. A system this size deserved a team to service it, and I didn't get there.
Flexibility
w/o forking
Color, spacing, type, radius, motion, all tokenized. No hardcoded values anywhere in a component. Product lines adjust density and rhythm in place.
Live tool demo
Impact
Designers got their judgment back instead of only reving on execution. The product owners were the surprise. People who know the domain cold but can't picture a screen. They could bring a process flow and get to something real to react to.
And sales walked into pitches already in the client's identity. For a business that wins on white labeled delivery, that was the clearest line I had between the platform and revenue.
Reflection
The philosophy underneath it is that all of this exists to help people materialize ideas.
Design to code may not ultimately ship straight to production, and that's fine. Even when the code version is only ever a faster, higher resolution, better communicated prototype, it lets you pressure test whether an idea actually holds up.
Seen from both a strategy seat and with my hands in the work, this is a powerful path to be leaning into.
