--- name: jpoindexter/brand-identity-and-design-principles source: https://app.decimal.ai/s/jpoindexter-brand-identity-and-design-principles@1/SKILL.md source_sha256: 798adb18bef1 --- # Brand Identity & Design Principles This is the **philosophical and expressive layer above tokens and components**. Tokens say *what* `#4F46E5` means; components say *how* a button behaves. Principles and brand say *why* the whole thing looks and decides the way it does. Get this layer right and the rest writes itself; get it wrong and you ship a thousand inconsistent screens that all technically pass review. --- ## 1. Authoring design principles A design principle is a **shared, opinionated rule that resolves disputes before they happen.** It is not a value, not a guideline, not a slogan. | Layer | What it is | Example | Lifespan | |-------|-----------|---------|----------| | **Value** | What you believe (cultural) | "We respect the user's time" | Years | | **Principle** | A design-decision rule with a tradeoff | "Default to the fastest path, not the most powerful one" | Years, rarely change | | **Guideline** | A specific, enforceable rule | "Primary actions use `--color-action`, max one per view" | Versioned, change often | | **Standard/spec** | A measurable check | "Touch targets ≥ 44×44pt" | Per release | Principles live between values and guidelines. They are abstract enough to apply to a screen you haven't designed yet, concrete enough to make you choose. ### What makes a GOOD principle A strong principle is **specific, actionable, opinionated, and reveals a tradeoff** — it helps you say *no*. The acid test: **can a smart person disagree with it?** If no one could possibly hold the opposite position, it is a platitude, not a principle. - ❌ "Be simple." → Nobody argues for complex. Useless. - ❌ "Delight users." → Unfalsifiable. Decides nothing. - ❌ "Make it intuitive / user-friendly / clean." → No tradeoff, no edge. - ✅ "Progressive disclosure over feature parity" → Reveals a tradeoff: you will *hide* power to protect clarity. Someone could argue the reverse. It tells you what to cut. - ✅ "Obvious always beats clever" → Kills your favorite easter-egg interaction. - ✅ "Content is the interface" (Vimeo, Medium) → Justifies stripping chrome. A principle should pass three checks: 1. **Two-sided** — the opposite is a position a competitor might actually take. 2. **Decisive** — you can point at a real past decision it would have settled. 3. **Memorable** — the team can recite it without the doc open. ### Strong principles from real systems - **Material Design** — "Bold, graphic, intentional" / "Motion provides meaning" (animation must explain causality, not decorate). - **Apple HIG** — "Clarity, Deference, Depth" — *deference* explicitly subordinates the UI to the content, an unusual, opinionated stance. - **GOV.UK** — "Do the hard work to make it simple" / "This is for everyone" — both name a cost (it's *hard*; *everyone* includes the edge cases you'd rather skip). - **Atlassian** — "Be bold, optimistic, practical, with heart" paired with concrete usage rules. - **Salesforce Lightning** — "Clarity, Efficiency, Consistency, Beauty" — and crucially *ordered*, so clarity wins ties against beauty. ### How many? **3–6.** Below 3 you're not covering enough decision space; above 6 nobody remembers them and they stop functioning as a tiebreaker. **Order them** — when two principles conflict on a real screen, the earlier one wins. That ordering is itself a design decision. ### Using principles to resolve disputes The whole point. When two designers argue "more powerful vs. simpler," you don't argue taste — you cite the ranked principle: *"Progressive disclosure ranks above feature parity, so we hide it behind 'Advanced.'"* Disagreement moves from personal to structural. If a recurring fight *isn't* covered by any principle, that's the signal you're missing one. **Do:** write principles *from* real past arguments you've already had. **Don't:** invent aspirational principles for problems you've never hit — they'll be generic, because you have no concrete case to sharpen them against. --- ## 2. The brand identity system — components Brand identity is a **system of expressive decisions**, not a logo. The full inventory: | Component | What it carries | Authored where | Cross-ref | |-----------|-----------------|----------------|-----------| | **Name** | The first impression; everything attaches to it | Naming brief | — | | **Logo / wordmark / monogram / mark** | Ownership signature | Logo spec | this skill §3 | | **Color** | Fastest-recognized brand cue (~80% of recognition) | Brand palette | `color-and-elevation` | | **Typography** | Voice made visible | Brand type scale | `typography-system` | | **Imagery / photo / illustration** | World the brand lives in | Art-direction guide | `iconography-and-imagery` | | **Iconography style** | Stroke, corner, metaphor language | Icon spec | `iconography-and-imagery` | | **Motion signature** | How the brand *moves* (easing personality) | Motion spec | `interaction-and-motion` | | **Sound / sonic logo** | Audio mnemonic (Netflix "ta-dum") | Sound brief | `multimodal-voice-and-haptics` | | **Voice + tone** | How the brand talks | Content guide | `ux-writing-and-content` | | **Layout / compositional signature** | Grid feel, density, asymmetry | Layout principles | `layout-and-composition`, `grid-and-spacing` | | **Texture / pattern / graphic devices** | Recurring shapes (Spotify "equalizer bars", Stripe gradients) | Brand kit | this skill | The signature emerges from *consistency across these*, not any single one. A user recognizes Spotify from green + circular shapes + a specific photo treatment long before reading "Spotify." ### Naming (briefest possible) Test any name on: pronounceable on first read, spellable when heard, domain/handle available, no negative meaning in target locales, trademark-clear, and short enough to wordmark. Descriptive names (Salesforce) age into constraints; abstract names (Stripe, Asana) cost more upfront marketing but flex forever. --- ## 3. Logo system The logo is the most regulated brand asset because it is the most abused. Spec it like an engineering tolerance. **Construction grid** — define the logo on a unit grid so anyone can rebuild it. Document optical (not mathematical) alignment: a circle must overshoot a square's bounds slightly to *look* the same size. **Clear space** — minimum exclusion zone, defined *relative to the mark* so it scales: e.g. "clear space = height of the wordmark's cap-height (`x`) on all sides." Never an absolute px value. **Minimum size** — the smallest size where the mark stays legible, specified **per medium**: e.g. wordmark min 24px digital / 12mm print; favicon-mark min 16px. **Logo lockups & hierarchy:** - **Wordmark** — name as styled type (Google, Coca-Cola). - **Mark / symbol** — abstract or pictorial glyph standalone (Apple, Nike). - **Monogram** — initials (WordPress "W", Honor "H"). - **Combination lockup** — mark + wordmark together, with a defined relationship and spacing. **Responsive / adaptive logos** — the logo must *degrade gracefully* by size, not just shrink. The canonical model (per Joe Harrison's responsive-logo work, popularized via Disney/Heineken studies): ``` Large surface → full combination lockup, all detail Medium → simplified mark + wordmark Small (app icon)→ mark only, fewer details Tiny (favicon) → monogram or single glyph, high contrast ``` Ship the logo as a **set of SVGs keyed to size breakpoints**, not one file you scale down into mush. **Misuse rules** — show the *don'ts* explicitly, because they're violated constantly: - ❌ Don't stretch / distort aspect ratio. - ❌ Don't recolor outside the approved set. - ❌ Don't add effects (drop shadow, gradient, outline) unless they're part of the mark. - ❌ Don't rotate, crowd the clear space, or place on low-contrast backgrounds. - ❌ Don't recreate the wordmark in a different font. - ✅ Provide approved variants: full-color, single-color (black), reversed (white), and on-photo (with scrim). --- ## 4. Brand attributes → visual translation This is the hardest, least-documented skill: turning **adjectives into pixels.** A brand picks 3–5 personality attributes, then *each one must cash out as concrete decisions.* | Attribute | Type | Color | Space / layout | Motion | Shape | |-----------|------|-------|----------------|--------|-------| | **Trustworthy** | Mid-weight, high-legibility sans/serif; tight tracking | Blue/navy, low saturation, high contrast | Generous, orderly, aligned grid | Calm, slow ease-out (~250ms) | Low corner radius, stable | | **Bold** | Heavy weights, big size jumps, tight leading | High-chroma, high-contrast pairs | Dense, full-bleed, edge-to-edge | Fast, snappy (~150ms), overshoot | Sharp corners, strong diagonals | | **Playful** | Rounded sans, varied weights, maybe display face | Saturated, multi-hue, warm | Asymmetric, loose, surprising | Springy, bouncy, generous | High radius, organic blobs | | **Premium / luxury** | High-contrast serif or refined grotesque, wide tracking | Restrained, mono/duotone, black + 1 accent | Vast whitespace, slow rhythm | Slow, deliberate fades | Thin rules, precise alignment | | **Approachable** | Humanist sans, comfortable size | Soft, mid-saturation, warm neutrals | Comfortable density, clear grouping | Gentle, friendly ease | Medium-soft radius | **The discipline:** every attribute must touch *type, color, space, and motion* — if "playful" only changed your accent color, you didn't translate it, you decorated. Pressure-test each attribute against its opposite to find the *edge*: "bold" means you will sacrifice some calm; name that sacrifice. **Do:** translate each adjective into ≥3 concrete token-level decisions. **Don't:** stop at a moodboard — a moodboard that never becomes type/color/space/motion rules is a feeling, not a system. --- ## 5. The brand spectrum: expressive vs. functional surfaces One identity must serve two very different jobs. This is where most brands fracture. ``` EXPRESSIVE end ◄─────────────────────────────► FUNCTIONAL end marketing site campaign onboarding app shell settings data table big type hero art illustration product UI forms dense UI brand LOUD ───────────────────────────────────────── brand QUIET ``` - **Expressive surfaces** (landing pages, ads, launch moments): brand turned up — full color, hero imagery, signature motion, personality copy. The job is *recognition and emotion*. - **Functional surfaces** (the actual product, dashboards, forms): brand turned *down*. The job is *clarity and task completion*. Apple HIG's "deference" lives here. **The flex without breaking:** the *same tokens and primitives* run across both, the **density and saturation dial changes.** The brand blue is identical; on the marketing page it's a 600px gradient hero, in the product it's a 2px focus ring. The wordmark is the same; it's 80px in the nav of the site and 20px in the app's top bar. **Brand-in-product** is the discipline of keeping a recognizable identity inside a UI optimized for work: - Brand shows up in *details*: the accent color, the icon style, the motion easing, the empty-state illustration, the loading animation — not in shouting chrome. - A user should *feel* it's your product within a second, without the brand getting in the way of the table they're trying to read. - **Test:** screenshot a dense product screen, blur it, hand it to someone — can they name the brand from color/shape/type alone? If yes, brand-in-product works. If it could be anyone's app, the brand stopped at the marketing door. --- ## 6. The brand → token bridge This is the load-bearing connection between this skill and `design-tokens`. **Brand decisions become semantic tokens.** The brand book says "our primary is confident indigo"; the token layer makes that *executable and consistent*. ``` Brand decision → Primitive token → Semantic token → Component token "confident indigo" --indigo-600: #4F46E5 --color-action: var(--indigo-600) --button-primary-bg "calm, deliberate" --ease-out, 250ms --motion-emphasis --dialog-enter "orderly, generous" 8pt base scale --space-comfortable --card-padding "trustworthy serif" "Tiempos", 1.5 ratio --font-brand-display --hero-title-font ``` Rules for the bridge: - Brand sets the **primitive + the *meaning***; never let a component hardcode a brand hex — it must reference a semantic token, so a rebrand is a token swap, not a find-replace across the codebase. - The semantic name encodes the *brand intent* (`--color-action`, not `--indigo`), so the brand can change indigo→teal and every action stays correct. - This is why **a rebrand is feasible**: if brand lives in tokens, you reskin; if brand lives in scattered literals, you rewrite. See §10. --- ## 7. Brand guidelines / brand book contents A real brand book (the *spec*, not a poster) contains: 1. **Brand strategy** — purpose, positioning, audience, attributes (the *why*). 2. **Design principles** (§1) — ranked. 3. **Logo system** (§3) — construction, clear space, min size, variants, misuse. 4. **Color** — palette + semantic roles + accessibility pairs (→ `color-and-elevation`). 5. **Typography** — type families, scale, weights, pairing, web/native fallbacks (→ `typography-system`). 6. **Imagery & illustration** — art direction, do/don't examples, treatment. 7. **Iconography** — grid, stroke, style. 8. **Motion** — easing personality, duration scale, signature transitions. 9. **Voice & tone** — with examples per context (→ `ux-writing-and-content`). 10. **Layout & graphic devices** — grid, patterns, textures. 11. **Application examples** — the brand *in situ* across surfaces (this is what makes it usable). 12. **Governance** — who owns it, how to request changes (→ `design-system-governance`). The most-skipped, most-valuable section is **#11 application examples** — abstract rules without "here's a real screen" get reinvented by every team. --- ## 8. Consistency vs. flexibility A brand system is a **system, not a straitjacket.** Over-locked brands die two ways: teams route around them, or every surface looks identical and the brand can't adapt to new contexts. - **Lock the load-bearing:** logo construction, core palette, primary type, voice. These never bend. - **Flex the expressive:** secondary palette extensions, illustration moods per campaign, layout density per surface, motion intensity. - **Give a sanctioned escape hatch:** "for X context, here's how to extend" beats an unwritten rule someone breaks anyway. **Co-existence with the design system:** think two cooperating layers. The **brand layer** owns expression (color *meaning*, type *personality*, motion *feel*); the **system layer** owns mechanics (the button's states, the grid's math, the a11y floor). The bridge (§6) is tokens. The brand layer feeds values *into* the system; the system enforces *how* they're used. **Sub-brands / multi-brand theming:** when one company runs multiple brands (or white-label), structure the token tree so the **semantic + component tiers are shared** and only the **primitive tier swaps per brand**. One component library, N brand themes, swapped at the token root: ```css [data-brand="aurora"] { --color-action: var(--teal-600); --font-brand: "Söhne"; } [data-brand="vela"] { --color-action: var(--amber-600); --font-brand: "Tiempos"; } ``` This is the same machinery as light/dark theming — a theme *is* a brand variant. --- ## 9. Accessibility of brand Brand decisions are **accessibility decisions.** A brand color that fails contrast isn't "on brand on most screens" — it's broken for some users, everywhere. - **Contrast-safe brand colors:** the *marketing* hero can use the vivid brand color decoratively, but the moment that color carries meaning (a button, a link, text), it must hit WCAG AA (4.5:1 text / 3:1 large & UI) — derive an accessible *action* shade from the brand hue rather than forcing the literal logo color to do UI work. (→ `color-and-elevation`, `accessibility-and-inclusive-design`.) - **Legible brand type:** a gorgeous thin display face is fine for a hero headline; it must never be the body or UI text size. Cap brand-type usage at sizes/weights that stay legible, and pair it with a workhorse face for everything functional. (→ `typography-system`.) - **Don't let brand override focus/state visibility** — a "clean" brand that removes focus rings fails keyboard users. Brand styles the ring; it doesn't delete it. - **Motion signature respects `prefers-reduced-motion`** — your springy brand bounce must have a reduced variant. The brand color in the logo and the brand color in a button are **two different tokens** — the logo can be the pure brand hue, the action token is the AA-safe derivative. Conflating them is the #1 brand-accessibility bug. --- ## 10. Rebrand / evolution Brands evolve. Plan for it. - **Evolution > revolution** for established brands — incremental shifts (Google's 2015 sans-serif, Instagram's 2016 gradient) keep equity; full revolutions reset recognition and are reserved for repositioning or post-scandal resets. - **The token layer is your rebrand insurance** (§6): brand-in-tokens means a rebrand is a values swap + asset re-export, not a code rewrite. Audit for hardcoded brand literals *before* you need to rebrand. - **Stage it:** logo + color first (highest recognition), then type, then motion/imagery. Run old and new in parallel behind a flag where possible. - **Version the brand** like the system (→ `design-system-governance`): announce, give migration windows, keep an old-asset archive, don't break partners overnight. --- ## 11. Common mistakes - **Vague principles** — "simple, delightful, intuitive." Platitudes nobody could disagree with; they resolve no disputes. Fix: §1's two-sided test. - **Logo that doesn't scale or adapt** — one SVG crammed into a 16px favicon. Fix: responsive logo set (§3). - **Brand that ignores product surfaces** — gorgeous marketing site, generic faceless app. Fix: brand-in-product (§5). - **Inaccessible brand colors** — the literal logo hue forced onto buttons/text, failing AA. Fix: separate logo color from action token (§9). - **Decoration over function** — brand applied as ornament that fights the task (animated logo in a data table). Fix: functional-end restraint (§5). - **Inconsistent application** — same brand, ten interpretations, because the rules were a mood not a spec. Fix: token bridge (§6) + application examples (§7.11). - **Brand as a dead PDF** — a 60-page guideline nobody opens, drifting from the live product. Fix: brand lives as *tokens + components + a maintained doc site*, versioned and governed (→ `design-tokens`, `design-system-governance`) — a living system, not an artifact. - **Too many / unordered principles** — 12 principles can't break a tie. Fix: 3–6, ranked (§1). --- **The throughline:** principles decide, attributes translate, tokens execute, the system enforces, and accessibility is non-negotiable across all of it. A brand identity is the *meaning* layer; tokens and components are how that meaning ships consistently to any screen — expressive or functional — without fracturing.