Context — the copy-paste economy
The app had pieces of a design system: some buttons, icons, colors, type styles. What it didn't have was a system. Designers worked by archaeology — digging through old Figma files, copying UI from past projects, pasting it into new ones. Every exploration started with excavation. Consistency depended on memory, and speed depended on how recently someone had built something similar.
Rebuilding it properly was a two-person effort: myself and one other product designer. The structure and architecture of the system was largely my work; my partner polished and migrated the components that predated us both. It remains ours — we maintain and extend it together to this day.
Building the system
Foundations first
Colors as tokens in paired light and dark sets. Typography defined for two scripts — Devanagari and Gujarati — across Android and iOS, because a Hindi news app's type system that only thinks in Latin is broken at birth. Iconography in outline and solid sets, spot icons by category, an illustration library, brand assets. The boring layers, done thoroughly, because everything above them inherits their quality.
Then the working vocabulary
On top of the foundations: the components teams actually reach for — headers, navigation, tabs, feed cards, widget cards, inputs, keyboards, notifications, players, payment methods, subscription plans, empty states. Built with variants, variables and design tokens so customization is a property panel, not a detach-and-hack. The clearest example: roughly ten article-preview card variations across the app, all served by one component.
Curation as a design act
Not everything earned entry. Components were added only after discussion with the design team established they were genuinely recurring — and a written rule governs growth: a component joins the DLS only once its design has shipped and deployed; until then it lives as a local component. A system without a bouncer becomes a landfill.
The second system: article tools for editors
The app's article pages had great content presented plainly — walls of well-reported text that looked a generation behind international news apps. Editorial knew it and asked for better. Sitting with the editorial team, I designed a formatting vocabulary for the article page itself: multiple heading styles with highlight treatments, chapter markers, pull-quote formats, top-image variants for different image aspect treatments, related-article cards, timeline layouts for chronology-driven stories, audio players, Q&A structures.
These aren't decorations — they're storytelling formats. A crime chronology gets a timeline. An explainer gets Q&A structure. A longread gets chapters. The editorial desk uses them daily, choosing the format the story needs.
Decisions & tradeoffs
Recurrence over completeness
The tempting version of a design system contains everything anyone might ever need. That version dies — unmaintained, untrusted, bypassed. Ours admits only what recurs. Ten article cards proved they recur; they became one component. A one-off exploration stays local until shipping proves otherwise. The system stays small enough to trust and complete enough to live in.
Variants over copies
The 10-in-1 card is the philosophy in miniature: variance belongs inside components, exposed as properties, not scattered across the file as near-duplicates. Every near-duplicate is a future inconsistency with a delay timer on it.
Two scripts as a first-class constraint
Devanagari sets taller than Latin, with different rhythm and density; Gujarati differs again. Type scales, line heights and component paddings were defined against the scripts readers actually read — not designed in English and translated later.
Outcome
The honest measure of a design system is whether people can work without it. We can't — none of us. Explorations that began with archaeology now begin with components; work that took days takes hours. UI errors dropped, developer handoff got faster, and visual consistency across the app improved to the point where inconsistency is now what stands out. The system is alive: maintained, extended, governed — infrastructure, not a project.
On the editorial side, the article toolkit is in daily use across the desk — the formats appear wherever stories need them, which is the only adoption metric that matters for a tool built at editorial's own request.
What I'd do differently
Close the loop to code. The system lives in Figma as tokens, variables and variants — but the mapping to the engineering component library is still human, which is where drift creeps in. As someone who builds in React, I know what the end state should be: design tokens exported as the single source of truth both sides consume, so a color change is one commit, not one announcement. That pipeline is the next maturity level, and I'd start it earlier next time.