AI Дизайн. AI-дизайнер на скорости света

Понимание этого сдвигает постановку задачи. Задача состоит в том, чтобы создать систему, в которой правильный контекст доставляется к каждому запросу автоматически, последовательно и в машиночитаемом формате. Именно это и есть Brand State Architecture: обход проблемы памяти через правильно спроектированную инфраструктуру контекста. Следующие три раздела, это три уровня этой инфраструктуры, от самого технологичного к самому практичному.

RAG-пайплайн для дизайнера: Pinecone, Weaviate и векторные базы без страха

Аббревиатура RAG расшифровывается как Retrieval-Augmented Generation, и если ты слышишь её впервые или она кажется тебе зоной компетенции исключительно ML-инженеров, то следующие несколько абзацев изменят эту установку. RAG, это технический паттерн, решающий ровно ту проблему, которую мы обсуждали: как давать языковой модели доступ к информации, которая не умещается в её контекстное окно целиком. Принцип работает следующим образом. Твои документы, токены, описания компонентов, гайдлайны, принципы бренда, разбиваются на фрагменты и преобразуются в числовые векторы, которые фиксируют смысловое содержание каждого фрагмента. Эти векторы хранятся в специализированной базе данных. Когда ты задаёшь вопрос или формулируешь задачу, система сначала ищет в векторной базе наиболее релевантные фрагменты и добавляет их в контекст запроса к модели. В результате модель видит не весь твой бренд-гайдлайн разом, а именно ту его часть, которая нужна для конкретного ответа.

Pinecone и Weaviate, два наиболее зрелых инструмента для хранения векторных данных, которые дизайнер может освоить без написания кода с нуля. Pinecone, это облачный сервис с управляемой инфраструктурой: ты создаёшь индекс, загружаешь документы через API или через один из многочисленных готовых коннекторов, и система сама занимается векторизацией и поиском. Pinecone хорошо подходит для ситуаций, когда тебе нужна надёжная работающая система с минимальными настройками. Weaviate, open-source альтернатива с более богатыми возможностями кастомизации и схемой данных, которая позволяет хранить вместе с векторами произвольные метаданные: к примеру, для каждого компонента дизайн-системы ты можешь хранить не только его описание, но и ссылку на Figma-файл, дату последнего обновления, теги контекста использования и имена ответственных. Weaviate требует чуть больше первоначальной настройки, но даёт значительно более гибкую структуру хранения.

Для дизайнера практический вход в мир RAG выглядит как использование готовых инструментов-оберток. Langchain и LlamaIndex, это фреймворки, которые абстрагируют техническую сложность RAG до уровня, с которым справится человек, умеющий читать документацию. LlamaIndex в особенности хорошо подходит для задачи «сделай мою дизайн-документацию доступной для AI»: у него есть встроенные загрузчики для Notion, Confluence, локальных файлов в формате Markdown, PDF и даже веб-страниц. Ты указываешь источник своей дизайн-документации, настраиваешь параметры разбивки на фрагменты и размещения в индексе, и получаешь рабочий пайплайн примерно за час работы, половину из которой займёт чтение документации. Важно: достаточно быть дизайнером, достаточно любопытным, чтобы один раз потратить вечер на настройку системы, которая сэкономит тебе часы каждую неделю.

Есть и ещё более лёгкий вход, который стоит упомянуть отдельно: инструменты типа Cursor AI, Windsurf или Claude Projects позволяют прикреплять файлы и документы к проекту как постоянный контекст. Claude Projects, в частности, хранит загруженные документы и делает их доступными в каждой сессии в рамках проекта, без необходимости настраивать векторную базу самостоятельно. Перед тобой упрощённое решение с семантическим поиском попроще, чем в полноценном RAG, но для большинства практических задач дизайнера это разумный первый шаг. Ты создаёшь проект «Дизайн-система Клиента X», загружаешь туда свои токены, компонентную документацию и гайдлайн, и с этого момента каждая сессия в этом проекте знает, с каким брендом она работает. RAG с Pinecone или Weaviate становится следующим уровнем, когда объём документации вырастает настолько, что даже контекстного окна проекта начинает не хватать или когда тебе нужен тонкий контроль над тем, какие именно фрагменты подставляются в контекст.

Строим папку Claude-Design: токены, палитры, компоненты в machine-readable формате

Если RAG-пайплайн можно сравнить с нервной системой, которая доставляет нужные знания в нужный момент, то то, что мы разберём сейчас, это сам язык, на котором эти знания записаны. Проблема большинства дизайн-систем в том, что они написаны для людей: длинные Notion-страницы с вдохновляющими принципами, Figma-файлы с аккуратно разложенными компонентами, PDF-гайдлайны с красивыми скриншотами. Всё это прекрасно читается на ретина-дисплее за чашкой кофе, но для языковой модели это примерно как пытаться понять чертёж здания, глядя на фотографию его фасада. Форма есть, а структуры нет. Чтобы AI мог работать с твоим брендом как полноценный член команды, а не как гость, который впервые зашёл на сайт, документацию нужно переписать в machine-readable формат. Задача состоит в том, чтобы добавить слой структуры, который модель способна надёжно интерпретировать.

Начнём с самого верхнего и самого недооценённого слоя: бренд-токены. Большинство дизайнеров знакомы с ними в контексте дизайн-систем вроде Figma Tokens или Style Dictionary, но мало кто думает о них как об инструменте общения с AI. А между тем, правильно описанный токен это маленький контракт между брендом и генеративной моделью. Вместо «основной цвет бренда это синий» пиши «primary-500: #1D4ED8, используется для основных интерактивных элементов, включая CTA-кнопки и активные состояния навигации; контрастность с белым фоном составляет 7.2:1, что соответствует WCAG AAA». Разница огромная. Поэзия остаётся в первом варианте, спецификация во втором. Модель, получая второй вариант, уже знает и цвет, и контекст применения, и ограничения доступности одновременно. Когда ты описываешь таким образом пятнадцать-двадцать ключевых токенов из своей системы, у модели формируется достаточно плотная карта бренда, чтобы она могла делать осознанные предложения, а не просто угадывать.

Типографика требует отдельного внимания, потому что это тот слой, где дизайнеры чаще всего грешат неполнотой описания. Написать «используем Inter для интерфейсных текстов и Cormorant Garamond для заголовков лонгридов» недостаточно. Для machine-readable документации тебе нужна таблица ролей: каждому уровню иерархии соответствует конкретный size в пикселях и в rem, конкретный line-height, конкретный letter-spacing и контекст применения. Display-heading: 64px / 4rem, line-height 1.1, letter-spacing minus 0.02em, только для hero-секций и промо-материалов. Body-default: 16px / 1rem, line-height 1.6, letter-spacing 0, для всего основного контента интерфейса. Когда модель видит такую структуру в контексте, она не будет предлагать тебе в UI-копирайтинге задачу использовать Display-heading для подзаголовков карточки. Она понимает иерархию так же, как понимаешь её ты, и это принципиально меняет качество диалога.

Третий слой, паттерны поведения и голос бренда, наименее формализован в большинстве команд, но именно он даёт AI контекст для принятия решений в серых зонах. Поведенческие паттерны это принципы взаимодействия: как бренд реагирует на ошибки пользователя, насколько он разговорчив в пустых состояниях, использует ли юмор в онбординге или держит дистанцию. Записывай это максимально конкретно и, желательно, с примерами антипаттернов. Конкретика решает всё: вместо размытого «мы дружелюбны, но профессиональны» пиши «текст ошибки валидации никогда не начинается со слова «Ошибка:" и никогда не обвиняет пользователя; формат: что пошло не так плюс что нужно сделать, не более двух предложений; пример корректного: «Кажется, email написан неверно. Проверь, есть ли в нём знак @"; пример некорректного: «Неверный формат email»». Это операционная инструкция, и языковая модель работает с ней именно так. Сложив все три слоя, токены, типографику и голос, в единый структурированный документ, который попадает в контекст через RAG или системный промт, ты получаешь ситуацию, когда AI не просто знает твой бренд, а способен его защищать так же рефлекторно, как это делает опытный дизайнер после двух лет работы в одной команде.

DESIGN.md как центральный файл документации и единый источник правды

Если ты когда-нибудь открывал Notion-страницу своей дизайн-системы через полгода после её создания, то знаешь это ощущение: пятнадцать вложенных разделов, три устаревших варианта цветовой палитры, комментарий от менеджера двухлетней давности с пометкой «разобраться», и где-то в глубине ссылка на Figma-файл, который уже переехал в другой проект. Ты не виноват. Это системная проблема большинства команд: документация живёт в слишком многих местах одновременно, и в итоге не живёт нигде. DESIGN.md решает это радикальным способом, которым программисты пользовались десятилетиями: один текстовый файл, который является единственным авторитетным источником правды о твоём бренде и дизайн-системе. Плоский, читаемый, версионируемый файл, который одинаково хорошо понимают и твой джун-дизайнер в первый рабочий день, и языковая модель в первую секунду нового контекста.

Структура DESIGN.md строится по принципу убывающей абстракции: от самого фундаментального к самому конкретному. Первый раздел описывает суть бренда в терминах, которые нельзя неверно интерпретировать. «Мы дружелюбные и инновационные» здесь не работает, нужно что-то вроде: «Интерфейс обращается к пользователю на „ты“, использует активный залог и избегает пассивных конструкций. Тон варьируется от нейтрально-делового в состояниях ошибки до тепло-поддерживающего в состояниях успеха. Восклицательные знаки используются не чаще одного раза на экран и только в момент значимого достижения пользователя.» Это спецификация поведения, а не поэзия о бренде. Следующий уровень касается визуальных токенов: не просто перечисление цветов, а их семантика. «Primary-600 (#1D4ED8) используется исключительно для интерактивных элементов, требующих основного действия пользователя. Применение этого цвета для декоративных элементов или фоновых поверхностей нарушает семантику системы.» Когда ты пишешь документацию таким образом, ты фактически описываешь то, как система думает. Именно это и нужно языковой модели.

Практическая архитектура файла, которую я рекомендую после нескольких итераций с реальными проектами, включает шесть блоков. Первый: Brand Core, где в пяти-семи предложениях описана суть продукта, его аудитория и позиционирование без маркетинговой воды. Второй: Visual Tokens, полный список дизайн-токенов с именами, значениями и семантическим описанием каждого. Третий: Typography Rules, где указаны правила применения шрифтов и размеров, включая исключения и запрещённые комбинации. Четвёртый: Component Behavior, описание ключевых компонентов через их состояния и логику переходов между ними. Пятый: Accessibility Constraints, обязательные требования к контрасту, размерам тач-зон и альтернативным текстам, сформулированные как жёсткие правила, а не рекомендации. Шестой: Anti-Patterns, раздел, который большинство команд пропускают и о котором потом жалеют: явное описание того, чего делать нельзя и почему. «Не использовать красный цвет для акцентов, не связанных с ошибками или деструктивными действиями» работает лучше, чем любая позитивная инструкция, потому что исключает целый класс ошибок ещё до их появления. Весь файл в зрелом состоянии занимает от восьмисот до полутора тысяч строк и помещается в контекстное окно современных моделей целиком, что делает его идеальным инструментом для прямой работы без RAG-пайплайна на этапах прототипирования.

Главное преимущество DESIGN.md перед любой другой формой документации, которое редко обсуждают, это его версионируемость через Git. Когда ты храниш файл в репозитории рядом с кодом или в отдельном дизайн-репо, каждое изменение системы становится коммитом с датой, автором и описанием причины изменения. Ты буквально видишь историю эволюции бренда: «02.2024, изменён основной радиус скругления с 4px до 8px после тестирования с пользователями старше 55 лет, которые испытывали трудности с идентификацией кнопок». Это организационная память, которой лишены команды, держащие документацию в Notion или Confluence. Более того, файл становится контрактом между дизайном и разработкой: любое расхождение между тем, что описано в DESIGN.md, и тем, что реализовано в коде, является задокументированным багом, а не предметом интерпретации. Когда ты передаёшь этот файл в контекст AI-инструмента в начале сессии, ты передаёшь ей систему ценностей, логику принятия решений и границы допустимого, за которые нельзя выходить. Это превращает каждый последующий запрос из угадывания намерений в точное исполнение задокументированной воли.

Контрольные вопросы

В чём принципиальное отличие RAG-пайплайна от простого добавления документации в начало каждого промпта, и в каких ситуациях RAG становится необходимостью, а не просто удобством?

Почему machine-readable формат дизайн-документации должен отличаться от документации, написанной для человека, и что конкретно это означает на уровне структуры текста?

Чем DESIGN.md отличается от классического бренд-гайдлайна по аудитории, структуре и функции, и почему раздел явных запретов является в нём наиболее критичным для AI-агентов?

Как концепция Brand State Architecture меняет представление дизайнера о его роли: что именно теперь является ключевым артефактом его работы помимо самих макетов?

Глава 5: Прототип за 20 минут: от идеи до интерактивного артефакта

Умение писать хороший промпт, это необходимое условие, но не достаточное. Можно идеально сформулировать запрос, избежать всех антипаттернов, выстроить точный контекст и при этом получить на выходе красивый, но мёртвый артефакт. Потому что промпт, это инструмент передачи намерения, а не инструмент создания опыта. Опыт создаётся тогда, когда идея становится чем-то, что можно потрогать, нажать, прокрутить и почувствовать. То есть когда она превращается в прототип. Именно здесь возможности Claude Design из умозрительных становятся практически ощутимыми.

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

Эта глава о том, как использовать Claude для создания прототипов, которые убеждают, проверяют гипотезы и помогают принимать решения, быстро и без потери качества суждений. Не о том, как заставить AI сделать всё за тебя. А о том, как выстроить процесс так, чтобы двадцать минут работы давали артефакт, вокруг которого можно вести осмысленный разговор с командой, заказчиком или самим собой.

8-шаговый фреймворк быстрого прототипирования с Claude

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

Первый шаг, формулировка гипотезы, а не задания. Это звучит тривиально, но большинство прототипов создаются с размытой целью вроде «нужно показать онбординг». Гипотеза звучит иначе: «Если мы покажем пользователю выгоду до запроса регистрации, он с большей вероятностью дойдёт до экрана создания аккаунта». Это конкретное утверждение, которое прототип должен помочь проверить. Именно эта формулировка идёт в начало первого промпта.

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

Третий шаг, описание контекста использования в промпте: кто, когда, на каком устройстве и в каком эмоциональном состоянии встречается с этим интерфейсом.

Четвёртый шаг, запрос первого артефакта с явным указанием на интерактивность: Claude должен знать, что ты хочешь HTML-прототип с рабочими переходами.

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

Шестой шаг, точечная итерация с сохранением контекста: ты уточняешь конкретный элемент или сценарий, продолжая начатое.

Седьмой шаг, стресс-тест: ты намеренно проверяешь граничные случаи, длинные тексты, пустые состояния, ошибки.

Восьмой шаг, фиксация решений: короткий комментарий прямо в переписке или в отдельном документе о том, что было проверено и что решено. Этот шаг пропускают почти все, и именно поэтому через неделю никто не помнит, почему кнопка стоит слева.

Практически это выглядит так. Ты открываешь Claude, пишешь гипотезу и контекст в первом сообщении, запрашиваешь интерактивный HTML-артефакт с конкретными сценариями взаимодействия. Через минуту у тебя есть что-то работающее в браузере. Ты нажимаешь кнопки, проходишь флоу, замечаешь, что не хватает состояния загрузки на третьем экране, и пишешь об этом во втором сообщении. К третьему ходу у тебя есть прототип, который отвечает на вопрос, ради которого затевался. Достаточный для того, чтобы принять следующее решение. Смысл прототипирования состоит в создании инструмента для следующего шага мышления.

Сложные интеракции и анимации: кейс Brilliant (20+ промптов vs 2 промпта)

Есть задачи, которые кажутся принципиально неподходящими для быстрого AI-прототипирования. Сложные микровзаимодействия, образовательные интерфейсы с адаптивной логикой, анимированные визуализации данных, всё это традиционно требовало либо глубокого знания CSS-анимаций и JavaScript, либо длительной работы с Motion Design специалистом. Именно здесь разница между опытным пользователем Claude и новичком становится особенно очевидной.

Kнига Brilliant, это образовательная платформа, построенная вокруг интерактивных визуальных объяснений. Когда команда хотела прототипировать новый формат интерактивного урока по теории вероятности, первый подход выглядел типично: дизайнер делал серию итераций, уточняя с каждым ходом анимацию, логику прогрессии, поведение при ошибке пользователя, состояния при правильном ответе. Двадцать с лишним промптов, разбросанных по нескольким сессиям, каждый из которых частично терял контекст предыдущего. Результат был функциональным, но процесс выматывал и не давал ощущения контроля. Второй подход появился после того, как один из дизайнеров взял паузу и выстроил промпт принципиально иначе: он описал пользовательский опыт, а именно то, что должен пережить пользователь. Эмоциональную дугу взаимодействия: момент непонимания, момент гипотезы, момент проверки, момент понимания. Плюс технические параметры: анимации через CSS transitions, состояния через классы, никаких внешних библиотек. Два промпта, и прототип, который команда смогла использовать в тестировании с реальными пользователями в тот же день.

Разница между двадцатью итерациями и двумя определяется ментальной моделью задачи. В первом случае дизайнер думал категориями элементов интерфейса: кнопка, прогресс-бар, анимация. Во втором случае он думал категориями пользовательского опыта: что человек чувствует, что он делает, что происходит в ответ. Claude значительно лучше переводит описание опыта в рабочий код, чем описание визуальных элементов в вакууме. Дизайнерам, привыкшим мыслить в терминах компонентов, такой подход кажется контринтуитивным, но как только это понимаешь, скорость работы меняется кардинально.

Для сложных анимаций работает ещё один принцип: описывай физику движения, а не параметры CSS. Вместо «добавь ease-in-out с duration 300ms» пиши «элемент появляется как будто выныривает из-под поверхности, с лёгким перелётом и возвратом». Claude переведёт это в конкретные значения кривых, и результат будет ближе к тому, что ты имел в виду, чем если бы ты указывал технические параметры напрямую, особенно если ты не анимационный дизайнер по специализации. Эта техника работает потому, что AI обучен на огромном корпусе описаний движения из кино, игрового дизайна и UX-документации, и умеет транслировать качественные метафоры в количественные значения точнее, чем многие ожидают.

Слайды, лендинги, one-pager’ы: выбор режима под задачу

Claude Design, не монофункциональный инструмент. Он одинаково хорошо создаёт интерактивные прототипы приложений, презентационные слайды, маркетинговые лендинги и компактные one-pager’ы. Но «одинаково хорошо» не означает «одинаково быстро и с одинаковым промптом». У каждого формата своя логика запроса, и смешивать их, значит получать артефакты, которые технически работают, но не решают задачу.

Слайды, это нарративный формат. Их логика подчинена последовательности аргументов, а не иерархии информации на одном экране. Когда ты просишь Claude создать слайд-презентацию, самая важная часть промпта, это описание аргументационного маршрута: с чего начинается история, какие возражения она должна снять по пути, чем заканчивается. Хороший промпт для слайдов звучит как тезисы для выступления, а не как техническое задание на дизайн. Если ты опишешь аудиторию (инвесторы серии А, которые уже видели десять похожих питчей сегодня), Claude сделает выборы в пользу лаконичности и ударных данных, а не декоративной сложности.

Лендинги, это совершенно другая задача. Здесь логика конверсионная: каждый блок должен отвечать на конкретное возражение или усиливать доверие перед следующим шагом. Промпт для лендинга должен содержать описание целевого действия (что пользователь должен сделать в итоге), описание пути к этому действию (какие сомнения нужно снять), и описание того, кто этот пользователь на уровне его внутреннего монолога в момент просмотра страницы. Claude, получив такой контекст, выстраивает структуру блоков с внутренней конверсионной логикой. Технически артефакт будет HTML с CSS, который можно открыть в браузере, прокрутить и нажать на кнопку. Для тестирования структуры и текстов этого более чем достаточно.

One-pager, самый недооценённый формат в арсенале senior-дизайнера. Это документ-убеждение, сжатый до одной страницы: идея, контекст, ключевые решения, следующий шаг. Его сила в том, что он вынуждает автора расставить приоритеты и отказаться от всего лишнего, а это само по себе форма мышления. Claude отлично создаёт one-pager’ы, если в промпте есть явное ограничение: «всё, что не умещается на одном экране без прокрутки, должно быть удалено». Это ограничение работает как дизайн-решение, и AI его соблюдает. Практически полезно просить Claude сначала написать one-pager, а потом, разместить тот же контент как лендинг: разница между двумя артефактами наглядно покажет, что теряется и что приобретается при смене формата. Это упражнение само по себе тренирует редакторское мышление.

Когда прототип достаточно хорош: критерии остановки итераций

Один из самых сложных профессиональных навыков, не умение улучшать, а умение останавливаться. В традиционном дизайне это регулировалось дедлайном и усталостью команды. В AI-прототипировании дедлайн исчезает как ограничение: следующая итерация стоит всего одного промпта и тридцати секунд ожидания. Это создаёт новую ловушку, бесконечное совершенствование артефакта, который давно перестал учить тебя чему-то новому.

Первый критерий остановки, ответ на исходную гипотезу. Если прототип создавался для проверки конкретного утверждения, как только ты можешь уверенно сказать «да» или «нет» на вопрос этой гипотезы, прототип сделал своё дело. Любые дальнейшие итерации работают уже на следующую гипотезу, и их стоит начинать с явной переформулировки цели. Это кажется очевидным, но на практике дизайнеры очень часто продолжают улучшать артефакт по инерции, не замечая, что изначальный вопрос давно закрыт и теперь они совершенствуют решение, которое ещё не было принято.