The design system behind Tata Neu's relaunch

A super app of many brands, running on a design library built for a much smaller app.

Tata Neu puts payments, shopping, travel, food and finance from across the Tata Group behind one login. Each is close to a business of its own, with its own idea of what a button should look like.

People noticed the seams. A first-impression review in April 2022 (opens in new tab) found that each brand had carried its own elements into the app, and the experience felt inconsistent for it.

Underneath sat an agency's library. Its colours were named for their shade, not their job, and one name had already stopped telling the truth: the swatch labelled Tertiary/Red CE0606 held F75F5F. The light theme was a second library file, kept in step by hand.

I had spent two years designing the app's core flows, so I knew where the library broke. In May 2022, five weeks after launch, I started an in-house token system to replace it.

Open the whole colour page

The agency library's colour page

Fit100%

×

One token layer under every brand and theme. Croma's green and Neu's purple are the same role with a different value.

Every component asks for a role named for its job, such as primary or surface, never for a colour. Brand, theme and screen size are modes on those roles, so one button serves Neu in dark and light, Croma and BigBasket, and the web app gets its larger steps without a second set of components.

Brands first ran on their own copies of the library, and copies drift. Once Figma variables could hold modes, I trialled them on the homepage in January 2024 and brought Croma back into the library as a mode in 2024; BigBasket followed in 2025. Cliq and ONDC stayed copies.

About 140 colour roles sit on more than 300 values. Three decisions shaped it:

• Tokens, not patches. Patching the agency library would have kept its untrustworthy names and its hand-kept light file, and every new brand would have added another file to keep in step. An off-the-shelf system, even Material 3, would have made the app bend to fit it. A token is defined once, so a change in one place reaches every screen.
• Two tiers, on purpose. Components ask for roles directly, with no third tier of component tokens. The brands differed in colour, not in shape: a brand changed what primary meant, never what a button was. The day a brand needs a different button is the day to add a component token.
• Material 3's roles, stretched. Engineers already knew the names, and paired roles made a second theme and contrast checks systematic. Neu needed more: a fourth accent, quaternary, and text in three strengths.

I kept the tokens in a Figma plugin and exported them as JSON for the developers, who mapped them into the Flutter apps. Design and code used the same names for the same values, which is most of what keeps them from drifting apart.

Every component documented three ways: what it is for, exactly how it is built, and when not to use it.

Each component has an overview, specs with every size and colour as a token name, and guidelines with right and wrong use side by side; 33 of 35 have all three. More than 30 widget types had rules exact enough for merchandising teams to follow without a designer in the room.

I wrote six design principles for it. The one this case study keeps coming back to:

OverviewSpecsGuidelines

Buttons specs pageOpen the whole specs page

Buttons: specs page

Fit100%

×

The screens a team forgets, the empty cart and the dropped connection, were defined once for every module, so none shipped a blank screen. New components went through review, and a changelog recorded every change with its reason.

A screen can be specified perfectly and still ship slightly wrong. So I checked the build against the design, page by page.

For releases 3.5 and 4.1 I compared design and build page by page on Android, iOS and the web app. On the homepage the gap between the payment icons and the NeuPass band was 16 pixels instead of 32, and the band had lost its 1-pixel gradient outline. Each fix went on a dated board and was checked again on the next build.

1234

1234

1. 1Extra space under the banner, not in the design
2. 2Payment icons smaller, each in its own box, and all five actions, not four
3. 3Gap from the payment icons to the NeuPass band 32 px, not 16
4. 4NeuPass band outlined in 1 px of gradient/neupass-band-border, with one clean rounded corner, not two layers

Because roles come in pairs, a background and the colour on it, every pair can be measured. All 33 pairs pass WCAG AA in Neu light, Neu dark and BigBasket; Croma passes 30 of 33, and those three are what I would fix first.

The app moved from dark to light in two planned steps, on the same tokens, and every module kept shipping.

Tata Neu launched dark. Dark suits a premium category, light suits reading, and most of Tata Neu is browsing prices, offers and products. The store pages were mapped to light from February 2023. Switching everything in one release would have meant redesigning every module at once while they were all still shipping.

• The decision. Keep every role and move in stages. Release 4.1, in late 2023, ran dark and light sections side by side on purpose, under rules anyone could check on a QC board: no more than two light widgets in a row, and the footer widget always dark. Because components asked for roles, a section switched theme by switching its mode, with nothing redrawn.
• What it cost. For a few months the app had two themes on one page, so the rules went on every QC board, not just in the docs.
• The result. The full light theme shipped in March 2024 on the same roles, and Business Standard reported it (opens in new tab) as a move from black to an all-white background.

2021March 2024

Show more of the 2021 homepage or of the March 2024 homepage

1. 2021 buildsThe agency libraryColours named for their shade; the light theme a second file, kept in step by hand.
2. IPL 2023Design System 1.0, darkEvery colour became a role named for its job, such as primary and surface.
3. Late 2023Release 4.1, hybrid on purposeDark at the top, light below, under rules anyone could check on a QC board.
4. March 2024Light, on the same rolesThe full light theme, on the same roles. X-ray at the top of the page shows them.

Every redesign after 1.0 was built on the system, and the rating rose in the same release.

• Shipped. Design System 1.0 went out in the IPL 2023 revamp.
• Adopted. Every module redesign after 1.0 was built on it, from the homepage to orders, and the March 2024 light theme ran on the same roles.
• Scaled. One library carried four brand modes, the web app's Desktop mode, food delivery on ONDC and the BigBasket integration.
• Taught. Hands-on sessions in August 2025 brought about 20 to 25 UI and UX designers onto the system.
• The rating. After the revamp, Moneycontrol reported (opens in new tab) Tata Neu's Google Play rating rising from 3.8 to 4.2. Performance work shipped in the same release, so I don't credit the system alone.

A system is only as good as how easily teams can ask it for more. I now set that up on day one.

After the 2024 relaunch, requests grew faster than the process could take, so I brought in a request form and one shared tracker. When asking for a component is harder than building your own, teams build their own. So on a new system I start with:

• Names. A naming grammar written down before the scale, so a name says what a value is for and never what it was.
• Tokens in code. One source exported to every platform in the design-token format from the W3C community group (opens in new tab), and a contrast check that runs on every change in every mode.
• Versions. A version number on every release, with a note to developers whenever a name changes or a component is retired.