Lose It! Design System

Project Overview

Lose It! is a longstanding leader in health & nutrition tracking. As the app improved for users, the design system fragmented, with each team maintaining its own version.

As the iOS lead designer, I was responsible for the entire rebuild, from the initial audit to the final published file. I served as the sole designer, collaborating closely with engineering and our Design Director. The new system is fully tokenized, structured with true variants, and prepared for Liquid Glass integration update.

The entire company now designs, builds, and markets from a single unified file, reducing confusion and keeping every team aligned.

Project Overview

Lose It! is a longstanding leader in health & nutrition tracking. As the app improved for users, the design system fragmented, with each team maintaining its own version.

As the iOS lead designer, I was responsible for the entire rebuild, from the initial audit to the final published file. I served as the sole designer, collaborating closely with engineering and our Design Director. The new system is fully tokenized, structured with true variants, and prepared for Liquid Glass integration update.

The entire company now designs, builds, and markets from a single unified file, reducing confusion and keeping every team aligned.

The Problem

Our design system required an update, and Apple’s introduction of Liquid Glass made the transition essential. Building on a fragmented foundation would have led to misalignment and larger issues, so reestablishing a solid foundation became the first priority.

The previous system slowed designers because it lacked variants and variables. Similar components, such as cards with images or text, existed as separate entities in different locations, forcing designers to search through near-duplicates and confirm which version was current.

The system’s age and size made it difficult to confirm whether a component already existed, which led to repeated rebuilding and more duplication.

Apple's new Liquid Glass guidelines brought new guidelines that the old system could not support, making a stable, updated foundation necessary for the new look.

The lack of a shared source of truth affected more than design. Engineers, product managers, and marketing each relied on separate versions of the product, increasing misalignment.

The Problem

Our design system required an update, and Apple’s introduction of Liquid Glass made the transition essential. Building on a fragmented foundation would have led to misalignment and larger issues, so reestablishing a solid foundation became the first priority.

The previous system slowed designers because it lacked variants and variables. Similar components, such as cards with images or text, existed as separate entities in different locations, forcing designers to search through near-duplicates and confirm which version was current.

The system’s age and size made it difficult to confirm whether a component already existed, which led to repeated rebuilding and more duplication.

Apple's new Liquid Glass guidelines brought new guidelines that the old system could not support, making a stable, updated foundation necessary for the new look.

The lack of a shared source of truth affected more than design. Engineers, product managers, and marketing each relied on separate versions of the product, increasing misalignment.

The Messy Middle

Steps to System Rebuild

The following outlines a high level view to the approach to rebuilding the system.

Audit major screens and components. I reviewed the main app pages and the existing component library to identify current assets, duplication, and outdated elements.
Set priorities. I focused on changes that would provide the greatest impact. Colors were addressed first, as they form the foundation for other elements. Next, I prioritized the four main app pages, where users spend the most time and where Liquid Glass would be most visible.
Tokenize. Every color and type style was converted into a named token, ensuring consistency and system-driven decisions.
Rebuild as variants. I consolidated scattered copies into single, flexible components.
Consolidate. Duplicates and near-duplicates were merged or removed.
Align to Liquid Glass. I used the migration as an opportunity to reconsider the function of each component, rather than simply updating their appearance.

I evaluated every decision against 4 principles:

Prioritize a single source of truth.
Use variants instead of duplicates.
Tokenize color, type, and spacing.
Ensure the system serves all stakeholders, not just designers.

AI integration: I rebuilt the system within Claude as a functional design system so the team could prototype and iterate using real tokens and components rather than generic defaults. This allowed designers and engineers to test new features quickly in a live environment, rapidly exploring alternatives without time-consuming manual updates. Teams could share links to working prototypes, streamlining feedback loops and making cross-functional collaboration easier. The system stays consistent across tools, preventing fragmentation outside Figma and ensuring that design decisions carry through directly into implementation.

The Messy Middle

Steps to System Rebuild

The following outlines a high level view to the approach to rebuilding the system.

Audit major screens and components. I reviewed the main app pages and the existing component library to identify current assets, duplication, and outdated elements.
Set priorities. I focused on changes that would provide the greatest impact. Colors were addressed first, as they form the foundation for other elements. Next, I prioritized the four main app pages, where users spend the most time and where Liquid Glass would be most visible.
Tokenize. Every color and type style was converted into a named token, ensuring consistency and system-driven decisions.
Rebuild as variants. I consolidated scattered copies into single, flexible components.
Consolidate. Duplicates and near-duplicates were merged or removed.
Align to Liquid Glass. I used the migration as an opportunity to reconsider the function of each component, rather than simply updating their appearance.

I evaluated every decision against 4 principles:

Prioritize a single source of truth.
Use variants instead of duplicates.
Tokenize color, type, and spacing.
Ensure the system serves all stakeholders, not just designers.

AI integration: I rebuilt the system within Claude as a functional design system so the team could prototype and iterate using real tokens and components rather than generic defaults. This allowed designers and engineers to test new features quickly in a live environment, rapidly exploring alternatives without time-consuming manual updates. Teams could share links to working prototypes, streamlining feedback loops and making cross-functional collaboration easier. The system stays consistent across tools, preventing fragmentation outside Figma and ensuring that design decisions carry through directly into implementation.

Decision 1

Patch Existing Components or Rebuild as Variants?

The problem: The same component existed as several disconnected copies, requiring designers to search through similar versions and often rebuild existing elements.

What I did: I rebuilt every component as a true variant, using variables for text and imagery. For example, nearly 100 food icons were consolidated into a single component with a searchable set of variants. Typing “yogurt” immediately displays the yogurt icon.

How it solved it: a designer drops in one component and swaps content in seconds. No hunting, no second-guessing which version is approved.

The tradeoff: A complete rebuild required more time upfront than a simple cleanup. However, only a rebuild could resolve the trust issue, making reliability a higher priority than speed.

Decision 1

Patch Existing Components or Rebuild as Variants?

The problem: The same component existed as several disconnected copies, requiring designers to search through similar versions and often rebuild existing elements.

What I did: I rebuilt every component as a true variant, using variables for text and imagery. For example, nearly 100 food icons were consolidated into a single component with a searchable set of variants. Typing “yogurt” immediately displays the yogurt icon.

How it solved it: a designer drops in one component and swaps content in seconds. No hunting, no second-guessing which version is approved.

The tradeoff: A complete rebuild required more time upfront than a simple cleanup. However, only a rebuild could resolve the trust issue, making reliability a higher priority than speed.

Decision 2

Ensuring Scalable Color Usage for Future Features

The problem: Nutrition data relies heavily on color coding, with each nutrient color conveying specific meaning. However, colors were previously assigned as one-off values, causing inconsistency as new features or illustrations were added.

What I did: I systematized every color into named tokens and introduced extended shades for each palette color, allowing nutrient colors and illustrations to draw from a unified, extensible system.

How it solved the issue: New features now use existing shades rather than creating new values, ensuring palette consistency as the product evolves.

The tradeoff: Creating tokens with extended shades required more initial effort in naming and structuring than using hardcoded values. However, this approach prevents the palette from breaking with each new addition.

Decision 2

Ensuring Scalable Color Usage for Future Features

The problem: Nutrition data relies heavily on color coding, with each nutrient color conveying specific meaning. However, colors were previously assigned as one-off values, causing inconsistency as new features or illustrations were added.

What I did: I systematized every color into named tokens and introduced extended shades for each palette color, allowing nutrient colors and illustrations to draw from a unified, extensible system.

How it solved the issue: New features now use existing shades rather than creating new values, ensuring palette consistency as the product evolves.

The tradeoff: Creating tokens with extended shades required more initial effort in naming and structuring than using hardcoded values. However, this approach prevents the palette from breaking with each new addition.

Decision 3

Do I fight for the header, or ship the system without it?

The problem: I advocated for the on-scroll log header, but engineering identified it as a non-native solution that posed risks under a tight deadline.

What I did: I deferred the header component to avoid delaying the entire system for a single feature.

How it solved the issue: All teams received a reliable system they could use immediately, delivered on schedule, so the rebuild could create value without delay.

The tradeoff: Deferring the header was disappointing, especially since Apple later validated the concept. However, a design system’s value depends on team trust and timely delivery. The idea remains available for future implementation.

A little Anecdote - The header Apple ended up loving. While working on the log page, I designed a new on-scroll header that kept the date in view and surfaced a running calorie summary as you scrolled. Engineering pushed back. iOS doesn't ship that nav bar behavior natively, and hacking it in under a tight deadline was a real risk. It didn't make the cut. Later we showed the concept at Apple's Liquid Glass design workshop. They loved it and told us it was doable. It went from "too risky to ship" to "endorsed by Apple."

Decision 3

Do I fight for the header, or ship the system without it?

The problem: I advocated for the on-scroll log header, but engineering identified it as a non-native solution that posed risks under a tight deadline.

What I did: I deferred the header component to avoid delaying the entire system for a single feature.

How it solved the issue: All teams received a reliable system they could use immediately, delivered on schedule, so the rebuild could create value without delay.

The tradeoff: Deferring the header was disappointing, especially since Apple later validated the concept. However, a design system’s value depends on team trust and timely delivery. The idea remains available for future implementation.

A little Anecdote - The header Apple ended up loving. While working on the log page, I designed a new on-scroll header that kept the date in view and surfaced a running calorie summary as you scrolled. Engineering pushed back. iOS doesn't ship that nav bar behavior natively, and hacking it in under a tight deadline was a real risk. It didn't make the cut. Later we showed the concept at Apple's Liquid Glass design workshop. They loved it and told us it was doable. It went from "too risky to ship" to "endorsed by Apple."

The Challeges

The primary challenge was scale. Lose It! is 18-year-old app with significant evolution and extensive legacy code, so I had to make sure everything stayed up to date at once while still landing on time.

Achieving complete coverage was not possible, but the most critical components were made robust, providing a solid foundation for future development. The token-based design allowed easy extension of color, type, and spacing as new features are introduced, and flexible variants make it straightforward to add or adjust components without disrupting what already works.

The Challeges

The primary challenge was scale. Lose It! is 18-year-old app with significant evolution and extensive legacy code, so I had to make sure everything stayed up to date at once while still landing on time.

Achieving complete coverage was not possible, but the most critical components were made robust, providing a solid foundation for future development. The token-based design allowed easy extension of color, type, and spacing as new features are introduced, and flexible variants make it straightforward to add or adjust components without disrupting what already works.

The Outcome

The system served as the intended single source of truth. Design and product teams work more efficiently, with an estimated 40% reduction in friction when finding and trusting components. Engineers navigate the system more easily, improving handoffs, and marketing can reliably access brand colors. Consistency is maintained across both Figma and Claude design. These improvements directly support business goals around speed to market and product excellence.

The Outcome

The system served as the intended single source of truth. Design and product teams work more efficiently, with an estimated 40% reduction in friction when finding and trusting components. Engineers navigate the system more easily, improving handoffs, and marketing can reliably access brand colors. Consistency is maintained across both Figma and Claude design. These improvements directly support business goals around speed to market and product excellence.

My Reflection

A design system is more than a collection of well-designed components; it is a contract that multiple teams agree to trust. While tokens and variants demonstrate craftsmanship, true success is measured by adoption, which depends on clarity, naming, and trust rather than visual elegance alone, so the payoff is shared use.

The header taught me something too. A good idea isn’t dead just because it didn’t ship on schedule. Sometimes it’s just waiting for the platform to catch up.

My Reflection

A design system is more than a collection of well-designed components; it is a contract that multiple teams agree to trust. While tokens and variants demonstrate craftsmanship, true success is measured by adoption, which depends on clarity, naming, and trust rather than visual elegance alone, so the payoff is shared use.

The header taught me something too. A good idea isn’t dead just because it didn’t ship on schedule. Sometimes it’s just waiting for the platform to catch up.