/marketing-vs-product-system

name: marketing-vs-product-system
description: A marketing site and the product it sells share a brand but not a design system. The surfaces differ in density, type scale, radius and weight for good reasons, and those differences are legitimate, but the token layer underneath them must stay single. The same rule covers the other surfaces a brand runs, including documentation, transactional email and a status page. Use when a product app and its public site drift apart, when deciding which values may differ between surfaces, when a signed-in surface needs a theme the marketing site does not have, when a component renders in both, when unifying a token layer that has already forked, or when deciding who owns it.
metadata:
  priority: 6
  pathPatterns:
    - "app/**"
    - "src/app/**"
    - "components/**"
    - "src/components/**"
    - "**/*.css"
    - "**/*.tsx"
    - "**/*.jsx"
    - "design-system/**"
  promptSignals:
    phrases:
      - "marketing site"
      - "landing page vs app"
      - "product UI"
      - "signed-in"
      - "logged-in area"
      - "same brand different"
      - "design system drift"
      - "app feels different"
      - "dashboard vs homepage"
      - "one codebase two surfaces"
      - "shared header"
      - "who owns the design system"
      - "token source of truth"
      - "design tokens package"
retrieval:
  aliases:
    - marketing vs app
    - site vs product
    - landing page vs dashboard
    - public vs signed-in
    - brand vs product UI
    - two surfaces one brand
    - who owns the tokens
    - shared component across site and app
  intents:
    - decide what may differ between the marketing site and the app
    - stop the product UI drifting from the brand
    - audit a codebase that renders both a site and a product
    - add a theme to the app but not the site
    - unify tokens across two surfaces
    - share tokens across separate repositories
    - decide who owns the token source
  examples:
    - the app doesn't look like our website
    - can the dashboard use tighter corners than the landing page
    - we have three different ways of writing colours
    - should the app support light mode if the site doesn't
    - our marketing pages and product have drifted
    - the header is duplicated in both codebases
    - nobody owns our design tokens

Marketing and Product Are Two Surfaces of One Brand

The public site sells; the product is used. A visitor reads one marketing page for ninety seconds and leaves. An operator opens the same brand every morning and stays for hours. Designing both to one specification produces either a brochure that is exhausting to work in or a product screen that cannot sell anything.

So the two surfaces *should* diverge. The question is never whether, it is **which layer is allowed to diverge**.

Marketing and product are the pair that forces the question, because they are the two nobody can pretend are the same job. But the rule underneath is not about two. Most brands run four or five surfaces: the site, the product, the documentation, the transactional email, the status page, sometimes a sales deck. Each one is a different job for a different reader at a different moment. **The brand owns the layer; every surface chooses from it.** Adding a sixth surface then changes nothing about the rule, which is the test of whether the rule was right.

Where a new surface belongs is settled by the same question the layer rule asks, not by which team built it. Docs are read for minutes at a time by someone mid-task, so they sit near the product on density and near the site on reading width. Transactional email has no theme control and no hover, so it takes the shared values and little else. Neither is a special case; both are the general rule applied.

The Layer Rule

**Brand values are shared. Application values are chosen per surface.**

| Shared, one value for both | Chosen per surface | |---|---| | Hue: brand accent, warm accent, status colours | Which of them dominates a screen | | Font families | Type scale in use | | Radius *scale* (the set of allowed steps) | Which step a surface reaches for | | Icon library | Icon size and weight | | Contrast floors for text (4.5:1 body, 3:1 large) | Density, spacing rhythm | | Component contracts (what a button is) | Button size defaults |

If a value answers *who are we*, it is shared. If it answers *what is this screen for*, it is the surface's own call. A product screen picking a tighter radius is design. A product screen picking a different blue is drift.

What Legitimately Differs

These divergences are healthy and worth stating explicitly rather than letting them happen by accident:

• **Type scale.** Marketing lives in the display registers and has real hero sizes. Product lives two or three

steps down, with the small end of the scale carrying most of the interface. The scale is the same ladder; the two surfaces stand on different rungs.

• **Weight.** Marketing leans bold, because a headline is competing for attention. Product leans medium and

semibold, because everything on screen is already wanted.

• **Radius.** Marketing can afford larger, softer cards: few elements, lots of air. Product goes tighter, because

at high density large radii eat the corners of adjacent elements and read as mushy. Between them the two surfaces may well use five or six steps, and that is not a broken scale as long as every step is drawn from the same ladder. What breaks it is a value that is on no ladder at all.

• **Density and width.** Marketing measures a reading column, because the limit is what an eye tracks across a

line of prose. Product measures a work area, because the limit is the data, and the data does not get narrower on a wider screen. That is also why the width belongs to the shell rather than the page: a product where each page picks its own column is a product where the content jumps sideways on every navigation.

• **Motion.** Marketing may a