Identity System

When to use this

Use when visual expression must be built or rebuilt as an operating system — something that generates new work, not a set of finished artifacts.

Use when the brand disappears the moment the logo is removed, when the guidelines look impressive but production work looks unrelated, or when every new surface requires the design team's personal intervention because the rules do not extend.

Do not use it to design a single asset. This skill produces the grammar; individual pieces are its output, not its purpose.

Inputs

The position, promise, and distinctive mechanism from strategy-brief.md. The chosen territory and why it won. The name and its lockup demands. The verbal register, so visual and verbal behavior can be tuned to each other.

Also required, and usually missing: the real production constraints. What the engineering team can implement, what the CMS permits, who makes assets day to day, what tooling they have, and what the least-resourced team will actually do under deadline.

Ask for the production constraints explicitly. They are rarely offered and they decide what is buildable. A system designed without them will be beautiful and quietly unimplementable.

Mission

Create a visual operating system, not a logo presentation.

Recognition comes from relationships between elements and from repeatable behavior, not from a mark. Most identities put the entire recognition burden on the logo, which is the element people look at least and remember worst.

Method

1. Establish the visual thesis. One sentence naming what this system does that expresses the strategic idea. If it could be applied to a competitor, it is not a thesis.
2. Develop concept territories visually, at a low enough fidelity that the idea is judged rather than the craft.
3. Decide what carries recognition. Explicitly rank elements by recognition strength and strategic role. Some elements carry the brand; others support. Confusing the two produces systems that are rigid where it does not matter and loose where it does.
4. Build the grammar: typographic behavior and hierarchy, color relationships and semantic roles, form logic, composition and density, imagery direction and boundaries, iconography, illustration, motion principles.
5. Set accessibility standards. Contrast ratios against a named standard, minimum sizes, focus states, color-independent meaning, reduced-motion behavior. Standards, not aspirations.
6. Define application rules per surface: required cues, permitted variation, failure risks.
7. Stress-test across small format, large format, dense information, sparse editorial, product UI, campaign, social, presentation, motion, and constrained reproduction — monochrome, one-color print, low resolution, dark mode, embroidery, screen glare.
8. Write evolution rules. What may change, what must not, and what evidence would justify changing a recognition-bearing element.

What must be established

Which two or three elements a customer could recognize the brand by with the logo removed. Name them, and design the system so they actually recur where customers encounter the brand — not only in the guidelines.

The system must generate work it has not seen. If every application requires a new judgment call by the original designer, you have produced a portfolio, not a system.

Strong versus merely polished

The system is strong when a good designer can do their best work inside it and a rushed designer cannot easily do damage.

Failure modes

• Manufacturing differentiation through arbitrary novelty. A strange choice is not an ownable one.
• Letting the logo carry recognition alone.
• Confusing a moodboard with a system. Atmosphere is not grammar.
• Rules so rigid that competent creative work becomes mechanical, which guarantees teams route around the system.
• Designing only for the flagship surface, so the brand degrades in the places most customers actually meet it — a search result, an email footer, a support page, an app icon.
• Choosing a palette that cannot meet contrast requirements, then treating accessibility as a later exception rather than a design failure.
• Specifying typefaces without checking licensing, language coverage, and the weights the web build can actually load.

Never claim without evidence

Never state that the system is accessible or compliant. State the standard tested against, what was measured, what passed, what failed, and what remains unverified. Contrast is measurable; usability for assistive technology is not established by a contrast check.

Never claim a visual direction will increase recognition, preference, or recall. Recognition is testable — say how it would be tested and against what baseline.

Never present a font, image, icon set, or texture without confirming its license covers the intended use, including embedding, web serving, and the client's headcount tier.

Output

Produce identity-system.md using the structure in references/identity-system.md.

Verification

• Logo-removal test. Strip the logo and name from six representative pieces. Ask whether they belong together, and what makes them belong. If the answer is only "the blue", recognition rests on one removable element.
• Generation test. Build three applications the system has never seen, using only the written rules. Where you had to improvise, the rules have a hole; write it down rather than patching it silently.
• Degradation test. View the identity at 16px, in greyscale, on a low-quality print, and on a bad screen. Most identity systems fail first in the places nobody presents.
• Handoff test. Give the system to a designer outside the project and compare their output to yours. The gap is the part of the system that lives in your head.
• Counterfactual pass. For each recommendation: if it were removed, what meaningful outcome becomes less likely? No credible answer means cut it, downgrade it, or reframe it.
• Fresh-eyes pass. Read the output as someone who must act on it and was not in the process. Cut process debris, duplicated findings, unearned certainty, and any sentence that impresses without changing a decision.

Complete when

The system generates high-quality new work, preserves recognition without depending on the logo, expresses the strategy, meets a stated accessibility standard, and survives real production constraints.

Handoff

Brand Worldbuilding extends this grammar into behavior, ritual, and environment — it needs to know which elements are load-bearing so it does not build a world on a decorative cue. Brand Governance classifies elements by recognition importance; the recognition map produced here is its primary input. Brand Ship verifies that source files, exports, templates, and licenses exist and function, so record where they live as you make them rather than reconstructing it later.