Design System · 6 Verticals
Tijori Design System
Falcon's production design system, built from nothing: governance, tokens and documentation across six product verticals, with ~60% less component duplication.
Overview
Tijori is Falcon's production design system. I built it from scratch inside live delivery - every component earned its place by shipping in a real product first - and grew it into the shared language for six verticals: retail and corporate credit cards, Credit Line on UPI, savings, FD, prepaid and gifting.
The problem
Six product verticals, no shared design language, and component duplication growing faster than the org. Every new bank partner meant re-deciding things that had already been decided, and consistency depended on whoever happened to be in the file.
Approach
- 01
Governance with a documented path
A component is proposed from real product work, reviewed against existing patterns, then accepted with a spec covering states, tokens, content rules and accessibility notes. Nothing enters speculatively.
- 02
Resolve the brand-versus-system seam at token level
Partner brand expression lives in colour, type and card visual tokens; structure, spacing and interaction logic stay system-owned. Documented, not improvised.
- 03
Win adoption through delivery, not mandate
KVB, NSDL and CLOU components were designed as system components first and product screens second, so teams adopted patterns with shipping proof behind them.
- 04
Make it cheaper for engineering on day one
Named tokens matched to front-end variables, specs that answer edge-state questions before they become tickets, and design QA against production builds.
Highlights
Decisions and tradeoffs
- •Ship the system through products rather than as a separate initiative - slower to look complete, far faster to become real.
- •Tokens over variants for partner branding, so theming never forks structure.
- •Localisation and RTL rules baked into tokens and layout early, before a product needed them.
- •Tradeoff: a deliberately smaller component set, accepting occasional one-off product work in exchange for a system nobody had to fight.
What I got wrong
The first documentation described components in isolation, and teams still asked when to use what. Rewriting it around product scenarios - onboarding, servicing, ops surfaces - stopped the questions. I'd also write the governance model down at the start instead of at the point it began to hurt.
Measurable impact
Business outcomes
- •Six product verticals running on one system
- •Faster partner launches, including KVB's 12-week and NSDL's 52-day deliveries
Design outcomes
- •~60% reduction in duplicate components
- •Tokens supporting localisation and RTL
- •Consistency held while the org scaled from 12 to 92 people
- •Shorter design review and dev handoff cycles on every subsequent product
Outcome
Tijori is now the default starting point for every new Falcon product and partner. Component duplication fell ~60%, delivery timelines shortened, and the brand-versus-system boundary is a documented decision every new partnership inherits.
CASE STUDY: TIJORI DESIGN SYSTEM
Design System · 6 Verticals · Product + Engineering
One-line summary
Falcon's production design system, built from nothing and adopted across six product verticals as the org scaled to 92 people.
Problem
Falcon shipped six product verticals - retail and corporate credit cards, Credit Line on UPI, savings, FD, prepaid and gifting - with no shared design language. Every new bank partner meant a new file, new components and new decisions about things that had already been decided. Duplication grew faster than the team, and consistency depended on whoever happened to be in the file.
Governance
A component enters Tijori through a defined path: proposed from real product work, reviewed against existing patterns to see whether an extension is enough, then accepted with a spec covering states, tokens, content rules and accessibility notes. Nothing ships into the system speculatively. What is documented: anatomy, every interactive state, token mapping, responsive behaviour, do-and-don't guidance, and the product surfaces where the component is already live. The brand-versus-system seam was the hardest governance problem. KVB is a 108-year-old bank with a century-old identity; Tijori is a platform system. I resolved it at token level - brand expression lives in colour, typography and card visual tokens, while structure, spacing and interaction logic stay system-owned. That boundary is documented, not improvised, so every new partner inherits a decision instead of relitigating it.
Adoption
Adoption was won product by product, not mandated. I built the system inside live delivery - KVB, NSDL and CLOU components were designed as system components first and product screens second - so teams adopted patterns that already had shipping proof behind them. For engineering, the system had to reduce work on day one: named tokens matching the front-end variables, specs that answered edge-state questions before they became tickets, and design QA where I validated production builds against the spec rather than filing opinions. What had to change to win adoption: fewer, better-documented components instead of an exhaustive library; a lightweight request path so teams weren't blocked waiting on me; and versioned changes so nobody's in-flight screens broke silently.
Decisions and tradeoffs
Ship the system through products, not as a separate initiative - slower to look complete, far faster to become real. Tokens over variants for brand differences, so partner theming never forks structure. Localisation and RTL support baked into token and layout rules early, before any product needed it. Tradeoff: a deliberately smaller component set, which meant occasional one-off work in products in exchange for a system nobody had to fight.
What I got wrong
The first version of the documentation described components in isolation. Teams still asked when to use what. I rewrote it around product scenarios - onboarding, servicing, ops surfaces - and the questions stopped.
Measurable impact
Business outcomes Six product verticals running on one system Faster partner launches, including KVB's 12-week and NSDL's 52-day deliveries
Design outcomes
~60% reduction in duplicate components Tokens supporting localisation and RTL Consistency held while the org scaled from 12 to 92 people Shorter design review and dev handoff cycles on every subsequent product
What I'd do differently
I'd write the governance model down at the start instead of at the point it began to hurt. The rules existed in my head for months; writing them earlier would have let other designers and engineers contribute sooner.