Design Systems for Marketing Sites That Are Not Product Apps

Product design systems optimize for screens that repeat forever: dashboards, settings, tables, forms. Marketing sites optimize for scenes that earn attention once and route a decision. Copy a product UI kit onto a brand homepage and you get a dashboard wearing a logo. A marketing-site design system is smaller, stricter about composition, and honest about what editors will touch. It exists to raise launch velocity — new campaign pages in hours, not a new art direction every Friday — while the site still reads as one brand film. This spoke sits under Websites That Feel Like Films.

The short answer

• Tokens first: color, type, space, radius. Few, semantic, named so a stranger can apply them.
• Type and composition before components. A weak type scale cannot be rescued by a button library.
• A short inventory: nav, hero, media plate, proof, section intro, CTA, FAQ, form, footer.
• CMS field limits and image rules are system, not afterthought. Editors are users of the kit.
• Grow from production. Ship a thin vertical on the homepage plus one interior template. Add a primitive only when a second page needs it.

If a token or component does not show up in the next three builds, delete it or demote it to a sketch. Dead documentation trains teams to ignore the living rules.

What is a marketing site design system?

A marketing design system is a governed set of tokens, type rules, layout primitives, components, motion budgets, and content constraints that keep every page reading as one brand. It is not a 400-component Storybook of every button variant ever imagined. It is the minimum vocabulary that prevents drift while still letting a homepage feel authored.

I treat systems as production tools. Hundreds of production sites taught the same lesson: the kit that ships is the kit people use. The kit that waits for completeness becomes a PDF in Drive.

Layer	Job on a marketing site	Usually skip
Primitive tokens	Raw palette, font families, base space unit	Mood-board poetry names
Semantic tokens	bg-canvas, text-primary, accent-cta	Page-specific hex in components
Type + composition	Display / body / UI roles, line length, fold jobs	Desktop sizes shrunk until they fit
Components	Nav, hero, plate, proof, CTA, FAQ, form, footer	Data tables, admin chrome, wizards
Motion	Duration steps, easing, reduced-motion policy	Parallax on every section
Content constraints	Headline caps, required alt, one primary CTA	Optional badge fields 1–8
Image / LCP rules	Hero and work-plate sizes, fetch priority	“We’ll compress it later”

What belongs, as a checklist:

• Color, type, space, radius, and elevation tokens
• Grid and section rhythm rules
• A short component inventory with hard edges
• Motion timing and a reduced-motion policy
• Content field limits for CMS-driven pages
• Image and LCP rules for hero and work plates
• A named human who can reject a Friday one-off

What usually does not belong: dense data tables, multi-step wizards, admin chrome, and infinite variant trees “for flexibility.” Flexibility is how brand sites turn into product shells.

Why do product UI kits fail on brand homepages?

Product kits optimize consistency across dense UI. Marketing systems optimize recognizability and conversion across sparse scenes. Density is the enemy of cinema. A product button matrix with twenty sizes is a gift to an app team and a curse to a brand homepage.

Product-kit habit	What it does on a marketing fold	Do this instead
Twenty button sizes	The fold looks like a settings panel	One primary CTA, one quiet secondary
Card as default atom	Every section becomes a card grid	Plates, rules, and space
Sidebar / app chrome metaphor	Brand reads as software, not a world	Full-bleed scenes, one job per section
Infinite variants	Editors pick the wrong one	Locked structure, few exposed fields
“Just in case” tokens	80 greys, 12 accents, nobody knows the pair	One accent for action, a short neutral ramp

The failure mode I see most: a company already has a product design system, so marketing inherits it to “stay consistent.” Consistency of hex is useful. Consistency of interaction model is not. Shared brand DNA, separate layout models. Do not force the marketing site to inherit the product sidebar. Do not force the product to inherit the marketing film hero.

If you remove the nav and the first screen could belong to another company — or to your own admin app — the system optimized for the wrong surface.

Which design tokens belong on a brand website?

Tokens are the contract between taste and implementation. Keep them boring and few. Brand sites fail when every page invents a new cream, a new “almost black,” and a new shadow stack.

The Design Tokens Community Group Format Module 2025.10 is the vendor-neutral JSON format for exchanging those decisions. It is a W3C Community Group final report, not a W3C Standard — useful as an interchange contract, not a religion. The 28 October 2025 announcement is the dated source for that stable cut. Use it when Figma, code, and a page builder need the same names. Do not wait to “finish the spec integration” before shipping a homepage.

Token layer	Example names	Who consumes it
Primitive	ink-900, space-4, font-display	Token file, Figma primitives collection
Semantic	bg-canvas, text-primary, accent-cta, border-quiet	Components and pages
Component (rare)	hero-scrim, nav-blur	One component, only if semantics would rot

Rules I enforce on brand tokens:

1. One primary accent used for action, not decoration.
2. Neutrals that cover text hierarchy without six nearly identical greys.
3. Space scale that fits section rhythm — tight inside components, generous between scenes.
4. No token for “marketing purple gradient #3” unless the brand actually owns that look.
5. Contrast pairs stored as pairs, not as orphan swatches. WCAG 2.2 SC 1.4.3 requires 4.5:1 for body text and 3:1 for large text. If text-quiet on bg-canvas fails, it is not a token. It is a bug.

Tokens for brand websites also encode performance taste. If your type scale assumes a display face at 96px on every breakpoint, you have also assumed font-loading cost and line-length failure. Pair tokens with loading strategy: which faces are critical, which are optional, what falls back when webfonts are late.

In Figma, variables are how those tokens live in the file. Figma’s design-token guide and the variables help article describe primitives, aliases, collections, and modes. Alias semantics to primitives. Do not bind a homepage rectangle to a raw hex that exists nowhere else.

On the web, those values become CSS custom properties. Style Dictionary is the usual transform when one JSON file must emit CSS, iOS, and docs. Marketing sites often only need CSS. That is fine. Do not stand up a multi-platform pipeline to theme a five-page brand site.

How should token layers be named so editors survive?

Avoid poetry in token names. sunset-blush is a mood-board label. accent-warm or brand-secondary is operable. When marketing asks for a “campaign red,” either map it to an existing semantic or create a time-boxed campaign token set that dies with the campaign. Permanent token sprawl is how systems rot.

Bad name	Why it fails	Better name
sunset-blush	Mood, not role	accent-warm
homepage-hero-cream	Page-locked	bg-canvas or bg-hero
grey-3-new	Versioned sludge	text-secondary
btn-blue-2	Component + color mashed	accent-cta on a button
shadow-fancy	Taste without a job	elevation-1

Naming procedure I use on a new brand site:

1. List the roles the pages actually have: canvas, ink, quiet text, accent, border, overlay.
2. Map each role to one primitive. No role gets two primitives “for options.”
3. Publish the same names in Figma variables, CSS custom properties, and the page-builder variable panel.
4. Write a one-page reference with swatches and do / don’t pairs. Not a 40-page PDF.
5. When a campaign needs a temporary color, prefix campaign- and give it an end date.

Document tokens where builders look: code, Figma variables, and that one-page reference. A PDF that ships once and disappears into Drive is not documentation. It is debris.

Webflow’s Variables panel is the same idea inside the builder: store color, size, font, and (when needed) clamp() / calc() once, apply everywhere. Using a design system in Webflow is the vendor’s own map — variables, classes, components, templates, Libraries. Match your semantic names there. Do not invent a second vocabulary because the panel UI tempts you.

Why do type and composition come before components?

Marketing sites are type and image systems first. Components are packaging. If the type scale is weak, no button library will save the brand.

Role	Use	Do not use for
Display	Brand and scene titles	Body paragraphs, form labels
Body	Proof, FAQ, captions	Nav, buttons
UI	Nav, forms, chips	Hero headlines

Type rules that hold:

• Line length that keeps body readable on desktop without becoming a newspaper column farm.
• Mobile sizes designed as compositions, not desktop sizes shrunk until they fit.
• Hierarchy that survives removing color — contrast and size, not “the accent makes it a heading.”
• Display faces loaded as critical only if the fold actually uses them. A display font that appears first in the footer is a waste of LCP budget.

Composition rules from the film model apply here: one job per section, one dominant visual plane on the fold, brand as a hero-level signal. The system should make the wrong composition harder. A hero component that accepts one headline, one support line, one primary CTA, and one media slot will outlive a hero that exposes twelve optional promo chips.

Fold checklist the type system must enforce:

• Brand mark large enough to own the frame
• One headline with a point of view
• One supporting sentence
• One primary CTA
• One dominant visual plane
• No badge cluster, stats strip, or logo landfill on the fold

If the type tokens allow a 400-character display line, you have already lost the fold. Cap the field. The type scale and the CMS are the same system.

How small should the component inventory be?

Build fewer components with clearer jobs. Prefer ten sharp components over eighty half-used ones.

Component	Job	Hard edge
Nav	Wayfinding without competing with the fold	No promo banners inside the bar
Hero / title card	Brand + offer + one action	One headline, one support, one primary CTA, one media slot
Media plate	Show work or world without card sludge	Fixed aspect, required alt, no nested cards
Proof strip	One specific proof	One line or one named receipt — not five logo blobs
Section intro	Headline + one support sentence	No third “optional eyebrow + badge + kicker” stack
CTA band	Single next step	One filled button
FAQ	Answer buyer questions	Question + answer. No chat widget
Form	Capture intent	Minimal fields, visible labels, visible errors
Footer	Legal, lanes, contact	Quiet. Not a second homepage

Cards are allowed when they are the interaction surface — pricing tier selection, project filters. Decorative cards that only add border, shadow, and radius are usually noise. The system should prefer plates, rules, and space over nested boxes.

When to add a new component:

1. Two or more shipping pages need the same structure.
2. Styling it ad hoc would create drift.
3. You can name the job in one sentence.
4. You can list the fields an editor is allowed to change.

One-off campaign art can stay one-off without becoming a system citizen. A winter film still is not a HolidayHeroV3 component.

Framer teams: keep variants short. Framer’s component-library guidance is explicit about naming, breakpoint variants (Desktop / Tablet / Phone), and a single library source. Resist the urge to duplicate slightly different heroes on every page. That is how a five-page site grows twelve hero components and zero system.

What states must every marketing component ship?

Marketing teams often skip focus styles because “it looks cleaner.” That is how accessibility debt and keyboard failure ship. Focus styles are part of the brand system, not a compliance sticker.

WCAG 2.2 SC 2.4.7 Focus Visible requires a visible keyboard focus indicator. If your reset sets outline: none and you do not replace it, the system failed before the first page shipped.

State	Required on	Failure if missing
Default	All	—
Hover	Pointer targets	Dead-feeling UI, but not the worst miss
Focus-visible	Links, buttons, inputs, nav	Keyboard users cannot operate the page
Active / pressed	Buttons, toggles	No feedback on tap
Disabled	Forms only, rarely	Fake disabled CTAs that still look clickable
Loading	Forms, async buttons	Double submits
Error	Inputs, forms	Silent failure, abandoned forms

State checklist for the marketing kit:

• :focus-visible styles use a brand token, not the browser default you then hide
• Focus contrast meets non-text contrast against adjacent colors
• Hover is never the only way to learn something (mobile has no hover)
• Error text is text, not color alone
• Disabled primary CTAs are rare; prefer enabling the button when the form is valid

If a component cannot show these states, it is not ready to be a system citizen. Ship fewer components that are finished.

How do content constraints become the system?

If the CMS allows a 400-character headline and five optional badge fields, the design system has already lost. Field limits, required alt text, image aspect guidance, and “one primary CTA” rules belong next to the components. Editors are part of the system whether you invite them or not.

This is the same honesty as CMS Choices Clients Will Actually Use: pick the tool by who edits on a Tuesday, then cap fields like you mean it. A beautiful Figma kit with an unlocked page builder is a costume.

Field	Cap I actually use	Why
Hero headline	~60–80 characters	Display type + mobile fold
Support line	~120–160 characters	One breath, not a paragraph
Primary CTA label	~24 characters	Buttons are not headlines
Work caption	~140 characters	Plates, not essays
Alt text	Required, descriptive	Empty alt on a hero is a defect
Image	Aspect + max weight in help text	LCP and layout shift
Badge / eyebrow	Zero or one, optional	Optional × 8 is a junk drawer

Train with examples: good fold copy, bad fold copy, good work caption, bad work caption. Systems without editorial taste still produce on-brand chaos — just prettier chaos.

Editor-facing checklist:

• Help text on every field that can break layout
• Preview before publish
• Editor role cannot invent new components
• Image size written into the field (“2400×1600, keep it lean”)
• A one-page cheat sheet, recorded once

Tools alone will not save an unlocked page builder. Lock structure, then train.

How do you treat motion as a system, not a playground?

Motion tokens: duration steps, easing families, and a hard rule that entrance motion never hides meaning. Reduced-motion users get the final composition immediately. Scroll-driven scenes are budgeted, not sprinkled.

The system layer only needs three decisions: what is allowed, what is forbidden, who can approve exceptions. Production motion detail is a different problem. This post is the contract those scenes must honor.

Token	Example	Rule
duration-sm	150–200ms	UI feedback, hover, focus
duration-md	300–400ms	Scene entrance
duration-lg	600ms max on marketing	If you need longer, you need a reason
ease-standard	One shared curve	Do not invent a new ease per section
motion-allowed	Transform + opacity	Avoid layout-thrashing properties on the fold

MDN’s prefers-reduced-motion is how the browser reports the OS setting. WCAG technique C39 is the documented way to suppress interaction-triggered motion when that preference is reduce. The preference value is reduce, not “none.” Essential motion that conveys meaning can stay. Decorative entrance choreography should not.

Forbidden by default on marketing systems I ship:

• Parallax on every section
• Autoplaying sound
• Long loader choreography before first paint of the offer
• Hover-only information that mobile users never see
• Scroll-jacking that steals the scrollbar

Motion checklist:

• Meaning is visible with motion disabled
• Fold LCP node is not waiting on a timeline
• Reduced-motion path is the final composition, not a broken half-state
• Exceptions go through the system owner, not a Friday experiment

Bravery is not a motion strategy. A budget is.

Should marketing and product share one design system?

Share brand primitives. Split components and layout models.

Share	Split
Color primitives and type families	Navigation chrome
Logo and wordmark rules	Density and spacing rhythm
Accessibility contrast pairs	Data tables, filters, app shells
Voice in microcopy, at a high level	Form complexity and wizard patterns
Legal footer fragments	Hero / title-card composition

When a company has both product and marketing surfaces, the cheap mistake is one Storybook to rule them all. The expensive mistake is two unrelated brands. The workable path is one token file for DNA, two component libraries for jobs.

Decision list:

1. If the marketing fold starts looking like a dashboard, you shared too much component.
2. If the product settings page starts using the film hero, you shared too much layout.
3. If hex values diverge by “close enough,” you shared too little token.
4. If both surfaces need a campaign accent, give it a campaign namespace and a kill date.

Marketing folds and product shells solve different jobs. Pretending otherwise is how you ship a homepage that feels like Jira with better kerning.

How do you implement the same system across stacks?

The system is the same idea on every stack: fewer decisions at build time, clearer decisions at edit time. Stack chooser detail lives in Framer vs Webflow vs custom. This post is the craft contract those stacks must honor.

Stack	Token home	Component home	Watch-out
Custom (Astro / React / etc.)	CSS variables or a typed token package	Colocated components; Storybook only if it earns its keep	Token file drifts from Figma if nobody owns the sync
Webflow	Native variables, same semantic names	Webflow components with locked structure; CMS fields capped	Designer-role editors invent combo classes
Framer	Shared styles + a short variable set	Variants kept short; library as source	Slightly different heroes duplicated per page

Implementation order that actually ships:

1. Tokens in one place (Figma variables + CSS or builder variables).
2. Type scale and space scale on a style-guide page that is a real route, not a screenshot.
3. Hero, CTA, section intro, footer — used on the homepage.
4. One interior template (work, service, or article).
5. CMS field caps that match the component props.
6. Only then: extra components the second template proves it needs.

Storybook is optional. A live style-guide route that uses production components is not. Documentation that does not match production trains people to ignore both.

Custom stacks: Style Dictionary earns its keep when you have more than one output target or you want DTCG JSON as the source. For a single marketing site, a hand-maintained :root of custom properties is often enough. Do not build a token platform to avoid writing twenty CSS variables.

Who owns the system without adding bureaucracy?

Someone must own the system. On studio builds, that is usually the design lead plus the implementer. On client teams, name a human: brand owner or marketing ops. Change process can be light. What fails is “anyone can invent a new component in the page builder on Friday.”

Change	Path	Who says yes
Copy inside a locked field	Edit, preview, publish	Editor
New image in an existing plate	Swap, check aspect and alt	Editor
New semantic token	Propose, show on staging, merge	Owner
New component	Two-page rule, then add	Owner + implementer
Campaign one-off	Time-boxed, not added to the kit	Owner
Global CTA restyle	Version note, staging, then ship	Owner

Version the system the way you version releases. When you change space scale or CTA styles sitewide, say so. Silent global changes train stakeholders to fear the system.

Governance checklist that stays light:

• Named owner in the kickoff doc, not “the team”
• Propose on a PR or a staging page — not a Slack screenshot
• Deprecate the old path; do not leave two accents “for now”
• Campaign tokens have an end date
• Style-guide page updated in the same change as production

Bureaucracy is a weekly committee. Ownership is one person who can say no to a seventh grey.

What fails when the system is optional?

This is the failure mode. A mid-engagement brand has a handsome homepage and three inner pages that look like cousins, not siblings. Buttons differ by a few pixels. Section padding wanders. A freelancer added a teal that is “close” to the accent. Sales wants a banner. Someone ships a card grid because the template had one.

Cost, even without invented metrics:

• New pages take days because every section is a negotiation.
• Editors break the fold because the CMS will accept anything.
• Visual QA after three months is a scavenger hunt.
• The next redesign starts from entropy, so you pay to rediscover decisions you already made.

What I do instead:

1. Audit the pages that already work. Extract tokens from those, not from a competitor mood board.
2. Define the short inventory and lock it.
3. Cap CMS fields to the component contract.
4. Delete the teal. Map or kill campaign colors.
5. Put the style-guide route in the nav for the team, even if it is noindexed.

The fix is not another homepage redesign. The fix is recipes. After recipes exist, new pages take hours instead of days, and the site starts feeling intentional again — the same authorship goal as Websites That Feel Like Films.

If every new page needs custom CSS to “make it special,” the system is incomplete or the culture is rejecting it. Fix the gap or the culture. Do not paper over with more exceptions.

How do you roll out a system without pausing launch?

Do not pause a launch for six months to “finish the system.” Ship a thin vertical. Systems grown from production stay honest. Systems grown from speculation invent ghosts.

Phase	Ship	Do not ship yet
1 — Thin vertical	Tokens, type, hero, CTA, section intro, footer	Full Storybook, every future template
2 — First interior	Work or service template using the same primitives	A second hero “for this page’s vibe”
3 — Editor path	CMS caps, help text, cheat sheet	Open Designer access for every stakeholder
4 — Expand	New primitive only when a second template needs it	Speculative components
5 — Maintain	PRs for token changes, version notes	Silent Figma drift

Rollout procedure:

1. Pick the homepage and one interior URL as the proving ground.
2. Extract tokens from the best existing work if this is a redesign.
3. Implement tokens in Figma and in the stack’s variable layer the same week.
4. Lock the hero and CTA. Refuse optional promo chips.
5. Launch. Expand when a real page blocks on a missing primitive.

When redesigning an existing site, codify what already works, then delete the rest. A competitor mood board is research. It is not a token source.

Launch-week checklist:

• Style-guide route uses production components
• Homepage and one interior share tokens without overrides
• CMS fields match component props
• Focus-visible and contrast pairs checked on the real fold
• Reduced-motion path checked on the real fold
• Owner named for post-launch exceptions

A system that exists only in Figma is a mood board with extra panels.

How do you measure whether the system works?

Component count is a vanity metric. A kit with 80 components and a three-day page build is a failed kit.

Proxy	Healthy signal	Sick signal
Time to a new campaign page	Hours, existing components	Days, new CSS, new one-offs
Editor error rate	Rare broken layouts, alt present	Oversized headlines, missing media, mystery gaps
Visual QA after three months	Pages still read as siblings	Cousins, then strangers
Fold job	Still one job, one CTA	Badge sludge returned
Exception log	Few, dated, retired	A graveyard of “just this once”

Measurement checklist:

• Log every new component request. If it fails the two-page rule, reject it.
• Once a quarter, screenshot the homepage against two interiors. Drift is visible or it is not.
• Ask the editor how long the last update took. If the answer is “I emailed you,” the CMS part of the system failed.
• Check whether campaign tokens from last quarter still exist. If yes and the campaign is dead, the kit is rotting.

Document before/after with screenshots for stakeholders. Systems sell better when people can see entropy called out concretely. Then maintain the kit like product code: pull requests for token changes, not silent Figma drift.

Explore the websites lane at /websites when you want this kit built as part of the site, not as a side project that never ships.

Where do performance and accessibility live in the kit?

A marketing design system that ignores LCP, focus, and contrast is incomplete. Image aspect tokens, font-loading rules, and focus styles belong in the same kit as color. Cinema-grade brand work that fails keyboard users or arrives late on mobile is unfinished craft.

Largest Contentful Paint is the Core Web Vital for when the main content likely rendered. On a marketing homepage the LCP node is usually the hero image or the display headline. The system should make the wrong LCP hard:

Rule	Why it is a system rule
Hero image has a defined aspect and a sized source	Stops layout shift and mystery downloads
Display font is critical only if it is the LCP text	Stops a decorative face from blocking the fold
Motion does not hide the LCP node	A 1.2s title reveal is a conversion bug
Work plates reuse the same aspect tokens	Editors cannot upload a 9:16 into a 16:9 slot without a crop rule

Accessibility rules that are tokens, not posters:

• Contrast pairs validated against SC 1.4.3 before they enter the palette.
• Focus indicator as a first-class token, per SC 2.4.7.
• Reduced-motion path as a first-class motion token, per C39 and prefers-reduced-motion.

Keep the system as the place those rules are enforced by default. A separate “a11y phase” after launch is how you ship a beautiful fold that keyboard users cannot use.

Which anti-patterns should you delete on sight?

I delete these when I find them. Not “deprecate.” Delete.

• Token files with 80 greys and 12 accents “for flexibility”
• Hero components with optional everything
• Card grids as the default for every content type
• Shadows as personality
• Documentation screenshots that do not match production
• Design-system pages that are prettier than the marketing site they claim to serve
• outline: none without a replacement focus style
• Campaign colors that outlived the campaign
• A second type scale “just for the blog”
• Product-app sidebar patterns copied onto the brand homepage
• Hover-only captions on work plates
• Uncapped CMS headlines
• Storybook as a substitute for a live style-guide route
• “We’ll add tokens after launch”

If an anti-pattern is load-bearing for one week of a campaign, isolate it. Do not promote it into the kit. Promotion is how exceptions become the system.

The system’s job is launch velocity with authorship. Anything that slows the next page or dilutes the brand is not a feature. It is weight.

FAQ

What belongs in a marketing site design system?

Tokens, type and space rules, a short component list, motion budgets, CMS field limits, and image/LCP guidance. Skip dense product UI patterns unless the marketing site truly needs them. If a piece will not appear on the next three builds, it does not belong in the kit yet.

How are design tokens for brand websites different from product tokens?

Brand tokens emphasize semantic roles for scenes and CTAs, fewer variants, and pairing with media and performance rules. Product tokens often expand for dense UI states and data density. Share primitives. Do not share the whole matrix.

Should we use the same system for app and marketing site?

Share brand primitives — color and type families. Split components and layout models. Marketing folds and product shells solve different jobs, and forcing one Storybook onto both is how the homepage starts looking like settings.

How big should the component library be?

Small enough that every component has a real job on shipping pages. Prefer ten sharp components over eighty half-used ones. Add a component when two or more pages need the same structure and styling it ad hoc would create drift.

When do we add a new component?

When two or more pages need the same structure and styling it ad hoc would create drift. One-off campaign art can stay one-off without becoming a system citizen. If you cannot name the job in one sentence, it is not a component yet.

How do we stop editors from breaking the system?

Lock structure in components, limit CMS fields, train with examples, and name an owner who reviews exceptions. Tools alone will not save an unlocked page builder. Preview before publish is part of that lock, not a luxury.

CTA

Want a marketing-site system that raises launch velocity without turning the brand into a product kit? Start at /websites or book a sprint at /contact?intent=websites-sprint.