---
name: branding
description: Use this skill when a designer needs to keep a product screen or feature consistent with the brand — applying brand identity, deciding what the brand dictates versus what the design system dictates, checking whether a solution stays on-brand, or working out how the brand voice shows up in the UI. Trigger on requests like "is this on-brand", "does this fit our identity", "where do I use the logo here", "brand vs design system — what wins", "how should the brand voice sound on this screen", "we're showing this to a client, does it look like us", or any mention of brand, identity, brand guidelines, brand voice in a product-design context. This skill applies branding to product interface work — it does NOT cover creating a brand from scratch, rebranding, logo-craft, illustration, marketing campaigns, or product/feature naming.
version: 1.0.0
language: ru
domain: branding
status: stable
last_updated: 2026-05-14
depends_on: []
related: [graphic-design, ux-writing, design-systems]
tags: [brand, identity, brand-voice, brand-guidelines, consistency, brand-vs-ds]
mirrors: null
---

# Брендинг для продуктовой работы — как держать продукт «в бренде»

## Когда использовать

Скилл нужен, когда дизайнеру надо свериться с брендом в продуктовой задаче — не создать бренд, а **не нарушить уже существующий**. Типовые триггеры:

- «Это в бренде или нет?»
- «Вписывается ли решение в нашу айдентику?»
- «Где здесь уместен логотип, а где нет?»
- «Бренд говорит одно, дизайн-система — другое. Что главнее?»
- «Как голос бренда должен звучать на этом экране?»
- «Показываем клиенту — выглядит ли это как мы?»
- На ревью замечание звучит как «не похоже на наш продукт», «выбивается из айдентики».

**Скилл не покрывает:** создание бренда с нуля, ребрендинг, брендинговые стратегии, логотип-дизайн как ремесло, иллюстрации, брендовые key visual, маркетинговый брендинг и рекламные кампании. Нейминг продуктов и фич — тоже вне scope (см. «Связи»). Большая часть этого — вне anti-cred Zhandos («не делаю иллюстрации», «не углубляюсь в маркетинг», см. `people/Zhandos/profile.md`) и вне продуктовой дизайн-работы. Если запрос про создание или переделку бренда — честно скажи, что это вне scope скилла и вне фокуса дизайнера.

## Что делает

Помогает продуктовому дизайнеру **удержать экран или фичу «в бренде»**: применять айдентику консистентно, понимать, что диктует бренд, а что — дизайн-система, и проверять решение на соответствие. На выходе — не «сделай брендово», а конкретный разбор: что в решении соответствует бренду, что выбивается, где проходит граница между брендом и DS. Глубина — принципы и чек-листы, без теории брендинга и моделей brand equity.

## Контекст и принципы

Базовая идея: **бренд для продуктового дизайнера — это не логотип, а система узнаваемости.** Визуальный язык и голос вместе делают так, что пользователь узнаёт продукт как один продукт одной компании. Задача дизайнера — не «добавить брендинг», а не разрушить эту узнаваемость своей задачей.

Четыре принципа:

1. **Бренд — это узнаваемость, а не украшение.** «Поставить логотип» — не брендинг. Брендинг — это когда экран ощущается частью одного продукта: тот же визуальный язык, тот же голос, те же паттерны. Логотип — лишь один из носителей, и не самый важный внутри продукта.
2. **Консистентность бренда > локальная находка.** Если решение красивое, но выбивается из остального продукта — оно вредит бренду. Это прямое продолжение командного принципа «консистентность с другими экранами продукта» (`team/design-principles.md`) — на уровне всего продукта, не одного экрана.
3. **Бренд и дизайн-система — разные слои, их нельзя путать.** Бренд отвечает на «как нас узнают» (айдентика, голос, характер). DS отвечает на «из чего собран интерфейс» (компоненты, токены, паттерны). Большинство продуктовых решений живёт в слое DS, и бренд туда не лезет. Путаница этих слоёв — частый источник споров и неверных решений.
4. **Бренд служит продукту, а не наоборот.** В B2B HR Tech продукт — рабочий инструмент. Брендовое решение, которое мешает работе (отвлекает, занимает место, замедляет) — плохое брендовое решение. Это то же, что командный принцип «решение упрощает пользователю, а не команде».

## Метод

### Шаг 1. Определи, это вопрос бренда или нет

Прежде чем «сверяться с брендом» — проверь, что задача действительно про бренд. Если проблема в логике флоу — это `product-design`. Если в визуальной иерархии экрана — `graphic-design`. Если в формулировке текста — `ux-writing`. Бренд — это про **узнаваемость продукта как целого**: «выглядит и звучит ли это как наш продукт». Не каждый визуальный или текстовый вопрос — брендовый.

### Шаг 2. Разведи, что здесь от бренда, а что от дизайн-системы

Это ключевой шаг. По каждому элементу задачи ответь: **это диктует бренд или DS?**

- **Слой бренда:** логотип и его использование, фирменные цвета как идентичность, фирменная типографика, общий характер и голос, тон коммуникации.
- **Слой DS:** компоненты (кнопки, инпуты, модалки), токены (spacing, радиусы, размеры), функциональные паттерны, состояния компонентов.

Если решение спорит с брендом — менять надо в слое бренда. Если спорит с DS — в слое DS. Большинство продуктовых правок — это DS, а не бренд. Когда дизайнер думает, что «правит бренд», а на деле правит компонент — это сигнал, что слои спутаны.

### Шаг 3. Проверь визуальную узнаваемость

Смотри на экран и спрашивай: **узнаётся ли это как продукт MyStartups?**

- Цвета — фирменная палитра или взяты со стороны?
- Логотип, если он на экране, — в правильном месте, правильного размера, не искажён?
- Общее впечатление консистентно с другими экранами продукта?

Важная оговорка для команды: визуальный бренд-гайд MyStartups пока не оцифрован (см. раздел «Ограничения команды»). Поэтому на этом шаге скилл работает на общих принципах узнаваемости, а конкретику (точные цвета, версии логотипа) дизайнер сверяет с фактическим источником бренда сам.

### Шаг 4. Проверь голос бренда

Голос — половина бренда, и он-то как раз зафиксирован: `team/brand-tone.md`. На этом шаге сверь тексты экрана с бренд-голосом:

- Тон соответствует характеру из `brand-tone.md` (без канцелярита, спокойный, чёткий, понятный)?
- Регистр и обращение выдержаны (формальный, на «вы»)?
- Нет ничего из стоп-листа `brand-tone.md` (инфантильные формулировки, англицизмы, обвинение пользователя)?

Если задача в основном про тексты — это уже домен `ux-writing`, branding только проверяет «звучит ли это как бренд». Подробную работу с микрокопи передавай в `ux-writing`.

### Шаг 5. Проверь двойственный контекст AM / рынок

Специфика WTM (и потенциально других продуктов): продукт делается под Astana Motors как captive-клиента, но брендируется как MyStartups, с прицелом на выход на рынок РК (`team/current-projects.md`). На этом шаге спроси: **решение «звучит как MyStartups для рынка» или «как удобно конкретно AM»?**

- Брендовое решение не должно завязываться на специфику одного клиента так, что для другой компании на рынке оно развалится.
- Если решение работает только в логике AM — это риск для бренда продукта как рыночного.

### Шаг 6. Сформулируй разбор, а не вердикт

Не «брендово» и не «не брендово». По каждой найденной проблеме: **что выбивается → слой бренда или DS → что поменять.** Если проблем несколько — приоритизируй: нарушение узнаваемости (чужие цвета, искажённый логотип) важнее, чем мелкие шероховатости голоса.

## Формат вывода

Когда проверяешь решение на соответствие бренду, выдавай структурированный ответ:

```
## Бренд-проверка: [название экрана / фичи]

### Что соответствует бренду
[что в решении работает на узнаваемость — визуально и по голосу]

### Что выбивается
1. [проблема] — слой [бренд / дизайн-система]
   Почему вредит: [короткое объяснение — что теряется в узнаваемости]
   Что поменять: [конкретное действие]
2. [проблема] — ...

### Бренд vs DS — где что
[если в задаче путаются слои — явно развести: это решает бренд, это решает DS]

### Контекст AM / рынок
[если релевантно — завязано решение на специфику AM или работает как рыночное]

### Оговорка про источник бренда
[визуальный бренд-гайд не оцифрован — какую конкретику дизайнер должен сверить сам]
```

Не выдавай абстрактных советов («сделай брендовее», «добавь айдентики»). Каждая правка — привязана к конкретному элементу и конкретному слою (бренд или DS).

## Анти-паттерны — чек-лист брендовых ошибок

Прогоняй решение через этот список. Попадание — повод для правки.

- **«Логотип = брендинг».** Поставить логотип и считать, что экран «в бренде». Узнаваемость — это весь визуальный язык и голос, а не один элемент.
- **Чужие цвета.** На экране цвета не из фирменной палитры — взяты «по вкусу» или из чужого продукта. Прямое разрушение узнаваемости (и нарушение командного правила про токены и палитру из `team/design-principles.md`).
- **Спутаны слои бренда и DS.** Дизайнер «правит бренд», а на деле правит компонент — или наоборот, лезет в айдентику там, где вопрос решается на уровне DS.
- **Локальная находка вместо консистентности.** Красивое решение, которое выбивается из остального продукта. Для бренда это минус, а не плюс.
- **Голос не сверен.** Тексты экрана живут сами по себе, не сверены с `brand-tone.md` — характер, регистр или стоп-лист нарушены.
- **Решение «только для AM».** Брендовое решение завязано на специфику Astana Motors так, что как рыночный продукт MyStartups оно не работает.
- **Брендинг мешает работе.** Брендовый элемент (крупный логотип, фирменный баннер, декоративная плашка) занимает место и отвлекает на рабочем экране. Бренд служит продукту, а не наоборот.
- **Искажение логотипа.** Логотип растянут, перекрашен, поставлен на пёстрый фон, уменьшен ниже читаемости. Носитель айдентики, который нельзя трогать произвольно.

## Ограничения команды (важно — читать всегда)

Контекст MyStartups определяет, какие советы по брендингу реалистичны. Это не универсальная теория брендинга — это про то, в каких рамках работает команда прямо сейчас.

### Визуальный бренд-гайд не оцифрован

Это главное ограничение скилла. В репозитории есть `team/brand-tone.md` (голос бренда), но **визуального бренд-гайда — логотипы, фирменные цвета, типографика, правила использования — в репозитории нет** (`team/brand-guidelines.md` не создан). Это значит:

- **Скилл работает на общих принципах узнаваемости, а не на конкретике MyStartups.** Он может сказать «цвета должны быть из фирменной палитры», но не «фирменный цвет — такой-то».
- Когда разбор упирается в конкретику (точный цвет, версия логотипа, защитное поле) — честно говори: «это нужно сверить с фактическим бренд-гайдом MyStartups, в репозитории его пока нет».
- Не выдумывай конкретику бренда. Лучше честно указать пробел, чем подставить правдоподобное, но неверное значение.
- Когда `team/brand-guidelines.md` будет создан — скилл актуализируется: общие принципы останутся, добавится привязка к конкретике. Это зафиксировано как отложенная задача.

### Нет маркетинга и нет бренд-команды

В команде нет отдела маркетинга и нет выделенной бренд-команды (см. `team/profile.md`). Бренд продукта поддерживают сами продуктовые дизайнеры. Это значит:

- Скилл должен делать дизайнера **самостоятельным** в проверке «в бренде или нет» — спросить бренд-менеджера не у кого.
- Но и не делать вид, что дизайнер заменяет бренд-стратега. Создание бренда, ребрендинг, брендинговая стратегия — за рамками и скилла, и роли. Для этого нужен внешний ресурс.
- Брендинг здесь — это «не сломать существующее», а не «развивать бренд». Развитие бренда — не задача продуктового дизайнера в этой команде.

### Бренд MyStartups молодой

Компания на стадии Series A (`team/profile.md`), бренд молодой и ещё формируется. Это значит:

- Не все брендовые вопросы имеют готовый ответ — часть айдентики просто ещё не зафиксирована. Это нормально для этой стадии.
- Когда ответа в бренде нет — это не повод выдумать его, а повод поднять вопрос: зафиксировать решение в бренд-гайд (когда он появится), а не молча решить на своём экране.

### Двойственный контекст AM / рынок

WTM делается под Astana Motors как captive-клиента, но с прицелом на выход на рынок РК как универсальный продукт (`team/current-projects.md`). Для брендинга это значит:

- Бренд продукта — MyStartups, не Astana Motors. Это уже зафиксировано в `current-projects.md` и важно держать.
- При брендовых решениях держи в голове оба режима: «как это для AM» и «как это для рынка». Решение, завязанное только на AM, — риск для бренда продукта как рыночного.

## Связи

- **Predecessor:** `skills/product-design` — если вопрос в логике фичи, а не в узнаваемости, сначала решается она; бренд-проверка идёт поверх готового продуктового решения.
- **Successor:** `mirrors/anthropic/design-critique` — когда бренд-соответствие проверено, общее ревью смотрит экран целиком перед lead review у Екатерины.
- **Связка с `skills/graphic-design`:** цепочка из `ROUTER.md` — `branding → graphic-design → ux-writing`. Брендинг задаёт рамку узнаваемости, графдизайн наводит визуальный порядок внутри неё, ux-writing доводит тексты.
- **Связка с `skills/design-systems`:** граница «бренд vs DS» — общая зона. Когда разбор упирается в «это вопрос компонента или токена», это переход в домен design-systems.
- **Связка с `ux-writing` и `team/brand-tone.md`:** голос бренда живёт в `brand-tone.md`, детальная работа с микрокопи — в `ux-writing`. Branding только проверяет «звучит ли как бренд», не пишет тексты.
- **Вне scope — нейминг:** названия продуктов и фич часто относят к брендингу, но в этом скилле нейминг сознательно не покрывается (нет маркетинга, нет бренд-команды). Если задача про нейминг — скажи, что это вне scope, и не пытайся решить «по аналогии».
- **Conflicts:** прямых конфликтов нет. Но обязательные стандарты из `team/design-principles.md` (a11y, токены вместо чужих палитр) побеждают любое брендовое решение. Нельзя «усилить бренд», нарушив доступность или подставив цвет вне токенов DS.

## Источники

- Marty Neumeier — «The Brand Gap» (бренд как восприятие, а не айдентика)
- Alina Wheeler — «Designing Brand Identity» (системы айдентики, консистентность)
- `team/brand-tone.md` — зафиксированный голос бренда продукта MyStartups
- `team/design-principles.md` — командное правило консистентности и работы с токенами/палитрой
