Work 01
Sonic
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 read
Timeline
Feb-March 2025
App
Netrin enhance
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 Problem
“The house was built with random bricks and walls”
“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
The Solution
“We created consistent bricks, then built new walls with them and replaced the old walls too”
“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
Design Process
“New bricks and walls, but the home had to stay recognizable.”
“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
Colors
1
We audited all colors across Figma and Flutter, separating accounted palettes (brand, fills) from unaccounted additions lacking names, documentation, or consistency.
Reasoning
Reveal inconsistencies and duplicates before rebuilding a palette foundation.
2
We found many unaccounted shades, including overlaps with existing tones, but without proper naming or traceability, causing duplication and confusion in usage.
Reasoning
Eliminate overlap to reduce confusion and prevent uncontrolled color creep.
3
We organized colors into light-to-dark spectrums, then reduced each spectrum to a single canonical shade to enforce clarity and predictable application.
Reasoning
Ensure new shades blend with existing app colors for visual consistency.
4
On top, we defined semantic colors—success, error, warning, surfaces, and more—each named, documented, and ready for consistent use across the entire app.
Reasoning
Align with universal standards so teams instantly know which color to use.
5
On top of that, we built semantic colors (success, error, warning, surface, etc.), each named and ready for use across the app.
Reasoning
Align with universal standards so teams instantly know which color to use.
1
We audited all colors across Figma and Flutter, separating accounted palettes (brand, fills) from unaccounted additions lacking names, documentation, or consistency.
Reasoning
Reveal inconsistencies and duplicates before rebuilding a palette foundation.
2
We found many unaccounted shades, including overlaps with existing tones, but without proper naming or traceability, causing duplication and confusion in usage.
Reasoning
Eliminate overlap to reduce confusion and prevent uncontrolled color creep.
3
We organized colors into light-to-dark spectrums, then reduced each spectrum to a single canonical shade to enforce clarity and predictable application.
Reasoning
Ensure new shades blend with existing app colors for visual consistency.
4
On top, we defined semantic colors—success, error, warning, surfaces, and more—each named, documented, and ready for consistent use across the entire app.
Reasoning
Align with universal standards so teams instantly know which color to use.
5
On top of that, we built semantic colors (success, error, warning, surface, etc.), each named and ready for use across the app.
Reasoning
Align with universal standards so teams instantly know which color to use.
1
We audited all colors across Figma and Flutter, separating accounted palettes (brand, fills) from unaccounted additions lacking names, documentation, or consistency.
Reasoning
Reveal inconsistencies and duplicates before rebuilding a palette foundation.
2
We found many unaccounted shades, including overlaps with existing tones, but without proper naming or traceability, causing duplication and confusion in usage.
Reasoning
Eliminate overlap to reduce confusion and prevent uncontrolled color creep.
3
We organized colors into light-to-dark spectrums, then reduced each spectrum to a single canonical shade to enforce clarity and predictable application.
Reasoning
Ensure new shades blend with existing app colors for visual consistency.
4
On top, we defined semantic colors—success, error, warning, surfaces, and more—each named, documented, and ready for consistent use across the entire app.
Reasoning
Align with universal standards so teams instantly know which color to use.
5
On top of that, we built semantic colors (success, error, warning, surface, etc.), each named and ready for use across the app.
Reasoning
Align with universal standards so teams instantly know which color to use.
Typography
Typography
1
We audited typography across the product, mapping accounted styles and identifying inconsistencies, drift, and gaps created by ad hoc additions over time.
Reasoning
Reveal inconsistencies and duplicates before rebuilding a typography system.
2
At the font level, we refined details using Inter—testing kerning—and found that approximately minus-3% letter spacing on larger sizes reads clearest.
Reasoning
Simplify divisions into fewer, clearer categories that are easier to recall.
3
We reorganized the type hierarchy, moving from the vague “body, subtitle, headline” model into clear categories: body, label, title, heading, and display.
Reasoning
Simplify divisions into fewer, clearer categories that are easier to recall.
4
We replaced confusing numeric names—body1, body1.5, body2—with a simple t-shirt sizing scale: XS, S, M, L, and XL for clarity and consistency across surfaces.
Reasoning
Keep button text consistent and expand flexibility with needed styles.
5
Finally, we replaced the confusing numbering system (body1, body1.5, body2, etc.) with a t-shirt sizing scale (XS, S, M, L, XL).
Reasoning
Adopt universal t-shirt sizing model, proven in systems like Uber Base.
6
We created a Figma preview with every style, tokens, examples, and usage notes, giving designers and developers quick reference and shared access.
Reasoning
Provide a single source of truth with examples and guardrails.
7
We added all styles into Figma and code, aligned naming, and ensured platform parity so designers and engineers reference the same canonical set.
Reasoning
Guarantee parity so designs translate cleanly into production components everywhere.
1
We audited typography across the product, mapping accounted styles and identifying inconsistencies, drift, and gaps created by ad hoc additions over time.
Reasoning
Reveal inconsistencies and duplicates before rebuilding a typography system.
2
At the font level, we refined details using Inter—testing kerning—and found that approximately minus-3% letter spacing on larger sizes reads clearest.
Reasoning
Simplify divisions into fewer, clearer categories that are easier to recall.
3
We reorganized the type hierarchy, moving from the vague “body, subtitle, headline” model into clear categories: body, label, title, heading, and display.
Reasoning
Simplify divisions into fewer, clearer categories that are easier to recall.
4
We replaced confusing numeric names—body1, body1.5, body2—with a simple t-shirt sizing scale: XS, S, M, L, and XL for clarity and consistency across surfaces.
Reasoning
Keep button text consistent and expand flexibility with needed styles.
5
Finally, we replaced the confusing numbering system (body1, body1.5, body2, etc.) with a t-shirt sizing scale (XS, S, M, L, XL).
Reasoning
Adopt universal t-shirt sizing model, proven in systems like Uber Base.
6
We created a Figma preview with every style, tokens, examples, and usage notes, giving designers and developers quick reference and shared access.
Reasoning
Provide a single source of truth with examples and guardrails.
7
We added all styles into Figma and code, aligned naming, and ensured platform parity so designers and engineers reference the same canonical set.
Reasoning
Guarantee parity so designs translate cleanly into production components everywhere.
1
We audited typography across the product, mapping accounted styles and identifying inconsistencies, drift, and gaps created by ad hoc additions over time.
Reasoning
Reveal inconsistencies and duplicates before rebuilding a typography system.
2
At the font level, we refined details using Inter—testing kerning—and found that approximately minus-3% letter spacing on larger sizes reads clearest.
Reasoning
Simplify divisions into fewer, clearer categories that are easier to recall.
3
We reorganized the type hierarchy, moving from the vague “body, subtitle, headline” model into clear categories: body, label, title, heading, and display.
Reasoning
Simplify divisions into fewer, clearer categories that are easier to recall.
4
We replaced confusing numeric names—body1, body1.5, body2—with a simple t-shirt sizing scale: XS, S, M, L, and XL for clarity and consistency across surfaces.
Reasoning
Keep button text consistent and expand flexibility with needed styles.
5
Finally, we replaced the confusing numbering system (body1, body1.5, body2, etc.) with a t-shirt sizing scale (XS, S, M, L, XL).
Reasoning
Adopt universal t-shirt sizing model, proven in systems like Uber Base.
6
We created a Figma preview with every style, tokens, examples, and usage notes, giving designers and developers quick reference and shared access.
Reasoning
Provide a single source of truth with examples and guardrails.
7
We added all styles into Figma and code, aligned naming, and ensured platform parity so designers and engineers reference the same canonical set.
Reasoning
Guarantee parity so designs translate cleanly into production components everywhere.
Spacing & Dividers
Spacing & Dividers
1
We audited spacing and divider usage, finding many random values applied inconsistently without documentation or standards across the product.
Reasoning
Reveal inconsistencies and ad-hoc usage before defining a clear spacing system.
2
To make spacing consistent, we formalized key tokens—especially 16, 24, and 32—and documented when to apply each within common layout patterns.
Reasoning
Define defaults to accelerate decisions and promote repeatable layouts consistently.
3
For dividers, we standardized three thicknesses—1px, 2px, 4px—each paired with subtle shade variations to suit density, contrast, and hierarchy needs better.
Reasoning
Offer minimal, flexible options that preserve hierarchy and visual calm.
1
We audited spacing and divider usage, finding many random values applied inconsistently without documentation or standards across the product.
Reasoning
Reveal inconsistencies and ad-hoc usage before defining a clear spacing system.
2
To make spacing consistent, we formalized key tokens—especially 16, 24, and 32—and documented when to apply each within common layout patterns.
Reasoning
Define defaults to accelerate decisions and promote repeatable layouts consistently.
3
For dividers, we standardized three thicknesses—1px, 2px, 4px—each paired with subtle shade variations to suit density, contrast, and hierarchy needs better.
Reasoning
Offer minimal, flexible options that preserve hierarchy and visual calm.
1
We audited spacing and divider usage, finding many random values applied inconsistently without documentation or standards across the product.
Reasoning
Reveal inconsistencies and ad-hoc usage before defining a clear spacing system.
2
To make spacing consistent, we formalized key tokens—especially 16, 24, and 32—and documented when to apply each within common layout patterns.
Reasoning
Define defaults to accelerate decisions and promote repeatable layouts consistently.
3
For dividers, we standardized three thicknesses—1px, 2px, 4px—each paired with subtle shade variations to suit density, contrast, and hierarchy needs better.
Reasoning
Offer minimal, flexible options that preserve hierarchy and visual calm.
Icons
Icons
1
We audited icon usage across the app, finding teams pulling from Material, Cupertino, and Noun Project with no shared rules or standards.
Reasoning
Reveal inconsistencies and duplicates before defining one unified icon system.
2
All icons follow simple forms with slight rounding and minimal detail, preserving clarity at small sizes and fitting the app’s friendly tone.
Reasoning
Rounded shapes feel friendly, minimal details ensure quick recognition without strain.
3
The standard size is 24×24 pixels with a 2px margin; scaling must follow proportional steps only, such as 24 to 18, never arbitrary resizing.
Reasoning
Prevent distortion and ensure predictable fit within components and layouts.
4
We introduced a strict naming scheme: lowercase, hyphen-separated, prefixed with “icon-”, and describing the literal shape to improve searchability and file handling.
Reasoning
Keep optical weight consistent to pair well with text and controls.
5
We introduced a strict naming convention: lowercase only, hyphens as separators, always starting with “icon-”, and describing the literal shape.
Reasoning
Improve search, file handling, and organized asset management across the system.
1
We audited icon usage across the app, finding teams pulling from Material, Cupertino, and Noun Project with no shared rules or standards.
Reasoning
Reveal inconsistencies and duplicates before defining one unified icon system.
2
All icons follow simple forms with slight rounding and minimal detail, preserving clarity at small sizes and fitting the app’s friendly tone.
Reasoning
Rounded shapes feel friendly, minimal details ensure quick recognition without strain.
3
The standard size is 24×24 pixels with a 2px margin; scaling must follow proportional steps only, such as 24 to 18, never arbitrary resizing.
Reasoning
Prevent distortion and ensure predictable fit within components and layouts.
4
We introduced a strict naming scheme: lowercase, hyphen-separated, prefixed with “icon-”, and describing the literal shape to improve searchability and file handling.
Reasoning
Keep optical weight consistent to pair well with text and controls.
5
We introduced a strict naming convention: lowercase only, hyphens as separators, always starting with “icon-”, and describing the literal shape.
Reasoning
Improve search, file handling, and organized asset management across the system.
1
We audited icon usage across the app, finding teams pulling from Material, Cupertino, and Noun Project with no shared rules or standards.
Reasoning
Reveal inconsistencies and duplicates before defining one unified icon system.
2
All icons follow simple forms with slight rounding and minimal detail, preserving clarity at small sizes and fitting the app’s friendly tone.
Reasoning
Rounded shapes feel friendly, minimal details ensure quick recognition without strain.
3
The standard size is 24×24 pixels with a 2px margin; scaling must follow proportional steps only, such as 24 to 18, never arbitrary resizing.
Reasoning
Prevent distortion and ensure predictable fit within components and layouts.
4
We introduced a strict naming scheme: lowercase, hyphen-separated, prefixed with “icon-”, and describing the literal shape to improve searchability and file handling.
Reasoning
Keep optical weight consistent to pair well with text and controls.
5
We introduced a strict naming convention: lowercase only, hyphens as separators, always starting with “icon-”, and describing the literal shape.
Reasoning
Improve search, file handling, and organized asset management across the system.
Buttons
Buttons
1
Initially, the app had one button style, two sizes—compact and large—and three variants: primary, secondary, tertiary, limiting flexibility and encouraging inconsistent hacks.
Reasoning
Set context by showing limitations of what we originally had in place.
2
We audited every button in code, cataloged ad-hoc implementations without design definitions, and interviewed designers and developers to capture missing use cases.
Reasoning
Capture ground truth and identify where needed variants were missing.
3
We introduced a standalone icon button and allowed icons on all buttons; button text now uses the new label typography for consistency and legibility.
Reasoning
Cover common layout patterns without one-off code or designer workarounds.
4
Every variant now ships with disabled and loading states by default, ensuring predictable behavior, accessible affordances, and easier testing across flows and platforms.
Reasoning
Provide the long-missing icon button instead of random workarounds in code or design.
5
Every variant now ships with disabled and loading states by default, ensuring predictable behavior, accessible affordances, and easier testing across flows and platforms.
Reasoning
Add feedback and states missing by default, making buttons reliable accelerants.
6
We added a colored variant—highly configurable within our visual language—while constraining customization: no shadows, no ad-hoc treatments, and consistent elevation rules across contexts.
Reasoning
Allow brand expression while preventing drift from system constraints over time.
1
Initially, the app had one button style, two sizes—compact and large—and three variants: primary, secondary, tertiary, limiting flexibility and encouraging inconsistent hacks.
Reasoning
Set context by showing limitations of what we originally had in place.
2
We audited every button in code, cataloged ad-hoc implementations without design definitions, and interviewed designers and developers to capture missing use cases.
Reasoning
Capture ground truth and identify where needed variants were missing.
3
We introduced a standalone icon button and allowed icons on all buttons; button text now uses the new label typography for consistency and legibility.
Reasoning
Cover common layout patterns without one-off code or designer workarounds.
4
Every variant now ships with disabled and loading states by default, ensuring predictable behavior, accessible affordances, and easier testing across flows and platforms.
Reasoning
Provide the long-missing icon button instead of random workarounds in code or design.
5
Every variant now ships with disabled and loading states by default, ensuring predictable behavior, accessible affordances, and easier testing across flows and platforms.
Reasoning
Add feedback and states missing by default, making buttons reliable accelerants.
6
We added a colored variant—highly configurable within our visual language—while constraining customization: no shadows, no ad-hoc treatments, and consistent elevation rules across contexts.
Reasoning
Allow brand expression while preventing drift from system constraints over time.
1
Initially, the app had one button style, two sizes—compact and large—and three variants: primary, secondary, tertiary, limiting flexibility and encouraging inconsistent hacks.
Reasoning
Set context by showing limitations of what we originally had in place.
2
We audited every button in code, cataloged ad-hoc implementations without design definitions, and interviewed designers and developers to capture missing use cases.
Reasoning
Capture ground truth and identify where needed variants were missing.
3
We introduced a standalone icon button and allowed icons on all buttons; button text now uses the new label typography for consistency and legibility.
Reasoning
Cover common layout patterns without one-off code or designer workarounds.
4
Every variant now ships with disabled and loading states by default, ensuring predictable behavior, accessible affordances, and easier testing across flows and platforms.
Reasoning
Provide the long-missing icon button instead of random workarounds in code or design.
5
Every variant now ships with disabled and loading states by default, ensuring predictable behavior, accessible affordances, and easier testing across flows and platforms.
Reasoning
Add feedback and states missing by default, making buttons reliable accelerants.
6
We added a colored variant—highly configurable within our visual language—while constraining customization: no shadows, no ad-hoc treatments, and consistent elevation rules across contexts.
Reasoning
Allow brand expression while preventing drift from system constraints over time.
Appbar
Appbar
1
We audited all app bars across the product, documenting every variation that appeared over time and clarifying which patterns still served real needs.
Reasoning
Understand current reality before proposing standardized, simplified variants that scale.
2
We studied external systems—Uber Base, Material 3, Apple HIG, Swiggy, Spotify—to understand successful patterns, trade-offs, and implementation details relevant to our context.
Reasoning
Avoid reinventing the wheel by learning from proven, widely adopted systems.
3
From the research, we aligned on a core direction: adopt the sliver app bar model to support scroll behaviors, flexible headers, and collapsing interactions.
Reasoning
Choose the most common industry pattern already familiar to users across apps.
4
We defined text styles and icon handling inside the bar, including a rule that more than two icons should collapse into a contextual overflow menu.
Reasoning
Deliver a long-requested feature, saving space and improving accessibility overall.
5
Finally, we created three core variants: solid, translucent, and clear app bars, with guidance on usage by screen type, content density, and scroll behavior.
Reasoning
Cover all present and future use cases with clear, well-documented defaults.
1
We audited all app bars across the product, documenting every variation that appeared over time and clarifying which patterns still served real needs.
Reasoning
Understand current reality before proposing standardized, simplified variants that scale.
2
We studied external systems—Uber Base, Material 3, Apple HIG, Swiggy, Spotify—to understand successful patterns, trade-offs, and implementation details relevant to our context.
Reasoning
Avoid reinventing the wheel by learning from proven, widely adopted systems.
3
From the research, we aligned on a core direction: adopt the sliver app bar model to support scroll behaviors, flexible headers, and collapsing interactions.
Reasoning
Choose the most common industry pattern already familiar to users across apps.
4
We defined text styles and icon handling inside the bar, including a rule that more than two icons should collapse into a contextual overflow menu.
Reasoning
Deliver a long-requested feature, saving space and improving accessibility overall.
5
Finally, we created three core variants: solid, translucent, and clear app bars, with guidance on usage by screen type, content density, and scroll behavior.
Reasoning
Cover all present and future use cases with clear, well-documented defaults.
1
We audited all app bars across the product, documenting every variation that appeared over time and clarifying which patterns still served real needs.
Reasoning
Understand current reality before proposing standardized, simplified variants that scale.
2
We studied external systems—Uber Base, Material 3, Apple HIG, Swiggy, Spotify—to understand successful patterns, trade-offs, and implementation details relevant to our context.
Reasoning
Avoid reinventing the wheel by learning from proven, widely adopted systems.
3
From the research, we aligned on a core direction: adopt the sliver app bar model to support scroll behaviors, flexible headers, and collapsing interactions.
Reasoning
Choose the most common industry pattern already familiar to users across apps.
4
We defined text styles and icon handling inside the bar, including a rule that more than two icons should collapse into a contextual overflow menu.
Reasoning
Deliver a long-requested feature, saving space and improving accessibility overall.
5
Finally, we created three core variants: solid, translucent, and clear app bars, with guidance on usage by screen type, content density, and scroll behavior.
Reasoning
Cover all present and future use cases with clear, well-documented defaults.
Yeah.
All the designs you just saw?
I developed them in code as well.
Development
Development
“We created consistent bricks, then built new walls with them and replaced the old walls too”
“We created consistent bricks, then built new walls with them and replaced the old walls too”
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.
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
Reflection
“We finished the house, but also learned 100 ways of how not to build one.”
“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.