Глубина,
которую видно.

Снаружи — ясный продукт. Внутри — маркетинг, архитектура, инженерия и защита. ИИ ускоряет работу; за качество и результат отвечают люди. Стиль выражает глубину, спокойную уверенность и точность.

Эталон — утверждённая сцена айсберга с водой. Она не меняется: при споре о форме, свете и композиции сравниваем с ней. Прежние альтернативные айсберги и метафоры не используются.

В состоянии покоя айсберг остаётся чистым кристаллом с той же водой, силуэтом, материалом и атмосферой. Интерфейсы, дороги и инженерные схемы снаружи не рисуем: внутреннее устройство раскрывается только по наведению, фокусу или выбору уровня.

Производные кадры сохраняют исходные силуэт, воду, ракурс и композицию. Их не усиливают CSS-размытием и не дополняют внешними линиями или псевдоинтерфейсом.

Внутреннее устройство читается как часть материала, а не как вставленный виджет. Вместо бесконечных световых сигналов используется короткий пространственный переход при раскрытии уровня: заметное действие без постоянной нагрузки.

Логотип существует в одном мастер-файле SVG. Он векторный, не набран шрифтом. Четыре знака: А без перекладины, V, А без перекладины, T. Не вводим кириллический вариант и не перепечатываем его текстом.

• ViewBox 332 × 78. Масштабирование только пропорциональное.
• Толщина штриха 5,4 в координатах мастера. Не редактировать для меню или footer.
• Геометрия мастер-файла: M12 66 40 10 68 66 M96 10 124 66 152 10 M181 66 209 10 237 66 M264 10H320 M292 10V66.
• Светлая и тёмная версии — тот же мастер, меняется только цвет. Это не разные логотипы.
• На светлом фоне Ink #20282C; на тёмном Ice White #F6F7F7.
• В меню ширина 135 px на desktop, 105 px на телефоне. Рекомендованный минимум полного слова — 104 px. Если места меньше, меняем компоновку меню, а не сжимаем знак.
• Охранное поле — не менее ¼ высоты всей SVG-области со всех сторон. В тесном меню соблюдать минимум 12 px.
• Не растягивать, не скруглять углы, не утолщать, не добавлять перекладины А, градиент, тени или объём.
• Большой полупрозрачный знак может быть частью фоновой композиции с непрозрачностью 4–6%; он не заменяет основной логотип.
• Кристалл в форме арки — иллюстрация, не второй знак и не favicon. Новый самостоятельный символ не утверждён.
• Редакционное название в тексте — AVAT или AVAT Studio, набранное основным текстовым шрифтом. Это упоминание компании, не замена логотипа.

Утверждённая пара — Geologica + Inter

Выбор команды: Geologica 400/500 для заголовков и Inter 400/500/600 для текста и интерфейса. Основные начертания заголовков — Regular и Medium. Geologica 600 допускается только для короткого акцента, не для всей страницы.

• Geologica 400 — первый экран, крупная фраза, крупные цифры.
• Geologica 500 — H2/H3, названия услуг и кейсов.
• Geologica 600 — короткое выделение, когда одного контраста недостаточно. Не набирать им длинный SEO-заголовок.
• Оси зафиксированы: SHRP 50, CRSV 0, slnt 0; насыщенность меняется через font-weight.
• Заголовки всегда прямые. Наклонные оси Geologica не используются в фирменной системе. Не включать искусственный italic, transform-skew или шрифт с засечками для одного слова.
• Geologica и Inter распространяются по открытой лицензии SIL Open Font License.

Шрифт должен поддерживать айсберг и содержание. Узнаваемый рисунок, точные интервалы и масштаб дают характер; декоративная сложность в каждом слове не нужна.

Onest, Unbounded, Exo 2 и прежний Manrope остаются в сравнительном разделе и истории. На новых страницах их не подключаем. Рабочая страница загружает только Geologica, Inter и отдельный настоящий Inter Italic. Кириллица и символы проверены.

Текст и интерфейс — Inter

Inter 400 — абзацы, описания и формы. Inter 500 — навигация, кнопки, подписи полей. Inter 600 — короткое выделение, имя автора, ключевой факт. Для абзацев запрещён сплошной 600/700.

Inter Italic 400 — настоящий курсив для короткой цитаты или редакционного выделения внутри основного текста. При необходимости имя/акцент в такой цитате допускает Inter Italic 500. Курсив не используется в меню, кнопках, таблицах, цифрах KPI и крупных заголовках.

Сочетания:

Обязательны font-synthesis: none и реальные файлы начертаний. При ошибке загрузки сначала восстанавливаем файлы, а не разрешаем браузеру рисовать наклон или жирность.

Проверены русские прописные и строчные буквы, Ё/ё, Й/й, ₽, №, тире и кавычки. В визуальном брендбуке есть живые строки с разными весами и курсивом. На Windows и Android возможны отличия сглаживания — геометрия и начертания остаются теми же.

Размеры и набор

Основной текст статьи или подробного раскрытия — обычно 65–75 символов в строке; это не ограничение ширины вступления раздела. Не разрежать кириллические абзацы. Капитель допускается только в коротких служебных подписях. Не разрывать слова искусственно. На широком экране H1 не должен заходить на объект. Длинный SEO-заголовок адаптируем переносами и размером, не сокращением содержания.

Композиция заголовков — обязательное правило

• Заголовок раздела занимает всю доступную ширину контентного контейнера с сохранением полей.
• Вводный абзац получает всю ширину контентного контейнера без max-width в символах или пикселях. На широком экране увеличивать кегль до 22–23 px, как указано в главе о сетке и компонентах. Короткий текст естественно заканчивается раньше правого поля. Абзац не ограничивают левой половиной сетки и не переносят в правую колонку. Проверять ширину на 1728, 2048 и 3440 px. «Во всю ширину» означает пространство для текста, а не растяжение букв. Мера строки для статей, карточек и подробных раскрытий остаётся отдельным правилом.
• Подзаголовок или вводный абзац располагается под заголовком, с читаемой длиной строки. Порядок: большой заголовок, под ним объяснение, затем содержание. Заголовок и объяснение выравниваются по одной левой направляющей; центрирование допускается только в специально собранной композиции целиком, не случайно для одного элемента.
• Блоки страницы не нумеруем и не подписываем. Над заголовком раздела или карточки не ставим ни номер, ни название блока: «01 / Для кого», «Блок 2. Услуги», «Принцип», «Наши услуги». О чём блок, говорит сам заголовок. Подпись над ним только повторяет его мелким капсом и выдаёт страницу, собранную нейросетью по шаблону. Во вкладках и оглавлении номеров тоже нет.
• Номер оставляем там, где порядок и есть смысл: у шагов процесса, которые идут строго друг за другом, и у отметок на экране продукта, которые связывают точку на картинке с пояснением. Простая проверка: если блоки можно поменять местами и ничего не сломается, номера им не нужны. Короткая подпись уместна под картинкой, у поля формы и в интерфейсе продукта, где она добавляет то, чего нет в заголовке.
• Переносы следуют смысловым группам. Не оставлять одно короткое слово в последней строке: «…поискать другого / подрядчика» — ошибка; «…кому лучше / поискать другого подрядчика» — возможная осмысленная композиция.
• На desktop заголовок течёт естественно на всю доступную ширину. Не превращать каждую смысловую группу в блочный span и не ставить постоянные <br>, из-за которых строка заканчивается на половине контейнера. Сначала дать тексту ширину и подобрать масштаб; text-wrap: pretty может улучшать окончания строк. text-wrap: balance применять после визуальной проверки, если он действительно улучшает конкретную композицию.
• Ручной смысловой перенос допустим только для проверенного размера экрана, когда без него возникает плохой баланс или одиночное слово. На более широком экране такой перенос должен исчезать, если фраза естественно помещается в строку. Неразрывную группу ограничивать несколькими словами и снимать, если она создаёт переполнение на телефоне.
• Не обрезать заголовок маской, фиксированной высотой, многоточием или line-clamp. Не вставлять искусственные дефисы. Изменение формулировки — отдельная редакционная правка с проверкой смысла и SEO, не способ замаскировать плохую вёрстку. Проверять отсутствие склеенных слов вокруг <br>.
• Первый экран с крупным арт-объектом и компактная карточка — осмысленные исключения: заголовок использует полную ширину своей области. Описание всё равно следует под ним. Исключение не становится стандартом всех разделов.

Основной объём сайта — светлый, но длинная страница не превращается в непрерывную белую ленту. Paper, White и Mist формируют спокойную основу; Depth объединяет инженерные разделы в цельную главу; небольшая насыщенная панель Oxide или Oxide Deep отмечает важный смысловой поворот, сохраняя вокруг нейтральное пространство. Warm Paper добавляет локальную паузу рядом с человеком или предметным объяснением. Это нейтральный тёплый белый, а не возвращение розового Oxide Mist и не новая песочная тема интерфейса. Чередование подчиняется содержанию, а не правилу «следующий блок — другой цвет». Реальные кейсы, фотографии, масштаб и свободное место создают дополнительные остановки для взгляда. Сам айсберг получает контраст за счёт материалов и света, без цветных неоновых свечений.

Depth — цвет тёмного блока со скриншота команды. Это #111C23, не Ink #20282C. Paper — прохладный почти белый #F6F7F7. Эта пара принята как основа. Визуализация реальных проектов, фото людей и видео сохраняют свои цвета. Не перекрашивать работу клиента ради монохромности.

Тёплый акцент из «Дюны»: Oxide

Oxide вырос из красно-коричневого рельефа стены. Это адаптация материала для интерфейса, а не точный цвет освещённой поверхности. Тёплый зал не заменяет айсберг.

Контраст Oxide / Paper — 7,48:1, Oxide / White — 8,03:1. Эти пары подходят для обычного текста по порогу 4,5:1. Светлая розоватая подложка Oxide Mist исключена из активной композиции; для спокойного общего фона использовать Paper или Mist, для локальной человеческой паузы — Warm Paper, для насыщенного тёплого акцента — Oxide / Oxide Deep. Не переносить Oxide на Depth для мелких надписей: там нужен светлый текст.

Масштаб тёплого акцента

Oxide и Oxide Deep не заливают подряд CTA, историю команды и цитату в длинную сплошную полосу. На широком экране это ограниченная панель или вставка, рядом с которой остаётся нейтральное поле, изображение или другое спокойное содержание. Как стартовый композиционный ориентир — примерно половина ширины блока или меньше; это не жёсткий CSS-процент и не квота. Проверять визуальный вес вместе с высотой панели: узкая, но очень длинная бордовая колонна тоже перегружает страницу.

На телефоне панель может занять ширину контентной колонки, сохраняя внешние поля, компактность и смысловую самостоятельность. Не переносить desktop-ограничение в буквальные 50% узкого экрана. Для крупных продолжительных глав используется Depth; для спокойной базы — Paper или Mist. Минеральное изображение Oxide остаётся самостоятельным изображением и не служит основанием покрасить все соседние блоки.

Латунь: материал, а не один HEX

По референсу команды выбран сатинированный латунный материал с медным подтоном: базовый тон #A07436, тёмная тень и мягкий светлый блик. Он сочетается с Depth и оживляет холодные поверхности. Прежняя бронза остаётся архивной альтернативой. Не использовать два металла на одном экране.

Латунь — редкая ценная деталь: тонкое подчёркивание, короткий разделитель, узкая кромка или небольшой фрагмент материала. Не окрашивать латунью целое слово, строку или крупный заголовок. Заголовки и основной текст остаются Ink на светлом и Depth Text на тёмном. Латунь не используется в логотипе, всей навигации и каждой кнопке. Допустимо изредка выделить короткую служебную подпись на Depth плоским оттенком #C69752 из утверждённого материала, при контрасте не ниже 4,5:1. Градиент — только для нетекстовых деталей; в мелком тексте блик недопустим. Браузерные образцы в брендбуке — CSS-пробы отражений и фактуры, не фотография и не готовая 3D-модель. Шрифт с засечками и варианты логотипа на цветовой картинке не заменяют утверждённые Geologica и мастер SVG.

Латунь должна занимать лишь следовую долю экрана: одна тонкая деталь рядом с главным акцентом, а не несколько конкурирующих золотистых пятен. Образец материала в палитре — демонстрация, не пропорция для сайта. Не задавать квоту, которую нужно заполнить металлом. Depth формирует крупные смысловые главы, Oxide — ограниченные акценты, латунь точечно подчёркивает отдельную деталь. Не красить все разделы по очереди. Айсберг, воду и кристаллы не перекрашивать в металл.

Ошибка формы может использовать #8B3530 только как функциональный статус с явным текстовым пояснением. Oxide не обозначает ошибку автоматически. Успешное действие объясняется текстом; цвет не единственный носитель смысла.

Основной мотив — материальная глубина и точная обработка. Прозрачные природные грани, серебристое преломление, плотный камень, сатинированный металл и минеральная поверхность принадлежат одной системе. Вода и мягкая светлая атмосфера исходного айсберга остаются эталоном главной. На остальных страницах не нужно повторять айсберг или кристалл: выбираем материал по содержанию.

Можно: тонкие прямые линии 1 px, аккуратные выноски с точкой 3–4 px, номер слоя, осмысленный разрез, фрагмент кристалла или базальта, точное металлическое соединение, минеральная фактура и спокойная тень реального объекта.

Не используем: случайные кольца и орбиты, шестерёнки, шарики, звёздочки, эмодзи-декор, цветные провода, псевдо-CRM, матричный дождь, галактики, пластик, 3D-буквы и случайные материалы вне утверждённой библиотеки. Круг допустим для фотографии человека, служебной точки или элемента настоящего интерфейса; он не становится отдельным декоративным мотивом.

Если в композиции нужен арт, на одном экране достаточно одного главного объекта или одной материальной сцены. Продуктовый экран, схема и фотография могут быть самостоятельным ведущим визуалом без материала. Не собирать коллаж из всей библиотеки. Материал не заменяет иконку каждой услуги и не повторяется около каждого абзаца. Для длинной статьи достаточно одного небольшого акцента у начала или конца. Локальная фактура изображения не определяет цвет фона интерфейса.

Навигационные знаки раскрываемых материалов

Для группы из четырёх редакционных материалов главной допускается одна серия лаконичных архитектурных SVG-знаков: соединение двух плоскостей (вайбкодинг), разрез из трёх слоёв (открытый стек), стык двух систем (ИИ-интеграция) и четыре угла области поиска (GEO). Это указатели на материалы, а не отдельные логотипы, картинки услуг или повторяемый декор FAQ. Один знак на один раскрываемый материал; все четыре имеют одинаковое поле 64 × 64 px и базовый штрих 1,5 px с прямыми завершениями. Основной штрих — Ink на светлом или Depth Text на тёмном, только короткий функциональный стык — плоская латунь #A07436. Не применять градиент, блеск, стеклянную 3D-модель, цветные заливки, тень и эмодзи. Знак декоративен для скринридера; действие объясняют текст и нативный элемент <details>. При раскрытии материал получает полноценную читабельную область; на телефоне знаки уменьшаются до 48 px. Серия не переносится автоматически на кнопки, FAQ и все 100 страниц.

В v1.16 отдельно вводятся малые функциональные пиктограммы для объяснения оплаты, доступа, данных, интеграции, проверки и запуска. Их поле 24–32 px, назначение и правила описаны в главе о сетке и компонентах. Это другая роль: маленький знак помогает найти понятие рядом с текстом, а крупный редакционный знак ведёт в материал. Одна серия не заменяет другую.

В v1.17 как локальный неутверждённый эксперимент добавлены крупные смысловые знаки: диалог с человеком, сборка продукта, связь систем и проверяемый результат. Это отдельная серия иллюстративных SVG в поле 160 × 160 px: прозрачные стеклянные плоскости с читаемым контуром, один тёплый акцент Oxide, светлая грань Ice Light и редкая латунная кромка. У каждого знака есть узнаваемое действие, а не абстрактный кристалл. Знак поддерживает заголовок и конкретный пример; он не подменяет работающий экран, фото человека или реальные данные. Пока не переносить их на страницы услуг: заказчик сомневается в этой серии. Если отдельный знак впоследствии будет утверждён, показывать только в конкретном смысловом блоке; одинаковые четверки по всем страницам создадут ощущение шаблона. Стекло допустимо только в самом иллюстративном предмете, не под текстом или контролами. На телефоне рисунок 96–120 px, подпись остаётся HTML. Четыре существующих редакционных знака выше сохраняют своё строгое правило без градиента.

Тепло создаётся прежде всего людьми и предметным контекстом: настоящее фото специалиста с именем и ролью; короткое объяснение выбора; кадр продукта в действии; локальная тёплая подложка. Крупный смысловой знак пока не входит в утверждённый набор. Не делать «человечность» из выдуманной цитаты, улыбчивого стокового лица или цветной пиктограммы возле каждого тезиса. Чередовать эти роли с тихими главами: после тёплого человеческого фрагмента может идти ясная инженерная схема или продуктовый экран.

Кристаллические объекты

• crystal-spire — вытянутый одиночный кристалл. Боковой акцент первого экрана услуги или заключительного CTA.
• crystal-cluster — связанная группа из трёх форм. Команда, комплексная услуга, несколько связанных направлений.
• crystal-section — прозрачный срез над минеральным основанием. Архитектура, инженерия, объяснение подхода.
• crystal-arch — кристаллическая арка. Обложка кейса или переход между главами; не новый логотип.

Файлы не заменяют оригинальный айсберг на главной. Перед применением проверять объект на светлом и тёмном фоне: полупрозрачные края и отражения дают разные впечатления. Не добавлять поверх растрового блика второй CSS glow.

Расширенная библиотека материалов

Единый свет, физически правдоподобные поверхности, спокойная композиция и точная работа с масштабом связывают разные материалы. Библиотека предназначена для системы примерно из 100 страниц, а не для размещения всех шести образцов на главной. Каждый материал раскрывает конкретную сторону работы студии.

Как применять библиотеку на разных страницах

1. Сначала выбрать смысл и подходящий способ объяснения: экран, действие в демо, схема, рабочий материал или человек. Если материальная поддержка действительно нужна, выбрать один материал: для интеграций подходит соединение, для надёжности — базальт, для подхода — минеральный Oxide. Это визуальные метафоры, не доказательства результата и не изображения реальных клиентских работ. Материал не назначается ведущим изображением услуги по умолчанию.
2. Использовать мастер в разных форматах: широкая полоса, предметный фрагмент рядом с содержанием, компактная обложка. Кадрировать без растяжения и без потери главной грани или соединения. Один ассет можно повторить в другой роли, но соседние разделы не должны выглядеть копиями.
3. Для длинной страницы достаточно не более одной ведущей материальной сцены и, если нужен, одного небольшого материального акцента в другой главе. Отсутствие материала допустимо. Реальные интерфейсы и люди важнее коллекции декоративных объектов. На страницах кейсов материал не подменяет скриншоты проекта.
4. Цвет изображения не становится новым цветом интерфейса. Песок остаётся внутри фотографии, Oxide — внутри минеральной сцены или ограниченной акцентной панели. Навигация, текст, формы и соседние блоки продолжают использовать Paper, Mist, Ink, Depth и утверждённые акценты. Новые «песочные», «каменные» или «медные» UI-палитры не вводить.
5. Латунь остаётся редкой. Крупный образец в библиотеке нужен для изучения материала; на странице услуги он работает как небольшой предметный акцент. Не суммировать металлическую картинку, золотистый текст, золотые кнопки и несколько линий на одном экране. Заголовки целиком и отдельные крупные слова латунью не окрашиваются.
6. Текст располагать вне активного рельефа или на проверенном ровном поле. Заголовок использует всю доступную ширину, пояснение идёт под ним. Картинка не должна сужать заголовок до случайных обрывков или оставлять одно слово последней строкой.
7. Материалы публикуются в WebP. Вёрстка использует WebP с размерами и отложенной загрузкой вне первого экрана. Не подгружать всю библиотеку на каждой странице; выбирать только используемые файлы.

Новые материалы дополняют эталон, а не меняют его. Исходный айсберг с водой хранится нетронутым; для первого экрана разрешена только описанная в главе о визуальной идее очистка внешней поверхности при сохранении формы, материалов, воды и атмосферы. Единый SVG-логотип, Geologica + Inter и фирменная палитра остаются неизменными. Архивные концепты со скалой, дубом и зданием по-прежнему не являются вариантами первого экрана.

• Desktop: поля 5,3vw, максимум 136 px; контент до 1940 px, крупная сцена до 2200 px. Поля планшета 32 px, телефона 22 px.
• Вступление раздела — единая вертикальная композиция: заголовок на всю ширину контейнера, под ним подзаголовок, затем контент. Не ставить вводный абзац в соседнюю правую колонку.
• Вводный абзац под заголовком получает всю ширину контентного контейнера, без max-width в символах или пикселях. На широком экране его кегль увеличивается до 22–23 px, чтобы строка оставалась читаемой; короткий текст естественно заканчивается раньше правого края. Ограничение вроде 82ch при контейнере 1940 px сжимает длинный абзац до половины экрана и оставляет пустую правую колонку. Проверять фактическую ширину всех вводных абзацев, а не только заголовков, на 1728, 2048 и 3440 px. Узкая мера строки остаётся у основного текста внутри карточек, FAQ и статей, где она помогает чтению.
• Для длинной страницы заранее задать смысловой ритм: светлый вход, выразительные реальные кейсы, глубокая инженерная глава, человеческая глава с фотографиями и локальную насыщенную тёплую вставку. Не объединять несколько разделов сплошной заливкой Oxide / Oxide Deep. Не заполнять пустоту декором и не делать все блоки одинаково белыми.
• Базовый шаг интервалов 4 px; основные значения 8, 12, 16, 24, 32, 48, 64, 96. Между большими разделами обычно 80–120 px, на телефоне 56–72 px.
• Кнопка: прямоугольная, радиус 2 px, минимум 48 px высотой, в главном CTA 56 px. Один основной CTA в локальном контексте.
• Форма: понятный label над полем, тонкая граница, явный фокус. Placeholder не заменяет label.
• Карточки: прямоугольные либо радиус 2–4 px. Не закруглять каждый блок в капсулу. Большая капсула допустима как единичный композиционный контейнер, а не универсальная сетка. Продуктовое окно — отдельная функциональная роль с радиусом 24 px по правилам ниже; этот радиус не наследуют обычные карточки сайта.
• Кейс: реальный скриншот → задача → результат → ссылка. Сохранить цвета интерфейса проекта; без выдуманных данных и генеративных скриншотов.
• Люди: показывать названных участников в главах, к которым относится их работа: основатель — аудитория и путь агентства к продукту, маркетолог — бизнес-логика подхода, руководитель команды — процесс, участники команды — рядом с основателями после кейсов. Один человек может появляться в нескольких местах, но не повторять одну и ту же большую карточку. Материал, металл и кристалл остаются вторым планом и не заменяют людей. Брать исходные публичные портреты или оригиналы команды, не растягивать аватары и не генерировать лица. Под фото — настоящее имя и согласованная роль. Если доступен только маленький файл, оставить место и запросить оригинал до публикации. Перед публикацией сверить роли с актуальной страницей команды.
• Сценарий без продуктового скриншота: допустима короткая типографическая схема реального рабочего пути, явно подписанная как схема. У неё нет вымышленных клиентских экранов, чисел, отзывов или результатов. Это способ объяснить работу, а не изобразить доказательство уже внедрённой системы.
• Витрина направлений: один крупный кадр настоящего продукта рядом с выбором услуг. Выбор мышью, клавиатурой или касанием меняет только кадр и честную подпись источника; автопрокрутки и автоматической карусели нет. Кадр может подтверждать направление или показывать смежное решение, но смежность следует назвать прямо. Не выдавать экран маркетингового продукта за доказательство SEO и экран автоматизации за работающего бота. При отсутствии подходящего кадра использовать ясно подписанную иллюстрацию, а не выдумывать интерфейс, цифры или клиентский результат. Цвета проекта остаются внутри его изображения; общая оболочка следует палитре AVAT. Не заменять сильные продуктовые кадры набором одинаковых декоративных 3D-иконок.
• На телефоне пример выбранного направления размещается сразу под его строкой. Управление подписано глаголом и результатом («Показать пример»), а все шесть направлений имеют отдельную понятную ссылку на услугу. Нельзя прыгать к общей сцене выше списка после каждого касания.
• Кадры сайтов и продуктов в витрине показывать целиком: рамка следует пропорциям исходного изображения, object-fit: contain, без обрезания края интерфейса ради заполнения карточки. Проверять каждый выбранный кадр, включая при смене направления и на телефоне.
• Информационная графика: один крупный факт или контраст может стать главным визуалом раздела. Цифры и подписи брать из проверенного текста раздела и показывать их как иллюстрацию конкретной истории, не как статистику AVAT. Сопутствующие истории короче и спокойнее по масштабу; не повторять три одинаковых текстовых колонки. В интерактивных списках фон, цвет и изображение могут меняться, но ширина текста, отступы и высота строк остаются стабильными при hover, фокусе и выборе.
• Материальная экспозиция: один утверждённый объект может объяснять несколько последовательных смыслов через ручной выбор. Объект сохраняет размер и узнаваемость; меняются короткое пояснение, номер этапа и сдержанный свет или кадрирование. Все этапы доступны мышью, клавиатурой и касанием, без автопереключения. Не пририсовывать к материалу выдуманный код, интерфейс клиента или метрики. Подробный исходный текст остаётся в доступном раскрытии после сцены.
• Процесс работы: показывать настоящий результат рядом с короткой последовательностью этапов, а не четыре одинаковые текстовые колонки. Подпись к продуктовому кадру называет конкретный проект и ведёт на его кейс; не приписывать этому проекту неподтверждённый срок. Подробности этапов можно раскрывать нативно, сохраняя исходный текст в HTML. Крупное число и тонкий латунный индикатор объясняют проверенный срок и выбранный шаг; не рисовать вымышленные коммиты, чертежи или дашборды.
• Гарантии: четыре конкретных обязательства можно собрать в компактную сетку рядом с одним базальтовым объектом на поверхности Mist. Номер помогает сканированию, латунь отмечает только первый акцент. Не повторять такой же карточный рисунок в соседних разделах и не подменять точные условия общими лозунгами.
• Цены: один основной формат допустимо выделить ограниченной панелью Depth внутри светлой таблицы предложений. Остальные варианты остаются равноправно читаемыми; цена, срок и состав всегда видны без взаимодействия. Не превращать каждую карточку в отдельную цветовую тему.
• Отзыв: точная цитата, имя/роль, реальное фото или честные инициалы при отсутствии фото. Видео только настоящее, без автозвука. Не подставлять случайные или сгенерированные лица.
• CTA и калькулятор: основные приглашения открывают одну рабочую форму. Контекст выбранного тарифа или предварительной сметы передаётся явно; при переходе к другому действию старый текст формы сбрасывается. Ориентир калькулятора не называется фиксированной ценой до договора. Бесплатная консультация не сопровождается обещанием «возврата сбора».
• Телефон допустим для работающего демо бота. Подписать демонстрационный сценарий; он не должен выдавать себя за реального клиента или рабочий бот.
• В таблицах важнее читаемость, чем декоративность: тонкие горизонтальные линии, минимум заливок, цифры ровными колонками.

Продуктовое окно: единая оболочка работающего примера

Продуктовое окно показывает, что посетитель сможет делать после разработки. Вдохновение — ясность и спокойная глубина настольного интерфейса macOS: светлые поверхности, аккуратные слои, скругление и читаемые действия. Это собственный компонент AVAT с Geologica/Inter и нашей палитрой; не копировать системные панели Apple, иконки приложений, логотипы или неработающие кнопки закрытия окна.

• Оболочка: радиус 24 px на desktop и 22 px на телефоне, граница 1 px, тень 0 20px 56px rgba(17,28,35,.10), 0 2px 8px rgba(17,28,35,.04). Тонкая внутренняя светлая кромка допустима. Окно стоит на поверхности и сохраняет фронтальный читаемый ракурс; его не наклоняют так, что продукт превращается в декор.
• Стекло: только внешняя рамка и компактная панель управления, Paper с непрозрачностью 88%. backdrop-filter: blur(12px) необязателен; без него используется непрозрачный Paper. Не накладывать несколько размывающих слоёв, не анимировать blur. Таблицы, графики, сообщения, поля и текст всегда лежат на непрозрачном White или Paper. Изображение за окном не просвечивает сквозь рабочие данные.
• Снаружи сохраняется общий дизайн AVAT: прямые CTA, строгая сетка, полная ширина вводных текстов. Стеклянное окно не превращает цены, отзывы, FAQ и все соседние карточки в стеклянные панели.
• Панель сверху называет продукт и статус содержимого: «Пульсар7 · реальный экран», «Демонстрация SaaS · учебные данные», «Пример лендинга» или «Сценарный демо-бот». Не ставить адрес приложения над кадром его рекламной страницы. Для реального проекта сохранять его UI и цвета внутри окна, указывать проверенный источник и ссылку на кейс.
• Один главный сценарий и один понятный результат в окне. Заголовок действия говорит, что произойдёт: «Изменить тариф», «Посмотреть следующий экран», «Проверить заявку». Доступные функции работают; остальное явно статично. Не добавлять кликоподобные пустые переключатели, россыпь случайных KPI или имитацию продуктовой сложности.
• Минимальная цель касания — 44 × 44 px. Основной текст рабочей области — от 14 px на телефоне, служебные подписи — от 12 px. На узком экране перестраивать интерфейс и убирать второстепенные столбцы с доступом к деталям, а не уменьшать целый desktop-скриншот до нечитабельности.
• График рисуется SVG/CSS из тех же данных, что и итог рядом с ним. Значение доступно текстом; подписи, форма линии и выбранное состояние дополняют цвет. Схема демо использует Ink, Muted, Line, Link и Oxide; цвет графика означает серию или состояние внутри продукта и не становится новым цветом бренда. Латунь не превращается в набор разноцветных метрик.

Три функциональных паттерна

Реальный продукт, учебная модель и концепция имеют разные подписи. Демонстрация показывает возможное поведение, но не доказывает клиентский результат. Синтетические данные нельзя выдавать за выручку студии, KPI клиента или историю реального пользователя. Никаких вымышленных отзывов, логотипов клиентов и экранов «как будто уже запущенного» продукта. Переключатель, фильтр, ввод и итог строятся HTML/CSS/SVG и короткой локальной логикой; их не генерируют растровой картинкой.

Для реального продукта приоритетен настоящий кадр или разрешённая демонстрация. Для объяснения будущей разработки допустим специально созданный работающий учебный интерфейс. Генерация изображений может понадобиться для одного фонового предмета, аккуратной предметной подложки или иллюстрации сценария; не генерировать текст, таблицы и интерфейс, который обещает взаимодействие. Реальные люди и реальные клиентские изображения сохраняют оригиналы.

Доступность, управление и скорость продуктового окна

Окно полноценно работает с клавиатуры и касания. Каждый input имеет label; кнопки имеют видимый фокус и понятное имя; итог расчёта доступен скринридеру без навязчивого озвучивания каждого кадра. Для чата новые ответы сообщаются через спокойный live-region. Указатель, hover и drag не являются единственными способами выполнить действие. Не перехватывать обычную прокрутку страницы и не запирать фокус внутри окна.

Вложенная прокрутка лендинга включается явной кнопкой, область имеет доступное имя и видимую полосу прокрутки; рядом доступны «Выйти из просмотра» и «Открыть полностью». До включения страница прокручивается привычно. В мобильной версии всегда есть путь открыть пример целиком. Горизонтальные таблицы получают заметную подсказку прокрутки или заменяются компактными строками.

Нет автопереключения вкладок, автопрокрутки, фонового видео и непрерывно бегающих значений. Короткая смена состояния — до 200 ms; prefers-reduced-motion убирает необязательные перемещения, сохраняя результат. Локальный пример работает без API, трекеров ввода и загрузки тяжёлого приложения. Настоящее внешнее приложение или iframe загружается только после понятного действия пользователя; статичный кадр и подпись остаются доступным первым состоянием. Одна оболочка переиспользуется для трёх паттернов; не подключать библиотеку анимации ради окна.

Состояния, которые нужно спроектировать до тиражирования: первый полезный экран, отсутствие данных, ожидание действия, ошибка с понятным следующим шагом и успешное завершение. У бота отдельно показать границу сценария и передачу человеку; у формы — проверку поля и подтверждение без ложного обещания отправки; у SaaS — что делать до появления первых данных. Достаточно одного небольшого набора состояний на каждый тип продукта, а не нового декоративного интерфейса на каждой странице.

Паспорт каждого визуала: исходный файл и проект, разрешение и допустимый размер показа, статус «реальная работа / обезличенный оригинал / учебное демо / концепция», дата проверки, точная подпись и ссылка на источник. Для растрового экрана стремиться к исходнику не менее удвоенной отображаемой ширины и готовить размеры для телефона и desktop; не увеличивать маленький скриншот искусственно. Текущий файл МП Приборки имеет ширину 900 px и остаётся образцом брендбука: перед широким производственным показом нужен оригинал большего размера. Клиентский UI не перекрашивается. Учебный Atlas не является клиентским кейсом.

Библиотека смысловых визуалов: семь способов объяснить услугу

Каждый пример отвечает на конкретный вопрос посетителя: «что здесь полезного», «что изменится», «что мне передадут», «чем подтверждается результат», «кто отвечает» или «как связаны системы». До отрисовки записать этот вопрос и ответ одной фразой. Если элемент можно убрать без потери понимания, он декоративный; ему не требуется отдельная глава. Выбирать один главный способ объяснения для блока и не повторять один рисунок в соседних главах. Заголовок и подводка по-прежнему идут во всю ширину над композицией, а не в её левую половину.

Общие правила: текст и подписи остаются HTML, схемы — SVG/CSS с текстовым эквивалентом; источник и статус примера видны рядом. Реальная работа, обезличенный рабочий материал, учебный образец и предположение различаются явно. Изображение не добавляет неподтверждённые сроки, проценты, клиентов или доходы. Иллюстрация функциональности не считается доказательством результата. На телефоне сохраняются последовательность и читаемые подписи; не уменьшать весь desktop-холст до ширины телефона.

1. Реальный экран с пояснениями

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

Что обязательно: название проекта, проверенный источник или ссылка на кейс, подпись «Реальный экран», 2–3 точные отметки и короткое объяснение каждой. Кадр берётся из оригинала без растяжения. Если показан только фрагмент, подписать это и оставить возможность увидеть полный экран. Не дорисовывать интерфейс клиента. Для учебной модели использовать подпись «Учебный пример» и правила продуктового окна.

Как собрать: на desktop показать один читаемый кадр и нумерованные отметки 32 px возле функций. К каждой отметке относится один пункт рядом или ниже; линии короткие и не пересекают текст. На телефоне — изображение без мелких выносок, под ним последовательный список тех же пояснений. Если отметка работает как кнопка, её область касания минимум 44 × 44 px; номер соответствует номеру в списке.

Поведение и границы: нажатие, Enter или Space выделяют связанное пояснение, aria-pressed сообщает выбор. Все пояснения доступны без hover и без необходимости попасть в маленькую точку. У изображения есть содержательный alt, декоративные линии скрыты от скринридера. Полный кадр доступен по явно подписанной ссылке. Если вместо перехода используется диалог, у него есть доступное имя, кнопка закрытия и возврат фокуса. Не превращать экран в карту из десятков точек; не ставить отметки поверх текста интерфейса.

2. Один процесс до и после

Задача и место: показать изменение повседневной работы в разделе о проблеме или результате автоматизации. Пример: «Выгрузить три таблицы → свести данные → отправить отчёт» и «Получить данные → проверить исключения → открыть готовый отчёт». Сохраняются одинаковые исходная задача, участники и конечный результат.

Что обязательно: название одной задачи, две явно подписанные последовательности, 3–5 коротких шагов в каждой, кто выполняет ручное действие и где нужна проверка человека. Пример возможной автоматизации подписывается как сценарий, а не внедрённый клиентский кейс. Минуты, суммы и проценты допустимы только с источником, периодом и одинаковым способом измерения.

Как собрать: desktop — две сопоставимые полосы или колонки с одинаковой логикой чтения; обычные панели сохраняют радиус 4 px. Телефон — сначала весь путь «До», затем весь путь «После», без горизонтального сжатия. Метки и слова передают различие независимо от цвета. Не использовать красный/зелёный как новую пару бренда.

Поведение и границы: схема полезна уже в статике. Если добавлен ручной выбор шага, он объясняет изменение и доступен с клавиатуры; необязательная смена состояния до 200 ms. Не делать обязательный ползунок сравнения, drag-only действие, бегущую конвейерную анимацию или обещание полной автономности, если остаётся ручная проверка. Не сравнивать разные по объёму процессы.

3. Что передаём на каждом этапе

Задача и место: объяснить состав работы и приёмку через реальные образцы в главе «Как работаем». Пример трёх этапов: карта пользовательского пути → работающий прототип → лист проверки перед запуском. Каждый образец помогает оценить конкретную часть услуги.

Что обязательно: имя этапа, видимый результат, 2–4 критерия готовности, роль проверяющего и состояние образца: «Обезличенный фрагмент проекта» либо «Учебный образец». Для реального документа удалить чувствительные данные до публикации и указать источник. Срок, количество экранов и формат передачи берутся из согласованного предложения, а не из примера.

Как собрать: desktop — короткий выбор этапов рядом с одним крупным образцом, а не три крохотных документа. Полезный текст документа верстается HTML; настоящий скан можно открыть крупно. Телефон — выбор этапа, затем его образец и критерии в обычном потоке. Не закреплять область так, чтобы она перекрывала следующие блоки.

Поведение и границы: кнопка этапа меняет образец и его подпись, имеет видимое выбранное состояние и aria-pressed; связанная область получает доступное имя. Фокус остаётся на выбранной кнопке. Без JS остаётся хотя бы первый законченный пример и доступное описание остальных этапов. Не рисовать фиктивные скачивания, вымышленные коммиты, отметки согласования или документы с нечитаемым генеративным текстом.

4. Результат с контекстом и источником

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

Что обязательно: задача, что именно сделано, наблюдаемый результат и ссылка на источник или кейс. Для числа — единица, период, база сравнения и источник; для цитаты — точные слова, имя и согласованная роль автора. Если подтверждён только факт запуска, так и назвать его. Учебный образец рядом со схемой не заменяет клиентское доказательство.

Как собрать: один результат становится главным, остальные факты коротко объясняют его. На desktop допустим экран рядом с текстовым доказательством; на телефоне порядок «задача → работа → результат → источник» сохраняется. Нельзя оставлять огромную цифру без видимого объяснения. Источник доступен обычной ссылкой, подробность измерения — при необходимости нативным раскрытием.

Поведение и границы: доказательство читается без анимации и клика; не прятать оговорки только в hover. Не считать цифры при скролле и не создавать ощущение живой статистики у статичного результата. Не смешивать метрику одного проекта, отзыв другого и экран третьего. Новые заявления о выручке или экономии требуют подтверждения до публикации.

5. Специалист объясняет свою работу

Задача и место: показать ответственность и профессиональное решение в процессе, техническом разделе или разборе продукта. Пример: Анна объясняет, как проходит приёмка; Михаил показывает функцию продукта; Алексей связывает рекламу с заявкой. Выбор человека определяется его фактической ролью.

Что обязательно: настоящее имя и согласованная роль, оригинальное фото или настоящее видео, одна конкретная тема, короткое объяснение и понятный вывод для клиента. Если прямой цитаты нет, текст обозначается как описание работы, а не придуманная реплика человека. Рабочий экран в кадре не должен раскрывать частные данные.

Как собрать: фото работы или кадр видео дополняет объяснение; портрет не вырезается из случайного изображения и не повторяет уже стоящую рядом большую карточку команды. На телефоне человек, тема и текст идут последовательно. У видео есть нормальный постер, длительность и явная кнопка воспроизведения минимум 44 px; при отсутствии видео показываем фото с полезным текстом без ложной кнопки play.

Поведение и границы: видео и тяжёлый внешний плеер загружаются после нажатия. Без автозвука и фонового автовоспроизведения; управление доступно клавиатуре. Субтитры и текстовая версия передают содержание. Не генерировать лица, рабочие встречи, отзывы и речь реальных сотрудников; не подменять объяснение общей фразой «мы профессионалы».

6. Карта события и интеграции

Задача и место: объяснить связь систем в автоматизации, SaaS, ботах и маркетинге. Пример: «Заявка с сайта → проверка полей → запись в CRM → уведомление сотруднику». Под каждым узлом показано действие, а у перехода — что передаётся: контакт, статус, номер заявки. Схема подписана как сценарий, если это не описание подтверждённого проекта.

Что обязательно: стартовое событие, 3–5 систем или операций, направление передачи, результат, место человеческой проверки и один понятный путь ошибки. Например, пустой телефон возвращает заявку на уточнение, а не исчезает из схемы. Не перечислять случайные логотипы сервисов вместо объяснения.

Как собрать: desktop — простой горизонтальный или ступенчатый маршрут с короткими линиями; основной интервал 24 px. Телефон — тот же путь вертикально, подписи у соответствующих узлов. Имена и шаги верстаются как упорядоченный список; соединения SVG/CSS декоративны. Одна карта объясняет один сценарий, без сети из десятков пересекающихся линий.

Поведение и границы: по умолчанию весь маршрут читается статично. Кнопка «Показать путь заявки» может последовательно выделить шаги по действию, но не запускает бесконечный поток частиц. Конечный результат сообщается текстом; при reduced-motion состояние меняется сразу. Если демонстрация позволяет выбрать корректную или неполную заявку, оба пути работают локально и явно обозначены как пример. Не отправлять реальные данные и не обещать готовую интеграцию с сервисом только потому, что его логотип показан в узле.

7. Подписанные функциональные SVG-пиктограммы

Задача и место: помочь сканировать повторяющиеся понятия в составе решения, этапах и карте процесса. Базовая серия: оплата, доступы, данные, интеграция, проверка, запуск. Пиктограмма сопровождает существующий смысл; она не требует отдельного текста или карточки только ради размещения.

Что обязательно: единая геометрия в поле 24 × 24 px, крупный вариант 32 × 32 px, штрих 1,5 px с одинаковыми завершениями, видимая текстовая подпись. Все знаки рисуются SVG и используют currentColor: Ink на светлом, Depth Text на тёмном, Link для выбранного состояния. Форма и текст дублируют значение цвета. Латунь не используется как общий цвет серии.

Как собрать: desktop и телефон используют тот же рисунок и читаемую подпись; в плотном списке достаточно 24 px, в крупном пояснении — 32 px. Размер рисунка не равен размеру нажатия: интерактивный родитель минимум 44 × 44 px. Основные CTA сайта сохраняют свой минимум 48–56 px. Малые знаки не заимствуют поле 64 px у редакционной серии из главы о графическом языке.

Поведение и границы: при наличии подписи SVG имеет aria-hidden="true"; смысл сообщает текст. Для исключительной кнопки без видимой подписи обязательно доступное имя и понятное действие; ключевые функции услуги не показываются одними символами. Не превращать знаки в отдельные логотипы, объёмные стеклянные предметы, эмодзи или шестицветную сетку. Не добавлять иконку к каждому абзацу, FAQ и числу.

Токены и проверка смысловой библиотеки

Номерная отметка — --meaning-marker-size: 32px; её активная область — --meaning-marker-target: 44px. Функциональный SVG — --meaning-icon-size: 24px или --meaning-icon-size-large: 32px со штрихом --meaning-icon-stroke: 1.5. Крупный иллюстративный знак остаётся в локальном эксперименте (--meaning-story-sign-size: 160px, на телефоне 112px) и не используется на действующем сайте без нового решения. Интервал простой карты — --meaning-map-gap: 24px. Подпись смыслового примера — --meaning-caption-size: 14px; не уменьшать важное объяснение до 12 px под предлогом служебной подписи. Это роли внутри существующей системы, не общий радиус всех карточек.

Перед повторным использованием проверить: понятен ли вопрос блока без чтения соседних глав; есть ли источник или честная маркировка; виден ли результат; работает ли клавиатура; читается ли пример на 390 px; не вылезает ли содержимое при увеличении текста; сохраняется ли фокус после выбора; есть ли полезное состояние без JS и движения. Проверять также широкий desktop 2048–3440 px: вводные тексты не сжимаются в левую половину, а пустое место не заполняется бессмысленной графикой.

В состоянии покоя показываем чистую внешнюю поверхность айсберга с водой по правилу из главы о визуальной идее: без квадратного интерфейса на вершине, дороги и открытой архитектуры. Пока не утверждена отдельная разборка, не двигать силуэт и не делить его на случайные плоские полосы. Внутренние уровни раскрываются только при взаимодействии; пояснение находится рядом. Подпись или панель описания не перекрывает айсберг, другие элементы управления или основной текст; ей выделяется собственное место. На широком экране четыре видимых уровня располагаются справа от айсберга в выделенной узкой области. Компактное описание находится в этой же области и не выезжает поверх арта, заголовка или других кнопок. Место под описание резервируется заранее, чтобы взаимодействие не двигало всю сцену. На узком экране управление можно перенести под изображение; это адаптация, а не основной desktop-вариант. Интерактив помогает понять технологическую архитектуру и не превращается в декоративную схему из случайных линий. Видимая смена состояния должна соответствовать реальной функции.

Фокус и hover элементов управления: 180–240 ms. Для материала айсберга допустимо короткое пространственное раскрытие одного уровня примерно за 700–900 ms; оно не задерживает отклик кнопок и не продолжается в цикле. Без постоянного вращения главного объекта, большого параллакса, захвата скролла и второго курсора. Управление одинаково доступно мышью, клавиатурой и касанием. При prefers-reduced-motion отключить необязательное движение.

На главной не рисуем полосы, швы, схемы или код поверх айсберга: они воспринимаются как инородный графический слой. Выбор уровня обозначают латунная кромка выбранной строки и индекс с пояснением в собственной правой области. Раскрытие уровня работает как оптическое раскрытие внутренней структуры без отдельного квадратного виджета: оболочка за одно короткое действие становится прозрачнее в выбранной области, открывая стекло, графит и инженерную глубину. Внешний силуэт, материал, вода, туман и камера сохраняются между состояниями. Маски фиксированы, смягчены и отступают от внешнего контура; не используем следящий тяжёлый фильтр, вращение плоской картинки или обещание полноценной 3D-модели. Hover и фокус открывают соответствующий уровень, клик или касание фиксируют выбор; повторный выбор и Escape возвращают чистое внешнее состояние. После ухода указателя и фокуса незафиксированное раскрытие закрывается. Без движения — мгновенная смена состояния.

В раскрытой внутренней области допускается необязательное мягкое движение света, только если проверка производительности подтверждает, что оно не ухудшает плавность и загрузку. Свет ограничен внутренним материалом; не добавляем наложенные полосы, схемы, код или свечение внешнего силуэта. Анимация останавливается, когда раскрытие закрыто, сцена находится вне экрана или вкладка скрыта; при prefers-reduced-motion полностью отключается. Спокойный неподвижный внутренний визуал остаётся полноценным вариантом. Это разрешение на проверку эффекта, не утверждение о его реализации.

Следующая короткая глава может перейти в Depth и показать крупные подтверждённые числа на тёмном фоне; это переход от метафоры к доказательству, а не шаблон для каждой страницы. На мобильном управлении сохраняются четыре видимых уровня и текстовая подпись.

• Главная: чистая внешняя производная эталонного айсберга с водой, внутренние уровни по взаимодействию; ясный оффер; одна типографическая фраза; реальные кейсы; команда и отзывы; объяснение подхода; квиз.
• Услуга: тот же header, шрифты, цвета, кнопки; ведущий визуал — реальный продукт или ясно подписанная функциональная демонстрация. Один материал по смыслу из библиотеки возможен как поддержка, если помогает объяснению. Содержание и польза услуги важнее арта.
• Кейс: реальная работа на первом плане; дополнительный материал необязателен. Метрики и отзыв связаны с этим же проектом.
• Статья: читабельная колонка, Geologica в заголовках и Inter в тексте. Курсив только настоящий. Декор не повторяется между абзацами.
• Каталог услуг/кейсов: одинаковая логика карточек и ссылок. Не вводить новую цветовую тему для каждой категории.

Коммерческая история страницы услуги

Страница отвечает последовательно: что получится, где это уже работает, что можно попробовать, кто отвечает за качество, сколько стоит и с чего начать. Вайбкодинг раскрывается через короткий путь от задачи к работающему экрану и человеческой проверке: нейросети ускоряют сборку, специалисты отвечают за бизнес-логику, код и запуск. Не заменять это слово россыпью логотипов ИИ, декоративным терминалом или анимированными частицами.

Ориентир — 8–10 видимых смысловых блоков, а не 18 одинаково крупных текстовых глав. Это правило ритма и приоритета, не лимит семантических H2 или количество карточек. Рядом с сильным продуктовым окном достаточно короткого объяснения; следующая глава меняет тип свидетельства или действие. Не каждому тезису нужны огромный заголовок и отдельный экран. Блоки идут без номеров и подписей над заголовком, порядок задаёт сам рассказ.

В единственном веб-брендбуке ниже библиотеки отдельных приёмов находится собранная учебная композиция SaaS-страницы. Она показывает чередование оффера, рабочего примера, настоящего публичного кадра, ответственного человека, условий и следующего шага. Это проверка ритма и применения правил, а не текст или дизайн, автоматически утверждённый для /services/saas/. Публичный кадр Пульсар7 не называется экраном его закрытого кабинета и не доказывает показатели учебного Atlas. Согласованные кейсы и производственные страницы не изменяются при сборке образца.

• Предложение: ясный результат, рамки услуги и ведущий продуктовый визуал; условия обещаний видны сразу.
• Доказательство: 1–2 подходящих реальных проекта, задача и проверенный результат. Публичный лендинг продукта не выдаётся за его рабочий кабинет.
• Работающий пример: один осмысленный сценарий в продуктовом окне. Если окно уже в hero, здесь показывается следующий полезный материал вместо его копии.
• Бизнес-ситуация и состав: какие действия пользователя и команды станет выполнять продукт; технические термины раскрываются после понятного результата.
• Работа команды: несколько этапов с проверяемым результатом каждого; как используется ИИ и что принимает специалист. Люди называются по именам и согласованным ролям.
• Экономика и варианты: цена, состав, границы и предварительный расчёт; учебная модель отделена от прогноза и договорной сметы.
• Люди и доверие: релевантная ответственность участников, настоящий отзыв о подходящей работе. Общее мнение об агентстве не маскируется под отзыв о конкретной услуге.
• Вопросы и технические подробности: сначала покупательские сомнения, затем архитектура, стек и другие полезные уточнения в доступных раскрытиях.
• Следующий шаг: одна рабочая форма с понятным продолжением и контекстом выбранной услуги или расчёта.

Порядок и объединение блоков определяются задачей страницы. Общими переиспользуемыми компонентами остаются оболочка окна, интерактивные контролы, форма, тарифы и раскрытия. Индивидуальными — реальный пример, сценарий взаимодействия, деловое объяснение, свидетельство результата и ответственный человек. Набор «одна уникальная задача + одно рабочее действие + подходящий кейс» важнее новой картинки для каждого раздела.

Ритм доверия и тепла: после первого объяснения услуги показать человека, который отвечает за конкретный выбор, или реальный продукт, с которым можно сделать одно полезное действие. Затем дать проверяемое свидетельство, а техническую глубину раскрыть по желанию. Тёплый фрагмент строится из настоящего фото, короткой ясной мысли и локального Warm Paper; при отсутствии согласованного фото лучше оставить продукт и текст, чем подменить сотрудника генерацией. Один выразительный знак помогает начать сложное объяснение, но не становится повторяющимся фоном. Вау-момент здесь — понятная работа продукта или неожиданно ясное сопоставление «до / после», а не постоянная анимация и бесконечная череда иконок. На длинной странице чередуются человек, продукт, доказательство и тихая пауза; одинаковый вид двух соседних глав — повод пересмотреть подачу.

При сокращении видимого объёма сохранять исходные URL, метаданные, значимые заголовки и поисковые темы. Полные технические материалы остаются серверным HTML в нативных <details> с ясными заголовками; полезные ответы доступны человеку и клавиатуре. Все редакционные сокращения и изменения заголовков фиксируются «было / стало» по главе об SEO и вёрстке. Переход к 8–10 акцентам не разрешает автоматически удалять SEO-текст, переписывать H1 или считать позиции сохранёнными.

Как выбрать визуал и не собирать страницу заново

1. Выписать вопрос посетителя и точный ответ блока. «Нужна картинка» не является задачей. Например: «Что будет после оплаты подписки?» → «Система проверит оплату и откроет доступ по выбранному тарифу».
2. Найти существующее свидетельство: настоящий экран, разрешённый документ, проверенный результат, рабочая фотография. При его отсутствии выбрать честный учебный сценарий или объясняющую схему; не генерировать фиктивное доказательство.
3. Выбрать один паттерн: функция → экран с пояснениями; изменение работы → до / после; состав и приёмка → образцы этапов; доверие → результат с источником; ответственность → объяснение специалиста; связь систем → карта события. Малые пиктограммы помогают этим паттернам, а не образуют ещё одну обязательную главу.
4. Определить одно полезное действие либо оставить статичный пример. Интерактив нужен для выбора, проверки или изучения; простое пояснение не требует анимации. Сначала сделать читаемое состояние без взаимодействия.
5. Уложить содержание в последовательность «полный заголовок → короткая подводка → пример → подробности». Все существенные условия цены, обещания и ограничения остаются рядом с утверждением. Развёрнутые технические темы могут идти в нативном раскрытии по главе об SEO и вёрстке.
6. Проверить соседние главы: не повторять подряд одинаковые окна, три колонки, фотографии или тёмные полосы. Ритм создаётся сменой вопроса и вида свидетельства, а не обязательным перекрашиванием секций. Для первого улучшения страницы достаточно двух подходящих паттернов; применять все семь не требуется.

Например, на SaaS-странице hero показывает действие в продукте, состав — путь от тарифа до доступа, процесс — образцы приёмки. На странице бота главный пример — короткий сценарный диалог, дальше схема передачи сложного вопроса человеку и реальный результат. На странице лендинга — прокручиваемая страница, пояснение формы и путь заявки в CRM. Это рецепты выбора содержания, не замена реальным услугам и их условиям. Существующие кейсы и согласованные тексты не переделываются автоматически при обновлении библиотеки.

Сохранять URL, canonical, hreflang, микроразметку, смысловую иерархию и перелинковку. Команда допускает сокращать формулировки, сохраняя смысл; каждую такую правку фиксировать отдельно и проверять по исходному тексту, ключевым темам и поисковым данным. Не переписывать H1 и значимые поисковые заголовки автоматически в процессе вёрстки. Дополнительные смыслы и блоки маркируются отдельно. Квиз — согласованное функциональное изменение; не выдавать новую логику за неизменившийся калькулятор.

При большом объёме сначала улучшать подачу: короткое вступление, затем доступное пользователю раскрытие с полным исходным текстом в HTML. Раскрытие должно иметь понятную кнопку или заголовок, работать с клавиатуры и открывать полезное содержание; это не скрытый текст для робота. Такой способ предпочтителен перед удалением значимых материалов, но сам по себе не гарантирует сохранения ранжирования.

Для редакционного сокращения вести сравнение «было / стало»: что убрано, какой смысл и поисковая тема сохранены, где теперь доступна подробная информация. Изменения сверять с SEO-аудитом; перенос на другую страницу не считать автоматически равнозначной заменой. Сохранность HTML, метаданных или числа ключевых слов не является обещанием неизменных позиций.

Текст остаётся HTML, не частью картинки. Изображения получают размеры и alt; вторичные изображения загружаются лениво. Отдельные прототипы и локальные предпросмотры — noindex. Встроенная учебная модель не делает всю опубликованную страницу услуги прототипом: production не наследует noindex и локальные обработчики настоящих форм обращения. Сценарная демо-форма внутри продуктового окна сохраняет честную подпись о том, что ничего не отправляет. Сохранение структуры не является гарантией поисковых позиций.

Смысловой визуал и длинный поисковый текст

Для каждого изменённого блока вести короткую карту: исходный заголовок и тема → краткий видимый ответ → выбранный пример → место полного текста. Схема или скриншот дополняют ответ и не заменяют существующий H2, ссылки, термины и важные условия. Не прятать весь коммерческий смысл в аккордеон ради минималистичного экрана. Вводный текст, состав основных вариантов и оговорки обещаний остаются видимыми.

Содержимое нативных раскрытий, подписи к схемам и объяснения выбранных этапов присутствуют в серверном HTML до взаимодействия. JS может менять видимость и состояние, но не является единственным способом получить основной текст. Значимое содержание не загружается только по hover, прокрутке или клику. Для карты интеграции остаётся последовательный текстовый маршрут; для графика — числовой итог с подписью; для видео — текстовая версия. Alt описывает изображение по смыслу и не превращается в набор ключевых слов.

После сборки сверить URL, title, description, canonical, hreflang, H1, значимые H2, FAQ и связанные данные, ссылки на услуги и кейсы с исходником. Новая учебная модель не добавляет разметку реального клиентского результата или отзыва. Все редакционные отличия фиксируются отдельно; сохранность структуры и корректная индексация не обещают прежние позиции. Публикация и наблюдение за поисковыми показателями остаются отдельным этапом.