A design system concept for Weee!
If we handed this app to a new designer, what would they start from?
That question became the brief.
A scalable design foundation for America's #1 Asian grocery app. Built to help Weee! move faster, stay consistent, and adapt across cuisines and cultures.
Role
UX/UI Designer
Duration
3.5 Months
Domain
E-commerce
CHALLENGE
Eight Cuisines. 7 Languages.
One Missing Layer.
Weee! ships fast. Eight cuisine storefronts. Seven languages. Millions of customers. The product keeps expanding into new categories, new cuisines, new surfaces.
That speed is the strength but it also raises the bar on infrastructure.
Four challenges at this scale
01
Every new feature pulls designers into the same small decisions
02
Every new storefront adds variation that needs to feel both native and consistent
03
Every new designer onboards into informal patterns instead of a shared system
04
Every new surface inherits whatever conventions happened to win that week
MY SHARE
What I was in-charge of
Umami was built by a team of four designers, all contributing across phases.
Within that shared work, I led these specific pieces:
Typography system
60 styles across 5 roles, all bound to a single font variable. The consolidation call from ten roles to five was a conversation I drove on the team.
Carousels and Category Cards
Created the component design and variant architecture for both.
Naming convention
Slash notation, property-value pairs, consistent ordering across the entire system.
Token structure
The architecture decisions about how tokens nest, reference, and propagate.
SOME PLACES WHERE WE SPOTTED INCONSISTENCIES
Same Same but different….
In the following screenshots the same product card has been used in different ways with different spacing and layout causing inconsistency.
1. Inspire
2. All Stores
3. Product Page
4. Global Plus
SOLUTION
Three principles.
One system.
A Single Source of Truth
A Figma-native design system, documented in Zeroheight, built from a full deconstruction of Weee!'s product. Three principles organize every decision.
01
Consistent from the Start
Token-based foundation locks in the visual language at the source.
02
Accessible from the Get-Go
Color contrast, type sizes, component states designed with accessibility built in.
03
Designed for Growth and Complexity.
Atomic architecture and slot-based components scale into new cuisines and surfaces without rebuilding.
Figma UI Kit
Zeroheight Documentation
THE AUDIT
Before we built anything, we took it apart.
The first three weeks of the project weren't design. They were excavation.
We pulled Weee!'s existing product apart, screen by screen, and laid every distinct UI pattern flat on a Figma board. The goal was to see the system that was already there. Not to critique it. To learn it.
What surfaced was depth, not chaos.
The audit found:
Ten typography roles in active use
Five color families serving different jobs
Three layout grids
Three illustration tiers
Navigation patterns split across Commerce, Marketing, Content, Utility
Strong, lived-in design decisions made at speed by real designers.
What this step taught me. The design wasn't bad. It was unaligned. That reframed everything that came after.
WHAT WE FOUND
Three Places Where Structure
Pays For Itself.
The deconstruction surfaced three places where structure creates the most leverage.
Color
The brand blue is recognizable. A token system locks it in everywhere. Five families (Primary, Accent, CTA, Neutral, Pastel) give every surface a defined role. One update propagates to every component automatically.
Typography
Ten roles compressed into five intentional ones. A defined scale makes hierarchy repeatable across all six languages. Designers stop deciding font sizes and start composing.
Components
Strong patterns already exist. Product cards, carousels, category nav. Formalized as atomic components, the next feature assembles rather than reinvents.
This step taught me that consistency creates leverage in some places. Variation does real work in others. Telling them apart became the hardest call on the project.
SYSTEM RULES
Three rules that hold everything together.
❝
No hardcoded values. Anywhere.
Every color, every type size, every spacing value references a token. If a value isn't bound, it doesn't ship.
❝
One token. One source. One update.
A color change happens once at the token layer. Every component using that token updates automatically. No find-and-replace.
❝
The component is the smallest unit a feature ships.
Designers compose with components, not from scratch. The atom is stable. The composition is flexible.
THE PROCESS
Audit. Foundation. Architecture.
01
Audit
Used the app as customers do. Screenshotted every distinct pattern. Categorized into Color, Typography, Components, Navigation, Layout, Illustration. Built a full visual inventory before designing anything new.
02
Foundation
Color tokens organized into Primary, Accent, CTA, Neutral, Pastel. Typography compressed to five semantic roles, 60 styles total, bound to one font variable. Spacing scale defined across mobile breakpoints.
03
Architecture
Atomic design applied. Atoms compose into molecules into organisms into surfaces. Every component references foundation tokens, never hardcoded values. Documentation template standardized before the library was built out.
What this step taught me is that the design wasn't bad. It was unaligned. That reframed everything that came after.
FOUNDATION: COLOR
Five families. Every color has a role.
The color system is organized by purpose, not by hue. Every component references a semantic role, never a raw hex. One token edit propagates everywhere.
Every component references the semantic role, never the raw hex. One token edit propagates everywhere.
FOUNDATION: TYPOGRAPHY
From ten roles to five.
I led the typography consolidation after an audit found ten active roles: Display, Heading, Title, Body, Label, Action, Data, Meta, Navigation, and Feedback. Each role served a purpose, but together they made the hierarchy harder to read. The challenge was deciding what truly needed to stay, especially when roles like Action, Label, Meta, and Caption had overlapping but valid use cases. I pushed for five core roles, with the rest absorbed through tiers and weights - not to simplify for the sake of it, but to make every remaining role carry more meaning.
BEFORE
10 roles in use
Display
Heading
Title
Body
Label
Action
Data
Meta
Navigation
Feedback
→
AFTER
5 intentional roles
Display
Heading
Body
Label
Price
Display
32 / 28 / 24
Aa
Aa
Aa
Heading
24 / 20 / 18
Aa
Aa
Aa
Body
16 / 14 / 12
Aa
Aa
Aa
Label
14 / 12 / 10
Aa
Aa
Aa
Price
22 / 20 / 18
$0
$0
$0
FONT DECISION
Noto Sans was the one. Full CJK coverage matters for an app rendering Chinese, Korean, Japanese, and Vietnamese alongside English. One variable. Every character set. And in future if Weee! decides to add support to more languages Noto Sans supports over 1000 languages, making their adaptation process easier.
Why each remaining role kept three tiers?
Every variant absorbs the job of one we removed.
COMPONENTS
The Building Blocks.
Every component is built from tokens, not hardcoded values. Variants follow consistent property axes, making them easier for the team to find and reuse. For example, Buttons include 10 components and 159 variants, composed across 7 axes: Type, Size, State, Shape, Icon, Notification, and Checkbox/Radio. This structure lets one base system cover every interaction surface in the product.
Buttons
10 components · 159 variants
Variants compose across 7 property axes: Type · Size · State · Shape · Icon · Notification · Checkbox/Radio.
Plus foundational components: cards, banners, empty states, filters, headers, tab bars, navigation patterns, and iconography tiers (feature, badge, category illustration).
The biggest decision in component work isn't what to build. It's how to compose what gets built.
COMPONENTS
Where Composition Happens.
The biggest decision in component work isn't what to build. It's how to compose what gets built.
Six carousel surfaces resolved into one slot-based pattern. Build the shell once. Vary the content. Adding a new carousel becomes a configuration call, not a new component.
Carousels
6 layout patterns
CategoryBar
Horizontal Row
Two Column Grid
Horizontal Card Carousel
Category Carousel
Banner Carousel
Plus foundational components: cards, banners, empty states, filters, headers, tab bars, navigation patterns, and iconography tiers (feature, badge, category illustration).
The biggest decision in component work isn't what to build. It's how to compose what gets built.
DOCUMENTATION & NAMING
One Template for Every Component.
The naming convention and the token structure (excluding colors) were areas I led on the team. Slash notation, property-value pairs, consistent ordering. The goal was findability without anyone needing to memorize the system.
Every component in Umami lives in a documentation page that follows the same template. Built in Figma, mirrored in Zeroheight for the broader team.
Every page carries
01
Header
Component name, category badge, descriptive caption
02
Meta strip
Components count, Variants count, Status (Complete / In Progress)
03
Inline navigation
Quick links to related subsections within the component family
04
Component preview
Real instances at scale, not isolated screenshots
05
Usage guidance
When to use each variant, what to avoid, anchored in Weee!'s grocery context
Naming is the most undervalued part of a design system.
A good convention does more work than three explanation pages.
The same convention threaded into tokens, components, and pages.
THE HONEST BEAT
What We Almost Got Wrong.
Halfway through, the team's instinct was to consolidate harder. Fewer roles. Fewer color variations. Fewer component variants.
The thinking was reasonable. Less variation usually means more consistency.
I pushed back. The deconstruction had already taught me something the team kept forgetting in practice. The existing Weee! design wasn't full of mistakes. It was full of decisions.
If we consolidated too aggressively, we'd flatten the product into something cleaner than Weee actually was. A design system isn't supposed to redesign the product. It's supposed to systematize what's already working and surface what isn't.
That balance shaped a lot of the calls that followed. Ten typography roles down to five, but five that each absorbed multiple jobs. Five color families instead of three, because the product genuinely needed five. Component variants kept generous where surfaces demanded them.
The lesson I keep coming back to,
When a team isn't on the same page across surfaces, the result looks like sloppiness from outside but is fragmentation from inside. The system's job is to fix the fragmentation, not the decisions.
OUTCOMES
What three and a half months built.
5
Color families
Primary, Accent, CTA, Neutral, Pastel
60
Text styles
5 roles × 3 tiers × 4 weights
159
Button variants
10 components, 7 property axes
Foundations
Color system organized into five token families with full semantic coverage
Typography consolidated from ten roles to five — 60 styles, all bound to one font variable
Spacing and grid scale defined across breakpoints
Components
Buttons: 10 components, 159 variants across 7 property axes
Carousels: 5 layout patterns covering primary feed surfaces
Cards, banners, empty states, filters, headers, tab bars, iconography tiers
Every component referencing the token layer, zero hardcoded values
Documentation
Standardized template in Figma, mirrored in Zeroheight
Naming convention threading through components, tokens, and pages
Status tracking, usage guidance on every page
The platform has a place to start from now. That was the point.
WHY THIS MATTERS
A system that knows it isn't finished.
That isn't a caveat. It's the design.
A frozen design system is already becoming a liability. Weee! launches a new cuisine storefront. A new market. A seasonal campaign. The system has to absorb that without breaking what already exists.
What Umami creates is the conditions for that movement to be controlled.
One color token edit propagates to every component automatically
A new surface for a new cuisine inherits the full design language by default
A new designer joining the team has a documented entry point into every decision
That's what we were actually building. Not a library. An agreement that holds even when the product around it keeps growing.
REFLECTING
What I'd Build Differently.
If I were starting again, I'd write the documentation template first and lock the naming convention earlier. We treated docs as an output of design work. They're not. They're the spec the work has to satisfy. The naming convention being late meant components had to be renamed after the fact.
THE BIGGEST LESSON
A design system is mostly judgment calls. The tooling is just the artifact. The system lives in the decisions about what stays in scope and what doesn't. The deconstruction taught me the most. We weren't building a system to fix the work. We were building a system to align it.
Three and a half months. Four designers. One question driving every decision. How do we make Weee! easier to scale?
Umami isn't a finished system. It's a foundation with real structure. The work to make it real is something I know how to do now in a way I didn't before.