PostHog Design System

Overview

PostHog's visual identity is built around an unexpected warmth—a tan-beige {colors.canvas} background that immediately distinguishes it from the sea of sterile white SaaS dashboards. This is not a neutral container; it's a personality choice that signals approachability, craftsmanship, and a departure from enterprise coldness. The canvas color (#e1d7c2) reads like aged paper or sun-warmed stone, creating an emotional foundation before a single word is read.

Brand voltage lives in two places: the electric {colors.accent-orange} (#f74e00) used for primary CTAs and high-emphasis actions, and the trustworthy {colors.accent-blue} (#2f80fa) deployed for links, informational elements, and secondary interactive surfaces. These two colors form a complementary pair—warm action, cool information—that gives the interface clear visual grammar without resorting to the purple-gradient cliché. A supporting cast of yellows and golds ({colors.accent-yellow}, {colors.accent-gold}) adds celebratory voltage for badges, highlights, and signature moments.

The typography system's defining move is its commitment to bold weights at every level. {typography.display-lg} sits at weight 800—not the delicate 300 you'd expect from a modern landing page. {typography.title-md} hits 700, and even {typography.caption} (used in navigation items) carries weight 500. This creates a confident, almost editorial voice that says "we know what we're building." The typeface itself—IBM Plex Sans Variable—is an open-source IBM face with humanist proportions and excellent readability at the dense sizes favored by developer tools documentation. It carries the gravitas of Helvetica but with more character in the letter terminals.

Shape language is restrained but purposeful: {rounded.sm} (4px) for small interactive elements, {rounded.DEFAULT} (6px) for standard cards and containers, and {rounded.pill} (9999px) exclusively for buttons and badges. This three-tier radius vocabulary keeps things predictable while allowing pills to signal "clickable action" at a glance.

Sub-systems observed include a pricing dialect (featured tier cards with elevated backgrounds), a documentation/code dialect (monospace blocks with {typography.mono} in {typography.mono-source} where available), and a navigation dialect (ghost buttons with hover-state surface reveals).

Key Characteristics

• Canvas is warm tan {colors.canvas} (#e1d7c2), never white—the brand's single most recognizable trait
• Primary CTA uses vibrant {colors.accent-orange} (#f74e00) with {rounded.pill} geometry
• All headings run bold: {typography.display-lg} at weight 800, {typography.title-md} at 700
• Body text in {colors.body} (#374151) at 15px/{typography.body-md} for optimal developer-tool reading
• Links rendered in {colors.link} (#2f80fa) with 150ms cubic-bezier transitions
• Code blocks use {typography.mono} (ui-monospace stack) at 13px on {colors.surface-soft}
• Cards default to {colors.surface-soft} with {rounded.md} (6px) corners
• Shadow elevation is minimal: {extensions.shadows.sm} for dropdowns, {extensions.shadows.md} for modals
• Spacing base unit is 4px; sections breathe with {spacing.section-lg} (48px) vertical rhythm
• Nav maxes at {spacing.nav-width} (1440px); articles constrain to {spacing.article-max} (896px)

Colors

Brand & Accent

• Primary ({colors.primary} — #111827): Near-black used for the darkest headings, primary button backgrounds in secondary contexts, and maximum-contrast text on light surfaces.
• Primary Active ({colors.primary-active} — #030712): Deepest black shade for pressed/active states on dark-themed buttons.
• Primary Hover ({colors.primary-hover} — #1f2937): Slightly lighter than primary for hover states on dark UI elements.
• Accent Blue ({colors.accent-blue} — #2f80fa): The informational/action-cool color—used for all links, "Learn more" CTAs, icon fills in informational contexts, and the PostHog logo's leftmost bar.
• Accent Orange ({colors.accent-orange} — #f74e00): The primary call-to-action color—"Get started free" buttons, pricing highlights, and the PostHog logo's center bar. High-energy, conversion-focused.
• Accent Yellow ({colors.accent-yellow} — #f7a501): Used for badges (like "NEW"), warning-adjacent highlights, and the PostHog logo's right bar.
• Accent Gold ({colors.accent-gold} — #eb9d2a): A warmer gold variant for gradient stops and decorative elements.
• Accent Gold Dark ({colors.accent-gold-dark} — #cd8407): Darker gold for pressed states on yellow/gold buttons or active badge variants.

Surface

• Canvas ({colors.canvas} — #e1d7c2): The iconic warm tan background that defines PostHog's visual identity. Used for the page body, footer bands, and any "full-bleed" atmospheric section.
• Surface Soft ({colors.surface-soft} — #eeefe9): Light cream/off-white for card backgrounds, input fields, and elevated content panels that need to lift slightly from canvas.
• Surface ({colors.surface} — #fdfdf8): Near-white with a hint of warmth—used for featured pricing tiers, modal interiors, and content areas requiring maximum brightness while avoiding sterile #fff.
• Surface Elevated ({colors.surface-elevated} — #e5e7e0): A cool gray-tan for subtle borders, divider lines, and very subtle background differentiation.
• Surface Elevated Fade ({colors.surface-elevated-fade}): Semi-transparent version of elevated for overlays and glass-like treatments.
• Surface White ({colors.surface-white} — #ffffff): Pure white reserved for input fields, code blocks needing max contrast, and cards within already-warm contexts.

Text / Ink

• Ink ({colors.ink} — #4d4f46): The dominant text color—a warm dark olive-gray that harmonizes with the tan canvas rather than fighting it. Used for most body copy, navigation labels, and general UI text.
• Body ({colors.body} — #374151): Standard gray-black for body paragraphs, slightly cooler/darker than ink for enhanced readability in long-form content.
• Body Dark ({colors.body-dark} — #232519): Very dark olive for navigation item text, button labels on ghost variants, and elements that need emphasis without reaching for pure black.
• Heading ({colors.heading} — #111827): The primary heading color—near-black, used for h1-h3 text, card titles, and any text demanding maximum hierarchical weight.
• Heading Deep ({colors.heading-deep} — #1a1a1a): An alternative near-black for specific heading contexts where #111827 feels too cool.
• Muted ({colors.muted} — #65675e): Medium gray for secondary text, timestamps, metadata labels, and placeholder/disabled-adjacent content.
• Muted Light ({colors.muted-light} — #9ea096): Light gray for truly tertiary text—hints, captions beneath form fields, disabled button text.
• On Primary ({colors.on-primary} — #ffffff): White text for rendering on dark primary/accent backgrounds. Satisfies AA contrast against both {colors.primary} and {colors.accent-orange}.
• On Accent Orange ({colors.on-accent-orange} — #ffffff): Explicitly mapped for orange button text—white is the only viable option here.
• On Canvas ({colors.on-canvas} — #4d4f46): Text specifically tuned for the warm canvas background; identical to ink by value, semantically distinct.
• Code Inline ({colors.code-inline} — #374151): Text color within inline code snippets and code blocks—standard readable gray.

Hairlines & Borders

• Hairline ({colors.hairline} — #e5e7e0): The default border/divider color—a cool light gray-tan visible against both canvas and white surfaces.
• Border Subtle ({colors.border-subtle}): Very low-opacity olive for input borders, focus rings, and subtle containment lines. Rendered as rgba(35, 37, 29, 0.12) in source.
• Border Input ({colors.border-input} — #232519): Darker border for focused inputs or emphasized field outlines.

Semantic

• Link ({colors.link} — #2f80fa): Identical to accent blue—all clickable text links render in this color.
• Link Hover ({colors.link-hover} — #1a56b8): Darker blue for the hover/active state on links, providing clear interaction feedback.
• Success ({colors.success} — #059669): Green for confirmation states, success messages, and positive indicators (inferred from semantic convention).
• Error ({colors.error} — #dc2626): Red for validation errors, destructive actions, and failure states (inferred from semantic convention).
• Warning ({colors.warning} — #f7a501): Yellow/orange for caution states, matching the accent yellow family.

Typography

Font Family

PostHog's type system is built entirely on IBM Plex Sans Variable, an open-source typeface from IBM's design language (Carbon). The variable font format allows smooth interpolation across weights 100–700 (with the system pushing into 800 via CSS), enabling crisp rendering at every size. The fallback chain prioritizes system fonts that share IBM Plex's humanist grotesque character: -apple-system, BlinkMacSystemFont, "avenir next", avenir, "segoe ui", "helvetica neue"—ensuring that even if the webfont fails to load, the visual voice remains in the sans-serif humanist family rather than degrading to Arial.

For code and technical content, two monospace stacks exist: the primary {typography.mono} uses ui-monospace, SFMono-Regular, Menlo, Monaco, Consolas (Apple's optimized monospace stack), while {typography.mono-source} pulls in Source Code Pro where explicitly specified. Source Code Pro appears in embedded font-face declarations with data URIs, indicating it's self-hosted for code-highlighting contexts.

Hierarchy

| Token | Size | Weight | Line Height | Letter Spacing | Use | |---|---|---|---|---|---| | {typography.display-xl} | 32px | 800 | 1.25 | -0.02em | Hero headlines (inferred), mega-section titles | | {typography.display-lg} | 24px | 800 | 1.333 | -0.6px | H1 headings, section headlines | | {typography.title-md} | 21.43px | 700 | 1.4 | -0.54px | H2 headings, card titles | | {typography.title-sm} | 19.29px | 600 | 1.556 | -0.48px | H3 headings, sub-section titles | | {typography.label-md} | 14px | 500 | 1.4 | normal | Form labels, field titles | | {typography.body-md} | 15px | 400 | 1.5 | normal | Paragraph text, body copy, descriptions | | {typography.body-sm} | 13.12px | 400 | 1.5 | normal | Small body text, sidebar content, footnotes | | {typography.caption} | 13px | 500 | 1.38 | normal | Nav items, badges, timestamps | | {typography.button} | 13px | 500 | 1 | normal | Button labels, CTA text, small interactive labels | | {typography.mono} | 13px | 400 | 1.5 | normal | Inline code, code blocks, terminal text | | {typography.mono-source} | 13px | 400 | 1.5 | normal | Syntax-highlighted code blocks |

Principles

The weight distribution tells the story: this is a bold-first system. Display text at 800 weight is aggressive for a product tool—most competitors cap at 600–700. This choice signals confidence and ensures headings remain legible even on lower-quality displays or when viewed quickly (as developers scanning docs tend to do). The negative letter-spacing on display and title scales (-0.6px at 24px down to -0.48px at 19.3px) tightens the letterforms for a more "designed" feel at large sizes, counteracting the natural looseness of IBM Plex's open apertures.

Size carries less hierarchical burden than weight does. The gap between {typography.display-lg} (24px) and {typography.title-md} (21.4px) is only 2.6px—barely noticeable—but the weight drops from 800 to 700, creating the level distinction. Similarly, {typography.title-sm} at 600 weight separates from body text without relying on size alone. This is a sophisticated approach: weight does the heavy lifting, size provides fine gradation.

Line heights are generous across the board (1.333–1.556), accommodating developer audiences who may be reading dense API documentation or scanning feature comparisons. The 1.5 line-height on body text (15px → 22.5px effective) exceeds the WCAG recommended minimum for comfortable reading.

No italic or uppercase conventions were detected in the extracted styles. The system trusts to weight, size, and color contrast for all emphasis needs.

Note on Font Substitutes

IBM Plex Sans Variable is available on Google Fonts as "IBM Plex Sans" (the static version). For the variable font capabilities, use the CSS @font-face declaration pointing to Google Fonts' variable-axiswoff2 files, or accept the static subset which covers weights 400, 600, and 700. Define the CSS variable --font-sans: 'IBM Plex Sans', -apple-system, BlinkMacSystemFont, sans-serif.

Source Code Pro is also on Google Fonts. For the monospace stack, define --font-mono: 'Source Code Pro', ui-monospace, SFMono-Regular, Menlo, Consolas, monospace. If Source Code Pro cannot be loaded, the system degrades gracefully to the platform-native monospace stack.

Layout

Spacing System

• Base unit: 4px (derived from the most frequent spacing value in extracted CSS).
• Tokens:
  • {spacing.xxs} (1px): Hairline borders, pixel-perfect dividers
  • {spacing.xs} (2px): Tight internal padding in compact components
  • {spacing.sm} (4px): Icon-text gaps, minimal element spacing
  • {spacing.md} (6px): Small gaps between related elements, list item padding
  • {spacing.base} (8px): Standard gap between sibling elements, form field margins
  • {spacing.lg} (10px): Input internal padding, button internal padding
  • {spacing.xl} (12px): Card internal padding, larger gaps
  • {spacing.2xl} (16px): Section-internal padding, card-to-card gaps
  • {spacing.3xl} (17px): Observed specific value for certain padded elements
  • {spacing.4xl} (20px): Large internal padding
  • {spacing.5xl} (24px): Component group separation
  • {spacing.section} (32px): Vertical section padding (top-level content bands)
  • {spacing.section-lg} (48px): Generous section padding for hero/CTA areas
• Section padding (vertical): {spacing.section-lg} (48px) — used in {component.hero-band} and {component.cta-band} for breathing room.
• Card internal padding: {component.card} uses {spacing.xl} (12px); {component.pricing-card} uses {spacing.section} (32px) for spacious pricing content.
• Gutters: Not explicitly defined in a grid token; the nav constrains to 1440px, articles to 896px—suggesting responsive gutters handled by the framework's container utilities.

Grid & Container

• Max content width: Two constraints observed—{spacing.nav-width} (1440px) for navigation/full-width layouts, {spacing.article-max} (896px) for prose/article content. This dual-constraint pattern suggests a "wide marketing shell, readable content core" approach common in developer-tool sites.
• Editorial vs marketplace density: Article content (docs, blog) runs at 896px for optimal line-length reading (~70–80 characters at 15px). Marketing/landing pages likely use the full 1440px for multi-column feature grids, comparison tables, and hero split-layouts.
• Specific grid behaviors: The extracted CSS shows Tailwind utility classes, implying a 12-column grid under the hood (Tailwind default). No explicit column-count classes were captured in the above-fold snapshot, but the component inventory suggests multi-column pricing grids and feature matrices.
• Hero column splits: Inferred from typical PostHog landing patterns: 50/50 or 45/55 text-to-visual split within the 1440px container, with the text column constrained to ~600px for heading readability.

Whitespace Philosophy

PostHog practices generous-but-purposeful whitespace. The warm canvas color naturally encourages breathing room—you don't crowd a textured surface the way you do pure white. Section vertical padding at 48px ({spacing.section-lg}) gives each band room to establish its own visual climate. Within cards, 32px ({spacing.section}) internal padding prevents dense information from feeling claustrophobic. This is not "airy luxury" whitespace; it's "developer documentation needs cognitive margin" whitespace.

Header Architecture

+--------------------------------------------------------------------------------------------------+
| [LOGO]                                    [Product OS] [Pricing] [Docs] [Community]     [CTA]     |
+--------------------------------------------------------------------------------------------------
|                                          ^1440px max-width^                                       |
|  flush-left logo                         center-weighted menu                    flush-right CTA   |

Navigation uses a transparent background ({component.top-nav}) floating over the canvas. Menu items are ghost-style {component.nav-item} components with 4px radius, 2px×8px internal padding, and hover-state background fill in {colors.surface-soft}. The entire nav constrains to 1440px width with horizontal auto-centering.

Hero Section

+--------------------------------------------------------------------------------------------------+
|                                                                                                  |
|          [Stat Label]                                                                             |
|          HEADLINE IN BOLD WEIGHT 800                                                             |
|          Subheadline paragraph in body-md explaining the value prop...                            |
|                                                                                                  |
|          [Get Started Free]  [Book a Demo]                                                        |
|                                                                                                  |
|                                              +------------------+                                 |
|                                              |                  |                                 |
|                                              | Hero Visual      |                                 |
|                                              | (Illustration/   |                                 |
|                                              |  Screenshot)     |                                 |
|                                              |                  |                                 |
|                                              +------------------+                                 |
|                                                                                                  |
+--------------------------------------------------------------------------------------------------+

The hero uses {component.hero-band} with canvas background, 48px vertical padding. Headline renders in {typography.display-lg} (or {typography.display-xl} at larger viewports) at weight 800 in {colors.heading}. CTA pair combines {component.button-primary} (orange pill) with {component.button-secondary} (dark pill). The visual column typically contains a product screenshot, illustration, or animated demo—often with a subtle {extensions.shadows.md} elevation treatment.

Elevation & Depth

| Level | Treatment | Use | |---|---|---| | 0 – Flat | No shadow, {colors.canvas} or {colors.surface-soft} background | Page body, nav bar, flat cards | | 1 – Hairline outline | 1px {colors.hairline} border | Input fields, contained buttons, card edges | | 2 – Soft drop | {extensions.shadows.sm} (0 0 6px 2px rgba(0,0,0,0.2)) | Dropdown menus, tooltips, popover panels | | 3 – Modal elevation | {extensions.shadows.md} (0 25px 50px -12px rgba(0,0,0,0.25)) | Modals, dialogs, slide-over panels |

PostHog's depth philosophy is layered but restrained. Unlike SaaS products that stack multiple colored shadows for "floating card" effects, PostHog uses shadows sparingly—and only when functional elevation is required (dropdowns must appear above content, modals must command focus). The shadow color is neutral (black-based rgba), avoiding the colored-shadow trend. Most "elevation" in the system comes from background color changes: moving from {colors.canvas} → {colors.surface-soft} → {colors.surface-white} provides sufficient layering for 90% of cases without any shadow at all.

Shapes

Border Radius Scale

| Token | Value | Use | |---|---|---| | {rounded.xs} | 2px | Code inline snippets, hairline-bordered elements, tiny tags | | {rounded.sm} | 4px | Ghost buttons, nav items, input fields, small badges | | {rounded.DEFAULT} / {rounded.md} | 6px | Standard cards, containers, panel corners | | {rounded.lg} | 8px | Featured cards, larger containers, image frames | | {rounded.xl} | 12px | Modal corners, large image treatments (inferred) | | {rounded.pill} | 9999px | Primary/secondary CTA buttons, badges, tag pills | | {rounded.top-rounded} | 6px 6px 0 0 | Top-only rounded cards (tab panels, accordion headers) |

The radius progression is tightly clustered at the small end (2→4→6→8px)—this is not a system that explores radical roundness. Pill radius is reserved exclusively for actionable elements, creating a visual shorthand: "if it's pill-shaped, click it." The {rounded.top-rounded} token suggests tab-panel or expandable-card patterns where only the header gets curvature.

Photography Geometry

Product screenshots and dashboard previews likely use {rounded.lg} (8px) or {rounded.md} (6px) corner treatment with {extensions.shadows.md} for lift. Avatar imagery (team photos, user avatars) would default to {rounded.full} or circular clipping based on standard patterns, though no explicit avatar components appeared in the extracted data. Hero illustrations may be full-bleed or contained within the right-hand column with no additional corner treatment (flat placement against canvas).

Components

No hover states documented. Hover behavior is unreliable to extract from a single screenshot. State variants live as separate entries in the components: frontmatter (e.g. {component.button-primary-active}, {component.text-input-focus}); add hover styling at implementation time per your stack's conventions.

Buttons

{component.button-primary} — The main conversion button. Background {colors.accent-orange} (#f74e00), text white via {colors.on-accent-orange}, set in {typography.button} at 13px/weight 500, fully pill-shaped via {rounded.pill}, with 10px×20px internal padding. Appears as "Get started free," "Start building," and similar high-intent CTAs throughout marketing pages. Its active state ({component.button-primary-active}) shifts to {colors.accent-gold}; disabled state ({component.button-primary-disabled}) mutes to {colors.muted-light} with light text.

{component.button-secondary} — Dark alternative for secondary actions. Uses {colors.heading} background with white text, same pill shape and type sizing as primary. Renders as "Book a demo," "View docs," or "Contact sales." Active state ({component.button-secondary-active}) deepens to {colors.primary-active}.

{component.button-ghost} — Transparent-background button for low-emphasis actions. Text in {colors.body-dark}, tiny 2px×8px padding, {rounded.sm} corners. Used extensively in the navigation menu (Product OS, Pricing, Docs, Community items). Hover state ({component.button-ghost-hover}) reveals {colors.surface-soft} background; open/expanded state ({component.button-ghost-open}) maintains transparency. These sit inside {component.top-nav} and respond to both hover and keyboard highlighting (data-[highlighted] classes observed).

{component.button-icon} — Square icon-only button at 32px, transparent background, for toolbar actions (close, menu toggle, settings gear).

Cards & Containers

{component.card} — Standard content card. Cream-colored {colors.surface-soft} background, {colors.ink} text, 6px rounded corners ({rounded.md}), 12px×12px padding. Used for feature summaries, testimonial blocks, and content modules that sit on the canvas background.

{component.card-elevated} — Variant with {rounded.top-rounded} (6px top-only) for tab-panel or stacked-card patterns where bottom edges meet adjacent elements. Same surface-soft background and padding.

{component.card-white} — White-surface card ({colors.surface-white}) for content that needs maximum brightness—code preview cards, empty states, or cards nested within already-warm containers. Slightly larger radius at {rounded.lg} (8px).

{component.pricing-card} — Dedicated pricing tier container. Surface-soft background, 32px internal padding for generous spacing of price/feature lists. Used in the pricing page grid.

{component.pricing-card-featured} — Highlighted pricing tier (typically "Team" or "Enterprise"). Elevates to {colors.surface} (near-white) with larger {rounded.lg} radius and {colors.heading} text for the tier name, making it visually pop among standard {component.pricing-card} siblings.

Inputs & Forms

{component.text-input} — Standard text entry field. White ({colors.surface-white}) background, {colors.body} text in 15px body type, 4px radius, 8px×12px internal padding, 40px fixed height. Subtle {colors.border-subtle} border (implied). Focus state ({component.text-input-focus}) likely adds a ring or border-color shift to {colors.border-input}.

{component.select-input} — Dropdown/select field variant. Surface-soft background (slightly darker than text input), smaller 13px text ({typography.body-sm}), tighter 6px×8px padding. Used for category filters and setting selectors.

Navigation

{component.top-nav} — The global navigation bar. Transparent background (lets canvas show through), 64px height, text in {colors.ink} via {typography.caption} at 13px/weight 500. Constrained to 1440px max width. Contains {component.logo-mark} on the left, {component.nav-item} buttons in the center, and {component.button-primary}/{component.button-secondary} CTAs on the right.

{component.nav-item} — Individual navigation link/button. Inherits from {component.button-ghost} pattern: transparent, 4px radius, 2px×8px padding, {colors.body-dark} text. Supports highlighted state (keyboard focus) and hover state with {colors.surface-soft} reveal.

Sections & Bands

{component.hero-band} — Full-width hero section. {colors.canvas} background (maintaining the warm page tone), heading text in {colors.heading}, 48px vertical padding. Contains the primary value proposition headline, subheadline, CTA pair, and hero visual.

{component.content-section} — Standard content band. Transparent background (inherits canvas), 32px top padding. Repeated for each major content area below the hero.

{component.cta-band} — Call-to-action section (typically mid-page or before footer). {colors.surface-soft} background creates a subtle tone shift from canvas, drawing attention to a final conversion prompt. Title text in {typography.title-sm} at weight 600, 48px padding.

{component.footer-band} — Page footer. Returns to {colors.canvas} background (matching hero), muted {colors.muted} text at small size, generous 48px×24px padding for link columns and legal text.

Typography Components

{component.headline-hero}, {component.headline-section}, {component.headline-card} — Typographic roles for H1/H2/H3-equivalent text at different context scales. All use {colors.heading} (near-black) but differ in size/weight: hero at display-xl (32px/800), section at display-lg (24px/800), card at title-md (21.4px/700).

{component.subheadline} — Supporting heading below the main headline. {typography.title-sm} (19.3px/600) in {colors.heading}.

{component.body-copy} — Standard paragraph text. 15px/400 in {colors.body} gray.

{component.body-small} — Secondary descriptive text. 13.12px/400 in {colors.muted}.

{component.code-block} — Multi-line code display. {colors.surface-soft} background (subtle contrast from surrounding content), monospace 13px type ({typography.mono}), 4px radius, 8px×16px padding. Used for code examples, API snippets, and config blocks.

{component.code-inline} — Inline code within prose. Tiny 1px×4px padding, {rounded.xs} (2px), surface-soft background, monospace at 13px.

Links & Badges

{component.link-default} — Standard hyperlink. Blue ({colors.link}) text, body-md type. Hover shifts to {colors.link-hover} (darker blue).

{component.badge} — Highlight badge ("NEW," "BETA"). Bright {colors.accent-yellow} background, dark text, pill shape, 4px×10px padding. Commands attention without overwhelming.

{component.tag} — Category/filter tag. Muted {colors.surface-elevated} background, ink-colored text, pill shape, same padding as badge. Lower visual priority than badge.

Signature Elements

{component.logo-mark} — The PostHog logomark (three diagonal bars: blue, orange, yellow). 40px square, transparent background. The bars map to {colors.accent-blue}, {colors.accent-orange}, and {colors.accent-yellow} respectively.

{component.divider} — Horizontal rule. 1px height, {colors.hairline} color. Used between content sections where a full band break isn't warranted.

Do's and Don'ts

Do

• Do use {colors.canvas} as your page background—never substitute white unless building a {component.card-white} or {component.text-input} interior.
• Do set all headings at weight 700 or 800 using {typography.display-lg}, {typography.title-md}, or {typography.title-sm}—never render headings at 400 weight.
• Do apply {rounded.pill} to all CTA buttons ({component.button-primary}, {component.button-secondary})—square or slightly-rounded buttons are reserved for ghost/nav items.
• Do maintain 150ms cubic-bezier(0.4, 0, 0.2, 1) transitions for all color/background/border changes per the extracted transition tokens.
• Do use {typography.mono} (or {typography.mono-source}) at 13px for all code—never style code in the sans-serif font family.
• Do constrain article/prose content to 896px ({spacing.article-max}) for optimal reading line length; marketing layouts can extend to 1440px.
• Do reserve {colors.accent-orange} for primary conversion actions—informational links should use {colors.link} (blue).
• Do apply {rounded.sm} (4px) to input fields and nav items—don't leave them sharp-edged or over-round them.
• Do use {colors.ink} (#4d4f46) for body text on canvas background—it's warmer than {colors.body} and designed specifically for the tan surface.
• Do include the warm {colors.surface-soft} or {colors.surface} backgrounds for cards sitting on canvas—pure white cards will look jarring against tan.
• Do keep shadow elevation minimal—use {extensions.shadows.sm} for dropdowns and {extensions.shadows.md} only for modals; avoid stacking multiple shadows.

Don't

• Don't use gradients on buttons or backgrounds—the system relies on solid colors and subtle surface shifts, not rainbow washes.
• Don't apply letter-spacing wider than -0.02em to display text—or any positive letter-spacing. The system tightens letterforms at large sizes; expanding them fights the typeface's design.
• Don't substitute {colors.primary} (near-black) for {colors.accent-orange} on primary CTAs—primary is for dark buttons/headings, orange is for the "hot" conversion action.
• Don't round avatar or logo images beyond what the component specifies—if a photo isn't assigned a radius token, assume it's either square or handled by an image-specific class.
• Don't add drop shadows to standard {component.card} instances—cards elevate via background color change, not shadow. Reserve shadows for functional elevation (dropdowns, modals).
• Don't use font weights below 400 for body text—there's no "light" or "thin" role in this system. Even captions sit at 500.
• Don't place {colors.muted-light} text on {colors.canvas} without ensuring sufficient contrast—it's meant for disabled states and hints, not primary content.
• Don't invent new radius values beyond the defined scale (2/4/6/8/12/9999px)—the {rounded.top-rounded} compound value is the only exception for special panel patterns.
• Don't ignore the 4px base spacing unit—all padding and gap values should be multiples of 2px, clustering around 4/6/8/12/16/24/32/48px.
• Don't render navigation items as plain anchor tags—style them as {component.button-ghost} with proper hover/open/highlighted states for accessibility and consistency.

Motion & Animation

Transition Tokens

/* Core UI transition (extracted from button, link, and input styles) */
--transition-ui: color 0.15s cubic-bezier(0.4, 0, 0.2, 1),
                 background-color 0.15s cubic-bezier(0.4, 0, 0.2, 1),
                 border-color 0.15s cubic-bezier(0.4, 0, 0.2, 1),
                 text-decoration-color 0.15s cubic-bezier(0.4, 0, 0.2, 1),
                 fill 0.15s cubic-bezier(0.4, 0, 0.2, 1),
                 stroke 0.15s cubic-bezier(0.4, 0, 0.2, 1);

/* Short transition utility */
--transition-fast: 0.15s cubic-bezier(0.4, 0, 0.2, 1);

/* Fallback for legacy/all-property transitions */
--transition-all: all 0.15s cubic-bezier(0.4, 0, 0.2, 1);

Keyframe Animations

The following keyframe names were detected in the stylesheet, suggesting a rich animation library:

• slideRight — Lateral entrance animation (likely for slide-in panels or off-canvas nav).
• rcSliderTooltipZoomDownIn / rcSliderTooltipZoomDownOut — Tooltip scale animations from a slider component library (rc-slider).
• wobble — Playful oscillation motion (likely for the PostHog mascot/hog character in error or loading states).
• breathe — Subtle scale pulse (loading indicators, attention-drawing elements).
• develop — Custom animation name (possibly code-typing or build-progress visualization).
• flash — Brief opacity/color flash (notification toasts, status changes).
• float — Gentle Y-axis oscillation (hero illustrations, mascot bobbing).
• gradient-rotate — CSS gradient position rotation (possibly for shimmer/loading effects on the gold accent).
• grow / grow-sm — Scale-up animations (expanding cards, appearing modals).
• hogfather-jump / hogfather-roll — Mascot-specific animations (PostHog's hog character performing jump and roll movements—signature brand moments).
• jump-out — Exit animation with upward movement and fade.
• ping — Expanding ring animation (live indicator dots, notification pulses).
• pulse — Opacity pulse (recording indicators, live-status badges).
• shimmer — Linear gradient sweep (skeleton loading placeholders, premium badge sheen).
• slideUpFadeIn — Combined upward translation and fade-in (content reveals on scroll).
• spin — Continuous rotation (loading spinners).
• wiggle — Small rotation oscillation (attention-grabbing micro-interactions).

Interaction Patterns

• Hover reveals: Ghost buttons ({component.button-ghost}) and nav items transition from transparent to {colors.surface-soft} background on hover.
• Color shifts: Links darken from {colors.link} to {colors.link-hover}; buttons shift to their -active palette variants.
• Scroll-triggered reveals: Content sections likely animate in via slideUpFadeIn when entering the viewport (IntersectionObserver-driven).
• Mascot animations: The PostHog hog character (observed in brand materials) performs contextual animations—wobble on idle, jump-out on dismissal, hogfather-jump on celebration.
• Tooltip animations: Slider and dropdown tooltips zoom in/out using rc-slider's custom keyframes.
• Live indicators: Recording/live status dots use ping (expanding ring) combined with pulse (opacity) for a "radar blip" effect.
• Skeleton loading: Shimmer animation sweeps across placeholder blocks during async content load.
• Focus rings: Inputs and interactive elements likely gain a subtle box-shadow or border-color transition on focus (not captured in static extract, inferred from text-input-focus component definition).

Imagery Style

• Product photography/screenshots: Dashboard UI captures displayed within rounded containers (likely {rounded.lg} or {rounded.md}) with {extensions.shadows.md} elevation, showing the actual PostHog interface with its dark-sidebar, light-content-panel layout.
• Illustration style: Flat, vector-based illustrations with a limited palette drawn from the brand colors (tan, orange, blue, yellow). Likely geometric/abstract representations of data pipelines, funnels, and user flows.
• Mascot imagery: PostHog's hog character appears in playful poses—rendered in a simple, friendly cartoon style with the brand colors. Animated in-context using the detected wobble, float, and hogfather-* keyframes.
• Team/avatar imagery: Professional headshots with consistent treatment (likely circular crop or {rounded.pill} for a friendly, approachable feel).
• Iconography within imagery: Feature icons (event tracking, session replay, analytics) rendered as simple outlined or filled shapes in {colors.ink} or {colors.accent-blue}.
• Background textures: The canvas color (#e1d7c2) may have a very subtle noise or paper texture at close inspection (the screenshot shows slight grain), adding tactile warmth.
• Color treatment: Images are generally placed without heavy color overlays—the warm canvas provides enough atmosphere without washing out visuals with tints.
• Data visualization imagery: Charts, graphs, and funnel diagrams shown in-product or in marketing materials use the accent palette (blue for primary data, orange for highlights, green for positive trends).
• Imagery role: Supporting rather than dominant—PostHog is a developer tool, so imagery illustrates concepts (pipelines, dashboards, code) rather than evoking emotion through abstract lifestyle photos.

Icon System

• Library: Custom SVG icon system (no external icon library detected in imports; framework.iconLibs is empty). Icons are likely hand-crafted or sourced from a customized set matching PostHog's brand language.
• Specific icons observed:
  • Menu/hamburger — Three horizontal lines (for mobile nav toggle, implied)
  • Chevron/down-arrow — Dropdown indicators on nav items with group and gap classes
  • Close/X — Dismissal icon for modals/toasts
  • External-link — Outbound link indicators on docs references
  • Search/magnifier — Search input icon (inferred from nav patterns)
  • GitHub/mark — GitHub logo for "Star on GitHub" or repo links
  • Check/circle-check — Feature list checkmarks, plan comparison ticks
  • Arrow-right — CTA button arrow indicators
  • Console/terminal — Code-related section icons
  • Chart/bar-graph — Analytics feature icons
  • Play button — Session replay/video playback triggers
  • Settings/gear — Configuration/settings icons
• Treatment: Icons are stroke-based (outlined style) rather than filled, maintaining a lightweight, technical aesthetic. Color is typically currentColor, inheriting from parent text color (usually {colors.ink} or {colors.body-dark}). Size aligns with adjacent text: 16px for inline icons (next to 13–15px text), 20–24px for standalone feature icons, 32px+ for hero-section illustrative icons. Icons are vertically centered with text using flexbox alignment (consistent with the flex items-center classes observed on buttons).

Recommended Frontend Stack

- Framework:      Next.js (App Router) — PostHog's site architecture suggests React-based SSR/SSG
- Styling:        Tailwind CSS v3-v4 — Utility classes detected (group, flex, rounded, px/py, text-[size], etc.)
- Fonts:          Self-hosted IBM Plex Sans Variable (variable font woff2 files served from /static/)
                   + Source Code Pro (data-URI embedded for code contexts)
- Animation:      CSS keyframes (custom) + Framer Motion (inferred for scroll-triggered reveals)
- Icons:          Custom SVG components (inline React components, not an icon library)
- Component lib:  Radix UI primitives (inferred from data-[highlighted], data-[state=open] ARIA patterns)
- Deployment:     Vercel (consistent with Next.js + PostHog's infra preferences)

Responsive Behavior

Breakpoints

| Name | Width | Key Changes | |---|---|---| | Mobile | < 640px | Single-column layout; hamburger nav; stacked hero (text above visual); reduced type sizes; touch-optimized spacing | | Tablet | 640px – 1024px | Two-column grids begin; condensed nav (icon-only or abbreviated); hero side-by-side at ~60/40 | | Desktop | 1024px – 1440px | Full nav visible; multi-column feature grids (3-col); pricing table expands to show all tiers | | Wide | > 1440px | Max-width container centers; gutters widen; hero text column caps at ~600px for readability |

Touch Targets

• {component.button-primary}: 40px+ height with 10px×20px padding—exceeds WCAG AAA 44×44 minimum comfortably.
• {component.button-ghost} (nav items): Current spec shows 2px×8px padding at 13px text—height may fall below 44px. Recommend increasing to minimum 36px height (adding py-2 or py-3) for mobile touch targets, or wrapping in a 44px tap area.
• {component.text-input}: 40px defined height—meets 44px recommendation closely; acceptable.
• {component.nav-item}: Same concern as ghost button—ensure tap area expansion on mobile via padding increase or invisible hit-area wrapper.

Collapsing Strategy

• Navigation: Full horizontal nav ({component.top-nav}) collapses to a hamburger menu on mobile (< 768px inferred). The menu items ({component.nav-item}) stack vertically in a dropdown/sheet triggered by the hamburger icon ({component.button-icon}).
• Hero section: Desktop's side-by-side text/visual layout stacks vertically on mobile—headline and CTAs above the hero image/screenshot. {typography.display-lg} (24px) may reduce to 20–22px on smallest screens.
• Pricing grid: Three-column pricing card grid ({component.pricing-card} × 3) collapses to single-column scrollable or stacked cards on mobile. {component.pricing-card-featured} loses its elevation advantage in stack—consider reordering it first or giving it distinct top-border treatment.
• Feature grids: Multi-column feature comparison or showcase grids collapse to single column, with each card ({component.card}) taking full width.
• Sticky elements: Any sticky nav or side-rail becomes static on mobile; scroll position is the only spatial reference.
• Footer: Multi-column footer link groups stack into a single column or accordion on mobile.

Image Behavior

• Hero illustrations/screenshots: Contained within their column, scaling down proportionally. May switch from side-by-side to full-width (below headline) on mobile, potentially increasing in relative visual weight.
• Dashboard preview images: Constrain to container width; may require horizontal scroll within a rounded container if showing wide dashboard views.
• Avatar/team images: Grid of avatars collapses—may show fewer faces or wrap to multiple lines.
• Logo mark: Maintains 40px size or reduces slightly to 32px on mobile; always visible (no collapse to icon-only wordmark).

Iteration Guide

1. Build a landing page or documentation template that closely mimics the design system in this DESIGN.md. Use Next.js with Tailwind CSS as the foundation—match the utility-class patterns observed in the extracted DOM.

2. Pull every color, font, radius, and spacing value from the YAML frontmatter via the {section.token} paths. Define these as Tailwind theme extensions (colors in theme.colors, spacing in theme.spacing, borderRadius in theme.borderRadius, etc.) or as CSS custom properties. Never hard-code a value that has a token.

3. Add state variants (-hover, -disabled, -focus, -active) per Tailwind's variant conventions (e.g., hover:bg-accent-orange-dark, focus:ring-2). The spec documents Default and Active/Pressed/Focus states; synthesize hover from the active tokens as a reasonable intermediate.

4. When adding a new component, decide first which sub-system it belongs to: marketing (hero-band, cta-band, pricing-card patterns), documentation (code-block, body-copy, article constraints), or app-shell (nav, inputs, modals). Each sub-system has subtly different density and surface-color expectations.

5. Variants of an existing component live as separate frontmatter entries (button-primary-active, never nested under button-primary.states.active). Mirror this in your component library as exported sub-components or variant props.

6. Implement the animation keyframe library early—the detected 22 keyframes (especially slideUpFadeIn, shimmer, hogfather-jump, and ping) are core to PostHog's interactive personality. Add them to your globals.css or animation utility file.

7. Run npx @google/design.md lint DESIGN.md after edits — broken-ref, contrast-ratio, and orphaned-tokens warnings flag issues automatically. Pay special attention to contrast ratios between {colors.muted-light} and {colors.surface-soft} (low-contrast combinations).

8. When in doubt about emphasis: bolder weight before bigger size, {colors.accent-orange} before {colors.primary} for CTAs, and surface-color change before shadow addition. The system prefers typographic and chromatic hierarchy over spatial/elevation tricks.

9. Test on the actual {colors.canvas} background constantly—design decisions made on white backgrounds will look wrong on tan. Set up your dev environment with the correct page background from day one.

10. Font setup: IBM Plex Sans Variable must be self-hosted (PostHog serves woff2 files from /static/). Define:

    :root {
      --font-sans: 'IBM Plex Sans Variable', 'IBM Plex Sans', -apple-system, BlinkMacSystemFont, 'avenir next', avenir, 'segoe ui', 'helvetica neue', helvetica, Ubuntu, roboto, noto, arial, sans-serif;
      --font-mono: ui-monospace, SFMono-Regular, Menlo, Monaco, Consolas, 'Liberation Mono', 'Courier New', monospace;
    }
    

    If self-hosting isn't feasible initially, substitute with Google Fonts' static 'IBM Plex Sans', sans-serif and accept the loss of variable-font axis interpolation.

Known Gaps

• Hover state styling: Per the no-hover policy, hover backgrounds, color lightens, and transform translates are documented only as separate -active or -hover component entries where inferable. Interactive prototype review needed for precise hover distances and color stops.
• Loading skeletons / pending states: While shimmer keyframe exists, exact skeleton component dimensions (line heights, pulse timings, border-radius on placeholder blocks) weren't captured.
• Form validation states: Beyond {component.text-input-focus}, error-state (red border/shake), warning-state (yellow border), success-state (green checkmark) styling is inferred from semantic color tokens but not directly observed.
• Dark mode: The system as extracted is light-mode only (extensions.mode: "light"). PostHog's app shell may offer dark mode for the dashboard, but the marketing/docs site appears light-exclusive. Dark-mode token mappings (canvas→dark surface, ink→light text) are speculative.
• Authenticated/app surfaces: Dashboard UI, settings panels, project creation flows, and authenticated-only navigation elements weren't present in the public-facing screenshot. These likely use a different surface palette (darker sidebar {colors.primary}-adjacent, lighter content area).
• Map view, session replay player, heatmap overlay: Product-specific surfaces with specialized UI (timeline scrubbers, event lists, heat-map canvases) are outside the scope of this marketing-site extraction.
• Sub-brand palettes: Separate domains or co-branded properties (PostHog Cloud vs. self-hosted, US vs. EU region indicators) may carry unique accent or certification-badge colors not seen here.
• Pixel-exact values for pastel surfaces: {colors.surface-soft}, {colors.surface}, and {colors.canvas} were extracted accurately from computed RGB, but subtle texture/noise overlays on the canvas background (visible in the screenshot grain) aren't representable in hex tokens.
• Misleading CSS variables: The data-[highlighted]:bg-accent and data-[state=open]:bg partial class fragments suggest Radix UI primitive usage where bg-accent resolves to a dynamic value possibly differing from {colors.surface-soft} in all contexts. Implementation should verify accent token resolution in combobox/dropdown scenarios.