У дизайнера часто есть макет, комментарии команды и список требований, но нет одного документа, который объясняет, что именно должен сделать пользователь и что интерфейс обязан ему сообщить. Я бы разделил работу с Claude на два прохода: сначала собрать проверяемый бриф, затем отдельно отредактировать тексты конкретного сценария. Так проще заметить, где модель помогла упорядочить материал, а где лишь красиво перефразировала неизвестное.
На сайте STIVA.ai сервис называют СТИВА, а пользователи иногда говорят СТИВА ИИ. Здесь разбираем именно текстовый бриф и микротексты для интерфейса, а не работу в отдельном продукте Claude Design и не автоматическую сборку макета.
Claude подходит для работы с текстами и структурированными заданиями. Но решение о поведении продукта, юридически значимых обещаниях и точности сведений остаётся за командой. Если в исходных материалах нет правила возврата, срока обработки или причины ошибки, модель не должна придумывать их для кнопки либо подсказки.
Сначала соберите входные данные, а не просите «улучшить UX»
Для брифа достаточно короткого пакета исходников. Отделите подтверждённые факты от предположений: это важнее объёма промпта.
- Сценарий: откуда пришёл человек, чего хочет достичь и на каком шаге находится.
- Границы задачи: какие экраны или состояния меняются, а какие трогать нельзя.
- Правила продукта: обязательные поля, известные ограничения, подтверждённые сроки и условия.
- Аудитория и тон: кому адресован интерфейс, как принято обращаться к пользователю, какие слова запрещены.
- Критерий готовности: по чему команда поймёт, что решение можно передавать дальше.
Например, запрос «сделай удобную форму регистрации» скрывает несколько разных задач. Нужно ли человеку создать пароль? Можно ли вернуться к заполнению? Что происходит после отправки? Пока ответы неизвестны, лучше получить список вопросов, чем уверенный на вид бриф с вымышленным сценарием.
Промпт: превратить заметки в рабочий дизайн-бриф
Вставьте свои материалы вместо текста в квадратных скобках. Формат ответа задан заранее, чтобы результат было удобно сверять с исходниками, а не принимать как готовое продуктовое решение.
Ты - редактор продуктового дизайн-брифа. Работай только с данными ниже. Не додумывай правила продукта, сроки, метрики и поведение экранов. Если сведений не хватает, пометь пункт «Нужно уточнить». Неизвестное не превращай в требование.
Задача команды: [что требуется изменить]
Пользователь и его цель: [кто он и зачем пришёл]
Текущий сценарий: [шаги до целевого экрана и после него]
Подтверждённые правила: [факты из документации или решения команды]
Ограничения: [что нельзя менять; требования к тону и терминологии]
Исходные заметки: [вставить заметки, комментарии, текущие тексты]
Верни:
1. Цель изменения одним предложением.
2. Сценарий пользователя по шагам. Каждый шаг привяжи к исходным данным.
3. Требования к экрану и текстам: отдельно факты и предположения.
4. Открытые вопросы с указанием, кто должен дать ответ: продукт, дизайн, разработка или юридическая команда.
5. Критерии проверки результата, которые можно наблюдать на макете или в сценарии.
6. Краткий бриф для передачи дизайнеру, без неподтверждённых обещаний.После ответа я бы прошёлся по каждому требованию и задал один вопрос: «Где это сказано в исходниках?» Если ответить нечем, пункт возвращается в список вопросов. Особенно внимательно проверяйте автоматически появившиеся слова «мгновенно», «надёжно», «всегда» и конкретные сроки.
Затем проверяйте не «все тексты», а путь человека
Ревью микротекста лучше проводить по состояниям интерфейса. Для одного действия соберите заголовок, подпись поля, текст кнопки, подсказку, ошибку и сообщение об успехе. По отдельности каждая строка может выглядеть удачно, но вместе они способны противоречить друг другу: кнопка обещает завершить действие, а следующий экран только просит подтвердить данные.
Передайте модели строки как текст с названиями элементов. Если важна последовательность, опишите её словами: какой экран виден сначала, после какого действия возникает ошибка и что происходит при повторной попытке. Не полагайтесь лишь на впечатление от макета: проверка формулировок требует точных строк, которые реально попадут в интерфейс.
Ты - редактор текстов интерфейса. Проверь один пользовательский сценарий, не меняя правила продукта. Не утверждай, что действие завершено, если это не следует из описания.
Цель пользователя: [например, отправить заявку]
Подтверждённые правила: [что точно происходит до и после отправки]
Состояния по порядку: [до ввода, заполнение, ошибка, успех]
Тон и терминология: [обращение, допустимые термины]
Текущие строки:
- Заголовок: [текст]
- Поле: [текст]
- Подсказка: [текст]
- Кнопка: [текст]
- Ошибка: [текст]
- Успех: [текст]
Сначала найди проблемы: непонятное действие, противоречие между состояниями, обвиняющий тон, неподтверждённое обещание, неоднозначный термин. Для каждой проблемы процитируй исходную строку и объясни риск для пользователя. Затем предложи замену только для проблемных строк. Если для замены нужен неизвестный факт, вместо текста напиши вопрос команде. В конце проверь, согласованы ли название действия на кнопке и сообщение после него.Это не просьба «сделать дружелюбнее». У неё есть наблюдаемый результат: перечень конкретных строк, объяснение проблемы и правка, которую можно принять или отклонить.
Три места, где такой подход особенно полезен
Форма с ошибкой
Проверьте связку «поле → ошибка → исправление». Сообщение «Неверный формат» само по себе мало помогает: человеку нужно понять, какое поле исправлять и какой ввод ожидается. Но пример допустимого формата можно писать только после подтверждения правила валидации. Если правило неизвестно, сначала запросите его у разработки.
Онбординг
Сверьте обещание на первом экране с тем, что пользователь сможет сделать на следующем. Если кнопка называется «Начать работу», а дальше ещё обязательная настройка, обсудите с командой более точное название действия. Здесь полезно попросить Claude отдельно отметить фразы, которые создают ожидание завершённого результата.
Подтверждение чувствительного действия
Для удаления, отмены или отправки данных составьте последовательность из экрана подтверждения и итогового состояния. Проверьте, ясно ли назван объект действия и можно ли понять последствия из подтверждённых правил. Не поручайте модели самостоятельно решать, обратимо ли действие: такой ответ должен прийти от владельца продукта.
Как принять результат без лишнего круга согласований
- Сравните с источником. Каждая новая деталь в брифе должна иметь подтверждение либо статус открытого вопроса.
- Пройдите сценарий вслух. Читайте только те строки, которые видит пользователь, в порядке появления. Так заметнее смена терминов и противоречия.
- Проверьте крайние состояния. Что написано при пустом поле, неверном вводе, повторной отправке и успешном завершении? Оставьте только состояния, которые действительно предусмотрены.
- Отдайте спорные пункты владельцам решений. Дизайнер может уточнить смысл, но не устанавливать сроки, условия обработки данных или бизнес-правила текстовой правкой.
- Проверьте строки в макете. Даже точная фраза может не поместиться или потерять смысл рядом с другими элементами. Финальное решение принимайте в контексте экрана.
Я бы сохранял итог в двух частях: короткий бриф с подтверждёнными требованиями и отдельный список вопросов. Для текстов интерфейса удобна такая же дисциплина: исходная строка, причина изменения, новая строка, ответственное лицо за проверку факта. Тогда обсуждение идёт о сценарии и смысле, а не о том, какой вариант «звучит красивее».
Главное ограничение этого процесса простое: Claude помогает сформулировать и проверить текст, но не знает за команду, как устроен конкретный продукт. Чем лучше вы обозначили известные правила и пробелы, тем легче использовать ответ как рабочий черновик, а не как источник неподтверждённых решений.
