Design Systems
Design systems work best when they directly improve product quality and team velocity—not when they exist as standalone artifacts.
At Foodsmart, I led the creation of Ambrosia, a design system built from the ground up to support multiple product surfaces, evolving product priorities, and a growing design team. The goal was not to create a perfect library. It was to create a system teams could actually use, extend, and trust. The work included defining shared foundations, introducing reusable components, improving documentation, and helping design and engineering align around practical decisions rather than abstract idealism.
Building from Zero
There was no established system when this work began. Patterns existed in isolated places, but there was no shared language or reliable source of truth. Ambrosia introduced:
foundational tokens for spacing, color, typography, and interaction
reusable components across product contexts
clearer naming conventions
documentation that explained intent, not just appearance
More Than One Library
The system evolved into distinct layers: Design Language System (DLS) for foundational principles, Product library for internal platform workflows, and Member library for customer-facing experiences. This allowed shared consistency while respecting different product needs.
What Scaling Actually Required
The hardest part of design systems is rarely drawing components. It is:
deciding where consistency matters most
knowing when not to standardize
documenting decisions before teams forget why they were made
helping engineers adopt patterns without slowing delivery
Principles
Consistency over perfection
Build for adoption
Document relentlessly
Systems are social before they are technical
Earlier in my career, I also built Nucleus, another system effort under different constraints. Together, those experiences reinforced the same lesson: systems succeed when they reduce friction, not when they chase elegance for its own sake.
Related case studies