Сайт может начать дорожать ещё до того, как разработчик напишет первую строку кода.

Не потому, что подрядчик внезапно решил увеличить смету. А потому, что по ходу проекта выясняется: нужен второй язык, заявки должны попадать в CRM, каталог будет загружаться из 1С, тексты писать некому, а вместо простой формы заказа требуется полноценный расчёт стоимости.

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

Поэтому перед заказом сайта не нужно писать техническое задание на 40 страниц. Гораздо полезнее подготовить ответы на вопросы о бизнесе, клиентах, контенте и процессах.

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

 

Главное: вам не нужно заранее проектировать сайт

Начнём с того, что снимает половину головной боли.

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

Бизнесу нужно хорошо объяснить задачу. Подрядчику — предложить способ её решения.

Формулировка «Нам нужна интеграция с CRM» оставляет десятки вопросов.

А вот «Посетитель оставляет заявку. Она должна автоматически появляться в Bitrix24, создаваться как новая сделка, а ответственному менеджеру должно приходить уведомление» — это уже понятный бизнес-сценарий.

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

Поэтому хороший старт разработки — это не готовое ТЗ. Это ситуация, когда обе стороны одинаково понимают, для кого строится сайт, что пользователь должен на нём сделать и какие процессы должны происходить после этого.

 

1. Сформулируйте, зачем бизнесу вообще нужен новый сайт

«Хотим современный сайт» — ещё не задача.

Попробуйте закончить предложение: «После запуска сайта мы хотим, чтобы…»

Например: «…клиенты могли самостоятельно подобрать оборудование и отправить запрос на расчёт». Или: «…по каждой нашей услуге была отдельная посадочная страница, которую можно продвигать в Google и Яндексе». Или: «…покупатель мог выбрать товар, оплатить заказ и оформить доставку без участия менеджера».

Эти три сайта будут совершенно разными.

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

Поэтому вопрос «Какой сайт вы хотите?» полезно заменить на: «Что человек должен суметь сделать с помощью сайта?»

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

Подробнее о форматах: корпоративный сайт, лендинг, интернет-магазин.

 

2. Опишите не «целевую аудиторию», а людей, которые принимают решение

Фраза «мужчины и женщины 25–55 лет со средним и высоким доходом» разработчику почти ничем не поможет.

Для сайта гораздо полезнее понимать, кто пришёл, зачем пришёл и что ему мешает принять решение.

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

Продукт один. Информация, которая помогает принять решение, — разная.

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

Из этих ответов начинают появляться будущие страницы, блоки и пользовательские сценарии.

Именно поэтому структуру сайта лучше строить не вокруг организационной структуры компании — «Отдел №1», «Направление №2», «Департамент №3», — а вокруг вопросов клиента.

 

3. Определите главное действие на каждой важной странице

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

Человек прочитал страницу услуги. Что дальше? Позвонить? Получить расчёт? Отправить техническое задание? Записаться на встречу? Скачать каталог? Посмотреть проекты? Перейти к товару?

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

Полезный способ проверить будущую страницу — сформулировать её логику одной строкой: «Посетитель приходит с вопросом X → получает информацию Y → убеждается благодаря Z → делает действие N».

Например: «Ищет поставщика металлопроката → видит ассортимент и сертификаты → проверяет условия поставки → отправляет запрос на расчёт».

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

 

4. Подготовьте список информации, а не готовую структуру сайта

Заказчику полезно знать, что он хочет показать. Но необязательно заранее решать, каким будет меню и сколько точно страниц понадобится.

Допустим, у компании есть: услуги, отраслевые решения, проекты, сертификаты, команда, оборудование, вакансии и филиалы.

Этого уже достаточно, чтобы проектировщик начал собирать архитектуру.

Во время анализа может выясниться, что десять услуг стоит вынести на отдельные страницы, два раздела можно объединить, а для разных отраслей нужны самостоятельные посадочные страницы.

Особенно важно не утверждать структуру в отрыве от SEO, если поисковое продвижение входит в планы компании.

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

Поэтому вопрос «Какие пункты поставить в меню?» лучше задавать после вопроса: «Какую информацию ищут наши клиенты и какие направления мы хотим продвигать?»

Источник: Google Search Central — crawlable links

 

5. Описывайте функции сценариями — это резко повышает качество оценки

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

«Калькулятор». Какой? Три поля и умножение количества на цену? Или расчёт по десятку параметров, после которого создаётся коммерческое предложение и информация уходит менеджеру?

«Личный кабинет». Что человек делает внутри? Только смотрит заказы? Загружает документы? Оплачивает счета? Видит персональные цены? Общается с менеджером?

«Интеграция с 1С». Какие данные и в какую сторону передаются? Цены? Остатки? Заказы? Клиенты? Статусы? Как часто должна происходить синхронизация?

Поэтому вместо названия функции описывайте путь: пользователь делает → система делает → сотрудник получает → данные сохраняются.

Хороший пример: «Покупатель выбирает товар → указывает город → видит доступные варианты доставки → оплачивает заказ → заказ создаётся в учётной системе → менеджер получает уведомление».

По такому описанию подрядчик уже может задавать конкретные вопросы. А по фразе «нужна доставка и интеграция» — практически нет.

 

6. Разделите функции на «нужны к запуску» и «хорошо бы когда-нибудь»

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

Если всё сразу объявить обязательным, первая версия сайта начинает разрастаться.

Гораздо полезнее задать каждому требованию вопрос: «Без этой функции сайт в день запуска сможет решать свою основную задачу?»

Если нет — это первая версия. Если сможет — функцию можно рассмотреть как следующий этап.

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

Именно здесь становится понятнее и бюджет.

См. также: Сколько стоит сайт в Казахстане в 2026 году

 

7. Проведите инвентаризацию контента до дизайна

Есть простой вопрос, который полезно задать до первого макета: «Чем мы наполним эти страницы?»

Представьте: в структуре есть раздел «Наши проекты». Дизайнер закладывает красивые кейсы с крупными фотографиями, задачей, процессом и результатами. А потом выясняется, что у компании есть только названия пяти клиентов и несколько фотографий из WhatsApp.

Это меняет сам блок. То же самое происходит с командой, отзывами, сертификатами, каталогами, видео и описаниями услуг.

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

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

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

 

8. Решите, кто пишет тексты, до начала проекта

«Тексты потом дадим» — одна из самых опасных фраз в проекте.

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

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

Если старые тексты планируется перенести, сначала стоит решить, действительно ли они подходят новой структуре.

Дизайн и текст не должны встречаться впервые в день наполнения сайта. Хороший интерфейс строится вокруг реального содержания: длины заголовков, количества характеристик, фотографий, доказательств, таблиц и сценариев.

 

9. Для Казахстана языковые версии лучше обсуждать сразу

Если компании нужны русский и казахский языки, а в будущем — английский, это не стоит оставлять на последний день перед запуском.

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

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

Поэтому достаточно заранее сказать подрядчику: «На запуске нужны русский и казахский. Английский возможен позже». Технический способ реализации пусть предложит команда.

 

10. Если планируете SEO — скажите об этом до того, как нарисован весь сайт

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

Сайт уже готов, а затем выясняется, что несколько услуг объединены на одной странице, хотя люди ищут их отдельно. Или нужный раздел спрятан слишком глубоко. Или каталог создаёт десятки ненужных вариантов URL. Или CMS неудобно управляет метаданными.

Поэтому поисковые задачи лучше учитывать ещё при проектировании.

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

Если органический трафик — важный канал продаж, архитектуру сайта имеет смысл проектировать вместе с SEO.

А если новый проект заменяет уже работающий сайт, задача становится ещё серьёзнее: нельзя просто забыть о старых URL, страницах, ссылках и накопленном трафике.

По теме: SEO и продвижение; Редизайн сайта без потери позиций и трафика

 

11. Решите заранее, что вы хотите измерять после запуска

Фраза «хотим больше заявок» понятна как бизнес-желание, но для аналитики её недостаточно.

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

Это влияет на то, какие события и цели нужно подготовить.

Особенно полезно сделать ещё один шаг и понять, какие источники нужно различать.

Если компания собирается запускать контекстную рекламу, SEO, соцсети и рассылки, после запуска должно быть возможно понять не только «были заявки», но и откуда они пришли.

Иначе через несколько месяцев бизнес получает красивый сайт и довольно неприятный вопрос: «А он вообще работает?» — на который никто не может ответить данными.

 

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

CRM, 1С, ERP, платёжные сервисы, службы доставки, телефония, email, карты, система бронирования, складская программа.

Не нужно знать API и способы авторизации.

Запишите три вещи: какая система используется → какие данные получает → какие данные должна отдавать.

Например: «1С → сайт: товары, цены, остатки. Сайт → 1С: созданные заказы».

Это уже намного полезнее фразы: «Нужна интеграция с 1С».

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

 

13. Не забудьте про домен, хостинг и доступы

Если сайт уже существует, до начала работ полезно выяснить, у кого находятся доступы к домену, хостингу, CMS, аналитике, Search Console, Яндекс Вебмастеру, корпоративной почте и сервисам, которые связаны с сайтом.

Не нужно складывать все пароли в один Word-файл и отправлять его подрядчику.

Важнее понять, кто является владельцем каждого ресурса и кто может предоставить доступ, когда он понадобится.

Для доменов .KZ и .ҚАЗ есть отдельный казахстанский нюанс: интернет-ресурс с таким доменным именем должен размещаться на аппаратно-программном комплексе, расположенном на территории Республики Казахстан.

Поэтому место размещения сайта лучше выяснять до переезда на выбранный хостинг, а не после.

Источник: правила доменного пространства Казахстана

 

14. Формы — это не только дизайн: определите, какие данные действительно нужны

На большинстве коммерческих сайтов есть формы: имя, телефон, email, компания, комментарий.

Но чем больше полей, тем больше данных бизнес собирает и должен обрабатывать.

В Казахстане сбор и обработка персональных данных регулируются соответствующим законодательством; правила предусматривают требования к согласию на их сбор и обработку.

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

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

Источник: нормативная база Республики Казахстан

 

15. Назначьте одного человека, который говорит подрядчику «да» или «нет»

Пять сотрудников могут участвовать в проекте. Но финальное решение должен принимать кто-то один.

Иначе главная страница превращается в корпоративный референдум.

Маркетолог хочет больше текста. Руководитель продаж — больше форм. Директор — убрать половину блоков. Через неделю один из участников впервые видит макет и просит всё перестроить.

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

Поэтому ещё до старта определите: кто собирает комментарии и кто утверждает результат.

Это не запрещает команде обсуждать макеты. Просто подрядчик должен получать консолидированное решение.

 

16. Обсудите дедлайн вместе с причиной дедлайна

«Нужно к первому ноября» — полезная информация.

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

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

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

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

А вот фраза «чем быстрее, тем лучше» почти ничего не говорит о приоритетах.

 

17. Бюджет лучше обсуждать как ограничение, а не как игру в угадайку

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

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

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

Бюджет не обязан звучать как: «У нас ровно X тенге».

Можно обозначить диапазон или приоритет: «Нам нужна первая рабочая версия в таком диапазоне. Если всё сразу не помещается, покажите, что можно перенести на второй этап».

Тогда обсуждение идёт не вокруг того, «как потратить весь бюджет», а вокруг того, что даст бизнесу наибольшую ценность на первом запуске.

 

18. Договоритесь, что означает слово «готово»

Сайт открывается по домену. Он готов? Не обязательно.

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

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

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

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

Если своей технической команды нет: техническая поддержка сайта

 

Как понять, что ваш бриф уже достаточно хорош

Есть простой тест.

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

Если половина разговора уходит на «А что вы вообще продаёте?», «Кому?», «Что должен делать сайт?», «Какие функции нужны?», «Кто готовит контент?», «Какие интеграции?» — проект пока описан слишком абстрактно.

Если вопросы уже звучат так: «Когда заявка попадает в CRM, какого ответственного назначать?», «Остатки из 1С нужно обновлять в реальном времени или достаточно периодической синхронизации?», «Казахская версия запускается одновременно с русской?» — значит, разговор перешёл с угадывания задачи на проектирование решения.

Это и есть цель хорошей подготовки.

 

Самый короткий бриф, которого уже достаточно для первого разговора

 

1. Чем занимается компания и что именно нужно продвигать или продавать через сайт?
2. Почему новый сайт понадобился именно сейчас?
3. Кто основные посетители и кто принимает решение о покупке?
4. Что посетитель должен сделать на сайте?
5. Какие услуги, товары или направления обязательно нужно представить?
6. Какой контент уже есть: тексты, фото, видео, проекты, документы, отзывы?
7. Какие функции обязательны к первому запуску?
8. Какие функции можно оставить на второй этап?
9. С какими системами сайт должен интегрироваться?
10. Какие языки нужны?
11. Планируется ли SEO и платная реклама?
12. Какие действия пользователей нужно измерять?
13. Есть ли существующий сайт, домен и накопленный поисковый трафик?
14. Кто предоставляет материалы и кто утверждает результат?
15. Есть ли желаемая дата запуска и почему важна именно она?
16. Какой бюджет или диапазон рассматривается?
17. Что после запуска сотрудники хотят менять самостоятельно?
18. Кто будет отвечать за сайт после публикации?

 

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

 

И ещё один важный чек-лист: чего делать НЕ нужно

 

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

 

Хорошая подготовка — это не попытка выполнить половину работы веб-студии самостоятельно. Это способность дать подрядчику достаточно контекста, чтобы он не угадывал ваш бизнес.

 

Подготовленный заказчик получает не просто более понятную смету

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

Тогда обсуждение дизайна становится предметным.

Не «А давайте эту кнопку сделаем ярче», а «Это главное действие пользователя — достаточно ли хорошо оно заметно?»

Не «Хотим красивый каталог», а «Покупателю важно быстро отфильтровать 500 позиций по четырём характеристикам».

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

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

Если вы собираетесь заказать разработку сайта, необязательно приходить в Astana Creative с готовым техническим заданием. Достаточно понимать бизнес-задачу и принести исходные данные, которые у вас есть. Неясные части можно разобрать вместе: определить структуру, обязательный функционал, точки интеграции и состав первой версии проекта — и только после этого переходить к оценке и разработке.