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

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

1. Спершу зафіксуйте, навіщо взагалі потрібен цей редизайн

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

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

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

2. Розкладіть задачу на вигляд, текст і поведінку

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

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

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

3. Назвіть сторінки, які входять у фазу, і сторінки, які цього тижня не чіпаєте

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

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

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

4. Зафіксуйте обсяг першого тижня так, щоб його можна було повторити без пояснень

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

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

5. Назвіть ризики, через які дата втрачає сенс

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

Коли зміни можна перевіряти лише на живому сайті, це треба назвати до того, як ви пообіцяли понеділок. Виправлення прямо на бойовій версії — не дрібниця, а окремий ризик для кампанії, особливо якщо сторінка вже приймає трафік. Окреме місце для перевірки — частина роботи, а не зайва бюрократія; про це є окремий текст. Таку вимогу краще вписати в бриф так само прямо, як і дедлайн.

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

6. Спершу прийміть зафіксований шматок, а вже потім розширюйте межу

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

Якщо якась перевірка не пройдена, треба назвати конкретний рядок, а не загальне враження. Фраза «щось не так» не дає команді зрозумілого наступного кроку. Якщо ж під час приймання клієнт додає ще одну сторінку, її потрібно або оформити новим рядком з новою датою, або відкласти. Мовчазне розширення межі майже гарантовано перетворює перший тиждень на третій із тим самим рахунком. Бриф при цьому має жити в одному місці, яке відкриє наступна людина без ваших пояснень. Чат для цього не підходить.

Коли краще покликати розробника ще до обіцянки дати

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

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