Технічне завдання на сайт: що погодити до дизайну

Опишіть задачу через дію клієнта

Фраза «потрібен сучасний сайт» не пояснює, що перевіряти під час здачі. Краще: відвідувач знаходить потрібну послугу, бачить умови, обирає спосіб контакту й передає заявку менеджеру. Для магазину шлях інший: пошук товару, вибір варіанта, доставка та оформлення замовлення.

Запишіть головну дію й кілька допоміжних. Це дозволяє визначити пріоритети, якщо бюджет обмежений. Анімація першого екрана може зачекати, якщо ще не погоджено, куди надходить заявка.

Перерахуйте сторінки та шаблони

Кількість URL і кількість унікальних макетів — не те саме. Десять сторінок послуг можуть використовувати один шаблон, але потребувати різного змісту. Для кожного типу вкажіть блоки, джерело матеріалів і можливість редагування.

Наприклад: головна, шаблон послуги, список статей, стаття й контакти. Поруч зазначте, які сторінки заповнює команда, а які — власник. Детальніше про логіку розділів є в матеріалі про структуру сайту послуг.

Уточніть функції на конкретних сценаріях

Замість «інтеграція з CRM» опишіть потрібні поля, відповідального менеджера, статус нової заявки та поведінку при помилці передачі. Для пошуку товарів — за якими даними він шукає і що показує, якщо результатів немає.

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

Домовтеся про контент і SEO-основу

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

Базова SEO-підготовка може включати редаговані title та description, зрозумілі URL, заголовки, внутрішні переходи й sitemap. Постійне просування та нові статті погоджують окремо. Так само визначте обсяг мовних версій і відповідальність за переклад.

Зафіксуйте приймання й зміни

• Які сценарії перевіряють на телефоні та комп’ютері?
• Як перевіряється доставка заявки?
• Які матеріали й доступи передають власнику?
• Скільки етапів погодження входить у роботу?
• Як оцінюються нові функції після затвердження обсягу?

Додайте кілька реальних прикладів: тестове замовлення, заміну ціни, публікацію статті. Приймання за сценаріями зрозуміліше за фразу «все працює». Для попереднього бюджету перегляньте формати й стартові ціни сайтів, а логіку кошторису — у статті про вартість розробки.

Практика: перетворіть побажання на перевірювану вимогу

Замість «потрібна зручна форма» опишіть поля, обов’язковість, валідацію та результат. Наприклад: відвідувач указує спосіб зв’язку й коротку задачу, після успішного приймання бачить підтвердження українською, а команда отримує звернення в погодженій системі. Окремо опишіть помилку відправлення й повторну спробу. Це дає зрозумілий сценарій для розробки та перевірки.

Для кожної інтеграції зазначте систему, власника доступу, напрям обміну й поля. «Підключити оплату» включає не лише кнопку: потрібні статуси успіху та відмови, повернення на сайт і перевірка підтвердження від провайдера. «Додати дві мови» потребує перекладів сторінок, навігації, форм і повідомлень.

Наприкінці визначте межі: що не входить у поточний етап, скільки матеріалів переноситься, хто готує фото й тексти. Додайте перелік пристроїв або ширин для перевірки та відповідального за погодження. Якщо вимога змінюється, зафіксуйте її вплив на обсяг, строк і бюджет до виконання. Так ТЗ залишається робочим документом, а не формальністю.