ARG-WORK-285 — Brief for Designer, Developer or Contractor

Article ID: ARG-WORK-285

Title: Brief for Designer, Developer or Contractor

Purpose

Задать правила создания понятного, практичного и проверяемого технического задания для дизайнера,

разработчика, рекламного специалиста, SEO-специалиста, копирайтера, SMM-специалиста,

видеомонтажёра или другого подрядчика.

Эта статья нужна, чтобы ArgumAI не просто давал владельцу бизнеса советы, а помогал превращать

диагностику, аудит, маркетинговые выводы и идеи в рабочее задание, которое можно отправить

подрядчику.

Главная задача ТЗ — снизить риск недопонимания между владельцем бизнеса и исполнителем.

Хорошее ТЗ должно объяснять:

что нужно сделать;

зачем это нужно бизнесу;

какой результат ожидается;

какие исходные данные есть;

какие требования обязательны;

что подрядчик должен уточнить;

как будет приниматься работа;

какие риски нужно заранее учесть.

Use this article when

Использовать, когда пользователь просит:

подготовить ТЗ дизайнеру;

подготовить ТЗ разработчику;

подготовить ТЗ рекламщику;

подготовить ТЗ SEO-специалисту;

подготовить ТЗ копирайтеру;

подготовить ТЗ SMM-специалисту;

подготовить ТЗ видеомонтажёру;

подготовить задание на лендинг;

подготовить задание на сайт;

подготовить задание на баннер;

подготовить задание на рекламную кампанию;

подготовить задание на SEO-страницу;

подготовить задание на контент-план;

подготовить задание на визуалы;

подготовить список требований для подрядчика;

превратить аудит сайта в задачу для разработчика;

превратить маркетинговый разбор в список работ;

проверить, достаточно ли понятно сформулирована задача для исполнителя.

Do not use this article when

Не использовать эту статью вместо аудита подрядчика. Если пользователь просит проверить предложение

подрядчика — использовать Contractor Proposal Review.

Не использовать вместо проверки отчёта подрядчика. Если пользователь прислал отчёт — использовать

Contractor Report Review.

Не писать ТЗ как набор общих пожеланий.

Не формулировать задачи в стиле:

“сделать красиво”;

“улучшить сайт”;

“настроить рекламу”;

“продвинуть бизнес”;

“сделать современно”;

“увеличить продажи”.

Такие формулировки бесполезны без конкретных требований, результата и критериев приёмки.

Не обещать, что подрядчик точно достигнет заявок, продаж или прибыли.

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

“гарантировать 100 заявок” без учёта бюджета, ниши, сайта, оффера, обработки лидов и рынка.

Core principle

Главный принцип:

ТЗ должно быть не красивым документом, а инструментом управления работой подрядчика.

Плохое ТЗ:

«Нужно улучшить сайт, сделать его более продающим, современным и удобным.»

Хорошее ТЗ:

«Нужно переработать первый экран лендинга: сделать ясный H1, подзаголовок с оффером, видимый CTA,

кнопку WhatsApp на мобильной версии, блок доверия и понятный путь к заявке. Критерий приёмки:

пользователь за 5 секунд понимает, что предлагается, для кого, где работает бизнес и как обратиться.»

Required inputs

Желательно получить:

кто подрядчик: дизайнер, разработчик, рекламщик, SEO, SMM, копирайтер, видео, другой;

что нужно сделать;

бизнес и ниша;

город / регион / география;

язык аудитории;

целевая аудитория;

текущая проблема;

цель задачи;

текущие материалы: сайт, скриншоты, логотип, брендбук, тексты, реклама, аналитика;

что уже есть;

что нужно изменить;

какие ограничения есть;

желаемый срок;

бюджет, если пользователь готов его указать;

кто будет принимать работу;

как будет измеряться результат;

какие вопросы нужно задать подрядчику.

Minimum inputs

Минимально достаточно:

тип подрядчика;

задача;

цель;

исходные материалы или описание текущей ситуации.

Если данных мало, ArgumAI должен сделать черновик ТЗ и отдельно указать, что нужно уточнить.

Правильная формулировка:

«Ниже — первая версия ТЗ. Я исхожу из того, что задача — улучшить конверсию сайта, основной канал

обращения — WhatsApp, аудитория — русскоязычные клиенты в Израиле. Перед отправкой подрядчику

нужно уточнить сроки, бюджет и технические ограничения.»

Main workflow

1. Определить тип подрядчика

ArgumAI должен понять, кому предназначено задание.

Разные подрядчики требуют разного уровня детализации.

Дизайнеру нужны:

цель визуала;

аудитория;

формат;

композиция;

текст на макете;

стиль;

цвета;

примеры;

ограничения;

критерии качества.

Разработчику нужны:

страница / сайт / функция;

техническая среда;

CMS;

плагины;

структура;

адаптивность;

формы;

интеграции;

скорость;

безопасность;

критерии проверки.

Рекламщику нужны:

цель рекламы;

сегменты;

география;

язык;

бюджет;

оффер;

посадочные страницы;

конверсии;

ограничения;

отчётность;

тестовые гипотезы.

SEO-специалисту нужны:

страницы;

ключевые направления;

поисковый интент;

структура контента;

Title / Description;

внутренние ссылки;

технические ошибки;

локальный SEO-контекст;

критерии отчётности.

Копирайтеру нужны:

продукт;

аудитория;

оффер;

тон;

структура;

доказательства;

ограничения;

формат текста;

целевое действие.

SMM-специалисту нужны:

аудитория;

рубрики;

частота публикаций;

площадки;

стиль;

визуальная логика;

CTA;

KPI;

правила согласования.

1. Определить бизнес-цель

Задача подрядчика должна быть привязана к бизнес-цели.

Плохо:

«Сделать баннер.»

Лучше:

«Сделать баннер для Meta Ads, цель — остановить внимание владельцев малого бизнеса, которые не

понимают, куда уходит рекламный бюджет, и привести их к покупке доступа к ArgumAI.»

Плохо:

«Переделать сайт.»

Лучше:

«Переделать первый экран сайта так, чтобы посетитель за 5 секунд понял оффер, доверие и следующий

шаг.»

1. Указать исходные данные

В ТЗ нужно перечислить, что есть сейчас:

ссылка на сайт;

текущие скриншоты;

логотип;

тексты;

брендовые цвета;

примеры конкурентов;

рекламные материалы;

аналитика;

структура страниц;

список услуг;

отзывы;

фото;

видео;

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

ArgumAI не должен просить пользователя передавать чувствительные доступы через чат. Лучше писать:

«Доступы к сайту, рекламному кабинету или аналитике передаются подрядчику напрямую безопасным

способом, не через текст ТЗ.»

1. Сформулировать требования к результату

Требования должны быть конкретными.

Не:

«Сделать красиво.»

А:

«Подготовить 3 варианта первого экрана: desktop и mobile. В каждом варианте должны быть H1,

подзаголовок, CTA, кнопка WhatsApp, блок доверия и место для визуала.»

Не:

«Настроить рекламу.»

А:

«Подготовить структуру кампаний по сегментам, написать объявления, определить конверсионные

события, настроить отслеживание и подготовить первый отчёт через 7 дней после запуска.»

1. Разделить технические и маркетинговые требования

В хорошом ТЗ должны быть два слоя.

Технические требования отвечают на вопрос: как это должно работать.

Маркетинговые требования отвечают на вопрос: зачем это нужно клиенту и бизнесу.

Пример для лендинга:

Технические требования:

адаптивная версия для mobile / desktop;

форма заявки;

WhatsApp-кнопка;

быстрая загрузка;

корректные клики по CTA;

базовая SEO-разметка;

подключение аналитики.

Маркетинговые требования:

ясный оффер на первом экране;

доверие через отзывы / опыт / процесс;

понятный путь к заявке;

блок возражений;

локальный контекст Израиля;

язык аудитории;

CTA без давления.

1. Указать критерии приёмки

Критерии приёмки — обязательная часть ТЗ.

Они отвечают на вопрос: как понять, что работа выполнена.

Примеры:

страница корректно отображается на мобильном и desktop;

WhatsApp-кнопка работает;

форма отправляет заявку;

пользователь видит CTA без прокрутки;

текст не содержит недоказанных обещаний;

баннер читается на мобильном экране;

рекламные кампании разделены по языкам;

подрядчик предоставил список ключевых слов и минус-слов;

SEO-страница содержит H1, Title, Description, H2, FAQ и коммерческий блок;

отчёт содержит не только клики, но и заявки / конверсии / стоимость заявки.

1. Добавить вопросы к подрядчику

ТЗ должно не только давать задачу, но и фиксировать вопросы.

Примеры:

1. Какие данные вам нужны для начала?
2. Какие риски вы видите?
3. Что может повлиять на сроки?
4. Что не входит в стоимость?
5. Какие материалы должен предоставить заказчик?
6. Как будет происходить согласование?
7. Какие критерии результата вы предлагаете?
8. Как будет выглядеть отчёт?
9. Что будет считаться завершением работы?

10.Какие дополнительные расходы возможны?

1. Указать риски

ArgumAI должен помогать пользователю заранее видеть риски.

Типовые риски:

задача сформулирована слишком широко;

нет критериев приёмки;

подрядчик не отвечает за бизнес-результат;

нет аналитики;

нет доступа к данным;

слабый оффер;

сайт не готов к рекламе;

неясно, что считается заявкой;

не разделены языковые аудитории;

нет мобильной проверки;

нет сроков;

не определено, кто пишет тексты;

неясно, кто загружает материалы на сайт;

не оговорены правки;

не указано, что входит и не входит в работу.

Standard output format

Когда пользователь просит ТЗ, ArgumAI должен выдавать документ в рабочем формате.

ТЗ для [подрядчик / тип работы]

1. Цель задачи

[Что нужно получить и зачем это бизнесу.]

1. Контекст бизнеса

Бизнес:

Ниша:

География:

Язык аудитории:

Целевая аудитория:

Главная проблема:

1. Что нужно сделать
2. …
3. …
4. …
5. Исходные данные

Сайт:

Материалы:

Логотип / брендбук:

Тексты:

Фото / видео:

Аналитика:

Другое:

1. Маркетинговые требования

…

…

…

1. Технические требования

…

…

…

1. Требования к результату

…

…

…

1. Сроки и этапы
2. Этап 1:
3. Этап 2:
4. Этап 3:
5. Критерии приёмки

Работа считается выполненной, если:

…

…

…

1. Что нужно уточнить у подрядчика
2. …
3. …
4. …
5. Риски

…

…

…

1. Комментарий для владельца бизнеса

[Короткое объяснение, на что обратить внимание при передаче ТЗ.]

Brief types

1. ТЗ дизайнеру

Использовать для:

баннера;

креатива;

лендинга;

первого экрана;

соцсетей;

презентации;

обложки видео;

визуальной концепции.

Обязательно указать:

формат;

платформа;

цель;

аудитория;

главная мысль;

текст на макете;

композиция;

стиль;

цвета;

логотип;

что нельзя использовать;

критерий читаемости.

1. ТЗ разработчику

Использовать для:

WordPress;

Elementor;

лендинга;

формы;

мобильной версии;

скорости сайта;

интеграций;

аналитики;

исправления ошибок;

личного кабинета;

платного доступа.

Обязательно указать:

CMS / стек;

страницы;

функциональность;

адаптивность;

формы;

WhatsApp;

аналитика;

доступы передаются отдельно;

безопасность;

критерии проверки.

1. ТЗ рекламщику

Использовать для:

Google Ads;

Meta Ads;

YouTube Ads;

ретаргетинга;

структуры кампаний;

проверки текущей рекламы.

Обязательно указать:

цель;

бюджет;

география;

язык;

сегменты;

оффер;

посадочная страница;

конверсии;

отчётность;

что считать качественной заявкой;

вопросы по структуре кампаний.

1. ТЗ SEO-специалисту

Использовать для:

SEO-страниц;

технического SEO;

локального SEO;

структуры сайта;

внутренней перелинковки;

контента.

Обязательно указать:

целевые страницы;

интент;

регион;

язык;

Title / Description;

H1 / H2;

FAQ;

коммерческий блок;

локальные элементы;

критерии отчёта.

1. ТЗ копирайтеру

Использовать для:

страницы услуги;

рекламных текстов;

постов;

email;

WhatsApp-шаблонов;

SEO-статьи;

лендинга.

Обязательно указать:

аудитория;

оффер;

тон;

структура;

доказательства;

CTA;

запрет на недоказанные обещания;

примеры плохих формулировок;

формат результата.

Good / bad examples

Плохо:

«Сделайте современный дизайн сайта.»

Хорошо:

«Подготовить новый первый экран для страницы услуги. Цель — чтобы посетитель за 5 секунд понял: что

предлагается, для кого, в каком регионе работает бизнес и как оставить заявку. Обязательные элементы:

H1, подзаголовок, CTA, WhatsApp, 2–3 сигнала доверия, адаптация под mobile.»

Плохо:

«Настройте рекламу на русскоязычных в Израиле.»

Хорошо:

«Подготовить структуру рекламных кампаний для русскоязычных владельцев малого бизнеса в Израиле.

Разделить кампании по типу спроса: активный поиск в Google и скрытый спрос в Meta. Для каждой

кампании указать оффер, объявление, посадочную страницу, конверсию и критерий оценки качества

заявки.»

Плохо:

«Напишите SEO-текст на страницу.»

Хорошо:

«Подготовить SEO-страницу услуги для русскоязычной аудитории в Израиле. Текст должен отвечать на

поисковый интент, объяснять услугу, показывать доверие, содержать FAQ, локальный контекст,

коммерческий переход и CTA. Не использовать недоказанные обещания и пустые фразы вроде “лучшие

специалисты”.»

Israel-specific rules

Для подрядчиков в Израиле учитывать:

язык аудитории;

русский / иврит / английский;

локальный регион;

WhatsApp как канал заявки;

шаббат и праздники, если это влияет на сроки и обработку обращений;

Google Business Profile для локального бизнеса;

доверие через реальные отзывы, лицензии, фото, адрес, опыт;

стоимость рекламы и конкуренцию;

мобильную версию как приоритет;

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

What ArgumAI must not do

ArgumAI не должен:

обещать пользователю, что ТЗ гарантирует результат;

подменять профессиональный договор юридическим документом;

писать обвинительное ТЗ подрядчику;

требовать невозможных гарантий;

выдумывать технические детали, если они неизвестны;

включать в ТЗ фальшивые кейсы, отзывы, цифры;

давать подрядчику расплывчатую задачу без критериев;

забывать про мобильную версию;

забывать про измерение результата;

забывать про ограничения MVP, закона и платформ.

Quality checklist

Перед выдачей ТЗ проверить:

понятно ли, кому оно адресовано;

есть ли бизнес-цель;

есть ли исходные данные;

есть ли конкретный список работ;

разделены ли маркетинговые и технические требования;

есть ли критерии приёмки;

есть ли вопросы к подрядчику;

указаны ли риски;

нет ли недоказанных обещаний;

нет ли лишней теории;

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

Internal note

Эта статья должна использоваться вместе с:

ARG-CORE-004 — Truth, Assumptions and Missing Data;

ARG-METHOD-150 — Offer Engineering;

ARG-METHOD-170 — Argument Matrix;

ARG-METHOD-180 — Proof Map;

ARG-METHOD-190 — Conversion Path;

ARG-WORK-210 — Website and Landing Page Audit;

ARG-WORK-225 — Google Ads Check-Up;

ARG-WORK-230 — Meta Ads Check-Up;

ARG-WORK-235 — Contractor Proposal Review;

ARG-WORK-240 — Contractor Report Review;

ARG-WORK-280 — Visual Strategy and Image Prompting;

ARG-QA-910 — Proof and Claims Check.

Главное правило:

ТЗ должно превращать идею в проверяемую задачу: что сделать, зачем, как принять работу и какие

риски проверить до начала.