A continuous design system practice I led to scale consistency across teams, products, and regions.

A Design System Built To Scale

Building a scalable design system across multi-market products

(Best viewed on desktop for full detail)

Project Overview

01

Year

2024 – 2025

Role

✶ Design System Lead

✶ Product Design

✶ QA

Key Contributions

✶ Defined system architecture and governance

✶ Led cross-team alignment with engineering

✶ Scaled system across products and regions (incl. LTR/RTL)

Impact

Reduced fragmentation and enabled consistent product experiences across markets

The Project

360F is a middleware company providing digital bancassurance, serving as a bridge between banks and insurers across Singapore, Thailand, Africa, and the Middle East. 

As 360F scaled across regions and products, UI decisions were increasingly made in isolation. Components were repeatedly recreated, behaviours diverged, and supporting new markets and languages became fragile.

The Challenge

02

01

Fragmented Interfaces

Components were repeatedly recreated across products, resulting in inconsistent UX, increased QA effort and slowed delivery.

02

LTR / RTL support

The system needed to support both English (LTR) and Arabic (RTL), requiring layouts and components to work symmetrically across directions.

03

Parallel Delivery

The design system evolved alongside active product development, requiring continuous balance between short-term delivery and long-term system integrity.

04

Continuous Change

Shifts in tools, frameworks, and priorities required the system to adapt without breaking existing products or workflows.

Design Process

03

My approach: A continuous loop designed to adapt as products, teams, and markets evolved.

Each step informed the next, and none existed in isolation.

Audit

Understand What Exists

I audited all active products, screens, and components across teams to understand:

✶ What patterns already existed

✶ Where duplication and inconsistency occurred

✶ How existing patterns behaved across different contexts and markets

→ This step helped surface duplication, hidden complexity, and gaps in foundational decisions.

The Outcome

 A clear baseline of the system’s current state, enabling informed decisions rather than assumptions.

Systemise

Turn Patterns Into Rules

With a full audit in place, I focused on defining foundations that could scale.

✶ Foundation

Tokens defining colour, typography (English & Arabic), spacing, radius, grid, and icons.

✶ Components

Reusable, prioritised components with defined states and behaviour.

✶ Templates

Page and journey references used to speed up work — not as sources for new components.

→ This ensured predictability across products and regions.

The Outcome

A stable foundation that supported reuse, localisation, and future expansion without redesigning from scratch.

Prioritise

Focus On Impact

The system evolved alongside active product development, so it was not possible (or desirable) to design everything at once. I prioritised:

✶ Base components used most frequently

✶ Patterns shared across multiple products

✶ Multi-language support

→ This allowed teams to continue shipping while the system matured.

The Outcome

A system that delivered value early, without blocking product velocity.

Evolve

Adapt As Products Scale

As tools, frameworks, and requirements changed, the system needed to evolve without breaking existing products. This included:

✶ Adapting the system to a shift from React (Storybook) to FlutterFlow (Widgetbook)

✶ Maintaining backward compatibility with live products

✶ Aligning regularly with engineers through weekly working sessions

✶ Updating documentation and QA processes as the system matured

→ Rather than aiming for a “final state,” I treated the system as an ongoing practice shaped by real product needs.

The Outcome

A resilient design system that continued to adapt as the company scaled across teams, products, and regions.

Impact

04

What Changed?

✶

A single source of truth replaced fragmented UI decisions

✶

Consistency improved across products, teams, and regions

✶

Delivery accelerated through reuse and shared patterns

✶

Duplication and QA overhead were reduced

What It Enabled?

The design system became product infrastructure.

It enabled 360F to scale across markets and languages while maintaining coherence, making localisation and customisation additive rather than disruptive.

As product complexity increased, the system reduced long-term design and engineering cost and established a shared, predictable way of building products, designed to evolve.

Key Learnings

✶ A design system is a long-term product, not a one-off deliverable

✶ Adoption depends as much on communication as on structure

✶ At scale, stability matters more than novelty

✶ Designing for multiple markets requires system-level thinking

© Mai Linh Design 2026
Made with love ♡ and good music ♬

Say hello
mailinh.designs@gmail.com
+65 8814 2089

Elsewhere
Resume
LinkedIn