Logo usage
guidelines & standards
in Irvine

A brandbook that covers color and type in exhaustive detail often says nothing about the small superscript symbols riding next to the logo. Not a small detail, in practice. That gap shows up constantly, because almost nobody outside legal knows the actual rule. The difference between a registered mark and an unregistered one is not stylistic. It changes which symbol belongs where.

The plain rule is simple to state and easy to misapply. A registered trademark, one formally granted by a trademark office, takes the circled R. An unregistered mark takes the TM superscript instead: a name a company is actively using and defending, a new product before registration clears, or a mark registered in some markets but not others. Using the circled R too early is not a harmless shortcut. It can weaken the claim to the mark later.

Placement rules deserve a section of their own. A brandbook that only names the two symbols still leaves designers guessing where to put either one. Most companies apply the symbol on first, prominent use of a mark within a given piece. The headline of a page. The cover of a document. The first mention in a press release. Later mentions in the same piece can usually drop the symbol without weakening the claim, as long as the first instance carries it clearly.

A short legal line at the bottom of a page or the close of a document does real work that the symbol alone cannot. It states, in a sentence or two, which marks are registered, in which general category, and to whom they belong. One line. For a company with several trademarks in active use across different products, that line keeps individual marks from needing the full symbol treatment scattered through every paragraph of body copy.

Third-party marks need their own quiet rule too. A comparison page, a case study, or an integration announcement that names a partner or a competitor should not apply the same symbol conventions to a mark that belongs to someone else. The safer path is an acknowledgment line. It notes, once, that other marks belong to their respective owners, placed near the legal line rather than repeated symbol by symbol through the copy.

Digital formats complicate a rule written for print. A superscript symbol that renders cleanly in a page layout tool can break, shift baseline, or simply vanish inside a CMS field, a social caption, or a plain-text email subject line. Test it there too. A brandbook worth using states a fallback for each context: real superscript in a web heading, a parenthetical R or TM where superscript fails, and a clear policy on whether social captions carry the mark at all.

None of this needs a long legal appendix nobody opens. A single, well-organized page does the job. The two symbols and when each applies. First-use placement. The legal line wording. The rule for naming a mark that belongs to someone else. That page saves a design team from re-asking legal the same handful of questions on every piece of collateral that goes out the door.

A brandbook full of Pantone codes and printed swatches tells a graphic designer everything and a developer almost nothing. Screens do not render Pantone. They render hex codes, RGB values and CSS variables. A color that looks right on a business card can shift noticeably once it passes through a monitor, an operating system color profile and a compressed image format. Enterprise brand systems that skip this translation step end up with a website close to the brand but never quite matching it.

The fix is a second layer of documentation sitting underneath the visual one. A table of design tokens. Every brand color gets a hex value and, where the product uses a dark mode or several themes, a mapped value for each context. Every type size in the hierarchy gets a pixel or rem value, a line height and a weight. Not a vague label like heading two that a developer has to guess at from a printed spread.

Spacing deserves the same treatment, and it is the piece most brandbooks skip entirely. A print-oriented guide might show generous whitespace around a logo without ever stating the rule as a number. That will not scale. A development team needs a fixed spacing scale, four, eight, sixteen, twenty four pixels and so on, so padding and margin choices across a product stay consistent without every engineer picking a number that felt about right.

Naming the tokens matters almost as much as defining their values. A token called primary-500 or brand-ink communicates intent. Blue1 does not. It survives a future palette change better than a variable named blue1, which stops meaning anything the day the palette shifts even slightly. Consistent naming also lets a design tool and a codebase reference the same token under the same name, so a change made in one place does not have to be copied manually into the other.

Icons, borders, shadows and corner radius values belong in the same document, even though they rarely appear in a printed brandbook at all. A rounded corner that reads as four pixels on one screen and twelve on another quietly signals a mismatch. Two parts of the product were simply not built from the same source. Small gap. Documenting a small, fixed set of radius and shadow values closes it without adding real design work.

None of this needs to live in the printed brandbook itself. Forcing it there usually produces a document nobody actually uses. A separate, living reference works better. Maintained alongside the codebase and updated the moment a value changes, it serves engineering better than a PDF exported once and left to fall out of date within a quarter. The printed brandbook can then point to that reference rather than duplicating it.

The return on this work shows up gradually, not all at once. A product built from a shared token set stays visually coherent across teams and releases without constant manual comparison against a style guide. New engineers pick up brand-correct defaults automatically. The correct value is the only one available in the component library, not something someone remembered to check in a PDF before shipping a feature.

Most brandbooks stop at the logo, the palette for marketing use and maybe a slide template. They say nothing about the charts a product actually ships to customers or the dashboards an internal team looks at every day. Nothing was planned there. Left undocumented, chart colors tend to default to whatever a charting library ships with out of the box. That rarely matches the palette used everywhere else on the same screen.

A chart color order is worth defining explicitly, as a short, ranked list rather than the full brand palette used all at once. Charts need colors that stay distinct from each other across five or six categories, remain readable at small sizes, and do not rely on red and green alone to separate meaning. A portion of any audience cannot reliably tell those two apart. A brand palette built for a logo and a hero banner is rarely built with that constraint in mind. A dedicated chart palette, pulled from the same family but adjusted for contrast, usually works better.

Gridlines, axis labels and typography inside a chart deserve their own small set of rules too. A heavy gridline competes with the data it is meant to support. A light one, set a shade lighter than body text, recedes and lets the data lead. Simple rule. Axis labels should use the same typeface as the rest of the product, not whatever a charting library defaults to. Numbers should follow one consistent format for thousands separators and decimal places across every chart a team ships.

Negative and positive values, thresholds and alerts need agreed treatment as well. These are the places where inconsistency gets noticed fastest. If a red bar means a value below target on one dashboard and a value above target on another, a viewer moving between the two draws the wrong conclusion. Seconds matter here. Fixing the meaning of a color once, in the brand documentation rather than in the head of whoever built each dashboard, prevents that kind of silent error.

Empty states and loading states inside a chart are easy to overlook. Easy to leave looking sloppy, too. A chart with no data yet should show a deliberate placeholder in the brand voice and style, not a blank rectangle or a generic spinner borrowed from a component library with no connection to anything else on the page. The same goes for an error state. Fail on brand. A chart that fails to load should still look like it belongs to the product around it.

None of these rules need to live in a separate document from the rest of the digital brand guidelines. A short section, four or five pages, covering the categorical color order, gridline and label treatment, and the handling of alerts and empty states, gives a product team and a data team a shared reference. Nothing to argue about. Two departments otherwise quietly invent their own conventions and drift apart over successive releases.

The payoff is most visible in reporting that crosses departments. A sales dashboard, a marketing report and a product analytics screen built from the same chart rules read as one connected system, even when three different teams built them independently. Without that shared reference, the same underlying data can look like it came from three unrelated companies. Each with its own idea of a chart.