Building the Design system that powered the Lose It! redesign.

Building the Design system that powered the Lose It! redesign.

Building the Design system that powered the Lose It! redesign.

OVERVIEW

When Lose It! set out to redesign its iOS experience, the design system wasn't ready to support the work. Components had drifted over time, styles were inconsistent, and every new screen required designers to recreate decisions that should have already been made.


I led the redesign of iOS design system, creating the component library, token architecture, and documentation aligned with the brand and Apple's latest design guidance that powered the redesign, and later extended it into AI-assisted workflows.

ROLE

ROLE

Owner of iOS Design system

Owner of iOS Design system

PLATFORM

PLATFORM

iOS · Figma variables & components · Claude Design

TIMELINE

TIMELINE

8 Weeks

IMPACT

IMPACT

Faster screen assembly / team adoption

The Challenge

The Challenge

The Challenge

A product redesign only moves as fast as the system underneath it.


The existing design system had grown organically over several years. Components had multiple versions, colors and typography existed as one-off styles, and documentation was limited. As the redesign gained momentum, those inconsistencies became a bottleneck.


At the same time, Apple introduced its new Liquid Glass design language. The product needed to feel native to the latest version of iOS while still feeling unmistakably like Lose It!.


Rather than treating the design system as a library of UI pieces, I approached it as the foundation that every designer would rely on throughout the redesign.

The Design Pillars

The Design Pillars

The Design Pillars

The goal wasn't simply to modernize the library. It was to give the team a system they could trust so every new screen could be built faster, more consistently, and with fewer design decisions repeated. Every component should be accessible, on-brand, and aligned with iOS by default, so designers could focus on solving product problems instead of rebuilding UI.

The goal wasn't simply to modernize the library. It was to give the team a system they could trust so every new screen could be built faster, more consistently, and with fewer design decisions repeated. Every component should be accessible, on-brand, and aligned with iOS by default, so designers could focus on solving product problems instead of rebuilding UI.

COMPLETE COMPONENT COVERAGE

Every recurring UI pattern was identified, rebuilt, and documented.

TOKEN BASED FOUNDATIONS

TOKEN BASED FOUNDATIONS

Color, typography, spacing, and corner radius were rebuilt using Figma Variables to create a scalable foundation.


NATIVE TO NEW iOS

NATIVE TO NEW iOS

Components and patterns were aligned with Apple's Liquid Glass guidance while preserving the Lose It! brand.

SELF SERVE DOCUMENTATION

SELF SERVE DOCUMENTATION

Clear documentation made the system usable for designers, product managers and engineers.

Clear documentation made the system usable for designers, product managers and engineers.

Key Design Decisions

Key Design Decisions

Key Design Decisions

These are the three decisions that had the most measurable impact on usability.

These are the three decisions that had the most measurable impact on usability.

Decision 01 - Audit the Product Before Building the System

Decision 01 - Audit the Product Before Building the System

OVERVIEW

OVERVIEW

Before designing anything new, I audited every component used across the production app. The goal wasn't to build the biggest design system possible. It was to build the one the product actually needed.


The audit exposed duplicated components, inconsistent patterns, and unnecessary variants that had accumulated over time. It also gave the redesign a clear scope by showing which components deserved investment and which could be simplified or removed.

TRADEOFF

TRADEOFF

Starting with an audit meant delaying component work, but it prevented surprises later in the redesign. Investing time upfront made the system more complete and reduced rework once product teams began adopting it.

Decision 2 - Build a Token Architecture That Could Scale

Decision 2 - Build a Token Architecture That Could Scale

Decision 2 - Build a Token Architecture That Could Scale

OVERVIEW

OVERVIEW

Instead of relying on traditional color and text styles, I rebuilt the foundation using Figma Variables.


Primitive tokens defined the raw building blocks such as color values, typography, spacing, and corner radius. Semantic tokens mapped those values to meaningful design decisions like Primary Surface, Secondary Text, and Card Radius. Components referenced semantic tokens rather than hard-coded values, making the system easier to maintain and evolve.


This architecture made future updates significantly simpler. Brand refinements, dark mode improvements, and future themes could be introduced by updating tokens instead of rebuilding components.

TRADEOFF

TRADEOFF

Defining semantic names required more discussion than building the components themselves. Naming became an important part of the system because every designer would rely on those decisions long after the project was finished.

Defining semantic names required more discussion than building the components themselves. Naming became an important part of the system because every designer would rely on those decisions long after the project was finished.

Defining semantic names required more discussion than building the components themselves. Naming became an important part of the system because every designer would rely on those decisions long after the project was finished.

Decision 3 - Translate Apple's Design Language Into Lose It's Product Language

Decision 3 - Translate Apple's Design Language Into Lose It's Product Language

Decision 3 - Translate Apple's Design Language Into Lose It's Product Language

OVERVIEW

OVERVIEW

Apple's Liquid Glass guidance introduced new patterns and visual behaviors, but applying those guidelines directly would have weakened parts of the Lose It! brand.


I created practical guidance that translated Apple's recommendations into decisions that fit our product. I documented which patterns we adopted, where we intentionally diverged, and how designers should apply those choices consistently across future work.


Instead of asking every designer to interpret Apple's documentation independently, the team could rely on a shared set of design principles built specifically for Lose It!.

I studied Apple’s Liquid Glass guidelines in depth, then wrote the translation layer for our team: what we adopt as-is, what we adapt to stay on-brand, and what we skip. These guidelines went straight into the documentation for buttons, icons, materials, and layout, so no designer had to re-interpret Apple’s rules on their own.

TRADEOFFS

TRADEOFFS

Platform guidance continues to evolve with every iOS release. Rather than documenting rigid rules, I created guidance that could evolve over time without forcing the team to relearn the system.

Platform guidance continues to evolve with every iOS release. Rather than documenting rigid rules, I created guidance that could evolve over time without forcing the team to relearn the system.

The Outcome

The Outcome

The Outcome

The design system became the foundation for the iOS redesign. Designers now build by composing reusable components instead of recreating UI from scratch.


I also migrated roughly half the component library into Claude Design to explore AI-assisted workflows. Early tests showed that structured components and semantic tokens produced more consistent results than prompting from scratch.

60+

60+

Components Published

300+

300+

Variables Created

75%

75%

Faster UI Assembly

65%

65%

System Adoption (on going)

Reflection

Reflection

Reflection

Building a design system isn't about creating components. It's about reducing decisions.


The most valuable part of this project wasn't the library itself. It was creating a shared language that helped designers move faster, stay consistent, and spend more time solving product problems instead of rebuilding UI. That shift in thinking has shaped how I approach every system I design today.

What's Next?

What's Next?

What's Next?

Beyond expanding component coverage and aligning tokens with engineering, I'm continuing to evolve the system for AI-assisted design. The next step is refining the Claude Design components so AI-generated interfaces follow the same accessibility, consistency, and product standards as the core system.

Beyond expanding component coverage and aligning tokens with engineering, I'm continuing to evolve the system for AI-assisted design. The next step is refining the Claude Design components so AI-generated interfaces follow the same accessibility, consistency, and product standards as the core system.

Copyright © 2024. Silu Manandhar

Copyright © 2024. Silu Manandhar