Design System Layered Architecture: From Preset to Platform

🌏 閱讀中文版本

---

The Grind of 9 Presets

The PM throws a Figma file at you.

“This one’s urgent.”

You open it. brand-system-v9-final-final-2.fig.

9 Presets. Finance, Healthcare, E-commerce…

They all look basically the same.

But this client wants “Finance seriousness” paired with “Tech lightness.”

That option doesn’t exist.

Either you modify the Finance template (affects every other banking client). Or you manually copy one, rename it Finance-Tech-Style, and adjust colors component by component.

Manual copy.

Then on another project, the client wants “Healthcare’s large type” with “E-commerce’s high-contrast palette.”

Another manual copy.

Checked the time logs (internal team estimates, not published research).

Over the past six months, custom Preset work alone ate 40 hours — copying files, adjusting tokens, QA alignment, roughly a third each.

40 hours.

Three Figma files that differ only in Primary Color.

This is normal.

The area worth optimizing:

We’ve been applying an additive solution to a multiplicative cost problem.

---

The Limits of Flat Presets

Most Design Systems start flat.

Preset 1: Finance Preset 2: Healthcare … Preset N: Startup

Each Preset is a closed box.

Inside each box, three things are bundled together:

• Visual style (Typography, Spacing, Border Radius)
• Brand color (Primary, Secondary, Semantic)
• Industry patterns (Hero block types, terminology, compliance considerations)

This is normal.

When you have five clients and their needs don’t overlap, it’s the fastest approach.

But once you pass ten clients and requirements start crossing, flat Preset predictability drops.

Combinatorial explosion.

Definition: “Preset artifact” here means a complete Figma file (or a bound token set) that bundles style, color, and industry patterns into a single package.

Six visual styles, ten industry patterns. In a flat architecture, you need 6 × 10 = 60 Preset artifacts.

Add 10 brand color options? 60 × 10 = 600 Preset artifacts.

600 Figma files.

Maintenance cost: astronomical.

And that’s only the theoretical number.

Reality is harder:

Because color and style are bound together, you can’t swap them independently.

Want to apply “Healthcare blocks” with a “Tech color palette”?

You can’t. The Healthcare Preset has colors hardcoded into the component variables.

You have to decouple them manually.

Manually.

Key Insight: In a flat architecture, maintenance cost is Style × Color × Industry (multiplicative). When any one dimension grows, workload multiplies — it doesn’t add.

This is why Design Systems grow larger but get harder to work with.

---

Three Layers: Style × Color × Industry

Start by separating the skeleton.

Layer 1: Style (Skeleton)

The first time a junior team member hears “layering,” they usually ask: “Isn’t Style just how things look?”

No. Style is the skeleton, not the look.

The skeleton has no color.

It defines:

• Typography (typeface, weight, line height)
• Spacing (spacing ratios, whitespace strategy)
• Border Radius (0px sharp vs 24px rounded)
• Shadows (none / light / heavy)
• Motion (no animation / subtle / lively)

Examples:

• Minimal: Inter, no borders, no shadows, generous whitespace
• Bold: Roboto Slab, heavy weight, sharp borders, strong shadows
• Playful: Nunito, large radius, gentle bounce animations

Style isn’t the look — it’s proportion and rhythm.

It handles shape and rhythm only. Not fill.

Layer 2: Color Scheme (Skin)

Color is the skin.

PMs often ask: “What if the client has their own brand colors?”

Just feed them in. No need to rebuild the skeleton.

It defines:

• Primary / Secondary / Accent
• Semantic (Success / Warning / Error)
• Neutrals (Background / Text / Border)

The key point:

Color can be preset or generated.

If the client has a brand guide, input the HEX values and generate an initial palette. Then validate WCAG contrast, dark mode, and semantic states. If they don’t have one, pick from 10 base palettes built into the Style defaults.

Color doesn’t affect structure. It only affects fill.

Figma Variables handles storing and applying tokens. Palette generation and WCAG validation require a plugin, script, or theme builder.

Layer 3: Industry Patterns (Muscle)

Industry is the muscle.

Industry isn’t visual style — it’s how content is arranged.

It defines:

• Block types (Hero, Features, Pricing, Testimonials)
• Terminology (Finance uses “subscribe,” Healthcare uses “appointment”)
• UX conventions (Finance favors data tables, Healthcare favors large type)
• Compliance considerations worth reviewing (HIPAA, PCI-DSS — actual applicability depends on business scope and geography)

Industry doesn’t determine the look.

It determines how content is arranged and expressed.

---

Combinatorial Explosion: From 600 Files to 28 Modules

Now, separate the three layers.

Layer	Variations	Count
Style	6 (Minimal, Bold, Playful, Corporate, Tech, Elegant)	6
Color	10 base palettes + ∞ custom	10+
Industry	12 patterns (Finance, Healthcare, E-commerce, SaaS, Education, Media, Non-profit, Government, Startup, Fintech, Edtech, Healthtech)	12

Theoretical combinations: 6 styles × 10 palettes × 12 industries ≈ 720.

That sounds like more than 600?

It is. But the comparison isn’t apples-to-apples.

Flat 600 = 600 artifacts that need human maintenance. Layered 720 = 720 results that compose on demand — backed by only 6 + 10 + 12 = 28 modules.

The key isn’t the number of combinations — it’s the cost formula:

• Flat architecture: cost = S × C × I (multiplicative — add one dimension and cost multiplies)
• Layered architecture: cost = S + C + I (additive — add one dimension and cost grows by one file)

In a flat architecture, adding one new industry pattern means copying 6 Styles, then 10 Color variants for each. 6 × 10 = 60 files.

In a layered architecture, adding an 11th industry? Style and Color stay untouched. Add one JSON file.

Because they’re independent.

---

Concrete Mapping: What Does Industry Actually Control?

Many teams confuse “Industry” and “Style.”

They assume “Healthcare” means “green colors, large type, rounded corners.”

This is a common conflation.

Industry affects content and UX patterns, not visual skeleton.

The three examples below are common default combinations (not requirements) — Industry itself only owns the middle column, “Patterns.” Style and Color layer on separately:

Finance — Common Combination

• Common Style: Corporate (precise, aligned, no animation)
• Common Color: Deep Blue (trust, stability)
• Industry Patterns (what Industry actually defines):
  • Hero block: emphasize assets under management and compliance credentials
  • Features: data tables, interest rate calculators
  • Terminology: “subscribe,” “redeem,” “annualized return”
  • Compliance considerations: may need PCI-DSS badges, privacy policy links (depending on business scope)

Healthcare — Common Combination

• Common Style: Minimal (clear, no distractions, large type)
• Common Color: Teal/Green (health, calm)
• Industry Patterns:
  • Hero block: emphasize appointment button and physician profiles
  • Features: symptom lookup, department navigation
  • Terminology: “appointment,” “visit,” “medical record”
  • Compliance considerations: may need HIPAA statements, medical device certification badges (depending on geography and scope)

E-commerce — Common Combination

• Common Style: Playful (high contrast, strong shadows, micro-animations)
• Common Color: Orange/Red (urgency, call to action)
• Industry Patterns:
  • Hero block: emphasize limited-time offers and shopping cart
  • Features: product recommendations, star ratings
  • Terminology: “add to cart,” “checkout,” “promo code”
  • Compliance considerations: cookie consent, return policy (depending on geography)

Note:

“Common combinations” aren’t locked in. A client can take Healthcare Patterns and pair them with Tech Style and their own brand colors.

If you hardcode “Healthcare’s large type” into the Style layer, you lose that flexibility.

Because a Tech product may also need large type — say, an app built for older users.

Industry should only define content structure and UX conventions.

Style defines proportion.

Color defines brand.

---

Trade-offs: When Layering Isn’t the Right Fit

To be clear, flat Presets are the right call early on.

They have a clear applicable range.

Layered architecture isn’t for every workflow.

If your team has two people, flat Presets may be the better fit for now.

The complexity of layering can exceed its benefits.

When Layering Makes Sense

• Many clients with overlapping needs: e.g., 20 clients all needing different brand colors but sharing the same industry patterns.
• Larger teams: designers, frontend engineers, and PMs work independently. Layering lets each person focus on their own layer.
• Long-term maintenance: Design System expected to run for 2+ years. Layering keeps update costs manageable.

When Layering Doesn’t Make Sense

• Single project: if you serve one client with clearly defined needs, flat Presets are faster.
• High customization: if every project needs 80% custom work, the “standardization” advantage of layering disappears.
• Small team: if there are only 1-2 designers, the decoupling overhead may exceed the maintenance savings.

Decision criteria:

If your team spends more time copying Presets and manually adjusting colors than designing new blocks, layering is a direction worth considering.

---

How to Start: Three Steps

No need to rewrite your entire Design System.

Start with the smallest viable unit.

Step 1: Decouple Style and Color

Identify which parts of your existing Presets are “skeleton” and which are “color.”

For example, Typography and Spacing in Finance-Preset are skeleton. Primary-Color is color.

Extract the skeleton as Style-Corporate.json. Extract the color as Color-DeepBlue.json.

Minimal token schema example:

// Style-Corporate.json (skeleton, no color)
{
  "typography": { "fontFamily": "Inter", "scale": [12,14,16,20,24,32] },
  "spacing":    { "base": 4, "scale": [0,4,8,16,24,32,48] },
  "radius":     { "sm": 2, "md": 4, "lg": 8 }
}

// Color-DeepBlue.json (skin, color only)
{
  "palette":  { "primary": "#0B3D91", "secondary": "#5A8DEE" },
  "semantic": { "success": "{palette.green.500}", "error": "{palette.red.500}" }
}

// Industry-Finance.json (muscle, content/structure only)
{
  "blocks":   ["hero.assets","features.dataTable","compliance.badges"],
  "glossary": { "subscribe": "申購", "redeem": "贖回" }
}

Merge precedence (each layer overrides the previous):

Style → Color (palette) → Client brand color → Semantic alias

In other words: the client’s brand HEX overrides the default palette, but semantic tokens (success, error) stay as alias references — don’t let them get directly overridden by brand color, or your status indicators will break.

Step 2: Define Industry Patterns

List each industry’s content blocks and terminology.

For example, Industry-Finance.json defines:

• Hero block structure
• Data table block structure, field semantics, and data display requirements
• Terminology glossary

Don’t define colors inside Industry Patterns.

Step 3: Build a Composer

Write a simple script (or Figma Plugin) that combines the three layers.

Input:

• Style: Minimal
• Color: Brand-HEX-#123456
• Industry: Healthcare

Output:

• Complete Design Token JSON
• Figma component link
• CSS Variables (note: Figma doesn’t export CSS Variables directly — you need a Figma plugin, the Variables REST API, or a build script like Style Dictionary)

Don’t aim for perfection in v1. But it will already be usable.

---

Preset or Platform

The ultimate goal of a Design System isn’t “offer more Presets.”

It’s “let clients compose for themselves.”

Platform here isn’t a marketing term. It means three specific things:

1. Composable: Style / Color / Industry are independent — clients mix and match freely
2. Verifiable: input a brand color and the system automatically runs WCAG contrast checks and semantic token consistency
3. Reproducible: given the same input, the system regenerates the Figma file and CSS Variables at any time — not a snapshot from a manual copy

When these three things are in place, you’re no longer selling Presets.

You’re selling a Platform.

Clients input their brand colors. Choose their industry patterns. Pick their visual style.

The system generates a complete Design System.

That’s what scaling a Design System actually looks like.

Layering doesn’t fragment the system — it hands the choices back.

Is your Design System selling Presets, or selling a Platform?

---

Sources

• Design Tokens W3C Community Group: Format Module — Official draft spec for Design Token format and layer composition
• Brad Frost: Atomic Design — Classic reference for layered thinking in Design Systems (atoms / molecules / organisms / templates)
• Nathan Curtis: Naming Tokens in Design Systems — Practical discussion of token layering and semantic alias precedence
• Figma: Variables and Modes — Figma Variables storage and token application (pending editor confirmation on latest doc URL)
• Style Dictionary — Build pipeline tool for exporting design tokens as CSS Variables, iOS, and Android formats