Lunora Design

2.10 Marketing Surfaces (landing, docs hub, product pages)

Sections 2.1–2.9 assume a product screen. Marketing surfaces carry the same voice with three additional structures. They are not decoration; each one is load-bearing, and half-applying them is what makes a page read as generic.

Page header. A full-bleed saturated colour field with a dark panel set into its lower-left, overhanging the field's bottom edge. The overhang is the composition — a panel that sits neatly inside the band reads as a banner with a box on it. Build it by pulling the panel up with a negative margin while it stays in normal flow, never by positioning it absolutely: in flow the panel's own height sets the overhang and the following content is pushed down for free, where absolute positioning needs a spacer kept in sync by hand with a height that changes per breakpoint and per content.

The field is one brand colour with depth, not three in equal measure. Violet carries it; cyan and rose are edge blooms for dimension. An even three-way split reads as a stock mesh gradient and belongs to no brand. Punch a canvas-coloured halftone dot matrix through it (≈9px grid) so it resolves from cells rather than blurring.

The navbar sits over this field. Aurora accents are mid-lightness, so dark ink on them fails contrast — keep light ink and guarantee it with a top scrim gradient rather than flipping the nav to dark.

Numbered sections. Each band opens with an index stacked over a category label (01 / FRAMEWORK) in the left column, title and lead beside it. The label says what kind of section it is, which the title rarely does. Index in accent, label in faint grey.

Hairline grid. Cells separated by real 1px lines, not whitespace: the container paints the hairline colour and a 1px gap lets it through between opaque cells. Two consequences that bite:

• cells must stay opaque — a translucent cell shows the hairline across its whole face instead of only at the seams;
• a cell must be the grid's direct child — wrap one in a transparent reveal animation and the wrapper becomes the grid item, with the same result.

Type scale for marketing. The 3-sizes-per-screen budget in 2.2 governs product screens. Marketing surfaces use the published scale, capped so headings stop growing on wide monitors while gutters stay fluid:

Negative tracking on display type is not optional. Large text set at default tracking is the single clearest tell of an untuned page.

Vary the layout family. A landing page that uses the hairline grid for four consecutive bands reads monotonous however good each band is. Rotate: hairline grid, rule-topped columns, a real table, a disclosure list, a full-bleed panel. No family twice in a row.

3. ANTI-PATTERNS — WHAT TO NEVER DO

• No gradients in UI chrome — the one exception is the aurora ribbon on the focal accent (hero clause, active underline, focus ring)
• No shadows. Depth = value step + one hairline. One atmospheric aurora glow per view max (soft radial behind a hero) — never on buttons.
• No skeleton loading screens. Use [LOADING...] text or segmented spinner.
• No toast popups. Use inline status text: [SAVED], [ERROR: ...]
• No sad-face illustrations, cute mascots, or multi-paragraph empty states
• No zebra striping in tables
• No filled icons, multi-color icons, or emoji as UI
• No parallax, scroll-jacking, or gratuitous animation
• No spring/bounce easing. Use subtle ease-out only.
• Sharp corners (rounded-none) on structural chrome — nav, console, buttons, cards, panels. Small radii (4–8px) only inside dense data (badges, table cells, chips). Never rounded glassy cards.
• Data visualization: differentiate with opacity (100%/60%/30%) or pattern (solid/striped/dotted) before introducing color.

3.1 IMPLEMENTATION TRAPS — THINGS THAT FAIL SILENTLY

These do not throw, do not fail a type check, and do not fail a lint. They ship a page that looks subtly wrong for reasons no one can point at.

tailwind-merge eats named type-scale utilities. When the scale is named (text-h2, text-blurb) rather than sized (text-lg), tailwind-merge cannot distinguish it from a colour utility. It sees cn("text-h3", "text-ink"), assumes both are text colours, resolves the "conflict" in favour of the last one, and drops the size. Headings then render at the browser default while the class list still looks right in the source.

This is not hypothetical: it shipped, and every h3 on a landing page rendered at 16px instead of 23px until it was measured.

Register the names as a font-size group, once, where cn is defined:

const twMerge = extendTailwindMerge({
    extend: {
        classGroups: {
            "font-size": [{ text: ["display", "h1", "h2", "h3", "body", "blurb", "kicker", "micro"] }],
        },
    },
});

Any token added to --text-* must be added here too. Verify with a direct assertion (twMerge("text-h3", "text-ink") must keep both) rather than trusting that it looks fine.

@theme vs @theme inline. Tokens declared in a plain @theme block are inlined at build time, so a runtime theme swap or a [data-theme] override does nothing. Use @theme inline when the value references another custom property, so utilities compile to var(--…).

Tailwind namespace names are not free-form. --container-shell produces max-w-shell, not max-w-container-shell. Check the generated utility exists before building a layout on it; a missing utility is simply no styling, not an error.

Verify the rendered page, not the source. Every trap above is invisible in the JSX and obvious in getComputedStyle. Before calling a surface done, read back the computed font sizes, line heights, and tracking of h1/h2/h3/body and compare them to the table in 2.10.

4. WORKFLOW

1. Declare fonts — tell the user which fonts to load (see references/tokens.md)
2. Ask mode — dark or light? Neither is default.
3. Sketch hierarchy — identify the 3 layers before writing any code
4. Compose — apply craft rules (Sections 2.1–2.10; 2.10 for marketing surfaces)
5. Check tokens — consult references/tokens.md for exact values
6. Build components — consult references/components.md for patterns
7. Adapt to platform — consult references/platform-mapping.md for output conventions
8. Measure the result — read back computed type and the chromatic ratio (2.5, 2.10). Section 3.1 lists what fails silently; none of it is visible in the source.

5. REFERENCE FILES

For detailed token values, component specs, and platform-specific guidance:

• references/tokens.md — Fonts, type scale, color system (dark + light), spacing scale, radius/surface, motion, iconography, texture motifs
• references/components.md — Cards, buttons, inputs, lists, tables, nav, tags, segmented controls, progress bars, charts, widgets, overlays, state patterns
• references/platform-mapping.md — HTML/CSS, SwiftUI, React/Tailwind, Paper output conventions

Canonical token source. The shipped values live in marketing/design-tokens/ (tokens.css for Tailwind v4, tokens.ts for JS) with intent in marketing/design-tokens/DESIGN.md. Those are authoritative; the references here restate them for the methodology. When generating real code, import the tokens rather than re-typing hex values.

Adapted under the MIT License from the "Nothing Design Skill" by Dominik Martin (https://github.com/dominikmartn/nothing-design-skill). The craft methodology is the original author's; the palette, typeface, corners, and accent rules were reconciled to Lunora's established design language (marketing/design-tokens/DESIGN.md). See LICENSE.