Rebuilding the design system that powered the Lose It! redesign.

Rebuilding the design system that powered the Lose It! redesign.

Rebuilding the design system that powered the Lose It! redesign.

OVERVIEW

When Lose It! committed to an app-wide redesign, the existing design system couldn’t carry it. I owned the iOS design system end-to-end: component library, token architecture, and documentation aligned to Apple’s Liquid Glass guidelines so that any designer, and PM could open Figma and build redesign-quality screens immediately.

[Add metric: “X components, Y tokens — used in Z% of redesign screens.”]

When Lose It! committed to an app-wide redesign, the existing design system couldn’t carry it. I owned the iOS design system end-to-end: component library, token architecture, and documentation aligned to Apple’s Liquid Glass guidelines so that any designer, and PM could open Figma and build redesign-quality screens immediately.

[Add metric: “X components, Y tokens — used in Z% of redesign screens.”]

ROLE

ROLE

Owner of iOS Design system

Owner of iOS Design system

PLATFORM

PLATFORM

iOS · Figma variables & components

TIMELINE

TIMELINE

8 Weeks

IMPACT

IMPACT

Faster screen assembly / team adoption

The Problem

The Problem

The Problem

A redesign is only as fast as the system underneath it. Lose It!'s existing design system was outdated and thinly documented components had drifted, colors and type lived as one-off styles, and every new screen meant rebuilding decisions that should have been solved once.


At the same time, Apple had introduced its Liquid Glass design language. The redesign had to feel native to the new iOS which meant the system couldn't just be cleaned up. It had to be rethought.

A redesign is only as fast as the system underneath it. Lose It!'s existing design system was outdated and thinly documented components had drifted, colors and type lived as one-off styles, and every new screen meant rebuilding decisions that should have been solved once.


At the same time, Apple had introduced its Liquid Glass design language. The redesign had to feel native to the new iOS which meant the system couldn't just be cleaned up. It had to be rethought.

The Goal

The Goal

The Goal

Build a design system where the right way is the easy way any designer grabs a component and gets accessibility, brand, and iOS-native behavior for free.

Build a design system where the right way is the easy way any designer grabs a component and gets accessibility, brand, and iOS-native behavior for free.

COMPLETE COMPONENT CPVERAGE

Every recurring pattern identified, rebuilt, and published

TOKEN BASED FOUNDATIOnS

TOKEN BASED FOUNDATIOnS

Color, typography, spacing, and radius as Figma variables, not one-off styles


NATIVE TO NEW iOS

NATIVE TO NEW iOS

Aligned with Apple's Liquid Glass guidelines


Aligned with Apple's Liquid Glass guidelines


SELF_SERVE DOCUMENTATION

SELF_SERVE DOCUMENTATION

Usable by a designer, PM, and Engineer

Usable by a designer, PM, and Engineer

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 before building inventory every component in production

Decision 01 - Audit before building inventory every component in production

OVERVIEW

OVERVIEW

Before creating anything, I catalogued every component type actually used across the app. This surfaced where designs had drifted, which variants were truly needed, and which existed only by accident. The audit became the system's scope: build what the product uses, not what a textbook says a design system needs.

Before creating anything, I catalogued every component type actually used across the app. This surfaced where designs had drifted, which variants were truly needed, and which existed only by accident. The audit became the system's scope: build what the product uses, not what a textbook says a design system needs.

TRADEOFF

TRADEOFF

The audit cost some time before a single component was built. It was a slower start, but it meant zero "Wait, we forgot the X component" surprises mid-redesign.

Decision 2 - Tokens first. Primitive → Semantic variable architecture

Decision 2 - Tokens first. Primitive → Semantic variable architecture

Decision 2 - Tokens first. Primitive → Semantic variable architecture

OVERVIEW

OVERVIEW

I built the foundations as Figma variables, not styles: a primitive layer (raw color ramps, type scale, spacing and radius units) mapped to a semantic layer (surface/primary, text/secondary, radius/card). Components only reference semantic tokens, so a brand tweak, a dark mode, or a new theme propagates through the entire system in one change.

I built the foundations as Figma variables, not styles: a primitive layer (raw color ramps, type scale, spacing and radius units) mapped to a semantic layer (surface/primary, text/secondary, radius/card). Components only reference semantic tokens, so a brand tweak, a dark mode, or a new theme propagates through the entire system in one change.

TRADEOFF

TRADEOFF

A semantic naming debates are slow and feel bureaucratic. But naming is the API of a design system, getting it right once beats renaming across 100 components later.

A semantic naming debates are slow and feel bureaucratic. But naming is the API of a design system, getting it right once beats renaming across 100 components later.

A semantic naming debates are slow and feel bureaucratic. But naming is the API of a design system, getting it right once beats renaming across 100 components later.

Decision 3 - Translate Liquid Glass into Lose It!'s language

Decision 3 - Translate Liquid Glass into Lose It!'s language

Decision 3 - Translate Liquid Glass into Lose It!'s language

OVERVIEW

OVERVIEW

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.

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.

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

Following a brand-new OS language means designing against guidelines that are still settling. I documented decisions as versioned guidance rather than fixed law, so updates wouldn't break trust in the docs.

Following a brand-new OS language means designing against guidelines that are still settling. I documented decisions as versioned guidance rather than fixed law, so updates wouldn't break trust in the docs.

The Result

The Result

The Result

The redesign team now builds new screens by composing, not recreating, and the theme system (see my themes case study) plugs directly into this token architecture.

7%

7%

Of the iOS design system built & documented by me

Cultural authenticity

Cultural authenticity

Components published · [Y] tokens/variables defined

One design system

One design system

e.g. % of redesign screens built from the system, or screen-assembly time before vs. after

e.g. % of redesign screens built from the system, or screen-assembly time before vs. after

What's Next?

What's Next?

What's Next?

Finishing the remaining component coverage, syncing tokens with engineering's variable names for true design–code parity, and adding contribution guidelines so the system grows without drifting again.

Finishing the remaining component coverage, syncing tokens with engineering's variable names for true design–code parity, and adding contribution guidelines so the system grows without drifting again.

Copyright © 2024. Silu Manandhar

Copyright © 2024. Silu Manandhar