At FYERS, designers were recreating familiar interface patterns and engineers were building them again. I began looking at the cost in human attention. Our team evolved the design style guide into a governed component system, connected it with reusable production components and began using that product language in AI-assisted creation.
Two people were solving something we already knew.
A designer would mock up a pattern we’d already solved. An engineer would translate that variation into code. Across product pods, small repetitions accumulated into work that needed separate interpretation and maintenance.
The button was a symptom. Familiar decisions kept consuming attention that could have gone towards customer behaviour, difficult flows or technical problems that needed original thinking.
I kept asking: why are we designing the same button again?
Reuse became the default. Variation needed a reason.
We already had the FYERS Design Style Guide, FDSG. The team evolved it into a governed component system with design tokens, variables and reusable components.
Instead of asking how to draw another button, designers could ask whether the problem genuinely required a new one. Reviews gave us places to challenge unnecessary variation while allowing new product needs to change the system.
One idea I explored was spacing based on relationships: parent and child, siblings, neighbours. A heading and its description could have a parent-child relationship. Designers could reason about the relationship first, then choose the corresponding token.
The system captured decisions so another designer, product or team could use what the organisation had already learned.
We built the system while continuing to ship.
The business couldn’t pause releases while we perfected a design system. We were also preparing for a ground-up application revamp.
We had to build the road while driving on it.
Primitives and their relationships needed stable foundations, while values remained easy to change. We also considered variables for different contexts, including multilingual experiences.
There was a learning curve. Designers were willing to learn, but the product timeline wasn’t going to wait. Building the capability had to happen alongside delivery.
A design component wasn’t enough. Engineering needed reuse too.
A governed design component could still reach Engineering and be built again. We had reduced repetition on one side while leaving it on the other.
The team created corresponding reusable production UI components, bringing design and implementation closer together. The ambition became: solve once, reuse across design and production.
Corresponding systems and shared foundations, rather than an automatic design-to-code pipeline.
Reliable reuse could shorten the path towards a usable product. More importantly, it offered a way to redirect capable people’s attention towards questions we hadn’t answered.
AI made governance more important.
Generation can multiply variations of a solved component. Speed doesn’t remove inconsistency; it can multiply it too.
I came to see the governed product language as infrastructure for creation. AI-assisted workflows began working with FDSG and the UI library, helping designers move from intent towards working interfaces within that language.
The purpose wasn’t simply to produce more screens. It was to remove execution that didn’t need new human judgment, so people could focus on exceptions, customer needs and new opportunities.
At Geojit, I had asked a similar question to recover my own time. At FYERS, it applied across designers and engineers. With AI, the question becomes larger: where is human intelligence actually necessary?
If a problem has already been solved, capture the solution. If it can become reusable, make it reusable. Then point people towards something the organisation doesn’t know yet.
Read where this habit began