Concept

2026

Weee! Design System - Turning a fragmented interface into a shared design language

Weee!’s product had grown across cultures, categories, and features, but its interface had grown in pieces. More than 60 color values, 27 tag styles, several grid systems, and repeated component variations made everyday design decisions harder than they needed to be. As part of a four-person team, I helped create Umami: a proposed design system connecting foundations, reusable components, accessibility standards, documentation, and contribution guidance.

Role

Product Designer

Timeline

4 months

Team

4 Designers

Platform

Figma, Zeroheight

Role

Product Designer

Timeline

4 months

Team

4 Designers

Platform

Figma, Zeroheight

Overview

A shared system for a product that had grown in pieces.

Weee!’s interface had expanded through a series of one-off decisions. Similar components were recreated across flows; more than 60 color values were in use; 27 tag styles competed for attention; and several color combinations failed accessibility checks. We created Umami to turn those repeated decisions into reusable rules.

What I owned

I focused on the parts of the system that had to be understood, not just built.

I led the interface and component audit, semantic tag architecture, component consolidation, accessibility review, Zeroheight documentation structure, and the external designer test. I also contributed to color, typography, grids, and the final system presentation.

Project context

Independent concept based on publicly available Weee! interfaces.

Not commissioned by or implemented at Weee!.

The scope was concrete, even though the system was not shipped.

These numbers describe what we audited and built. They are not presented as business impact.

60+

color value audited

27+

tag styles audited

21

consolidated color tokens

10

typography roles

252

tag combinations

40+

documented components and variants

Audit

The problem was not one inconsistent screen. It was repeated decisions without shared rules.

We deconstructed the web and mobile experience across color, typography, buttons, tags, cards, navigation, grids, motion, and accessibility. The same patterns had been rebuilt with different meanings, styles, and states.

60+

color values spread across the product

27+

tag treatments carrying competing meanings

3

grid approaches without clear usage rules

2.65:1

one of the contrast failures uncovered

There was no shared guide to help make consistent choices.

What should have been 7 intentional families had fractured into 60+ individual values. No single designer made a wrong call. The system had no shared reference.

Typography was inconsistent

Typography was chosen screen by screen on instinct, without a shared scale; the interface spoke in multiple voices simultaneously.

Navigation was difficult and different

Filters, tabs, and pill buttons all handled navigation, but each looked different. This made users figure out how things worked again on every screen.

Foundations

Before components, we defined the decisions underneath them.

A library cannot stay consistent when color, type, spacing, grids, and accessibility are still open to interpretation.

We organized those foundations first, then traced them into components and product patterns.

Design for all users

Accessibility was a requirement at the foundation level, not a check at the end.

01

Be authentic and clear

Components had to describe what they actually did without adding noise or misleading emphasis

02

Build for change

The system needs controlled flexibility instead of a new component for every screen.

03

Audit

13 competing pinks

Primitive

Dragonfruit Pink 500

Semantic

Promotion/Primary

Component

Promotional tag

Pattern

Offer label on product cards

Example through the system

One type system instead of screen-by-screen choices.

We replaced contextual font decisions with ten named roles. Noto Sans supported the product’s multilingual audience while giving headings, body text, labels, actions, and data a predictable hierarchy.

Multilingual

Contrast and touch targets shaped the palette and components.

We checked contrast while defining the system instead of treating accessibility as a final review. Touch-target guidance also covered controls whose visible height was smaller than the recommended interactive area.

Accessibility from the start

System decisions

The strongest parts of the system came from deciding what each pattern meant.

We focused on places where similar-looking elements were doing different jobs. The goal was not to minimize variants at any cost. It was to make every variant explainable.

Tags needed an order of importance.

Promotions, dietary information, status, and categories had been styled as if they were equally urgent. We consolidated them into one component, then defined semantic groups, visual weight, and stacking priority.

Components needed flexibility without becoming unmanageable.

Product cards, buttons, labels, and carousels had to work across different screen sizes and content conditions. Shared families used controlled properties for orientation, size, state, availability, and interaction.

1

Promo - Highest weight,

time-sensitive

Bold color, always takes

priority in stacking.

Flash Sale

Promo

Ends Soon

2

Dietary - Informational, persistent

Softer color, lower visual weight. Persistent doesn’t

change based on time.

Promo

Dairy Free

Vegan

3

Status - Neutral, dynamic

Updates dynamically. Low urgency unless combined with Promo.

In Stock

Limited

Out of Stock

4

Category - Lowest weight, navigation aids

Never compete with Promo or Dietary tags.

Meat

Seafood

Vegetables

Documentation was part of the component.

A Figma component was not finished until another designer could understand when to use it, when not to use it, how it behaved, and what accessibility rules came with it.

Test drive

The library looked complete until someone else tried to use it.

We asked a designer outside the project to recreate a Weee! screen using only the library and documentation. The test exposed four places where the system still depended on knowledge held by its creators.

What did not work
The first attempt did not fail because the components looked wrong. It failed because the library’s structure did not match how a new designer searched, chose, and combined them.

We found four issues and fixed each one.
The test did more than confirm the system; it actually improved it.

Each issue we found led to a real improvement in the system. These were not just minor tweaks, but major changes. The main lesson was that most problems were not about missing features. Instead, our language was different from the words designers already use.

Built and added the missing header component

A complete top navigation header with logo, navigation links, search, and cart was added to the library and became the first part of the Getting Started guide.

Reorganized button variants by type, not by state

Buttons were regrouped into Primary, Secondary, Destructive, and Ghost, with states nested under each type so designers make fewer decisions.

Reduced carousel size and added scroll direction annotation

The carousel was scaled to a realistic viewport proportion and annotated so the horizontal scroll interaction is legible from a static Figma frame.

Added semantic aliases to color tokens

A semantic alias layer was added for surfaces, raised layers, and subtle backgrounds, mapping food-named primitives to language designers already use.

We asked a designer unfamiliar with our work to build a Weee! screen using only our library components. They ran into four main problems.

After making the first version of the UI kit, we tested it with a simple challenge: one designer, one task, no help. The results were not about looks. Instead, they showed missing parts in our components, how easy they were to use, and whether our naming system matched how designers really think.

Outcome

We finished with a stronger foundation and a clearer view of what was still missing

Umami connected the audit, foundations, components, accessibility guidance, documentation, contribution support, and final pitch. The outcome was a complete design system proposal, not a production rollout.

The case study tells the story. The artifacts let you inspect the system.

Each preview is built from the real Umami component structure: color foundations, tag variants, buttons, product cards, typography, and documentation.

Open the Figma System

Risk is ranked on load. Every row carries severity, cohort size, affected courses, and a direct Review action.

Open Figma library

See how we presented the system

The pitch connects audit evidence, system principles, accessibility decisions, reusable components, and future recommendations

Open pitch deck

Read the Zeroheight documentation

Review component guidance, accessibility rules, contribution steps, resources, and release notes.

View Documentation

consolidated color tokens

21

named color families

7

semantic typography roles

10

supported tag combinations

252

These numbers describe the system we created. They are not evidence of product adoption, business impact, or design and engineering velocity.system

A connected design system proposal

Figma foundations, components, variants, and states
Zeroheight getting started and usage documentation
Accessibility and touch target guidance
Contribution guidance and release note structure
A tested revision of library coverage and organization

A design system works when the next person can understand the decision without having to ask the person who made it.

I started by treating consistency as a visual problem. Testing showed me it was also a dependency problem.

A library can contain every color, component, and state and still fail when its structure only makes sense to the people who built it. That changes how I judge the work: completeness was not the finish line.

Independent use was the real test of whether the system worked. A library was not complete simply because we had documented every component; it was complete only when another designer could find, understand, and apply those decisions without our help.

Explore more

🏆 Designing stronger reasons to return to Amazon Music

From medication tracking to shared care coordination

Enterprise LMS: Multi-Role Workflows & AI Integration

🏆 Designing stronger reasons to return to Amazon Music

From medication tracking to shared care coordination

Enterprise LMS: Multi-Role Workflows & AI Integration

Weee! Design System - Turning a fragmented interface into a shared design language

Role

Timeline

Team

Platform

Role

Timeline

Team

Platform

A shared system for a product that had grown in pieces.

What I owned

I focused on the parts of the system that had to be understood, not just built.

Project context

Independent concept based on publicly available Weee! interfaces.

The scope was concrete, even though the system was not shipped.

60+

27+

21

10

252

40+

The problem was not one inconsistent screen. It was repeated decisions without shared rules.

60+

27+

3

2.65:1

There was no shared guide to help make consistent choices.

Typography was inconsistent

Navigation was difficult and different

Before components, we defined the decisions underneath them.

Design for all users

01

Be authentic and clear

02

Build for change

03

Audit

Primitive

Semantic

Component

Pattern

Example through the system

One type system instead of screen-by-screen choices.

Contrast and touch targets shaped the palette and components.

The strongest parts of the system came from deciding what each pattern meant.

Tags needed an order of importance.

Components needed flexibility without becoming unmanageable.

1

Promo - Highest weight,

time-sensitive

2

Dietary - Informational, persistent

3

Status - Neutral, dynamic

4

Category - Lowest weight, navigation aids

Documentation was part of the component.

The library looked complete until someone else tried to use it.

What did not work

We found four issues and fixed each one. The test did more than confirm the system; it actually improved it.

Built and added the missing header component

Reorganized button variants by type, not by state

Reduced carousel size and added scroll direction annotation

Added semantic aliases to color tokens

We asked a designer unfamiliar with our work to build a Weee! screen using only our library components. They ran into four main problems.

We finished with a stronger foundation and a clearer view of what was still missing

The case study tells the story. The artifacts let you inspect the system.

Open the Figma System

See how we presented the system

Read the Zeroheight documentation

consolidated color tokens

21

named color families

7

semantic typography roles

10

supported tag combinations

252

A connected design system proposal

A design system works when the next person can understand the decision without having to ask the person who made it.

We found four issues and fixed each one.
The test did more than confirm the system; it actually improved it.