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

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

Article ID: ARG-WORK-285

Title: Brief for Designer, Developer or Contractor

Purpose

Задать правила подготовки понятного рабочего brief-а для дизайнера, web-разработчика, рекламщика, SEO-специалиста, SMM-специалиста, копирайтера, монтажёра, маркетолога, агентства или другого подрядчика.

Эта статья нужна, чтобы ArgumAI помогал пользователю не просто “объяснить задачу”, а подготовить документ, по которому подрядчик сможет работать без лишних догадок, а владелец бизнеса сможет контролировать результат.

Brief должен помогать:

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

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

Хороший brief защищает обе стороны: пользователь понимает, что заказывает, а подрядчик понимает, что должен сделать.

Use this article when

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

• просит подготовить brief подрядчику;
• хочет написать задачу дизайнеру;
• хочет написать задачу разработчику;
• хочет написать задачу рекламщику;
• хочет написать задачу SEO-специалисту;
• хочет написать задачу SMM-специалисту;
• хочет написать задачу копирайтеру;
• хочет написать задачу монтажёру;
• хочет подготовить ТЗ;
• хочет объяснить подрядчику, что нужно сделать;
• хочет отправить задачу в WhatsApp, email или рабочий чат;
• хочет сравнить предложения подрядчиков;
• хочет запросить КП;
• хочет избежать недопонимания;
• после анализа бизнеса выбран следующий шаг: подготовить brief подрядчику.

Do not use this article when

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

Если пользователь прислал предложение подрядчика — использовать ARG-WORK-235.

Если пользователь прислал отчёт подрядчика — использовать ARG-WORK-240.

Если пользователь прислал скриншот — использовать ARG-WORK-245.

Если пользователь просит составить рекламные кампании — использовать ARG-WORK-265.

Если пользователь просит написать рекламный текст — использовать ARG-WORK-260.

Если пользователь просит визуальную концепцию или промпт изображения — использовать ARG-WORK-280.

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

Core principle

Brief должен быть конкретным, но не перегруженным.

Он должен отвечать на вопросы:

• кто заказчик;
• что нужно сделать;
• зачем это нужно;
• для кого это делается;
• какой результат должен быть на выходе;
• какие материалы есть;
• какие ограничения есть;
• какие сроки;
• как будет проверяться готовность;
• что входит в задачу;
• что не входит;
• какие вопросы подрядчик должен уточнить до начала работы.

Плохой brief:

«Нужно сделать красивый лендинг.»

Хороший brief:

«Нужно подготовить лендинг для услуги проверки рекламы для малого бизнеса в Израиле. Цель страницы — получить заявки в WhatsApp. Аудитория — русскоязычные владельцы бизнеса, которые уже платят за рекламу, но не понимают результат. На странице должны быть первый экран с оффером, блок проблем, описание услуги, доказательства, процесс работы, цена, FAQ и кнопки WhatsApp.»

Main restriction

ArgumAI не должен писать brief, если неясно:

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

Если данных мало, нужно задать вопросы.

Если пользователь хочет быстрый черновик, можно подготовить brief на гипотезах, но отметить:

«Это черновик brief-а. Перед отправкой подрядчику нужно уточнить детали, сроки, формат результата и критерии готовности.»

Required inputs

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

1. Кому нужен brief: дизайнеру, разработчику, рекламщику, SEO, SMM, копирайтеру, монтажёру, агентству, другому подрядчику.
2. Название бизнеса.
3. Что делает бизнес.
4. География бизнеса.
5. Язык аудитории.
6. Основная аудитория.
7. Что именно нужно сделать.
8. Зачем это нужно.
9. Где будет использоваться результат.
10. Какой результат пользователь хочет получить.
11. Какие материалы уже есть.
12. Какие материалы нужно подготовить подрядчику.
13. Есть ли брендбук, логотип, цвета, шрифты.
14. Есть ли сайт, ссылки, примеры.
15. Есть ли тексты.
16. Есть ли фото, видео, отзывы, кейсы.
17. Есть ли технические ограничения.
18. Есть ли юридические или рекламные ограничения.
19. Сроки.
20. Бюджет или диапазон, если пользователь хочет указать.
21. Формат сдачи результата.
22. Критерии готовности.
23. Кто утверждает работу.
24. Сколько правок включить.
25. Что точно не нужно делать.
26. Какая коммуникация удобна: WhatsApp, email, Google Docs, Trello, ClickUp, другое.

Minimum inputs

Для базового brief-а достаточно:

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

Если нет даже этих данных, сначала задать вопросы.

Default question list

Если данных мало, использовать:

«Чтобы подготовить brief не на догадках, ответьте коротко:

1. Кому нужен brief: дизайнеру, разработчику, рекламщику, SEO, SMM, копирайтеру или другому подрядчику?
2. Что именно нужно сделать?
3. Для какого бизнеса?
4. Кто аудитория?
5. Какая цель задачи?
6. Где будет использоваться результат?
7. Какие материалы уже есть: сайт, логотип, тексты, фото, отзывы, примеры?
8. Какие сроки?
9. Какой формат результата нужен?
10. Что точно не нужно делать?
11. На каком языке должен быть результат?
12. Нужен короткий brief для WhatsApp или подробное ТЗ?»

One question at a time mode

Если пользователь выбрал вопросы по одному, начинать:

«Начнём с главного: кому готовим brief — дизайнеру, разработчику, рекламщику, SEO-специалисту, SMM или другому подрядчику?»

Дальше идти по логике:

1. тип подрядчика;
2. задача;
3. бизнес;
4. цель;
5. аудитория;
6. материалы;
7. формат результата;
8. сроки;
9. ограничения;
10. критерии готовности.

Brief creation workflow

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

Brief зависит от того, кому он адресован.

Возможные типы:

• дизайнер;
• web-разработчик;
• рекламщик;
• SEO-специалист;
• SMM-специалист;
• копирайтер;
• монтажёр видео;
• фотограф;
• маркетолог;
• агентство;
• технический специалист;
• подрядчик по Elementor / WordPress;
• подрядчик по аналитике;
• подрядчик по CRM;
• переводчик;
• специалист по ивриту;
• специалист по креативам.

Нельзя писать одинаковый brief для всех.

2. Определить цель задачи

Цель должна быть бизнесовой, а не только технической.

Плохо:

«Нужно сделать баннер.»

Лучше:

«Нужно сделать баннер для Facebook-рекламы, цель — быстро объяснить оффер и привести человека в WhatsApp.»

Плохо:

«Нужно сделать сайт.»

Лучше:

«Нужно сделать посадочную страницу, которая объясняет услугу, вызывает доверие и приводит заявки через WhatsApp или форму.»

3. Описать бизнес кратко

Подрядчику нужно понимать контекст.

В brief-е должно быть:

• что делает бизнес;
• где работает;
• на каком языке общается;
• кто клиент;
• что продаётся;
• какой главный оффер;
• чем бизнес отличается;
• какой следующий шаг нужен от клиента.

Не нужно перегружать историей компании, если это не помогает задаче.

4. Описать аудиторию

Подрядчик должен понимать, для кого делает работу.

Указать:

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

Для Израиля особенно важно уточнить:

• русскоязычная аудитория;
• ивритоязычная аудитория;
• англоязычная аудитория;
• смешанная аудитория;
• локальный город или регион;
• WhatsApp как канал обращения;
• культурная адаптация языка.

5. Описать задачу

Задача должна быть конкретной.

Формат:

«Нужно сделать [что] для [где используется], чтобы [цель].»

Примеры:

• «Нужно разработать первый экран лендинга для услуги проверки рекламы.»
• «Нужно подготовить 5 баннеров для Meta Ads.»
• «Нужно сверстать страницу в Elementor по готовому тексту.»
• «Нужно подготовить структуру Google Ads для трёх услуг.»
• «Нужно сделать SEO-оптимизацию страницы услуги.»
• «Нужно смонтировать короткое видео для Reels.»
• «Нужно подготовить визуальные креативы для A/B-теста.»

6. Описать результат на выходе

Указать, что пользователь должен получить.

Например:

Для дизайнера:

• Figma-макет;
• PNG / JPG;
• адаптации размеров;
• исходник;
• мобильная версия;
• варианты для теста.

Для разработчика:

• готовая страница;
• адаптивная версия;
• подключенная форма;
• WhatsApp-кнопка;
• базовая SEO-структура;
• проверка скорости;
• доступы / инструкция.

Для рекламщика:

• структура кампаний;
• список аудиторий;
• список ключевых слов;
• тексты объявлений;
• настройки конверсий;
• план теста;
• отчётность.

Для SEO:

• список задач;
• meta title;
• meta description;
• H1 / H2;
• структура текста;
• внутренние ссылки;
• schema, если нужно;
• Search Console check;
• список технических правок.

Для SMM:

• контент-план;
• тексты постов;
• визуальные рекомендации;
• даты публикаций;
• рубрики;
• CTA;
• правила ответов на комментарии.

7. Указать материалы

Подрядчику нужно знать, что уже есть.

Материалы:

• сайт;
• логотип;
• брендбук;
• фото;
• видео;
• тексты;
• отзывы;
• кейсы;
• доступы;
• статистика;
• примеры конкурентов;
• старые объявления;
• рекламные отчёты;
• Google Drive;
• Figma;
• WordPress доступ;
• Elementor шаблоны;
• CRM;
• Google Analytics;
• Google Tag Manager;
• Google Ads;
• Meta Business Manager.

Если материалов нет, brief должен сказать, кто их готовит.

8. Указать ограничения

Ограничения могут быть:

• язык;
• стиль;
• брендовые цвета;
• нельзя использовать определённые слова;
• нельзя обещать результат;
• нельзя использовать фото клиентов;
• нельзя указывать цену;
• нельзя использовать агрессивный тон;
• соблюдать правила Google / Meta;
• соблюдать юридические ограничения;
• учитывать шаббат;
• учитывать географию Израиля;
• учитывать мобильную версию;
• не использовать стоковые лица;
• не использовать изображения, нарушающие права.

9. Указать сроки

Brief должен содержать:

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

Если сроки неизвестны, нужно написать:

«Подрядчик должен предложить реалистичный срок по этапам.»

10. Указать критерии готовности

Критерии готовности нужны, чтобы избежать спора.

Примеры:

• страница корректно открывается на мобильном;
• форма отправляет заявки;
• WhatsApp-кнопка работает;
• все тексты вставлены без ошибок;
• дизайн соответствует утверждённому стилю;
• подготовлены все размеры баннеров;
• кампания содержит согласованные группы;
• конверсии настроены и проверены;
• SEO-поля заполнены;
• отчёт передан в понятном формате.

11. Указать, что не входит

Важно фиксировать, что не входит в задачу.

Например:

• написание текстов;
• перевод на иврит;
• дизайн;
• разработка;
• покупка изображений;
• настройка рекламы;
• рекламный бюджет;
• SEO;
• поддержка после запуска;
• интеграция CRM;
• дополнительные страницы;
• дополнительные правки;
• юридическая проверка текста.

Если не указать, что не входит, подрядчик и пользователь могут понимать объём по-разному.

12. Указать вопросы подрядчику

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

Примеры:

• Что вам нужно от нас для старта?
• Какие данные нужны?
• Какие есть риски?
• Что может повлиять на сроки?
• Что не входит в стоимость?
• Как будет выглядеть финальный результат?
• Сколько раундов правок включено?
• В каком формате вы передадите результат?
• Как мы будем проверять готовность?

Output format — standard brief

Использовать по умолчанию:

Brief for Contractor

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

• Бизнес:
• Что продаём:
• География:
• Язык:
• Основная аудитория:
• Главный оффер:
• Канал обращения:

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

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

3. Задача подрядчику

Нужно сделать:
[…]

4. Аудитория

• Кто:
• В какой ситуации:
• Что важно для клиента:
• Что должно вызвать доверие:

5. Что должно быть на выходе

• …
• …
• …

6. Материалы, которые есть

• …
• …

7. Материалы, которые нужно подготовить

• …
• …

8. Ограничения и требования

• …
• …

9. Сроки

• Первый вариант:
• Правки:
• Финальная сдача:

10. Критерии готовности

Работа считается готовой, когда:

1. …
2. …
3. …
4. Что не входит в задачу

• …
• …

12. Вопросы подрядчику перед стартом
13. …
14. …
15. …

Output format — short WhatsApp brief

Использовать, если пользователь хочет короткое сообщение подрядчику:

«Привет! Нужно сделать [задача].

Контекст: [коротко о бизнесе].
Цель: [зачем это нужно].
Аудитория: [кто клиент].
Нужный результат: [что должно быть на выходе].
Материалы: [что уже есть].
Важно учесть: [язык, стиль, ограничения, сроки].
Формат сдачи: [файлы / страница / структура / документ].

Пожалуйста, напиши:

1. что тебе нужно от меня для старта;
2. сколько времени займёт работа;
3. что входит в стоимость;
4. что не входит;
5. как будет выглядеть финальный результат.»

Output format — email brief

Использовать, если нужен более официальный формат:

Subject: Brief for [project/task]

Hello [Name],

I’m sending the brief for [task/project].

Business context:
[…]

Goal:
[…]

Target audience:
[…]

Task:
[…]

Expected deliverables:
[…]

Available materials:
[…]

Requirements and limitations:
[…]

Timeline:
[…]

Completion criteria:
[…]

Please confirm:

1. What information or materials you need from us.
2. What is included in your scope.
3. What is not included.
4. Estimated timeline.
5. Final deliverable format.
6. Number of revision rounds included.

Best,
[Name]

Output format — developer brief

Для разработчика:

Brief for Web Developer

1. Project context

• Website:
• Platform:
• WordPress / Elementor / WooCommerce / other:
• Current issue or task:
• Business goal:

2. Task

Нужно сделать:
[…]

3. Pages / elements

• …
• …

4. Functional requirements

• forms;
• WhatsApp button;
• phone click;
• responsive layout;
• speed;
• SEO fields;
• analytics;
• tracking;
• thank-you page;
• integrations.

5. Design requirements

• existing design;
• reference pages;
• colors;
• typography;
• mobile behavior.

6. Technical requirements

• platform;
• plugins;
• access;
• staging / live;
• backups;
• browser compatibility;
• mobile testing.

7. Materials

• texts;
• images;
• icons;
• links;
• examples.

8. Completion criteria

Work is complete when:

1. …
2. …
3. …
4. Questions for developer
5. …
6. …
7. …

Output format — designer brief

Для дизайнера:

Brief for Designer

1. Business context

• Business:
• Product / service:
• Audience:
• Language:
• Geography:
• Brand style:

2. Design task

Нужно сделать:
[…]

3. Goal

[Что дизайн должен помочь сделать.]

4. Formats and sizes

• …
• …

5. Key message

[…]

6. Visual direction

• mood;
• style;
• colors;
• composition;
• main focus;
• what to avoid.

7. Text on design

• headline:
• subheadline:
• CTA:
• additional text:

8. Materials

• logo;
• photos;
• brand colors;
• examples;
• references.

9. Deliverables

• Figma;
• PNG;
• JPG;
• editable source;
• mobile versions;
• adaptations.

10. Completion criteria

[…]

Output format — advertising contractor brief

Для рекламщика:

Brief for Advertising Contractor

1. Business context

• Business:
• Product / service:
• Geography:
• Language:
• Audience:
• Average check / client value, if known:

2. Advertising goal

• leads;
• calls;
• WhatsApp;
• purchases;
• bookings;
• consultation requests;
• test demand.

3. Channels

• Google Ads;
• Meta Ads;
• YouTube;
• LinkedIn;
• other.

4. Offer

[…]

5. Landing destination

• website;
• landing page;
• WhatsApp;
• lead form;
• call;
• product page.

6. Conversion tracking

• what counts as conversion;
• analytics status;
• events to set up;
• CRM / lead quality tracking.

7. Budget

[…]

8. Campaign structure expectations

• separate by language;
• separate by geography;
• separate by service;
• separate cold and retargeting;
• do not mix unrelated segments.

9. Reporting expectations

Report should include:

• spend;
• clicks;
• leads;
• CPL;
• lead quality;
• conversions;
• changes made;
• conclusions;
• next steps.

10. Questions for contractor
11. …
12. …
13. …

Output format — SEO brief

Для SEO-специалиста:

SEO Brief

1. Website and business

• Website:
• Business:
• Services:
• Geography:
• Languages:

2. Goal

• organic traffic;
• leads;
• local SEO;
• service pages;
• blog structure;
• technical SEO;
• rankings for commercial queries.

3. Pages to work on

• …
• …

4. Keywords / topics

• …
• …

5. Required work

• technical audit;
• meta titles;
• meta descriptions;
• H1 / H2;
• content structure;
• internal links;
• schema;
• Search Console;
• local SEO;
• Google Business Profile;
• page speed;
• indexation.

6. Deliverables

• audit document;
• list of fixes;
• optimized texts;
• keyword map;
• monthly report;
• next-step plan.

7. Reporting

Report should show:

• what was done;
• what changed;
• what results appeared;
• what is planned next.

Output format — SMM brief

Для SMM:

SMM Brief

1. Business context

• Business:
• Product / service:
• Audience:
• Language:
• Geography:
• Tone:

2. Goal

• awareness;
• trust;
• leads;
• community;
• event promotion;
• product sales;
• employer brand.

3. Platforms

• Facebook;
• Instagram;
• LinkedIn;
• TikTok;
• YouTube Shorts;
• other.

4. Content directions

• educational;
• trust-building;
• proof;
• product / offer;
• behind the scenes;
• client questions;
• local context;
• objections.

5. Deliverables

• content plan;
• post texts;
• visual briefs;
• publishing schedule;
• Stories;
• Reels;
• community management.

6. Requirements

• language;
• style;
• forbidden claims;
• brand tone;
• CTA;
• approval process.

7. Reporting

• posts published;
• reach;
• engagement;
• messages;
• leads;
• best-performing topics;
• next recommendations.

Decision rules

Если задача для дизайнера:

• фокус на визуальной цели, форматах, сообщении, материалах и критериях сдачи.

Если задача для разработчика:

• фокус на функциональности, платформе, доступах, адаптивности, формах, аналитике и критериях готовности.

Если задача для рекламщика:

• фокус на цели, аудитории, бюджете, каналах, конверсиях, отчётности и качестве заявок.

Если задача для SEO:

• фокус на страницах, запросах, технических задачах, Search Console, контенте и органических заявках.

Если задача для SMM:

• фокус на аудитории, рубриках, каналах, тоне, частоте и связи с бизнес-целью.

Если задача для копирайтера:

• фокус на аудитории, оффере, структуре текста, доказательствах, стиле и CTA.

Если задача для монтажёра:

• фокус на формате, сценарии, длительности, стиле, исходниках, музыке, титрах и финальном формате файла.

If user has very little information

Если пользователь просит brief, но даёт мало данных:

«Сейчас можно сделать только базовый brief. Я отмечу места, которые нужно заполнить перед отправкой подрядчику.»

Затем дать шаблон с placeholders:

• [указать бизнес]
• [указать аудиторию]
• [указать срок]
• [указать материалы]

If user wants “make it professional”

Подготовить более деловой формат:

• Project Background;
• Objective;
• Scope of Work;
• Target Audience;
• Deliverables;
• Requirements;
• Timeline;
• Acceptance Criteria;
• Questions Before Start.

If user wants “simple WhatsApp message”

Не перегружать.

Дать короткое сообщение, которое можно отправить подрядчику.

If user wants to compare contractors

Brief должен быть одинаковым для всех подрядчиков, чтобы сравнение было честным.

Добавить блок:

«Пожалуйста, ответьте в одном формате:

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

Israel-specific rules

Если бизнес работает в Израиле, brief должен учитывать:

• город или регион;
• язык аудитории;
• русский / иврит / английский / арабский;
• WhatsApp как канал заявки;
• мобильную версию;
• шаббат и праздники;
• локальные отзывы;
• Google Business Profile;
• стоимость рекламы;
• локальную конкуренцию;
• культурную адаптацию;
• доступность материалов на нужном языке;
• необходимость перевода не дословного, а адаптированного.

Для ивритоязычных материалов указывать:

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

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

• понятный язык;
• объяснение израильских реалий;
• доверие;
• WhatsApp;
• локальность;
• отсутствие перегруза терминами.

Important limitations

ArgumAI must not:

• писать brief без понимания задачи;
• выдумывать материалы, которых нет;
• обещать результат от имени подрядчика;
• включать в задачу лишние работы без согласия пользователя;
• делать юридическое ТЗ как официальный договор;
• скрывать важные ограничения;
• размывать критерии готовности;
• писать “сделать красиво” без конкретики;
• забывать про формат результата;
• забывать про сроки;
• забывать про доступы и собственность;
• забывать указать, что не входит в работу;
• смешивать задачи разных подрядчиков в один неуправляемый brief.

Correct phrases

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

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

Avoid phrases

Не использовать как единственное описание:

• «сделать красиво»;
• «сделать современно»;
• «настроить нормально»;
• «продвинуть сайт»;
• «вести соцсети»;
• «сделать рекламу»;
• «улучшить результат»;
• «как у конкурентов»;

без конкретизации.

Quality checklist

Перед отправкой brief-а проверить:

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

Final rule

Brief for Designer, Developer or Contractor должен превращать размытую задачу в управляемое рабочее задание.

ArgumAI должен помочь пользователю зафиксировать:

• цель;
• контекст;
• аудиторию;
• задачу;
• результат;
• материалы;
• ограничения;
• сроки;
• критерии готовности;
• вопросы подрядчику.

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

Хороший brief не просто объясняет, что нужно сделать. Он заранее снижает риск недопонимания, лишних правок, споров о результате и оплаты “за процесс без ясного выхода”.