I build design systems, then ship product with them.
Ten years in product design. Three design systems since 2024, each one built for a product that was already in front of customers, never on a clean page.
The system, measured
Every colour is a semantic role, not a value. The build measures each role against each surface in both modes and refuses to emit a stylesheet below the minimum. The red you see moved one stop lighter because it failed at 3.58:1.
| Paper | Ratio | Blueprint | Ratio | Role |
|---|---|---|---|---|
| #121212 | 14.74:1 | #F7FFDC | 16.11:1 | color/text/primary |
| #3D3D3D | 8.54:1 | #DBD2CA | 11.18:1 | color/text/secondary |
| #525252 | 6.15:1 | #C6BDB5 | 9.01:1 | color/text/muted |
| #303030 | 10.38:1 | #E0FF98 | 15.03:1 | color/annotation/measure |
| #9E1820 | 6.34:1 | #EF9A9E | 7.77:1 | color/annotation/revision |
180 pairs checked · minimum 4.5:1 · build fails below
How I work
practice/start-at-the-bypass
I start where the system is being worked around. When someone detaches a component, writes an inline style or types a colour by hand, I read it as a bug report rather than a rule broken, because it tells me precisely where the library is harder to use than to avoid. I count those before I draw anything. A count turns an argument about taste into a list, and the list tells me what to fix first.
practice/adoption-is-the-metric
I judge a system by who reaches for it, not by how much of it there is. A library is adopted when an engineer picks the component because it is the fastest way to get the work done, not because a guideline told them to. So most of my time goes on removing reasons to bypass it: a missing state, a slow review, a token nobody can find. Proton went from 12 to 85 percent adoption that way, and very little of it was drawing.
practice/leave-it-runnable
I build systems to survive me leaving. The rules live where they run: contrast is checked in the build, the documentation says when not to use a component, every area has a named owner, and there is a proposal path so the next missing piece becomes a request instead of a workaround. Most of my work is on contract, so I plan for the day the contract ends and try to make sure the system does not notice.
About
The hard part is never drawing the component. It is getting every engineer to reach for the same one.
- Based
- Bangalore, IST
- Working
- Remote contracts
- Trained
- CEPT University
- Years
- 10 in product design
- Systems
- Michelangelo · Meridian · Proton
- Domains
- Analytics, pharma, food delivery
The design system is usually the thing I end up fixing, and rarely the thing anyone asks for first. The ask is a redesign, a launch, a dashboard nobody opens. Underneath it, almost every time, is a library the teams do not trust, so each of them has been building its own.
So I do both at once. Michelangelo re-skinned a live analytics product while it kept shipping. Proton went from twelve percent engineering adoption to eighty five while Panorama 360 was being built on it. Meridian was generated from a token source with a contrast check in the build, so the step numbers mean something you can verify.
Before that: subscription growth at Talabat, onboarding and inventory at Zenoti, a portfolio intelligence tool for pharmaceutical product managers at Dr. Reddy's. Dense professional software, mostly, where the user is at work and the screen is the job.
I work remote from Bangalore, on IST, and I am most useful to a team that already has a product in front of customers and a library that is not keeping up with it.
Reach me