The problem
When I joined FYERS, design didn't have one language — it had several dialects. Style guides were scattered, half-finished, or duplicated: small pockets of standards that each team had grown on its own.
The same element could exist several different ways across web, iOS, and Android, and every new screen meant re-deciding things that should already have been settled.
That cost the business twice. Designers spent time rebuilding instead of designing, and users met a product that felt subtly inconsistent as they moved between verticals — the kind of friction that's hard to name but easy to feel in a financial product, where trust is the whole game.
There was appetite to fix it, but the early instinct was to patch: another partial guide, another local system. I became one of the louder voices arguing the opposite — that FYERS needed a single, real style guide, owned and versioned, rather than more scattered ones. That argument is where my involvement started.
Before / after: the same component as it existed across apps pre-FDSG, next to its single form on the system.
The vision
One source of truth. Not a component dump — an operating standard for how FYERS looks, behaves, and gets built, consistent across web, iOS, and Android.
FDSG was conceived to hold everything except coded components: the Figma libraries, the usage guidelines, the tokens, and the rules that make design decisions repeatable. The coded layer would come later, built by engineering — but the design system had to be authoritative first.
The library is just the artifact. The agreement is the system.
How I led it
I earned the system before I owned it. During v1.0, I contributed individually as a member of the Design Review Board (DRB) — the designers-only forum where components and patterns are proposed, critiqued, and ratified before anything ships. Work that clears the DRB then moves to the ARB for the front-end build, so the two boards form a clear pipeline: design decides, engineering implements.
A pattern or component is put forward against a real product need.
Designers-only forum. Critiqued, revised, and accepted into FDSG — or sent back.
Engineering implements the ratified pattern as a coded component.
After 1.0 shipped, I took over the initiative and drove FDSG 2.0 and 2.1 across both web and mobile. Two deliberate shifts defined those versions:
- 2.0 — a visual reset. We moved away from a gradient-heavy style toward a cleaner, more minimal look. Less decoration, more clarity — the right register for a trading and investing product where the interface should get out of the user's way.
- 2.1 — density and rhythm. We tightened spacing and made layouts more compact, refining components so the same screen could carry more without feeling crowded. This was the "make it feel considered" pass.
2.0, side by side: the gradient-heavy language on the left, the clean minimal reset on the right.
2.1: the same screen before and after the spacing and density pass.
The engineering bridge
A design system that engineering can't build is just a nice PDF. So the real test came after 2.1, when the ARB team built FDSG into a coded component library they named Fy_UI.
I'll be honest about the hard part, because it's the interesting part: we did not hit a 100% match between the design system and Fy_UI. Translating design intent into production components surfaced real gaps — the places where a token, a spacing rule, or a state didn't map cleanly to what the front-end could do. Naming those gaps, rather than pretending they didn't exist, is what made the next round of refinement honest and useful.
This is also where I stopped being only the person who defines the system and became the person who ships it. Using Claude as an AI pair, I delivered Wealth Tracker end to end in the front-end myself — design through to working interface. Doing that closed the loop on everything FDSG was arguing for: I felt exactly where design intent meets implementation reality, and I could bring that back into the system instead of guessing at it from the Figma side.
The order ticket in the Lab is the same argument in miniature — a component designed and built in one pass, in the browser, by one person.
Wealth Tracker — the screen designed and shipped in front-end, and the Fy_UI coded library beside it.
The ownership model
The deeper change FDSG enabled wasn't visual — it was organizational.
When I arrived, FYERS ran design like a relay in a waterfall: UX and UI were separate roles. A requirement would come in, a UX designer would pick it up, hand it to a UI designer for finesse, and only then would it go to front-end for dev handoff. Every handoff was a chance to lose intent.
Because I work end to end — and, luckily, a couple of my teammates do too — I pushed to collapse that split and champion "Product Designer" as the role, one person carrying a problem from UX through UI to shipped screen. My own path mirrored the shift: I joined as a UX Manager and transitioned to Product Design Manager as the model took hold. End-to-end designers also meant FDSG 2.1 was adopted quickly, because the people using the system were the same people who understood it top to bottom.
I've written the fuller argument for that change in One designer, whole problem.
The outcome
A simple consistency or velocity chart — the effort reduction, shown rather than asserted.
The components were the easy part. What made FDSG hold was the governance behind it and the people it changed — which is the part I'd argue about in any room.