Как описать продукт для ИИ-команды: бриф из пяти блоков

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

Почему не ТЗ на сорок страниц

Классическое техническое задание пишут для подрядчика, с которым потом сверяются по пунктам на приёмке. Для ИИ-команды такой документ избыточен: программировать не нужно, продукт описывается словами, а превью появляется рядом с чатом. Несоответствие видно сразу, а не на сдаче работ.

Но «словами» не значит «как получится». ИИ-команда не знает вашего бизнеса. Всё, что вы не сказали, она заполнит типовыми решениями: придумает разделы, поля формы, тексты. Иногда типовое решение попадает в цель, чаще оно оказывается средним по рынку. Задача брифа — закрыть ровно те места, где среднее вам не подходит.

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

Пять блоков брифа

1. Задача бизнеса. Зачем нужен продукт и как вы поймёте, что он работает. Не «чтобы было присутствие в интернете», а «получать заявки на замер кухни» или «чтобы менеджеры вели сделки не в таблице».
2. Пользователи. Кто приходит и с чем. Двух-трёх типов достаточно: покупатель, постоянный клиент, сотрудник. Для каждого — одна фраза о том, что ему важно.
3. Действия. Что пользователь должен сделать: оставить заявку, найти товар и оформить заказ, зарегистрироваться и посмотреть историю, сменить статус сделки. Это главный блок — именно действия превращаются в формы, кнопки и экраны.
4. Данные. Что сохраняется и какие поля у каждой записи: заявки, товара, заказа, объявления, клиента. Подробнее — в отдельном разделе ниже.
5. Тип продукта. Лендинг, интернет-магазин, портал с объявлениями, поиском и кабинетами или рабочая панель с таблицами, KPI и доступами. Если не уверены, какой тип ваш, сначала посмотрите сравнение лендинга, магазина, портала и панели: ошибка в типе обходится дороже любой опечатки.

Порядок выбран не случайно. Тип продукта стоит последним, потому что он следует из задачи и действий, а не наоборот. Кто начинает с «хочу портал», часто получает лишние кабинеты там, где хватило бы формы заявки.

Слабая и сильная формулировка

Представим условную мастерскую, которая делает кухни на заказ. Это пример формулировки, а не кейс, поэтому никаких результатов здесь нет.

Слабый вариант:

«Нужен современный красивый сайт для мебельной компании. Кухни на заказ. Чтобы были заявки и выглядело дорого».

Что не так: нет ни одного действия, кроме размытого «чтобы были заявки»; не сказано, кто клиент; «дорого» каждый понимает по-своему; непонятно, какие данные собирать. Скорее всего, ИИ-команда соберёт лендинг с общей формой «имя и телефон» — и формально выполнит задачу.

Сильный вариант:

«Задача: получать заявки на бесплатный замер кухни в нашем городе. Пользователи: семьи, которые делают ремонт, и дизайнеры интерьера, которые приводят своих клиентов. Действия: посмотреть готовые кухни по стилям, понять, из чего складывается цена, записаться на замер. Данные: у заявки есть имя, телефон, район, стиль кухни (современный, классика, лофт), желаемые сроки, комментарий и отметка „я дизайнер“. Тип: лендинг с галереей работ и формой заявки, заявки сохраняются в базу».

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

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

Данные: какие поля назвать сразу

Поля — место, где типовое решение чаще всего расходится с реальностью. Заявки пишутся в настоящую базу данных, и если в форме нет нужного поля, менеджер будет доспрашивать клиента по телефону. Назовите поля в первом же описании.

Заявка

• контакты: имя и телефон или почта;
• то, без чего нельзя назвать цену или срок: объём, адрес или район, вид услуги;
• то, что помогает расставить приоритеты: желаемые сроки, откуда узнали, комментарий.

Каталог

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

Кабинет

• что пользователь видит после входа: свои заявки, заказы или объявления;
• какие записи видны всем, а какие — только их автору после входа.

Учтите границы сборки: посетитель может добавлять записи и видеть свои, но не редактировать их — изменения вносит владелец проекта в базе данных проекта в редакторе. Роли вроде «руководитель видит все записи» и редактирование из кабинета дописывает разработчик в выгруженном коде.

Технические термины не нужны. Достаточно человеческого списка: «у заказа есть номер, дата, товары, сумма и статус».

Чем не перегружать первое описание

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

• Точные цвета, шрифты, анимации. Хватит одной фразы о характере: строго, тепло, по-деловому. Оттенки проще подбирать, глядя на превью.
• Все тексты целиком. Дайте ключевые факты: что продаёте, чем отличаетесь, какие условия. Шлифовать формулировки лучше потом.
• Десятки страниц сразу. Опишите главный сценарий, второстепенные разделы добавите следующими сообщениями.
• Обмен данными с внешними системами. Связка с вашим учётом или сторонними сервисами — это доработка разработчиком выгруженного кода, а не пункт первого брифа.
• Противоречия. «Минимализм» и «побольше информации на главной» в одном сообщении заставят ИИ-команду выбирать за вас.

Отдельно про генерации. На пробном тарифе их 10 разово, до 3 проектов. Каждая генерация, потраченная на исправление недопонимания, — минус одна итерация по существу. Пять минут на бриф здесь окупаются напрямую.

Готовые примеры как отправная точка

В редакторе есть готовые примеры по типам продуктов: магазин, портал, рабочая панель, лендинг. Если ваш продукт похож на один из них, не начинайте с чистого листа. Откройте пример, посмотрите, как он устроен, и опишите только отличия: «как этот магазин, но вместо корзины — запрос расчёта, а у товара есть поле „минимальная партия“».

Так бриф становится короче: не нужно объяснять очевидное, только то, чем ваш бизнес отличается от типового. Весь путь от идеи до опубликованного проекта разобран в пошаговом руководстве по запуску продукта.

Первое превью: что проверить до правок

Когда справа от чата появилось превью, не спешите менять цвет кнопки. Сначала проверьте каркас — его переделывать дороже всего:

1. Пройдите главный сценарий каждого пользователя от начала до конца. Можно ли сделать всё, что записано в блоке «Действия»?
2. Проверьте, что в каталоге есть характеристики, по которым выбирают, а не только название и цена.
3. Если есть регистрация, зайдите под тестовым пользователем и посмотрите, что он видит в кабинете.
4. Опубликуйте проект по ссылке и откройте его с телефона.
5. Отправьте тестовую заявку и найдите её в разделе «Заявки с проектов». Учтите, что там у заявки фиксированный набор полей — имя, телефон, почта, сообщение, проект, дата и статус; все поля вашей формы проверяйте в базе данных проекта в редакторе.
6. Запишите замечания списком и отделите ошибки каркаса от вопросов оформления.

Ошибки каркаса исправляйте первыми, оформление — потом, по одной задаче за раз. Как формулировать такие задачи, чтобы не сломать уже сделанное, — в отдельной статье про правки словами.

Шаг на сегодня: откройте заметки и заполните пять блоков для своего продукта — по два-три предложения на каждый. Если текст сложился, его можно сразу отправить в редактор: регистрация и пробный тариф бесплатны.