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

Анатомия инструмента, которую мы разобрали в предыдущей главе, даёт понимание того, что именно перед тобой стоит. Но понимание устройства механизма и умение им управлять, это разные вещи. Можно знать, как работает двигатель внутреннего сгорания, и при этом не уметь водить машину. С Claude Design та же история: знание того, что такое Artifacts и чем Opus 4.8 отличается от 4.7, не сделает тебя автоматически человеком, который получает нужный результат с первого раза. Это делает промпт.

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

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

Структура промпта, который даёт результат с первого раза

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

Этих элементов пять, и их можно думать как слои. Первый слой, это роль и контекст. Claude должен понимать, кто ты в этой задаче и для чего она решается. Речь идёт о реальном операционном контексте: «я проектирую онбординг для B2B SaaS-продукта, аудитория, финансовые менеджеры среднего звена в компаниях от 50 до 500 человек, они технически грамотны, но не разработчики». Это даёт модели карту местности, по которой предстоит двигаться. Второй слой, задача, сформулированная в терминах результата, а не процесса. Формулировка «создай форму регистрации, после прохождения которой пользователь должен почувствовать, что сложность продукта управляема и стоит его времени» работает иначе, чем просто «создай форму регистрации». Разница между этими формулировками, это разница между техническим заданием и дизайн-намерением.

Третий слой, ограничения. Речь идёт о реальных границах, внутри которых должно существовать решение: технический стек, доступность, существующая дизайн-система, корпоративные гайдлайны, конкретные компоненты, которые уже используются и не подлежат переработке. Четвёртый слой, критерии оценки. Этот слой пропускают почти все, и именно его отсутствие приводит к тому, что Claude делает «что-то хорошее», но не обязательно то, что нужно. Если ты формулируешь, по каким признакам результат будет считаться успешным, «форма должна умещаться в один экран без скролла на 1366px, содержать не более семи полей и заканчиваться микрокопией, которая снижает тревогу перед нажатием кнопки»,, ты даёшь модели внутренний фильтр качества. Пятый слой, формат вывода. Укажи, что именно ты хочешь получить: HTML с инлайновыми стилями, React-компонент с Tailwind, структурированный список с пояснениями к каждому решению, или интерактивный артефакт. Без этого указания Claude делает выбор за тебя, и он не всегда совпадает с твоими ожиданиями.

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

Референс вместо тысячи слов: техника скриншот-инъекции

Есть категория дизайн-намерений, которую словами передать почти невозможно. Визуальный опыт работает иначе, чем вербальный. Когда ты говоришь «минималистичный», ты имеешь в виду что-то конкретное, сложившееся из десятков насмотренных примеров. Когда Claude читает слово «минималистичный», он интерпретирует его через статистику своих обучающих данных, которая может существенно расходиться с твоим внутренним определением. Именно здесь скриншот-инъекция становится принципиальным методом работы.

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

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

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

Итерационный диалог: как вести Claude к нужному решению за 2—3 хода

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

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

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

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

Антипаттерны промптинга, которые убивают качество вывода

Разговор о том, как делать правильно, будет неполным без честного разбора того, как делают неправильно. Антипаттерны промптинга, это ошибки, которые совершают в том числе опытные дизайнеры, потому что они кажутся интуитивно правильными. Именно поэтому они устойчивы и именно поэтому их стоит назвать прямо.

Первый и самый распространённый антипаттерн, это эстетические дескрипторы без функционального обоснования. Промпты вроде «сделай красиво», «добавь ощущение премиальности», «должно быть современно и чисто», это инструкции в режиме вкусовщины. Они не дают Claude ничего операционного, потому что «красиво» и «премиально» в разных контекстах означают диаметрально противоположные решения. Fintech-премиальность выглядит иначе, чем luxury fashion, которая выглядит иначе, чем enterprise SaaS. Каждый раз, когда ты ловишь себя на использовании чисто эстетического дескриптора, спрашивай себя: а что именно я имею в виду под этим словом в контексте этой конкретной задачи? Ответ на этот вопрос и есть твой промпт.

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

Третий антипаттерн, это избыточная вежливость и хеджирование, которые размывают задачу. Промпты вида «может быть, попробуй как-нибудь сделать что-то вроде…» или «не знаю, насколько это возможно, но было бы здорово, если бы…» сигнализируют модели о неуверенности в задаче. Claude устроен таким образом, что неопределённость в запросе он склонен компенсировать усреднённым, безопасным результатом. Если ты знаешь, чего хочешь, говори об этом прямо. Если не знаешь, признай это явно и попроси помочь с определением направления, а не маскируй неопределённость вежливыми оговорками. Четвёртый антипаттерн, это отсутствие негативных ограничений. Большинство промптов говорят о том, что должно быть. Лучшие промпты также говорят о том, чего не должно быть. «Без модальных окон», «без carousel-компонентов», «без анимации, которая требует пользовательского действия для остановки», это конкретные, верифицируемые ограничения, которые исключают целые классы нежелательных решений и позволяют Claude сосредоточиться на том пространстве, которое тебе действительно нужно. Пятый антипаттерн, самый тонкий, и именно поэтому самый опасный. Это принятие первого правдоподобного результата без критической проверки. Когда Claude выдаёт убедительно выглядящий артефакт, возникает соблазн счесть задачу выполненной. Но «выглядит правдоподобно» и «решает задачу», слова с разным смыслом. Профессиональная работа с AI требует того же критического взгляда на результат, который ты применяешь к работе любого другого дизайнера: что здесь сделано верно, что неверно, и почему. Без этой проверки ты не управляешь процессом, ты наблюдаешь за ним.

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

Чем принципиально отличается формулировка задачи через результат от формулировки через процесс — и как эта разница влияет на дизайн-решения, которые принимает Claude?

В каких ситуациях скриншот-инъекция даёт принципиальное преимущество перед текстовым описанием — и что нужно явно указывать при работе с визуальными референсами, чтобы модель не скопировала нежелательные элементы?

Что такое «негативные ограничения» в промпте и почему их отсутствие заставляет Claude исследовать нежелательное пространство дизайн-решений?

Как фиксация «что не трогать» в промпте второй и третьей итерации предотвращает конкретную и распространённую ошибку при внесении изменений в существующий артефакт?

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

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

Проблема «амнезии»: почему AI забывает бренд между сессиями

Чтобы по-настоящему понять проблему, нужно разобраться в её архитектурной природе. Большие языковые модели, включая Claude, работают в рамках так называемого контекстного окна. Это ограниченный объём текста, который модель «видит» в один момент времени и на основе которого формирует ответ. Всё, что находится внутри этого окна, существует для модели. Всё, что за его пределами, не существует вообще. Когда сессия заканчивается, контекстное окно очищается. Следующая сессия начинается с нуля, без каких-либо следов предыдущей. Это фундаментальное свойство архитектуры, которое имеет свои веские технические причины. Проблема в том, что дизайн-системы по своей природе существуют во времени: они накапливаются, уточняются, эволюционируют. И дизайнер, который работает с AI без решения проблемы амнезии, каждый раз тратит значительную часть своего контекстного окна на то, чтобы заново объяснять AI, с кем он разговаривает.

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

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