Skip to content
Community content. Review instructions before giving them to an AI agent — treat modules like open-source code.

Logo Design Brief Rules

Rules for writing a logo design brief that produces usable concepts: brand attributes before visuals, audience and usage contexts, required sizes, color and monochrome requirements, references, and feedback vocabulary.

Mby @markdownersPublished August 21, 2026 · ~4 min read

0 downloads · Used by 0 stacks

A logo brief's most common failure is jumping straight to visual preferences before establishing what the brand actually needs to communicate — a brief built on "make it look modern" produces generic output because it gave the designer nothing specific to solve for. Define the brand problem first; visual direction should be a consequence of that, not a substitute for it.

Brand attributes before visuals

  • Start the brief with 3–5 specific brand attributes (not adjectives lifted from a generic list — "trustworthy," "innovative," "premium" mean nothing without context) tied to what makes this brand actually different from its direct competitors.
  • State what the logo needs to communicate that a competitor's logo currently doesn't — a brief that can't answer "different from what, specifically" hasn't done the strategic work yet, and no amount of visual iteration fixes that gap.
  • Include one sentence on brand personality expressed as a contrast pair ("confident but not corporate," "playful but not childish") — a single adjective is too open to interpretation; a contrast pair bounds the direction concretely.

Audience and usage contexts

  • Name the primary audience specifically (not "everyone" or "millennials" — an actual description of who makes the buying or engagement decision) and what that audience already associates with the category.
  • List every context the logo must function in: app icon, website header, business card, embroidered merch, large-format signage, black-and-white print, social avatar. A mark designed only for a website header often breaks the moment it has to work as a 32px favicon.
  • Flag any context with unusual constraints up front (must work engraved, must work as a single die-cut sticker color, must survive fax/thermal print) — these constraints should shape the concept phase, not surface as a rejected round three revisions in.

Must-work-at-sizes requirement

  • State the smallest required deployment size explicitly (typically a 16–32px favicon or app icon) as a hard constraint, not a nice-to-have — a mark that only reads at large sizes fails a real, common use case.
  • Require that the primary mark remain legible and recognizable at that minimum size without a simplified fallback version, unless the brief explicitly commissions a separate simplified/icon-only lockup for small contexts.
  • Test-fit constraint: any wordmark or lockup with more than a few words needs an explicit brief note on whether a short-form or icon-only version is also required, since a full wordmark rarely survives favicon scale.

Color and monochrome requirement

  • Require every concept to be presented and evaluated in single-color (pure black, and pure white on a dark background) before color is finalized — a mark that only works with a specific color palette holding it together is a fragile mark that will fail on merch, faxes, or engraving.
  • Specify whether an established brand color already exists (hex/Pantone) that the logo must incorporate, or whether palette is open for this project — don't leave this ambiguous, since it changes what a designer explores from the first sketch.
  • If the brand needs to work on both light and dark backgrounds, require reversed/knockout versions be validated at the same review stage as the primary color version, not bolted on afterward.

References: what to include, what to ban

  • Provide 3–5 reference logos with a one-line note on what specifically to take from each (a construction technique, a level of simplicity, a typographic weight) — "I like this vibe" without the specific element is not actionable.
  • Explicitly list direct competitors' logos as references for what to differentiate from, not what to emulate — flag any visual element (a specific icon motif, a color strongly owned by a competitor) that's off-limits for brand-distinction reasons.
  • Ban vague reference requests like "something like Nike but different" without saying which specific property of that reference (the swoosh's motion, the wordmark's confidence) is actually being requested — ambiguous references produce ambiguous concepts.

Deliverables list

  • Specify exact file formats and variants required at handoff: vector source (AI/SVG/EPS), raster exports at defined sizes, color and monochrome (black/white) versions, and horizontal/stacked lockup variants if both are needed.
  • State whether favicon/app-icon-ready exports are in scope as part of this engagement or handled separately — this is a common scope gap that causes rework later.
  • Require a basic usage-rules one-pager (minimum size, clear space, forbidden distortions) as part of the deliverable set if no full brand style guide is planned separately — a logo without any usage guidance degrades quickly once it leaves the designer's hands.

Feedback vocabulary

  • Give feedback on what the mark needs to communicate that it currently doesn't ("this reads as playful, we need more authority") rather than raw aesthetic reaction ("I don't like it") — feedback tied to the brief's attributes is actionable; feedback tied only to personal taste isn't.
  • Avoid "make it pop" and similarly vague directives — name the specific element (weight, spacing, a particular shape) and the specific problem it's causing.
  • Limit feedback rounds to a defined number in the brief itself (e.g., 2 concept rounds, 2 refinement rounds) so both sides know the process has a clear end state rather than open-ended iteration.
Badge

Link back to this module from your own README.

Get it on Markdowners
[![Get it on Markdowners](https://markdowners.com/mdstack-badge.svg)](https://markdowners.com/m/markdowners/logo-design-brief-rules)

Comments (0)

Sign in to comment. Sign in

No comments yet. Be the first to add one.

Discussions about this module

No discussions about this module yet.

Start a discussion