Hi, I'm Purnima.
Before I designed AI agents, I spent two years on a design system — and learned that the hard part isn't building one. It's getting anyone to use it.
Four foundations authored for a design system serving an entire iPaaS suite — and the programme that persuaded product teams to actually adopt them.
Delite was good. The guidance was thorough, the components worked, the portal was well organised. And product teams carried on shipping screens that looked nothing like it.
Not out of stubbornness. A rebrand is weeks of work that ships no features, and every team already had a roadmap. The system asked for effort and offered, in return, consistency — which is a benefit the company gets, not the team doing the work.
So the job had two halves that most people only count as one. Author foundations solid enough that adopting them is genuinely better than not. And build something that makes a busy team want to start — a path they can see the end of, a review they can book, a badge worth having, a wall with their name on it.
A design system is a product. Its users are the people who have to change their work to use it.
One about where design systems actually fail. One about how to make a colour palette produce consistent illustrations in hands that aren't yours.
I drew the system as a pipeline to find where teams actually dropped out. Almost nobody fell off because the guidance was wrong. They fell off in the middle — after deciding it was worth doing, before finding the time to do it.
How it was used: this is the argument for why a design system team should spend real time on programme design rather than only on the system. Every element on the right exists because of the cliff on the left.
A colour palette handed to a dozen designers produces a dozen looks. The weighting model was the fix: not which colours are available, but how much of each you're allowed to use. It's the single decision that made product illustrations across the suite recognisably one family.
How it was used: the ratio is stated at the top of the illustration colour guideline, before any swatch. It's the first thing a designer reads and the reason the Do/Don't pairs further down make sense.
Each of these is a published guideline that product teams across the suite designed against. Two of them later became mandatory milestones in the rebranding programme — which is the clearest evidence I have that the foundations were load-bearing rather than decorative.
The palette every product illustration in the suite is drawn from, and the rules that keep them consistent: a core green carrying 60% of the visual weight, a purple accent at 30%, and an extended palette limited to 10% for props and detail. Backgrounds are defined separately as a backdrop. Hair and skin ranges are deliberately wide, so the people in enterprise software illustrations don't all look the same.
The layout foundation for every product in the suite. Grid anatomy down to margins, columns and gutters; the 12, 8 and 4 column structures and when each applies; how the grid behaves when navigation panels offset it; and the breakpoint set, with artboard sizes chosen from real device usage rather than convention.
A palette built for charts rather than interfaces, where colour carries meaning rather than hierarchy. Categorical palettes for unordered categories, applied in a fixed sequence so neighbouring series stay distinguishable. Monochromatic ramps for trends, darkest at the largest value. And two diverging palettes — red-cyan where the data has a natural hot-cold reading, purple-teal where it doesn't.
Every colour decision in a design system gets tested twice: once on white, and once when the background inverts. I worked on the dark theme that the token architecture carries — CTA colours resolving from a single token across light and dark, background layering that keeps depth readable without borders, content colours shared between text and icons, and category colours holding their meaning in both themes.
The half of the job that isn't the system. A structured path from "we should probably rebrand" to a badge, with the scope made estimable before anyone commits. I contributed to how the programme worked and designed everything about how it looked — the identity, the illustrations, the milestone and step diagrams, the badges and the wall of fame.
The foundations and the programme are usually treated as different disciplines — one craft, one operations. On this project they were the same job. A palette nobody applies and a programme with nothing worth applying both fail, and they fail in exactly the same way.
One takes a product team from unbranded to badged. The other takes an idea from someone outside the core team into the system itself. Between them they're the whole relationship between a design system and the people who use it.
Six stages across the top, five mandatory milestones underneath. The milestones are deliberately independent: a team can complete illustration colours this sprint and data visualisation next quarter without losing progress.
My contribution: I designed the visual language of this programme — the milestone diagram, the step illustrations, the badge and the identity. The structure was the team's; how a product team encountered and understood it was mine.
The only measure that matters for a design system is whether products changed. Here's what actually happened, and what I'd claim credit for.
The illustration and data visualisation palettes both became mandatory milestones in the company's rebranding programme — required steps to becoming brand compliant across the product portfolio.
Guidance that ends up on a compliance checklist has stopped being a suggestion.
Products completed the programme and were published as brand compliant — webMethods.io Documentation, webMethods.io B2B, Cumulocity IoT and Software AG Cloud — with more teams in progress behind them.
The wall of fame stopped being an empty page, which was the point of building it.
The contribution process ran with real throughput — components, patterns and foundations contributed by designers and engineers across product teams, each credited on the wall of fame. Standing cadences did the work: Drop-in Clinics and Vibe Checks meant the first step was showing up to something that already existed rather than scheduling a meeting with a team you'd never met.
I was recognised as Design-Focused and All-Round Designer at Software AG for breadth of contribution and consistent collaboration across product areas — which, for this role, was the job description rather than a bonus.
Two years later I was designing AI agents, and the thing I carried over wasn't a component or a colour. It was the habit of asking who has to change their behaviour for this to work, and what I'm offering them in return.
I learned to write rules for people who would never ask me a question.
Product work gives you feedback. Someone uses the thing, and you find out. Foundations don't work like that — a designer three products away opens a page, reads a paragraph, and either applies it correctly or doesn't, and you may never hear either way. That changed how I wrote. Less rationale, more do this, not that, with the failure mode shown rather than described. The illustration guideline states the sixty-thirty-ten ratio before it shows a single swatch, because the ratio is the part that has to survive being skimmed.
The mistake I made early was believing the system was the product. I spent months making guidance thorough and correct, and teams still didn't adopt it — not because it was wrong, but because adopting cost them weeks and paid them nothing they could point at. Consistency is a benefit the organisation receives and an individual team pays for. Once I understood that, the badge, the milestones and the wall of fame stopped looking like decoration and started looking like the actual design work. I'd now argue that a design system team that isn't spending real time on adoption is only doing half its job.
The last thing, and the one I use most: standing beats scheduled. The Drop-in Clinic worked because it was already in the calendar. A designer with a five-minute question doesn't book a meeting with the design system team — the cost of asking is higher than the cost of guessing, so they guess, and the guess ships. Making the first step something that already exists removed the largest barrier in the whole process, and it cost us an hour a week. I've reached for that pattern on every team since.