HIFDocs
HIF / Документация / Системы идентичности

Выражение бренда

Статус: нормативная основа и справочник по governance

Версия: 0.1

Этот документ определяет, как идентичность может выражаться через соответствующий HIF интерфейс, не меняя правдивость, семантику, доступность или agency продукта. Он поддерживает один продукт, семейство продуктов, white-label поставку и независимо управляемые бренды.

1. Бренд не является контрактом интерфейса

HIF различает:

  • идентичность: кто говорит или несёт ответственность;
  • репутацию: убеждения, сформированные опытом и коммуникацией;
  • обещание: ожидания, которые организация намеренно создаёт;
  • выражение: воспринимаемые assets и behaviours, используемые для идентификации организации или продукта;
  • trade mark: знак, использование и защита которого зависят от юрисдикции, регистрации, класса и контекста;
  • семантику продукта: objects, commands, states, consequences и permissions;
  • платформенную конвенцию: поведение, на которое люди рассчитывают в среде.

Бренд MAY влиять на выражение. Он MUST NOT переопределять:

  • является ли действие primary, destructive или reversible;
  • сохраняются, передаются, удаляются ли данные и взимается ли плата;
  • смысл success, warning, danger или disabled;
  • нативная семантика доступности;
  • принадлежащие платформе security или permission surfaces;
  • prominence, требуемый для существенных условий;
  • возможность отказаться, отменить, восстановиться или связаться с support.

Визуальная согласованность не может компенсировать нарушенное обещание. Наиболее устойчивое выражение бренда — точное и надёжное поведение продукта.

2. Запись brand strategy

До проектирования assets зафиксируйте:

BRAND-ID и ответственный
юридическое лицо и ответственный продукт
аудитории и контексты
обещание и поддерживающие его свидетельства
positioning и действительные отличия
recognition assets и их текущую силу
portfolio relationship
названия, domains и marks
voice и language policy
experience principles
запрещённые импликации
доступность и культурные ограничения
юрисдикции и юридическая проверка
измерение и дата пересмотра

«Premium», «human», «innovative», «simple», «bold» и подобные прилагательные не являются design specifications. Каждый attribute MUST быть переведён в наблюдаемое поведение, ограниченные правила выражения и counterexamples.

3. Distinctiveness и распознавание

Distinctiveness — способность определить источник без необходимости убеждающего утверждения. Differentiation — существенное воспринимаемое отличие. Они связаны, но не взаимозаменяемы.

Candidate asset SHOULD оцениваться по:

  • uniqueness: ассоциации с одним источником, а не категорией;
  • fame: доле целевой аудитории, которая его распознаёт;
  • fluency: скорости и уверенности правильного распознавания;
  • reach: распознаванию в релевантных языках, способностях и контекстах;
  • flexibility: сохранению при обязательных размерах, носителях и режимах;
  • protectability: legal availability и enforceability, где требуется;
  • provenance: документированным авторству, licence и permitted uses;
  • confusability: риску спутать с другой сущностью, status или control.

Распознавание MUST измеряться без подсказки brand name в вопросе. Сходство mood board или внутреннее голосование предпочтений не доказывает общественную distinctiveness.

Система SHOULD развивать небольшой согласованный набор recognition assets, а не менять каждую переменную. Согласованность ценна лишь пока assets остаются правдивыми, доступными и законно используемыми.

4. Система выражения

4.1. Классы assets

Brand registry MAY включать:

  • юридические и продуктовые названия;
  • wordmarks, symbols и signatures;
  • цвет и цветовые сочетания;
  • typography;
  • мотивы shape, framing и layout;
  • стиль iconography и illustration;
  • photographic direction;
  • motion, transition и spatial behaviour;
  • sound marks, earcons и voice;
  • haptic signatures;
  • язык, vocabulary и narrative;
  • физические материалы и environmental expression;
  • data-visualisation accent и publication style.

Каждый asset MUST иметь определённые purpose и non-purpose. Logo идентифицирует; он не устанавливает безопасность платежа. Brand sound идентифицирует; он не заменяет alarm.

4.2. Запись asset

ASSET-ID и версия
класс asset и semantic purpose
source files и canonical checksum
creator и approval
copyright, trade-mark и patent status
licence, territory, duration и attribution
разрешённые продукты, носители и modifications
minimum/maximum size и exclusion zone
colour-space, gamut и print specifications
варианты light, dark, forced-colour и monochrome
accessible name или alternative
локализация и культурная проверка
устаревшие и замещающие версии

Файлы MUST NOT попадать в production library как анонимные downloads. “Free”, “royalty-free” и “found online” не определяют права на redistribution.

5. Идентичность и semantic colour

Brand colour и семантика интерфейса являются разными token domains:

brand primitive
→ brand expression role

system primitive
→ semantic interface role
→ component role

Brand accent MAY отображаться на action.primary, только если каждое обязательное состояние и ограничение контраста пройдено. Danger MUST NOT отображаться на brand colour только ради визуальной согласованности. И наоборот, brand red MUST NOT заставлять обычный brand decoration выглядеть ошибкой.

Определите collision tests для:

  • brand против danger, warning, success и information;
  • brand decoration против links и focus;
  • logo против security/trust indicators;
  • campaign treatments против disabled или selected state;
  • partner colours против product ownership.

Исправление доступности MAY менять выражение без изменения исходного ресурса бренда. Доступное отображение имеет приоритет в интерфейсе.

6. Typography и бренд

Distinctive typeface MAY поддерживать распознавание, но typography system MUST сначала поддерживать:

  • все обязательные scripts и language features;
  • читаемые UI и long-form text при отрисованных размерах;
  • zoom, text spacing и reflow;
  • достаточные designed weights и styles;
  • однозначные critical characters;
  • надёжный резервный вариант;
  • performance и privacy budgets;
  • права application, embedding, redistribution и server-use.

Display typography SHOULD NOT навязываться dense data, code, user-generated content или extended reading, если она снижает выполнение задачи. Faux bold, синтетический курсив и резервный вариант для отсутствующих глифов MUST проверяться относительно контрактов identity и legibility.

Font licensing MUST фиксировать файлы, версии, foundry/source, licence text, разрешённые channels, условия seat/page-view/application, где применимо, права subsetting/modification и attribution. Название шрифта в design file не является свидетельством licence.

7. Голос, тон и идентичность содержания

7.1. Голос

Voice — стабильное языковое поведение ответственной организации. Определите:

  • отношение к читателю;
  • vocabulary и канонические object/command names;
  • политику sentence и information order;
  • степень формальности;
  • использование первого и второго лица;
  • обращение с неопределённостью и доказательствами;
  • политику language, translation и transliteration;
  • запрещённые claims, stereotypes и rhetorical devices.

Voice MUST сохранять domain vocabulary. Стилистическая вариативность MUST NOT переименовывать один object или command так, чтобы скрывать identity.

7.2. Tone

Tone меняется с ситуацией и последствием. Tone matrix SHOULD покрывать:

СитуацияОбязательное качествоЗапрещённая тенденция
Routine successкраткий, фактическийcelebration, прерывающая работу
Delay или outageоткровенный, конкретный по времениложное успокоение
User errorконструктивный, recoverableобвинение или насмешка
Product failureответственный, actionableперенос ответственности
Danger или lossпрямой, спокойный, явныйшутки, эвфемизм или brand slogans
Consent или purchaseсбалансированный, полныйдавление или asymmetric framing
Sensitive eventуважительный, приватныйпоказная фамильярность

Tone MUST NOT снижать disclosure, точность или prominence существенного последствия.

7.3. Localisation

Канонический смысл предшествует локальному выражению. Localisation MAY адаптировать idiom, examples, reading direction и cultural reference, но MUST сохранять object, command, state, consequence, uncertainty и legal meaning.

Local market team MUST NOT независимо менять ownership identity, consent семантику или словарь состояний. Транскреация требует записи решения от исходного текста к целевому и проверки носителем языка в контексте.

8. Imagery, illustration, iconography и motion

Brand imagery MUST NOT:

  • имитировать controls или system messages;
  • подразумевать несуществующее product state или capability;
  • представлять исключённые группы как token gesture;
  • использовать likeness человека или generated identity без документированного полномочия;
  • скрывать content или обязательные focus/contrast;
  • нормализовать небезопасное или незаконное поведение;
  • скрывать sponsorship, simulation или material editing.

Система illustration и icon MUST документировать grid, stroke/fill logic, optical correction, perspective, corner policy, sizes и accessible alternatives. Style MUST NOT превосходить recognisability общих commands.

Motion MAY выражать continuity и identity, но MUST быть interruptible, performance-bounded и совместимым с reduced-motion preferences. Brand transition MUST NOT задерживать доступ к content, completion, cancellation или error recovery.

Sound и haptic identity MUST оставаться отличимыми от alerts, alarms, confirmation и assistive-technology output. System mute и user preferences имеют приоритет.

9. White-label architecture

9.1. Определение

White-label product имеет одно поддерживаемое семантическое и поведенческое ядро с контролируемыми identity mappings для авторизованных tenants или distributors. Это не коллекция forks, внешний вид которых случайно различается.

Архитектура:

обязательства HIF
→ product/domain semantics
→ platform и component contracts
→ semantic tokens
→ brand-expression adapter
→ approved brand package

Нижние слои MUST NOT переопределять обязательства выше них.

9.2. Brand package

Каждый brand package MUST объявлять:

brand identifier и версия
parent/portfolio relation
ссылки asset registry
expression-token mappings
варианты light/dark/contrast/forced-colour
typography и fallbacks
voice/content layer
domains, manifests и metadata
email, document, print и support identities
licences и expiry dates
compatibility range с core product
доказательства проверки и утверждающие лица

Runtime tenant values MUST валидироваться по schema и allowlist. Raw CSS, HTML, executable templates, произвольные URLs и непроверенные font files MUST NOT приниматься как «branding».

9.3. Non-customisable core

Следующее не настраивается кроме как через утверждённое core change:

  • accessible names, roles, values и state;
  • command meaning и order, где от этого зависит безопасность;
  • destructive, financial, privacy и consent consequences;
  • focus и keyboard model;
  • validation и recovery logic;
  • security origin и disclosure ответственной сущности;
  • пользовательские contrast, motion, font и platform preferences;
  • audit, provenance и support routes, требуемые policy или law.

9.4. Изоляция

Brand packages MUST быть изолированы по tenant и environment. Cache keys, asset paths, generated metadata и server rendering MUST включать разрешённую brand identity. Запрос MUST NOT получать logo, domain, support address, analytics или legal terms другого tenant при failure или cache reuse.

Безопасный резервный вариант — проверенная нейтральная или базовая идентичность, а не последний успешно загруженный tenant.

10. Governance мультибрендового portfolio

10.1. Модель portfolio

Зафиксируйте, является ли отношение:

  • master brand;
  • endorsed brand;
  • sub-brand;
  • independent house of brands;
  • partner/co-brand;
  • temporary campaign;
  • neutral white-label.

Отношение определяет naming, signature, attribution и responsibility. Оно MUST NOT выводиться только из размера logo.

10.2. Права принятия решений

Назначьте:

  • ответственный за бренд;
  • ответственные за продукт и семантику;
  • ответственный за дизайн-систему;
  • уполномоченный по доступности и инклюзивному дизайну;
  • уполномоченный по содержанию и локализации;
  • юридическая, товарно-знаковая и лицензионная проверка;
  • ответственный за безопасность и доменную идентичность;
  • утверждающее лицо арендатора или партнёра;
  • лицо, принимающее окончательное решение, и ответственный за инцидент.

Доступность, правдивое раскрытие и платформенная безопасность имеют право вето на выражение. Ответственные за бренд MAY выбрать другое соответствующее выражение; они MAY NOT отменить обязательство.

10.3. Изменение и выпуск

Каждое существенное brand change MUST указывать:

  • причину и intended recognition effect;
  • затронутые brands, products и jurisdictions;
  • token и asset diffs;
  • semantic collision assessment;
  • доказательства доступности;
  • migration и compatibility;
  • обработку cached/offline/transactional artefacts;
  • measurement plan;
  • rollback и expiry.

Rename или change ownership — системная миграция, затрагивающая domains, certificates, application manifests, stores, notifications, email, documents, support, legal notices, analytics и saved links, а не замена logo.

11. Licensing, права и provenance

11.1. Реестр прав

Поддерживайте rights ledger для каждого внешнего или заказанного:

  • name и mark;
  • font;
  • icon, image и illustration;
  • audio, voice и haptic asset;
  • template и code;
  • palette или dataset;
  • model-generated asset и его inputs, где релевантно.

Фиксируйте:

identity asset и checksum
author, supplier и commissioning entity
source URL/repository и acquisition date
declared и concluded licence
правообладатель авторского права и товарного знака
territory, channel, duration и audience
права modification, sub-licensing и redistribution
attribution и notice
model/property/person releases
срок действия, пересмотр и порядок удаления

SPDX identifiers SHOULD использоваться, когда licence есть в списке SPDX. Неизвестные права MUST представляться неизвестными, а не выводиться как разрешение.

11.2. Provenance

Provenance MUST сохраняться через:

  • format conversion и optimisation;
  • design-tool export;
  • token generation;
  • repository и package publication;
  • преобразование при доставке содержания;
  • localisation и derivative creation;
  • retirement.

Используйте stable identifiers и checksums. C2PA content credentials MAY дополнять внутреннюю запись для поддерживаемых media, но отсутствие credential не доказывает и не опровергает authenticity.

11.3. Trade marks

Trade-mark clearance, registration и correct use требуют квалифицированной проверки в релевантных jurisdictions. HIF не определяет legal availability. Система MUST фиксировать approved spelling, grammar, ownership marks, prohibited alterations, attribution и third-party use conditions.

12. Этика, autonomy и dark patterns

Brand expression MUST NOT использоваться для подрыва свободного и информированного выбора. Запрещены:

  • visual interference в пользу consent, purchase или data disclosure;
  • ложная иерархия между эквивалентными choices accept/refuse;
  • замаскированные advertising или sponsorship;
  • ложные scarcity, countdowns или social proof;
  • скрытые существенные terms, fees или renewal;
  • confirm-shaming и обвинение;
  • obstruction cancellation, deletion, refund или complaint;
  • повторные prompts после устойчивого отказа без существенного изменения;
  • emotional imagery для подавления понимания risk;
  • имитация официальных, security или independent certification signals;
  • personalisation, созданная для эксплуатации известной vulnerability.

Улучшение conversion не оправдывает impaired agency. Experiments MUST включать harm и cancellation measures и MUST NOT рандомизировать людей в design, уже известный как deceptive или unlawful.

13. Измерение

Балансируйте узнаваемость и результаты бизнеса с результатами для людей:

13.1. Recognition

  • unaided и aided recognition;
  • правильная source attribution;
  • confusion с competitors, partners или system states;
  • recognition по размеру, режиму, языку и disability;
  • asset fame и uniqueness во времени.

13.2. Experience

  • task success, error и recovery;
  • понимание ownership и consequence;
  • барьеры доступности;
  • trust calibration относительно реальной reliability;
  • успех refusal, cancellation и support;
  • complaints и identity/security incidents.

13.3. System health

  • unlicensed или expiring assets;
  • unknown provenance;
  • cross-tenant leakage;
  • nonconforming token overrides;
  • устаревший transactional material;
  • design/code/content drift;
  • local exceptions и time to resolve.

Preference, conversion или spontaneous adjectives MUST NOT быть единственной мерой качества brand system.

14. Протокол проверки

14.1. Strategy

  • Ответственная организация, аудитория, обещание и доказательства указаны.
  • Distinctiveness отделена от substantive differentiation.
  • Product semantics и platform conventions защищены.
  • Portfolio и co-brand relationships явны.
  • Prohibited implications и harms определены.

14.2. Expression

  • Каждый asset имеет purpose и non-purpose.
  • Recognition сохраняется при обязательных размерах, носителях, режимах и языках.
  • Проверены collisions brand и semantic colour.
  • Типографика покрывает обязательные письменности, доступность и производительность.
  • Voice и tone сохраняют object, command, state и consequence.
  • Imagery правдиво представляет людей и capability.
  • Motion, sound и haptics учитывают user preferences.

14.3. White-label engineering

  • Brand package соответствует schema и compatibility range.
  • Tenant input не может внедрять arbitrary code или unapproved URLs.
  • Базовая семантика и доступность не настраиваются.
  • Cache, metadata, domains, support и legal identity изолированы.
  • Проверен нейтральный резервный вариант при отказе.
  • Матрицы снимков экрана, взаимодействия и доступности проходят для каждого выпущенного сочетания бренда и режима.

14.4. Права и этика

  • Rights ledger и checksums полны.
  • Проверка товарного знака и юрисдикции зафиксирована.
  • Процедуры attribution, expiry и takedown работают.
  • Consent, purchase, cancellation и deletion визуально сбалансированы.
  • Ни одна brand treatment не имитирует state, authority или certification.
  • Переопределения доступности имеют приоритет и остаются распознаваемыми.

14.5. Выпуск

  • Owners и approvers подписали change record.
  • Assets, tokens, code, content и documentation имеют одну версию.
  • Offline, transactional, print и support surfaces включены.
  • Измерение включает замешательство, вред и доступность.
  • Rollback восстанавливает полную, юридически допустимую identity.

15. Источники

Все источники являются англоязычными оригинальными исследованиями, стандартами, законодательством или официальными спецификациями. Дата обращения: 30 июля 2026 года.