Етапи розробки сайту: що відбувається від брифу до запуску

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

Ключові висновки

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

Зміст

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

Етапи розробки сайту коротко

Назви етапів у різних команд відрізняються, але порядок майже завжди однаковий. Важливо не те, як етап називається, а що ви отримуєте в його кінці.

Якщо ви ще обираєте, кому доручити проєкт, подивіться, як влаштована розробка сайту на замовлення в нашій студії: там ці ж кроки описано з боку виконавця. А далі — кожен етап докладно.

Бриф і аналіз: що вирішити до старту

Бриф — не анкета для галочки. Від його відповідей залежить усе, що буде далі: скільки сторінок, які функції, з якими сервісами сайт має працювати. Добрий бриф відповідає на п'ять питань:

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

Окреме питання для українського бізнесу — мови сайту. Стаття 27 Закону «Про забезпечення функціонування української мови як державної» вимагає, щоб інтернет-представництва суб'єктів господарювання, які зареєстровані в Україні і продають товари та послуги в Україні, виконувались державною мовою. Версії іншими мовами дозволені, але українська має бути не меншою за обсягом і змістом і завантажуватися за замовчуванням для користувачів в Україні (Закон № 2704-VIII, ст. 27). Тому кількість мов вирішують ще на брифі: від неї залежать структура, обсяг текстів і налаштування для пошуку. Це не юридична консультація.

Там само домовтеся, на кого реєструються домен і хостинг. Правильна відповідь — на вас або вашу компанію, а виконавець отримує доступ. Так сайт лишається вашим, навіть якщо колись ви зміните команду.

Результат етапу — погоджений бриф або технічне завдання. Саме за ним потім оцінюють обсяг робіт і перевіряють, чи все зроблено.

Структура, прототип і дизайн

Далі бриф перетворюється на структуру: перелік сторінок і зв'язки між ними. Потім для ключових сторінок малюють прототипи.

Прототип

Схематичний чорно-білий макет сторінки: які блоки на ній є, у якому порядку і куди ведуть кнопки. Без кольорів і фото, щоб обговорювати зміст, а не смак.

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

Якщо у вас уже є сайт

Коли новий сайт замінює старий, на цьому ж етапі складають таблицю: кожна стара адреса сторінки і нова, куди вона має вести. Google у довідці про переїзд сайту радить зіставити старі URL з новими і налаштувати серверні постійні редиректи, наприклад 301 або 308 (Google Search Central, Site moves and migrations). Без цього сторінки, які вже приводили клієнтів із пошуку, після запуску відповідатимуть помилкою «сторінку не знайдено».

Дизайн

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

На цьому кроці варто подумати про доступність — щоб сайтом могли користуватися люди з порушеннями зору, слуху чи рухливості. Міжнародний орієнтир для цього — рекомендація W3C WCAG 2.2 (W3C, WCAG 2.2). Контраст тексту, розмір кнопок і підписи полів закладають у макетах, а не латають після запуску.

Коли дизайн робимо ми, перед здачею проводимо тести зручності на клікабельних макетах, а вихідні Figma-файли і права на графіку передаємо вам — так влаштоване наше проєктування інтерфейсів і дизайн сайтів.

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

Розробка й інтеграції

На цьому етапі макети стають сайтом. Розробники збирають сторінки, підключають адмінку, форми, оплату, доставку й аналітику. Робоча версія живе на тестовому домені, закритому від пошуку, і ви бачите її ще до запуску.

Що варто вимагати від виконавця:

• Регулярні демо. У нашому процесі це демо щотижня, щоб ви завжди знали, на якому етапі проєкт.
• Адмінку без коду. Тексти, ціни, фото й нові сторінки ви змінюєте самі, без програміста.
• Доступ до репозиторію. Код має належати вам, а не жити лише на комп'ютері розробника.

Оплату перевіряють ще до запуску, без реальних грошей. Наприклад, LiqPay видає для цього тестові ключі з приставкою sandbox_ і тестові картки, а в документації прямо сказано, що реального списання і зарахування коштів під час такої перевірки не відбувається (LiqPay, тестування). Попросіть показати вам на тестовому сайті і вдалу, і невдалу оплату, перш ніж підключати робочі ключі.

Кожна форма заявки збирає персональні дані: ім'я, телефон, пошту. Стаття 12 Закону «Про захист персональних даних» вимагає повідомити людину в момент збору про володільця даних, склад і зміст зібраних даних, її права, мету збору та осіб, яким дані передаються (Закон № 2297-VI, ст. 12). На практиці це короткий текст біля форми і сторінка про обробку даних, і їх теж треба написати до запуску. Це не юридична консультація.

Результат етапу — робоча версія на тестовому домені з усіма функціями з брифу.

Наповнення і тестування перед запуском

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

Тестування — це перевірка всього, що робить сайт, а не лише того, як він виглядає:

• сторінки на телефонах і комп'ютерах, у різних браузерах;
• форми: заявка доходить туди, куди треба, — на пошту, у CRM чи месенджер;
• оплата й доставка в тестовому режимі;
• аналітика: відвідування і заявки рахуються;
• швидкість завантаження.

Для швидкості є загальноприйняті орієнтири Google — Core Web Vitals. Добрим результатом вважається, коли найбільший елемент сторінки (LCP) з'являється за 2,5 секунди, реакція на дію користувача (INP) займає до 200 мілісекунд, а зсув макета (CLS) не перевищує 0,1; міряти радять на 75-му перцентилі завантажень, окремо для мобільних і десктопів (web.dev, Web Vitals). Швидкість, SEO і доступність ми перевіряємо до запуску, а не покладаємося на везіння. Чому швидкість важить для заявок і продажів, ми розбирали в статті про оптимізацію швидкості сайту.

Результат етапу — список знайдених помилок і підтвердження, що кожну виправлено. Попросіть цей список: він показує, що тестування справді було.

Запуск і перші тижні після

Запуск — це перенесення сайту з тестового домену на ваш. У день запуску перевіряють:

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

Щоб Google дізнався про нові сторінки, карту сайту (sitemap) надсилають у Search Console або вказують рядком у файлі robots.txt. У звіті Search Console потім видно, коли Googlebot прочитав карту і чи були помилки обробки (Google Search Central, Build and submit a sitemap).

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

Наприкінці у вас мають бути доступи до домену, хостингу, адмінки і репозиторію, а також коротка інструкція, як редагувати сайт.

Як прийняти кожен етап: чекліст

Перед тим як погодити етап, дайте відповідь «так» чи «ні» на питання нижче:

1. Бриф. Чи записано головну ціль сайту, мови і список інтеграцій?
2. Структура. Чи є в карті сайту кожна сторінка, про яку ви говорили, і чи зрозуміло, куди веде кожна кнопка на прототипі?
3. Дизайн. Чи бачили ви макети для телефона, а не лише для комп'ютера?
4. Розробка. Чи можете ви самі змінити текст і ціну в адмінці тестової версії?
5. Тестування. Чи надіслали ви тестову заявку, і чи дійшла вона туди, куди треба?
6. Запуск. Чи оформлено домен, хостинг і доступ до коду на вас?

Права на код визначає договір, тож пункт про них варто перечитати ще до старту. Як закон розподіляє права на програму, створену на замовлення, ми розбирали в статті готова програма чи розробка під себе.

Висновок

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

Якщо ви плануєте новий сайт або заміну старого, розкажіть нам про проєкт — обговоримо, які етапи потрібні саме вам і що підготувати до першої зустрічі.

Часті питання

Що підготувати до першої зустрічі з розробниками?

Головну ціль сайту одним реченням; кілька сайтів, які вам подобаються чи не подобаються, і чому; список того, з чим сайт має працювати (оплата, доставка, CRM, месенджери); доступи до старого сайту й аналітики, якщо вони є. Тексти й фото на першу зустріч не потрібні, але варто знати, хто їх готуватиме.

Чи можна змінити дизайн, коли розробка вже почалася?

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

На кого реєструвати домен і хостинг?

На вас або вашу компанію. Виконавець отримує доступ для роботи, але власником лишаєтеся ви. Тоді сайт можна передати іншій команді без переговорів про доступи.

Чи обов'язкова українська версія сайту?

Для компанії, яка зареєстрована в Україні і продає товари чи послуги в Україні, — так. Стаття 27 Закону «Про забезпечення функціонування української мови як державної» вимагає, щоб українська версія сайту була не меншою за обсягом і змістом, ніж іншомовні, і завантажувалась за замовчуванням для користувачів в Україні. Інші мови додавати можна. Це не юридична консультація.

Що буде зі старим сайтом після запуску нового?

Кожну стару адресу, яка мала відвідувачів або зовнішні посилання, перенаправляють постійним редиректом на відповідну нову сторінку. Таблицю відповідностей складають ще на етапі структури, а в день запуску перевіряють, що редиректи працюють.

Джерела

1. Закон України «Про забезпечення функціонування української мови як державної» № 2704-VIII
2. Закон України «Про захист персональних даних» № 2297-VI
3. Google Search Central — Site moves and migrations
4. W3C — Web Content Accessibility Guidelines (WCAG) 2.2
5. LiqPay — Тестування
6. web.dev — Web Vitals
7. Google Search Central — Build and submit a sitemap