FoodCourt Design System

A design system built to bring order to a mobile app that had grown fast without shared rules, before that inconsistency started compounding with every new feature.

Background & Role

FoodCourt's app had accumulated small inconsistencies over time, in icon styles, colour usage, and spacing, the kind of drift that happens naturally as a product grows without a shared reference point. With more features on the roadmap, we recognised that leaving these inconsistencies unchecked would only make them harder to unwind later. Rather than wait for the problem to compound, we chose to establish a shared system early.

I worked alongside another product designer to research, define, and roll out the design system, in close collaboration with mobile engineering and the product manager who helped see it through implementation.

Timeline

January 2024 - March 2024

Tools

Figma, Google Meet, Jira, Slack

Foundations

Before building out components, we needed to establish the rules everything else would follow. We started with three foundational areas: typography, colour, and spacing, creating a consistent visual language for the rest of the system.

Typography: Typography wasn't really a decision we made, it was one we inherited. The app had used the same two typefaces since day one, so our job was less about choosing and more about formalising what already existed into a proper type scale. That gave future screens a consistent reference instead of relying on individual designers to eyeball sizes.
Colours: We organised the palette into three groups: product, primary, and neutral colours, each with a defined role within the system.Product colours created a visual distinction between the two sides of the app: FoodCourt Red for the core experience and FoodCourt Blue for FC Shop. Primary colours handled key actions and states, while neutrals formed the foundation for surfaces, text, borders, and supporting UI.
Spacing: Spacing was the most straightforward of the three. We adopted an 8px base unit and built smaller and larger increments around it, giving the system a consistent rhythm while still allowing for finer adjustments.

Typography: Typography wasn't really a decision we made, it was one we inherited. The app had used the same two typefaces since day one, so our job was less about choosing and more about formalising what already existed into a proper type scale. That gave future screens a consistent reference instead of relying on individual designers to eyeball sizes.
Colours: We organised the palette into three groups: product, primary, and neutral colours, each with a defined role within the system.Product colours created a visual distinction between the two sides of the app: FoodCourt Red for the core experience and FoodCourt Blue for FC Shop. Primary colours handled key actions and states, while neutrals formed the foundation for surfaces, text, borders, and supporting UI.
Spacing: Spacing was the most straightforward of the three. We adopted an 8px base unit and built smaller and larger increments around it, giving the system a consistent rhythm while still allowing for finer adjustments.

Styles & Components

With the foundations set, we documented icon sizing, alignment, and touch targets to keep interaction patterns consistent across the app, particularly important on mobile where inconsistent tap targets can easily become usability issues.

From there, we built out a component library covering core patterns such as inputs, buttons, search bars, bottom navigation, toast notifications, radio buttons, checkboxes etc. Each component had defined measurements, anatomy, variants, and use cases, giving designers and engineers a shared reference instead of requiring decisions to be made from scratch.

Rolling Out the Design System

A design system only works if people adopt it. We ran sessions with the wider team to walk through the structure and address questions from engineering before rollout. The mobile engineers were receptive and made the internal changes needed to bring existing screens in line.

We also created a product manual to document the system and guide future updates, making it easier for design and engineering to work from the same reference as the product evolved.

What Happened After

The system did what it was meant to do. New features continued to reference the same foundations rather than drifting back into inconsistency, and the shared language it created made design and engineering conversations faster and more efficient.

Check it out yourself on the Google Play Store or Apple App Store.