Work 03
Rebuilding the Design System to work with the existing codebase
Role
Designer & Developer
Role
Designer & Developer
Read time
10 mins read
Read time
10 mins read
Timeline
Feb-March 2025
Timeline
Feb-March 2025
App
Netrin enhance
App
Netrin enhance
Role
Designer & Developer
Read time
10 mins
Timeline
Feb-March 2025
App
Netrin enhance
Want to see this story for yourself?
Highlights
The Problem
The design system lacked foundation tokens and core components, and they were falling out of sync.
Painpoints
Design reviews took longer and confusion increased between designers & developers during handoffs.
Constraints
All updates had to be made in a live app already in use, while I was the sole designer and developer on this.
The Solution
We rebuilt the foundation and core components while establishing a system for consistent syncing.
Design Process
Involved a detailed audit of the existing system to create new tokens that still felt native to the app.
Development
Focused on crafting previews, reducing duplication, and safely migrating 500+ files while keeping the system stable.
Reflection
Captured learnings from handling and maintaining a dense system, and identified methods to improve future iterations.
The Problem
The design system lacked foundation tokens and core components, and they were falling out of sync.
Painpoints
Design reviews took longer and confusion increased between designers & developers during handoffs.
Constraints
All updates had to be made in a live app already in use, while I was the sole designer and developer on this.
The Solution
We rebuilt the foundation and core components while establishing a system for consistent syncing.
Design Process
Involved a detailed audit of the existing system to create new tokens that still felt native to the app.
Development
Focused on crafting previews, reducing duplication, and safely migrating 500+ files while keeping the system stable.
Reflection
Captured learnings from handling and maintaining a dense system, and identified methods to improve future iterations.
The Problem
The design system lacked foundation tokens and core components, and they were falling out of sync.
Painpoints
Design reviews took longer and confusion increased between designers & developers during handoffs.
Constraints
All updates had to be made in a live app already in use, while I was the sole designer and developer on this.
The Solution
We rebuilt the foundation and core components while establishing a system for consistent syncing.
Design Process
Involved a detailed audit of the existing system to create new tokens that still felt native to the app.
Development
Focused on crafting previews, reducing duplication, and safely migrating 500+ files while keeping the system stable.
Reflection
Captured learnings from handling and maintaining a dense system, and identified methods to improve future iterations.
The Story
“We rebuilt the bricks and walls of a house while people were still living in it.”
The Problem
“The house was built with random bricks and walls”
Context
PainPoints
Constraints
No Tokens
There were no semantic colors, no proper typography structure, buttons and app bars were inconsistent or missing.
No Tokens
The gap between design and code was wide, with Figma showing one reality and Flutter showing another.
Weak Foundation
Our design system lacked the foundations needed for consistency and scalability.
Context
PainPoints
Constraints
No Tokens
There were no semantic colors, no proper typography structure, buttons and app bars were inconsistent or missing.
No Tokens
The gap between design and code was wide, with Figma showing one reality and Flutter showing another.
Weak Foundation
Our design system lacked the foundations needed for consistency and scalability.
Context
PainPoints
Constraints
No Tokens
There were no semantic colors, no proper typography structure, buttons and app bars were inconsistent or missing.
No Tokens
The gap between design and code was wide, with Figma showing one reality and Flutter showing another.
Weak Foundation
Our design system lacked the foundations needed for consistency and scalability.
The Solution
“We created consistent bricks, then built new walls with them and replaced the old walls too”
Foundation Tokens
Created new foundation tokens - Colors, Typography & Spacing.
Foundation Tokens
Created new foundation tokens - Colors, Typography & Spacing.
Foundation Tokens
Created new foundation tokens - Colors, Typography & Spacing.
Core Components
Created new core components - Buttons, Appbars, etc
Core Components
Created new core components - Buttons, Appbars, etc
Core Components
Created new core components - Buttons, Appbars, etc
Sync
Maintained sync across Figma and Code at every step.
Sync
Maintained sync across Figma and Code at every step.
Sync
Maintained sync across Figma and Code at every step.
Design Process
“New bricks and walls, but the home had to stay recognizable.”
Consistency
We had to be very conscious while designing, since without proper guardrails the new tokens would not align with the existing app, which was built on the older, broken design system.
Consistency
We had to be very conscious while designing, since without proper guardrails the new tokens would not align with the existing app, which was built on the older, broken design system.
Consistency
We had to be very conscious while designing, since without proper guardrails the new tokens would not align with the existing app, which was built on the older, broken design system.
Colors
1
Audited all colours in Figma and Flutter; separated documented palettes from random additions .
Reasoning
Expose inconsistencies early.
2
Step: Identified unnamed, overlapping shades and removed duplicates .
Reasoning
Reduce colour confusion.
3
Arranged colours light‑to‑dark and chose one canonical shade per spectrum.
Reasoning
Maintain visual harmony.
4
Created styles in Figma as variables called v1Primitives
Reasoning
Ease of access
5
Created named semantic colours (success, error, warning, surface, etc.) .
Reasoning
Standardise colour usage.
1
Audited all colours in Figma and Flutter; separated documented palettes from random additions .
Reasoning
Expose inconsistencies early.
2
Step: Identified unnamed, overlapping shades and removed duplicates .
Reasoning
Reduce colour confusion.
3
Arranged colours light‑to‑dark and chose one canonical shade per spectrum.
Reasoning
Maintain visual harmony.
4
Created styles in Figma as variables called v1Primitives
Reasoning
Ease of access
5
Created named semantic colours (success, error, warning, surface, etc.) .
Reasoning
Standardise colour usage.
1
Audited all colours in Figma and Flutter; separated documented palettes from random additions .
Reasoning
Expose inconsistencies early.
2
Step: Identified unnamed, overlapping shades and removed duplicates .
Reasoning
Reduce colour confusion.
3
Arranged colours light‑to‑dark and chose one canonical shade per spectrum.
Reasoning
Maintain visual harmony.
4
Created styles in Figma as variables called v1Primitives
Reasoning
Ease of access
5
Created named semantic colours (success, error, warning, surface, etc.) .
Reasoning
Standardise colour usage.
Typography
1
Audited all type styles to map inconsistencies and duplicates .
Reasoning
Find type system gaps.
2
Refined Inter’s kerning to -3% at higher font sizes and -2% for smaller fonts.
Reasoning
Premium and compact
3
Replaced vague “body/subtitle/headline” with body, label, title, heading and display .
Reasoning
Clarify type hierarchy.
4
A much asked label variant specifically for CTAs was created
Reasoning
Makes tap regions consistent
5
Swapped numeric style names for intuitive t‑shirt sizing (XS–XL) .
Reasoning
Make sizes intuitive.
6
Built a Figma preview showing all styles, tokens and examples .
Reasoning
Single source of truth
7
Synced the final style set into Figma and code with consistent naming .
Reasoning
Ensure platform parity.
1
Audited all type styles to map inconsistencies and duplicates .
Reasoning
Find type system gaps.
2
Refined Inter’s kerning to -3% at higher font sizes and -2% for smaller fonts.
Reasoning
Premium and compact
3
Replaced vague “body/subtitle/headline” with body, label, title, heading and display .
Reasoning
Clarify type hierarchy.
4
A much asked label variant specifically for CTAs was created
Reasoning
Makes tap regions consistent
5
Swapped numeric style names for intuitive t‑shirt sizing (XS–XL) .
Reasoning
Make sizes intuitive.
6
Built a Figma preview showing all styles, tokens and examples .
Reasoning
Single source of truth
7
Synced the final style set into Figma and code with consistent naming .
Reasoning
Ensure platform parity.
1
Audited all type styles to map inconsistencies and duplicates .
Reasoning
Find type system gaps.
2
Refined Inter’s kerning to -3% at higher font sizes and -2% for smaller fonts.
Reasoning
Premium and compact
3
Replaced vague “body/subtitle/headline” with body, label, title, heading and display .
Reasoning
Clarify type hierarchy.
4
A much asked label variant specifically for CTAs was created
Reasoning
Makes tap regions consistent
5
Swapped numeric style names for intuitive t‑shirt sizing (XS–XL) .
Reasoning
Make sizes intuitive.
6
Built a Figma preview showing all styles, tokens and examples .
Reasoning
Single source of truth
7
Synced the final style set into Figma and code with consistent naming .
Reasoning
Ensure platform parity.
Spacing & Dividers
1
Audited all spacing and divider usage across the product .
Reasoning
Highlight inconsistency.
2
Formalised spacing tokens (e.g. 16, 24, 32 px) and documented when to use each .
Reasoning
Create spacing defaults.
3
Standardised divider thicknesses to 1, 2 and 4 px with subtle colour variants .
Reasoning
Preserve hierarchy calmness.
1
Audited all spacing and divider usage across the product .
Reasoning
Highlight inconsistency.
2
Formalised spacing tokens (e.g. 16, 24, 32 px) and documented when to use each .
Reasoning
Create spacing defaults.
3
Standardised divider thicknesses to 1, 2 and 4 px with subtle colour variants .
Reasoning
Preserve hierarchy calmness.
1
Audited all spacing and divider usage across the product .
Reasoning
Highlight inconsistency.
2
Formalised spacing tokens (e.g. 16, 24, 32 px) and documented when to use each .
Reasoning
Create spacing defaults.
3
Standardised divider thicknesses to 1, 2 and 4 px with subtle colour variants .
Reasoning
Preserve hierarchy calmness.
Icons
1
Audited icon usage and noted multiple inconsistent libraries .
Reasoning
Justify unified system.
2
Designed icons with simple, slightly rounded forms and minimal detail .
Reasoning
Ensure clarity and friendliness.
3
Set a default icon size (24 × 24 px, 2 px margin) and allowed only proportional scaling .
Reasoning
Avoid distortion.
4
Enforced consistent optical weight of 2px for all icons unless they cross 48px
Reasoning
Visual consistency
5
We introduced a strict naming convention : lowercase, hyphen‑separated, “icon‑” prefix
Reasoning
Asset management
1
Audited icon usage and noted multiple inconsistent libraries .
Reasoning
Justify unified system.
2
Designed icons with simple, slightly rounded forms and minimal detail .
Reasoning
Ensure clarity and friendliness.
3
Set a default icon size (24 × 24 px, 2 px margin) and allowed only proportional scaling .
Reasoning
Avoid distortion.
4
Enforced consistent optical weight of 2px for all icons unless they cross 48px
Reasoning
Visual consistency
5
We introduced a strict naming convention : lowercase, hyphen‑separated, “icon‑” prefix
Reasoning
Asset management
1
Audited icon usage and noted multiple inconsistent libraries .
Reasoning
Justify unified system.
2
Designed icons with simple, slightly rounded forms and minimal detail .
Reasoning
Ensure clarity and friendliness.
3
Set a default icon size (24 × 24 px, 2 px margin) and allowed only proportional scaling .
Reasoning
Avoid distortion.
4
Enforced consistent optical weight of 2px for all icons unless they cross 48px
Reasoning
Visual consistency
5
We introduced a strict naming convention : lowercase, hyphen‑separated, “icon‑” prefix
Reasoning
Asset management
Buttons
1
The original button sets limitations (one style, two sizes, three variants) .
Reasoning
Figure out limitations
2
Audited all buttons and gathered missing use cases from designers and developers .
Reasoning
Capture ground truth.
3
So based off the audit and surveys the final list of Button types were created
Reasoning
Support all possibilities
4
Added a standalone icon button which was in the app but never standardised
Reasoning
Standardisation
5
Added built‑in disabled and loading states to every variant .
Reasoning
Mandatory requirement
6
Introduced a coloured button variant with no shadows and consistent elevation rules .
Reasoning
Consistent brand identity
1
The original button sets limitations (one style, two sizes, three variants) .
Reasoning
Figure out limitations
2
Audited all buttons and gathered missing use cases from designers and developers .
Reasoning
Capture ground truth.
3
So based off the audit and surveys the final list of Button types were created
Reasoning
Support all possibilities
4
Added a standalone icon button which was in the app but never standardised
Reasoning
Standardisation
5
Added built‑in disabled and loading states to every variant .
Reasoning
Mandatory requirement
6
Introduced a coloured button variant with no shadows and consistent elevation rules .
Reasoning
Consistent brand identity
1
The original button sets limitations (one style, two sizes, three variants) .
Reasoning
Figure out limitations
2
Audited all buttons and gathered missing use cases from designers and developers .
Reasoning
Capture ground truth.
3
So based off the audit and surveys the final list of Button types were created
Reasoning
Support all possibilities
4
Added a standalone icon button which was in the app but never standardised
Reasoning
Standardisation
5
Added built‑in disabled and loading states to every variant .
Reasoning
Mandatory requirement
6
Introduced a coloured button variant with no shadows and consistent elevation rules .
Reasoning
Consistent brand identity
Appbar
1
Documented all existing app bar variations to assess which patterns were still needed .
Reasoning
Understand current state.
2
Researched app bars in Uber Base, Material 3, Apple HIG, Swiggy and Spotify .
Reasoning
Learn from Industry
3
Adopted the sliver app bar pattern to support scroll and collapsing behaviour .
Reasoning
Follow common pattern.
4
Defined text and icon rules, including collapsing extra icons into an overflow menu .
Reasoning
Save space & improve access.
5
Created solid, translucent and clear app bar variants with usage guidelines .
Reasoning
Cover all use cases.
1
Documented all existing app bar variations to assess which patterns were still needed .
Reasoning
Understand current state.
2
Researched app bars in Uber Base, Material 3, Apple HIG, Swiggy and Spotify .
Reasoning
Learn from Industry
3
Adopted the sliver app bar pattern to support scroll and collapsing behaviour .
Reasoning
Follow common pattern.
4
Defined text and icon rules, including collapsing extra icons into an overflow menu .
Reasoning
Save space & improve access.
5
Created solid, translucent and clear app bar variants with usage guidelines .
Reasoning
Cover all use cases.
1
Documented all existing app bar variations to assess which patterns were still needed .
Reasoning
Understand current state.
2
Researched app bars in Uber Base, Material 3, Apple HIG, Swiggy and Spotify .
Reasoning
Learn from Industry
3
Adopted the sliver app bar pattern to support scroll and collapsing behaviour .
Reasoning
Follow common pattern.
4
Defined text and icon rules, including collapsing extra icons into an overflow menu .
Reasoning
Save space & improve access.
5
Created solid, translucent and clear app bar variants with usage guidelines .
Reasoning
Cover all use cases.
All the designs you just saw?
I developed them in code as well.
Development
“We had to replace the bricks and the walls of the house with new ones while people still lived in it”
Reducing Duplication
Old typography styles were scattered and inconsistent, so I replaced them with new tokens. This had to be done precisely: if a new style didn’t match an old one, it could cause style breaks or misaligned layouts.
Reducing Duplication
Old typography styles were scattered and inconsistent, so I replaced them with new tokens. This had to be done precisely: if a new style didn’t match an old one, it could cause style breaks or misaligned layouts.
Reducing Duplication
Old typography styles were scattered and inconsistent, so I replaced them with new tokens. This had to be done precisely: if a new style didn’t match an old one, it could cause style breaks or misaligned layouts.
Component Migration
With tokens stabilized, migration began. Nearly 500 files were updated as each legacy element—typography, buttons, app bars—was replaced with the new components. Every change was carefully verified to avoid visual glitches or inconsistencies.
Component Migration
With tokens stabilized, migration began. Nearly 500 files were updated as each legacy element—typography, buttons, app bars—was replaced with the new components. Every change was carefully verified to avoid visual glitches or inconsistencies.
Component Migration
With tokens stabilized, migration began. Nearly 500 files were updated as each legacy element—typography, buttons, app bars—was replaced with the new components. Every change was carefully verified to avoid visual glitches or inconsistencies.
Testing and Stabiltity
With tokens stabilized, migration began. Nearly 500 files were updated as each legacy element—typography, buttons, app bars—was replaced with the new components. Every change was carefully verified to avoid visual glitches or inconsistencies.
Testing and Stabiltity
With tokens stabilized, migration began. Nearly 500 files were updated as each legacy element—typography, buttons, app bars—was replaced with the new components. Every change was carefully verified to avoid visual glitches or inconsistencies.
Testing and Stabiltity
With tokens stabilized, migration began. Nearly 500 files were updated as each legacy element—typography, buttons, app bars—was replaced with the new components. Every change was carefully verified to avoid visual glitches or inconsistencies.
“Even the parts you can’t see should look good.”
“Even the parts you can’t see should look good.”
I followed that principle in code. For every token and component, I built dedicated previews.
I followed that principle in code. For every token and component, I built dedicated previews.
The entire design system in code is as polished as it is in Figma.
Each token has a dedicated preview with its specifications clearly defined.
Token previews also include their properties and usage examples.
Reflection
“We finished the house, but also learned 100 ways of how not to build one.”
Manual Migration
Migration was slow and manual. With Gen-AI tools like Cursor or Claude, it could have been cut down to 10% of the time.
Manual Migration
Migration was slow and manual. With Gen-AI tools like Cursor or Claude, it could have been cut down to 10% of the time.
Manual Migration
Migration was slow and manual. With Gen-AI tools like Cursor or Claude, it could have been cut down to 10% of the time.
Impact of Typography
Typography changes had the biggest impact—almost 80%. I should have prioritized it earlier.
Impact of Typography
Typography changes had the biggest impact—almost 80%. I should have prioritized it earlier.
Impact of Typography
Typography changes had the biggest impact—almost 80%. I should have prioritized it earlier.
Value of Previews
Previews should have been structured sooner. Setting them up late added avoidable effort.
Value of Previews
Previews should have been structured sooner. Setting them up late added avoidable effort.
Value of Previews
Previews should have been structured sooner. Setting them up late added avoidable effort.
